4 ms·

This is some serious bike-shedding. Well there are some rare cases where you really need generic data structures, is not hugely annoying to use go generate and

by eloff 11y ago

This is some serious bike-shedding. Well there are some rare cases where you really need generic data structures, is not hugely annoying to use go generate and a template implementation. That being said, I'd still like to see generics in Go, providing the drawbacks are limited. The other criticism about null pointers is just ridiculous. If null pointers make in into a list of your top ten pain points while developing software in a team, I'm going to call you out for not being honest to yourself. Null pointers have their benefits and drawbacks, but it's so far down the list of practical concerns that it shouldn't even feature in your decision on what language to use.

AdieuToLogic 11y ago
> This is some serious bike-shedding. Does identfying fundamental deficiencies in a language now qualify as "bike shedding?" > Well there are some rare cases where you really need generic data structures, is not hugely annoying to use go generate and a template implementation. I don't understand how you draw this conclusion, as homogeneous collections are one of the most used forms of collections I've seen for many years. For an example of the precise issue losing the type within a container causes, see this example[1] of where a Go developer was struggling with an issue that is non-existent when types are retained. As for using an external tool to do "template generation", XDoclet[2] did that well over a decade ago. It was a PiTA then and now. > If null pointers make in into a list of your top ten pain points while developing software in a team, I'm going to call you out for not being honest to yourself. "Those who do not learn from history are doomed to repeat it" (source: http://thinkexist.com/quotation/those_who_do_not_learn_from_history_are_doomed_to/170710.html http://thinkexist.com/quotation/those_who_do_not_learn_from_...) They certainly do, as the number of people involved in working in a system increases, the assumptions regarding subsystem interaction vary. By having the ability to create a "software singularity" at any point by producing a null, everything will have to be _manually_ checked at the invocation site. Just like what had to be done in C for decades. Can you guarantee that everyone involved in the lifetime of a project will always use the same approach, have the same assumptions about how the behavioural contracts are fulfilled, and will _always_ check everything that needs to be ensured "non-null" at the call sites? With option types[3], or even better with disjoint union types[4] where the type contains either an error _or_ the desired result, this simply isn't a concern. The developer _must_ deal with the possibility of maybe not getting something back from a call (or of getting an error _instead of_ the desired result). 1- http://stackoverflow.com/questions/20087233/golang-get-the-value-from-list-element http://stackoverflow.com/questions/20087233/golang-get-the-v... 2 - http://xdoclet.sourceforge.net/xdoclet/index.html http://xdoclet.sourceforge.net/xdoclet/index.html 3 - https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type 4 - https://en.wikipedia.org/wiki/Disjoint_union https://en.wikipedia.org/wiki/Disjoint_union

by eloff 11y ago

AdieuToLogic 11y ago

> This is some serious bike-shedding. Does identfying fundamental deficiencies in a language now qualify as "bike shedding?" > Well there are some rare cases where you really need generic data structures, is not hugely annoying to use go generate and a template implementation. I don't understand how you draw this conclusion, as homogeneous collections are one of the most used forms of collections I've seen for many years. For an example of the precise issue losing the type within a container causes, see this example[1] of where a Go developer was struggling with an issue that is non-existent when types are retained. As for using an external tool to do "template generation", XDoclet[2] did that well over a decade ago. It was a PiTA then and now. > If null pointers make in into a list of your top ten pain points while developing software in a team, I'm going to call you out for not being honest to yourself. "Those who do not learn from history are doomed to repeat it" (source: http://thinkexist.com/quotation/those_who_do_not_learn_from_history_are_doomed_to/170710.html http://thinkexist.com/quotation/those_who_do_not_learn_from_...) They certainly do, as the number of people involved in working in a system increases, the assumptions regarding subsystem interaction vary. By having the ability to create a "software singularity" at any point by producing a null, everything will have to be _manually_ checked at the invocation site. Just like what had to be done in C for decades. Can you guarantee that everyone involved in the lifetime of a project will always use the same approach, have the same assumptions about how the behavioural contracts are fulfilled, and will _always_ check everything that needs to be ensured "non-null" at the call sites? With option types[3], or even better with disjoint union types[4] where the type contains either an error _or_ the desired result, this simply isn't a concern. The developer _must_ deal with the possibility of maybe not getting something back from a call (or of getting an error _instead of_ the desired result). 1- http://stackoverflow.com/questions/20087233/golang-get-the-value-from-list-element http://stackoverflow.com/questions/20087233/golang-get-the-v... 2 - http://xdoclet.sourceforge.net/xdoclet/index.html http://xdoclet.sourceforge.net/xdoclet/index.html 3 - https://en.wikipedia.org/wiki/Option_type https://en.wikipedia.org/wiki/Option_type 4 - https://en.wikipedia.org/wiki/Disjoint_union https://en.wikipedia.org/wiki/Disjoint_union