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.
Anyways, here's some hacker news links to other discussions in case you think I'm exaggerating. You can see some hostility exists even in this forum that is built with a lisp variant and run by a company named after a mathematical concept relevant to functional programming.
https://news.ycombinator.com/item?id=20374782
https://news.ycombinator.com/item?id=502074
https://news.ycombinator.com/item?id=9730277
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.
But does it actually have that impact? Being able to represent language constructs within the language doesn’t seem to have much to do with the textual syntax that humans use to input those constructs. Or perhaps you meant it in the sense that when introducing new constructs for humans to use (and not just generating code programmatically), it’s easier to make their syntax “blend in” with existing syntax if there isn’t much of the latter.
> and maybe it's helping code reading by human brains.
Empirically, I’m not convinced that it’s the case.
Mojo?
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.
> 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://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.
Some of the code also did networking in user space and communicated with other processes by coordinating writes to shared memory.
It’s true that there’s certain system software that you probably can’t write because of the presence of a GC: parts of the operating system, a language runtime, a virtualization toolkit. The category “system software” contains those things but also databases, browsers, and servers.
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.
Alone that fact makes devs that have to deal with what they can afford, to pick other ecosystems that can be usable on their potatoes.
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.
It looks like TinyGo also had to make some compromises to reduce the memory footprint and increase optimizations: https://tinygo.org/docs/concepts/compiler-internals/differen...
> A whole program is compiled in a single step, without intermediate linking. This makes incremental development much slower for large programs but enables far more optimization opportunities. We are actively working on build caching so that at least part of the work does not need to be redone on every compilation.
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.
$ du -hcs target/
190G target/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).
`actix-web` itself should be fine, `sqlx` can be heavy if you use its compile time features, I'd assume `askama` is heavy as well, just based on the description (it generates rust code at compile time).
Otherwise it depends on how the code is structured (e.g. how generic it is, how deep types or complicated futures it creates).
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.
fn needs_string_like(x: Into<String>) {
fn actual_logic(_: String) {}
actual_logic(x.into())
}
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: