> It's easy to understate how big of a deal this is for the compiler. This work resolves a major piece of technical debt that a lot of compiler developers dreamed about for years.
No kidding. I’ve been waiting for the solver at least half that decade now. Hopefully it and Polonius unblock specialization which has been in purgatory for years.
It's not directly blocked on the solver, but getting the type system into a better shape definitely helps reasoning about the soundness issues involved.
yhjc2692 6 hours ago [-]
Smaller target directory size would be such a lifesaver. Hoping the best for you, and Rust!
stymaar 4 hours ago [-]
This!
There's a recurring meme here and in other social media about rust being slow to compile, but anyone who's worked with Rust know that target dirs are a much more annoying papercut in practice than the relative speed of the compiler (which isn't appreciably worse than any other toolchain out there for the most common workflows).
anonymous908213 3 hours ago [-]
A papercut is an unbelievable way to describe this. I tried forking Codex CLI and, for a terminal UI that manages chats and HTTP requests, it takes over 15 minutes to rebuild trivial changes on a top-shelf CPU with all incremental/caching optimizations, and tens of GBs in build caches. Neither of those is acceptable. Full stop. I am aware part of the problem is that Codex CLI is a vibe-coded monstrosity (surprise, software is not solved), but I've not had this problem with vibe-coded monstrosities in eg. Go. Hold your language to better standards. That doesn't mean abandon Rust; that means strive to make the Rust toolchain better than the Go toolchain rather than shrugging your shoulders and saying "lol this is fine no way anybody could do anything about this".
xyzzy_plugh 1 hours ago [-]
I've seen three outages at various orgs that were prolonged due to compile times. In these cases it was a root contributor to missing RTO. The compile times are a liability.
One proposal I came across actually suggested breaking up a perfectly fine monolith into a dozen microservices to reduce compile times (at the cost of cumulative CI costs going up).
When the alternative is massively rearchitecting your systems, Zig and Go begin to look really nice by comparison.
simonask 3 hours ago [-]
I have no idea about the code quality of Codex CLI, but it takes way way less time to build a full game engine (Bevy).
Stories like this make me think something is wrong with your setup. Do you have Windows Defender or similar enabled on the build directory?
shakna 23 minutes ago [-]
Bevy is intentionally sharded across many crates, is small, and has the dev working on optimised build times.
That isn't "Rust compiles are fast", it's another example of "Rust requires you architect your code a specific way".
aliasxneo 1 hours ago [-]
Weird take. I've worked in large Rust projects for half a decade (in one case, a full blockchain written in Rust). It's slow, full stop. I was under constant pressure to keep CI times down and was resorting to some of the craziest optimizations just to save a few minutes. Meanwhile, all of the platform code I was writing in Go almost never had a CI time above a few minutes.
Doesn't mean one is better than the other, but to find it odd someone had an experience with slow Rust compiliations and then blame it on their setup is a bit odd.
okanat 15 minutes ago [-]
What kind of Rust projects? How many dependencies? Does it use macros? How about generics and traits?
Most of the Rust ecosystem makes unnecessarily heavy use of compile-time traits and monomorphized generics (aka Go generics or C++ templates). The language syntax encourages it as well. The thing is compile times will NEVER drop to level of Go unless the entire set of players (language, standard library, almost all library developers) actually prioritize dynamic dispatching instead of static dispatching / monomorphization. That's the tradeoff for the performance and RAM usage you gain. Template-heavy C++ also suffers from the same issues for the same reason.
Golang is fast to compile because its interface definitions are runtime/dynamically dispatched (aka `&dyn Trait` in Rust or virtual classes in C++) and it had no generics for a long time forcing types like slices, map and vectors to be magic types.
If you need fast compile times, you need to split your program into multiple binaries or write your own backend ecosystem that almost only uses dynamic dispatching. If your full Cargo dependency tree pulls 50+ crates, you'll not get fast compile times. You need to avoid derive-macros like plague. You need to use non-Cargo build systems or `build.rs` to generate Rust code instead of derive-macros.
Unlike Golang Rust also targets extremely memory constrained devices where monomorphization enables memory savings, extra optimizations and fewer CPU cycles / instructions (e.g. microcontrollers, UEFI/BIOS implementation). It is a system programming language first. With system programming languages you are responsible for these choices as the developer. Rust just happens to have a vivid scene of backend libraries since the language's safety enabled many non-system developers to write correct and performant programs quickly.
simonask 5 minutes ago [-]
Well, me too, and I can confidently tell you I’ve never seen build times in the 10+ minute range (on capable machines).
3 hours ago [-]
rapind 4 hours ago [-]
Both (and memory) are a problem. Build sizes is definitely more easily solved just by throwing more disk at it though (unless you are using a hard constrained mac...).
estebank 3 hours ago [-]
A partial solution that avoids you spending money is to stick `debuginfo = "line-tables-only"` in your `Cargo.toml`.
epage 1 hours ago [-]
This will be the default for the `dev` profile in an upcoming release now that the `debug` profile has been split out.
colechristensen 2 hours ago [-]
A good 4TB SSD was $1000 the last time I checked. The "throw more resources at it" attitude makes all but very top tier equipment kinda useless for many cases.
I had to abandon several projects until I bought a significantly beefier computer because of disk space, which is ridiculous. A lot of it was rust target directories taking up tens of gigabytes.
yhjc2692 2 hours ago [-]
[dead]
d0mine 3 hours ago [-]
~Zero build time Python vs 20 min for Rust web app
maccard 1 hours ago [-]
Go is pretty close to 0 as well IME.
Funnily enough, last week I was working on parsing some json. I wrote a little script in python, tested it and then ran it over the main dataset. It took so long that I rewrote it in C# before the python script had finished!
Filligree 3 hours ago [-]
It's more than zero, but 15 seconds would be a great deal more realistic for an incremental build.
colechristensen 2 hours ago [-]
I have a whole section in my global AGENTS.md about how python sucks to influence agents to not use it for anything performance sensitive.
My favorite improvement example was something a bit of a slog was taking 20 minutes in python, I told the agent to rewrite it in rust and the result was 300,000 times faster... 20 minutes to ones of milliseconds. Obviously not just a python problem but better solutions just seem to fall out of Rust and Python is just slow.
thomashabets2 6 hours ago [-]
It would help, yes. Here's one of my projects, that uses different subdirectories in target/ based on compiler options pre-commit runs:
$ du -hcs target/
190G target/
bitbasher 4 hours ago [-]
I can deal with large builds, what I cant deal with is time. My rust web application takes 20 minutes to build in release mode on a high end developer machine. I can’t build it in ci/cd.
rapind 3 hours ago [-]
Yeah, there are some things I've done to mitigate this, especially for the dev loop. Moving templates out of rust (losing some safety). Splitting the application into vertical slices. Only generating code that's changed. Turning features into crates.
It's been a journey...
panstromek 3 hours ago [-]
20 minut definitely sounds suspicious. For comparison, Rust compiler takes ~10 minutes to build in release mode (in the simple config without all the fancy PGO stuff we run on CI).
Do you have some more info about the codebase, is it public?
simonask 3 hours ago [-]
That sounds like something is very wrong with your setup.
MBCook 3 hours ago [-]
Could you e plain the issue for a non-rustacean?
estebank 2 hours ago [-]
The Rust toolchain by default produces a lot of debug information for each crate being compiled and the language relies heavily on monomorphization (instantiating a different function/type for each combination of generics) which translates to generally having duplicated functionality where the only difference in the object code is the different types. These two things combined, along with large dependency trees and that "features" for conditional compilation cause the same crate to be considered different across different workspaces (meaning the rlibs that were created for one can't be reused for another), means that the target directory for Rust projects can quickly grow. That, + clippy not having stabilized an already implemented process to automatically delete files from the target directory when they are unlikely to be needed again (which can't be 100% accurate, it uses heuristics because a developer could always potentially need an exact rlib from 6 months ago, it is just unlikely) means that you can expect that under the default configuration your target directory ends up being huge after a short period of time.
A lot of those things are in different stages of being fixed. I would personally want the default for generated debug information to be changed. cargo gc will help with running out of disk space. Better cross-project reuse of existing rlibs could be accomplished with some better tracking of optional features that can be unified (think having `serde` with feature `derive` enabled in one project, and having it without it in another: features are supposed to be purely additive, so you could reuse the earlier rlib on the later, but in practice people (ab?)use features in non-additive ways so it isn't straighforward to do something like that by default). Tools like hakari lets you create workspace-unified Cargo.toml to emulate this behavior.
yhjc2692 2 hours ago [-]
Woah, this is great to know. Thanks for explaining!
infogulch 46 minutes ago [-]
I'm curious about polymorphism. Should it be default on for debug builds just to save storage and compile time? How will rust decide whether to enable polymorphism? Will it be possible to provide source-level polymorphism hints to the compiler?
estebank 28 minutes ago [-]
The "hint" you could provide today for polymorphization is to write code like
which is the explicit way of representing the same thing rustc would be doing automatically. The above will create an almost empty `needs_string_like` for each type that it is called with, but a single `actual_logic`. IIRC some optimization passess would completely remove specific instances of `needs_string_like` (like if you call `needs_string_like(String::new())`).
panstromek 7 hours ago [-]
I don't understandy why, but all submissions of this post so far had incorrect title. When I posted the correct one, it still got reassigned the wrong title and I had to edit it (and it didn't allow me to do that yesterday, only today).
tialaramex 6 hours ago [-]
Hacker News has some automatic fixes for title text. Some - perhaps all - of them can walk into false positives where a change that's usually desirable instead ruins the title either because it's a joke and the change spoils the joke or just because English is complicated.
hmokiguess 6 hours ago [-]
Pretty wild to see how different people’s experiences can be within the same industry but under different applications and circumstances, here is someone joyful about the future of a language whereas not long ago we had a Ruby gem maintainer in deep dissatisfaction and frustration with the future of it.
Not implying to compare Rust and Ruby, just mainly observing how these two things came out near each other in the present day.
anonymous908213 3 hours ago [-]
Leadership matters. I don't suppose the Rust leaders have been telling their community to write more open-source code for free with the express purpose of replacing those people with LLMs trained on their work.
hmokiguess 1 hours ago [-]
On this topic, how ironic that the Ruby dude who is getting infamous for doing this is preaching moving to Rust
5 hours ago [-]
jdbloodstone 5 hours ago [-]
[flagged]
vatsachak 4 hours ago [-]
The best way to get a rust job is get a regular job and just write rust
cpursley 3 hours ago [-]
I did this once but with Elixir, and it worked - because I shipped ahead of schedule (way ahead of the other teams portions). Performance and quality met the standards. Sometimes it's better to ask for forgiveness than permission if that means not having to fool with Java.
vatsachak 2 hours ago [-]
Unless you work at a FAANG the team will ask you to make a tool and will probably be fine with a mainstream language.
lolakutty 4 hours ago [-]
Rust is not very relevant anymore when you can write it in C and once in a while run an LLM over it to catch any memory issues...
satvikpendem 4 hours ago [-]
I hope this is satire.
lolakutty 3 hours ago [-]
It is not. Tell me one good reason to deal with the horrible language called rust now that we have mechanisms capable of doing the exact same stuff in a vastly less obnoxious manner....(I am talking about running LLMs over your C code once in a while).
I don't like rust because
1. Verbose Syntax made worse by having to include type system info...
2. Dumb Borrow checker
3. Automagic stuff...
Sharlin 2 hours ago [-]
Thanks for your opinion, we’ll give it all the attention that it deserves.
lolakutty 4 minutes ago [-]
Who gives a fuck.
ikety 4 hours ago [-]
or to save tokens you can have an LLM write a borrow checker to do this for you. Oh wait you're just rebuilding rust...
lolakutty 3 hours ago [-]
The point of writing in C is that I don't have to deal with borrow checker shit when it is too dumb to figure out what I want to do is actually safe.
simonask 3 hours ago [-]
My money is on the opposite.
1 hours ago [-]
Rendered at 20:49:52 GMT+0000 (Coordinated Universal Time) with Vercel.
No kidding. I’ve been waiting for the solver at least half that decade now. Hopefully it and Polonius unblock specialization which has been in purgatory for years.
It's not directly blocked on the solver, but getting the type system into a better shape definitely helps reasoning about the soundness issues involved.
There's a recurring meme here and in other social media about rust being slow to compile, but anyone who's worked with Rust know that target dirs are a much more annoying papercut in practice than the relative speed of the compiler (which isn't appreciably worse than any other toolchain out there for the most common workflows).
One proposal I came across actually suggested breaking up a perfectly fine monolith into a dozen microservices to reduce compile times (at the cost of cumulative CI costs going up).
When the alternative is massively rearchitecting your systems, Zig and Go begin to look really nice by comparison.
Stories like this make me think something is wrong with your setup. Do you have Windows Defender or similar enabled on the build directory?
That isn't "Rust compiles are fast", it's another example of "Rust requires you architect your code a specific way".
Doesn't mean one is better than the other, but to find it odd someone had an experience with slow Rust compiliations and then blame it on their setup is a bit odd.
Most of the Rust ecosystem makes unnecessarily heavy use of compile-time traits and monomorphized generics (aka Go generics or C++ templates). The language syntax encourages it as well. The thing is compile times will NEVER drop to level of Go unless the entire set of players (language, standard library, almost all library developers) actually prioritize dynamic dispatching instead of static dispatching / monomorphization. That's the tradeoff for the performance and RAM usage you gain. Template-heavy C++ also suffers from the same issues for the same reason.
Golang is fast to compile because its interface definitions are runtime/dynamically dispatched (aka `&dyn Trait` in Rust or virtual classes in C++) and it had no generics for a long time forcing types like slices, map and vectors to be magic types.
If you need fast compile times, you need to split your program into multiple binaries or write your own backend ecosystem that almost only uses dynamic dispatching. If your full Cargo dependency tree pulls 50+ crates, you'll not get fast compile times. You need to avoid derive-macros like plague. You need to use non-Cargo build systems or `build.rs` to generate Rust code instead of derive-macros.
Unlike Golang Rust also targets extremely memory constrained devices where monomorphization enables memory savings, extra optimizations and fewer CPU cycles / instructions (e.g. microcontrollers, UEFI/BIOS implementation). It is a system programming language first. With system programming languages you are responsible for these choices as the developer. Rust just happens to have a vivid scene of backend libraries since the language's safety enabled many non-system developers to write correct and performant programs quickly.
I had to abandon several projects until I bought a significantly beefier computer because of disk space, which is ridiculous. A lot of it was rust target directories taking up tens of gigabytes.
Funnily enough, last week I was working on parsing some json. I wrote a little script in python, tested it and then ran it over the main dataset. It took so long that I rewrote it in C# before the python script had finished!
My favorite improvement example was something a bit of a slog was taking 20 minutes in python, I told the agent to rewrite it in rust and the result was 300,000 times faster... 20 minutes to ones of milliseconds. Obviously not just a python problem but better solutions just seem to fall out of Rust and Python is just slow.
It's been a journey...
Do you have some more info about the codebase, is it public?
A lot of those things are in different stages of being fixed. I would personally want the default for generated debug information to be changed. cargo gc will help with running out of disk space. Better cross-project reuse of existing rlibs could be accomplished with some better tracking of optional features that can be unified (think having `serde` with feature `derive` enabled in one project, and having it without it in another: features are supposed to be purely additive, so you could reuse the earlier rlib on the later, but in practice people (ab?)use features in non-additive ways so it isn't straighforward to do something like that by default). Tools like hakari lets you create workspace-unified Cargo.toml to emulate this behavior.
Not implying to compare Rust and Ruby, just mainly observing how these two things came out near each other in the present day.
I don't like rust because
1. Verbose Syntax made worse by having to include type system info... 2. Dumb Borrow checker 3. Automagic stuff...