2 ms·
OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions
by jrobn 10y ago
OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody.
* Pattern matching is intuitive and can be extremely powerful.
* It's pretty clear that Null should not exist anymore.
* Multiple return values, but no tuples?!
The go designers seem to not have a problem with special cases so why didn't they include special cases for an Option<T> and Result<T,E>, two things that, with pattern matching, would fit right into Go's explicit error checking philosophy.
- sjellis 10y ago> OK, go will never have generics (except that it does in "make", "range", "chan", ok whatever...). That's fine with me. But including even just a few suggestions in the parent article would make Go a more approachable language to everybody. The current position is that the core team will only include generics if they can find a design that satisfies them. Which has sounded a lot like "no, never" but Russ Cox has said that he wants to look into implementing generics again this year.