4 ms·

Rust’s cavalier attitude to language and compiler stability, their absurd bootstrapping situation and limited platform support, not to mention their belief that

by fmajid 5y ago

Rust’s cavalier attitude to language and compiler stability, their absurd bootstrapping situation and limited platform support, not to mention their belief that “curl something|bash” is acceptable procedure are all reasons why I’ve avoided it despite the many good qualities of the language.

jopsen 5y ago
Aren't many of those things stuff that can be fixed as the ecosystem matures? Is C ecosystems much better?
humanrebar 5y ago
I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compilers, make, etc. are really stable, existing Linux source tarballs have a habit of building fine for decades after initial release.
- tialaramex 5y ago
  In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.
  - humanrebar 5y ago
    Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.
    - tialaramex 5y ago
      So, firstly the editions system means it doesn't even matter about crates using a different edition. Remember that await variable in the Rust 1.0 code above? My Rust 2021 code can still talk about that variable, even though it's from a different edition and the word "await" is now a keyword, it just calls that variable r#await meaning "the identifier named await" - which is a bit ugly but gets the job done for interoperability purposes. But also, all previous versions of published crates are kept indefinitely. If Linux wants serde v1.0.240 then that's fine, even if subsequently serde shipped v1.0.241, v1.1.14 and v2.0.1 the repository holds on to everything.
      - humanrebar 5y ago
        It matters if certain drivers require certain toolchains. C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. You're correct that the kernel codebase could pin older versions of crates when it is appropriate, but it's never quite that simple at scale, especially if the kernel pulls in more than a handful of crates.
        cesarb 5y ago
        > C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. Funny you should mention that. The Linux kernel recently switched from C89 to C11 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50560ce6a0bdab2fc37384c52aa02c7043909d2c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), so only toolchains that support C11 can compile the kernel. Even before that, the minimum version of GCC required to compile the kernel has risen several times. The current minimum is GCC 5.1, so the GCC 4.9 which you could use to compile the kernel one year ago is no longer good enough.
roblabla 5y ago
Wat? Rust has been a very stable language since Rust 1.0. They have a stellar record of keeping things working - with most code breaking being due to said code invoking UB. The edition system is a brilliant invention that allows evolving the language _without_ causing an ecosystem split. Thanks to this, Rust ends up having a much better stability story than even C++ (for whom you can't really mix and match different C++ versions). The bootstrapping situation is really not that bad? We have mrustc (A C++ rust->C transpiler) which allows compiling modern versions of rustc (latest supported rustc version being 1.54), which we can then iteratively bootstrap from up to the latest version. And things are getting better, with gccrs[0] in particular promising a rust frontend for GCC, written in C. As for the "curl something|bash", I suppose you're talking about rustup. You're free to download the script, and review it before installing it. And rust is also distributed many different ways. At least `curl something|bash` does not require root account, unlike `sudo apt install`, which can be very convenient. Like all things: Multiple options are generally better. [0] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs
- kldx 5y ago
  What do you mean by different C++ versions can't mix? Language, standard library implemention or something else?
  - tialaramex 5y ago
    Try it. Here's a completely reasonable line of C++ 17 code: int concept = 4; Now here's a completely reasonable line of C++ 20 code: template <class T> concept delicious = true; Huh. You can't have those in the same project because C++ 20 believes you can't name a variable "concept" and C++ 17 believes "concept" is an identifier and so you can't write your delicious concept template. These are both valid C++, it's just that they aren't simultaneously valid in any of the half dozen distinct versions of standard C++.
    - zozbot234 5y ago
      C fixes this by using _Concept as the keyword and sticking a #define concept _Concept in a separate stdconcept.h header file. Or maybe it was about complex or whatever, but same deal.

by fmajid 5y ago

jopsen 5y ago

Aren't many of those things stuff that can be fixed as the ecosystem matures? Is C ecosystems much better?

humanrebar 5y ago

I wouldn't phrase my concerns that way, but it is concerning that Rust doesn't do LTS releases (someone correct me if I missed something here). Because C compilers, make, etc. are really stable, existing Linux source tarballs have a habit of building fine for decades after initial release.

tialaramex 5y ago
In what sense is Rust 1.0 not already an LTS release ? If you wrote some Rust 1.0 code back in 2015, put it away in a drawer (maybe on a USB stick) but now get it out today it will still build with current Rust tooling -- except for some very narrow cases where you might have done something inherently unsound and subsequently the compiler was corrected to fix that so it's an error. Rust's language shifted slightly in those years. However the Editions system - even though it hadn't yet been invented in 2015 - allows for that. Your 2015 code lacks any Edition metadata, so, the modern tools understand that as Rust 2015 edition, and will compile accordingly, while still interoperating correctly with modern Rust. Suppose your 2015 code named a variable await. That's a keyword in modern Rust. But it isn't a keyword in Rust 2015 edition, so your code compiles just fine. This would not work in C of course, which is why its newer keywords are ugly stuff like _Bool but in Rust it's fine.
- humanrebar 5y ago
  Modern releases of GCC still support C89. If rustc, at least, will keep supporting 1.0 features for all future releases, I guess that's fine. But that also means that crates used by the kernel would need to likewise be conservative about updating to new Editions so as to not break expected support surfaces.
  - tialaramex 5y ago
    So, firstly the editions system means it doesn't even matter about crates using a different edition. Remember that await variable in the Rust 1.0 code above? My Rust 2021 code can still talk about that variable, even though it's from a different edition and the word "await" is now a keyword, it just calls that variable r#await meaning "the identifier named await" - which is a bit ugly but gets the job done for interoperability purposes. But also, all previous versions of published crates are kept indefinitely. If Linux wants serde v1.0.240 then that's fine, even if subsequently serde shipped v1.0.241, v1.1.14 and v2.0.1 the repository holds on to everything.
    - humanrebar 5y ago
      It matters if certain drivers require certain toolchains. C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. You're correct that the kernel codebase could pin older versions of crates when it is appropriate, but it's never quite that simple at scale, especially if the kernel pulls in more than a handful of crates.
      - cesarb 5y ago
        > C89 is portable across all sorts of C toolchains. If the Linux kernel added C17 features, only toolchains that support C17 could compile the kernel. Funny you should mention that. The Linux kernel recently switched from C89 to C11 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=50560ce6a0bdab2fc37384c52aa02c7043909d2c https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...), so only toolchains that support C11 can compile the kernel. Even before that, the minimum version of GCC required to compile the kernel has risen several times. The current minimum is GCC 5.1, so the GCC 4.9 which you could use to compile the kernel one year ago is no longer good enough.

roblabla 5y ago

Wat? Rust has been a very stable language since Rust 1.0. They have a stellar record of keeping things working - with most code breaking being due to said code invoking UB. The edition system is a brilliant invention that allows evolving the language _without_ causing an ecosystem split. Thanks to this, Rust ends up having a much better stability story than even C++ (for whom you can't really mix and match different C++ versions). The bootstrapping situation is really not that bad? We have mrustc (A C++ rust->C transpiler) which allows compiling modern versions of rustc (latest supported rustc version being 1.54), which we can then iteratively bootstrap from up to the latest version. And things are getting better, with gccrs[0] in particular promising a rust frontend for GCC, written in C. As for the "curl something|bash", I suppose you're talking about rustup. You're free to download the script, and review it before installing it. And rust is also distributed many different ways. At least `curl something|bash` does not require root account, unlike `sudo apt install`, which can be very convenient. Like all things: Multiple options are generally better. [0] https://github.com/Rust-GCC/gccrs https://github.com/Rust-GCC/gccrs

kldx 5y ago
What do you mean by different C++ versions can't mix? Language, standard library implemention or something else?
- tialaramex 5y ago
  Try it. Here's a completely reasonable line of C++ 17 code: int concept = 4; Now here's a completely reasonable line of C++ 20 code: template <class T> concept delicious = true; Huh. You can't have those in the same project because C++ 20 believes you can't name a variable "concept" and C++ 17 believes "concept" is an identifier and so you can't write your delicious concept template. These are both valid C++, it's just that they aren't simultaneously valid in any of the half dozen distinct versions of standard C++.
  - zozbot234 5y ago
    C fixes this by using _Concept as the keyword and sticking a #define concept _Concept in a separate stdconcept.h header file. Or maybe it was about complex or whatever, but same deal.