Actually C/C++ compilers are shooting themselves in the foot performance-wise with the header mechanism, so writing a compiler that's faster than C/C++ is not that hard. Not sure what the reasons of the Rust compiler being (even more?) slow are, maybe the ability to easily interface with C code has something to do with it?

Last time I checked [1], the Rust part of the Rust compiler is not the slowest. LLVM spends a lot of time processing relatively poor IR code which the Rust compiler emits.

Rust compilation is not intrinsically slow; better IR and more incremental compilation can and will improve it. Incremental compilation (only changed files, not crates) is 7 years in making though.

[1]: https://prev.rust-lang.org/en-US/faq.html#why-is-rustc-slow

Thanks for that link! That sounds like the really major factor is the decision to recompile the entire crate when a file in the crate changes. I'm sure that made sense at the time ;) And, if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision - incremental compilation might have its edge cases and pitfalls, but other compilers are doing it just fine, so it shouldn't be rocket science?

Other reasons:

- suboptimal LLVM IR code, as you mentioned, and other tech debt

- the preferred strategy of monomorphising generics is fast at runtime, but slow to compile, using trait objects is faster

- the complex type system of course also plays a part

- LLVM itself is of course not optimized for Rust

> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision

I'm not sure it was a "bad decision" if it was something that can be addressed after the fact and allowed them to ship working software more quickly.

The vast majority of the popular projects I am aware of have this kind of technical debt, likely due to survivorship bias. Project teams that refuse to take on technical debt are rarely successful enough to become popular.

> if slow compilation is such a pain point, I wonder why it takes seven years and counting to fix this bad decision

Maybe we are giving Rust developers computers that are too fast. ;-)

OTOH, it's always wise to design for the future, so it also makes sense to give Rust developers beefy server grade hardware so they can play with SIMD pipelines and all those extra cores and threads, because that's what workstations will be a couple years from now.

In this case I really have to nitpick about the use of "C/C++": This specific problem really only exists in C++, because there it is common to put implementation code into headers via inline and template functions (worst example is the C++ stdlib), while in C you only put declarations into headers, and just parsing a few hundred lines of struct and function declarations won't blow up your build times (while just including a common C++ stdlib header like <vector> pulls in tens of thousands of lines of tricky template code.

In VC++ "import std", which imports the whole C++ standard library, is faster than just doing "#include <iostreams>".

It is only a matter of time, until GCC and clang finally catch up.

According to Wikipedia, both have support for precompiled headers: https://en.m.wikipedia.org/wiki/Precompiled_header

Shouldn't this be enough? Or does it require explicitly including the precompiled header whereas VC++ has magic to make that transparent?

C++20 modules and pre-compiler headers aren't the same thing in terms of technology.

I think it's more related to the grammatical complexity of the language than to safety itself

(Same reason why C with typedefs is slower to compile than plain C, why C++ is slower, etc)

(that and cargo dependencies, etc - also C compilers have some +30yrs of optimizations)

I've seen some Rust programs that look nice, but in the kernel, the code ends up making perl'ls propensity for line noise look competitive. I'm sure some of that is the need to shovel between languages, but it does make you wonder if the entire effort is a little misguided.

A full Rust kernel might be neat. A compromised Rust driver inside of a C kernel is never going to be the default choice.

Most of the code committed to the kernel is infrastructure for C<->Rust interoperability. It's the least readable of it all, and as fun to work on as watching paint dry.

The actual driver code is pretty readable, see https://lwn.net/Articles/863459/.

>A full Rust kernel might be neat.

May I interest you in Redox? https://www.redox-os.org/

If "embedded OS" counts as "full Rust kernel", you may want to check out https://hubris.oxide.computer/

Obviously very different than Linux.

More complexe languages are faster to compile. The issue is mostly the implementation. It could, should and will be better but it takes time.

As others have pointed out most of the performance hit is in the optimization of the relatively verbose IR code the Rust compiler sends to LLVM, not the Rust compiler itself.

There's been multiple passes at making the Rust compiler faster. It'll happen. There's a GCC-based Rust implementation in the works too.

Nim is also memory safe and the compilation is really fast.

> No, Nim doesn't have stronger or weaker safety guarantees than Rust [1]. Rust's memory safety is nothing new, either. It is mostly that some older languages like C/C++ are the exceptions in not being memory-safe. There is nothing new or magical about memory safety. LISP was already memory-safe when it was invented in 1958. The only question is how much performance you need to trade away for it (the value is never zero for non-trivial programs, but can vary greatly, depending on whether the language was designed with it in mind or not).

> The main difference between Rust and other languages is that it does some more (but not all [2]) safety checks at compile time rather than at runtime. It also allows you to avoid GC, but does not provide you any memory safety over GC. Rust's borrow checker allows you to statically prove that references are live [3]; a GC simply avoids deallocating any memory that has a live reference to it (on the other hand, a GC can ensure that references remain live even where this is hard or impossible to prove statically). The end result is the same with respect to memory safety (the reason some people want to avoid GC is for performance reasons, not memory safety).

https://forum.nim-lang.org/t/1961

That's outdated information from 2016. Now Nim uses ARC/ORC. ARC implements memory management at compile time like Rust and it's still very fast at compiling.

Cool, I wasn't aware, thanks. https://nim-lang.org/blog/2020/10/15/introduction-to-arc-orc...

> The main difference between ARC and Nim GCs is that ARC is fully deterministic - the compiler automatically injects destructors when it deems that some variable (a string, sequence, reference, or something else) is no longer needed. In this sense, it’s similar to C++ with its destructors (RAII). To illustrate, we can use Nim’s expandArc introspection (will be available in Nim 1.4).

> This shows one of the main ARC features: scope-based memory management. A scope is a separate region of code in the program. Scope-based MM means that the compiler will automatically insert destructor calls for any variables which need a destructor after the scope ends. Many Nim constructs introduce new scopes: procs, funcs, converters, methods, block statements and expressions, for and while loops, etc.

> ARC also has so-called hooks - special procedures that can be defined for types to override the default compiler behaviour when destroying/moving/copying the variable. These are particularly useful when you want to make custom semantics for your types, deal with low-level operations involving pointers, or do FFI.

Really. I did not know that. so, can I use today Nim but with a Rust-like ARC?

--gc:arc/--mm:arc has been around for a couple years (as per that blog post link) and fairly stable for >1 year. It is slated to become the default automatic memory management strategy in Nim-2.0. The hope is to release 2.0 this year.

You can always make it your own personal default with older versions (e.g. nim-1.6), by editing your $HOME/.config/nim/nim.cfg to say so or doing similar on per project/file basis.

Rust doesn't have ARC like Nim or Swift. (And Nim and Swift's are a bit different here but closer to each other than anything that exists in Rust.)

While it's true that memory safety has been done in a lot of languages for a long time this overstates the point. Doing memory safety at compile time is an important change that allows replacing C/C++ in a lot more situations. In the benchmarks game for example Rust has been the only language capable of breaking into the C/C++ league, even after very many years of investment into Java for example.

Rust also uses the same mechanisms to get compile time thread safety with full memory sharing between threads. Does any other language that doesn't have a global lock, throwing away most of the advantage, have that? There are actual new and interesting advantages to the compile time ownership model.

> Rust also uses the same mechanisms to get compile time thread safety with full memory sharing between threads.

A minor advantage on the age of microservices and OS IPC to shared external resources.

Sendable doesn't apply when those threads are accessing shared external resources.

Benchmarks vary wildly but Haskell tends to perform in the same realm as C++, fwiw. It's GC'd, uses immutable data structures, and uses a green threading model that can be easily exploited by user code for extreme levels of parallelism with full memory safety. It's even possible to hold mutable references and share them across threads safely with STM (not a global lock).

If you want fully lock-free it might be possible to prove that with extensions like Liquid Haskell, via Linear types, and is definitely easier to prove with a theorem prover than it is, generally, for C++ code. Not sure about Rust though I realize quite a lot of its moving parts have already been formalized which is super cool.

There are reasons for using Rust but it's not the only game in town. And GC doesn't automatically mean pessimistic performance.

Anything you can statically prove at compile time is interest you don't have to pay at run time.

Rust is a huge, huge win for that reason. It allows for code written in a Lisp/OCaml/Nim style that's memory safe without any additional overhead.

Not on my laptop it wasn't. I wonder if someone's done a performance comparison.

There are languages with similar type safety, which are faster, because the authors have placed focus on having several ways available to compile the code.

Ada, Delphi, OCaml, C#/F# (.NET Native / Native AOT), D, Nim,...

I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?), but c# is not as memory safe as rust.

The only memory safety that C# lacks in comparisaion with Rust is one special case, data races for in-process data.

For everything else regarding concurrent access to shared data out of process, they are on the same foot.

Ada didn't took off, because of several reasons, price of compilers, on UNIX it was an additional SKU on top of the respective developers SDK that already offered C and C++ in the box, 1980's mainstream hardware wasn't able to cope with it, most OS vendors outside UNIX decide to migrate from their toolchains into C and C++, so again additional money on top of the OS SDK.

>> I will admit I never understood why Ada never took off (is it only because of the tooling being propertiary for a long time?)

Early Ada compilers had expensive licensing and required expensive hardware to run.

By the time GNAT was added to GCC, C++ had already taken over most of the spaces that were not Ada exclusive (meaning safety critical / defense / aerospace niches where either Ada was once mandated or has thrived in despite the original high costs).

Does C# not have a GC? I thought that would immediately disqualify it for kernel work.

For Linux yes, for those that aren't blinded by anti-GC religion, no.

https://www.wildernesslabs.co/

Anti GC isn't a religion. GC is a performance cliff in some cases.

It is certainly a religion, as most people that advocate against it hardly ever learned to use a profiler, or bothered to learn that not all GC languages are alike, and many of them offer the same capabilities like C and C++ for low level coding.

It's not, collaborating on a C# game engine and what I've seen is basically a lot of skirting around GC, because it's impact shows up in profiler. It has gotten to a point arrays and stack alloc are prefered over List and HashSet were basically forbidden in the hottest path.

Except most of C# ecosystem relies on classes and GC. A lot of these problems are caused by overuse of GC-ed classes, and their ease of use.

Don't confuse Unity runtime with C#, specially since it lacks all the nice features post C# 7.

C and C++ aren't immune to heap abuse as well.

You do on C# just like on them, think about data structures, and avoid heap during render loop

Did I mention Unity? It was a independently developed engine. The engine is in C# 10.

They still ran into limitations where basically "This would be a lot easier if we didn't have GC".

My take on this is a little different than the comments previous. I tend to side with your position over the default position the GC is workable as a languages base assumption. I think the problem really is an expressiveness issue. In a language conceptualized to have memory managed either manually or GC’d and that said choice should be easily made (i.e. it should not take much work to designate some code path as utilizing a GC’d strategy), but I would say for implementation and performance you would give up being able to easily abstract over the memory strategy.

tr;dl — I’d really prefer the option to determine when I’d like GC, as opposed to dodging the collector to avoid performance hits, hot code can default to manual. Probably not a realistic ask, but it could work.

> I’d really prefer the option to determine when I’d like GC, as opposed to dodging the collector to avoid performance hits

Fair enough. If SS14 used D maybe they wouldn't have these problems.

D and early Rust (pre 0.2, like alpha alpha) had that. Problem is you split your community in two. You get a version of "What GC-color is your function/lib?".

It's a tradeoff for some domains - allow no GC bypass you're going to run into nigh insurmountable performance cliff.

Allow GC as opt-in and you run into issue of splitting your APIs in two.

Well that is what everyone is actually using nowadays when they state they are doing a game in C#.

"This would be a lot easier if we didn't have malloc()/free()", basically.

In any case Sony, Nintendo and Microsoft have been doing graphics stuff with C# for their platforms, although they could have kept being pure C++.

Also we shouldn't silo ourselves into only C# as discussion point, Go, D, Nim, Swift, Eiffel are also possible examples.

> "This would be a lot easier if we didn't have malloc()/free()", basically.

Well, not really. It's just some libraries like YamlDotNet copy waaaay more than needed and it shows in serialization. They mostly minimized calling YamlDotNet, but true solution would be a zero copy parser.

Other issue was HashSet operation like Clear had huge impact. Think they replaced those with arrays.

Third issue was something about flecs and archetype ECS. I don't know if it was a jest, but they mentioned changing GC layout or rewriting GC.

Points is, they now face a steep performance cliff. The only way out of it is through sheer effort.

So no, it's not anti-GC religion. Some domains and GC really badly mix.

For Linux kernel work.

https://www.microsoft.com/en-us/research/project/singularity

https://en.wikipedia.org/wiki/SharpOS

It does have GC but that is not the point being made.

I believe the point the author is making is that other languages provide better safety than C and have faster compile times than Rust, therefore Rust should be able to improve its compile times.

If those languages achieve their memory safety at runtime, like C# does with GC, then that becomes relevant to the point of the compile time performance. The C# compiler has to do less as that complexity has been pushed elsewhere with different tradeoffs.

Rust safety with runtime dependencies, Vec bounds checking, Arc and Rc datatypes.

Ada with SPARK 2014 formal proofs, for your other part of the remark.

GC is not a roadblock for OS kernel work. Smalltalk is itself an OS and had GC from the start. IBM's i (the descendant of OS/400) most likely has GC as part of its kernel. Lisp machines had hardware-assisted GC.

What you may want to try to avoid is complex and non-deterministic GC, which makes it harder to reason about.

What's the old adage? It's easier to make a correct thing fast than it is to make a fast thing correct.