Hacker News Reader

Comment by 10x-dev | Hacker News Reader

In my experience (and to generalize a bit), people who shoot themselves in the foot with C are the same people who will shoot themselves in the foot with any other language.

Those who aren't careful enough to free up allocated memory are the same types of people who leak memory in Java.

You can't fix lack of knowledge with a compiler. You can only catch accidental mistakes, but that assumes that the norm is for the person to know what they are doing and a lot of people have only superficial knowledge of the tools they are using.

We already have accident catching tools for C. What C doesn't have is a helmet, training wheels and padded walls, which is by design.

View on HN

In my experience, people who shoot themselves in the foot with a magnetized needle are the same people who will shoot themselves in the foot with any other programming technique.

Those who aren't careful enough to only flip the bits they intend to when programming with a magnetized needle are the same types of people who overflow buffers in C.

We already have accident catching tools for magnetized needles. What a magnetic needle doesn't have is a helmet, training wheels and padded walls, which is by design.

It's telling that you chose to omit my memory leak example. Weak developers blame the tools.

Quoting from the article:

> AS IT TURNS OUT, good craftspeople don't shy away from questioning, criticizing, and trying to improve their tools (or even switching to other tools entirely!)

C is the best tool for a lot of use cases, but no tool can be a perfect fit for every use case. This is the reason that multiple programming languages exist and the world has not converged on using only C everywhere. Also, there are properties not intrinsic to the language that also affect the fit.

Saying "it's easy to shoot yourself in the foot with C" is not constructive criticism because what's easy for you could be difficult for me.

If the Rust fanboy brigade could articulate actual criticism for C, such as the lack of imports, or eskewing the type system with void*, or the signedness of char, or any of the other topics beaten to death in online "C gotchas" power point presentations, then we could have a constructive conversation amongst craftspeople.

> Saying "it's easy to shoot yourself in the foot with C" is not constructive criticism because what's easy for you could be difficult for me.

That’s a fair point. Unfortunately I think that in order to really talk about the pros and cons, we’d need a relatively specific situation. Toy examples are just that… toy examples. FWIW most of the time I will make language choices based on the expected lifetime of a particular project, the relative expertise of team members working on a project, and the ease of delivering bug fixes.

I believe that Rust users are past caring about that.

If you feel that C is a good language for your needs, then by all means, use it.

I know that Rust brings me a very efficient safety net that lets me concentrate on the algorithm [1] without having to also spend quite as much time auditing, fuzzing, valgrinding and {thread, memory, ...} sanitizing my code. In addition to the safety added by the type-system, I also enjoy the convenience of tools such as `Drop`, or the ability to derive (de)serializers for most formats, etc.

This is not about criticizing C. This is about picking the best tool for the job. Sometimes, it is Rust. Sometimes, it is TypeScript. I haven't encountered a job for which C was the best tool for me in a while. I'm sure that there are cases, mind you, but I don't encounter them anymore.

[1] With caveats, of course. As all Rust users, I need to please the borrow-checker gods.

> You can't fix lack of knowledge with a compiler.

The original article and the Rust language would beg to differ. The compiler generates detailed, didactic error messages with actionable suggestions.

Note that rust doesn't claim to catch all errors, and the article points out places where it doesn't. In rust it is a lot harder to get into those situations accidentally, but you can.

Most of the incorrect code on the article for rust is quite contrived though. It's not perfect, just better, or more strict.

Any non contrived example would be thousands of lines of code. Rust is meant for those areas where you are forced to do weird things, it does it's best but they don't know how to solve the problem of what they need in a way that can't be misused.

Seeing how contrived the examples are makes me more interested in rust.

I use it professionally, and can say: it's worth it. Even the warts are minor compared to how polished and intuitive the language feels after you accept it's dogmas (or die fighting against the borrow checker).

The error messages are very good, cargo is awesome, rust analyzer is already good but still needs some time to flourish, and the performance in production is really predictable. It's for sure not perfect, but in many aspects it feels like a step forward, so much that sometimes I'm wary on how much I'm relying on the compiler to check my decisions for me.

So does clang and GCC at this point.

Yes, that supports my point that it’s a useful and helpful thing to add to a compiler.

Reply on news.ycombinator.com