Comments

• By dminik 2025-06-2713:571 reply

  One aspect that I find interesting is that Rust projects often seem deceivingly small.

  First, dependencies don't translate easily to the perceived size. In C++ dependencies on large projects are often vendored (or even not used at all). And so it is easy to look at your ~400000 line codebase and go "it's slow, but there's a lot of code here after all".

  Second (and a much worse problem) are macros. They actually hit the same issue. A macro that expands to 10s or 100s of lines can very quickly take your 10000 line project and turn it into a million line behemoth.

  Third are generics. They also suffer the same problem. Every generic instantiation is eating your CPU.

  But I do want to offer a bit of an excuse for rust. Because these are great features. They turn what would have taken 100000 lines of C or 25000 lines of C++ to a few 1000s lines of Rust.

  However, there is definitely an overuse here making the ecosystem seem slow. For instance, at work we use async-graphql. The library itself is great, but it's an absolute proc-macro hog. There's issues in the repository open for years about the performance. You can literally feel the compiler getting slower for each type you add.

  By jvanderbot 2025-06-2715:021 reply
  You can literally feel the compiler getting slower for each type you add.
  YSK: The compiler performance is IIRC exponential in the "depth" of types. And oh boy does GraphQL love their nested types.
• By taylorallred 2025-06-2620:2917 reply

  So there's this guy you may have heard of called Ryan Fleury who makes the RAD debugger for Epic. The whole thing is made with 278k lines of C and is built as a unity build (all the code is included into one file that is compiled as a single translation unit). On a decent windows machine it takes 1.5 seconds to do a clean compile. This seems like a clear case-study that compilation can be incredibly fast and makes me wonder why other languages like Rust and Swift can't just do something similar to achieve similar speeds.

  By lordofgibbons 2025-06-2620:397 reply

  The more your compiler does for you at build time, the longer it will take to build, it's that simple.

  Go has sub-second build times even on massive code-bases. Why? because it doesn't do a lot at build time. It has a simple module system, (relatively) simple type system, and leaves a whole bunch of stuff be handled by the GC at runtime. It's great for its intended use case.

  When you have things like macros, advanced type systems, and want robustness guarantees at build time.. then you have to pay for that.

  By duped 2025-06-2621:256 reply

  I think this is mostly a myth. If you look at Rust compiler benchmarks, while typechecking isn't _free_ it's also not the bottleneck.

  A big reason that amalgamation builds of C and C++ can absolutely fly is because they aren't reparsing headers and generating exactly one object file so the linker has no work to do.

  Once you add static linking to the toolchain (in all of its forms) things get really fucking slow.

  Codegen is also a problem. Rust tends to generate a lot more code than C or C++, so while the compiler is done doing most of its typechecking work, the backend and assembler has a lot of things to chuck through.

  By benreesman 2025-06-2712:423 reply

  The meme that static linking is slow or produces anything other than the best executables is demonstrably false and the result of surprisingly sinister agendas. Get out readelf and nm and PS sometime and do the arithematic: most programs don't link much of glibc (and its static link is broken by design, musl is better at just about everything). Matt Godbolt has a great talk about how dynamic linking actually works that should give anyone pause.

  DLLs got their start when early windowing systems didn't quite fit on the workstations of the era in the late 80s / early 90s.

  In about 4 minutes both Microsoft and GNU were like, "let me get this straight, it will never work on another system and I can silently change it whenever I want?" Debian went along because it gives distro maintainers degrees of freedom they like and don't bear the costs of.

  Fast forward 30 years and Docker is too profitable a problem to fix by the simple expedient of calling a stable kernel ABI on anything, and don't even get me started on how penetrated everything but libressl and libsodium are. Protip: TLS is popular with the establishment because even Wireshark requires special settings and privileges for a user to see their own traffic, security patches my ass. eBPF is easier.

  Dynamic linking moves control from users to vendors and governments at ruinous cost in performance, props up bloated industries like the cloud compute and Docker industrial complex, and should die in a fire.

  Don't take my word for it, swing by cat-v.org sometimes and see what the authors of Unix have to say about it.

  I'll save the rant about how rustc somehow manages to be slower than clang++ and clang-tidy combined for another day.

  By jelder 2025-06-2713:43

  CppCon 2018: Matt Godbolt “The Bits Between the Bits: How We Get to main()"

  https://www.youtube.com/watch?v=dOfucXtyEsU

  By duped 2025-06-2714:161 reply

  I think you're confused about my comment and this thread - I'm talking about build times.

  By benreesman 2025-06-2716:31

  You said something false and important and I took the opportunity to educate anyone reading about why this aspect of their computing experience is a mess. All of that is germane to how we ended up in a situation where someone is calling rustc with a Dockerfile and this is considered normal.

  By jrmg 2025-06-2714:002 reply

  …surprisingly sinister agendas.

  …

  Dynamic linking moves control from users to vendors and governments at ruinous cost in performance, props up bloated industries...

  This is ridiculous. Not everything is a conspiracy!

  By benreesman 2025-06-2716:28

  I didn't say anything was a conspiracy, let alone everything. I said inferior software is promoted by vendors on Linux as well as on MacOS and Windows with unpleasant consequences for users in a way that serves those vendors and the even more powerful institutions to which they are beholden. Sinister intentions are everywhere in this business (go read the opinions of the people who run YC), that's not even remotely controversial.

  If fact, if there was anything remotely controversial about a bunch of extremely specific, extremely falsifiable claims I made, one imagines your rebuttal would have mentioned at least one.

  I said inflmatory things (Docker is both arsonist and fireman at ruinous cost), but they're fucking true. That Alpine in the Docker jank? Links musl!

  By k__ 2025-06-2714:11

  That's an even more reasonable fear than trusting trust, and people seem to take that seriously.

  By treyd 2025-06-2623:441 reply

  Not only does it generate more code, the initially generated code before optimizations is also often worse. For example, heavy use of iterators means a ton of generics being instantiated and a ton of call code for setting up and tearing down call frames. This gets heavily inlined and flattened out, so in the end it's extremely well-optimized, but it's a lot of work for the compiler. Writing it all out classically with for loops and ifs is possible, but it's harder to read.

  By estebank 2025-06-2714:29

  For loops are sugar around an Iterator instantiation:

    for i in 0..10 {}
  

  translates to roughly

    let mut iter = Range { start: 0, end: 10 }.into_iter();
    while let Some(i) = iter.next() {}

  By the-lazy-guy 2025-06-2712:07

  > Once you add static linking to the toolchain (in all of its forms) things get really fucking slow.

  Could you expand on that, please? Every time you run dynmically linked program, it is linked at runtime. (unless it explicitly avoids linking unneccessary stuff by dlopening things lazily; which pretty much never happens). If it is fine to link on every program launch, linking at build time should not be a problem at all.

  If you want to have link time optimization, that's another story. But you absolutely don't have to do that if you care about build speed.

  By fingerlocks 2025-06-270:353 reply

  The swift compiler is definitely bottle necked by type checking. For example, as a language requirement, generic types are left more or less in-tact after compilation. They are type checked independent of what is happening. This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.

  This has tradeoffs: increased ABI stability at the cost of longer compile times.

  By slavapestov 2025-06-2715:18

  > This has tradeoffs: increased ABI stability at the cost of longer compile times.

  Nah. Slow type checking in Swift is primarily caused by the fact that functions and operators can be overloaded on type.

  Separately-compiled generics don't introduce any algorithmic complexity and are actually good for compile time, because you don't have to re-type check every template expansion more than once.

  By willtemperley 2025-06-274:162 reply

  A lot can be done by the programmer to mitigate slow builds in Swift. Breaking up long expressions into smaller ones and using explicit types where type inference is expensive for example.

  I’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.

  By ykonstant 2025-06-277:561 reply

  >I’d like to see tooling for this to pinpoint bottlenecks - it’s not always obvious what’s making builds slow.

  I second this enthusiastically.

  By glhaynes 2025-06-2710:27

  I'll third it. I've started to see more and more cargo culting of "fixes" that I'm extremely suspicious do nothing aside from making the code bulkier.

  By never_inline 2025-06-2712:11

  > Breaking up long expressions into smaller ones

  If it improves compile time, that sounds like a bug in the compiler or the design of the language itself.

  By windward 2025-06-278:26

  >This is unlike C++ templates which are effectively copy-pasting the resolved type with the generic for every occurrence of type resolution.

  Even this can lead to unworkable compile times, to the point that code is rewritten.

  By windward 2025-06-278:231 reply

  >Codegen is also a problem. Rust tends to generate a lot more code than C or C++

  Wouldn't you say a lot of that comes from the macros and (by way of monomorphisation) the type system?

  By jandrewrogers 2025-06-2715:48

  Modern C++ in particular does a lot of similar, albeit not identical, codegen due to its extensive metaprogramming facilities. (C is, of course, dead simple.) I've never looked into it too much but anecdotally Rust does seem to generate significantly more code than C++ in cases where I would intuitively expect the codegen to be similar. For whatever reason, the "in theory" doesn't translate to "in practice" reliably.

  I suspect this leaks into both compile-time and run-time costs.

  By blizdiddy 2025-06-2712:241 reply

  Go is static by default and still fast as hell

  By vintagedave 2025-06-2712:49

  Delphi is static by default and incredibly fast too.

  By ChadNauseam 2025-06-2621:213 reply

  That the type system is responsible for rust's slow builds is a common and enduring myth. `cargo check` (which just does typechecking) is actually usually pretty fast. Most of the build time is spent in the code generation phase. Some macros do cause problems as you mention, since the code that contains the macro must be compiled before the code that uses it, so they reduce parallelism.

  By rstuart4133 2025-06-2621:361 reply

  > Most of the build time is spent in the code generation phase.

  I can believe that, but even so it's caused by the type system monomorphising everything. When it use qsort from libc, you are using per-compiled code from a library. When you use slice::sort(), you get custom assembler compiled to suit your application. Thus, there is a lot more code generation going on, and that is caused by the tradeoffs they've made with the type system.

  Rusts approach give you all sorts of advantages, like fast code and strong compile time type checking. But it comes with warts too, like fat binaries, and a bug in slice::sort() can't be fixed by just shipping of the std dynamic library, because there is no such library. It's been recompiled, just for you.

  FWIW, modern C++ (like boost) that places everything in templates in .h files suffers from the same problem. If Swift suffers from it too, I'd wager it's the same cause.

  By badmintonbaseba 2025-06-279:261 reply

  It's partly by the type system. You can implement a std::sort (or slice::sort()) that just delegates to qsort or a qsort-like implementation and have roughly the same compile time performance as just using qsort straight.

  But not having to is a win, as the monomorphised sorts are just much faster at runtime than having to do an indirect call for each comparison.

  By estebank 2025-06-2714:37

  This is a pattern a crate author can rely on (write a function that uses genetics that immediately delegates to a function that uses trait objects or converts to the needed types eagerly so the common logic gets compiled only once), and there have been multiple efforts to have the compiler do that automatically. It has been called polymorphization and it comes up every now and then: https://internals.rust-lang.org/t/add-back-polymorphization/...

  By tedunangst 2025-06-2622:322 reply

  I just ran cargo check on nushell, and it took a minute and a half. I didn't time how long it took to compile, maybe five minutes earlier today? So I would call it faster, but still not fast.

  I was all excited to conduct the "cargo check; mrustc; cc" is 100x faster experiment, but I think at best, the multiple is going to be pretty small.

  By ChadNauseam 2025-06-2623:491 reply

  Did you do it from a clean build? In that case, it's actually a slightly misleading metric, since rust needs to actually compile macros in order to typecheck code that uses them. (And therefore must also compile all the code that the macro depends on.) My bad for suggesting it, haha. Incremental cargo check is often a better way of seeing how long typechecking takes, since usually you haven't modified any macros that will need to be recompiled. On my project at work, incremental cargo check takes `1.71s`.

  By estebank 2025-06-2714:48

  Side note: There's an effort to cache proc macro invocations so that they get executed only once if the item they annotate hasn't changed: https://github.com/rust-lang/rust/pull/129102

  There are multiple caveats on providing this to users (we can't assume that macro invocations are idempotent, so the new behavior would have to be opt in, and this only benefits incremental compilation), but it's in our radar.

  By CryZe 2025-06-279:08

  A ton of that is actually still doing codegen (for the proc macros for example).

  By cogman10 2025-06-2621:281 reply

  Yes but I'd also add that Go specifically does not optimize well.

  The compiler is optimized for compilation speed, not runtime performance. Generally speaking, it does well enough. Especially because it's usecase is often applications where "good enough" is good enough (IE, IO heavy applications).

  You can see that with "gccgo". Slower to compile, faster to run.

  By cherryteastain 2025-06-2622:191 reply

  Is gccgo really faster? Last time I looked it looked like it was abandoned (stuck at go 1.18, had no generics support) and was not really faster than the "actual" compiler.

  By cogman10 2025-06-273:28

  Digging around, looks like it's workload dependent.

  For pure computational workloads, it'll be faster. However, anything with heavy allocation will suffer as apparently the gccgo GC and GC related optimizations aren't as good as cgo's.

  By Mawr 2025-06-276:39

  Not really. The root reason behind Go's fast compilation is that it was specifically designed to compile fast. The implementation details are just a natural consequence of that design decision.

  Since fast compilation was a goal, every part of the design was looked at through a rough "can this be a horrible bottleneck?", and discarded if so. For example, the import (package) system was designed to avoid the horrible, inefficient mess of C++. It's obvious that you never want to compile the same package more than once and that you need to support parallel package compilation. These may be blindingly obvious, but if you don't think about compilation speed at design time, you'll get this wrong and will never be able to fix it.

  As far as optimizations vs compile speed goes, it's just a simple case of diminishing returns. Since Rust has maximum possible perfomance as a goal, it's forced to go well into the diminishing returns territory, sacrificing a ton of compile speed for minor performance improvements. Go has far more modest performance goals, so it can get 80% of the possible performance for only 20% of the compile cost. Rust can't afford to relax its stance because it's competing with languages like C++, and to some extent C, that are willing to go to any length to squeeze out an extra 1% of perfomance.

  By phplovesong 2025-06-2715:01

  Thats not really true. As a counter example, Ocaml has a very advanced type system, full typeinference, generics and all that jazz. Still its on par, or even faster to compile than Go.

  By jstanley 2025-06-2711:141 reply

  > Go has sub-second build times even on massive code-bases.

  Unless you use sqlite, in which case your build takes a million years.

  By Groxx 2025-06-2713:03

  Yeah, I deal with multiple Go projects that take a couple minutes to link the final binary, much less build all the intermediates.

  Compilation speed depends on what you do with a language. "Fast" is not an absolute, and for most people it depends heavily on community habits. Rust habits tend to favor extreme optimizability and/or extreme compile-time guarantees, and that's obviously going to be slower than simpler code.

  By Zardoz84 2025-06-2622:00

  Dlang compilers does more than any C++ compiler (metaprogramming, a better template system and compile time execution) and it's hugely faster. Language syntax design has a role here.

  By dhosek 2025-06-2620:465 reply

  Because Russt and Swift are doing much more work than a C compiler would? The analysis necessary for the borrow checker is not free, likewise with a lot of other compile-time checks in both languages. C can be fast because it effectively does no compile-time checking of things beyond basic syntax so you can call foo(char) with foo(int) and other unholy things.

  By steveklabnik 2025-06-2620:521 reply

  The borrow checker is usually a blip on the overall graph of compilation time.

  The overall principle is sound though: it's true that doing some work is more than doing no work. But the borrow checker and other safety checks are not the root of compile time performance in Rust.

  By kimixa 2025-06-2622:591 reply

  While the borrow checker is one big difference, it's certainly not the only thing the rust compiler offers on top of C that takes more work.

  Stuff like inserting bounds checking puts more work on the optimization passes and codegen backend as it simply has to deal with more instructions. And that then puts more symbols and larger sections in the input to the linker, slowing that down. Even if the frontend "proves" it's unnecessary that calculation isn't free. Many of those features are related to "safety" due to the goals of the language. I doubt the syntax itself really makes much of a difference as the parser isn't normally high on the profiled times either.

  Generally it provides stricter checks that are normally punted to a linter tool in the c/c++ world - and nobody has accused clang-tidy of being fast :P

  By simonask 2025-06-279:49

  It truly is not about bounds checks. Index lookups are rare in practical Rust code, and the amount of code generated from them is miniscule.

  But it _is_ about the sheer volume of stuff passed to LLVM, as you say, which comes from a couple of places, mostly related to monomorphization (generics), but also many calls to tiny inlined functions. Incidentally, this is also what makes many "modern" C++ projects slow to compile.

  In my experience, similarly sized Rust and C++ projects seem to see similar compilation times. Sometimes C++ wins due to better parallelization (translation units in Rust are crates, not source files).

  By taylorallred 2025-06-2620:54

  These languages do more at compile time, yes. However, I learned from Ryan's discord server that he did a unity build in a C++ codebase and got similar results (just a few seconds slower than the C code). Also, you could see in the article that most of the time was being spent in LLVM and linking. With a unity build, you nearly cut out link step entirely. Rust and Swift do some sophisticated things (hinley-milner, generics, etc.) but I have my doubts that those things cause the most slowdown.

  By drivebyhooting 2025-06-2620:49

  That’s not a good example. Foo(int) is analyzed by compiler and a type conversion is inserted. The language spec might be bad, but this isn’t letting the compiler cut corners.

  By jvanderbot 2025-06-2621:111 reply

  If you'd like the rust compiler to operate quickly:

  * Make no nested types - these slow compiler time a lot

  * Include no crates, or ones that emphasize compiler speed

  C is still v. fast though. That's why I love it (and Rust).

  By windward 2025-06-278:31

  >Make no nested types

  I wouldn't like it that much

  By Thiez 2025-06-2620:561 reply

  This explanation gets repeated over and over again in discussions about the speed of the Rust compiler, but apart from rare pathological cases, the majority of time in a release build is not spent doing compile-time checks, but in LLVM. Rust has zero-cost abstractions, but the zero-cost refers to runtime, sadly there's a lot of junk generated at compile-time that LLVM has to work to remove. Which is does, very well, but at cost of slower compilation.

  By vbezhenar 2025-06-2621:473 reply

  Is it possible to generate less junk? Sounds like compiler developers took a shortcuts, which could be improved over time.

  By LtdJorge 2025-06-278:16

  Well, zero-cost abstractions are still abstractions. It’s not junk per-se, but things that will be optimized out if the IR has enough information to safely do so, so basically lots of extra metadata to actually prove to LLVM that these things are safe.

  By zozbot234 2025-06-2622:291 reply

  You can address the junk problem manually by having generic functions delegate as much of their work as possible to non-generic or "less" generic functions (Where a "less" generic function is one that depends only on a known subset of type traits, such as size or alignment. Then delegating can help the compiler generate fewer redundant copies of your code, even if it can't avoid code monomorphization altogether.)

  By andrepd 2025-06-277:411 reply

  Isn't something like this blocked on the lack of specialisation?

  By dwattttt 2025-06-2711:201 reply

  I believe the specific advice they're referring to has been stable for a while. You take your generic function & split it into a thin generic wrapper, and a non-generic worker.

  As an example, say your function takes anything that can be turned into a String. You'd write a generic wrapper that does the ToString step, then change the existing function to just take a String. That way when your function is called, only the thin outer function is monomorphised, and the bulk of the work is a single implementation.

  It's not _that_ commonly known, as it only becomes a problem for a library that becomes popular.

  By estebank 2025-06-2714:55

  To illustrate:

    fn foo<S: Into<String>>(s: S) {
        fn inner(s: String) { ... }
        inner(s.into())
    }

  By rcxdude 2025-06-2622:13

  Probably, but it's the kind of thing that needs a lot of fairly significant overhauls in the compiler architecture to really move the needle on, as far as I understand.

  By vbezhenar 2025-06-2621:402 reply

  I encountered one project in 2000-th with few dozens of KLoC in C++. It compiled in a fraction of a second on old computer. My hello world code with Boost took few seconds to compile. So it's not just about language, it's about structuring your code and using features with heavy compilation cost. I'm pretty sure that you can write Doom with C macros and it won't be fast. I'm also pretty sure, that you can write Rust code in a way to compile very fast.

  By taylorallred 2025-06-2621:543 reply

  I'd be very interested to see a list of features/patterns and the cost that they incur on the compiler. Ideally, people should be able to use the whole language without having to wait so long for the result.

  By vbezhenar 2025-06-2622:561 reply

  So there are few distinctive patterns I observed in that project. Please note that many of those patterns are considered anti-patterns by many people, so I don't necessarily suggest to use them.

  1. Use pointers and do not include header file for class, if you need pointer to that class. I think that's a pretty established pattern in C++. So if you want to declare pointer to a class in your header, you just write `class SomeClass;` instead of `#include "SomeClass.hpp"`.

  2. Do not use STL or IOstreams. That project used only libc and POSIX API. I know that author really hated STL and considered it a huge mistake to be included to the standard language.

  3. Avoid generic templates unless absolutely necessary. Templates force you to write your code in header file, so it'll be parsed multiple times for every include, compiled to multiple copies, etc. And even when you use templates, try to split the class to generic and non-generic part, so some code could be moved from header to source. Generally prefer run-time polymorphism to generic compile-time polymorphism.

  By dieortin 2025-06-270:522 reply

  Why use C++ at that point? Also, pre declaring classes instead of including the corresponding headers has quite a few drawbacks.

  By maccard 2025-06-277:49

  References, for one. Also there’s a huge difference between “avoid templates unless necessary” and “don’t use templates”.

  By kortilla 2025-06-271:23

  RAII? shared pointers?

  By kccqzy 2025-06-2622:09

  Templates as one single feature can be hugely variable. Its effect on compilation time can be unmeasurable. Or you can easily write a few dozen lines that will take hours to compile.

  By LtdJorge 2025-06-278:19

  There is an experimental Cranelift backend[0] for rustc to improve compilation performance in debug builds.

  https://github.com/rust-lang/rustc_codegen_cranelift

  By herewulf 2025-06-278:12

  My anecdata would be that the average C++ developer puts includes inside of every header file which includes more headers to the point where everything is including everything else and a single .cpp file draws huge swaths of unnecessary code in and the project takes eons to compile on a fast computer.

  That's my 2000s development experience. Fortunately I've spent a good chunk of the 2010s and most of the 2020s using other languages.

  The classic XKCD compilation comic exists for a reason.

  By tptacek 2025-06-2620:36

  I don't think it's interesting to observe that C code can be compiled quickly (so can Go, a language designed specifically for fast compilation). It's not a problem intrinsic to compilation; the interesting hard problem is to make Rust's semantics compile quickly. This is a FAQ on the Rust website.

  By weinzierl 2025-06-279:04

  This is sometimes called amalgamation and you can do it Rust as well. Either manually or with tools. The point is that apart from very specific niches it is just not a practical approach.

  It's not that it can't be done but that it usually is not worth the hassle and our goal should be for compilation to be fast despite not everything being in one file.

  Turbo Pascal is a prime example for a compiler that won the market not least because of its - for the time - outstanding compilation speed.

  In the same vein, a language can be designed for fast compilation. Pascal in general was designed for single-pass compilation which made it naturally fast. All the necessary forward declarations were a pain though and the victory of languages that are not designed for single-pass compilation proofs that while doable it was not worth it in the end.

  By ceronman 2025-06-2621:052 reply

  I bet that if you take those 278k lines of code and rewrite them in simple Rust, without using generics, or macros, and using a single crate, without dependencies, you could achieve very similar compile times. The Rust compiler can be very fast if the code is simple. It's when you have dependencies and heavy abstractions (macros, generics, traits, deep dependency trees) that things become slow.

  By taylorallred 2025-06-2622:241 reply

  I'm curious about that point you made about dependencies. This Rust project (https://github.com/microsoft/edit) is made with essentially no dependencies, is 17,426 lines of code, and on an M4 Max it compiles in 1.83s debug and 5.40s release. The code seems pretty simple as well. Edit: Note also that this is 10k more lines than the OP's project. This certainly makes those deps suspicious.

  By MindSpunk 2025-06-270:431 reply
  The 'essentially no dependencies' isn't entirely true. It depends on the 'windows' crate, which is Microsoft's auto-generated Win32 bindings. The 'windows' crate is huge, and would be leading to hundreds of thousands of LoC being pulled in.
  There's some other dependencies in there that are only used when building for test/benchmarking like serde, zstd, and criterion. You would need to be certain you're building only the library and not the test harness to be sure those aren't being built too.

  By 90s_dev 2025-06-2621:083 reply

  I can't help but think the borrow checker alone would slow this down by at least 1 or 2 orders of magnitude.

  By tomjakubowski 2025-06-2621:42

  The borrow checker is really not that expensive. On a random example, a release build of the regex crate, I see <1% of time spent in borrowck. >80% is spent in codegen and LLVM.

  By steveklabnik 2025-06-2621:15

  Your intuition would be wrong: the borrow checker does not take much time at all.

  By FridgeSeal 2025-06-2621:21

  Again, as this been often repeated, and backed up with data, the borrow-checker is a tiny fraction of a Rust apps build time, the biggest chunk of time is spent in LLVM.

  By john-h-k 2025-06-2710:07

  My C compiler, which is pretty naive and around ~90,000 lines, can compile _itself_ in around 1 second. Clang can do it in like 0.4.

  The simple truth is a C compiler doesn’t need to do very much!

  By motorest 2025-06-2711:531 reply

  > This seems like a clear case-study that compilation can be incredibly fast (...)

  Have you tried troubleshooting a compiler error in a unity build?

  Yeah.

  By moffkalast 2025-06-2718:32

  It compiles in 2 seconds! Does it run? No, but it was fast!

  By ben-schaaf 2025-06-272:421 reply

  Every claim I've seen about unity builds being fast just never rings true to me. I just downloaded the rad debugger and ran the build script on a 7950x (about as fast as you can get). A debug build took 5s, a release build 34s with either gcc or clang.

  Maybe it's a MSVC thing - it does seem to have some multi-threading stuff. In any case raddbg non-clean builds take longer than any of my rust projects.

  By maccard 2025-06-277:522 reply

  I use unity builds day in day out. The speed up is an order of magnitude on a 2m+ LOC project.

  If you want to see the difference download unreal engine and compile the editor with and without unity builds enabled.

  My experience has been the polar opposite of yours - similar size rust projects are an order of magnitude slower than C++ ones. Could you share an example of a project to compare with?

  By ben-schaaf 2025-06-2715:01

  > If you want to see the difference download unreal engine and compile the editor with and without unity builds enabled.

  UE doesn't use a full unity build, it groups some files together into small "modules". I can see how this approach may have some benefits; you're trading off a faster clean build for a slower incremental build.

  I tested compiling UnrealFrontend, and a default setup with the hybrid unity build took 148s. I noticed it was only using half my cores due to memory constraints. I disabled unity and upped the parallelism and got 182s, so 22% slower while still using less memory. A similarly configured unity build was 108s, so best case is ~2x.

  On the other hand only changing the file TraceTools/SFilterPreset.cpp resulted in 10s compilation time under a unity build, and only 2s without unit.

  I can see how this approach has its benefits (and drawbacks). But to be clear this isn't what projects like raddbg and sqlite3 are doing. They're doing a single translation unit for the entire project. No parallelism, no incremental builds, just a single compiler invocation. This is usually what I've seen people mean by a unity build.

  > My experience has been the polar opposite of yours - similar size rust projects are an order of magnitude slower than C++ ones. Could you share an example of a project to compare with?

  I just did a release build of egui in 35s, about the same as raddbg's release build. This includes compiling dependencies like wgpu, serde and about 290 other dependencies which add up to well over a million lines of code.

  Note I do have mold configured as my linker, which speeds things up significantly.

  By almostgotcaught 2025-06-2714:471 reply

  How many LOC is unreal? I'm trying to estimate whether making LLVM compatible with UNITY_BUILD would be worth the effort.

  EDIT: i signed up to get access to unreal so take a look at how they do unity builds and turns out they have their own build tool (not CMake) that orchestrates the build. so does anyone know (can someone comment) whether unity builds for them (unreal) means literally one file for literally all project sources files or if it's "higher-granularity" like UNITY_BUILD in CMake (i.e., single file per object).

  By Culonavirus 2025-06-2715:37

  At least 10M (from what I remember, maybe more now)

  By glandium 2025-06-271:30

  That is kind of surprising. The sqlite "unity" build, has about the same number of lines of C and takes a lot longer than that to compile.

  By Aurornis 2025-06-2620:50

  > makes me wonder why other languages like Rust and Swift can't just do something similar to achieve similar speeds.

  One of the primary features of Rust is the extensive compile-time checking. Monomorphization is also a complex operation, which is not exclusive to Rust.

  C compile times should be very fast because it's a relatively low-level language.

  On the grand scale of programming languages and their compile-time complexity, C code is closer to assembly language than modern languages like Rust or Swift.

  By 1vuio0pswjnm7 2025-06-274:08

  Alpha. Windows-only.

  https://codeload.github.com/EpicGamesExt/raddebugger/tar.gz/...

  By js2 2025-06-2620:352 reply

  "Just". Probably because there's a lot of complexity you're waving away. Almost nothing is ever simple as "just".

  By pixelpoet 2025-06-2620:491 reply

  At a previous company, we had a rule: whoever says "just" gets to implement it :)

  By forrestthewoods 2025-06-2622:04

  I wanted to ban “just” but your rule is better. Brilliant.

  By taylorallred 2025-06-2620:511 reply

  That "just" was too flippant. My bad. What I meant to convey is "hey, there's some fast compiling going on here and it wasn't that hard to pull off. Can we at least take a look at why that is and maybe do the same thing?".

  By steveklabnik 2025-06-2620:531 reply

  > "hey, there's some fast compiling going on here and it wasn't that hard to pull off. Can we at least take a look at why that is and maybe do the same thing?".

  Do you really believe that nobody over the course of Rust's lifetime has ever taken a look at C compilers and thought about if techniques they use could apply to the Rust compiler?

  By taylorallred 2025-06-2620:572 reply

  Of course not. But it wouldn't surprise me if nobody thought to use a unity build. (Maybe they did. Idk. I'm curious).

  By steveklabnik 2025-06-2621:06

  Rust and C have differences around compilation units: Rust's already tend to be much larger than C on average, because the entire crate (aka tree of modules) is the compilation unit in Rust, as opposed to the file-based (okay not if you're on some weird architecture) compilation unit of C.

  Unity builds are useful for C programs because they tend to reduce header processing overhead, whereas Rust does not have the preprocessor or header files at all.

  They also can help with reducing the number of object files (down to one from many), so that the linker has less work to do, this is already sort of done (though not to literally one) due to what I mentioned above.

  In general, the conventional advice is to do the exact opposite: breaking large Rust projects into more, smaller compilation units can help do less "spurious" rebuilding, so smaller changes have less overall impact.

  Basically, Rust's compile time issues lie elsewhere.

  By ameliaquining 2025-06-2621:11

  Can you explain why a unity build would help? Conventional wisdom is that Rust compilation is slow in part because it has too few translation units (one per crate, plus codegen units which only sometimes work), not too many.

  By troupo 2025-06-277:55

  There's also Jonathan Blow's jai where he routinely builds an entire game from scratch in a few seconds (hopefully public beta will be released by the end of this year).

  By TZubiri 2025-06-279:21

  I guess you can do that, but if for some reason you needed to compile separately, (suppose you sell the system to a third party to a client, and they need to modify module 1, module 2 and the main loop.) It would be pretty trivial to remove some #include "module3.c" lines and add some -o module3 options to the compiler. Right?

  I'm not sure what Rust or docker have to do with this basic issue, it just feels like young blood attempting 2020 solutions before exploring 1970 solutions.

  By rowanG077 2025-06-278:481 reply

  C hardly requires any high effort compile things. No templates, no generics, super simple types, no high level structures.

  By dgb23 2025-06-2711:44

  Are we seeing similar compilation speed when a Rust program doesn't use these types of features?

  By maxk42 2025-06-2621:31

  Rust is doing a lot more under the hood. C doesn't track variable lifetimes, ownership, types, generics, handle dependency management, or handle compile-time execution (beyond the limited language that is the pre-compiler). The rust compiler also makes intelligent (scary intelligent!) suggestions when you've made a mistake: it needs a lot of context to be able to do that.

  The rust compiler is actually pretty fast for all the work it's doing. It's just an absolutely insane amount of additional work. You shouldn't expect it to compile as fast as C.

• By rednafi 2025-06-2623:059 reply

  I’m glad that Go went the other way around: compilation speed over optimization.

  For the kind of work I do — writing servers, networking, and glue code — fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps. So I’ll gladly pay the price. Not having to deal with sigil soup is another plus point.

  I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness. Given the amount of networking and large - scale infrastructure software written in Go, I think they absolutely nailed it.

  But of course there are places where GC can’t be tolerated or correctness matters more than development speed. But I don’t work in that arena and am quite happy with the tradeoffs that Go made.

  By paldepind2 2025-06-2710:151 reply

  > I guess Google’s years of experience led to the conclusion that, for software development to scale, a simple type system, GC, and wicked fast compilation speed are more important than raw runtime throughput and semantic correctness.

  I'm a fan of Go, but I don't think it's the product of some awesome collective Google wisdom and experience. Had it been, I think they'd have come to the conclusion that statically eliminating null pointer exceptions was a worthwhile endeavor, just to mention one thing. Instead, I think it's just the product of some people at Google making a language they way they wanted to.

  By melodyogonna 2025-06-2714:111 reply

  But those people at Google were veteran researchers who wanted to make a language that could scale for Google's use cases; these things are well documented.

  For example, Ken Thompson has said his job at Google was just to find things he could make better.

  By nine_k 2025-06-2716:38

  They also built a language that can be learned in a weekend (well, now two) and is small enough for a fresh grad hire to learn at the job.

  Go has a very low barrier to entry, but also a relatively low ceiling. The proliferation of codegen tools for Go is a testament of its limited expressive power.

  It doesn't mean that Go didn't hit a sweet spot. For certain tasks, it very much did.

  By mike_hearn 2025-06-278:065 reply

  > fast compilation is absolutely paramount. At the same time, I want some type safety, but not the overly obnoxious kind that won’t let me sloppily prototype. Also, the GC helps

  Well, that point in the design space was already occupied by Java which also has extremely fast builds. Go exists primarily because the designers wanted to make a new programming language, as far as I can tell. It has some nice implementation aspects but it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java, which was the original target market they had in mind (i.e. Google servers). Scripting language users were in the market for a language that had a type system but not one that was too advanced, and which kept the scripting "feel" of very fast turnaround times. But not Java because that was old and unhip, and all the interesting intellectual space like writing libs/conf talks was camped on already.

  By loudmax 2025-06-2713:10

  As a system administrator, I vastly prefer to deploy Go programs over Java programs. Go programs are typically distributed as a single executable file with no reliance on external libraries. I can usually run `./program -h` and it tells me about all the flags.

  Java programs rely on the JVM, of which there are many variants. Run time options are often split into multiple XML files -- one file for logging, another to control the number of threads and so on. Checking for the running process using `ps | grep` yields some long line that wraps the terminal window, or doesn't fit neatly into columns shown in `htop` or `btop`.

  These complaints are mostly about conventions and idioms, not the languages themselves. I appreciate that the Java ecosystem is extremely powerful and flexible. It is possible to compile Java programs into standalone binaries, though I rarely see these in practice. Containers can mitigate the messiness, and that helps, up until the point when you need to debug some weird runtime issue.

  I wouldn't argue that people should stop programming in Java, as there are places where it really is the best choice. For example deep legacy codebases, or where you need the power of the JVM for dynamic runtime performance optimizations.

  There are a lot of places where Go is the best choice (eg. simple network services, CLI utilities), and in those cases, please, please deploy simple Go programs. Most of the time, developers will reach for whatever language they're most comfortable with.

  What I like most about Go is how convenient it is, by default. This makes a big difference.

  By rednafi 2025-06-2715:58

  Java absolutely does not fill in the niche that Go targeted. Even without OO theology, JVM applications are heavy and memory intensive. Plus the startup time of the VM alone is a show stopper for the type of work I do. Also yes, Java isn’t hip and you couldn’t pay me to write it anymore.

  By rsanheim 2025-06-278:461 reply

  Java still had slow startup and warmup time circa 2005-2007, on the order of 1-3 seconds for hello world and quite a bit more for real apps. That is horrendous for anything CLI based.

  And you left out classloader/classpath/JAR dependency hell, which was horrid circa late 90s/early 2000s...and I'm guessing was still a struggle when Go really started development. Especially at Google's scale.

  Don't get me wrong, Java has come a long way and is a fine language and the JVM is fantastic. But the java of 2025 is not the same as mid-to-late 2000s.

  By mike_hearn 2025-06-2712:421 reply

  Maybe so, although I don't recall it being that bad.

  But Go wasn't designed for CLI apps. It was designed for writing highly multi-threaded servers at Google, according to the designers, hence the focus on features like goroutines. And in that context startup time just doesn't matter. Startup time of servers at Google was (in that era) dominated by cluster scheduling, connecting to backends, loading reference data and so on. Nothing that a change in programming language would have fixed.

  Google didn't use classloader based frameworks so that also wasn't relevant.

  By frollogaston 2025-06-2716:56

  Golang is frequently used for CLIs, even if it wasn't designed for that exactly

  By frollogaston 2025-06-2716:371 reply

  Golang having solid n:m greenthreading day 1 was its big deal. Java has had no good way to do IO-heavy multitasking, leading to all those async/promise frameworks that jack up your code. I cannot even read the Java code we have at work. Java recently got virtual threads, but even if that fixes the problem, it'll be a while before things change to that. Python had the same problem before asyncio. This isn't even a niche thing, your typical web backend needs cooperative multitasking.

  I'm also not fond of any of the Golang syntax, especially not having exceptions. Or if you want explicit errors, fine, at least provide nice unwrap syntax like Rust does.

  By aaronblohowiak 2025-06-2718:20

  by FAR my biggest complaint about Golang was null instead of Option. could have been special cased like their slice and map and would have been so so so much better than nil checks imho. really, a big miss.

  By k__ 2025-06-2714:141 reply

  "it picked up its users mostly from the Python/Ruby/JS world rather than C/C++/Java"

  And with the increasing performance of Bun, it seems that Go is about to get a whooping by JS.

  (Which isn't really true, as most of the Bun perf comes from Zig, but they are targeting JS Devs.)

  By rednafi 2025-06-2716:041 reply

  Runtimes like Bun, Deno, or type systems like TypeScript don’t change the fact it’s still JS underneath — a crappily designed language that should’ve never left throwable frontend code.

  None of these runtimes make JS anywhere even close to single-threaded Go perf, let alone multithreaded (goroutine) perf.

  By frollogaston 2025-06-2716:451 reply

  JS is perfectly designed for what it does, frontend and non-CPU-intensive backend code. It's never going to reach singlethreaded Golang perf.

  By rednafi 2025-06-2718:141 reply

  JavaScript was never designed for non-browser usage. It’s the community’s unquenchable thirst to use the same language everywhere that brought us here.

  By frollogaston 2025-06-2718:29

  NodeJS "about" page states its case pretty succinctly, JS was a good fit for IO-bound concurrent backends because of the event loop. This was at a time when no other major language had a good answer for this, unless you count Erlang. JS later got nicer syntax like async/await, and 0 = "" weirdness aside, it was otherwise ok. Plenty of people using it didn't even come from the web frontend side, myself included.

  npm was also maybe the first default package manager that "just works," unlike Python or browser JS.

  By mark38848 2025-06-275:433 reply

  What are obnoxious types? Types either represent the data correctly or not. I think you can force types to shut up the compiler in any language including Haskell, Idris, PureScript...

  By Mawr 2025-06-276:461 reply

  I'd say you already get like 70% of the benefit of a type system with just the basic "you can't pass an int where string is expected". Being able to define your own types based on the basic ones, like "type Email string", so it's no longer possible to pass a "string" where "Email" is expected gets you to 80%. Add Result and Optional types (or arguably just sum types if you prefer) and you're at 95%. Anything more and you're pushing into diminishing returns.

  By hgomersall 2025-06-278:431 reply

  Well it depends what you're doing. 95% is like, just your opinion man. The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about. To be clear, such APIs are just as relevant internally to a project as externally if you want to design a system that is long term maintainable and robust and I would argue is the point when the type system starts to get really useful (rather than diminishing returns).

  By rednafi 2025-06-2716:13

  > The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about

  I need none of that guarantee and all of the compilation speed along with a language where juniors in my team can contribute quickly. Different problem space.

  By ratorx 2025-06-279:06

  This might work for the types you create, but what about all the code written in the language that expects the “proper” structure?

  > Types either represent the data or not

  This definitely required, but is only really the first step. Where types get really useful is when you need to change them later on. The key aspects here are how easily you can change them, and how much the language tooling can help.

  By throwawaymaths 2025-06-2713:33

  > Types either represent the data correctly or not.

  No. two types can represent the same payload, but one might be a simple structure, the other one could be three or twenty nested type template abstractions deep, and created by a proc macro so you can't chase down how it was made so easily.

  By liampulles 2025-06-2717:05

  As the story goes, a couple of Google developers designed Go while waiting for one of their C++ projects to compile.

  By frollogaston 2025-06-2716:311 reply

  Same but with Python and NodeJS cause I'm doing less performance-critical stuff. Dealing with type safety and slow builds would cost way more than it's worth.

  By rednafi 2025-06-2718:171 reply

  Python and NodeJS bring a whole lot of other problems. But yeah at a smaller scale these languages are faster to work with.

  At the same time, I have worked at places where people had to rewrite major parts of their backend in other languages because Python/Node was no longer sufficient.

  By frollogaston 2025-06-2718:34

  I'd have to see it, cause rewrites happen all the time. We had a system written in C++, then rewritten in Golang because C++ was supposedly not good enough, then rewritten back into C++.

  By galangalalgol 2025-06-2623:301 reply

  That is exactly what go was meant for and there is nothing better than picking the right tool for the job. The only foot gun I have seen people run into is parallelism with mutable shared state through channels can be subtly and exploitably wrong. I don't feel like most people use channels like that though? I use rust because that isn't the job I have. I usually have to cramb slow algorithms into slower hardware, and the problems are usually almost but not quite embarrassingly parallel.

  By bjackman 2025-06-278:521 reply

  I think a lot of the materials that the Go folks put out in the early days encourage a very channel-heavy style of programming that leads to extremely bad places.

  Nowadays the culture seems to have evolved a bit. I now go into high alert mode if I see a channel cross a function boundary or a goroutine that wasn't created via errgroup or similar.

  People also seem to have chilled out about the "share by communicating" thing. It's usually better to just use a mutex and I think people recognise that now.

  By rednafi 2025-06-2716:05

  This is true. I have been writing Go for years and still think channel is a bit too low level. It probably would've benefited from a different layer of abstraction.

  By silverwind 2025-06-279:37

  You can have the best of both worlds: A fast, but sloppy compiler and slow, but thorough checkers/linters. I think it's ideal that way, but rust seems to have chosen to needlessly combine both actions into one.

  By danielscrubs 2025-06-2710:362 reply

  One day I would like to just change pascals syntax a bit to be Pythonic and just blow the socks of junior and Go developers.

  By the_sleaze_ 2025-06-2715:09

  That's what they did to Erlang with Elixir and now there are a lot of people saying it's the Greatest Of All Time.

  I'd be interested in this project if you do decide to pursue it.

  By rednafi 2025-06-2716:08

  Sounds like the guy who wanted to write curl in a weekend. /s

  By ode 2025-06-270:472 reply

  Is Go still in heavy use at Google these days?

  By fsmv 2025-06-2713:431 reply

  Go has never been in heavy use at Google

  By melodyogonna 2025-06-2714:17

  Isn't it heavily used in Google Cloud?

  By hu3 2025-06-272:052 reply

  What would they use for networking if not Go?

  By homebrewer 2025-06-2711:241 reply

  Last time I paid any attention to Google's high level conference presenters (like Titus Winters), they almost didn't use Go at all. Judging by the sibling comment, this hasn't changed much. For some reason people are thinking that half of Google is written in Go at this point, when in reality if you listen to what they themselves are saying, it's 99% C++ and Java, with a tiny bit of Python and other languages where it makes sense.

  It's just a project from a few very talented people who happen to draw their salary from Google's coffers.

  By fireflash38 2025-06-2717:051 reply

  K8s isn't entirely in go?

  By frollogaston 2025-06-2718:41

  They don't really use K8S internally

  By surajrmal 2025-06-277:431 reply

  C++ and Java. Go is still used, but it's never caught up to the big two.

  By frollogaston 2025-06-2717:02

  And probably more Java than C++