Hacker News Reader

Comment by jeffrallen | Hacker News Reader

This is tl;dr. As a software engineer who is passionate about reliable systems, I want to love Rust, but when it is this hard to reason about (not the footgun he promised, and I didn't even get to, but the first 3/4 of his article) then I can't get into it, and can't recommend companies invest in it.

View on HN

Locks are not easy to reason about, period. Rust makes it particularly easier; I shudder about doing similar logic in any other language without this level of tooling.

Channels are easy to reason about. If the language that gives me channels asks me to let it manage memory too, then cool, fine with me.

Channels are most definitely not easy to reason about in the slightest. Superficially, they might appear to be on the surface: but they're really not and have innumerable subtle cases and behaviours in the face of various kinds external conditions, scheduling behaviours, etc. They only start to become 'easy' in a language that utterly ignores all other paradigms, interoperability, and performance concerns as in Go.

They're easy to implement; terribly difficult to reason about from a correctness point of view, which is really all that matters in performant multithreaded code.

Given that it can take weeks to debug a deadlock, I am more than happy to pay the price of some boilerplate and difficult types if that helps correctness.

Which systems language do you recommend?

If anything, locks are hard so if you can do parallel code that doesn't require it (essentially embarrasingly parallel or the like), it's better. It doesn't fit all use cases though.

Honestly, if things are slower, not really mission critical for speed, but are easier to reason about, it's probably worth it to keep it simple and even sequential.

Reply on news.ycombinator.com