Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Generics aren't ready for Go

drewdevault.com

Post reply on HN
Print view View original

161–170 of 238 posts

Re: Generics aren't ready for Go

#161

Post by jstimpfle »

Foober223 wrote: post #85

An algorithm or data structure may be applied to various types of data. There's various ways to handle this. Macro expansion, generics (basically equivalent of macro expansion but as a language syntax), or losing types: void pointers, duck typing, interfaces. Go puts it's head in the sand and and handles the problem like it's 1970 with the "void pointer" way of thinking. That's fine if you're using a dynamic language…

I don't speak from experience with Go, but a simple type assertion at an interface boundary should normally not be noticeable at all. Where performance matters, there you usually do not have parameteric types or similar. Have you measured anything?

Re: Generics aren't ready for Go

#162

Post by throwaway415415 »

rebeccaskinner wrote: post #96
throwaway415415 wrote: post #57

Earlier quoted context omitted.

Maybe go back to java or c++? I'd rather have less people complain about a feature I don't want in the language.

I'd love to get away from Go again, but unfortunately it's the hot thing that people see on your resume and then they don't want to talk to you about anything else. I'm very concerned that in a few years it's going to be the terrible low-paying boring thing that people see on your resume and don't want to talk to you about anything else.

Its the hot thing for a reason. Adapt or be left out.

Re: Generics aren't ready for Go

#163

Post by throwaway415415 »

latronic_notron wrote: post #110
throwaway415415 wrote: post #57

Earlier quoted context omitted.

Maybe go back to java or c++? I'd rather have less people complain about a feature I don't want in the language.

Just curious: why don't you want generics in Go? The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}. It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself. This is a legitimate question, btw. Legitimately looking for other points of view

Because they are easily abused (look at c++) and makes code unreadable. Working around generics usually make the code clearer and thus more secure

Re: Generics aren't ready for Go

#164

Post by latronic_notron »

jstimpfle wrote: post #152
latronic_notron wrote: post #138

Earlier quoted context omitted.

> But the standard generic does not fit very well with go type system, so.... Why not? Generics in Arrays/Maps/Slices fit perfectly in the language, and don't feel weird at all in Go.

> Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go.

And generics aren't just for abstract data structures, there are other uses as well.

Re: Generics aren't ready for Go

#165

Post by throwaway415415 »

apta wrote: post #128
latronic_notron wrote: post #110

Earlier quoted context omitted.

Just curious: why don't you want generics in Go? The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}. It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself. This is a legitimate question, btw. Legitimately looking for other points of view

Keep in mind that many golang programmers just parrot what the golang authors say, without fully understanding it or even realizing the golang authors are wrong (not saying that's the case in this specific instance). They hear the golang authors complain about Java, that it's the only way to do things, so they think that the only other solution is to go the extreme opposite way, not even looking at real modern langua…

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure.

It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

Re: Generics aren't ready for Go

#166

Post by latronic_notron »

throwaway415415 wrote: post #163
latronic_notron wrote: post #110

Earlier quoted context omitted.

Just curious: why don't you want generics in Go? The language already uses them for Arrays, Maps and Slices, plus a lot of code relies on runtime-typed ad-hoc generics with interface{}. It's not as if Go is a language without warts... there's a lot of ugly stuff, like Iota, Reflection, the error handling, interface{} itself. This is a legitimate question, btw. Legitimately looking for other points of view

Because they are easily abused (look at c++) and makes code unreadable. Working around generics usually make the code clearer and thus more secure

Go has interface{}, which can be abused as much as generics for the same purpose, but without the type safety, hence, less secure.

And nobody is advocating C++ style template metaprogramming. There are much better implementations of generics, as acknowledged by Russ Cox himself.

Re: Generics aren't ready for Go

#167

Post by cannabis_sam »

jstimpfle wrote: post #125
cannabis_sam wrote: post #103

It’s weird seeing all this post-hoc rationalising when there is a perfect explanation for why go doesn’t have generics: Rob Pike didn’t bother to look into any of the research into type theory and programming language technology. Hence his understanding of types were restricted to Java and C++ and similar (whose type systems are an abomination), and he could not separate subclass polymorhism with inhertance from para…

Or maybe the academics and type theorists are philistines about the software that runs the world and their arguments have mostly been about hand-picked toy examples? Maybe Mr. Pike actually has some well-deserved reputation when it comes to real-world software and engineering projects that are about handling large scale data in real time?

His well-deserved reputation makes me interested in listening to what he has to say, but you have to evalute anyone’s idea on its own merits.

I think there is a tendency to create an unneccessary barrier between ”real-world” software and ”useless” academic theory. I’ve spent most of my career working with java, php, python and js, and I absolutely agree with Rob that class hierarchies and inheritance is a bad way to program, but there’s a lot more to types than oop type systems with limited type inference.

It’s of course always a trade off, which is why I build frontends in Elm, backends in Haskell and play with proofs in Agda, but why throw away types altogether?

Re: Generics aren't ready for Go

#168

Post by latronic_notron »

throwaway415415 wrote: post #165
apta wrote: post #128

Earlier quoted context omitted.

Keep in mind that many golang programmers just parrot what the golang authors say, without fully understanding it or even realizing the golang authors are wrong (not saying that's the case in this specific instance). They hear the golang authors complain about Java, that it's the only way to do things, so they think that the only other solution is to go the extreme opposite way, not even looking at real modern langua…

Unfortunately I am not parroting. If you are used to read code, and you read c++, you will see that templates are abused. No generics force devs to make their code clearer and thus more secure. It is evident that Go is a better language than most thanks to the creators having deep experience in that domain.

They aren't abused in C#, Java, Haskell, OCaml and other languages. Honestly, picking C++ as an example of traditional generic usage is a bit disingenuous.

Re: Generics aren't ready for Go

#169

Post by jstimpfle »

latronic_notron wrote: post #164
jstimpfle wrote: post #152

Earlier quoted context omitted.

> Arrays/Maps/Slices They are widely used data structures and so, in the opinion of the Go creators, justified separate specialized implementations in the Go compiler. In other words, there isn't actually a Generics system in the language (I don't actually know this, correct me if I'm wrong). For various reasons. There are quite a few talks and design docs from Rob Pike and Russ Cox if you look for them.

Nope. They are generics, aka parametric polymorphism. And they fit perfectly within Go. And generics aren't just for abstract data structures, there are other uses as well.

I think you've misunderstood what I said. For example here: https://golang.org/src/go/parser/parser.go you can clearly see how e.g. token.MAP is a special case.

    func (p *parser) tryIdentOrType() ast.Expr {
        ....
        case token.MAP:
            return p.parseMapType()
There is a special-cased function parseMapType() function in the Go parser. This isn't generic at all. I mean even the syntax (as in func foo(bar map[String]int) ...) does not seem to be generic at all.

Yes, you can use any type as keys and values. But that's a far cry from an abstract system that lets the user define any parameterizable data type. And that's for good reason: By hardcoding just the most important parameterizable data types, the problems that an abstract system would bring can be avoided.

Re: Generics aren't ready for Go

#170

Post by latronic_notron »

weberc2 wrote: post #158
latronic_notron wrote: post #151

Earlier quoted context omitted.

I personally find most implementations of generics to be in the class of "boring and predictable". I agree that C++ template meta programming might be a bit too much for Go (or for any language, for that matter), but generics as they are implemented in C# and Java are pretty cool and simple. IMO, if generics were to be ever added in Go they should just be a simple replacement for some uses of interface{} and code gen…

I'm talking about code written in Go, not the implementation of any particular feature. Generics would simplify those cases, but they also remove the rails that keeps Go code pretty consistent relative to Java or C#. For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative. And I appreciate that there are multi-paradigm languages like C# and Java that allow for both (better for experim…

> they also remove the rails that keeps Go code pretty consistent

But why? There's nothing in generics that would make Go non-consistent. In fact, there's already generics in Go in Array/Map/Slice, and they're not inconsistent with the rest of the language at all.

> For example, in Go, there is no functional-vs-imperative conundrum; it's only imperative

Why would generics break that? Funcional programming and type-safety/polymorphism are orthogonal concepts. IIRC, generics were introduced in Barbara Liskov's CLU language, which is imperative.

It sounds to me that most people advocating generics in Go are having a pragmatic/utilitarian approach, while people against it are opposing it from a purely ideological standpoint not grounded in either theory or pragmatism.

Post reply on HN