4 ms·

Rust promises backwards compatibility, but I'm not aware of any language that promises forwards compatibility -- not even C. C compilers from 1999 aren't able t

Rust promises backwards compatibility, but I'm not aware of any language that promises forwards compatibility -- not even C. C compilers from 1999 aren't able to compile code that uses C11 features.

pjmlp 4y ago
And C23 compilers won't be able to compile code that still uses K&R, trigraphs, gets(), are free to ignore annexes made optional on C99 and still achieve ISO compliance.
- msla 4y ago
  What's more interesting to me is that C23 apparently removed support for non-two's-complement signed integers. Which vendors had to change position to get that change made, and what hardware had to officially get removed from serious consideration to make it happen? This site mentions UNISYS: https://en.cppreference.com/w/c/language/arithmetic_types https://en.cppreference.com/w/c/language/arithmetic_types
superkuh 4y ago
Correct. But other more mature languages, like C or Bash or whatever, have devs that don't immediately use bleeding edge features. Bash gets forwards incompatible features all the time but it's devs actually write for pretty much any OS from 2000 to now. Because it's mature. C11 wasn't required for a significant amount of C projects until close to 2020. As Rust grows and it's demographic changes from bleeding edge types to a more general purpose userbase hopefully their use of the latest forwards incompatible features stop and distro rustc compilers become useful for more than half a year. And you know this is true. Otherwise all the docs wouldn't be advocating for dangerous curl | sh rustc (into rustup) installs. You absolutely do not get this kind of community behavior in C where your system compiler is good for at least a decade.
- orf 4y ago
  Homebrew manages just fine. This also sounds entirely like a problem with the rather old packaging process that evolved from the historical mess of distributing C projects.
- pornel 4y ago
  I've moved away from C partly because I had to fight decades-old compilers. It's incredibly disheartening to realize I can't hope it will fix even smallest warts, because the series of multi-year lags of the standards process, implementation, LTS cycles, and laggard upgrades mean everything takes decades and C from 1999 is still "new". Distros need to get their act together. Downloading a tarball every few months is not hard, and Rust doesn't have the whole-OS-breaking UB fragility that a change of a system's C compiler may have.
  - kccqzy 4y ago
    At work I usually write C++17 but I recently just had to work on a project in C89. Going back 28 years is painful. Not to mention the instant reduction in productivity, but it made me seriously hate my job.
    - stouset 4y ago
      Yes, but just think of all the effort you saved by not having to run ${package_manager} update clang
    - pjmlp 4y ago
      ARM C++ was already better than dealing with C89.
- dijit 4y ago
  I'm not sure how I feel about this. On the one hand: I hate the growing trend of "everything bundled seperately" and "everything has it's own package manager". On the other... Why are you compiling things using packages? If your job is dev work then surely you have a bunch of tools that are unversioned by the OS? (Perhaps you've considered that they're not actually unversioned). VSCode, which updates in the background, intellij IDEA which updates into /opt. There is value in having it packaged, it helps you have a relatively deterministic system especially w.r.t. building other packages. But what does it actually give you the developer? Surely it's better to use the native tools for the language, which are tailored precisely for this and guarantee that your dependencies will be versioned correctly and available? It's not like the binaries you create using the compiler require you to have the compiler installed.
  - superkuh 4y ago
    I am an end user of programs people write in rust. Like when I tried to use a fast radio scanning software defined radio program written in rust. There was no compiled version. It was written 3 months after the version of compiler from my repos was released but still used forwards incompatible features. Or the time a web serial I was reading had a spider and epub generator written in rust. Approximately the same deal. And it's only become worse as my rustc became older than a few months. I am not a developer. I use my operating system to run software that other people write. Most of it like the above examples don't come from repos but the tools to compile them do. Or at least did until rust became popular.

Rust promises backwards compatibility, but I'm not aware of any language that promises forwards compatibility -- not even C. C compilers from 1999 aren't able to compile code that uses C11 features.

pjmlp 4y ago

And C23 compilers won't be able to compile code that still uses K&R, trigraphs, gets(), are free to ignore annexes made optional on C99 and still achieve ISO compliance.

msla 4y ago
What's more interesting to me is that C23 apparently removed support for non-two's-complement signed integers. Which vendors had to change position to get that change made, and what hardware had to officially get removed from serious consideration to make it happen? This site mentions UNISYS: https://en.cppreference.com/w/c/language/arithmetic_types https://en.cppreference.com/w/c/language/arithmetic_types

superkuh 4y ago

Correct. But other more mature languages, like C or Bash or whatever, have devs that don't immediately use bleeding edge features. Bash gets forwards incompatible features all the time but it's devs actually write for pretty much any OS from 2000 to now. Because it's mature. C11 wasn't required for a significant amount of C projects until close to 2020. As Rust grows and it's demographic changes from bleeding edge types to a more general purpose userbase hopefully their use of the latest forwards incompatible features stop and distro rustc compilers become useful for more than half a year. And you know this is true. Otherwise all the docs wouldn't be advocating for dangerous curl | sh rustc (into rustup) installs. You absolutely do not get this kind of community behavior in C where your system compiler is good for at least a decade.

orf 4y ago
Homebrew manages just fine. This also sounds entirely like a problem with the rather old packaging process that evolved from the historical mess of distributing C projects.
pornel 4y ago
I've moved away from C partly because I had to fight decades-old compilers. It's incredibly disheartening to realize I can't hope it will fix even smallest warts, because the series of multi-year lags of the standards process, implementation, LTS cycles, and laggard upgrades mean everything takes decades and C from 1999 is still "new". Distros need to get their act together. Downloading a tarball every few months is not hard, and Rust doesn't have the whole-OS-breaking UB fragility that a change of a system's C compiler may have.
- kccqzy 4y ago
  At work I usually write C++17 but I recently just had to work on a project in C89. Going back 28 years is painful. Not to mention the instant reduction in productivity, but it made me seriously hate my job.
  - stouset 4y ago
    Yes, but just think of all the effort you saved by not having to run ${package_manager} update clang
  - pjmlp 4y ago
    ARM C++ was already better than dealing with C89.
dijit 4y ago
I'm not sure how I feel about this. On the one hand: I hate the growing trend of "everything bundled seperately" and "everything has it's own package manager". On the other... Why are you compiling things using packages? If your job is dev work then surely you have a bunch of tools that are unversioned by the OS? (Perhaps you've considered that they're not actually unversioned). VSCode, which updates in the background, intellij IDEA which updates into /opt. There is value in having it packaged, it helps you have a relatively deterministic system especially w.r.t. building other packages. But what does it actually give you the developer? Surely it's better to use the native tools for the language, which are tailored precisely for this and guarantee that your dependencies will be versioned correctly and available? It's not like the binaries you create using the compiler require you to have the compiler installed.
- superkuh 4y ago
  I am an end user of programs people write in rust. Like when I tried to use a fast radio scanning software defined radio program written in rust. There was no compiled version. It was written 3 months after the version of compiler from my repos was released but still used forwards incompatible features. Or the time a web serial I was reading had a spider and epub generator written in rust. Approximately the same deal. And it's only become worse as my rustc became older than a few months. I am not a developer. I use my operating system to run software that other people write. Most of it like the above examples don't come from repos but the tools to compile them do. Or at least did until rust became popular.