3 ms·
> In Go you would have to use a pointer to represent Option<T>, which makes code really awkward. This sounded surprising to me, then I remembered Go doesn’t ha
by eyelidlessness 5y ago
> In Go you would have to use a pointer to represent Option<T>, which makes code really awkward.
This sounded surprising to me, then I remembered Go doesn’t have generics. I imagine this won’t be as much of an issue when it does?
- throwaway192874 5y agoPerhaps if they were to remove the concept of nil in golang, but since they are all about backwards compatibility (which is nice to be fair), I don't think there's much change of seeing mainstream adoption because of how many existing projects will rely on default value in certain circumstances I'd love to be proven wrong, but even with generics if you start using option types, it's going to be like JS and TypeScript where you'll have some parts nicely typed and others are the wild west
- the_duke 5y agoEmulating ADTs without language support/pattern matching is quite awkward. A prime example is std::optional in C++. .map() et al only get you so far. When extracting the value in Go you either have to return a pointer / error pair or abort. Both of which introduce awkward code patterns and potential for misuse.