> 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.
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).
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".
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...).
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.
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.
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.
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.
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).
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.
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...
> 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.
There's some movement on specialization as well: https://goals.rust-lang.org/2026/specialization.html
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.
Smaller target directory size would be such a lifesaver. Hoping the best for you, and Rust!
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).
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".
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...).
A partial solution that avoids you spending money is to stick `debuginfo = "line-tables-only"` in your `Cargo.toml`.
~Zero build time Python vs 20 min for Rust web app
It's more than zero, but 15 seconds would be a great deal more realistic for an incremental build.
It would help, yes. Here's one of my projects, that uses different subdirectories in target/ based on compiler options pre-commit runs:
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.
That sounds like something is very wrong with your setup.
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...
Could you e plain the issue for a non-rustacean?
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.
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.
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).
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.
The best way to get a rust job is get a regular job and just write rust
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...
I hope this is satire.
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...
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...
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.