‹ BackHN Continuity

Thread

How to speed up the Rust compiler in September 2026

279 points · 171 comments · trickypr

Loading the complete thread in the background. This saved snapshot is available now. Refresh

  1. torutofu · · focus · HN ↗
    Incremental seems to keep winning the easy wins, so the interesting part is whether the remaining compile-time still lives in the same places as last year.
  2. Citrusoff · · focus · HN ↗

    [dead]

    1. embedding-shape · · focus · HN ↗
      [delayed]
      1. dev_hugepages · · focus · HN ↗
        This isn't a human you are asking your question to.
        1. pjmlp · · focus · HN ↗
          A regular day at the job nowadays.
  3. Surac · · focus · HN ↗
    Why is the compiler slow in the first place? I have no rust knowledge, how slow us slow, lets say in comparison to a c compiler?

    What is the performance killer?

    1. JMKH42 · · focus · HN ↗
      Its similar to C++ compilers, there is no one reason. It is a language that tries to optimize a lot, its a big language, it does safety checks, it uses llvm which is a bit slow, its a language that makes use of generics which generate extra code etc etc.
      1. pjmlp · · focus · HN ↗
        C++ compilers have it better, despite the fame, because on the C++ world, people like their binary libraries (not compiling the world from scratch on each git clone), there better support for incremental compilation, and incremental linking, there are interpreters and hot code reload tooling available.
        1. panstromek · · focus · HN ↗
          > there better support for incremental compilation

          What do you mean by this?

          1. pjmlp · · focus · HN ↗
            Some C++ compilers and linkers have better support for incremental compilation and linking, and do it more fine grained than Rust, e.g. VC++.

            Some tooling ideas go all the way back to when C++ vendors started adopting ideas from Smalltalk and Lisp, e.g. Energize C++ or Visual Age for C++ v4.

            Or build systems like ClearMake from ClearCase, where the object files and binary libraries are shared across everyone on the cluster with the same views (ClearMake speak for what files/branches are selected).

    2. ModernMech · · focus · HN ↗
      It's doing static analysis that many other languages don't do at compile time.
      1. dralley · · focus · HN ↗
        This is not actually the main reason, most of the time.

        Generics/monomorphization and how iterators work results in a lot of compiler bytecode that has to be churned through. More bytecode = longer compilation. It increases the size of the (debug) binaries, the debuginfo in general, causes performance issues with debug binaries in some situations unless you bump the optimization level, causes more IO, etc.

        1. ModernMech · · focus · HN ↗
          Okay but if you don't use generics and monomerization, then what explains it?
          1. dralley · · focus · HN ↗
            It's unlikely that many people are using Rust without using Option<T> or Result<T, U> a fair bit. Idiomatic Rust fundamentally uses a lot of generics. And a basic for loop expands into quite a large Iterator trait implementation.
            1. ModernMech · · focus · HN ↗
              Other languages support generics, monomorphization, and iterators, but they're not as slow as Rust to compile, what's the reason for that?
              1. moritzruth · · focus · HN ↗
                AFAIK it's because of trait solving. And also not every language does monomorphization.
                1. kibwen · · focus · HN ↗
                  Trait solving isn't a bottleneck for Rust compilation unless you're doing some extremely cursed things like trying to implement Doom in the type system. At the end of the day it's still mostly that Rust just generates a ton of IR for LLVM to chew on (because of monomorphization), then LLVM takes a while to process all of it (because LLVM is designed primarily to produce high-performance code, often resulting in reasonable tradeoffs against compilation speed), and then the linker takes a while to connect it all together. With a more radical vertically-integrated model where Rust controls the linker you could do in-place linking and nearly completely skip the final step (at least for debug builds), but that's a big change compared to the classic C-style build model.
              2. tialaramex · · focus · HN ↗
                It's likely easier to answer for specific languages

                All three of those words can mean "just like Rust" but equally "Not at all like Rust" for different languages.

                Two examples to contrast: In C++ the iterators are basically a pointer analog (in some cases they're just literally pointers) and that's a very difference "feature" but it's still definitely iterators. In Ginger Bill's Odin, the iterators are a function, possibly generic, which returns a pair, the next item and a boolean telling you whether the iterator was exhausted.

              3. gf000 · · focus · HN ↗
                Zig has their own backend, monomorphization is afaik slow because LLVM itself.

                On top the borrow checker and other features are non-existent in these languages.

                1. pjmlp · · focus · HN ↗
                  See ML language family.
    3. thevinter · · focus · HN ↗
      First of all, the fact that the article talks about "speeding up" the rust compiler doesn't automatically mean that the compiler is "slow"[0].

      Now, is rustc slower than e.g. clang? by how much? why?

      Those are different (and complicated) questions. It really depends on what you're compiling, but I'd say rustc can be 1-5x slower (maybe more at times?).

      The reasons are many and varied, but in general rust compilation is slower because the compiler is doing way more things compared to C (monomorphization, complex trait resolution + type inference, borrow checker..)

      [0]: Also I'd argue that "slow" without a concrete point of reference is a meaningless term in this context.

      1. Joker_vD · · focus · HN ↗
        > the fact that the article talks about "speeding up" the rust compiler doesn't automatically mean that the compiler is "slow"

        Well, if it weren't "slow" for some definition of "slow", nobody would bother speeding it up, would they?

        1. bryanlarsen · · focus · HN ↗
          The go compiler is considered fast, yet Google spends effort speeding up the go compiler. Not to the same extent, but Google has a lot of go code, so it does make a difference.
    4. jerf · · focus · HN ↗
      Doing stuff isn't free. For instance, Go compiles relatively quickly for a modern language, but the biggest reason for that is that it does less stuff than most compilers... less optimization, less checking, and some stuff built into the language to avoid some of the problems with having to read lots of headers just to compile a file and other ways of doing less stuff, but mostly the key is it does less stuff, in both the good and bad senses of that.

      If you want something like Rust that offers guarantees and checks and cross-checks by the boatload, it adds up. Macros, monomorphization, implicit code generation with traits and all those other things add up too. And you can't always get O(n) or O(n log n) code to implement those checks. Maybe it can be sped up and maybe there's tricks here or there, but at the Pareto frontier, a language that has more checks will be slower to compile than one that has fewer.

      And that's not a bad thing or a deficit in Rust, it's just the nature of the beast.

      1. ch4s3 · · focus · HN ↗
        Yeah doing optimizations in a compiler on things like loops, addition, or string layouts is never free.
        1. eikenberry · · focus · HN ↗
          Optimizations not needed in development builds would be free if they were skipped.
      2. ModernMech · · focus · HN ↗
        And since you bring up Go and contrast the compile time with Rust, it&#x27;s been experienced at Google (and also Volvo and other places) that Rust and Go teams are as productive whereas C++ is less than half as productive: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?t=27012&amp;v=6mZRWFQRvmw&amp;feature=youtu.be" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?t=27012&amp;v=6mZRWFQRvmw&amp;feature=...

        So the focus on Rust compile time is misplaced. It&#x27;s not a big deal in terms of overall productivity.

        1. gpm · · focus · HN ↗
          I don&#x27;t think that follows - just that compile times aren&#x27;t the only thing that matters. Maybe rust could be twice as productive as go if compile times went to zero for instance (or maybe not - just disputing that the evidence proves the claim here).
          1. ModernMech · · focus · HN ↗
            But it can&#x27;t go to zero, that was the point -- at some level you have to pay for what you get. I&#x27;m not saying the compile times couldn&#x27;t be better, but Rust can&#x27;t be Go in terms of compile times if it wants to offer the guarantees and options it does. Meanwhile if Go wants to offer more options and stronger guarantees, it won&#x27;t be able to preserve the short compile times everyone points to.
            1. vlovich123 · · focus · HN ↗
              The Cranelift backend is extremely fast. Most of the slowness is all the crazy optimizations that LLVM does + other things (generating debug info etc).
              1. estebank · · focus · HN ↗
                For symbol heavy projects, linking is a surprising bottleneck.

                Some ideas to speed up compilation by not evaluating items that are not used might pan out significantly for big crates in your dep tree (that behavior might never be stable because that would allow items with compile errors in a crate that would still let your application compile, which is against the Rust approach). The same work to do that would also allow overlapping of crate evaluation between different rustc instances called by cargo, as it would require partial evaluation of crates (to do name res only and gather the symbols needed from its deps).

                I know people are working on a bunch of different strategies to improve both first and incremental compile times, and I&#x27;m looking forward to the fruit of their labor.

                Compile times are rarely the bottleneck for me, but that doesn&#x27;t mean I won&#x27;t welcome any improvements on that front.

                1. nicoburns · · focus · HN ↗
                  &gt; For symbol heavy projects, linking is a surprising bottleneck.

                  Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.

                  &gt; Another thing is that stable rust doesn&#x27;t treat macros as idempotent

                  This seems absolutely insane to me given how pervasive macros are in Rust (I wonder how much of incremental compilation time is just repeated serde derives?). Obviously we can&#x27;t just blindly treat all macros as idempotent, but an opt-in attribute on a macros that pinky-promises that it is seems like it ought to be pretty easy to implement?

                  Maybe somebody&#x27;s looked into it and it doesn&#x27;t help much? But I&#x27;ve heard (unverified) rumours of the opposite.

                  1. estebank · · focus · HN ↗
                    &gt; Is that still true with modern linkers like `wild`? Seems like it can link Chromium in 1-2s.

                    Wild improves things significantly, but it really depends on the kind of project. For some a third of the time can be linking. And not everyone configures their environment to use a different linker. Another thing that can easily improve performance is changing the global allocator, but I&#x27;ve seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the &quot;default&quot;.

                    I fully expect that if wild delivers an effective incremental linking architecture, then rustc will be able to produce the patches directly (instead of wild having to produce patches from two versions of the object files), which would mean both that rustc is producing less LLVM bytecode and that wild gets to do what it (will) do best and make linking as fast as mechanically possible.

                    &gt; This seems absolutely insane to me given how pervasive macros are in Rust

                    There was some work done on this front, but I haven&#x27;t kept up to date on the current status of that. There was a PR showing promise <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;129102" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;129102 (later landed as <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;145354" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;145354, 10% on a specific serde-heavy crate, reports of 32% improvements in the original PR). The tracking issue doesn&#x27;t have any updates <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;151364" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;issues&#x2F;151364, but you can try out nightly with -Zcache-proc-macros to see what the effect could be on your projects.

                    Part of the problem I see is that crates will have to opt-in (and we might be able to change the default over an edition boundary) to get the perf benefit, and it might require a granularity lower than &quot;a crate&quot; (which would complicate implementation). I haven&#x27;t seen additional discussions around these design considerations (needed to stabilize), which will need to happen before people can see progress.

                    Sadly, Rust is, like many open source projects, a show-up-o-cracy: you need a motivated (group of?) individual(s) to deliver a feature to fruition, and if the person driving a feature is fine with using nightly for their purposes, and only needs a subset of a feature, they will drive the feature to that state (lets say 80% completion), and then the feature will linger (until someone else with enough motivation to see the other 80% through shows up). This is exacerbated because the project is unwilling to have 80% solutions on stable unless the state is very clearly not going to preclude other future work, or the path to completion is 100% visible (but if that were the case, then it would have been completed already). So we end up with situations like the Allocator APIs.

                    1. nicoburns · · focus · HN ↗
                      (I did a quick test, and I&#x27;m seeing between 15-20% for <a href="https:&#x2F;&#x2F;github.com&#x2F;servo&#x2F;stylo" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;servo&#x2F;stylo which is a macro-heavy crate. I guess it only matter for crates you&#x27;re actually editing though, macro will already be cached as part of &quot;entire crate is unchanged&quot;)

                      &gt; Another thing that can easily improve performance is changing the global allocator, but I&#x27;ve seen teams that measured 10% perf improvements in their own metrics decide against going with anything other than the &quot;default&quot;.

                      Yeah, although I think there&#x27;s more of a trade-off there. Alternative allocators can add significant amounts of compile time. Whereas, modulo maturity, I think a faster linker is more of a pure win. I would imagine we will make wild the default linker at some point if development continues on the trajectory it seems to be on.

              2. dicytea · · focus · HN ↗
                Cranelift&#x27;s biggest blocker for me is that it completely breaks debuggers:

                <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rustc_codegen_cranelift&#x2F;issues&#x2F;166" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rustc_codegen_cranelift&#x2F;issues&#x2F;...

                1. dabinat · · focus · HN ↗
                  I’m not sure if Cranelift support will ever become stable. It’s really complex, it has tradeoffs like you mentioned, and it requires its own backend to be maintained. TPDE looks like something that could more realistically be stabilized as it just slots into the existing LLVM support.
      3. jchw · · focus · HN ↗
        Rust wants badly to have its cake and eat it too. I get it, but it&#x27;s not the sensibilities I have. The rustc compiler, if it really can achieve everything all at once, will be a beast like none other, making C++ compilers look simple by comparison.

        I&#x27;d love something halfway. Go is maybe a bit radical in some regards, but also, with the news of the new SIMD package for Go, it has occured to me just how little I missed having things like, say, autovectorization.

        1. oscillonoscope · · focus · HN ↗
          The middle ground is pretty much nim.
      4. pjmlp · · focus · HN ↗
        Nah, the only reason is lack of tooling.

        Instead of Go, you could have reached out to complex languages with fast compilation times like D, OCaml, Haskell, Ada, Delphi, C++.

        All of them have alternative implementations with fast compilation times.

        D, use dmd for fast development workflows, gdc or ldc for the ultimate performance at the expense of compilation times.

        OCaml, use the REPL or bytecode interpreter for fast development times, the full blow compiler for ultimate performance.

        Haskell, use the REPL, GHCi for the fast development cycles, GHC for the release build.

        Ada and Delphi, have had fast implementations since forever, although Ada&#x2F;SPARK is indeed somehow expensive.

        C++, yes it isn&#x27;t a mistake. Use Live++, VS hot reload, coupled with binary libraries, or a REPL like CINT (nee ROOT), binary libraries for dependencies, incremental compilation and incremental linking for the development workflow.

        The problem with Rust isn&#x27;t the language itself, rather the ecosystem currently lacking such kind of options being available.

        1. Shorel · · focus · HN ↗
          Dlang is my weapon of choice and I prefer it to rust.
        2. [deleted] · · focus · HN ↗

          [deleted]

        3. slopinthebag · · focus · HN ↗
          including c++ with all of those qualifiers would be like me saying rust is fast with sccache, subsecond, cranelift, and making every single module a separate crate.
          1. pjmlp · · focus · HN ↗
            The difference being the adoption culture across the ecosystem.

            C++ game engines also don&#x27;t need Bevy like tutorials, because most studios aren&#x27;t compiling them from scratch, and tools like Live++ or VC++ hot reload are relatively easy to use.

            1. slopinthebag · · focus · HN ↗
              unreal engine is compiled from scratch (depending on your definition of &quot;from scratch&quot;) and has notoriously long compile times. heck you have to recompile the editor to make certain gameplay code changes. and it&#x27;s by far the most popular AAA game engine on the planet. if it was so easy to fix with your suggestions they would have done it already.

              but hey, just add subsecond and switch to cranelift. problem solved :)

              1. pjmlp · · focus · HN ↗
                Unreal Engine has an installer, and they have done my suggestions, as they are the main customers of Live++ [0], advocates of tooling like Blueprints and now Verse for doing full games.

                Many studios have delivered games with little to no changes to the underlying C++ code.

                [0] - <a href="https:&#x2F;&#x2F;dev.epicgames.com&#x2F;documentation&#x2F;unreal-engine&#x2F;using-live-coding-to-recompile-unreal-engine-applications-at-runtime" rel="nofollow">https:&#x2F;&#x2F;dev.epicgames.com&#x2F;documentation&#x2F;unreal-engine&#x2F;using-...

                1. slopinthebag · · focus · HN ↗
                  so... c++ compile times are fast, because you can simply not compile c++ and instead use blueprints? seems odd since we&#x27;re talking about c++&#x2F;rust compile times. turns out you can make rust compile times infinitely faster by not compiling it too...

                  but when you do have to compile c++, it can be real slow. maybe not as slow as rust, but it&#x27;s not in the same league as eg. go, c#, zig, etc.

                  ue5&#x27;s hot reload is by no means perfect either - many gameplay code changes require recompiling the editor. exposing c++ properties on a blueprint? recompile. modify a constructor? recompile. changing parameters, return types, or adding&#x2F;removing UFUNCTION or UPROPERTY macros? recompile. you can simply search the web to read the experiences of thousands of ue devs complaining about slow compile times and workflows. it&#x27;s the same with unity btw, search &quot;reloading domain unity&quot;.

                  also verse is not in unreal engine. no studio is using verse for ue games. not sure why you threw that in.

                  i get you love c++ and dislike rust, but you aren&#x27;t really making a good case for c++ when you group it in with other languages that have fast compile times ootb, make arguments that involve not using c++ (like blueprints, lol), and rely on brittle third-party hot-reloading solutions.

                  1. pjmlp · · focus · HN ↗
                    I threw that in, because if you knew Unreal Engine, you would be aware of the roadmap for Unreal 6.

                    No one is saying that C++ compile times are anywhere close to Delphi or D, although they are much better when using modules actually.

                    Rather that C++ ecosystem has a developer culture and tools, that makes compiling from scratch and pure distribution of source code for what is a compiled language, something rare, thus despite its slowness, the average impact is less felt than on Rust projects.

                    1. slopinthebag · · focus · HN ↗
                      the roadmap for late 2027 for an experimental release? where studios will still be using C++ for gameplay code?

                      modules? you mean the thing where 2&#x2F;3 major compilers still only have partial support for? how many major c++ projects are using modules?

                      i get it, you hate rust.

                      1. pjmlp · · focus · HN ↗
                        C++ gameplay code doesn&#x27;t require a full engine build for the most part.

                        Office has been using C++ modules for a while now, I think they are major enough.

                        Nah, I hate lack of tooling, you missed my other examples from languages in the ML family.

    5. pornel · · focus · HN ↗
      Zero-cost abstractions aren&#x27;t zero cost in compilation time. High-level abstractions translate to a lot of boilerplate that the compiler has to optimize out.

      In unoptimized builds often the linker is the bottleneck. Rust&#x2F;Cargo can parallelize most of the build, generating tons of code and debug info, but then the poor linker has to consume all of it at once. The object&#x2F;exe formats were designed in ancient times, so they&#x27;re hard to build incrementally or in parallel (some linkers are trying).

      1. sigbottle · · focus · HN ↗
        Is there any experimentation with new ABIs? I mean certain linker flags like --f-lto literally hijack the linker protocol to dump an AST into the backend.

        At least for the fully static binary part of rust, there should be some optimizations there w.r.t. compilation. Sure you&#x27;re not going to interface with shared libraries well but maybe a small experimental feature for fully owned projects? Idk.

        1. pornel · · focus · HN ↗
          Rust already uses MIR-based libraries for LTO, and uses thinLTO by default.

          ABIs won&#x27;t help automatically. The overhead comes mainly from generics and macros. Monomorphic generics and AST macros are impossible to express in an ABI. Turning them into polymorphic usually wouldn&#x27;t remove the many abstraction layers that need to be peeled off, and only make them cost at runtime too.

          So far MIR optimizations were helpful. Rust can simplify high-level MIR quicker than LLVM can simplify the same code after it&#x27;s been lowered to lots of low-level instructions.

    6. kreco · · focus · HN ↗
      Not sure why you are being downvoted here.
    7. weinzierl · · focus · HN ↗
      I once heard (and don&#x27;t know if it&#x27;s still true) that the biggest compile-time sinks are macro expansion and codegen.

      Both are kind of outside the Rust compiler&#x27;s influence. Macros can be almost arbitrarily complex: you pay for what you order. Codegen is LLVM, and that&#x27;s a fixed choice. You can use Cranelift to get around it, but then you pay elsewhere.

      Regardless, it&#x27;s nice to see performance improvements in the compiler, even if you have to cooperate to benefit from them (e.g. by keeping your macros light).

    8. senderista · · focus · HN ↗
      Ultimately it&#x27;s the fact that compile time was not a first-class consideration during the design of Rust&#x27;s important features. There&#x27;s only so much you can do to mitigate the consequences.
      1. kibwen · · focus · HN ↗
        Compilation times were a consideration, but they were a subservient consideration to the prime considerations of 1) being as memory-safe as GC&#x27;d languages, 2) exploring the limits of statically-guaranteed thread safety, and 3) being as fast and memory-efficient as C and C++. If Rust had been willing to compromise on those goals and instead had just, for example, used a virtual machine with pervasive garbage collection and been designed for dynamically-dispatched generics then you&#x27;d get a lot of compilation time reductions for free, but the world didn&#x27;t need another Java, it needed a more secure systems language to stand up against C++ where every previous challenger had failed.
        1. applfanboysbgon · · focus · HN ↗
          No, Rust is not at the paretto frontier for your mentioned 1, 2, 3 and also 4 compilation speed. It could have all of those things and also just have faster compilation. Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language&#x27;s development time. Arguably I think that is the single worst trait you can optimize for in language development, because by saving a little time developing the language you cost humanity, let&#x27;s say hundreds of millions of hours of development time downstream from you, with millions of users being less productive.
          1. kibwen · · focus · HN ↗
            &gt; It could have all of those things and also just have faster compilation.

            Rust was originally a research language. It wasn&#x27;t even clear that their primary three goals--&quot;safe, concurrent, fast&quot;--were simultaneously achievable to their desired degree. That it turned out to be possible was one of the most surprising and impactful results in the history of language design; even the early formulations of Rust assumed that both a garbage collector and a green thread runtime would be necessary, neither of which turned out to be true. That Rust could have faster compilation is both true and vacuous; there&#x27;s always more optimizations to be eked out. The main question is whether or not significant performance wins could be gained by having made different, fundamentally-backwards-incompatible design decisions, and the answer is no, not really. Performance-related features like referentially-transparent procmacros can easily be made the default over an edition, and polymorphization can be implemented via an alloca-based virtual-dispatch ABI vis-a-vis Swift.

            &gt; Rust devs have talked about how they have some regrets about not optimizing more for compilation, but instead another attribute got optimized in terms of paretto efficiency - the language&#x27;s development time.

            No, the early Rust devs got this right. They were in fact highly incentivized to care about compiler performance, because rustc has been bootstrapped since 2011, making them the most serious users of the language in earnest (with the second-most serious users being the Servo devs one cubicle over). Rust spent years getting its basic design nailed down, then it did the hardest thing for any language: understanding the importance of shipping, resisting the urge to endlessly pursue perfection, and future-proofing what they could. Without shipping a useful language you can&#x27;t get in the hands of users, and without getting in the hands of users you can&#x27;t discover your most important flaws in practice. And because Rust shipped in 2015, it had ten years to hammer itself into shape to weather the agentic era; it could have easily still been on version 0.113 by now, puttering around in an ivory tower with no commitment to stability and no real users to give feedback.

        2. pjmlp · · focus · HN ↗
          While it has found success on mainstream, it basically proven Cyclone ideas were right, and now we have other languages adopting similar ideas into their type systems, which helps closing the gap with 3).

          Since the 2000&#x27;s we have been on the wrong path, many developers kept reaching for C and C++, not because they needed the actual features of a systems programming language, rather they didn&#x27;t knew anything else that would ahead of time compile to native code, or even if they did the mindshare wasn&#x27;t relevant for them.

          Now thankfully we are circling back to how it should have been all along.

          However all of this might be meaningless in the age of AI driven programming, where developers have no clue if the agent is driving automatic or stick, while delivering on the Markdown file plan.

    9. jiehong · · focus · HN ↗
      Contrast this with zig, where compiler performance is so important that it has influenced the language design.

      Zig and Go are similar on that front.

      1. pjmlp · · focus · HN ↗
        As did NEWP, Pascal, Mesa, Modula-2, Cedar, Apple Pascal, Turbo Pascal, Delphi, Oberon(-2), Component Pascal, Active Oberon, Eiffel, OCaml, D,...

        This is really nothing new, the visibility problem is that many developers only know C and C++ as how long compilers take.

  4. adamch · · focus · HN ↗
    I&#x27;m glad to see the donations from big companies to open source maintainers are making measurable difference to the Rust experience. Telling these companies that their employees spend 5% less time waiting for compilation might motivate future investment in people like Nick and the others mentioned.
  5. bryanlarsen · · focus · HN ↗
    Really nice to see that the 5% speedup is despite making the borrow checker better, validating code that previously would have tripped it up.

    Sometimes we really can have our cake and eat it too.

  6. maherbeg · · focus · HN ↗
    I&#x27;m surprised the OpenAI Codex team doesn&#x27;t donate like 10B tokens or something to the Rust team for performance
    1. OG_BME · · focus · HN ↗
      LLM written code is disallowed by the rust project policy

      <a href="https:&#x2F;&#x2F;forge.rust-lang.org&#x2F;policies&#x2F;llm-usage.html" rel="nofollow">https:&#x2F;&#x2F;forge.rust-lang.org&#x2F;policies&#x2F;llm-usage.html

      1. poly2it · · focus · HN ↗
        It doesn&#x27;t seem to be quite that simple?

        <a href="https:&#x2F;&#x2F;forge.rust-lang.org&#x2F;policies&#x2F;llm-usage.html#experiment-llm-created-code-changes-intended-for-review" rel="nofollow">https:&#x2F;&#x2F;forge.rust-lang.org&#x2F;policies&#x2F;llm-usage.html#experime...

      2. sigmar · · focus · HN ↗
        LLMs are useful in engineering even if the PRs don&#x27;t include LLM-written code.

        &gt;I’m still writing all my own code and text, because (a) that’s paramount, and (b) the project policy requires it, but I had useful LLM analysis assistance on several of the PRs mentioned in this post.

        from the article

    2. echelon · · focus · HN ↗
      This is one of the most important objectives in software today.

      Rust is the best language to serialize agentic LLM output to. It&#x27;s native, well constructed, low-defect due to design. It&#x27;s also easy for humans to read and debug if necessary.

      The biggest problem with Rust is the compile times. The cycle has to get faster. And we need to start thinking about making the artifact cache non-blocking so multiple agents can work simultaneously - that&#x27;ll be a big task, but essential if we want to speed up work on one machine rather than spinning up clusters of agent sandboxes (the alternative, perhaps superior solution).

    3. Aurornis · · focus · HN ↗
      OpenAI is a Rust Foundation platinum level donor. They gave straight cash which can go toward paying maintainers, which is better IMO. This actually made a lot of people angry because they saw it as a risk of OpenAI gaining influence or something. Can&#x27;t make everyone happy.

      OpenAI also hands out free subscriptions to open source maintainers: <a href="https:&#x2F;&#x2F;developers.openai.com&#x2F;community&#x2F;codex-for-oss" rel="nofollow">https:&#x2F;&#x2F;developers.openai.com&#x2F;community&#x2F;codex-for-oss They&#x27;re time limited for now, but they&#x27;ve been pretty generous about who gets them. Anyone who can show Rust contributions would have been able to get one before.

      1. rirze · · focus · HN ↗
        I tend to disregard anyone who complains about foundational open source being funded like this. As long as the donor doesn&#x27;t have dictatorial control over the product, why obsess over this?
        1. jodrellblank · · focus · HN ↗
          Because not having dictatorial control doesn&#x27;t protect anyone from anything; politicians take &#x27;donations&#x27; (bribes) and then argue or enact laws for what the donor wants, no dictating involved.

          Or in software terms, BigCorp sponsors you to develop an open source tool fulltime. If you make the tool more useful for them while making it more complex or worse or ignoring things for others, they might fund you next year as well. If you don&#x27;t, they might stop and you need to get a normal job instead. What are you incentivised to do in this situation?

          1. tancop · · focus · HN ↗
            There&#x27;s definitely a cost in terms of features BigCo doesn&#x27;t need that get deprioritized. But that work still gets done if other people need it, it&#x27;s just slower, and I don&#x27;t think you could ever pull off making things worse on purpose in a big community run project like Rust.

            The only times this actually happened are C++ and CORBA as far as I remember. Both of them were bureaucratic design by committee efforts from the start, the people doing it weren&#x27;t users but implementors looking to stop competition, and it all happened before the open source era.

            1. pjmlp · · focus · HN ↗
              Missing C, OpenGL, Vulkan, OpenCL, HTML 4 onwards, CSS, IP6, and so much more committe driven standards.
      2. maherbeg · · focus · HN ↗
        That&#x27;s awesome
      3. silverwind · · focus · HN ↗
        Can&#x27;t confirm this &quot;pretty generous&quot;, many people with lots of contributions to popular projects got any from OpenAI, not even a response to their request.
    4. nicoburns · · focus · HN ↗
      If you have fast enough hardware then Rust compile times are already not that big of a deal.
    5. godwinson__4-8 · · focus · HN ↗
      Both OpenAI and Anthropic have robust programs for free tokens that you can apply to if you are a significant enough oss maintainer.

      What you suggest may thus be more or less already happening.

  7. hnp9j9qtda · · focus · HN ↗
    Biggest win for me was splitting one fat crate into three, parallelism got real.
    1. clarus · · focus · HN ↗
      Yes this seems like the main way to go. With dependency injection using &quot;dyn&quot; traits on top of that, it seems that this mostly solves the compilation issues with Rust. It might be better for tests and agents to split code in small chunks too.
    2. rapind · · focus · HN ↗
      I am experimenting with this in my project right now. I haven&#x27;t reached a verdict yet, but in theory it sounds good. I think you&#x27;re still paying the linking cost though?
      1. geauxvirtual · · focus · HN ↗
        Yes.

        Splitting out a project into multiple crates reduces what needs to be recompiled during development. I tend to break out areas of my application that aren&#x27;t going to change regularly so I&#x27;m only having to rebuild the main application.

        In a production scenario where you&#x27;re probably building your application in some CI environment, unless you cache the release build artifacts to re-use when applicable, the entire project will be rebuilt every run.

        1. rapind · · focus · HN ↗
          It’s honestly my biggest issue right now during development. I’m refactoring into a “vertical slice” architecture and crating by feature… fingers crossed.
  8. ddalcino · · focus · HN ↗
    Gonna have to name my next project Penelope Hammertime, or at least Pineapple Häagen-Dazs.
  9. slowin · · focus · HN ↗
    I&#x27;ve moved from Rust to Go for most things because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation. There are times when Rust is more appropriate, but for the vast majority of things Go is perfectly fine.
    1. echelon · · focus · HN ↗
      I nearly did this, but then I swapped to writing native desktop apps and egui - Rust is still worth it.

      I&#x27;ve stopped using Tauri and gone with 100% egui. It&#x27;s cross platform and excellent, and if you give it design constraints it will look beautiful.

      Check out my 100% adobe clean room reimplementations:

      <a href="https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;filmcraft" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;filmcraft

      <a href="https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;photocraft" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;photocraft

      <a href="https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;drawcraft" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;storytold&#x2F;drawcraft (going to rename this vectorcraft)

      The #1 thing for the Rust project to do is make Rust faster to compile.

      Rust is the agentic AI language. It just needs to lean in and go faster.

      1. tcfhgj · · focus · HN ↗
        &gt; The #1 thing for the Rust project to do is make Rust faster to compile.

        #0 get rid of the orphan rule

        1. Quitschquat · · focus · HN ↗
          What&#x27;s the orphan rule?
          1. estebank · · focus · HN ↗
            Rust doesn&#x27;t let you write an impl a trait that wasn&#x27;t declared in your crate for a type that wasn&#x27;t declared in your crate. At least one of the two needs to be locally declared. This makes splitting projects into multiple crates harder than it could be, but on the other hand it makes the crates ecosystem less brittle than it otherwise would be.

            Some people propose relaxing this rule for &quot;workspaces&quot; (local projects with multiple crates that are not published individually). I haven&#x27;t researched whether that would be technically feasible.

            1. echelon · · focus · HN ↗
              It absolutely should be relaxed for workspaces.

              Workspaces are a great way to architect larger projects and monorepos, and they&#x27;d at least be internally consistent.

            2. mrkeen · · focus · HN ↗
              If you built two impls, your compiler wouldn&#x27;t know which to pick. Or to phrase it differently, if you wanted to be able to choose the right one, it wouldn&#x27;t be &#x27;orphan impls&#x27;, it would be &#x27;orphan impls plus some selection mechanism&#x27;. E.g. Scala implicits.
        2. panstromek · · focus · HN ↗
          btw. That could actually make it slower to compile. The compiler uses the orphan rule to short circuit some checks IIRC.

          Nevertheless, people in the project are trying to figuring out a way to relax the rule while still maintaining coherence, so this might happen some day.

          1. cztomsik · · focus · HN ↗
            there are good reasons, obviously, but it&#x27;s my #1 PITA, #2 is comptime type introspection (it looks like @yara-blue is making some progress, so fingers crossed)

            BTW: cheers, we should grab a beer some day :)

            1. panstromek · · focus · HN ↗
              We should ;)
      2. the_sleaze_ · · focus · HN ↗
        These are great
      3. slowin · · focus · HN ↗
        Very cool projects! I agree, desktop apps are one of the areas that Rust beats Go. It&#x27;s too bad though, since I feel anything with a heavy GUI like this can benefit from a rapid iteration cycle which is painful with Rust.
      4. xutopia · · focus · HN ↗
        Wow those are some nice applications! Thanks for sharing this!
      5. jlahijani · · focus · HN ↗
        !!! WOW !!!
      6. mixmastamyk · · focus · HN ↗
        [delayed]
      7. nonethewiser · · focus · HN ↗
        Are agents able to control these well? I saw vector craft mention MCP and a command api. Whats the command api? No CLI it sounds like.
        1. echelon · · focus · HN ↗
          Working on it! That&#x27;s the intent for all of these.

          Going to do Toon Boom and a few others too and build them as a suite.

      8. pjmlp · · focus · HN ↗
        Machine code is the ultimate agentic AI language, we will eventually get there, we are in the middle of the transition to 5 GLs.
        1. echelon · · focus · HN ↗
          Humans need to understand the code.
          1. pjmlp · · focus · HN ↗
            It is right there in the 5 GL language, unless you want to convince us that all your PR come with the corresponding Assembly that the compiler generated, while doing all the compiler passes with PhD level knowledge from everyone that has worked in LLVM since 2003.
      9. shirol · · focus · HN ↗
        Checked out your GitHub profile. This is an insane amount of LLM usage. You created 7 full-blown apps, and each of them is very recent. The earliest commit was only 2 days ago.

        I&#x27;m normally against fully vibe-coded apps, but at this point, I&#x27;m just impressed.

        1. krapp · · focus · HN ↗
          Be impressed when professionals actually test them and find them competitive. Claims like &quot;I one-shotted Photoshop&quot; should cause more alarm than wonder.

          At some point we have to move on from amazement at what these models can do to actually caring about the quality of the product.

    2. throwaway27448 · · focus · HN ↗
      [delayed]
    3. Bolwin · · focus · HN ↗
      I don&#x27;t really understand why Rust seems to be the go-to language for llms. Yes sure it has a good type system, but in practice llms seem to trip over it as much as I do, and given how fast llms are at writing code, that just makes compile times a much larger bottleneck.
      1. GuB-42 · · focus · HN ↗
        Rust and LLMs are a good match.

        Rust is built on the idea that code that compile must be correct, to the best of its abilities. LLMs are fast and sloppy, Rust keeps them in check by not letting them get away with preventable bugs.

        Of course, Rust can&#x27;t do anything for spec bugs, like making the stop light green when it should be red, but it can help with crashes and vulnerabilities.

        1. wannabe44 · · focus · HN ↗
          Real world is far messier than that. Eg:

          1. <a href="https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Ubuntu-Rust-Coreutils-Audit" rel="nofollow">https:&#x2F;&#x2F;www.phoronix.com&#x2F;news&#x2F;Ubuntu-Rust-Coreutils-Audit - file system and OS aren&#x27;t always neatly represented in tYpE sYsTeM.

          2. <a href="https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;18-november-2025-outage&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.cloudflare.com&#x2F;18-november-2025-outage&#x2F; - bad programmers can write bad code in any language.

          3. <a href="https:&#x2F;&#x2F;blog.rust-lang.org&#x2F;2026&#x2F;08&#x2F;20&#x2F;supply-chain-attack-on-arrayref&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.rust-lang.org&#x2F;2026&#x2F;08&#x2F;20&#x2F;supply-chain-attack-on... - the culture of trusting random strangers logging in through GitHub without even 2FA is concerning too.

          If we compare open issues in comparable rust and Go software (eg: sharkdp&#x2F;bat vs sharkdp&#x2F;fd) one would find there&#x27;s no persisting pattern where rust is better.

        2. GuB-42 · · focus · HN ↗
          Another thing I might add is that Rust is a relatively popular language, with a culture of writing high quality code. Many people, starting by those of Mozilla chose Rust to write security-critical, efficient software. They wouldn&#x27;t chose it for throwaway, low skill, non-critical code, as there are languages that are more appropriate for this.

          The result is a large amount of high quality code a LLM can train on. Compare to Zig for instance, which is a fine language, but not as popular so lacking in volume for good training. You then can understand why Anthropic ported Bun from Zig to Rust if they intend to vibe code. Languages like PHP, while actually quite decent today, have a long history of terrible code, so not great for a LLM as most of its training dataset is poisoned.

          The unfortunate part is that it may not last. If Rust becomes the de-facto language for LLM production, overall quality may decrease. It is a common problem with many machine learning techniques including LLMs: feeding them their own output tend to decrease quality.

      2. jeroenhd · · focus · HN ↗
        Go is full of footguns and LLMs still cannot be trusted to follow the rules they themselves conjured up out of thin air. Unlike humans, they don&#x27;t need to be taught the language (which is the hardest part of using Rust, by far), so they get more benefits out of it than many humans do.

        LLMs do trip up when they generate Rust code, but they also do when generating any other language. The big difference is that the Rust compiler refuses to compile broken code faster, whereas Go will just let you SIGSEGV on edge cases without warning.

        The recent TLA+ hype here on HN shows that Rust may just be the beginning here. There are valid, safe Rust programs that will crash, the language isn&#x27;t perfect. The older languages with more math and validation behind them (Ada?) are probably even better suited for generated code, but they don&#x27;t have the hype culture to capture mainstream attention (and even fewer people have the ability to really review that code).

        There&#x27;s an alternative solution of course: use platforms like JS&#x2F;.NET&#x2F;JVMs&#x2F;Python to run code that cannot violently crash because of the language runtime around it. That comes with a performance overhead but it&#x27;s good for prototyping without as many stability footguns and with faster compilations.

        1. mkesper · · focus · HN ↗
          In JS and Python it&#x27;s really easy to produce runtime errors. So no SIGSEGV without C modules but you&#x27;re not sure it works either.
    4. dmead · · focus · HN ↗
      Isn&#x27;t this also the reason people dropped Haskell?
    5. Aurornis · · focus · HN ↗
      &gt; because in the era of agents, being able to iterate quickly on a project is a huge advantage and Rust is way, way slower than Go for compilation.

      Incremental changes in a normal project shouldn’t cause massive compile times. Even for my large projects, the compile times are trivial compared to the duration of an LLM turn.

      Very large projects should be broken into logical modules so only the changed part is incrementally compiled. If linking is taking a long time there are alternate linkers that can be used.

      If you’re using work trees a lot, set up compiler caching to avoid rebuilding everything from zero on every new work tree is important.

      I know these things are frustrating to new Rust users who just want everything to be automatic and easy, but if we’re talking about LLM development anyway then these optimizations would have come up the first time you asked your LLM what could be done about improving compile times. LLMs are very good at setting up these optimizations.

      1. asutekku · · focus · HN ↗
        Compile can take minutes on large codebases, LLM turns usually seconds. How are these even comparable?
        1. Aurornis · · focus · HN ↗
          &gt; LLM turns usually seconds.

          What kind of work are you doing where the LLM turns are only taking &quot;seconds&quot; and it&#x27;s recompiling all the time?

          This morning so far my LLM rounds have taken between 10-15 minutes. An incremental compile happens a couple times at most.

          Even on the largest Rust codebases I&#x27;ve been working with (OSS projects), incremental compiles are not taking multiple minutes unless I do something that triggers a full recompile.

  10. mattz56 · · focus · HN ↗

    [dead]

  11. flipping_beacon · · focus · HN ↗
    Where I live it&#x27;s October already will this work now
  12. s08148692 · · focus · HN ↗
    I finally gave in to the rust hype and built a new project in it (or my agent fleet did). Almost instant regret. My poor machine with just 2TB HDD and 24 cores was almost immediately crippled by agents each working in their own sandbox, each one building and compiling

    Most projects my fleet works on are in other languages (TS, Go, Elixir) and can comfortably handle 10+ agents working in parallel, but not rust. I had to cap the fleet to 5 workers and build a dedicated resource monitor to step in and tidy up every time the disk almost filled up

    That and general progress on building is far slower, with far more time spent building and testing than any other language I use.

    Ended up rebuilding in Go, the perf gains weren&#x27;t worth it

    1. slopinthebag · · focus · HN ↗
      first time i&#x27;ve seen rust&#x27;s compile performance actually act as a filter haha
    2. paholg · · focus · HN ↗
      Most of that time was probably compiling dependencies. If you give it another go, I would recommend a shared sccache.

      <a href="https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;sccache" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;sccache

      1. pjmlp · · focus · HN ↗
        Even that doesn&#x27;t fully avoid recompilation of the same crate, due to features changes across the dependency chain.
        1. dwattttt · · focus · HN ↗
          Changing features should be happening a lot less than building, you surely would go weeks between those after early dev.
    3. Aurornis · · focus · HN ↗
      You should have set up <a href="https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;sccache" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;mozilla&#x2F;sccache at minimum. Setting up compiler caching is routine for people coming from older compiled language backgrounds but it&#x27;s often missed by people coming from languages like JS&#x2F;TS who have never been exposed to these ideas.

      There&#x27;s a new project called kache <a href="https:&#x2F;&#x2F;github.com&#x2F;kunobi-ninja&#x2F;kache" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kunobi-ninja&#x2F;kache that takes this even further and handles more edge cases with worktrees, but it&#x27;s newer.

      If you were pulling the entire project fresh and rebuilding everything in every worktree all the time without any caching then it would be frustrating. You could have asked your agent to set up basic caching and solved most of your problem in minutes.

      1. slopinthebag · · focus · HN ↗
        this is the issue with vibing...you don&#x27;t know what you don&#x27;t know
      2. jiehong · · focus · HN ↗
        Shouldn’t this be part of cargo and enabled by default then ?
        1. gpm · · focus · HN ↗
          Cargo could definitely improve with some inter-project sharing by default, but simultaneously working with a bunch of workspaces of the same project is a very new phenomena...
        2. Aurornis · · focus · HN ↗
          Up until now, developers only worked on one thing at a time. Maybe two.

          Doing 10 separate clean builds to work on 10 things at the same time wasn’t a consideration until very recently.

    4. npalli · · focus · HN ↗

      [dead]

    5. jarjoura · · focus · HN ↗
      You really shouldn&#x27;t build software with rust if your workflow involves 10+ agents. Why aren&#x27;t you using Python or Typescript for things like that?

      Rust is what you use when you want to maximize on the runtime performance. It will build software that requires significantly less memory and maximize the CPU that will save time and energy. It&#x27;s a system language for writing software meant to access the hardware.

      1. ameliaquining · · focus · HN ↗
        Why would that imply that you wouldn&#x27;t use a lot of agents?
    6. virtualritz · · focus · HN ↗
      Make a cargo wrapper (or ask your clanker) with a global build lock.

      Cargo run&#x2F;test&#x2F;nextest&#x2F;run only, check&#x2F;fmt etc should be excluded.

      This avoids contention&#x2F;oversubscription of the CPU which makes builds up to 300% slower from what I measured.

    7. jbellis · · focus · HN ↗
      A couple recs for sccache, which is great, but I upgraded to mbx (<a href="https:&#x2F;&#x2F;github.com&#x2F;jdx&#x2F;mr-boxington&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;jdx&#x2F;mr-boxington&#x2F;) which goes beyond sccache by wrapping cargo to give you better rust-specific management, including incremental compilation.

      My harness control plane will autoconfigure mbx across all your machines, if you like. <a href="https:&#x2F;&#x2F;github.com&#x2F;BrokkAi&#x2F;mjolnir&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;BrokkAi&#x2F;mjolnir&#x2F;

  13. muthuh · · focus · HN ↗
    Oh man just miseed it, October already.
  14. knuckleheads · · focus · HN ↗
    Funny to see this now. I’ve got a private branch I am in the process of shaping up this weekend to show the compiler team. For deep nested projects like rust analyzer, if you emit the meta data about function types earlier for downstream slots to use, before successful type checking, you can start other crates earlier and use all the slots you have instead of sitting around waiting for the full type checking of the bodies (which other crates largely don’t care about). Something like 40% wall time speed up, maybe 10% to 15% if you have the parallel frontend on.
    1. embedding-shape · · focus · HN ↗
      Sounds lovely, give it a try on the codex-rs which seems to be getting close to using 2K crates in their repository any time now. Takes like 30 minutes to compile on a my beefy machine and it&#x27;s a goddamn TUI, not sure what&#x27;s going on, and not too interested in diving into that beast either.
      1. knuckleheads · · focus · HN ↗
        This thing is a monster, blows out the disk space on a Claude code web session. Will run it on my test server later and let you know.
        1. embedding-shape · · focus · HN ↗
          Now I want to test it too! Need any testers with Threadripper systems to really see what it can do? ;) Email in profile
          1. knuckleheads · · focus · HN ↗
            I will email you when I have something up for sure! First cargo check has it at about 28% reduced on codex rs, from 383 seconds down to 277 seconds on a 16 core machine. No -Zthreads yet though, and that typically has a similar effect and reduces the speed up the early meta data gives.
            1. knuckleheads · · focus · HN ↗
              Result:

              Headstart on codex-rs (16 cores, clean builds, median of 3 alternating off&#x2F;on pairs):

                                        off       on     saved
  cargo check           383.8s   277.1s    28%
  cargo build           530.7s   330.8s    38%
  check, -Zthreads=8    220.0s   190.5s    13%
  build, -Zthreads=8    317.3s   249.2s    21%
              Not helpful for compilation yet, but it&#x27;s something :)
              1. hensenjuang · · focus · HN ↗

                [dead]

                1. knuckleheads · · focus · HN ↗
                  Depends on what you are editing I would say, if it&#x27;s something deeper in the stack then it should help. The last numbers I have is that this is a 6-8% improvement for incremental editing of the code for cargo itself, but I&#x27;m having the benchmark be rerun now, as I&#x27;ve landed a fair amount of changes since then.
      2. yearolinuxdsktp · · focus · HN ↗
        It’s insane. 45 minutes to build debug from scratch. Linking is super slow even in debug and that’s without LTO.

        Incremental compilation is not cleaned up. Older deps pile up and don’t get cleaned.

        Run out of disk space? Oh it’s just the 200+ GB codex-rs target folder.

        Forget about doing worktrees.

        Rust has a lot of work to do.

        1. ninkendo · · focus · HN ↗
          [delayed]
          1. yearolinuxdsktp · · focus · HN ↗
            I disagree it’s impossible to solve. Huge C++ projects don’t have continuously growing build directories and can still compile incrementally correctly.
            1. ninkendo · · focus · HN ↗
              [delayed]
        2. WalterBright · · focus · HN ↗
          A full debug build of the DMD D compiler takes 3 seconds on my Mac Mini.
        3. nicoburns · · focus · HN ↗
          &gt; Linking is super slow even in debug

          Linking is normally slower in debug btw (because of the debug info)

          1. khuey · · focus · HN ↗
            Use the split-debuginfo setting in your Cargo.toml to have the DWARF bypass the linker (on Linux, YMMV on other platforms).
        4. kibwen · · focus · HN ↗
          If there&#x27;s a project that takes 45 minutes to produce a debug build from scratch, that&#x27;s not a Rust problem, that&#x27;s a them problem.

          Let&#x27;s compare. I just checked out ripgrep and built it and all its dependencies from scratch. Total time to produce a debug build: 6.92 seconds. This is inside a 16GB VM on a random Linux laptop (on battery); no beefy hardware here.

          Let&#x27;s try something beefier. I just checked out uutils (an implementation of coreutils) and built it from scratch. Total time to produce debug builds, for eighty binaries and all their dependencies: 30.26 seconds.

          Let&#x27;s try something beefier. I just checked out Servo, an entire browser engine, and built it and all its dependencies from scratch. Total time to build and link its one-thousand one-hundred and ten compilation units (along with its infamously huge and serial servo-script bottleneck) into a binary: 4 minutes and 38 seconds.

          If Codex takes 45 minutes to build from scratch, that&#x27;s an indictment of OpenAI and their development processes.

          1. surajrmal · · focus · HN ↗
            Arguably it is a rust problem. Rust can be improved to reduce the need to do as much manual maintenance of crates dynamics to allow for faster build times. The &quot;you&#x27;re holding it wrong&quot; answer is not a good perspective to apply and I am surprised to see a prominent member of the rust community using it.
            1. kibwen · · focus · HN ↗
              No, one can write pathological code in any language. I welcome efforts to improve the performance of the Rust compiler, but nobody is served by optimizing for degenerate use cases to the detriment of legitimate use cases. It is, in fact, possible to hold it wrong; this isn&#x27;t blithe dismissiveness, but rather an accurate statement of reality, and pretending otherwise doesn&#x27;t lead to a better language.
        5. je42 · · focus · HN ↗
          This is why I like Zig and Go. :)
        6. surajrmal · · focus · HN ↗
          Worktrees can work with a shared build cache.
          1. embedding-shape · · focus · HN ↗
            And this specifically work with Rust and target&#x2F; directory? Please do share what you&#x27;ve validated to actually work here.
            1. ninkendo · · focus · HN ↗
              [delayed]
        7. scrubs · · focus · HN ↗
          I&#x27;ve abandoned zig for rust. I expected to be annoyed by rust build times, but so far it&#x27;s been quite good for my needs. To the contrary it has not been any impediment even when prost etc all drag in many deps from a cold build.

          The zig compiler apart from a couple of cross build or linker issues is darn good. Switch to rust is a function of library support, private struct fields. Rust itself is better organized and far better documented compared to zig.

          However, rust has got to get their allocators for container support straightened out soon. I do SAAS for fintech and low level packet transports. Both benefit greatly with allocators custom designed for job at hand.

          45 mins strikes me as something else is amiss ...

          1. NobodyNada · · focus · HN ↗
            &gt; However, rust has got to get their allocators for container support straightened out soon

            Good news: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;156882" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rust&#x2F;pull&#x2F;156882

            The allocator API has been stabilized, to be released in Rust 1.100 in November. (Though only Vec and Box will support custom allocators immediately; the rest of the standard library collections are coming later.)

        8. JoshTriplett · · focus · HN ↗
          &gt; It’s insane. 45 minutes to build debug from scratch. Linking is super slow even in debug and that’s without LTO.

          How much memory do you have, and do you have swap turned on?

          I have 32GB of RAM, and it barely manages to build release if I shut down everything else on the system that uses RAM. 64GB would be better. If you have 32GB or less and you have swap on, the performance might be mostly because you&#x27;re spending a lot of time swapping. And that&#x27;s for release; debug on a repo that size may spend a lot of time and memory linking debug info.

      3. lr1970 · · focus · HN ↗
        I build it with `cargo build -p codex-cli --bin codex` in under 4 minutes on my old M1 MacBook Pro with 64GB memory compiling more than 1250 crates.
        1. embedding-shape · · focus · HN ↗
          Sure, that compiles in a few minutes for me too, give it a try with a release build and compiling the full workspace though, since the point here is to stress the compiler :)
      4. surajrmal · · focus · HN ↗
        It has 1.8 million lines of rust. That compilation time seems close to what I&#x27;d expect at that size. If you want something faster you should focus on distributed build caching rather than speeding up the compiler. Also note that crates are effectively equivalent to a single file in c++ as it&#x27;s the compilation unit. This is similar to compiling 2k files that average 1k loc each in c++. I&#x27;m sure it&#x27;s much worse when you account for macro expansion and generics.
        1. mort96 · · focus · HN ↗
          As they say, it&#x27;s a damn TUI for a chat bot. 1.8 MLoC is like 50x what you&#x27;d expect from something like that. If you want to speed up compilation, reducing that absolutely insane bloat would be a good start
        2. embedding-shape · · focus · HN ↗
          &gt; If you want something faster you should focus on distributed build caching rather than speeding up the compiler

          ... But the whole point is that that project is big, unwieldy and has lots of crates, both their own and 3rd party. Slapping a cache in front of it kind of defeats the purpose here, to see how parent&#x27;s thing would speed things up for really large projects.

    2. panstromek · · focus · HN ↗
      Nice, excited to see that. This is basically deeper pipelining, IIUC. Nick (the author of the blog) implemented the current version of this &quot;emit metadata sooner,&quot; optimization and already experimented with pushing it even sooner a while back.

      We have discussed this briefly on last All Hands, the problem will probably be dealing with compiler errors, when they happen in builds that already emitted metadata. I believe this was the reason why it wasn&#x27;t merged in the first place.

      1. knuckleheads · · focus · HN ↗
        Yes I think I read a post of his from like 2019 were something was tried like this before. My guess is that this will be an interesting and hopefully informative PR for you all to see, but will likely not be merged as is. I had to add the ability for rustc to pause after early meta data emission and that was hacked together I feel, not well designed per se.

        I view this as speculative execution&#x2F;compilation and just throw out any errors from a crate that depended on another crate that ultimately errors out. It has the same outcome (same errors are printed in both cases) you just have a chance of having totally wasted some cpu time (that was otherwise just sitting around though).

        1. knuckleheads · · focus · HN ↗
          <a href="https:&#x2F;&#x2F;github.com&#x2F;PowderworksCode&#x2F;headstart" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;PowderworksCode&#x2F;headstart

          ^ run setup and give it a whirl. Will send to Rust compiler team when I have some pr&#x27;s up etc.

  15. randypewick · · focus · HN ↗
    I recall a talk about makepad.dev, I think it was by Rik Arends, that explained how they achieved outstanding compilation times in rust for makepad.

    I can&#x27;t find that talk again, but it was quite interesting: the rust compiler is fast, but often times it has to perform a lot of unnecessary checks because crates contain more stuff than needed. By stripping unnecessary work, the makepad team made building pretty fast.

  16. dabinat · · focus · HN ↗
    The parallel frontend is inching closer to stability too, with an open PR to enable it by default on nightly.

    But the real speedup will happen when TPDE is enabled: <a href="https:&#x2F;&#x2F;goals.rust-lang.org&#x2F;2026&#x2F;tpde.html" rel="nofollow">https:&#x2F;&#x2F;goals.rust-lang.org&#x2F;2026&#x2F;tpde.html

  17. 1vuio0pswjnm7 · · focus · HN ↗
    How does the Rust compiler&#x27;s speed compare to the speed of the C compiler GCC

    Is it slower

    1. simonask · · focus · HN ↗
      It’s not compiling C code, so that’s not really possible to answer. C is uniquely fast to compile, especially compared with more featureful languages like C++ and Rust.

      In practice, C++ and Rust feel pretty similar, mostly due to the kind of code people tend to write in both languages (favoring static dispatch, generics&#x2F;templates, etc.).

      1. pjmlp · · focus · HN ↗
        Nowadays it is fast, back in the 2000&#x27;s was still able to take one hour per platform on our application servers, when doing a clean build.

        Compilers for languages like BASIC, Delphi, Eiffel, Modula-2, Caml Light, Oberon, Clipper, COBOL, were running circles around C compilers back then.

    2. 1vuio0pswjnm7 · · focus · HN ↗
      Rephrased question: How does the Rust compiler&#x27;s speed compare to the C compiler GCC&#x27;s speed with respect the language each is compiling, i.e., rust and C, respectively
  18. sharktheone · · focus · HN ↗
    I think there are a few more. Especially cranelift, but I would not use it for production stuff and it is missing a lot of llvm intrinsics that will just trap if you are trying to use them. But for most it seems to be just fine for regular dev builds with a HUGE speedup.
  19. jongjong · · focus · HN ↗
    I don&#x27;t understand why developers are interested in Rust.

    - Raw performance doesn&#x27;t actually matter for the vast majority of use cases. Performance does not equate scalability. Moreover, differences usually disappear in practice once you&#x27;ve actually developed the software because time and storage complexity of operations usually dwarf constant resource costs. Furthermore, do you realize how much more computational resources AI uses compared to a classic piece of software? Trying to optimize tools in the age of AI is like putting lipstick on a pig.

    - It&#x27;s more verbose than most other languages; waste of tokens, context window, time and AI reasoning capacity. The strain most devs feel when reading Rust, also impacts LLMs. It obfuscates essential logic and replaces it with ceremony.

    - The Rust training set is far smaller than other popular programming languages. It&#x27;s also quite different from other programming languages so it probably doesn&#x27;t benefit as much from cross-language patterns; in fact, could be problematic.

    - You have to wait for a compiler; more wasted time which the AI agent could have been using to write code.

    It&#x27;s like TypeScript. Devs became obsessed with TypeScript. Everyone was sure that it would be better for AI. Not the case. LLMs essentially never make type errors in JavaScript (or TypeScript). Static typing is completely redundant. These are the most trivial kinds of errors to avoid. Seriously, try Claude with vanilla JavaScript on Node.js. TypeScript is worse with AI because people who used it tended to over-engineer, also a lot of TypeScript is ceremonial and performative complexity intended for a bureaucratic audience; those are the main patterns which AIs picked up from their training set.

    Seriously, try working with a TypeScript codebase and notice how Claude invents all these contrived abstractions, spread out over a huge number of files with unclear separation of concerns and full of lengthy, highly contrived comments.

    It&#x27;s the same issue with all these over-engineered languages which were developed for people who were not good at coding and needed a whole bunch of extra safety features in order to produce functioning software. It&#x27;s like training wheels on a bike; great to learn in the early stages but if you want to learn how the pros do it, you&#x27;ve got to look at the people who compete in the Olympics; and note that there&#x27;s a reason none of them still have training wheels on their bikes!

    1. pjmlp · · focus · HN ↗
      Some of us are interested in its type system, more than anything.

      I rather have the option of Swift 6, Linear Haskell, Koka, OxCaml, Scala 3, and co.

      Have automatic resource management as default, with additional type system abilities for low level coding.

      1. blandflakes · · focus · HN ↗
        I agree that automatic resource management is a real prize, and something that Scala 2 had in libraries but was hard to guarantee at compile time. I think I fix a leaked resource a month in our Scala code.
    2. vor_ · · focus · HN ↗
      Goodness. What a terrible take on every point. My favorites are the claim that raw performance doesn&#x27;t matter and that memory safety is only for bad programmers, despite this industry having nearly a half-century history of severe memory vulnerabilities regardless of experience level.
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.