4 ms·

>Its compilation is slow. I mean SLOW. D language smiling in the corner [1]. "D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler,

>Its compilation is slow. I mean SLOW. D language smiling in the corner [1]. "D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." [2] [1] Kevin James meme creator tries to guess why the photo went so viral: https://www.yahoo.com/lifestyle/kevin-james-became-internets-king-003000488.html https://www.yahoo.com/lifestyle/kevin-james-became-internets... [2] Ask HN: Why do you use Rust, when D is available? https://news.ycombinator.com/item?id=23494490 https://news.ycombinator.com/item?id=23494490

byko3y 11mo ago
>"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".
- vacuity 11mo ago
  "Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.
  - byko3y 11mo ago
    >Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++. Okay, what's your take on why exactly Rust compiles slowly?
    - vacuity 11mo ago
      Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for. > Okay, what's your take on why exactly Rust compiles slowly? It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity/ https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.
      - aw1621107 11mo ago
        > It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this. I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable. For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.
        estebank 11mo ago
        There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequently, leveraging an incremental linker and have rustc only codegen the binary patch instead of the whole binary and have the linker calculate the patch, and caching proc-macros and treat them as idempotent (likely as opt-in). There are of course others, like pre-compiled distribution, better intra-rustc parallelism or feature cfg handling, but those have more open questions and require additional design work before I could claim they're attainable.
throwaway81523 11mo ago
Ocaml compilation is also very fast, and it has generics like Rust, amirite?
- IshKebab 11mo ago
  OCaml has other serious issues.
  - aw1621107 11mo ago
    What are those issues, if you don't mind me asking? Don't see much OCaml discussion here so I'll take interesting discussions where I can get them.
    - IshKebab 11mo ago
      My biggest gripes: * Windows support is mediocre due to decades of not supporting it at all. * OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents. * A silly obsession with linked lists. Ok I understand why but it's still annoying. * Ocamlfmt thinks it is writing an essay, and generally makes things less readable IMO. * The syntax is not easy to read. They threw away all the useful punctuation that help you visually parse code. * Tiny community. * Very spartan documentation. Examples are very rare. * Global type inference is definitely worse than Rust's local approach because it makes errors much worse, and makes the code harder to understand. * Native int type is 63 bits. I haven't even done much OCaml but it's definitely got enough issues that I strongly prefer Rust. Just the community size is reason enough really. That said, it's still way better than Python, Ruby, PHP, Java, JavaScript and Perl. Those are kind of the Z-tier languages though so I guess that's not saying much. If it was a choice between OCaml and Go, Swift, C#, Dart... then it wouldn't be a slam dunk either way. Unless you wanted Windows support and then OCaml is a crazy choice.
      - aw1621107 11mo ago
        I can certainly see how those can be problematic. Thanks for taking the time to elaborate!
vacuity 11mo ago
I am not too familiar with D, but it seems that D's borrowing system is somewhat different than Rust's, given that it is not the focus of how D is implemented and used. This means different design tradeoffs. There are appropriate ways to contrast D with Rust and illustrate where D is stronger, but it is inaccurate to say "Rust has borrowing; D has borrowing" and conclude that they are comparable in this sense.
arresin 11mo ago
Maybe it’s not a fair judgement because I just looked at the docs, but I didn’t like the syntax on first looking at it.

byko3y 11mo ago

>"D supports Ownership and Borrowing, just like Rust. DMD, D's reference compiler, can compile itself in less than 5 seconds, thanks to a fast frontend and fast backend. D is easy to metaprogram through traits and templates. You can make your own JIT in D with dynamicCompile." Indeed, there are languages that have generics, compile blazingly fast, and still have good runtime performance. Go lang is another good example, although not perfect too. If only Rust designers did a single thing to make it compile fast instead of "eventually".

vacuity 11mo ago
"Generics" is not why Rust compiles slowly. Rust had certain design decisions and implementation details that impact compile times significantly. Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. By doing so, you invite discourse as ideological and uncritical as that of Rust fanatics, however many or few there are.
- byko3y 11mo ago
  >Do not misrepresent them and pretend that the Rust developers are incompetent or malicious. I'm sorry, but I sensirely think the Rust designer did a sloppy work by reimplementing C++ flaws with a new syntax. The history repeats itself, the same pathological mechanism once driving C++ development now drived Rust — I mean large enterprise wanting to change everything without changing nothing, the new tool that would feel like the old tool. They did not really invent some new model, look at std::shared_ptr, std::mutex, move semantic — it was already in C++ before the prototype of Rust. The "share immutables, lock mutables" model was a holy grail of C++ concurrency caused by the way STL worked — and STL is not nearly the only container library in C++. Okay, what's your take on why exactly Rust compiles slowly?
  - vacuity 11mo ago
    Rust certainly takes after C++, but it's not the same. It's more like C++ if it was made today. For instance, Rust's destructive move semantics are the better default. (However, Rust making everything moveable by default is a bit of a drawback.) I don't understand your point about std::shared_ptr, std::mutex, and the immutability/mutability model. These are not C++ constructs; they are general programming constructs that C++ has an implementation of. Rust does not claim to have some innovative take on reference counting or locking. However, Rust's borrowing is an improvement (by default) on managing shared mutable state. Rust is not Carbon, or whatever new C++ variant is out there; it is a backwards-incompatible language that offers better ways to do many of the things C++ is used for. > Okay, what's your take on why exactly Rust compiles slowly? It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity/ https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this.
    - aw1621107 11mo ago
      > It's not "my take". https://www.pingcap.com/blog/rust-compilation-model-calamity https://www.pingcap.com/blog/rust-compilation-model-calamity... is a good resource on this. I think one interesting thing that could be explored more is what aspects of Rust "inherently" result in slow compilation (i.e., if you changed said aspects to improve compilation speeds then you end up with a "different" language, assuming some hand-waviness with respect to equivalence here) and what aspects are practically and/or theoretically improvable. For example, rustc's reliance on LLVM for optimization is a well-known source of sluggishness, but I wouldn't classify that as "inherent" since Rust could use a different backend that works faster (e.g., Cranelift) and/or be more efficient about the IR it emits. Something like monomorphization, on the other hand, is a more in a grey area since it's (as far as I know) essential for Rust to meet its performance goals, but IIRC it's not out of the question for the compiler to implement generics using a different strategy instead, which might be viable as an opt-in tradeoff.
      - estebank 11mo ago
        There are at least three separate things that rustc and cargo could do to significantly improve compilation speed, but they are complex engineering efforts that require time and engineers being paid to work on full-time. They are: doing what zig does to compile only items that arr reachable, which requires making rustc reentrant to stop after name resolution and cargo more complex to pass used paths through subsequently, leveraging an incremental linker and have rustc only codegen the binary patch instead of the whole binary and have the linker calculate the patch, and caching proc-macros and treat them as idempotent (likely as opt-in). There are of course others, like pre-compiled distribution, better intra-rustc parallelism or feature cfg handling, but those have more open questions and require additional design work before I could claim they're attainable.

throwaway81523 11mo ago

Ocaml compilation is also very fast, and it has generics like Rust, amirite?

IshKebab 11mo ago
OCaml has other serious issues.
- aw1621107 11mo ago
  What are those issues, if you don't mind me asking? Don't see much OCaml discussion here so I'll take interesting discussions where I can get them.
  - IshKebab 11mo ago
    My biggest gripes: * Windows support is mediocre due to decades of not supporting it at all. * OPAM is a nightmare. Surprisingly buggy and extremely confusing. We're not talking Pip levels of badness but it's nowhere near as good as Rust, Zig or Go's equivalents. * A silly obsession with linked lists. Ok I understand why but it's still annoying. * Ocamlfmt thinks it is writing an essay, and generally makes things less readable IMO. * The syntax is not easy to read. They threw away all the useful punctuation that help you visually parse code. * Tiny community. * Very spartan documentation. Examples are very rare. * Global type inference is definitely worse than Rust's local approach because it makes errors much worse, and makes the code harder to understand. * Native int type is 63 bits. I haven't even done much OCaml but it's definitely got enough issues that I strongly prefer Rust. Just the community size is reason enough really. That said, it's still way better than Python, Ruby, PHP, Java, JavaScript and Perl. Those are kind of the Z-tier languages though so I guess that's not saying much. If it was a choice between OCaml and Go, Swift, C#, Dart... then it wouldn't be a slam dunk either way. Unless you wanted Windows support and then OCaml is a crazy choice.
    - aw1621107 11mo ago
      I can certainly see how those can be problematic. Thanks for taking the time to elaborate!

vacuity 11mo ago

I am not too familiar with D, but it seems that D's borrowing system is somewhat different than Rust's, given that it is not the focus of how D is implemented and used. This means different design tradeoffs. There are appropriate ways to contrast D with Rust and illustrate where D is stronger, but it is inaccurate to say "Rust has borrowing; D has borrowing" and conclude that they are comparable in this sense.

arresin 11mo ago

Maybe it’s not a fair judgement because I just looked at the docs, but I didn’t like the syntax on first looking at it.