5 ms·

> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is

by stymaar 3mo ago

> The rust compiler is very slow. It's not “very slow”, that's a tired meme. It's slower than it could/should, but complaining about rustc being “very slow” is a clear misrepresentation, especially when everybody seems to have been fine with tsc's historical performance for instance. It could be nice if it was faster indeed, but people claiming it's “very slow” are just showing they never worked with it. > The best way to speed it up appears to be organizing a codebase in many crates. This is not preferable ergonomics to many. In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero.

minraws 3mo ago
As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.
OtomotO 3mo ago
I am using Rust since 2016 productively... before I dabbled with it. Rust is not compiling any slower than a comparable C++ codebase for me. It is compiling much slower than a managed language like Kotlin, C# etc. though. Which is an unfair comparison anyway. The problem with e.g. gamedev is the iteration cycles. It's very creative work and not so much your average engineering job (apart form game engine dev). But again, that's an unfair comparison, because even in Unity and many if not most other game engines, there is a scripting language that is used for most of the game logic, that doesn't need hyper performance... Still, when compared to such languages, Rust indeed does compile slowly AND one has to say: Rust is selling itself not only as a safe, blazingly fast systems programming language these days, but it also is used for its type system etc. and then, when you come from a managed language, compile times really suck. (Although debug builds are better, they are not an option for game dev for example, because the binary is just too slow then... 200fps vs. 20 :X)
MobiusHorizons 3mo ago
Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.
- stymaar 3mo ago
  > Why do you think it is not slow? The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means. > I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable for a human being anyway, despite the x50 difference. > That makes rust pretty slow in my book. “Slow” is a perceptual thing. It doesn't matter if it's slower in absolute benchmark performance. If it doesn't slow you down in your work it's not “slow”. > As far as I know the only language that compiles slower is C++ Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter outside of pissing contests.
  - iainmerrick 3mo ago
    Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. A 10x faster Rust compiler would be incredible.
    - stymaar 3mo ago
      > But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. And yet I'm waiting for TSC every day while almost never thinking about rustc… > The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. It will be very nice, but I don't expect it to be a game changer, tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. Anything else is pointless internet language war. > A 10x faster Rust compiler would be incredible. For development? Not really, not for me at least. Against the endless rants about rustc's performance on HN, absolutely.
kelnos 3mo ago
It depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used. Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about. > a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Nonsense. That's another Cargo.toml to maintain, and another place you might need to add/remove dependencies, and you have to manage the dependency tree among your sub-crates. The ergonomic impact is absolutely not literally zero, and I'd even say it's enough to be annoying.
- jason_s 3mo ago
  Confused here. Are you talking about the execution speed of the compiler's output, or the compilation time itself? Java's compiler is extremely fast, compared to a C compiler. (I haven't used Rust or Zig so I don't have any experience with those.)
Pay08 3mo ago
As far as I'm concerned, I already hate the write-compile-run cycle, any further slowdown in that irritates me exponentially.
vrighter 3mo ago
it is insanely slow. I regularly need to wait for minutes just for the final crate to compile when compiling some tui program from scratch

by stymaar 3mo ago

minraws 3mo ago

As much as I like Rust, > In this context (where you don't plan on publishing you stuff on crates.io) a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Is not true, you can't have circular out of crate dependencies. This often means you now need a third crate that's a trait crate, but then you can't implement external traits on external types, so you need bridge crates, and so on. Rust's limitation of performance requiring lots of crates indeed has real impacts on projects beyond simple hello worlds or trivial cli apps. Considering it to be a zero impact issue is rather reductive, even in the context of the language's design principles itself. Rust for all it's good sides has had a lack of interest from core team and energy to drive real valuable changes beyond the nightly blockers into stable, or maybe they are working real hard and the boulders are so hard to move that we can't see any change looking outside in. Is it justified after the gargantuan effort that was merging Async and GATs? Yes. But acknowledging the problem doesn't help us solve it. This is to say, Rust is an amazing labour of love project that seems rather stuck in time due to lack of investment/time/effort or all of the above, I am not sure, but it's moving slower than I would like, at solving the problems Rust developers face everyday. And yes Rust compiler is slow (very slow is arguable, compared to modern C++ it isn't that bad, but compared to say Go without cgo, its horrid), Cargo is just bad, without proper hermetic builds and stuff, even when I setup sccache for our team and our cache hit rate remained below 20% and most of it was just C++ deps hitting the cache. Just to be clear Zig builds are quite slow too, especially on windows where debug builds also use llvm. TBH Zig debug builds on Linux also don't really feel that fast, C still compiles faster for me by a considerable margin. Either way as someone doing Rust everyday for last 8+ years, 5+ in small/large teams, I have lots of complaints and I am sad, it has been over years of me complaining without nearly enough progress, they have a survey declare ambitions, and then well... things just don't move much.. not nearly as much as I would have expected. Honestly given I have been a rust dev for over half a decade now, I should instead of commenting here probably be figuring out if I can contribute to Rust to help things along (faster?). But most meetings and discussions happen at very EU/US centric times, and number of non US/European core contributors in Rust is also rather small(I don't know of one but I hope there are a few) so as someone not in those circles, I don't have the energy to figure out my way in, with my day job. Tldr; Is Rust the language for the job here, likely. But the question should be why couldn't have been the language Bun was written from the very start. Why does Zig or C++ or C seem so much more productive. Sorry for ranting about this but this felt a little relevant since you claimed people complaining, are likely people who have never worked with Rust.

OtomotO 3mo ago

I am using Rust since 2016 productively... before I dabbled with it. Rust is not compiling any slower than a comparable C++ codebase for me. It is compiling much slower than a managed language like Kotlin, C# etc. though. Which is an unfair comparison anyway. The problem with e.g. gamedev is the iteration cycles. It's very creative work and not so much your average engineering job (apart form game engine dev). But again, that's an unfair comparison, because even in Unity and many if not most other game engines, there is a scripting language that is used for most of the game logic, that doesn't need hyper performance... Still, when compared to such languages, Rust indeed does compile slowly AND one has to say: Rust is selling itself not only as a safe, blazingly fast systems programming language these days, but it also is used for its type system etc. and then, when you come from a managed language, compile times really suck. (Although debug builds are better, they are not an option for game dev for example, because the binary is just too slow then... 200fps vs. 20 :X)

MobiusHorizons 3mo ago

Why do you think it is not slow? As far as I know the only language that compiles slower is C++, and even then the compilation speeds between c++ and rust seem to be comparable. I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. That makes rust pretty slow in my book. I get that it doesn’t bother everyone, but that doesn’t change the facts.

stymaar 3mo ago
> Why do you think it is not slow? The average cargo check for the projects I've worked on, usually finish in less than 1 second, with `cargo build` completing in a single digit second (often below 2s), it's not slow by any means. > I believe c, Fortran, zig, C#, Java and golang are all faster compiling languages. Sure, but the difference between type checking is 10ms and type checking in 500ms is barely noticeable for a human being anyway, despite the x50 difference. > That makes rust pretty slow in my book. “Slow” is a perceptual thing. It doesn't matter if it's slower in absolute benchmark performance. If it doesn't slow you down in your work it's not “slow”. > As far as I know the only language that compiles slower is C++ Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter outside of pissing contests.
- iainmerrick 3mo ago
  Typescript's compiler is much slower than Rust's, but it's plenty fast enough for most people and you almost never see complains about it because it mostly doesn't matter But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. A 10x faster Rust compiler would be incredible.
  - stymaar 3mo ago
    > But you have to compile Rust code to run it. You can run TypeScript code without type-checking it. That’s a massive difference in the development workflow. And yet I'm waiting for TSC every day while almost never thinking about rustc… > The new TSC, supposedly 10x faster, will be very pleasant to have but not as much of a game-changer as you might expect. It will be very nice, but I don't expect it to be a game changer, tsc isn't fast but it's fast enough to get the work done, the annoyance is there but it's objectively minimal. Anything else is pointless internet language war. > A 10x faster Rust compiler would be incredible. For development? Not really, not for me at least. Against the endless rants about rustc's performance on HN, absolutely.

kelnos 3mo ago

It depends on what you're comparing it to. It is indeed very slow when compared to a C compiler, or a zig compiler, or even a Java compiler. C++ can be comparable, or slower, or faster, depending on the C++ features used. Sure, maybe rustc's performance compares favorably to how tsc used to be, but that's not the benchmark most Rust developers (such as myself, for more than 10 years now) care about. > a “crate” are just a directory at the root of your repo, the ergonomic impact is literally zero. Nonsense. That's another Cargo.toml to maintain, and another place you might need to add/remove dependencies, and you have to manage the dependency tree among your sub-crates. The ergonomic impact is absolutely not literally zero, and I'd even say it's enough to be annoying.

jason_s 3mo ago
Confused here. Are you talking about the execution speed of the compiler's output, or the compilation time itself? Java's compiler is extremely fast, compared to a C compiler. (I haven't used Rust or Zig so I don't have any experience with those.)

Pay08 3mo ago

As far as I'm concerned, I already hate the write-compile-run cycle, any further slowdown in that irritates me exponentially.

vrighter 3mo ago

it is insanely slow. I regularly need to wait for minutes just for the final crate to compile when compiling some tui program from scratch