4 ms·

It is insane to assert that Rust hasn't "really stabilized yet" in comparison to C, a language which has been replaced twice (as C17 and C23) after Rust 1.0

1718627440 10mo ago
Except that those are more like bug fixes, it's unlikely to have something newer than C11 and most are still on C99.
- pjmlp 10mo ago
  Show us that you haven't read ISO C documents without telling us.
  - 1718627440 10mo ago
    True, at most I read excerpts when I have a question. Can you tell me what gave it away? I thought the saying is that C17 is the sane version of C11 and C23 has quite some changes, but is way to new to be counted on.
    - uecker 10mo ago
      C17 is indeed a bug fix release. C23 finally removed some features that were deprecated a long time ago already in the first standardized version (auto as storage classifier, K&R function definitions, empty parenthesis as "arbitrary arguments") and also support for ones' complement. So yes, C is extremely backwards compatible.
      - 1718627440 10mo ago
        Auto as storage classifier was deprecated? TIL.
        uecker 10mo ago
        Ah no, sorry, my mistake. And it is still a storage classifier, but now (in C23) it is mentioned that it will become a type specifier.
- dfawcus 10mo ago
  Actually lots is still on C89. I'm trying to drag one program at $employer up to C99 (plus C11 _Generic), so I can then subsequently drag it to the bits of C23 which GCC 13 supports. This all takes times, and having to convince colleagues during code reviews. What C23 has done is authorise some of the extensions which GCC has had for some time as legitimate things (typeof, etc). However the ability to adopt is also limited by what third party linters in use at $employer may also support.
tliltocatl 10mo ago
C17 didn't introduce any changes to the language. C23 mostly standardized existing compiler-specific goodies. None of this broke existing code. When I run `sudo dnf upgrade gcc` I can be 99.9% sure my old code still compiles. Compare e. g. https://github.com/rust-lang/rust/pull/102750/ https://github.com/rust-lang/rust/pull/102750/ (I'm not following Rust development closely, picked up the first one). Yes, developers do rely on non-guaranteed behavior, that's their nature. C would likely standardize old behavior. Basically all of the C standard is a promoted vendor-specific extension - for better or worse. Here is another good one: https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374 https://internals.rust-lang.org/t/type-inference-breakage-in...
- tialaramex 10mo ago
  C17 ostensibly "didn't change" the language but it did still need to fix a bunch of stuff and it chose to do this by just issuing an entirely new language standards document. C23 on the other hand landed a bunch of hard changes, and "it didn't break my code" only matches the reality most people observe with Rust too. The changes you mention didn't break my Rust either. But some trivial C did break because C23 is a new language https://c.godbolt.org/z/n9vhMGYW5 https://c.godbolt.org/z/n9vhMGYW5 In fact those Rust changes aren't language changes unlike C23, the first you linked is a choice for the compiler to improve on layout it didn't guarantee, anybody who was relying on that layout (and there were a few) was never promised this wouldn't change, next version, next week or indeed the next time they compiled the same code. You can even ask Rust's compiler to help light a fire under you on this by arbitrarily changing some layout between builds, so that stuff which depends on unpromised layout breaks earlier, reminding you to actually tell Rust e.g. repr(C) "I need the same layout guarantees for my type T as I'd get in C" or repr(transparent) "I need to ensure my type wrapper T has the same layout as the type I'm wrapping" The second isn't a language change at all, it's a change to a library feature, so now we're down to "C isn't stable until the C library is forever unchanging" which hopefully you recognise as entirely silly. Needless to say nobody does that.

1718627440 10mo ago

Except that those are more like bug fixes, it's unlikely to have something newer than C11 and most are still on C99.

pjmlp 10mo ago
Show us that you haven't read ISO C documents without telling us.
- 1718627440 10mo ago
  True, at most I read excerpts when I have a question. Can you tell me what gave it away? I thought the saying is that C17 is the sane version of C11 and C23 has quite some changes, but is way to new to be counted on.
  - uecker 10mo ago
    C17 is indeed a bug fix release. C23 finally removed some features that were deprecated a long time ago already in the first standardized version (auto as storage classifier, K&R function definitions, empty parenthesis as "arbitrary arguments") and also support for ones' complement. So yes, C is extremely backwards compatible.
    - 1718627440 10mo ago
      Auto as storage classifier was deprecated? TIL.
      - uecker 10mo ago
        Ah no, sorry, my mistake. And it is still a storage classifier, but now (in C23) it is mentioned that it will become a type specifier.
dfawcus 10mo ago
Actually lots is still on C89. I'm trying to drag one program at $employer up to C99 (plus C11 _Generic), so I can then subsequently drag it to the bits of C23 which GCC 13 supports. This all takes times, and having to convince colleagues during code reviews. What C23 has done is authorise some of the extensions which GCC has had for some time as legitimate things (typeof, etc). However the ability to adopt is also limited by what third party linters in use at $employer may also support.

tliltocatl 10mo ago

C17 didn't introduce any changes to the language. C23 mostly standardized existing compiler-specific goodies. None of this broke existing code. When I run `sudo dnf upgrade gcc` I can be 99.9% sure my old code still compiles. Compare e. g. https://github.com/rust-lang/rust/pull/102750/ https://github.com/rust-lang/rust/pull/102750/ (I'm not following Rust development closely, picked up the first one). Yes, developers do rely on non-guaranteed behavior, that's their nature. C would likely standardize old behavior. Basically all of the C standard is a promoted vendor-specific extension - for better or worse. Here is another good one: https://internals.rust-lang.org/t/type-inference-breakage-in-1-80-has-not-been-handled-well/21374 https://internals.rust-lang.org/t/type-inference-breakage-in...

tialaramex 10mo ago
C17 ostensibly "didn't change" the language but it did still need to fix a bunch of stuff and it chose to do this by just issuing an entirely new language standards document. C23 on the other hand landed a bunch of hard changes, and "it didn't break my code" only matches the reality most people observe with Rust too. The changes you mention didn't break my Rust either. But some trivial C did break because C23 is a new language https://c.godbolt.org/z/n9vhMGYW5 https://c.godbolt.org/z/n9vhMGYW5 In fact those Rust changes aren't language changes unlike C23, the first you linked is a choice for the compiler to improve on layout it didn't guarantee, anybody who was relying on that layout (and there were a few) was never promised this wouldn't change, next version, next week or indeed the next time they compiled the same code. You can even ask Rust's compiler to help light a fire under you on this by arbitrarily changing some layout between builds, so that stuff which depends on unpromised layout breaks earlier, reminding you to actually tell Rust e.g. repr(C) "I need the same layout guarantees for my type T as I'd get in C" or repr(transparent) "I need to ensure my type wrapper T has the same layout as the type I'm wrapping" The second isn't a language change at all, it's a change to a library feature, so now we're down to "C isn't stable until the C library is forever unchanging" which hopefully you recognise as entirely silly. Needless to say nobody does that.