4 ms·

I think Rust has shown a way to remove deprecated interfaces while retaining back compat - automated tooling to migrate to the next version and give a few versi

I think Rust has shown a way to remove deprecated interfaces while retaining back compat - automated tooling to migrate to the next version and give a few versions for a deprecated interfaces to stick around at the source level.

jjmarr 8mo ago
C++ almost never removes features because of the ABI compatibility guarantees. Programs compiled with older versions of the standard can be linked against newer versions. This is allegedly because in the 80s companies would write software, fire the programmers, and throw the source code away once it compiled.
- Sharlin 8mo ago
  Fixing syntax by definition does not affect the ABI. And Rust has shown that both ABI and API compatibility can be achieved in the presence of several "versions" (editions) of the language in the same build.
  - irishcoffee 8mo ago
    Rust has shown that it’s yet another language that kind of sort of addresses 3% of the issues c/c++ has, tops.
    - tialaramex 8mo ago
      I really don't like C++ but it's hard to come up with thirty-odd times as many other terrible problems as the ones Rust addresses.
    - saghm 8mo ago
      Probably because like 95% of C++'s issues are self-inflicted and don't need to be addressed if you use a different language in the first place, and 1% of them are fundamentally unsolvable by any language.
    - vlovich123 8mo ago
      lol. A functions module system that’s easy to use and adopted? A package manager? A well implemented hash table? Fast compile times? Effectively no segfaults? Effectively no memory leaks? Comparatively no race condition bugs? A benchmark and unit test framework baked into the language? Auto optimization of the layout of structs? No UB? I don’t know what you’re counting as “3% of the issues” but if those are the 3%, they sound like massive productivity and safety wins that’s not existed in a language with a similar performance profile to C/C++.
      - jjmarr 8mo ago
        Is Rust faster to compile than C++?
        tialaramex 8mo ago
        Different (though related) things make compiling Rust slow. In both cases the compiler can spend a lot of time working on types which you, as programmer, weren't really thinking about. Rust cares about types which could exist based on what you wrote but which you never made, whereas C++ doesn't care about that, but it does need to do a lot of "from scratch" work for parametrised types that Rust doesn't have to because C++ basically does a lot of textual substitution in template expansion rather than "really" having parametrised typing. If you're comparing Clang the backend optimiser work is identical in both cases it's LLVM. People who've never measured often believe Rust's borrowck needs a lot of compiler effort but actual measurements don't agree - it's not free but it's very cheap (in terms of proportion of compiler runtime).
        vlovich123 8mo ago
        For most day to day cases, rust will actually compile faster because the build system will do good incremental builds - not perfect, but better than c++. Also clean builds are still “perfectly” parallelized by default. And yes, while rust has a reputation for being slow, in my experience it’s faster for most projects you encounter in practice because the c++ ecosystem is generally not parallelized and even if it is many projects have poor header hygiene that makes things slow.
    - Sharlin 8mo ago
      Do you actually know Rust or were you just talking out if hour ass? I’d like you to enumerate even thirty problems of C or C++ that Rust doesn’t fix, never mind hundreds (because Rust fixes a metric shit ton of C/C++ problems!)
IcyWindows 8mo ago
Rust is a single vendor. It's not really the same situation.
- zaphar 8mo ago
  There is a single standard committee though. There is really nothing stopping them from shipping tooling that can do the conversions for people. The number of vendors isn't really the problem here. The problem is that the committee shifts that responsibility onto the vendors of the compiler rather than owning it themselves.
- vlovich123 8mo ago
  Having multiple compiler vendors is a problem IMO not a feature. It fragments the ecosystem - the code compiles fine with this compiler but not this other one. The maintenance of portable Rust code is significantly easier. I think the way forward is multiple backends (LLVM + GCC) to improve platform support, but a single unified frontend that works correctly on all platforms is a good thing.
ameliaquining 8mo ago
If you're talking about editions, this isn't how they work at all; every edition continues to be supported forever. (The part about automated migration tooling is true, and nice.) There've been a few cases where code was unsound and should never have compiled, but did due to compiler bugs, and then they fixed the bugs and the code stopped compiling. These were handled through deprecation warnings with timelines at least several months long (Rust releases a new version every six weeks), but usually didn't have automated migration tooling, and didn't fracture the language mostly because they were rare edge cases that most programmers didn't encounter.
- vlovich123 8mo ago
  Editions are still allowed to remove old syntax or even remove APIs - they only can’t break ABIs. So the code is still there once removed from an edition in previous editions, but such symbols don’t even get linked if they’re unused supporting progressive removal. And similarly, I could see editions getting completely removed in the future at some point. Eg rather than indefinitely maintaining editions, in 20 years have a checkpoint version of a compiler that supports the previous 20 years of editions and going forward editions older than 10 aren’t in the build (for example, assuming a meaningful maintenance burden, which is hard to predict when that happens and what a specific policy looks like).
  - ameliaquining 8mo ago
    Editions never remove APIs.
    - vlovich123 8mo ago
      Have not yet. There’s nothing stopping them though and from talking with the std folks it seems like they will likely at some point experiment crossing that bridge.

jjmarr 8mo ago

C++ almost never removes features because of the ABI compatibility guarantees. Programs compiled with older versions of the standard can be linked against newer versions. This is allegedly because in the 80s companies would write software, fire the programmers, and throw the source code away once it compiled.

Sharlin 8mo ago
Fixing syntax by definition does not affect the ABI. And Rust has shown that both ABI and API compatibility can be achieved in the presence of several "versions" (editions) of the language in the same build.
- irishcoffee 8mo ago
  Rust has shown that it’s yet another language that kind of sort of addresses 3% of the issues c/c++ has, tops.
  - tialaramex 8mo ago
    I really don't like C++ but it's hard to come up with thirty-odd times as many other terrible problems as the ones Rust addresses.
  - saghm 8mo ago
    Probably because like 95% of C++'s issues are self-inflicted and don't need to be addressed if you use a different language in the first place, and 1% of them are fundamentally unsolvable by any language.
  - vlovich123 8mo ago
    lol. A functions module system that’s easy to use and adopted? A package manager? A well implemented hash table? Fast compile times? Effectively no segfaults? Effectively no memory leaks? Comparatively no race condition bugs? A benchmark and unit test framework baked into the language? Auto optimization of the layout of structs? No UB? I don’t know what you’re counting as “3% of the issues” but if those are the 3%, they sound like massive productivity and safety wins that’s not existed in a language with a similar performance profile to C/C++.
    - jjmarr 8mo ago
      Is Rust faster to compile than C++?
      - tialaramex 8mo ago
        Different (though related) things make compiling Rust slow. In both cases the compiler can spend a lot of time working on types which you, as programmer, weren't really thinking about. Rust cares about types which could exist based on what you wrote but which you never made, whereas C++ doesn't care about that, but it does need to do a lot of "from scratch" work for parametrised types that Rust doesn't have to because C++ basically does a lot of textual substitution in template expansion rather than "really" having parametrised typing. If you're comparing Clang the backend optimiser work is identical in both cases it's LLVM. People who've never measured often believe Rust's borrowck needs a lot of compiler effort but actual measurements don't agree - it's not free but it's very cheap (in terms of proportion of compiler runtime).
        vlovich123 8mo ago
        For most day to day cases, rust will actually compile faster because the build system will do good incremental builds - not perfect, but better than c++. Also clean builds are still “perfectly” parallelized by default. And yes, while rust has a reputation for being slow, in my experience it’s faster for most projects you encounter in practice because the c++ ecosystem is generally not parallelized and even if it is many projects have poor header hygiene that makes things slow.
  - Sharlin 8mo ago
    Do you actually know Rust or were you just talking out if hour ass? I’d like you to enumerate even thirty problems of C or C++ that Rust doesn’t fix, never mind hundreds (because Rust fixes a metric shit ton of C/C++ problems!)

IcyWindows 8mo ago

Rust is a single vendor. It's not really the same situation.

zaphar 8mo ago
There is a single standard committee though. There is really nothing stopping them from shipping tooling that can do the conversions for people. The number of vendors isn't really the problem here. The problem is that the committee shifts that responsibility onto the vendors of the compiler rather than owning it themselves.
vlovich123 8mo ago
Having multiple compiler vendors is a problem IMO not a feature. It fragments the ecosystem - the code compiles fine with this compiler but not this other one. The maintenance of portable Rust code is significantly easier. I think the way forward is multiple backends (LLVM + GCC) to improve platform support, but a single unified frontend that works correctly on all platforms is a good thing.

ameliaquining 8mo ago

If you're talking about editions, this isn't how they work at all; every edition continues to be supported forever. (The part about automated migration tooling is true, and nice.) There've been a few cases where code was unsound and should never have compiled, but did due to compiler bugs, and then they fixed the bugs and the code stopped compiling. These were handled through deprecation warnings with timelines at least several months long (Rust releases a new version every six weeks), but usually didn't have automated migration tooling, and didn't fracture the language mostly because they were rare edge cases that most programmers didn't encounter.

vlovich123 8mo ago
Editions are still allowed to remove old syntax or even remove APIs - they only can’t break ABIs. So the code is still there once removed from an edition in previous editions, but such symbols don’t even get linked if they’re unused supporting progressive removal. And similarly, I could see editions getting completely removed in the future at some point. Eg rather than indefinitely maintaining editions, in 20 years have a checkpoint version of a compiler that supports the previous 20 years of editions and going forward editions older than 10 aren’t in the build (for example, assuming a meaningful maintenance burden, which is hard to predict when that happens and what a specific policy looks like).
- ameliaquining 8mo ago
  Editions never remove APIs.
  - vlovich123 8mo ago
    Have not yet. There’s nothing stopping them though and from talking with the std folks it seems like they will likely at some point experiment crossing that bridge.