3 ms·

Rust is a pragmatic project. They chose a compiler which is performant and widely available and bet everything on it to keep things straightforward. It looks li

by blub 6y ago

Rust is a pragmatic project. They chose a compiler which is performant and widely available and bet everything on it to keep things straightforward. It looks like it's served them well. This compiler is on the other hand naturally not available on all platforms and is not appropriate for all contexts. Alternate implementations could have filled these gaps, but they're not there. The fact that the compiler defines the language and vice-versa enables additional flexibility in changing the language/compiler and development speed at the cost of instability. Different projects may tolerate different amounts of instability and for those that are more conservative Rust may not be an appropriate investment. With C++ one can code for a specific compiler or in a standard way. One can pick C++98 or 17 or anything in between. All of these are supported options and they give C++ its massive breadth and offer the most flexibility to teams. There's obviously disadvantages associated with all that, but claiming that diversity is a weakness is not generally true.

hobofan 6y ago
I'm assuming you mean LLVM by "compiler". If platform support of Rust is your concern here due to limited platform support of LLVM, then that might be going away. Based on the fact that Cranelift recently landed as a non-LLVM codegen backend in nightly, I assume that work is already pretty far on supporting alternative backends that could support alternative platforms.
- blub 6y ago
  Correct, I was not precise. Actually LLVM is not a problem for me personally, as the platforms I'm using right now are mainstream. I was merely trying to explain why some wouldn't be content just with LLVM.
karavelov 6y ago
Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords. There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc [2] https://github.com/sapir/gcc-rust/tree/rust https://github.com/sapir/gcc-rust/tree/rust [3] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs [4] https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift
- blub 6y ago
  Technically the possibility is there. What I'm interested in is how this will be regarded by Rust programmers as time passes and how it will continue to be supported. It would be interesting for example to see if e.g. the 2015 edition will still be usable/used 9 years later (like C++11) or even ~20 years later (like C++98) but we have some way to go before we can find that out. On the other hand, there's something exciting about being on the bleeding edge. Right now I'm using C++17 and would probably jump on C++20 when it becomes widely available. But having the knowledge that I have the rock-solid C++11 at my disposal and knowing that it will likely be there for decades gives me a feeling of security that's hard to beat.
  - steveklabnik 6y ago
    There's significant difference between the edition system and the C and C++ standards, and that is that the standards are done when they're done, but the editions are not, exactly. That is, new features arrive in the largest set of editions possible, whereas C99 is frozen in time. This is not to say that you or the parent are wrong exactly, but it doesn't really work in exactly the same way.
    - pjmlp 6y ago
      I still look forward to how editions will actually work in practice, when Rust gets a couple of years behind it. Lib A compiled with edition 2018, talking callbacks to functions implemented in Lib B with edition 2020, Lib C edition 2030 importing Lib D edition 2025. Naturally, I am also assuming that for pleasing the commercial users of binary libraries, typical in C and C++ universe, all those crates are only available as binary libraries being pulled into a multi-edition final executable.
      - dralley 6y ago
        Rust does not yet have a stable ABI, and there is not any such thing as a "binary crate" at the moment. So it's kind of hard to run into that problem as the entire exercise is impossible.

by blub 6y ago

hobofan 6y ago

I'm assuming you mean LLVM by "compiler". If platform support of Rust is your concern here due to limited platform support of LLVM, then that might be going away. Based on the fact that Cranelift recently landed as a non-LLVM codegen backend in nightly, I assume that work is already pretty far on supporting alternative backends that could support alternative platforms.

blub 6y ago
Correct, I was not precise. Actually LLVM is not a problem for me personally, as the platforms I'm using right now are mainstream. I was merely trying to explain why some wouldn't be content just with LLVM.

karavelov 6y ago

Similarly you can compile Rust in "edition = 2015" or "edition = 2018" and soon "edition = 2021" to guard against changes in the language, e.g. adding keywords. There are already alternative compilers, though most of them are WIP, e.g. mrustc[1], rust front-end for gcc[2][3], or using cranelift[4] for the back-end. [1] https://github.com/thepowersgang/mrustc https://github.com/thepowersgang/mrustc [2] https://github.com/sapir/gcc-rust/tree/rust https://github.com/sapir/gcc-rust/tree/rust [3] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs [4] https://github.com/bjorn3/rustc_codegen_cranelift https://github.com/bjorn3/rustc_codegen_cranelift

blub 6y ago
Technically the possibility is there. What I'm interested in is how this will be regarded by Rust programmers as time passes and how it will continue to be supported. It would be interesting for example to see if e.g. the 2015 edition will still be usable/used 9 years later (like C++11) or even ~20 years later (like C++98) but we have some way to go before we can find that out. On the other hand, there's something exciting about being on the bleeding edge. Right now I'm using C++17 and would probably jump on C++20 when it becomes widely available. But having the knowledge that I have the rock-solid C++11 at my disposal and knowing that it will likely be there for decades gives me a feeling of security that's hard to beat.
- steveklabnik 6y ago
  There's significant difference between the edition system and the C and C++ standards, and that is that the standards are done when they're done, but the editions are not, exactly. That is, new features arrive in the largest set of editions possible, whereas C99 is frozen in time. This is not to say that you or the parent are wrong exactly, but it doesn't really work in exactly the same way.
  - pjmlp 6y ago
    I still look forward to how editions will actually work in practice, when Rust gets a couple of years behind it. Lib A compiled with edition 2018, talking callbacks to functions implemented in Lib B with edition 2020, Lib C edition 2030 importing Lib D edition 2025. Naturally, I am also assuming that for pleasing the commercial users of binary libraries, typical in C and C++ universe, all those crates are only available as binary libraries being pulled into a multi-edition final executable.
    - dralley 6y ago
      Rust does not yet have a stable ABI, and there is not any such thing as a "binary crate" at the moment. So it's kind of hard to run into that problem as the entire exercise is impossible.