Rendered at 14:23:40 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
throwup238 22 hours ago [-]
> 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.
afdbcreid 16 hours ago [-]
More precisely: it wasn't known to be blocked on the new solver (unlike some other features), because nobody dared to touch it until recently... (more seriously, there wasn't enough investment).
KolmogorovComp 16 hours ago [-]
I don't think rust is the future anymore, despite having contributed to its compiler few times and been quite involved for years. It has spread too much and that impact compiles time too much.
I think a newer language, having the boreness of go, the compile speed and maybe comp time of zig and safety of rust will emerge, maybe with lisp syntax.
jazzypants 3 hours ago [-]
Normal people hate Lisp syntax, and reading the code will never stop being important.
isolay 24 minutes ago [-]
Are you saying I’m not normal?
raincole 12 hours ago [-]
> I don't think rust is the future
Yeah because it's the present. Rust is everywhere now.
Buttons840 15 hours ago [-]
What a weird take. At first I though you were going to predict a language with an even more featureful and strict type system.
We don't need the "boreness" and human usability of Go anymore. Fast compile times are still nice though.
Lisp syntax doesn't have much value in the age of AI I think. Lisp seems optimized to make it easy to parse, and also easy to hack on the interpreter. I don't think Lisp was ever meant to optimize human readability. The uniformity and minimalism of Lisp makes it easier to learn the syntax though. -- I don't know, maybe I underestimate the value and flexibility of Lisp syntax.
I think the most valuable features of programming languages now are human readability and type systems that give guarantees humans can rely on. Some of the most exciting code AI has written has been in Lean.
attila-lendvai 7 hours ago [-]
the key impact of simple syntax is in metaprogramming.
secondary impact is structured editing, and maybe it's helping code reading by human brains.
pjmlp 5 hours ago [-]
That already exists, OCaml.
The problem with Rust is lack of alternative implementations, like it happens in OCaml and Haskell, which allow for quick development loops, or going for lunch with an heavily optimised build.
KolmogorovComp 4 hours ago [-]
Ocaml has a GC though, no? That makes it improper for system programming.
pjmlp 3 hours ago [-]
Only for those ideologically against GC in systems programming languages.
> Docker Desktop avoids this problem by forwarding all traffic at user-level via vpnkit, a TCP/IP stack written in OCaml on top of the network protocol libraries of the MirageOS Unikernel project.
I not so versed into that debate so will gladly take input, but seeing how the “stop the world” issue seem to be for games for example, I’m cautious.
pjmlp 2 hours ago [-]
The "stop the world" also affects C code in games, when malloc() is used in a loop, and the C standard library has to do a syscall into kernel space to get a fresh memory block.
Especially relevant anything describing how mmap() and sbrk() are being called.
The matter is not if the language has a GC or not, regardless of the GC algorithm(s) being used, rather what language primitives and standard library features are available to be taken advantage of, when required to do some low level coding.
Here is another set of examples, TinyGo, TamaGo or Oberon for tiny computers.
Well, that implies there's some sort of threshold that it's still reaching for and hasn't yet achieved before it can be considered successful. But it's already everywhere now. Hell, not only is it in the Linux kernel, it's even in Windows (!).
Gigachad 13 hours ago [-]
2026 has really been the year of Rust. The fact that it can run in the browser as well as natively has made it an electron killer.
pjmlp 5 hours ago [-]
The problem with Electron is laziness of certain class of developers, no programming language will fix that.
chamomeal 15 hours ago [-]
A lisp with the type safety of rust. Mmmmmm. Makes me do the homer drool
Really? With AI you can have your cake and eat it too with Rust now.
yhjc2692 23 hours ago [-]
Smaller target directory size would be such a lifesaver. Hoping the best for you, and Rust!
stymaar 21 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 20 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".
simonask 20 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 18 hours 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".
afdbcreid 16 hours ago [-]
> That isn't "Rust compiles are fast"
And neither the original example is "Rust compiles extremely slowly" (it does compile slowly), it's another example of "vibecoded software is of poor quality".
yosefk 17 hours ago [-]
Fair enough but Rust also gives you a mix of safety and efficiency nothing else does
aliasxneo 19 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.
afdbcreid 16 hours ago [-]
It is slow. Nobody would deny that. It also requires work to avoid disastrous compile times, that's also true.
But 15 minutes? Even rustc doesn't take that long (on a powerful computer), and that's a very large program that is compiled at least twice (bootstrapping)! That's just poor engineering, not knowing how to write fast-to-compile Rust code.
yearolinuxdsktp 14 hours ago [-]
You can't compare rustc to a large application. Yes it's a large program, no it's nowhere near as large as Codex CLI. 1420 crates.
I just did a release build of Codex CLI with "lto = false" for codex CLI binary and code mode host only, and it took 75 minutes, of it 1063 seconds for the final rustc of codex bin. Windows Defender off. That's on a 4-core 2021-era Intel laptop with 32GB RAM and a half-TB SSD. And I can't let the build run at default concurrency, because rustc OOMs the machine, so this is with cargo jobs = 4. Regardless, the final rustc call is independent of that and that was 1063s with lto=false. Previous build was 90 minutes with default thinlto for the same CLI build.
How can Codex write fast-to-compile Rust code, do tell?? Do tell!
afdbcreid 14 hours ago [-]
Behavior-wise, it does a lot more than the Codex CLI. The code of Codex is just of extremely poor quality. Just glanced, it looks like it uses at least two different HTTP server libraries (axum and tiny_http)! From quick check, rustc has 44 duplicate transitive dependencies (with different versions) while Codex has 109! And 2 dependencies are duplicated five times (in rustc the most duplicated are only three times)!
> How can Codex write fast-to-compile Rust code, do tell?? Do tell!
Like a human can, I suppose? Avoid extreme usage of generics. Avoid dependencies if not needed. Make sure you synchronize dependency versions to avoid duplicate code. Etc..
afdbcreid 14 hours ago [-]
Also, Linux has (often significantly) faster compile times than Windows (due to filesystem performance, even with Dev Drive).
okanat 18 hours 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.
kbolino 16 hours ago [-]
This is a bit of a tangent, but Go generics aren't monomorphized. Each instantiation is "stenciled" down to its GC shape and then the differences among types with the same shape are handled using a "dictionary" which is kind of like Swift's witness tables or Go's own interface vtables. See this description for details: https://github.com/golang/proposal/blob/master/design/generi...
The typical end result sits somewhere between monomorphization and type erasure in terms of generated code and runtime indirection.
simonask 18 hours ago [-]
Well, me too, and I can confidently tell you I’ve never seen build times in the 10+ minute range (on capable machines).
stymaar 17 hours ago [-]
> it takes over 15 minutes to rebuild trivial changes on a top-shelf CPU
I have no idea how this could possibly be this bad given that I worked full time with Rust from 2015 to 2023 on a $600 Clevo laptop from 2012 and was used to incremental builds in the low double digit seconds for projects ranging between 100k and 600k loc. (From scratch release builds where excruciatingly slow, but these only happened once every rust updates).
afdbcreid 16 hours ago [-]
You only clean the build directory once every Rust update? Unless you use nightly, I don't see how that's feasible. Having a 1TB (and pretty free) disk, I still need to clean regularly (not that commonly, but more than once a release).
xyzzy_plugh 19 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.
iknowstuff 17 hours ago [-]
Maybe the proposal you saw was breaking up into crates, which is Rust's compilation units and can be parallelized. They're not microservices, they're just libraries which still combine to produce a single binary.
yosefk 17 hours ago [-]
Zig dumps core and Go is slower and needs more memory though, and this matters, too. (not that Rust build times are really a price to pay for avoiding these things, it's more a result of not making fast builds a goal from the start)
20 hours ago [-]
rapind 21 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 20 hours ago [-]
A partial solution that avoids you spending money is to stick `debuginfo = "line-tables-only"` in your `Cargo.toml`.
epage 19 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 20 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.
rapind 17 hours ago [-]
Yes it's a problem. Not dismissing it. Just a less expensive problem than CPU or RAM is all I'm saying. It's been a thorn for me too (being on a macbook myself, but now I have a dedicated build box).
RAM prices are insane right now...
yhjc2692 19 hours ago [-]
[dead]
d0mine 21 hours ago [-]
~Zero build time Python vs 20 min for Rust web app
Filligree 20 hours ago [-]
It's more than zero, but 15 seconds would be a great deal more realistic for an incremental build.
maccard 19 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!
d0mine 6 hours ago [-]
Parsing JSON at tens of gigabytes per second… in Python
Nah, that is the usual mistake to call Python libraries to something that is actually implemented in a native compiled language.
stymaar 6 hours ago [-]
Exception it's merely a python binding for Daniel Lemire's Simdjson which is written in C++ (which takes even more time to compile than Rust).
colechristensen 19 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 23 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 21 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.
panstromek 20 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?
bitbasher 15 minutes ago [-]
There's nothing public, but it's a SaaS application written with actix-web, askama and sqlx.
One of the big slow downs comes from a single crate (async-stripe). In retrospect, I should just use reqwest and serde to do everything with Stripe's API manually and not use any crate at all (especially if it cuts the build time in half).
rapind 21 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...
simonask 21 hours ago [-]
That sounds like something is very wrong with your setup.
MBCook 21 hours ago [-]
Could you e plain the issue for a non-rustacean?
estebank 20 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 19 hours ago [-]
Woah, this is great to know. Thanks for explaining!
infogulch 18 hours 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 18 hours 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 17 hours ago [-]
> polymorphism
I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.
The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.
More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.
hmokiguess 23 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 20 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 19 hours ago [-]
On this topic, how ironic that the Ruby dude who is getting infamous for doing this is preaching moving to Rust
pipe01 3 hours ago [-]
It's important to note that DHH has nothing to do with Ruby the language
panstromek 1 days 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 23 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.
23 hours ago [-]
simplesocieties 14 hours ago [-]
What are the problems in async the new trait solver will fix? Looking forward to building more on async Rust so I'm curious
yoshuaw 13 hours ago [-]
Return Type Notation (RTN) I believe is the big one blocked by the new solver. This is the primitive that makes it possible to add bounds to futures returned by async functions. This should look something like: `where <T as Trait>::method(..): Send`.
This is one of two remaining features needed to make Async Functions in Traits (AFITs) practical. Dyn dispatch support being the other missing feature, though that isn't blocked by the new solver.
panstromek 7 hours ago [-]
I was also thinking about Move and Forget traits, which impact cancellation safety. I think those are at least somewhat soft-blocked on the solver, but I'm not sure. Honestly, you're probably much better contact to talk about that, this is out of my wheelhouse.
LoganDark 17 hours ago [-]
Hexcat link is broken and leads to "https://https//hexcat.nl" instead of https://hexcat.nl
panstromek 7 hours ago [-]
thanks, fixed ;)
KolmogorovComp 17 hours ago [-]
I'm wondering about the future of clippy.
archermarks 16 hours ago [-]
A bit out of the loop, what's going on with clippy?
KolmogorovComp 16 hours ago [-]
is it going to be useful in a LLM-driven code-world.
vor_ 14 hours ago [-]
Yes.
shmerl 17 hours ago [-]
Somewhat indirectly related, but is there any progress on implementing persistent caching in rust-analyzer? It would really benefit from faster startup times.
afdbcreid 16 hours ago [-]
(r-a team member here) The progress is in Salsa (the incremental framework we use), not in r-a itself yet. And there is progress but it's not particularly fast, it's also not a priority for the r-a team (though if you want to contribute, you're welcome of course).
shmerl 15 hours ago [-]
You mean progress to make the framework faster itself?
I was asking about something else, i.e. basically saving whatever possible from those expensive computations on disk, so next time it starts, it can spend significantly less time (assuming things didn't change too much). clangd has such feature and it's super helpful.
Or you mean Salsa already supports such persistent caching in some form?
afdbcreid 14 hours ago [-]
I meant, the progress to make Salsa support persistent caching is not advancing particularly fast. It does exist, but is preliminary.
The implication being that you're writing in a language so unsafe that you need to pay for AI data centers to periodically double-check it for you. That isn't the argument in favor of C that you think it is.
lolakutty 10 hours ago [-]
Oh, do you think Rust code bases won't be checked using LLMs?
satvikpendem 22 hours ago [-]
I hope this is satire.
lolakutty 21 hours ago [-]
[dead]
Sharlin 19 hours ago [-]
Thanks for your opinion, we’ll give it all the attention that it deserves.
lolakutty 18 hours ago [-]
[flagged]
esafak 18 hours ago [-]
A C user calling Rust a bad language is a fine example of the pot calling the kettle black.
afdbcreid 16 hours ago [-]
I've never seen a proof that LLMs can fix memory safety in C or C++ like Rust does. I'll believe it when I'll see it.
And I prefer to work with Rust than both anyway. Such advancement (if it will happen) will only make other languages like Zig feasible for me.
ikety 21 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 21 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 20 hours ago [-]
My money is on the opposite.
lolakutty 18 hours ago [-]
[flagged]
19 hours ago [-]
vatsachak 21 hours ago [-]
The best way to get a rust job is get a regular job and just write rust
cpursley 20 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 20 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.
pjmlp 5 hours ago [-]
If working in a team, good luck having those PR accepted though.
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.
I think a newer language, having the boreness of go, the compile speed and maybe comp time of zig and safety of rust will emerge, maybe with lisp syntax.
Yeah because it's the present. Rust is everywhere now.
We don't need the "boreness" and human usability of Go anymore. Fast compile times are still nice though.
Lisp syntax doesn't have much value in the age of AI I think. Lisp seems optimized to make it easy to parse, and also easy to hack on the interpreter. I don't think Lisp was ever meant to optimize human readability. The uniformity and minimalism of Lisp makes it easier to learn the syntax though. -- I don't know, maybe I underestimate the value and flexibility of Lisp syntax.
I think the most valuable features of programming languages now are human readability and type systems that give guarantees humans can rely on. Some of the most exciting code AI has written has been in Lean.
secondary impact is structured editing, and maybe it's helping code reading by human brains.
The problem with Rust is lack of alternative implementations, like it happens in OCaml and Haskell, which allow for quick development loops, or going for lunch with an heavily optimised build.
https://mirage.io
> Docker Desktop avoids this problem by forwarding all traffic at user-level via vpnkit, a TCP/IP stack written in OCaml on top of the network protocol libraries of the MirageOS Unikernel project.
https://www.docker.com/blog/how-docker-desktop-networking-wo...
https://ocaml.github.io/ocamlunix/ocamlunix.pdf
And to go back to the 1980s, more broadly than only OCaml,
"Eric Bier Demonstrates Cedar"
https://www.youtube.com/watch?v=z_dt7NG38V4
Or if you prefer bare metal stuff, with hard real time requirements, and somehow more mainstream language,
> Aonix PERC Ultra Virtual Machine supports Lockheed Martin's Java components in Aegis Weapon System aboard guided missile cruiser USS Bunker Hill
https://www.militaryaerospace.com/computers/article/16724324...
> Thales Air Systems Selects Aonix PERC Ultra For Java Execution on Ground Radar Systems
https://vita.militaryembedded.com/5922-thales-execution-grou...
Nowadays Aonix has been integrated into PTC.
https://www.ptc.com/en/products/developer-tools/perc
https://sourceware.org/glibc/wiki/MallocInternals
Especially relevant anything describing how mmap() and sbrk() are being called.
The matter is not if the language has a GC or not, regardless of the GC algorithm(s) being used, rather what language primitives and standard library features are available to be taken advantage of, when required to do some low level coding.
Here is another set of examples, TinyGo, TamaGo or Oberon for tiny computers.
https://www.astrobe.com
https://tinygo.org/docs/reference/microcontrollers/boards
https://reversec.com/usb-armory
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).
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".
And neither the original example is "Rust compiles extremely slowly" (it does compile slowly), it's another example of "vibecoded software is of poor quality".
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.
But 15 minutes? Even rustc doesn't take that long (on a powerful computer), and that's a very large program that is compiled at least twice (bootstrapping)! That's just poor engineering, not knowing how to write fast-to-compile Rust code.
I just did a release build of Codex CLI with "lto = false" for codex CLI binary and code mode host only, and it took 75 minutes, of it 1063 seconds for the final rustc of codex bin. Windows Defender off. That's on a 4-core 2021-era Intel laptop with 32GB RAM and a half-TB SSD. And I can't let the build run at default concurrency, because rustc OOMs the machine, so this is with cargo jobs = 4. Regardless, the final rustc call is independent of that and that was 1063s with lto=false. Previous build was 90 minutes with default thinlto for the same CLI build.
How can Codex write fast-to-compile Rust code, do tell?? Do tell!
> How can Codex write fast-to-compile Rust code, do tell?? Do tell!
Like a human can, I suppose? Avoid extreme usage of generics. Avoid dependencies if not needed. Make sure you synchronize dependency versions to avoid duplicate code. Etc..
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.
The typical end result sits somewhere between monomorphization and type erasure in terms of generated code and runtime indirection.
I have no idea how this could possibly be this bad given that I worked full time with Rust from 2015 to 2023 on a $600 Clevo laptop from 2012 and was used to incremental builds in the low double digit seconds for projects ranging between 100k and 600k loc. (From scratch release builds where excruciatingly slow, but these only happened once every rust updates).
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.
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.
RAM prices are insane right now...
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!
https://lemire.me/blog/2026/10/12/parsing-json-at-tens-of-gi...
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.
Do you have some more info about the codebase, is it public?
One of the big slow downs comes from a single crate (async-stripe). In retrospect, I should just use reqwest and serde to do everything with Stripe's API manually and not use any crate at all (especially if it cuts the build time in half).
It's been a journey...
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.
I assume you ask about polymorphization, which is a term used to refer to a specific optimization mentioned in the blog post.
The base version which Rust wants the most makes sense to enable by default for all builds, because it's purely just removing duplicate work - this is for cases like Vec<u64> and Vec<i64>, where we currently emit code for each one separately, even though it's pretty much the same for both.
More general version will make sense for debug builds or in some special cases, like when optimizing for size. I believe people also want to experiment with it for some interop use cases (and for that, it'd be useful to have source level annotation). I think it's too early to tell how all of this is going to look like, though.
Not implying to compare Rust and Ruby, just mainly observing how these two things came out near each other in the present day.
This is one of two remaining features needed to make Async Functions in Traits (AFITs) practical. Dyn dispatch support being the other missing feature, though that isn't blocked by the new solver.
I was asking about something else, i.e. basically saving whatever possible from those expensive computations on disk, so next time it starts, it can spend significantly less time (assuming things didn't change too much). clangd has such feature and it's super helpful.
Or you mean Salsa already supports such persistent caching in some form?
UPDATE:
Found some pointers if anyone is interested:
* https://github.com/salsa-rs/salsa/issues/10
* https://hackmd.io/@ibraheemdev/S17Bxowwxg
And I prefer to work with Rust than both anyway. Such advancement (if it will happen) will only make other languages like Zig feasible for me.