> Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment.
Is it? I agree there's definite virtue in having this property checked by the compiler, but I think you and I will have to disagree on the notion of complexity here.
The beauty of Option types is that they are mostly used as return types. Most function arguments are non-nullable pointers or references; only ones that might be None are passed as options. This makes reasoning about code much easier. I just look at the function signature, and I know the types of arguments it expects. I also don't have to litter the beginning of each function call with if !null checks to each reference parameter.
> They must also perform checks when converting values from optional to non-optional types.
There are multiple ways to manipulate option type variables. The following comment from a Redditor sums it up very nicely:
"What is interesting is that (coming from scala and haskell) you almost never pattern-match on option types. The power of option, imho, is that you don't have to care whether it is Some or None, you write the same code regardless. If you are pattern-matching the whole time, you haven't gained all that much over checking for nil/null.
Option is a container, and we can use my_var.chain(...) and my_var.map(...) to update the things in the container. And the joy of it is that these methods will automatically do the right thing, with repect to Some/None, so you can string a bunch of these calls together, and if my_var is Some(...) is will apply all of the specified functions. If it is None, it will remain None."
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.
Yes, I had it backwards. Corrected.
> Specifying whether a value is optional is less complex than the usual way of specifying whether a reference can be null — a documentation comment.
Is it? I agree there's definite virtue in having this property checked by the compiler, but I think you and I will have to disagree on the notion of complexity here.