4 ms·

I don't think it's fair to say Rust is a "latest craze" language. Maybe five years ago, but not now. Numerous tools have been (re)written in it and supplanted o

by saila 4y ago

I don't think it's fair to say Rust is a "latest craze" language. Maybe five years ago, but not now. Numerous tools have been (re)written in it and supplanted old tools in at least some cases. Additionally, there are reasons given in the linked issue. I guess you could debate about whether they're good reasons (they sound reasonable to me), but you can't say they're proposing it for no reason just because you don't like or agree with the reasons. To that point, as someone who learned a decent amount of C and C++ a long time ago, I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance. And to be clear, I'm not bashing C/C++ at all. They're venerable and appreciated, but I have little to no interest in working with them, and it seems to me that this is a fairly common sentiment.

dmitrygr 4y ago
> Maybe five years ago, but not now. A language stops being "new" when debian stable's previous release supports it as fully as Arch's current beta.
- Macha 4y ago
  Here you go: https://packages.debian.org/buster/rust/ https://packages.debian.org/buster/rust/
  - dmitrygr 4y ago
    Yes..those are antique. 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.
    - loeg 4y ago
      Modern C requires 2’s complement signed integers.
    - Macha 4y ago
      I don't quite get the distinction being drawn. 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.
    - jcranmer 4y ago
      > 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.
fbdab103 4y ago
>I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance. This right here is a killer motivation. I will never contribute to a C/C++ codebase. The tooling is all bad, and I am too uncomfortable doing the simplest things (hello C strings). With Rust, I have few such reservations, and could contribute a patch here or there.

by saila 4y ago

dmitrygr 4y ago

> Maybe five years ago, but not now. A language stops being "new" when debian stable's previous release supports it as fully as Arch's current beta.

Macha 4y ago
Here you go: https://packages.debian.org/buster/rust/ https://packages.debian.org/buster/rust/
- dmitrygr 4y ago
  Yes..those are antique. 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.
  - loeg 4y ago
    Modern C requires 2’s complement signed integers.
  - Macha 4y ago
    I don't quite get the distinction being drawn. 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.
  - jcranmer 4y ago
    > 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.

fbdab103 4y ago

>I would probably never get involved in a C/C++ project nowadays, but I've been learning Rust these past few years and would definitely get involved in a Rust project if I had the chance. This right here is a killer motivation. I will never contribute to a C/C++ codebase. The tooling is all bad, and I am too uncomfortable doing the simplest things (hello C strings). With Rust, I have few such reservations, and could contribute a patch here or there.