What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported.
For option types to work well in Go you would need to add more support to the type system. But we don't want a more complex type system. That's a tradeoff we made.
Again, I'm not really sure why people keep getting bent out of shape about this. Haskell, Scala, and Rust exist for people who want to write that kind of code. I prefer to write Go code.
> What I get from your comment is that option types work well in Haskell and Scala. This doesn't surprise me, as both languages places a strong emphasis on the type system, and so they are easily supported.
Option types need no type system support beyond having option types at all. Think of an option type as a container. It's either empty, or it has a single element inside it.
You can manipulate your container by checking if it's empty, getting the value out, manipulating the value and putting the value in a new collection. That's the basic low-level primitives of interacting with an option type.
And you can also use higher-order operations, e.g. map over the collection which will only "do things" if there's a value and will just return an empty collection if there isn't. These are the higher-level combinators on option types. They require no type system complexity outside of having option types in the first place.
Yes. Also, these low-level primitives already exist in Go, as support for pointers, or references. The missing bit is requiring references to be explicitly annotated as nullable or non-nullable.
I disagree with you on the relative complexity of type systems, and, as someone passionate about my craft, I despair Go is merely good not great, due to what appears to be uninformed design decisions.
You may prefer to write in Go, but you don't work in a vacuum. Your creation is out there, gaining mindshare, and propagating mistakes made half a century ago. As a language designer, you have the power to shape human thought for years to come, and the responsibility to remain intellectually honest. This is the meaning of Hoare's apology. He didn't know better. You have no such excuse.
I can't speak about the others. However, I feel that we have reached an unfortunate state in the industry when a sub-par technology starts to get picked up because of brand names, and not on inherent merits.
For option types to work well in Go you would need to add more support to the type system. But we don't want a more complex type system. That's a tradeoff we made.
Again, I'm not really sure why people keep getting bent out of shape about this. Haskell, Scala, and Rust exist for people who want to write that kind of code. I prefer to write Go code.