Hacker News Reader

Comment by catlifeonmars | Hacker News Reader

I don’t think that a simpler language and a helpful compiler are mutually exclusive. In the article, the author even points out multiple examples where Go (a simpler language, relative to Rust) could output more helpful error messages.

I assert it’s possible to have a simple language where it’s difficult to shoot yourself in the foot. C just happens to be a simple language where it’s exceedingly easy to shoot yourself in the foot.

View on HN

> I assert it’s possible to have a simple language where it’s difficult to shoot yourself in the foot

Zig would be one such example.

So why is Zig being dwarfed by Rust in this arena? Shouldn't Zig be more popular or is it still too small and immature?

Zig refers to itself with a version number < 1 and says that the language is not yet stable. That's going to filter the less adventurous crowd out right away. And that's probably ideal - zig can work out the kinks with the adventurous crowd and be better prepared for its post-1.0 life.

I haven't used Zig, but my understanding is that Zig is more comparable to C, whereas Rust is more comparable to C++. Zig is a much smaller and simpler language, but Rust has more high level constructs and abstractions.

I can't comment on either, but I do enjoy C and you can build relatively safe C programs using tools like Valgrind and static analysis. So unless you are building the next OpenSSL it could very well be worth sticking to C11.

> whereas Rust is more comparable to C++

That only in matter of complexity. If rust were actually comparable to C++ it will a major mess.

Rust is actually a ML + C + Haskell-ish lang..

And that's exactly why I am a bit worried about learning it. I am not looking for a language that is too theoretical, like Haskell.

It's a very practical language (more than C or C++). But it does have a challenging learning curve.

Pay no attention to how the language was derived. Just dive into it.

> I am not looking for a language that is too theoretical, like Haskell.

Rust is not "theoretical", but have some theory applied to great effect. The comparison to Haskell is more in the use functional idioms, algebraic types, pattern matching and bits here and there...

Rust is built to be 100% memory safe, not just "hard to misuse in practice". Of course the claim comes with some provisos about how you're always relying on 'unsafe' code, but there is real value to it. Zig is interesting but doesn't have that USP.

So basically Zig is a toy, Rust is for serious stuff.

That’s an oversimplification. There are many reasons to choose one programming language over another. Strong guarantees of memory safety is only one design parameter.

Is C a toy?

Zig just provides different guarantees.

Elm is a good example of what you’re talking about, though it “cheats” a bit by being quite domain specific.

Anyway it’s simultaneously a very simplified cousin of Haskell (similar syntax but most of the advanced syntactic and type stuff dropped), and where the current movement to make compiler error message more readable, conversational, and helpful (e.g. decoration, explaining the “reasoning”, providing possible solutions) originates.

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.

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

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.

Reply on news.ycombinator.com