Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO", so rust 1.0 will likely get you LESS free labour from randoms online than C++ would
That's the point...
Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement.
Your C89 code will build on the C2x compiler in Arch and the C11 compiler in Debian stable N-1.
Your C17 code will not build on the C11 compiler in Debian Stable N-1 but will in the C2x compiler in Arch.
Your Rust 1.0 code will build on the Rust 1.67 compiler in Arch and the Rust 1.41 compiler in Debian Stable N-1.
Your Rust 2021 code will not build on the Rust 1.41 compiler in Debian Stable N-1 but will in the Rust 1.67 compiler in Arch.
I don't consider support for vintage platforms a requirement for a language being used in 2023.
EDIT: Since you've edited in this quote
> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO", so rust 1.0 will likely get you LESS free labour from randoms online than C++ would
Yes. This is true. But I don't exactly see maintainers lining up for your hypothetical C89 example either.
> Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO"
Funny. I skimmed the changelog for all the changes since that version of Rust, and the only change that looked like it might be must-have is the the one that stabilized inline assembly. The Rust language has matured to the point that it is fine to pick up new compiler versions as lackadaisically as other languages (e.g., C++).
> Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement.
Actually, a lot of C89 code is likely to get hung up on pointers being 64-bits instead of 32-bits. While it is possible to write C code that works on non-8-bit-bytes or not-2's-complement machines, it is easy to write code that is not robust to such assumptions. Furthermore, C programmers--especially older vintage--have this nasty habit of assuming that they're writing only a thin veneer over assembly code, which tends to cause portability issues if they're making very architecture-specific assumptions, not to mention issue when it turns out that the behavior they think is happening is actually undefined and the more powerful modern optimizers make it do something completely different.
Oh, and I can think of two features in C89 which are no longer supported by modern compilers. And neither of them are trigraphs.
Last I asked anyone writing rust "for fun" - the answer I got was "latest compiler/features/shiny or GTFO", so rust 1.0 will likely get you LESS free labour from randoms online than C++ would
That's the point...
Compare to C89 code that will happily build on any C compiler of any vintage on any system you dig up anywhere, even those that are big endian, have non-8-bit bytes, or are not 2s complement.