3 ms·

C programmers NO! You can't do that, that would break compatibility! also C programmers Wow, You are trying to compile this old program on new toolchain? Here

by Xeamek 2y ago

C programmers NO! You can't do that, that would break compatibility! also C programmers Wow, You are trying to compile this old program on new toolchain? Here is a list of 10k errors due to changed defaults flags for compilation, dependencies breaking by going from 9.4.1 to 9.4.2 and also, your code contains platform-specific extensions anyway. But C is portable guys! It really is!

jeroenhd 2y ago
But that's the thing, code bases are full of non-standard C, but they never break because the C standard changes, only because their weird hacks are falling out of favour. Fixing a design flaw in C will break all existing code, instead of the code of the dozens of companies relying on weird hacks they wrote ten years ago. Once Zig becomes stable, I think it may have a chance of slowly fixing existing C code bases, by its virtue of being able to co-exist with existing code bases. On the other hand, a lot of C programmers don't want to change because they don't see a problem, so the presence of those will probably ruin any chance Zig has of improving the situation.
- samatman 2y ago
  Other than the pessimistic finish, my prediction is that this is exactly what will happen. The change will be a generational one. C will never entirely disappear, but over time, C code will be old code. People will occasionally write new C for what amounts to aesthetic reasons, and there will be a robust niche (doubtless well-paid) of maintainers of legacy C projects. All the kernels currently written in C will still exist, and still be composed mostly or entirely of C. But new work in embedded, drivers, implementation of programming languages, netork stacks, will be in Zig instead. With some Rust as well, but I figure we've seen enough of that arc to tentatively conclude that what Rust is displacing is mostly C++, not C. But when I say generational, I mean it. You're quite right that there is a legion of C programmers who like it and intend to stick with it. But they'll retire one day.
  - jeroenhd 2y ago
    Except for maybe in kernel projects, C code already is old code. As far as I can tell, (modern) C++ is the oldest common language for new projects. Rust is already part of the Linux kernel, being used for rather complex things like GPU drivers in Asahi. Android rewrote their Bluetooth stack into Rust and Windows is actively replacing existing operating system components with Rust as well. I don't think we'll need to wait for Zig to start replacing old C code, it's already being replaced with Rust now. I think Zig would've been a better choice for some parts, but it's taking too long to become stable for it to be included in large projects. Still, it may be useful for people working on embedded stuff, as embedded code seems to be stuck with 90s C when it comes to language support, if someone can manage to write a compiler backend for that specific embedded chip.
  - pjmlp 2y ago
    In many places outside the UNIX FOSS sphere and hardcore embedded devs, C++ keeps replacing C already, that includes Apple, Google and Microsoft OSes. While Rust might be a better alternative, C++ is already much better than raw C.
- qiqitori 2y ago
  > Once Zig becomes stable Zig was introduced in 2016. If it still isn't stable 8 years later, I wouldn't hold my breath.
  - jeroenhd 2y ago
    Rust began in 2006 and became stable in 2015. Zig still has a year at the very least! Zig lacks the corporate backing Rust had, though, so it's hard to say when they'll get stable. Regardless, even if it'll take Zig a decade, I'm sure it'll have a stable release with decent memory management as part of the language spec before C will.
    - pjmlp 2y ago
      Zig is basically the Modula-2 features (1978) in a more C like friendly packaging, with an additional metaprogramming capabilities. It needs a bit more than only corporate backing for taking off, something that makes it unavoidable, specially given the alternatives.
pdw 2y ago
That makes sense when you realize that what C folks care about more than anything else is _ABI compatibility_. Changes to language or toolchain are acceptable as long as they don't change the ABI. E.g. consider the hemming and hawing about a 64-bit time_t. That's a tiny change in comparison, and one that's obviously unavoidable and with a strict deadline. And yet...
- kukkamario 2y ago
  64-bit time has already been resolved in newer 32-bit Linux versions. Issue isn't that changing ABI couldn't be done. It is that no one wants to update OS and custom software of a 15-year-old embedded system that still works. Archeology to find correct instructions to build a working OS image is challenge itself and then there is a need to adapt them to more modern tools. Been there, done that, and it wasn't fun...
- zzo38computer 2y ago
  > E.g. consider the hemming and hawing about a 64-bit time_t. I had received a compiler warning about this when trying to compile a program on Raspberry Pi (it was a old version; I did this a few days before they implemented 64-bit time_t on Raspberry Pi). Fortunately I was able to add a macro to allow it to work on computers without 64-bit time_t. Other than that, the program I compiled worked perfectly, although I wrote the program on PC and did not specifically try to make it work with Raspberry Pi. So, a C code is portable, although sometimes a few changes are required to make the program to work. But I think that 64-bit time_t is a good idea.

by Xeamek 2y ago

jeroenhd 2y ago

But that's the thing, code bases are full of non-standard C, but they never break because the C standard changes, only because their weird hacks are falling out of favour. Fixing a design flaw in C will break all existing code, instead of the code of the dozens of companies relying on weird hacks they wrote ten years ago. Once Zig becomes stable, I think it may have a chance of slowly fixing existing C code bases, by its virtue of being able to co-exist with existing code bases. On the other hand, a lot of C programmers don't want to change because they don't see a problem, so the presence of those will probably ruin any chance Zig has of improving the situation.

samatman 2y ago
Other than the pessimistic finish, my prediction is that this is exactly what will happen. The change will be a generational one. C will never entirely disappear, but over time, C code will be old code. People will occasionally write new C for what amounts to aesthetic reasons, and there will be a robust niche (doubtless well-paid) of maintainers of legacy C projects. All the kernels currently written in C will still exist, and still be composed mostly or entirely of C. But new work in embedded, drivers, implementation of programming languages, netork stacks, will be in Zig instead. With some Rust as well, but I figure we've seen enough of that arc to tentatively conclude that what Rust is displacing is mostly C++, not C. But when I say generational, I mean it. You're quite right that there is a legion of C programmers who like it and intend to stick with it. But they'll retire one day.
- jeroenhd 2y ago
  Except for maybe in kernel projects, C code already is old code. As far as I can tell, (modern) C++ is the oldest common language for new projects. Rust is already part of the Linux kernel, being used for rather complex things like GPU drivers in Asahi. Android rewrote their Bluetooth stack into Rust and Windows is actively replacing existing operating system components with Rust as well. I don't think we'll need to wait for Zig to start replacing old C code, it's already being replaced with Rust now. I think Zig would've been a better choice for some parts, but it's taking too long to become stable for it to be included in large projects. Still, it may be useful for people working on embedded stuff, as embedded code seems to be stuck with 90s C when it comes to language support, if someone can manage to write a compiler backend for that specific embedded chip.
- pjmlp 2y ago
  In many places outside the UNIX FOSS sphere and hardcore embedded devs, C++ keeps replacing C already, that includes Apple, Google and Microsoft OSes. While Rust might be a better alternative, C++ is already much better than raw C.
qiqitori 2y ago
> Once Zig becomes stable Zig was introduced in 2016. If it still isn't stable 8 years later, I wouldn't hold my breath.
- jeroenhd 2y ago
  Rust began in 2006 and became stable in 2015. Zig still has a year at the very least! Zig lacks the corporate backing Rust had, though, so it's hard to say when they'll get stable. Regardless, even if it'll take Zig a decade, I'm sure it'll have a stable release with decent memory management as part of the language spec before C will.
  - pjmlp 2y ago
    Zig is basically the Modula-2 features (1978) in a more C like friendly packaging, with an additional metaprogramming capabilities. It needs a bit more than only corporate backing for taking off, something that makes it unavoidable, specially given the alternatives.

pdw 2y ago

That makes sense when you realize that what C folks care about more than anything else is _ABI compatibility_. Changes to language or toolchain are acceptable as long as they don't change the ABI. E.g. consider the hemming and hawing about a 64-bit time_t. That's a tiny change in comparison, and one that's obviously unavoidable and with a strict deadline. And yet...

kukkamario 2y ago
64-bit time has already been resolved in newer 32-bit Linux versions. Issue isn't that changing ABI couldn't be done. It is that no one wants to update OS and custom software of a 15-year-old embedded system that still works. Archeology to find correct instructions to build a working OS image is challenge itself and then there is a need to adapt them to more modern tools. Been there, done that, and it wasn't fun...
zzo38computer 2y ago
> E.g. consider the hemming and hawing about a 64-bit time_t. I had received a compiler warning about this when trying to compile a program on Raspberry Pi (it was a old version; I did this a few days before they implemented 64-bit time_t on Raspberry Pi). Fortunately I was able to add a macro to allow it to work on computers without 64-bit time_t. Other than that, the program I compiled worked perfectly, although I wrote the program on PC and did not specifically try to make it work with Raspberry Pi. So, a C code is portable, although sometimes a few changes are required to make the program to work. But I think that 64-bit time_t is a good idea.