6 ms·

A problem with previous efforts to replace C has been their ambition; "Why not fix all the other issues too?" Then we get languages with Opinions and "you can'

A problem with previous efforts to replace C has been their ambition; "Why not fix all the other issues too?" Then we get languages with Opinions and "you can't do that 'cuz its Wrong;" or in the enlightened "free" languages, "you can do that, but only after a bunch of syntactic apologia and Guilt." But the simple "C with bounds checking" answer doesn't fly because "why go to the trouble for a tiny, incremental gain?"

kragen 3y ago
wasm sort of gives you c with bounds checking; so does cheri
- pjmlp 3y ago
  No it doesn't, there are no bounds checking inside linear memory segments, unless there is a magical C compiler generating tons of linear memory segments for each variable indivually. SPARC ADI, ARM MTE and CHERI are the only ones doing it right.
  - kragen 3y ago
    it sounds like you're talking about wasm, since you say cheri is doing it right. wasm indeed only has one single linear memory for the entire 'module', roughly its equivalent of a unix process
injb 3y ago
I'm not much of a C programmer but my gut feeling on this is that is isn't ever going to be resolved by debating or reasoning of any kind. It'll be fixed when someone does something that makes some other language more relevant. C didn't get popular because of a consensus. It got popular because of Unix. Python got popular because of Django. We're stuck with C until someone builds something more important than Linux using some other language.
sneed_chucker 3y ago
I mean Go is really close to that. It even ported C's (lack of an) error handling model.
- alisonatwork 3y ago
  Go scratched my itch of wanting something that would run at native compiled speeds on every platform I was likely to encounter in my everyday life, which is Windows on the desktop, Linux on the servers and Mac if I'm working for a company that forces developers to use Mac. It's great for writing little command line tools and lightweight services/daemons. The thing Go isn't very good at is writing operating systems or firmware or other things with very strict memory requirements, so I don't see it replacing C in those domains. I'm not sure what will. I wonder if it will be Zig, because every time I see some Zig code it looks comfortable and familiar to me (as a long-lapsed C programmer) but also better, which is a similar feeling I had when I first saw Go.
  - snovymgodym 3y ago
    Go was never supposed to replace C for OS or firmware. Go was pretty explicitly designed by Google as a replacement for both C++ and Java in application code. It beats Java by having compiled executables with no JIT warmup, and it beats C++ by having memory safety (especially in the pre C++11 days when Go was designed). A bunch of Go's design decisions seemed to be in reaction to the complexity that emerges in Enterprise/OOP Java, C++, and C# codebases. Therefore, no classes, no exceptions, and no generics until very recently. All that makes coding in Go feel like you're writing "new C". (Ken Thompson and Rob Pike being one the core team for Go probably also added to this).
    - neonsunset 3y ago
      "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike Go does not and cannot replace C/C++/Rust family of languages, nor can it replace C# at writing higher-level HPC code (lack of cross-platform SIMD API, zero-cost interop, hardware intrinsics, etc.), something you do to drastically reduce the maintenance effort compared to doing so in C++. And lastly it's still unfortunate it replaces JVM family which goes to show how abysmal the basics of dev UX are in some aspects of it, because it has the most advanced JIT compiler implementations that Go will never be able to compete with.
pornel 3y ago
I think that’s why Rust managed to get a foot in the door. It doesn’t look like C with an extra feature or two, so it doesn’t get dismissed as an incremental improvement that could be DIYed in C instead (at least not by people who understand what Rust does). Safety helps justify use of Rust it in places where this is important, but developers stick with it for all the other quality of life improvements. If you only fix safety in C, you’ll still have C, with all the 1970’s clunkiness.

kragen 3y ago

wasm sort of gives you c with bounds checking; so does cheri

pjmlp 3y ago
No it doesn't, there are no bounds checking inside linear memory segments, unless there is a magical C compiler generating tons of linear memory segments for each variable indivually. SPARC ADI, ARM MTE and CHERI are the only ones doing it right.
- kragen 3y ago
  it sounds like you're talking about wasm, since you say cheri is doing it right. wasm indeed only has one single linear memory for the entire 'module', roughly its equivalent of a unix process

injb 3y ago

I'm not much of a C programmer but my gut feeling on this is that is isn't ever going to be resolved by debating or reasoning of any kind. It'll be fixed when someone does something that makes some other language more relevant. C didn't get popular because of a consensus. It got popular because of Unix. Python got popular because of Django. We're stuck with C until someone builds something more important than Linux using some other language.

sneed_chucker 3y ago

I mean Go is really close to that. It even ported C's (lack of an) error handling model.

alisonatwork 3y ago
Go scratched my itch of wanting something that would run at native compiled speeds on every platform I was likely to encounter in my everyday life, which is Windows on the desktop, Linux on the servers and Mac if I'm working for a company that forces developers to use Mac. It's great for writing little command line tools and lightweight services/daemons. The thing Go isn't very good at is writing operating systems or firmware or other things with very strict memory requirements, so I don't see it replacing C in those domains. I'm not sure what will. I wonder if it will be Zig, because every time I see some Zig code it looks comfortable and familiar to me (as a long-lapsed C programmer) but also better, which is a similar feeling I had when I first saw Go.
- snovymgodym 3y ago
  Go was never supposed to replace C for OS or firmware. Go was pretty explicitly designed by Google as a replacement for both C++ and Java in application code. It beats Java by having compiled executables with no JIT warmup, and it beats C++ by having memory safety (especially in the pre C++11 days when Go was designed). A bunch of Go's design decisions seemed to be in reaction to the complexity that emerges in Enterprise/OOP Java, C++, and C# codebases. Therefore, no classes, no exceptions, and no generics until very recently. All that makes coding in Go feel like you're writing "new C". (Ken Thompson and Rob Pike being one the core team for Go probably also added to this).
  - neonsunset 3y ago
    "The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." - Rob Pike Go does not and cannot replace C/C++/Rust family of languages, nor can it replace C# at writing higher-level HPC code (lack of cross-platform SIMD API, zero-cost interop, hardware intrinsics, etc.), something you do to drastically reduce the maintenance effort compared to doing so in C++. And lastly it's still unfortunate it replaces JVM family which goes to show how abysmal the basics of dev UX are in some aspects of it, because it has the most advanced JIT compiler implementations that Go will never be able to compete with.

pornel 3y ago

I think that’s why Rust managed to get a foot in the door. It doesn’t look like C with an extra feature or two, so it doesn’t get dismissed as an incremental improvement that could be DIYed in C instead (at least not by people who understand what Rust does). Safety helps justify use of Rust it in places where this is important, but developers stick with it for all the other quality of life improvements. If you only fix safety in C, you’ll still have C, with all the 1970’s clunkiness.