4 ms·

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 fe

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.

baby 6y ago
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.
sullyj3 6y ago
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.
- masklinn 6y ago
  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-were-no-type-classes-at-all/5693 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.
  - sullyj3 6y ago
    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.

baby 6y ago

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.

sullyj3 6y ago

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.

masklinn 6y ago
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-were-no-type-classes-at-all/5693 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.
- sullyj3 6y ago
  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.