3 ms·

The replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious one

by okanat 9mo ago

The replacement has already happened. It is HTTP and JSON for 99% of the software developed today. The reason C stayed has multiple reasons but most obvious ones are for me are: - People just stopped caring about operating systems research and systems programming after ~2005. Actual engineering implementations of the concepts largely stopped after the second half of 90s. Most developers moved on to making websites or applications in higher level programming languages. - C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax and code length and quite easy to implement compilers for. This caused lots of legacy software being built into the infrastructure that gave birth to the current contemporary popular OSes and more importantly the infrastructure of the Internet. Add in .com bubbles and other crises, we basically have/had zero economic incentive to replace those systems. - Culture changed. We cared more about stability, repairability and reusability. Computers were expensive. So are programmers and software. Now computers are cheap. Our culture is more consumerist than ever. The mentality of "move fast and break things" permeated so well with economic policy and the zeitgeist. With AI it will get worse. So trying to make a real alternative to C (as a generic low level OS protocol) has reduced cultural value / optics. It doesn't fill the CVs as well. It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia.

kogasa240p 9mo ago
>Culture changed. We cared more about stability, repairability and reusability. Computers were expensive. So are programmers and software. Now computers are cheap. Our culture is more consumerist than ever. The mentality of "move fast and break things" permeated so well with economic policy and the zeitgeist. With AI it will get worse. So trying to make a real alternative to C (as a generic low level OS protocol) has reduced cultural value / optics. It doesn't fill the CVs as well. IMO I do see this changing in the future as higher power computers become expensive once again, and I'm not just referring to the recent chip shortage.
trueismywork 9mo ago
Name me a stable binary interface that is not ints and arrays of ints
- pjmlp 9mo ago
  COM, WinRT, XPC, AIDL. Now you can move the goal posts and assert that any data serialized into a memory buffer is an array of ints.
- okanat 9mo ago
  C ABI is more than how ints and array of ints sit next to each other in memory. It cares about calling conventions and what you can store in registers vs what you cannot. There are multiple possible ways of doing an RPC call and C ABI only provides one way of doing it.
- kevin_thibedeau 9mo ago
  How big is an int?
noosphr 9mo ago
I'd never thought I'd see the day that anyone praises COM.
- pjmlp 9mo ago
  As idea it is great, as the tooling available in C++ Builder, Delphi, VB 6, C++/CX (WinRT is basically COM with extras) also great. Using it from MFC, kind of alright. Using it from .NET, depends if Framework, .NET Native, or modern, with various levels of usability. Using it from ATL, WRL, C++/WinRT, is a mess unfortunely.
- tonyedgecombe 9mo ago
  If you read Don Box’s book on COM he goes through every decision they made and the rationale for it. It all seemed to make sense. Unfortunately I think Don Box’s was the only person in the world who really understood it all.
- okanat 9mo ago
  Compared to wobbly types in C and hidden contracts due to C compiler internals, COM's IDL-based approach is much better!
sinnsro 9mo ago
> It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia. I am not sure I buy this from a system perspective, especially when taking this[1] into consideration. ______ 1. Alexis King's reply to "Why do common Rust packages depend on C code?". Link: https://langdev.stackexchange.com/a/3237 https://langdev.stackexchange.com/a/3237
chasil 9mo ago
In pieces of my code, I need to call setuserid() to manage some of the security that I designed in 2010. There was no Rust at that point, and I used the most basic tool that could do it. Could I have done this in Java with gymnastics of JNI, linking C into the JRE? Definite maybe.
- pjmlp 9mo ago
  Yes, nowadays with Panama, and before Rust was around, JNA was already there so using JNI wasn't strictly necessary.
  - direwolf20 9mo ago
    JNA is a whole dependency of its own, shame it's not built into the JRE
    - pjmlp 9mo ago
      It is nowadays, that is what Panama is for. Unless one is stuck with Android Java, Google's J++.
PaulDavisThe1st 9mo ago
> People just stopped caring about operating systems research and systems programming after ~2005. and so it was that after that date, all development of embedded systems kernel drivers digital audio workstations video editors codecs for audio and video anything that involved actually controlling non-computer hardware game engines came to a grinding halt, and no further work was done.
- pjmlp 9mo ago
  On Windows, macOS and Android, most of that development on that list is done in C++, not C.
- okanat 9mo ago
  What I mean is all of those things are more of the same things we did since 90s. It is better and higher performing hardware but until Rust and Zig arrived, the most popular ways of designing system-level software stayed the same. RTOSes work the same as how they work in late 90s / early 00s. C ABI is still the majority of communication interface. Interacting with OS using system calls stayed the same. After virtual memory and paging no big change in OS design happened. Main programming design patterns in C and C++ also stayed the same. One area that stayed interesting is GPU programming. Nowadays CPUs basically provide us a PDP-11 simulator. Most of the time you don't need to recompile programs to harness most of the gains from a CPU. GPUs expose more of their internal hardware detaila than CPUs and unlike CPUs you need to recompile programs (which is what a GPU userspace driver does) to use newer models.
  - pjmlp 9mo ago
    Nowadays, NVidia designs their GPUs for C++, not C. "Designing (New) C++ Hardware" - https://www.youtube.com/watch?v=86seb-iZCnI https://www.youtube.com/watch?v=86seb-iZCnI And now with tiled architecture, Python JIT as well.
jacinabox 9mo ago
If you think about it, those who shape mainstream opinion on operating systems were always mostly bought off, and invested in the mainstream operating systems. That investment meant that a niche operating system like Plan9 or BeOS was never going to see wide support from the opinion shapers, even if those OSes had some interesting ideas.
xigoi 9mo ago
> C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax C is a complex language with complex syntax. The C specification is, like, 800 pages. And good luck implementing a C parser as easily as you could a Scheme parser.

by okanat 9mo ago

kogasa240p 9mo ago

>Culture changed. We cared more about stability, repairability and reusability. Computers were expensive. So are programmers and software. Now computers are cheap. Our culture is more consumerist than ever. The mentality of "move fast and break things" permeated so well with economic policy and the zeitgeist. With AI it will get worse. So trying to make a real alternative to C (as a generic low level OS protocol) has reduced cultural value / optics. It doesn't fill the CVs as well. IMO I do see this changing in the future as higher power computers become expensive once again, and I'm not just referring to the recent chip shortage.

trueismywork 9mo ago

Name me a stable binary interface that is not ints and arrays of ints

pjmlp 9mo ago
COM, WinRT, XPC, AIDL. Now you can move the goal posts and assert that any data serialized into a memory buffer is an array of ints.
okanat 9mo ago
C ABI is more than how ints and array of ints sit next to each other in memory. It cares about calling conventions and what you can store in registers vs what you cannot. There are multiple possible ways of doing an RPC call and C ABI only provides one way of doing it.
kevin_thibedeau 9mo ago
How big is an int?

noosphr 9mo ago

I'd never thought I'd see the day that anyone praises COM.

pjmlp 9mo ago
As idea it is great, as the tooling available in C++ Builder, Delphi, VB 6, C++/CX (WinRT is basically COM with extras) also great. Using it from MFC, kind of alright. Using it from .NET, depends if Framework, .NET Native, or modern, with various levels of usability. Using it from ATL, WRL, C++/WinRT, is a mess unfortunely.
tonyedgecombe 9mo ago
If you read Don Box’s book on COM he goes through every decision they made and the rationale for it. It all seemed to make sense. Unfortunately I think Don Box’s was the only person in the world who really understood it all.
okanat 9mo ago
Compared to wobbly types in C and hidden contracts due to C compiler internals, COM's IDL-based approach is much better!

sinnsro 9mo ago

> It doesn't mean that people haven't tried or even succeeded. Android was successful in multiple fronts in replacing C. Its "intents" and low level interface description language for hardware interfaces are great replacement for C ABI. Windows' COM is also a good replacement that gets rid of language dependence. There are still newer OSes try like Redox or Fuchsia. I am not sure I buy this from a system perspective, especially when taking this[1] into consideration. ______ 1. Alexis King's reply to "Why do common Rust packages depend on C code?". Link: https://langdev.stackexchange.com/a/3237 https://langdev.stackexchange.com/a/3237

chasil 9mo ago

In pieces of my code, I need to call setuserid() to manage some of the security that I designed in 2010. There was no Rust at that point, and I used the most basic tool that could do it. Could I have done this in Java with gymnastics of JNI, linking C into the JRE? Definite maybe.

pjmlp 9mo ago
Yes, nowadays with Panama, and before Rust was around, JNA was already there so using JNI wasn't strictly necessary.
- direwolf20 9mo ago
  JNA is a whole dependency of its own, shame it's not built into the JRE
  - pjmlp 9mo ago
    It is nowadays, that is what Panama is for. Unless one is stuck with Android Java, Google's J++.

PaulDavisThe1st 9mo ago

> People just stopped caring about operating systems research and systems programming after ~2005. and so it was that after that date, all development of embedded systems kernel drivers digital audio workstations video editors codecs for audio and video anything that involved actually controlling non-computer hardware game engines came to a grinding halt, and no further work was done.

pjmlp 9mo ago
On Windows, macOS and Android, most of that development on that list is done in C++, not C.
okanat 9mo ago
What I mean is all of those things are more of the same things we did since 90s. It is better and higher performing hardware but until Rust and Zig arrived, the most popular ways of designing system-level software stayed the same. RTOSes work the same as how they work in late 90s / early 00s. C ABI is still the majority of communication interface. Interacting with OS using system calls stayed the same. After virtual memory and paging no big change in OS design happened. Main programming design patterns in C and C++ also stayed the same. One area that stayed interesting is GPU programming. Nowadays CPUs basically provide us a PDP-11 simulator. Most of the time you don't need to recompile programs to harness most of the gains from a CPU. GPUs expose more of their internal hardware detaila than CPUs and unlike CPUs you need to recompile programs (which is what a GPU userspace driver does) to use newer models.
- pjmlp 9mo ago
  Nowadays, NVidia designs their GPUs for C++, not C. "Designing (New) C++ Hardware" - https://www.youtube.com/watch?v=86seb-iZCnI https://www.youtube.com/watch?v=86seb-iZCnI And now with tiled architecture, Python JIT as well.

jacinabox 9mo ago

If you think about it, those who shape mainstream opinion on operating systems were always mostly bought off, and invested in the mainstream operating systems. That investment meant that a niche operating system like Plan9 or BeOS was never going to see wide support from the opinion shapers, even if those OSes had some interesting ideas.

xigoi 9mo ago

> C hit a perfect balance of being a small enough language to grok, being indepedent of the system manufacturers, reflecting the computer architecture of 80s, actually small in syntax C is a complex language with complex syntax. The C specification is, like, 800 pages. And good luck implementing a C parser as easily as you could a Scheme parser.