7 ms·
I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "
by glangdale 8y ago
I'm pretty excited by the idea of Go getting generics. This has always been my deal-breaker issue with Go and I'm glad that what appeared to be a disingenuous "let's pretend to be hunting for the truth until people go away" stance was actually really a hunt for the truth! Goes to show that you shouldn't make snarky snap judgments.
As for all the folks claiming they'll leave Go if it gets generics, it's faintly reminiscent of Mac fanboys claiming PowerPC chips were the Very Best right up until this was obviously not true. C++ generics are a PITA in many ways, but you can be insanely productive in the STL without having to hand-roll everything and with good type safety.
Despite the pain, I've been amazed at how easily you can build up some really complex data structures as pretty much one-liners ("Oh, I need a vector of maps from a pair of Foo to a set of Bar") that would either take a preposterous amount of code (or be a type-unsafe disaster waiting to happen) without generics.
Hopefully the final Go 2 generics proposal will capture some of this goodness without some of the horrifying C++ issues (error messages, bloat, sheer brain-numbing complexity).
- burtonator 8y agoI'm hoping things like generics can just be accepted to be a good idea moving forward and that we can all agree that languages without them are handicapped. I still fell things are up in the air about exceptions but maybe we can just agree on generics which would make me feel better. Using go without generics just felt insane to me...
- cultus 8y agoYeah, Go has some really fantastic aspects around tooling and a good concurrency story, but it's otherwise such a huge step backwards. I can't fathom the reason for not having generics. It's such a simple, completely common-sense abstraction. Things like typeclasses or multimethods offer vastly more abstraction power. These are (a bit) more difficult to understand, but you certainly don't have to be a genius (take it from me). I can kind of get why a language targeted towards "average" programmers might want to omit these. But here's the thing: The less abstraction power a language has, the more complexity must be handled by the developer. This leads to things like Java Spring, which you do have to be a genius to understand.
- tatersolid 8y agos/genius/masochist/g
- ryeguy 8y agoI really don't get the people opposed to generics. Is there actually a cross between experienced developers who have come from languages that have generics and understand them, yet don't want them in go? If so, why, and what do they use instead? Because go has no compromise-free answer for generics. You either lose type safety, maintainability, or performance. I suspect a lot of the generics hate is due to a large chunk of the community coming from dynamically typed languages. In which case they're just have a negative reaction to unfamiliarity.
- ramenmeal 8y agoI think the main fear people have isn't the concept of generics, but the implementation of generics. Go's primary goal is simplicity, and implementing generics isn't simple.
- bmon 8y agoIf language features were free we'd likely have had generics for a long time now. Unfortunately generics is a trade-off: you get development speed/ease and pay for it in compile time, binary size and/or execution speed. This seems to be slowly changing, but Go was designed to be a solution to Google problems - python being slow but some c++ applications taking literal hours to compile. Keeping that perspective in mind makes it easier to understand why Go maintainers have not accepted an implementation of generics into the language yet.
- atilaneves 8y agoIf you maintain type safety, you'll pay in increased compile times with or without generics. You'll either hand-roll an implementation for each type (https://golang.org/pkg/sort/ https://golang.org/pkg/sort/) or you'll generate code before actually compiling. The problem doesn't go away.
- ryeguy 8y agoBut like I said, Go doesn't have an answer for generics. So the complexity just lives in userland code instead of the language itself. The problem and complexity doesn't go away.
- endorphone 8y ago"As for all the folks claiming they'll leave Go if it gets generics" Baffled at this claim I searched and found one person who really seemed to be saying "if Go changes dramatically...". This recurring notion that Go fans are anti-generic is not rooted in reality. Instead they simply didn't buy the "either it's there or the language is useless -- generics or bust!" argument that pops up in every Go discussion. It's a fine, if imperfect, language without generics. It's a better language with them.
- comex 8y agoI don’t know about threatening to leave Go, but I’ve definitely seen a lot of posts claiming Go is better without generics.
- stcredzero 8y agoThe more nuanced and better side of that is that any language is better without badly designed and badly implemented generics.
- dnautics 8y agoMaybe the even more nuanced side is that a language that can't conjure a safe and well designed generic has a badly designed type system in the first place
- stcredzero 8y agoThat sounds axiomatic. How would you define "badly designed?" I can imagine a context where the "well designed" type system is very plain.
- mrfusion 8y agoWhat are generics?0
- w8rbt 8y agoRather than writing multiple functions that take different types as args and return different types (say int8, int16, int32, etc.) but do the exact same thing, with generics, you can instead write one function that takes a number (which could be any int type) and return a number, and you only wrote one function. That is generics in a nutshell. The function is generic, not specific to one type. Generics allow for less code, thus they are easier to debug, test and reason about. I've used them a lot in C++ and I do miss them in Go. It's not a deal breaker for me either way, but for people who write larger, more complex code, not having them makes it more difficult (more code to write, test and maintain). C does not have generics either. Go is a lot like C in this regard.
- mrfusion 8y agoWouldn’t this make golang slow though? Isn’t that what people claim makes python slow?
- w8rbt 8y agoNo. C++ is very fast. It has generics.
- AsyncAwait 8y agoAlso, very slow to compile.
- shakna 8y agoIn a ahead-of-time compiled language probably not. The generic function is just a code generator for several functions that will get called in the right places, generated and put in the right places by the compiler, and then get optimised as per normal. And no, being a dynamic language is not what makes Python slow. Lua, Nim and Scheme are all examples of dynamic languages with fast implementations.
- gameswithgo 8y ago>"Oh, I need a vector of maps from a pair of Foo to a set of Bar" This is a fun example since you can do that in Go now, as it comes with a generic vector (essentially) and map :D I think that was the design decision, 95% of generics use cases are covered by having growable arrays and maps, so why clutter the language with generics. I like generics, I think most people who dislike them are coming from C++ templates, which has downsides that don't exist in newer generics systems (such as in C# or F#)