2 things I like about golang is just 1) the ease of getting someone to start work, and 2) goroutines. I have no complains about goroutines cause I’ve barely used it, and when I do it’s been fine. The first point though, I’d say the simplicity of the language is a double-edged sword — it’s easy to learn with little surface to cover, but it forces you to implement a lot of basic machinery you find in other languages by yourself, and so your codebase can get clunky to read really quickly, especially as your project grows.
Not trying to dissuade you from learning golang tho. I think it’s a good language to learn and use, especially for small simple programs, but it’s not the great language many try to say it is. It’s… fine. There are many reasons why it grinds my gears, but I’m still fine with using it and maintaining it for prod.
Many of these meanings seem to be captured in some modern solutions already:
Futures?
Exception?
Result
monads? (Okay, yea, we try to avoid the m word, but bear with me there)An
Option
orMaybe
monad?An enumeration of return types would seem to solve this problem. I can picture doing this in Rust.