Rust compiler performance
243 comments
·June 10, 2025norir
pjmlp
Not only language.
Many of complaints towards Rust, or C++, are in reality tooling complaints.
As shown on other ecosystems, the availability of interpreters or image based tooling are great ways to overcome slow optimizating compilers.
C++ already had a go at this back in the early 90's with Energize C++ and Visual Age for C++ v4, both based on Common Lisp and Smalltalk from their respective owners.
They failed on the market due to the hardware requirements for 90's budgets.
Now slowly coming back with tooling like Visual C++ hot reload improvements, debugging optimised builds, Live++, Jupiter notebooks.
Rational Software started their business selling Ada Machines, the same development experience as Lisp Machines, but with Ada, lovely inspired on Xerox PARC experience with Mesa and Mesa/Cedar.
Haskell and OCaml, besides the slow compilers, have bytecode interpreters and REPLs.
D has the super fast dms, with ldc and gdc, for the optimised builds suffering from longer compile times.
So while Rust cannot be archited in a different way, there is certainly plenty of room for interpreters, REPLs, not compiling always from source and many other tooling improvements, within the same language.
hinkley
I had a coworker who was using Rational back then, and found out one of its killer features was caching of pre compiled headers. Whoever changed them had to pay the piper of compilation, but everyone else got a copy shipped to them over the local network.
pjmlp
Yes, you are most likely talking about ClearMake, the build tool used by ClearCase.
It may have required dedicated infra team, but it had features that many folks only got to discover with git.
Better save those view description configurations safely.
kibwen
It's certainly possible to think of language features that would preclude trivially-achievable high-performance compilation. None of those language features that are present in Rust (specifically, monomorphized generics) would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.
panstromek
There are many more mundane examples of language design choices in rust that are problematic for compile time. Polymorphization (which has big potential to speed up compile time) has been blocked on pretty obscure problems with TypeId. Procedural macros require double parsing. Ability to define items in function bodies prevents skipping parsing bodies. Those things are not essential, they could pretty easily be tweaked to be less problematic for compile time without compromising anything.
kibwen
This is an oversimplification. Automatic polymorphization is blocked on several concerns, e.g. dyn safety (and redesigning the language to make it possible to paper over the difference between dyn and non-dyn safe traits imposes costs on the static use case), and/or obscure LLVM implementation deficiencies (which was the blocker for the last time I proposed a Swift-style ABI to address this). Procedural macros don't require double-parsing; many people do use syn to parse the token stream, but 1) parsing isn't a performance bottleneck, 2) providing a parsed AST rather than a token stream freezes the AST, which is something that the Rust authors deliberately wanted to avoid, rather than being some kind of accident of design, 3) at any point in the future the Rust devs could decide to stabilize the AST and provide a parsed representation, so this isn't anything unfixable that would cause any sort of trauma in the community, 4) proc macro expansions are trivially cacheable if you know you're not doing arbitrary I/O, which is easy to achieve manually today and should absolutely be built-in to the compiler (if for no other reason than having a sandboxed dev environment), but once again this is easy to tack on in future versions. As for allowing item definitions in function bodies, I want to reiterate that parsing is not a bottleneck.
WhyNotHugo
Macros themselves are a terrible hack to work around support for proper reflection.
The entire Rust ecosystem would be reshaped in such fascinating ways if we had support for reflection. I'd love to see this happen one day.
Someone
> would have ever been considered for omission, regardless of their compile-time cost, because that would have compromised Rust's other goals.
That basically says compiler speed isn’t a goal at all for Rust. I think that’s not completely true, but yes, speed of generated code definitely ranks very high for rust.
In contrast, Wirth definitely had the speed at which the Oberon compiler compiled code as a goal (often quoted as that he only added compiler optimizations if they made the compiler itself so much faster that it didn’t become slower because of the added complexity, but I’m not sure he was that strict)
http://www.projectoberon.net/wirth/CompilerConstruction/Comp..., section 16.1:
“It is hardly surprising that certain measures for code improvement may yield considerable gains with modest effort, whereas others may require large increases in compiler complexity and size while yielding only moderate code improvements, simply because they apply in rare cases only.
Indeed, there are tremendous differences in the ratio of effort to gain. Before the compiler designer decides to incorporate sophisticated optimization facilities, or before deciding to purchase a highly optimizing, slow and expensive compiler, it is worth while clarifying this ratio, and whether the promised improvements are truly needed.
Furthermore, we must distinguish between optimizations whose effects could also be obtained by a more appropriate formulation of the source program, and those where this is impossible.
The first kind of optimization mainly serves the untalented or sloppy programmer, but merely burdens all the other users through the increased size and decreased speed of the compiler.
As an extreme example, consider the case of a compiler which eliminates a multiplication if one factor has the value 1. The situation is completely different for the computation of the address of an array element, where the index must be multiplied by the size of the elements. Here, the case of a size equal to 1 is frequent, and the multiplication cannot be eliminated by a clever trick in the source program.”
kibwen
> That basically says compiler speed isn’t a goal at all for Rust
No, it says that language design inherently involves difficult trade-offs, and the Rust developers consciously decided that some trade-offs were worth the cost. And their judgement appears to have been correct, because Rust today is more successful than even the most optimistic proponent would have dared to believe in 2014; that users are asking for something implies that you have succeeded to the point of having users at all, which is a good problem to have and one that nearly no language ever enjoys.
In the context of Oberon, let's also keep in mind that Rust is a bootstrapped compiler, and in the early days the Rust developers were by far the most extensive users of the language; nobody on Earth was more acutely affected by compiler performance than they were. They still chose to prefer runtime performance (to be competitive with C++) over compiler performance (to be competitive with Go), and IMO they chose correctly.
And as for the case of Oberon, its obscurity further confirms that prioritizing compiler performance at all cost is not a royal road to popularity.
swsieber
What about crates as the unit of compilation? I am genuinely curious because it's not clear to me what trade-offs there are around that decision.
pornel
It's a "unit" in the sense of calling `rustc` once, but it's not a minimal unit of work. It's not directly comparable to what C does.
Rust has incremental compilation within a crate. It also splits optimization work into many parallel codegen units. The compiler front-end is also becoming parallel within crates.
The advantage is that there can be common shared state (equivalent of parsing C headers) in RAM, used for the entire crate. Otherwise it would need to be collected, written out to disk, and reloaded/reparsed by different compiler invocations much more often.
kibwen
All compilers have compilation units, there's not actually much interesting about Rust here other than using the word "crate" as a friendlier term for "compilation unit".
What you may be referring to instead is Cargo's decision to re-use the notion of a crate as the unit of package distribution. I don't think this was necessarily a bad idea (it certainly made things simpler, which matters when you're bootstrapping an ecosystem), but it's true that prevailing best practices since then have led to Rust's ecosystem having comparatively larger compilation units (which itself isn't necessarily a bad thing either; larger compilation units do tend to produce faster code). I would personally like to see Cargo provide a way to decouple the unit of distribution from the unit of compilation, which would give us free parallelism (which currently today rustc needs to tease out via parallel codegen units (and the forthcoming parallel frontend)) and also assuage some of the perpetual hand-wringing about how many crates are in a dependency tree (which is exactly the wrong measure as getting upset about how many source files are in your C program). This would be a fully backwards-compatible change.
fngjdflmdflg
This was a big reason for dart canceling its previous macros attempt (as I understand it). Fast compilation is integral for Flutter development - which accounts for a late percentage of dart usage - so after IIRC more than two years of developing it they still ended up not going through with that iteration of macros because it would make hot reload too slow. That degree of level-headedness and consideration is worthy of respect IMO.
krzat
Dart is a meh language but their focus on hot reload single handedly made it worth it's existence.
WhyNotHugo
One of the issue why compile times are so awful is that all dependencies must be compiled for each project.
20 different projects use the same dependency? They each need to recompile it.
This is an effect of the language not having a proper ABI for compiling libraries as dynamically loadable modules, which in itself presents many other issues, including making distribution of software a complete nightmare.
kibwen
> This is an effect of the language not having a proper ABI for compiling libraries as dynamically loadable modules
No, this is a design decision of Cargo to default to using project-local cached artifacts rather than caching them at the user or system level. You can configure Cargo to do so if you'd like. The reason it doesn't do this by default is because Cargo gives crates great latitude to configure themselves via compile-time flags, and any difference in flags means you get a different compiled artifact anyway. On top of that, there's the question of what `cargo clean` should do when you have a global cache rather than a local one.
CrendKing
Why can't Cargo have a system like PyPI where library author uploads compiled binary (even with their specific flags) for each rust version/platform combination, and if said binary is missing for certain combination, fallback to local compile? Imagine `cargo publish` handle the compile+upload task, and crates.io be changed to also host binaries.
eddd-ddde
Dependencies must compile with the right features enabled. You can't possibly share the 2^n versions of every binary. ABI stability doesn't fix this.
surajrmal
If you use bazel to compile rust, it doesn't suffer from this problem. In fact you can get distributed caching as well.
goodpoint
That's solved with sccache but even with that compilation time is still garbage
feelamee
maybe rustc will never be re-architectured (although it has already been rewritten once), but with developing rust standard there will come new Rust implementations. And there is a chance that they will prioritize performance when architecting.
muth02446
The key to unlocking a 10x improvement to compilation speeds will like be multithreading. I vaguely remember that LLVM struggled with this and I am not sure where it stands today. On the frontend side language (not compiler) design will affect how well things can be parallelized, e.g. forward declatations probably help, mandatory interprocedural anaylyses probably hurt.
Having said that, we are in a bad shape when golang compiling 40kLOC in 2s is a celebrated achievement. Assuming this is single threaded on a 2GHz machine, we 2s * 2GHz / 40kLOC = 100k [cycles] / LOC
That seems like a lot of compute and I do not see how this cannot be improved substantially.
Shameless plug: the Cwerg language (http://cwerg.org) is very focussed on compilation speeds.
Fiahil
At some point, the community is also responsible for the demanding expectation of a "not slow" compiler.
What's "slow"? What's "fast"? It depends. It depends on the program, the programmer, his or her hardware, the day of the week, the hour of the day, the season, what he or she had for lunch, ...
It's a never ending quest.
I, for exemple, am perfectly happy with the current benchmark of the rust compiler. I find a x2 improvement absolutly excellent.
felipeccastro
It is ironic how “rewrite it in Rust” is the solution to make any program fast, except the Rust compiler.
jplusequalt
Having worked on large scale C++ code-bases and thus used to long compilation times, it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust.
maccard
I work on large c++ code bases day in day out - think 30 minute compiles on an i9 with 128GB ram and NVMe drives.
Rusts compile times are still ungodly slow. I contributed to a “small to medium” open source project [0] a while back, fixing a few issues that we came across when using it. Given that the project is approximately 3 orders of magnitude smaller than my day to day project, a clean build of a few thousand lines of rust took close to 10 minutes. Incremental changes to the project were still closer to a minute at the time. I’ve never worked on a 5m+ LOC project in rust, but I can only imagine how long it would take.
On the flip side, I also submitted some patches to a golang program of a similar size [1] and it was faster to clone, install dependencies and clean build that project than a single file change to the rust project was.
sapiogram
Thanks for actually including the slow repo in your comment. My results on a Ryzen 5900X:
* Clean debug build: 1m 22s
* Incremental debug build: 13s
* Clean release build: 1m 51s
* Incremental release build: 24s
Incremental builds were done by changing one line in creates/symbolicator/src/cli.rs.
It's not great, but it sounds like your experience was much worse for some reason.
maccard
For reference, buildkite-agent [0] is about 40k lines of go. Running `go build` including dependencies took 40 seconds, and running `go clean && go build` took 2 seconds. I know Go and Rust aren't comparable, but Rust's attitude appears to be "we don't really care" when you compare it to Go, considering they both started at _roughly_ the same time and Rust's first stable release came long after Go was in use.
maccard
Sorry - my clean build was actually including the dependency fetching, which is a large part of it. My experience was in 2023 which if we go by article roughly scales with compiler performance to 5 minutes or so
Fluorescence
> clean build of a few thousand lines of rust took close to 10 minutes
That doesn't sound likely. I would expect seconds unless something very odd is happing.
Is the example symbolicator?
I can't build the optional "symbolicator-crash" crate because it's not rust but 300k of C++/C pulled from a git submodule that requires dependencies I am not going to install. Your complaint might literally be about C++!
For the rest of the workspace, 60k of rust builds in 60 seconds
- clean debug build on a 6 year old 3900X (which is under load because I am working)
- time includes fetching 650 deps over a poor network and building them (the real line count of the build is likely 100s of thousands or millions of lines of code)
- subsequent release build took 100s
- I use the mold linker which is advised for faster builds
- modern cpus are so much faster than my machine they might not even take 10s
maccard
> That doesn't sound likely. I would expect seconds unless something very odd is happing.
And yet here we are.
There are plenty of stories like this floating around of degenerate cases of small projects. Here's [0] one example with numbers and how they solved it. There are enough of these issues that by getting bogged down in "well technically it's not Rust's fault, it's LLVM's single threadedness causing the slowdown here" ignores the point - Rust (very fairly) has a rep for being dog slow to compile even compared to large C++ projects
> For the rest of the workspace, 60k of rust builds in 60 seconds
That's... not fast.
https://github.com/buildkite/agent is 40k lines of go according to cloc, and running `go build` including pulling dependencies takes 40 seconds. Without pulling dependencies it's 2 seconds. _That's_ fast.
[0] https://www.feldera.com/blog/cutting-down-rust-compile-times...
9d
Just curious, are you still able to get instant feedback and development conveniences on that 30 minute compile time project, like up to date autocomplete and type hints and real-time errors/warnings while developing before compiling?
maccard
Yeah - there’s a 60-ish second delay in my IDE before this info is available but once it’s there it’s there.
jason-johnson
Can you say what your development environment was like? I was having 15 minute build times for a pretty small system. Everyone talks about how slow Rust compile times are so I thought that's just how it is. Then, by chance, I ended up building from a clean install on my work laptop and it took about 3 minutes from scratch.
My development environment is VS Code running in a Dev container in docker desktop. So after my work laptop was so fast, I made some changes to my Mac docker desktop and suddenly the mac could build the project from scratch in about 2 minutes. Incremental compile was several minutes before, instant now.
maccard
Cargo in vscode on windows on a monstrously big machine (3990x/128GB RAM/NVMe drive, Gigabit Ethernet)
I think if it's that sensitive to environment issues, that solidifies the point that there are major problems that lots of people are going to have.
hinkley
30 minutes versus 60 is really an hour versus two.
Some coworkers and I noticed a long time ago that once you try to task switch while doing build/test automation steps, it always seems like you remember to come back and check about twice as long as the compile was supposed to take. 7+ turned into 15, 15 into a half hour.
And then one day it hit me that this is just Hofstadter’s Law. You think you have ten minutes so you start a ten minute task and it takes you twenty, or you get in a flow and forget to look until your senses tell you you’re forgetting something.
Cutting 10 minutes off a build really averages 20 minutes in saved time per cycle. Which matters a hell of a lot when you go from 4 to 5 cycles per 8 hour day.
jplusequalt
Yes, but Go is a higher level language than Rust. It feels unfair to compare the two. That's why I brought up C++ (as did the article).
maccard
I disagree that it’s unfair to compare the two. The performance difference between go and rust is far less than the difference between go and python, it has a garbage collector sure but it’s an example of a language designed for fast compilation time that achieves an order of magnitude faster compile times than rust
afdbcreid
What are incremental compile times with the C++ codebase?
Also, does the line of code you count include dependencies (admitting, dependencies in Rust are a problem, but it's not related to compiler performance)?
maccard
About 15 seconds, because we carve it up into 100 or so dlls specifically for this case
phkahler
>> it surprises me that this is the hill many C++ devs would die on in regards to their dislike of Rust
I believe people will exaggerate their current issue so it sounds like the only thing that matters to them. On another project I've had people say "This is the only thing that keeps me using commercial alternatives" or the only thing holding back wider adoption, or the only thing needed for blah blah blah. Meanwhile I've got my own list of high priority things needed to bring it to what I'd consider a basic level of completeness.
When it comes to performance it will never be good enough for everyone. There is always a bigger project to consume whatever resources are available. There are always people who insist on doing things in odd ways (maybe valid, but very atypical). These requests to improve are often indistinguishable from the regular ones.
pton_xd
Makes sense to me! Everyone with enough C++ experience has dealt with that nightmare at one point. Never again, if you can help it.
0cf8612b2e1e
It is a quantifiable negative to which you can always point. Of course it will be used for justifications.
logicchains
There's a lot of things you can do in C++ to reduce compilation time if you care about it, that aren't possible with Rust.
kibwen
You can absolutely do the same things in Rust, it's just that the culture and tooling of Rust encourages much larger compilation units than in C or C++, so you don't get the same sort of best-case nontrivial embarrassing-parallelism, forcing the compiler to do more work to parallelize.
To address the tooling pressure, I would like to see Cargo support first-class internal-only crates, thereby deconflating the crate as what is today both the unit of compilation and the unit of distribution.
MeetingsBrowser
There are things you can do for Rust if it really is a deal breaker.
Dioxus has a hot reload system. Some rust game engines have done similar things.
jplusequalt
When in doubt, manually patch your dll's
bnolsen
The answer there was to always write small standalone executable unit test sets and simulation for day to day coding. Avoiding template heavy pigs like QT or boost helps too.
akazantsev
> Avoiding template heavy pigs like QT
Well, you definitely have no experience with Qt.
throwaway664786
C++ is one of the fastest languages to compile*, assuming you aren't doing silly stuff like abusing templates. It just gets a bad rep because actual, real-world, massive projects are written in C++. Like, yeah, no wonder Chromium build times aren't spectacular, but I assure you that they'd be much, much worse if it was written in Rust. Pointing and scoffing at it when there's nothing written in Rust that we can even compare it to is just intellectually dishonest.
* It's not beating interpreted languages any time soon, but that's not really a fair comparison.
kristoff_it
> Speaking of DoD, an additional thing to consider is the maintainability of the compiler codebase. Imagine that we swung our magic wand again, and rewrote everything over the night using DoD, SIMD vectorization, hand-rolled assembly, etc. It would (possibly) be way faster, yay! However, we do not only care about immediate performance, but also about our ability to make long-term improvements to it.
This is an unfortunate hyperbole from the author. There's a lot of distance between DoD and "hand-rolled assembly" and thinking that it's fair to put them in the same bucket to justify the argument of maintainability is just going to hurt the Rust project's ability to make a better compiler for its users.
You know what helps a lot making software maintainable? A Faster development loop. Zig has invested years into this and both users and the core team itself have started enjoying the fruits of that labor.
https://ziglang.org/devlog/2025/#2025-06-08
Of course everybody is free to choose their own priorities, but I find the reasoning flawed and I think that it would ultimately be in the Rust project's best interest to prioritize compiler performance more.
Rusky
"Hand-rolled assembly" was one item in a list that also included DoD. You're reading way more into that sentence than they wrote- the claim is that DoD itself also impacts the maintainability of the codebase.
deadfa11
I was working on a zig project recently that uses some complex comptime type construction. I had bumped to the latest dev version from 0.13, and I couldn't believe how much improvement there has been in this area. I am very appreciative of really fast iteration cycles.
90s_dev
Yeah but it's Zig. Rust is for when you want to write C but have it be easier. Zig is when you want it to be harder than C, but with more control over execution and allocation as a trade off.
AndyKelley
For anyone who wants to form their own opinion about whether this style of programming is easier or harder than it would be in other languages:
https://github.com/ziglang/zig/blob/0.14.1/lib/std/zig/token...
Rusky
The tokenizer is not really a good demonstration of the differences between these styles. A more representative comparison would be the later stages that build, traverse, and manipulate tree and graph data structures.
dgb23
I had almost the exact opposite experience.
moooo99
I share this impression. I’ve never worked much with low level languages with the exception of a few university assignments. I did last years advent of code in Zig and was quite productive and never really struggled with the language that much. Meanwhile, rust makes things a lot more complicated on my current project.
The main benefit of rust over zig seems to be the maturity. Rust has had a decade+ to stabilize and build an ecosystem while Zig is still a very new language
juliangmp
>[...] this will depend on who you ask, e.g. some C++ developers don’t mind Rust’s compilation times at all, as they are used to the same (or worse) build times
Yeah pretty much. C++ is a lot worse when you consider the practical time spent vs compilation benchmarks. In most C++ projects I've seen/worked on, there were one or sometimes more code generators in the toolchain which slowed things down a lot.
And it looks even more dire when you want to add clang-tidy in the mix. It can take like 5 solid minutes to lint even small projects.
When I work in Rust, the overall speed of the toolchain (and the language server) is an absolute blessing!
carlmr
>And it looks even more dire when you want to add clang-tidy in the mix. It can take like 5 solid minutes to lint even small projects.
And running all tests with sanitizers, just to get some runtime checks of what Rust excludes at compile time.
I love Rust for the fast compile times.
feelamee
why do you run clang-tidy with compiler? Just use it interactively - with cland. These is much more useful to me
adrian17
> On this benchmark, the compiler is almost twice as fast than it was three years ago.
I think the cause of the public perception issue could be the variant of Wirth's law: the size of an average codebase (and its dependencies) might be growing faster than the compiler's improvements in compiling it?
IshKebab
Yeah definitely when you include dependencies. Also I've noticed that when your dependency tree gets above a certain size you end up pulling in every alternative crate for a certain task, because e.g. one of your dependencies uses miniz_oxide and another uses zlib-rs (or whatever).
On the other hand the compile to for most dependencies doesn't matter hugely because they are easy to do in parallel. It's always the last few crates and linking that take half the time.
kjuulh
Could Rust be faster, yes. But honestly, for our use-case shipping; tools, services, libraries and what have you in production, it is plenty fast. That said, Rust definitely falls off a cliff once you get to a very large workspace (I'd say plus 100k lines of code it begins to snowball), but you can design yourself out of that, unless you build truly massive apps.
Incremental builds doesn't disrupt my feedback loop much, only when paired with building for multiple targets at once. I.e. Leptos where a wasm and native build is run. Incremental builds do however, eat up a lot of space, a comical amount even. I had a 28GB target/ folder yesterday from working a few hours on a leptos app.
One recommendation is to definitely upgrade your CI workers, Rust definitely benefits from larger workers than the default GitHub actions runners as an example.
Compilling a fairly simple app, though including DuckDB which needs to be compiled, took 28 minutes on default runners. but on a 32x machine, we're down to around 3 minutes. Which is fast enough that it doesn't disrupt our feedback loop.
ruuda
The Rust ecosystem is getting slower faster than the compiler is getting faster. Libraries grow to add features, they add dependencies. Individually the growth is not so bad, and justified by features or wider platform support. But they add up, and especially dependencies adding dependencies act as a multiplier.
I started writing a post about this many years ago, but never finished it. I took a few slow-changing projects of mine that had a pinned Rust compiler, and then updated both the compiler and dependencies to the latest versions. Invariably, everything got slower to compile, even though the compiler update in isolation made things faster!
eddd-ddde
When a platform has good support and is easy to onboard this is the inevitable result. It's just like the JavaScript ecosystem.
But this is not a downside. Just like I can start a new website project and not use a single dependency, I can start a new rust project and not install a single dependency.
To me the real value is in the tools and core language feature. I could probably implement my own minimal ad-hoc async IO framework if I wanted to, and shape it to my needs. No dependencies.
simonask
I don't know, these things ebb and flow.
There's a bit of pushback against high-dependency project structures and compile times recently, and even niche crates like `unsynn` have garnered some attention as an alternative to the relatively heavy `syn` crate.
jadbox
Not related to the article, but after years of using Rust, it still is a pain in the ass. While it may be a good choice for OS development, high frequency trading, medical devices, vehicle firmware, finance software, or working on device drivers, it feels way overkill for most other general domains. On the other hand, I learned Zig and Go both over a weekend and find they run almost as fast and don't suffer from memory issues (as much as say Java or C++).
sfvisser
This comment would have been more useful with some qualification of why that’s the case. The language, tooling, library ecosystem? Something else?
skrtskrt
For me the hangup is that async is Still Hard. Just a ridiculous amount of internal implementation details exposed in order to just write, like, an http middleware.
We looked at proposing Rust as the second blessed language in addition to Go where I work, and the conclusion was basically... why?
We have skilled Go engineers that can drop down to manual memory management and squeeze lots of extra performance out of it. And it's still dead simple when you don't need to do that or the task is suitable for a junior engineer. And channels are simply one of the best concurrency primitives out there, and baked into the language unlike Rust where everything is library making independent decisions. (to be fair I haven't tried Elixir/Erlang message passing, I understand people like that too).
akazantsev
For Go, it's a design decision. From the start, they strived to make compilation as fast as possible.
https://en.wikipedia.org/wiki/Go_(programming_language)#Desi...
bobbylarrybobby
Not to be that guy who comes to Rust’s defense whenever Go is mentioned, but... Rust protects from a much larger class of errors than just memory safety. For instance, it is impossible to invalidate an iterator while iterating over it, refer to an unset or invalid value, inadvertently merely shallow copy a variable, or forget to lock/unlock a mutex.
codr7
If only these were common problems that were difficult to otherwise avoid.
dvt
I like Rust, but I think this post is unfairly downvoted. Rustaceans often annoyingly point out that "you can't use super-common-footgun X with Rust!" which, while true, they also omit the compromises made are immense (frankly, compiler performance is one of them).
90s_dev
Rust feels like wearing a giant bubble just to go outside safely.
C++ feels like driving a car. Dangerous but doable and often necessary and usually safe.
(Forth feels like being drunk?)
90s_dev
Could you elaborate on the memory issues in all four languages that you ran into?
kunley
The article is fine and has a lot of good points, but tries to avoid the main issue like a plague. So I will speak it here:
The slowness comes mainly from LLVM.
kobzol
For many use-cases yes, but there are crates bottlenecked on different things than the codegen backend.
But I don't think that's the point. We could get rid of LLVM and use other backends, same as we could do other improvements. The point is that there are also other priorities and we don't have enough manpower to make progress faster.
kunley
Fair reply, thank you.
panstromek
This is somewhat true but also a bit misleading. Lot of the problems comes from how rust interacts with it, and how are rust projects structured. This ultimately shows up as time in LLVM, but LLVM is not entirely responsible for it.
Animats
This isn't a huge problem. My big Rust project compiles in about a minute in release mode. Failed compiles with errors only take a few seconds. That's where most of the debugging takes place. Once it compiles, it usually works the first time.
afdbcreid
But how big are your big projects?
Animats
About 40,000 lines of my own code, plus a hundred or so crates from crates.io.
johnfn
A minute is pretty bad. I understand it may work for your use case, but there are plenty of use cases out there where errors typically don't fail the compile and a minute iteration time is a deal killer. For instance: UI work - good luck catching an incorrect color with a compile error. Vite can compile 40,000 loc and display it on your screen in probably a couple of milliseconds.
dominicrose
Different programming languages have different qualities. For some tasks I like Ruby because it doesn't get in my way. But Ruby is built in C and so are JS VMs and web browsers etc (C/C++/Rust). A good LLM can convert Ruby code to Rust for a 10-100x performance boost, only multiplying the number of lines of code by 2. That makes Ruby a good programming language and Rust a good target language.
shmerl
Consider how long it takes to compile the Linux kernel for example. So one minute is very good.
kalaksi
Compile what language?
FridgeSeal
Probably js given they mentioned Vite; not exactly sure I’d call it “compiling” in nearly t he r same order of magnitude of complexity though…
vlovich123
I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.
I wonder if the JVM as an initial target might be interesting given how mature and robust their JIT is.
bbatha
> I wonder if how much value there is in skipping LLVM in favor of having a JIT optimized linked in instead. For release builds it would get you a reasonable proxy if it optimized decently while still retaining better debugability.
Rust is in the process of building out the cranelift backend. Cranelift was originally built to be a JIT compiler. The hope is that this can become the debug build compiler.
actualwitch
I recently tried using cranelift on a monorepo with a bunch of crates, and it is nothing short of amazing. Nothing broke and workspace build time went from a minute and a half to a half of a second!
lsuresh
Was this for a release build or a debug build?
zozbot234
The JVM is not a very meaningful target for Rust since it does not use C-like flat memory addressing and pointer arithmetic. It's as if every single Java object and field is sitting in its own tiny memory segment/address space. On the one hand, this makes it essentially transparent to GC, which is a key property for Java; OTOH, it means that compiling C-like languages to the JVM is usually done by reimplementing "memory" as a JVM array of byte values.
lsuresh
LLVM optimizations are the overwhelming majority of the compilation bottleneck for us over at Feldera. We blogged about some of the challenges we faced here: https://www.feldera.com/blog/cutting-down-rust-compile-times...
We almost definitely need to build a JIT in the future to avoid this problem.
dhruvrajvanshi
I would love this in modern languages.
For dev builds, I see JIT compilation as a better deal than debug builds because it's capable of eventually reaching peak performance. For performance sensitive stuff like games, it really matters to keep a nice feedback loop without making the game unusable by turning off all optimizations.
AOT static binaries are valuable for deployments.
No idea how expensive it would be to develop for an existing language like Rust though.
lrvick
If anyone wants to feel better about compile times for their rust programs, try full source bootstrapping the rust compiler itself. Took about 2 days on 64 cores until very recently (thanks to mrustc 0.74). Now only 7 hours!
Compiler performance must be considered up front in language design. It is nearly impossible to fix once the language reaches a certain size without it being a priority. I recently saw here the observation that one can often get a 2x performance improvement through optimization, but 10x requires redesigning the architecture.
Rust can likely never be rearchitected without causing a disastrous schism in the community, so it seems probable that compilation will always be slow.