To the compiler folks: Can a language with memory safety and speed of rust be made with the compilation speed of Go? I'm just curios. I have no idea about this
This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language.
In theory, with enough time and resources, Rust could see an efficient compiler, but this is something that can't be predicted, as it depends on its future success, or, to be clear, the backing it will have.
In practice, the Rust Cranelift backend could provide enough speed (for debug builds) that compilation times won't be slow anymore.
Something to consider is also that compilation is a tradeoff between compiling speed and runtime speed (Golang's favoring compiling speed), so one can't have both ends of the the spectrum at the same time.
> and in particular, that they are entirely inherent to the language.
But... this is true. The design of the language is biased to make slow compiling across the full pipeline.
Is possible to get into a shout contest about this :), so just look at what Pascal(Delphi) do and how absurdly fast it is, despite the fact is still a "batch compiler".
So in the presence of pascal (that is even more complex than Go, to be a really close to C/C++ in capabilities) is clear that Rust is MADE to be slow.
And to the point, I used more than +12 languages already, super popular things like this:
I think the most accurate way to say it is that, while Rust compile times are not inherently slow, Rust has in most cases where where a desirable feature was at odds with compile times decided to sacrifice it. So while it is not inherently slow to compile, it was not designed to be easy to compile quickly either.
I've profiled the compilation of a small but not trivially written crate (~5k lines, with macros, many UTs etc.), and the vast majority of the time (78%+) was actually spent on the LLVM side (see numbers in a post above).
In other words the Rust language design (as opposed to the compiler implementation) was not the bottleneck in the compilation time; the factors were well-known issues of the Rust compiler implementation: 1. it relies on LLVM, which is slow 2. it generates slow to compile IR code.
This is correct, and part of "the design of Rust make it slow". The use of LLVM is part of the design, and how use it is too.
Is like the people on the C-like languages (with the exception of Go) can't resits the temptation of make languages slow to use (yet, spend absurd amount of time on produce good binaries).
Is not that I not grateful of how good Rust/LLVM compiled binaries perform, in fact, is one of the big reasons I use Rust! but is kind of weird(?)/funny(?) that the languages itself are so slow.
I think is cultural. People on that side of the fence are so used to use sub-optimal tooling that don't mind too much to use another tool on the same feels. And if it provide "10%" increase on performance, get so happy, because is against the old, not agains the best.
> The use of LLVM is part of the design, and how use it is too.
This is false. There is the Rust Cranelift backend in development, which is actually usable already (depending on the project). Having a fast compiler for debug builds and a slow one for release ones is a setup that I can imagine being the future of Rust.
I've just built a project of mine and it took exactly half of the time to compile, when compared to the standard compiler.
It's actually crazy that they're even developing a JIT (although it requires dynamic libraries as dependencies, so its usage is and possibly will be limited).
Delphi compile times are very slow on a reasonable 10 man year project. It doesn’t help the the IDE (and compiler?) was still 32 bit last year (even though it can compile 64 bit apps). Apart from some other toxic problems!
Parent poster is referring to a full build, which are not really representative of a daily workflow. Incremental builds, in particular of a project where the large part of a full build is on external crates (which don't need to be recompiled) are much faster.
I can't test on an old machine, but modifying the project code and performing an incremental (standard) build, takes around 5 seconds on a modern machine.
> which are not really representative of a daily workflow.
Only on Rust :). This is a "hack" that must be done to make Rust viable. In Delphi, a full compile is so fast that it's pointless to make it incremental.
The biggest issue is lack of support for binary crates in cargo, so instead of pkg-config, you need to build the whole world when starting a new project.
So imagine being on the waiting lobby of an airport, reading about a cool Rust project and then trying to check it on your laptop. With luck it is finished compiling before being called for boarding.
> This question inappropriately assumes that the Rust compiling design and performance are fixed to what is today, and in particular, that they are entirely inherent to the language.
Either that, or: it asks exactly that question rather than assumes that slow compilation is intrinsic to memory safety etc. But yes, there might be an implicit premise about some part of the Rust design contributing to slow compilation times.
The two passes above are arbitrarily picked, but anything other than the top three takes cumulatively 22% of the time.
Based on this, the Rust IR generation and LLVM are the bottleneck. I'd be interested in the opinion of somebody knowledgeable, since there may be non-obvious mistakes in the above reasoning.
I'm not inappropriately assuming that design is fixed. I just wanted to know if it's possible. I'm not complaining about rust cause I don't know much than the basics also I have not worked with statically compiled languages.
Safety doesn't cost that much in compilation time. `cargo check` performs full type-checking and borrow checking, and it's reasonably fast already.
Rust's performance depends very much on optimizations, mainly LLVM. It could be faster if you were willing to accept less optimized code, or change coding style to use fewer libraries and fewer abstractions. But if you want the same speed without any compromises, then I don't see any way around that.
Yes, of course is possible. This is a question with open definitions, there are dynamic languages with memory safety that can be as fast as Rust (or native code in general) in some cases. Also you could say that Go itself is mostly memory and can be as fast as Rust.
