LLVM 13's new pass manager improves Rust's compile times by up to 20%
twitter.com
twitter.com
Rusts zero cost abstractions aren't free at all, you pay with compile time, and they ain't cheap.
And it has real world implications too. Documentation could be vastly better if it could reference traits across package boundaries. With a "slow" compiler that is simply not feasible, the act of finding the relevant packages is NP hard in itself and multiplied with the compile time.
Could you clarify what you mean by this? As far as I know the vast, vast majority of rustc's compile time is spent on code generation (hence the massive speedup from an LLVM update), and everything else is relatively well optimized.
The issue is that it is quite common to have trait definitions in one create being used by other ones. Often this is even done when a single library gets too large e.g. tokio, one incentive for splitting being compile time.
However since analysis happens upwards the dependency tree, nodes further up the chain won't know what's below them and can't link to them.
You'd essentially have to do whole creates.io analysis, and while in theory that's feasible with static analysis, rusts type system is so powerful that you have to run a lot of the compiler to get meaningful "static" information, and thus would need a faster compiler/type checker.
(Ranty tangent ;) : I'm not sure if static analysis is even feasible with rusts massive complexity, and implementation defined behaviours. I mean nobody actually _knows_ if rust is save, it's just generally assumed. The closest thing to a formal proof that I know of is Oxide (https://arxiv.org/abs/1903.00982). The rust "commitee" tends to defer so many descisions into the future as to not accidentally paint themselves into a corner, that the spec is just the code and a bunch of thoughts in heads, RFCs, and github issues.
Hoare comes to mind: There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.)
So the "classes implementing this interface" which exists in the Java world, and which is really useful for exploring an API doesn't really exist for crates (at least not automatically).
It creates these Trait islands, where you can navigate to, but not away from.
I know that Rustdoc can do this; see SWC's docs for example: https://rustdoc.swc.rs/swc_ecma_visit/trait.Visit.html#imple...
I stumbled upon this because somebody had forgot to add the annotation, as these things happen when they're done manually.
The bigger issue is that the number of implementers for certain traits is going to be huge due to broad "forall" implementations. Instead of doing that, you can just list out actual implementations and condense the "forall" implementations into one node. In practice, I have found it pretty easy to figure out what code implements what interface, particularly if you build the docs for your own crate.
Turing complete type system + turing complete macro system => you gotta run (compile) the thing to see what it does or is (Rice's theorem).
For a language like Zig, which also has a turing complete compilation step, due to it's comptime sytem, this limitation also applies, but Zig mitigates this with insanely quick compile times. So for these multi project analysis to work you either need to have a very syntax heavy language (Java) or a fast compiler (Zig). Although the latter doesn't really have that strong of a type system in practice (though I think you could implement a datalog engine like rust has in comptime and do arcane type magic then ;) ).
If you compile the packages yourself you can get rustdoc to provide you with the correct links, but then we're back to the manual labor part which I'd like to remove in order to get eco-system-wide docs.
In regards to your point, using other backends other than LLVM and cargo having full support for binary libraries would solve a big part of the compilation time story.
In spite of its fame, C++ builds can be made relatively fast when using binary libraries, and even on its baby state, one can already notice some difference with modules workloads in Visual C++.
So I am still hopeful that Rust will improve its compilation story.
I've never seen this in the wild and to be honest, it seems massively inconvenient to write a library, create a C-compatible interface for it (meaning you lose out on most benefits of Rust's type system), and then write a wrapper for said C-like API to regain type/memory safety and abstraction power. The killer is that you lose the ability to use traits in the interface between, which idiomatic Rust heavily relies upon.
Those stability practices is what allows me to use Qt, VCL, MFC, .... without rebuilding the world every time I need to start something new with them.
It also allows several companies to sell C and C++ libraries, that wouldn't have done otherwise.