Hacker News Reader

Comment by svnt | Hacker News Reader

I like firearms as an analogy here.

Rust is like a modern rifle, unloaded, with six safeties and three locked triggers in a gun safe. The ammunition will harmlessly self-destruct if you don’t focus properly before firing.

C is sort of like Rust except the rifle is on the couch, loaded, one in the chamber, all the safeties are off, the numerous open triggers are held by RNGs, and the business end is pointed right at your most prized possession.

It is fun, in a way. Use it in an environment that you don’t care too much about.

View on HN

Ha.

Confession time: I came to this thread to Ctrl-F for "Rust" to find the Rust-C fisticuffs. And this answer is like what I would expect if I said "ChatGPT, write me a reddit-style Rust defense that would rustle some jimmies."

I'm about equally capable at both Rust and C - I could pass a 1st year undergrad CS course using either, but I'm no better than that.

I know C has its place - its marketshare of embedded devices and gamedev is huuuge - and Rust... may eventually reach a similar place of importance, but isn't there yet.

I also know the very best C and Rust devs are pretty much geniuses - Ph.D. level understanding of math, that kind of thing - and would squash me in any type of fair competition.

Maybe in the year 2050, an attitude of condescending acceptance towards C might be appropriate. And also... maybe not, because C might not slip. Who knows?

And really, beyond this pretty crude but accurate-ish description, I think we're getting into unnecessary hair-splitting, among people who don't work with either and wouldn't understand the tradeoffs anyway.

There is a lot of nuance in this discussion that someone inexperienced could misinterpret, you’re definitely right about that.

Meh. People love to hate on C but the invariants you have to keep track of are relatively simple (things like 0<=i<L.) Most languages replace these with multi-dimensional string based hashmaps that have much more complex invariants to keep track of and similar consequences for failing to do so.

Some languages like Rust and Haskell do a little better by having the compiler keep track of most of them (if you use it right) but the consequence of misunderstanding them here is accidentally coding yourself into a corner which is extremely unpleasant.

There are other things people like to talk about like automatic memory management and package management and again I'm not convinced these really improve much. The pain of allocating memory in C means people often find ways to avoid doing it altogether which results in much more predictable behavior. Same with pulling in third party libraries. It's rare using more than a couple is actually beneficial but when the package manager is there the temptation is way too much for most people and the result is both unpleasant and very vulnerable to supply chain attacks.

I'm still not convinced any of this is the improvement people think it is.

I mean I’ve worked with C for a long time. It’s love-hate. I think it’s hard to see the value from the other side of having internalized C, and Rust definitely encumbers you.

The number of things a beginner doesn’t have to know or worry about to code something as essential as a function that reads a file, searches for a string, and interacts in a serious way with the network in Rust vs C is substantial.

Probably I’ll get downvoted again but it’s fine.

But you do learn from such things (opening a file, reading from the network). All the stuff that can go wrong, and that it all has to be handled. Like writing a device driver.

It’s useful to write that C code, and then try to break it (e.g., to force a segfault rather than a proper error-then-exit).

Is knowing all that necessary? No, as you are kind of implying. ;-)

> the invariants you have to keep track of are relatively simple (things like 0<=i<L.)

If maintaining these invariants were so simple, why would the smartest people in the industry have so much trouble doing so? Humans cannot consistently write correct C, not even the ones who believe they can. We have decades of evidence.

> Most languages replace these with multi-dimensional string based hashmaps that have much more complex invariants to keep track of and similar consequences for failing to do so.

This take reflects a profound ignorance of the relative severity of different kinds of software defect.

When you get an array bound wrong in Java or Rust, you get an exception or a panic. Your program exits and restarts. You get a ticket for fixing the bug. Life goes on.

When you get an array bound wrong in C, you open the door for a nefarious actor to gain control over everything that your program can access.

These aren't similar consequences. They're not even on the same planet of consequences. C apologists are like apologists for asbestos and lead paint.

> Humans cannot consistently write correct C,

So? Humans cannot consistently write correct code in any language.

> When you get an array bound wrong in C, you open the door for a nefarious actor to gain control over everything that your program can access.

What's really interesting to me is how Heartbleed (the largest example of getting an array bound wrong) was orders of magnitude less expensive to fix than Log4j, and yet it was Log4j that resulted in gauranteed RCE, not Heartbleed.

> C apologists are like apologists for asbestos and lead paint.

Let's not go spilling hyperbole all down our shirt.

I get the feeling that a lot of people comparing C to things that kill have never worked in life-critical situations, the systems of which ran C for decades and decades, and never appeared to have lost very many lives in the process.

Military, munitions, healthcare machines ... I can't remember any of them losing lives because of a misfeature in the C programming language, and yet there you are, proudly proclaiming to the word that C is like Asbestos, which has taken peoples lives.

Get a grip.

My point is that they can't consistently write correct software in any language. Javascript for example has similar issues where if you're not careful about which keys in a hashmap you write to you can create situations that allow for all kinds of things including arbitrary code execution.

Modern C compilers/runtimes also have bounds checking (although I've never used it) like java if you want to use it.

Sure there's some improvement but it's not nearly as extreme as it's made out to be.

It's true that humans will inevitably produce software with defects. There are differences in the impacts of these defects.

> Javascript for example has similar issues where if you're not careful about which keys in a hashmap you write to you can create situations that allow for all kinds of things including arbitrary code execution.

Not without eval() you can't.

> Modern C compilers/runtimes also have bounds checking

No, they don't. There are C-like languages (e.g. C++/CLI) that do, and you can use containers, but no, plain C cannot do bounds checking. There's no room in the ABI for it, at least not without CHERI or ASAN.

> although I've never used it

One of the most dangerous things in the world is giving powerful tools to people who don't know that they shouldn't use them.

> My point is that they can’t consistently write correct software in any language. Javascript for example

I don’t think Javascript is the counterexample you want to use as a good language. It is like C where safety is traded for flexibility.

If people can’t write correct software in any language, the language designers can help, which is exactly what the Rust designers did.

It’s not great for everyone because now all the scar tissue that great C devs have around what near-fatal errors they’ve made previously has lost some of its value.

This analogy is really more like dogmatic Rustacean-ism than actual truth. Rust has it's merits. However, it's a tired language. It doesn't maintain very good stability due to it's ever-evolving compiler which makes it almost unusable in anything but a "move fast and break things" environment. It's too particular, making development a burden and interrupting flow. Most importantly, the community is absolutely exhausting to listen to and this post is a perfect example.

C can be dangerous, yes. No one is denying that. C is also extremely stable, fast, and a "known-known". With proper discipline that any experienced developer of ANY language will have C can be very safe. Most, if not all, dangerous errors can be found and fixed simply by understanding how to use valgrind. With the advent of modern CI/CD it's never been easier to remember to valgrind your code.

C is probably the first language I would use in an environment I cared a lot about. For example, if binary size, availability of libraries, competency of programmer, etc would be in my list of concerns I would use C. I take particular offense to the "RNG" part of your analogy. C errors are not random at all. They are always the developer's fault and are often very predictable (use-after-free, poor array hygiene, etc). Despite the ever-evolving condition of post-C religions (Go, Rust, etc) there are only a handful of languages that fit the bill for a so-called serious systems project. C, C++, Java, and C#. You simply will not find a better library ecosystem and community of highly tenured developers to draw from for at least another decade in other languages.

I don’t even prefer Rust to C personally, and I’m not a dogmatic sort. My analogy wasn’t particularly complimentary to either language.

If some people are too sensitive to take a little caricaturization of C in stride, maybe those people should examine those sensitivities.

Edit because I didn’t read your comment all the way through: uninitialized memory is RNG, functionally.

Reply on news.ycombinator.com