9 ms·

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

augusto-moura 6y ago
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.
MrBuddyCasino 6y ago
For a language to reach the compilation speed of Go, it must have been designed with that goal in mind from the start. The best Rust can hope for is to make it largely irrelevant during dev by doing fine grained incremental compilation.
pizza234 6y ago
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. There are a few interesting reasons why Rust compilation time is slow and Go's is fast. Here's a summary of the first: https://pingcap.com/blog/reasons-rust-compiles-slowly https://pingcap.com/blog/reasons-rust-compiles-slowly. 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.
- mamcx 6y ago
  > 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: https://endler.dev/2020/rust-compile-times/ https://endler.dev/2020/rust-compile-times/ NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.
  - ATsch 6y ago
    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.
  - robocat 6y ago
    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!
    - pjmlp 6y ago
      This toy project https://github.com/pjmlp/gwc-rs https://github.com/pjmlp/gwc-rs takes 16 minutes to compile from scratch on a core 2 machine, with 8GB and a SSD. The original one in Gtkmm, takes around 5 minutes in release mode, if that much.
      - vijaybritto 6y ago
        Hmm that looks slow. Can rust support binary patching like zig or is it impossible with the current design?
- Privacy846 6y ago
  > 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.
  - pizza234 6y ago
    Well, I've just profiled the incremental compilation of a 4.8k lines Rust project (using the `self-profile` option); top three offenders: - LLVM_module_codegen_emit_obj: 47% of the time - LLVM_passes: 16% - codegen_module: 15% Sample of Rust-specific passes: - MIR_borrow_checking: 0.2% - resolve_lifetimes: 0.0% 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.
    - steveklabnik 6y ago
      This is a pretty common shape of the measurement, yes.
      - vijaybritto 6y ago
        Hello Steve, I hope you're well and baking more breads for Christmas!
        steveklabnik 6y ago
        Thanks! I am working on two loaves right now, haha!
- vijaybritto 6y ago
  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.
pjmlp 6y ago
Yes, example Ada/SPARK, Eiffel, Delphi, OCaml, Haskell, D. It is a matter of tooling, and where to spend development resources.
- sanxiyn 6y ago
  Isn't Haskell (GHC in particular) extremely slow to compile? In fact, I think GHC is the slowest compiler I used.
  - pjmlp 6y ago
    Except when one is developing, GHCi is the way to go.
pornel 6y ago
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.

augusto-moura 6y ago

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.

MrBuddyCasino 6y ago

For a language to reach the compilation speed of Go, it must have been designed with that goal in mind from the start. The best Rust can hope for is to make it largely irrelevant during dev by doing fine grained incremental compilation.

pizza234 6y ago

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. There are a few interesting reasons why Rust compilation time is slow and Go's is fast. Here's a summary of the first: https://pingcap.com/blog/reasons-rust-compiles-slowly https://pingcap.com/blog/reasons-rust-compiles-slowly. 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.

mamcx 6y ago
> 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: https://endler.dev/2020/rust-compile-times/ https://endler.dev/2020/rust-compile-times/ NOT exist for Delphi. The "how make delphi compile fast" is to just use delphi. It will compile fast.
- ATsch 6y ago
  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.
- robocat 6y ago
  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!
  - pjmlp 6y ago
    This toy project https://github.com/pjmlp/gwc-rs https://github.com/pjmlp/gwc-rs takes 16 minutes to compile from scratch on a core 2 machine, with 8GB and a SSD. The original one in Gtkmm, takes around 5 minutes in release mode, if that much.
    - vijaybritto 6y ago
      Hmm that looks slow. Can rust support binary patching like zig or is it impossible with the current design?
Privacy846 6y ago
> 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.
- pizza234 6y ago
  Well, I've just profiled the incremental compilation of a 4.8k lines Rust project (using the `self-profile` option); top three offenders: - LLVM_module_codegen_emit_obj: 47% of the time - LLVM_passes: 16% - codegen_module: 15% Sample of Rust-specific passes: - MIR_borrow_checking: 0.2% - resolve_lifetimes: 0.0% 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.
  - steveklabnik 6y ago
    This is a pretty common shape of the measurement, yes.
    - vijaybritto 6y ago
      Hello Steve, I hope you're well and baking more breads for Christmas!
      - steveklabnik 6y ago
        Thanks! I am working on two loaves right now, haha!
vijaybritto 6y ago
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.

pjmlp 6y ago

Yes, example Ada/SPARK, Eiffel, Delphi, OCaml, Haskell, D. It is a matter of tooling, and where to spend development resources.

sanxiyn 6y ago
Isn't Haskell (GHC in particular) extremely slow to compile? In fact, I think GHC is the slowest compiler I used.
- pjmlp 6y ago
  Except when one is developing, GHCi is the way to go.

pornel 6y ago

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.