4 ms·

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is

> Rust needs to mature a little more, stop changing so fast, and move further toward being old and boring. One of the very strange things about C is that it is designed by a committee that is inherently conservative and prefers to not add new features, especially if they have any chance of breaking any compatibility. This seems necessary before Rust ever becomes an old, boring language. But I don't see Rust ever going in such a direction. It seems fundamentally opposed to Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree.

alexpadula 9mo ago
Uh oh! I think Rust may settle down eventually. Who knows, maybe one of the devs will chime in.
- IshKebab 9mo ago
  It's pretty settled now.
pie_flavor 9mo ago
The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not ever have to update your 2015 edition code for anything.
- TZubiri 9mo ago
  Sounds like textbook bc break. I'm curious as to what you think a bc break would look like? Consider python2 and python3, you don't need to update your python2 code really, you can just use the python2 interpreter.
  - vlovich123 9mo ago
    No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every file should be compiled with the same language version target although practically that may be less of an issue depending on the specific stdlib implementation and if they break ABI) There’s also automated migration tools to convert 2021 code to 2024. It might fail on some translations but generally it’s pretty automatic. So huge difference both in the migration mechanism and the bc story.
    - bobbylarrybobby 9mo ago
      As long as the compiler is new enough to handle 2024 code (i.e., you're not using a 2021 version of the compiler itself), 2021 code can use 2024 code.
      - tialaramex 9mo ago
        Right. A good mental model would be to imagine every crate of Rust source has an associated Edition and there's a sort of "pre-processing" step where we translate that into the latest version of Rust seamlessly, preserving its exact meaning. So e.g. 2018 Edition said r# at the start of an identifier now marks a "raw" identifier. Keywords promise never to start this way, so r#foo is the same as foo but r#foo even works if some lunatic makes foo a keyword whereas just foo would become a keyword if that happened. As a result if you write let async = 5; ... in Rust 1.0 that translator treats it exactly as though you'd written let r#async = 5; ... in a modern Rust edition because these days the keyword async exists.
  - onetoo 9mo ago
    The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue. Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.
jll29 9mo ago
> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree. But the Rust team found a great way to avoid breaking backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler. That is much better IMHO than carrying that old baggage along in the language that e.g. the C++ folks struggle with, where every half-decade a pile of additive changes get piled on the previous version of the language, and nobody can clean up the old mess.
- muvlon 9mo ago
  > old code gets automatically compiled by the old version of the compile That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.
  - usefulcat 9mo ago
    And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.
    - maximilianburke 9mo ago
      Well, there's the 2015, 2018, 2021, and 2024 editions. It's been a decade and it seems to be working pretty well?
    - kibwen 9mo ago
      That won't be any more of a problem than the support that every existing C or C++ compiler has for targeting different versions of the standard.
      - tialaramex 9mo ago
        Right, it's not considered weird for a C++ compiler to offer C++ 98, C++ 11, C++ 14, C++ 17, C++ 20, C++ 23 and C++ 26 (seven versions) and support its own extra dialects. It is also usual for the C++ compilers to support all seven standard library versions too. Rust doesn't have this problem, the editions can define their own stdlib "prelude" (the reason why you can just say Vec or println! in Rust rather than their full names, a prelude is a set of use statements offered by default) but they all share the same standard library. core::mem::uninitialized() is a bad idea and we've known that for many years, but that doesn't mean you can't use it in brand new 2024 Edition Rust code, it just means doing so is still a bad idea. In contrast C++ removes things entirely from its standard library sometimes because they're now frowned on.
assimpleaspossi 9mo ago
Calling C "strange" for being conservative and not wanting to break things is rather odd. It's one of the "great" things in that sense. "Stable" could be another description.
- kstrauser 9mo ago
  Depends on what it’s unwilling to break. “The compiler generates code that segfaults when you multiply 13 * 37, but someone found a way way to trap it and used that as a faster way to make syscalls on Prime minicomputer, so we had to add -ffix-four-eight-won, which the original implementor misspelled in 1993 so we can’t fix that, either, for backward compatibility.” Some of its actual weirdnesses seem no less odd than that to people who aren’t C experts, I assure you.
cladopa 9mo ago
The great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in). To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee. If you look at the structure of C++ in Backus Naur form it is absolutely nuts. The compile times have gone through the roof and people leave to create new languages like jai, Zig or whatever. Common Lisp was designed by committee. It is as chaotic as C++. Rust is also gigantic. I am very careful not to use in critical systems because it is so big unless we could restrict it with the compiler or something.
- vlovich123 9mo ago
  For what it’s worth rust was also designed by a person with strong opinions. It’s devolved to an organization but that’s inevitable in terms of long term sustainability. You can always use no-std if you so choose where the language is about the size of C (but still has better utility) although if you’re complaining about the size of the language, c++ is drastically worse in my opinion. Rust starting to work its way into the Linux kernel should be a signal that the language is better suited for paring down than c++
- aw1621107 9mo ago
  > To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee. This comparison confuses me because C is... also controlled by a committee? The evolution of the C standard is under the control of ISO WG14 [0], much like how the C++ standard is under the control of ISO WG21 [1]. This was true for even the first versions of each language that was standardized. [0]: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ [1]: https://www.open-std.org/jtc1/sc22/wg21/ https://www.open-std.org/jtc1/sc22/wg21/

alexpadula 9mo ago

Uh oh! I think Rust may settle down eventually. Who knows, maybe one of the devs will chime in.

IshKebab 9mo ago
It's pretty settled now.

pie_flavor 9mo ago

The 'some degree' is pretty important, though. The Rust language undergoes backwards incompatible changes sometimes, but the Rust tools do not. The 2024 edition has breaking changes since the 2021 edition, but all compilers can compile all historical editions and will do so forever, and new language features are available in as many editions as possible, and editions can be mixed in a dependency tree, so you do not ever have to update your 2015 edition code for anything.

TZubiri 9mo ago
Sounds like textbook bc break. I'm curious as to what you think a bc break would look like? Consider python2 and python3, you don't need to update your python2 code really, you can just use the python2 interpreter.
- vlovich123 9mo ago
  No you’re misunderstanding the ecosystem. Rust 2024 code can call 2021 code without issue (and vice versa I think although could be wrong on the vice versa). So you can progressively update code of individual components as you want or not at all and still continue using it just fine in new code using later editions. Thats the very definition of back compat, something you really really shouldn’t do with C++ (every file should be compiled with the same language version target although practically that may be less of an issue depending on the specific stdlib implementation and if they break ABI) There’s also automated migration tools to convert 2021 code to 2024. It might fail on some translations but generally it’s pretty automatic. So huge difference both in the migration mechanism and the bc story.
  - bobbylarrybobby 9mo ago
    As long as the compiler is new enough to handle 2024 code (i.e., you're not using a 2021 version of the compiler itself), 2021 code can use 2024 code.
    - tialaramex 9mo ago
      Right. A good mental model would be to imagine every crate of Rust source has an associated Edition and there's a sort of "pre-processing" step where we translate that into the latest version of Rust seamlessly, preserving its exact meaning. So e.g. 2018 Edition said r# at the start of an identifier now marks a "raw" identifier. Keywords promise never to start this way, so r#foo is the same as foo but r#foo even works if some lunatic makes foo a keyword whereas just foo would become a keyword if that happened. As a result if you write let async = 5; ... in Rust 1.0 that translator treats it exactly as though you'd written let r#async = 5; ... in a modern Rust edition because these days the keyword async exists.
- onetoo 9mo ago
  The equivalent in python-metaphor-land would be that python files clearly designate whether they are py2 or py3, and a single python interpreter can run both py2 and py3 scripts, as well as cross-include files of each version without issue. Rust editions only (and rarely!) break your code when you decide to upgrade your project's edition. Your public API stays the same as well (IIRC), so upgrading edition doesn't break your dependents either -unless they don't have a new enough version of the compiler to support said newer edition.

jll29 9mo ago

> Rust's philosophy, which is to find the best solution to the problems it's trying to solve, at any cost, including breaking compatibility, at least to some degree. But the Rust team found a great way to avoid breaking backward compatibility: old code gets automatically compiled by the old version of the compiler, whereas more recent code is treated with the latest version of the compiler. That is much better IMHO than carrying that old baggage along in the language that e.g. the C++ folks struggle with, where every half-decade a pile of additive changes get piled on the previous version of the language, and nobody can clean up the old mess.

muvlon 9mo ago
> old code gets automatically compiled by the old version of the compile That's not what happens. You always use the same version of the compiler. It's just that the newer compiler version also knows several older dialects (known as editions) of the language.
- usefulcat 9mo ago
  And it remains to be seen how well this approach will work as time passes and the number of versions continues to increase.
  - maximilianburke 9mo ago
    Well, there's the 2015, 2018, 2021, and 2024 editions. It's been a decade and it seems to be working pretty well?
  - kibwen 9mo ago
    That won't be any more of a problem than the support that every existing C or C++ compiler has for targeting different versions of the standard.
    - tialaramex 9mo ago
      Right, it's not considered weird for a C++ compiler to offer C++ 98, C++ 11, C++ 14, C++ 17, C++ 20, C++ 23 and C++ 26 (seven versions) and support its own extra dialects. It is also usual for the C++ compilers to support all seven standard library versions too. Rust doesn't have this problem, the editions can define their own stdlib "prelude" (the reason why you can just say Vec or println! in Rust rather than their full names, a prelude is a set of use statements offered by default) but they all share the same standard library. core::mem::uninitialized() is a bad idea and we've known that for many years, but that doesn't mean you can't use it in brand new 2024 Edition Rust code, it just means doing so is still a bad idea. In contrast C++ removes things entirely from its standard library sometimes because they're now frowned on.

assimpleaspossi 9mo ago

Calling C "strange" for being conservative and not wanting to break things is rather odd. It's one of the "great" things in that sense. "Stable" could be another description.

kstrauser 9mo ago
Depends on what it’s unwilling to break. “The compiler generates code that segfaults when you multiply 13 * 37, but someone found a way way to trap it and used that as a faster way to make syscalls on Prime minicomputer, so we had to add -ffix-four-eight-won, which the original implementor misspelled in 1993 so we can’t fix that, either, for backward compatibility.” Some of its actual weirdnesses seem no less odd than that to people who aren’t C experts, I assure you.

cladopa 9mo ago

The great thing about C is that is was not designed by a committee at all. It was designed by a person with strong opinions. This means it is really great for what it does well(what the author was interested in). To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee. If you look at the structure of C++ in Backus Naur form it is absolutely nuts. The compile times have gone through the roof and people leave to create new languages like jai, Zig or whatever. Common Lisp was designed by committee. It is as chaotic as C++. Rust is also gigantic. I am very careful not to use in critical systems because it is so big unless we could restrict it with the compiler or something.

vlovich123 9mo ago
For what it’s worth rust was also designed by a person with strong opinions. It’s devolved to an organization but that’s inevitable in terms of long term sustainability. You can always use no-std if you so choose where the language is about the size of C (but still has better utility) although if you’re complaining about the size of the language, c++ is drastically worse in my opinion. Rust starting to work its way into the Linux kernel should be a signal that the language is better suited for paring down than c++
aw1621107 9mo ago
> To illustrate the difference look at C++, it was designed by a person with strong opinions, but then left it to be controlled by a committee. This comparison confuses me because C is... also controlled by a committee? The evolution of the C standard is under the control of ISO WG14 [0], much like how the C++ standard is under the control of ISO WG21 [1]. This was true for even the first versions of each language that was standardized. [0]: https://www.open-std.org/jtc1/sc22/wg14/ https://www.open-std.org/jtc1/sc22/wg14/ [1]: https://www.open-std.org/jtc1/sc22/wg21/ https://www.open-std.org/jtc1/sc22/wg21/