[HN Gopher] "Why is the Rust compiler so slow?"
___________________________________________________________________
"Why is the Rust compiler so slow?"
Author : Bogdanp
Score : 124 points
Date : 2025-06-26 19:29 UTC (3 hours ago)
(HTM) web link (sharnoff.io)
(TXT) w3m dump (sharnoff.io)
| ahartmetz wrote:
| That person seems to be confused. Installing a single, statically
| linked binary is clearly simpler than managing a container?!
| hu3 wrote:
| From the article, the goal was not to simplify, but rather to
| modernize:
|
| > So instead, I'd like to switch to deploying my website with
| containers (be it Docker, Kubernetes, or otherwise), matching
| the vast majority of software deployed any time in the last
| decade.
|
| Containers offer many benefits. To name some: process
| isolation, increased security, standardized logging and mature
| horizontal scalability.
| adastra22 wrote:
| So put the binary in the container. Why does it have to be
| compiled within the container?
| hu3 wrote:
| That is what they are doing. It's a 2 stage Dockerfile.
|
| First stage compiles the code. This is good for isolation
| and reproducibility.
|
| Second stage is a lightweight container to run the compiled
| binary.
|
| Why is the author being attacked (by multiple comments) for
| not making things simpler when that was not claimed that as
| the goal. They are modernizing it.
|
| Containers are good practice for CI/CD anyway.
| MobiusHorizons wrote:
| That's a reasonable deployment strategy, but a pretty
| terrible local development strategy
| AndrewDucker wrote:
| I'm not sure why "complicate things unnecessarily" is
| considered more modern.
|
| Don't do what you don't need to do.
| hu3 wrote:
| You realize the author is compiling a Rust webserver for
| a static website right?
|
| They are already long past the point of "complicate
| things unnecessarily".
|
| A simple Dockerfile pales in comparison.
| dwattttt wrote:
| Mightily resisting the urge to be flippant, but all of those
| benefits were achieved before Docker.
|
| Docker is a (the, in some areas) modern way to do it, but far
| from the only way.
| a3w wrote:
| Increased security compared to bare hardware, lower than VMs.
| Also, lower than Jails and RKT (Rocket) which seems to be
| dead.
| jerf wrote:
| Also strikes me as not fully understanding what exactly docker
| is doing. In reference to building everything in a docker
| image:
|
| "Unfortunately, this will rebuild everything from scratch
| whenever there's any change."
|
| In this situation, with only one person as the builder, with no
| need for CI or CD or whatever, there's nothing wrong with
| building locally with all the local conveniences and just
| slurping the result into a docker container. Double-check any
| settings that may accidentally add paths if the paths have
| anything that would bother you. (In my case it would merely
| reveal that, yes, someone with my username built it and they
| have a "src" directory... you can tell how worried I am about
| both those tidbits by the fact I just posted them publicly.)
|
| It's good for CI/CD in a professional setting to ensure that
| you can build a project from a hard drive, a magnetic needle,
| and a monkey trained to scratch a minimal kernel on to it, and
| boot strap from there, but personal projects don't need that.
| scuff3d wrote:
| Thank you! I got a couple minutes in and was confused as
| hell. There is no reason to do the builds in the container.
|
| Even at work, I have a few projects where we had to build a
| Java uber jar (all the dependencies bundled into one big far)
| and when we need it containerized we just copy the jar in.
|
| I honestly don't see much reason to do builds in the
| container unless there is some limitation in my CICD pipeline
| where I don't have access to necessary build tools.
| vorgol wrote:
| Exactly. I immediately thought of the grug brain dev when I
| read that.
| kelnos wrote:
| > _This is... not ideal._
|
| What? That's absolutely ideal! It's incredibly simple. I _wish_
| deployment processes were always that simple! Docker is not going
| to make your deployment process simpler than that.
|
| I did enjoy the deep dive into figuring out what was taking a
| long time when compiling.
| quectophoton wrote:
| One thing I like about Alpine Linux is how easy and dumbproof
| it is to make packages. It's not some wild beast like trying to
| create `.deb` files.
|
| If anyone out there is already _fully_ committed to using only
| Alpine Linux, I 'd recommend trying creating native packages at
| least once.
| tmtvl wrote:
| Just set up a build server and have your docker containers fetch
| prebuilt binaries from that?
| adastra22 wrote:
| As a former C++ developer, claims that rust compilation is slow
| leave me scratching my head.
| shadowgovt wrote:
| I thorougly enjoy all the work on encapsulation and reducing
| the steps of compilation to compile, then link that C does...
| Only to have C++ come along and undo almost all of it through
| the simple expedient of requiring templates for everything.
|
| Oops, changed one template in one header. And that impacts....
| 98% of my code.
| eikenberry wrote:
| Which is one of the reasons why Rust is considered to be
| targeting C++'s developers. C++ devs already have the Stockholm
| syndrome needed to tolerate the tooling.
| MyOutfitIsVague wrote:
| Rust's compilation is slow, but the tooling is just about the
| best that any programming language has.
| zozbot234 wrote:
| > Stockholm syndrome
|
| A.k.a. "Remember the Vasa!"
| https://news.ycombinator.com/item?id=17172057
| MobiusHorizons wrote:
| Things can still be slow in absolute terms without being as
| slow as C++. The issues with compiling C++ are incredibly well
| understood and documented. It is one of the worst languages on
| earth for compile times. Rust doesn't share those language
| level issues, so the expectations are understandably higher.
| int_19h wrote:
| But it does share some of those issues. Specifically, while
| Rust generics aren't as unstructured as C++ templates, the
| main burden is actually from compiling all those tiny
| instantiations, and Rust monomorphization has the same exact
| problem responsible for the bulk of its compile times.
| ecshafer wrote:
| The Rust compiler is slow. But if you want more features from
| your compiler you need to have a slower compiler, there isn't a
| way around that. However this blog post doesn't really seem to be
| around that and more an annoyance in how they deploy binaries.
| MangoToupe wrote:
| I don't really consider it to be slow at all. It seems about as
| performant as any other language this complexity, and it's far
| faster than the 15 minute C++ and Scala build times I'd place in
| the same category.
| randomNumber7 wrote:
| When C++ templates are turing complete is it pointless to
| complain about the compile times without considering the actual
| code :)
| namibj wrote:
| Incremental compilation good. If you want, freeze the initial
| incremental cache after a single fresh build to use for
| building/deploying updates, to mitigate the risk of intermediate
| states gradually corrupting the cache.
|
| Works great with docker: upon new compiler version or major
| website update, rebuild the layer with the incremental cache;
| otherwise just run from the snapshot and build newest website
| update version/state, and upload/deploy the resulting static
| binary. Just set so that mere code changes won't force rebuilding
| the layer that caches/materializes the fresh clean build's
| incremental compilation cache.
| b0a04gl wrote:
| rust prioritises build-time correctness: no runtime linker or no
| dynamic deps. all checks (types, traits, ownership) happen before
| execution. this makes builds sensitive to upstream changes.
| docker uses content-hash layers, so small context edits
| invalidate caches. without careful layer ordering, rust gets
| fully recompiled on every change.
| RS-232 wrote:
| Is there an equivalent of ninja for rust yet?
| steveklabnik wrote:
| It depends on what you mean by 'equivalent of ninja.'
|
| Cargo is the standard build system for Rust projects, though
| some users use other ones. (And some build those on top of
| Cargo too.)
| senderista wrote:
| WRT compilation efficiency, the C/C++ model of compiling separate
| translation units in parallel seems like an advance over the Rust
| model (but obviously forecloses opportunities for whole-program
| optimization).
| woodruffw wrote:
| Rust can and does compile separate translation units in
| parallel; it's just that the translation unit is (roughly) a
| crate instead of a single C or C++ source file.
| EnPissant wrote:
| And even for crates, Rust has incremental compilation.
| ic_fly2 wrote:
| This is such a weird cannon on sparrows approach.
|
| The local builds are fast, why would you rebuild docker for small
| changes?
|
| Also why is a personal page so much rust and so many
| dependencies. For a larger project with more complex stuff you'd
| have a test suite that takes time too. Run both in parallel in
| your CI and call it a day.
| taylorallred wrote:
| 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.
| js2 wrote:
| "Just". Probably because there's a lot of complexity you're
| waving away. Almost nothing is ever simple as "just".
| pixelpoet wrote:
| At a previous company, we had a rule: whoever says "just"
| gets to implement it :)
| forrestthewoods wrote:
| I wanted to ban "just" but your rule is better. Brilliant.
| taylorallred wrote:
| 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?".
| steveklabnik wrote:
| > "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?
| taylorallred wrote:
| Of course not. But it wouldn't surprise me if nobody
| thought to use a unity build. (Maybe they did. Idk. I'm
| curious).
| steveklabnik wrote:
| 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.
| ameliaquining wrote:
| 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.
| tptacek wrote:
| 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.
| lordofgibbons wrote:
| 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.
| ChadNauseam wrote:
| 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.
| rstuart4133 wrote:
| > 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.
| tedunangst wrote:
| 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.
| duped wrote:
| 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.
| cogman10 wrote:
| 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.
| cherryteastain wrote:
| 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.
| Zardoz84 wrote:
| 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.
| dhosek wrote:
| 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.
| drivebyhooting wrote:
| 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.
| steveklabnik wrote:
| 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.
| taylorallred wrote:
| 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.
| Thiez wrote:
| 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.
| vbezhenar wrote:
| Is it possible to generate less junk? Sounds like compiler
| developers took a shortcuts, which could be improved over
| time.
| rcxdude wrote:
| 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.
| zozbot234 wrote:
| 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.)
| jvanderbot wrote:
| 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).
| Aurornis wrote:
| > 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.
| ceronman wrote:
| 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.
| 90s_dev wrote:
| I can't help but think the borrow checker alone would slow
| this down by at least 1 or 2 orders of magnitude.
| steveklabnik wrote:
| Your intuition would be wrong: the borrow checker does not
| take much time at all.
| FridgeSeal wrote:
| 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.
| tomjakubowski wrote:
| 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.
| taylorallred wrote:
| 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.
| maxk42 wrote:
| 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.
| vbezhenar wrote:
| 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.
| taylorallred wrote:
| 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.
| kccqzy wrote:
| 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.
| vbezhenar wrote:
| 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.
| charcircuit wrote:
| Why doesn't the Rust ecosystem optimize around compile time? It
| seems a lot of these frameworks and libraries encourage doing
| things which are slow to compile.
| steveklabnik wrote:
| The ecosystem is vast, and different people have different
| priorities. Simple as that.
| nicoburns wrote:
| It's starting to, but a lot of people are using Rust because
| they need (or want) the best possible runtime performance, so
| that tends to be prioritised a lot of the time.
| aappleby wrote:
| you had a functional and minimal deployment process (compile copy
| restart) and now you have...
| OtomotO wrote:
| It's not. It's just doing way more work than many other
| compilers, due to a sane type system.
|
| Personally I don't care anymore, since I do hotpatching:
|
| https://lib.rs/crates/subsecond
|
| Zig is faster, but then again, Zig isn't memory save, so
| personally I don't care. It's an impressive language, I love the
| syntax, the simplicity. But I don't trust myself to keep all the
| memory relevant invariants in my head anymore as I used to do
| many years ago. So Zig isn't for me. Simply not the target
| audience.
| o11c wrote:
| TL;DR `async` considered harmful.
|
| For all the C++ laughing in this thread, there's really only one
| thing that makes C++ slow - non-`extern` templates - and C++
| gives you a lot more space to speed them up than Rust does.
| gz09 wrote:
| Unfortunately, removing debug symbols in most cases isn't a
| good/useful option
| magackame wrote:
| What "most" cases are you thinking of? Also don't forget that a
| binary that in release weights 10 MB, when compiled with debug
| symbols can weight 300 MB, which is way less practical to
| distribute.
| kenoath69 wrote:
| Where is Cranelift mentioned
|
| My 2c on this is nearly ditching rust for game development due to
| the compile times, in digging it turned out that LLVM is very
| slow regardless of opt level. Indeed it's what the Jai devs have
| been saying.
|
| So Cranelift might be relevant for OP, I will shill it endlessly,
| took my game from 16 seconds to 4 seconds. Incredible work
| Cranelift team.
| jiehong wrote:
| I think that's what zig team is also doing to allow very fast
| build times: remove LLVM.
| norman784 wrote:
| Yes, Zig author commented[0] that a while ago
|
| [0] https://news.ycombinator.com/item?id=44390972
| norman784 wrote:
| Nice, I checked a while ago and was no support for macOS
| aarch64, but seems that now it is supported.
| lll-o-lll wrote:
| Wait. You were going to ditch rust because of _16 second_ build
| times?
| smcleod wrote:
| I've got to say when I come across an open source project and
| realise it's in rust I flinch a bit know how incredibly slow the
| build process is. It's certainly been one of the deterrents to
| learning it.
| juped wrote:
| I don't think rustc is that slow. It's usually cargo/the dozens
| of crates that make it take a long time, even if you've set up a
| cache and rustc is doing nothing but hitting the cache.
| Devasta wrote:
| Slow compile times are a feature, get to make a cuppa.
| zozbot234 wrote:
| > Slow compile times are a feature
|
| xkcd is always relevant: https://xkcd.com/303/
| randomNumber7 wrote:
| On the other hand you get mentally insane if you try to work
| in a way that you do s.th. usefull during the 5-10 min
| compile times you often have with C++ projects.
|
| When I had to deal with this I would just open the newspaper
| and read an article in front of my boss.
| duped wrote:
| A lot of people are replying to the title instead of the article.
|
| > To get your Rust program in a container, the typical approach
| you might find would be something like:
|
| If you have `cargo build --target x86_64-unknown-linux-musl` in
| your build process you do not need to do this anywhere in your
| Dockerfile. You should compile and copy into /sbin or something.
|
| If you really want to build in a docker image I would suggest
| using `cargo --target-dir=/target ...` and then run with `docker
| run --mount type-bind,...` and then copy out of the bind mount
| into /bin or wherever.
| cratermoon wrote:
| Some code that can make Rust compilation pathologically slow is
| complex const expressions. Because the compiler can evaluate a
| subset of expressions at compile time[1], a complex expression
| can take an unbounded amount of time to evaluate. The long-
| running-const-eval will by default abort the compilation if the
| evaluation takes too long.
|
| 1 https://doc.rust-lang.org/reference/const_eval.html
| ozgrakkurt wrote:
| Rust compiler is very very fast but language has too many
| features.
|
| The slowness is because everyone has to write code with generics
| and macros in Java Enterprise style in order to show they are
| smart with rust.
|
| This is really sad to see but most libraries abuse codegen
| features really hard.
|
| You have to write a lot of things manually if you want fast
| compilation in rust.
|
| Compilation speed of code just doesn't seem to be a priority in
| general with the community.
___________________________________________________________________
(page generated 2025-06-26 23:00 UTC)