Hacker News Reader

Comment by strangeattractr | Hacker News Reader

As someone who writes a fair bit of Go and has dabbled with Rust a little bit after trying to learn it 3-4 times I agree. The Option and Result enums make me feel like I'm not missing an obscure error. Admittedly I find Go considerably more productive though but I wonder how much of that is familiarity and the cognitive burden GC eliminates.

View on HN

As someone who only wrote Golang, and then worked for 2 years on a Rust codebase, I agree as well. Sum types, Option, and Result really change everything. The number of crashes we avoided thanks to these is really meaningful. On the other hand the number of crashes I found in Golang applications due to a nil dereference is worriesome.

Complexity around memory management and lifetimes is a definite tradeoff that rust makes. A GC imperative language that uses Sum/Product types seems interesting. I guess that would be swift? I'm not familiar.

Swift, OCaml, Haskell ('bit of a toughie that one),

Elm if you favor "absolute simplicity", it's a pure functional language which eschews all the advanced type stuff found in most functional language. And I do mean all: elm actually eschews abstract types entirely, it doesn't have traits, interfaces, … except for a limited number of built-ins (comparable, number, appendable, and that's about it, well there's also compappendable which means comparable & appendable, and some people advocate for removing even those: https://discourse.elm-lang.org/t/just-for-fun-what-if-there-...).

It used to have a concept of "extensible records" but I'm not sure even that remains.

Yeah, I'm familiar with the ML derivatives, I'm a haskeller, I was musing specifically about imperative languages, because I doubt go programmers would be interested in that much of a switch up.

Reply on news.ycombinator.com