Eric S. Raymond tweet on current C safety issues | Hacker News Reader

Eric S. Raymond tweet on current C safety issues

twitter.com

15 pointspjmlp13 comments

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?"

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

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.

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

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.

I mean Go is really close to that.

It even ported C's (lack of an) error handling model.

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.

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).

"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.

Go was designed by a group of people not found of C++ or Java, to this day Go remains a minority inside Google, used mostly alongside Kubernetes or gVisor workloads.

Java, C++, Python and nowadays Rust, are the key programming stacks.

Java has had AOT compilation since early 2000's, however it was gated behind commercial JDKs, like Excelsior JET.

Nowadays free beer AOT is available in GraalVM, OpenJ9, and Android since version 5.

Pity that they forgot about enum in the process, and rather use something that is hardly any better than #define MY_CONSTANT num.

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.

The real issue is there is legacy code written 40 years ago that no one wants to update.

Reply on news.ycombinator.com