Hacker News new | ask | show | jobs
by mnd999 1897 days ago
I skimmed it, but I think what the author is getting at is that rust demands rigour. The kind of rigour required when failure is a problem and this tends to be the kind of code people get paid to write.

I guess the reverse is also true, if you’re writing the kind of code where failure doesn’t matter (e.g. spikes, experimentation, just messing about) perhaps rust isn’t the best choice.

3 comments

I think it's a little bit of a trap to fall into to believe that since Rust:

1. provides some unique benefits in terms of safety, and

2. is hard to program and requires rigor

that all that rigor is "worth it", and that it makes you a better programmer to put up with it.

Don't get me wrong, Rust's tradeoffs are valuable for some use-cases, but there are many, many use-cases where a GC'd language will work just fine, and it doesn't make you less professional for choosing a higher level tool which you can be more productive in if you don't have performance or memory constraints.

I also think, as the author alludes to, that many programmers get their first exposure to algebraic types and the elimination of NPE's through Rust, and get the false impression that the benefits of these features are somehow related to the additional complexity required by Rust. But these features are not related. Languages like Swift have shown us that you can get many of the benefits of Rust in terms of providing an "if it compiles it works" experience without many of the challenges Rust imposes on the programmer.

Completely, I don’t see rust as a replacement for Scala, Java, Go (and especially) Javascript which tend to be what I use at work. It’s certainly possible, but I don’t think it would add much.
> I skimmed it, but I think what the author is getting at is that rust demands rigour.

C demands rigor, too, but we're not talking about C because C compilers don't hold your hand and show you where your rigor slipped. Which is a sign C demands more rigor than Rust, isn't it? It's a problem with the author's argument: It's better to say that both C and Rust demand rigor, because they both compile to low-overhead executables (lower-overhead than C++, certainly), but Rust has more handrails and warning signs than C, so it's less dangerous.

Perhaps there are better choices than Rust when failure doesn't matter, but Rust is still good at some of those.

As an example, the rigour of strong typing helps set some experiments on the right track.