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

Notes on the Go2 Generics Draft

jmoiron.net

Post reply on HN
Print view View original

31–40 of 116 posts

Re: Notes on the Go2 Generics Draft

#31

Post by bitwize »

laumars wrote: post #5
hugofirth wrote: post #2

The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

The Go team should have considered generics for Go 1.0 during the 0.x phase.

It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like dependent and higher-kinded types are a bonus.

We've also done enough computer science to know there are much better ways to relieve the programmer of the burden of doing all memory/resource management explicitly than a tracing GC. So using a tracing GC in an ostensible systems programming language was another huge boner.

Go 1.x was a cascade of bad decisions. It's like Java was in 1995: a language with training wheels that had to change directions entirely when real programmers started using it to build real applications.

Re: Notes on the Go2 Generics Draft

#32

Post by joshuak »

viraptor wrote: post #10
laumars wrote: post #5

Earlier quoted context omitted.

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

> critics of Go aren't even Go developers This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released. If only people continuing to use X could criticise X, we wouldn't get much progress.

I’m so conflicted about this comment because I have made nearly identical comments in the past.

I think I’m going to have to change my stance on this point, however. There have been so many occasions that something about Go bothered me, and I then later discovered was a prerequisite to leveraging a much simpler programming model, that I am humbled by how much more I had to learn about programming. And I have to admit that others before me said as much, but I didn’t believe them.

Sometimes one just isn’t competent to render a useful opinion.

If you haven’t seen the movie, read the book or eaten at the restaurant, the directors, authors, and chefs should rightfully ignore your criticism. And I for one am glad the Go authors ignored criticisms like mine, I am a much better programmer now then I was then because I learned something new.

Although I will admit it was difficult at times. It’s hard to go from being an expert at something to a beginner at something you feel should be essentially the same.

Re: Notes on the Go2 Generics Draft

#33

Post by throwaway34241 »

coldtea wrote: post #16
laumars wrote: post #5

Earlier quoted context omitted.

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

> I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigm…

It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust...

Also I see stuff like they should just use "perfectly fine existing paradigms from other languages" on HN all the time. But from the very beginning they said that Java-style generics were undesirable (due to overhead) and C++/Rust style were also undesirable due to code size. In the end, the proposal does not choose either system and tries to enable the compiler to make trade-offs in between. It seems most inspired by CLU and a proposed future C++ feature... I genuinely don't understand why HN views this as an easy thing to just copy in, unless they view the design goals as unnecessary to begin with...

I definitely think it will be convenient to have type safety for collections that are not lists or hashmaps/sets. I also think it's convenient to have multiple return values and slices (so every list api accepts sub-lists without copying). Overall, I didn't find Go to be tremendously less convenient than Java or C#... I'm kind of curious what kind of software HN is working on, where Go is so much worse than the alternatives.

Re: Notes on the Go2 Generics Draft

#34

Post by viraptor »

joshuak wrote: post #32
viraptor wrote: post #10

Earlier quoted context omitted.

> critics of Go aren't even Go developers This doesn't make the criticism invalid. I tried Go, found the lack of genetics / gopath / depends management too annoying, went back to other languages. I'm going to try it again after V2 is released. If only people continuing to use X could criticise X, we wouldn't get much progress.

I’m so conflicted about this comment because I have made nearly identical comments in the past. I think I’m going to have to change my stance on this point, however. There have been so many occasions that something about Go bothered me, and I then later discovered was a prerequisite to leveraging a much simpler programming model, that I am humbled by how much more I had to learn about programming. And I have to admit…

I feel like you're saying the criticism has to turn out right or wrong. I don't feel that's the case. A criticism is just an opinion (based on facts or not). Ignoring them will lead one way, addressing them another. Some people will like either one of them.

I think criticism from people who stopped using X is a valid opinion even if it's ignored and if other people are happy it was ignored. You can't please everyone.

Re: Notes on the Go2 Generics Draft

#35

Post by [deleted] »

laumars wrote: post #5
hugofirth wrote: post #2

The author makes some interesting arguments, but they are all predicated on the idea that generics are somehow hard to grok or use? Having helped teach Java to many people with less than a year's programming experience at university, I refute this. Bear in mind we're hardly talking about higher kinded types here. Generics are a simple abstraction over a lack of type information which allows you to write and maintain…

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

[deleted]

Re: Notes on the Go2 Generics Draft

#36

Post by pjmlp »

throwaway34241 wrote: post #33
coldtea wrote: post #16

Earlier quoted context omitted.

> I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. They said that occasionally, but always dismissing any kind of proposal that wasn't theirs, including perfectly fine existing paradigm…

It's true language changes don't seem to have been prioritized until recently. But the last big thing (package management) was probably long overdue. Before that it was mostly improving the compiler, runtime, and standard library. There's all sorts of interesting niche languages that aren't used because those ecosystem things aren't as robust... Also I see stuff like they should just use "perfectly fine existing para…

As you say " It seems most inspired by CLU".

Do you happen to know by chance when CLU was created?

Re: Notes on the Go2 Generics Draft

#37

Post by dnomad »

zmanian wrote: post #30

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...

Exactly. Like all ideological arguments it completely ignores actual real-world evidence. Somebody should sit down and analyze real codebases and understand and quantify how much these projects would be improved by real generics and proper exception handling. My (anecdotal) experience and speculation suggests that you'd see massive reduction in complexity and lines of code (especially when you consider code-gen).

But then this is part of a larger problem of the community which isn't motivated by evidence or basic pragmatism but rather strict adherence to a philosophy.

Re: Notes on the Go2 Generics Draft

#38

Post by mseepgood »

jniedrauer wrote: post #28
Exuma wrote: post #25

Can someone explain in terms to someone who hasn't really used a static typed language what "generics" are? I've only used javascript and ruby.

Consider this function signature: func SomeAdditionFunction(arg1 int, arg2 int) { fmt.Println("Sum:", arg1 + arg2) } This function will only accept a pair of integers. In order to perform addition on floats or int64s or any other number type, you would need a separate function. Go has the concept of an empty interface (interface{}) which can accept any type. But this is not really a generic because you have to assert…

> In a language like Java, I could write this function to accept any type for which the + operator is valid, and it would still be type safe at compile time. I would not need to assert the types like I did above.

Really? No. Not in Java.

  static  void someAdditionFunction(T arg1, T arg2) {
    System.out.println("Sum:", arg1 + arg2);
  }
"error: bad operand types for binary operator '+'"

Re: Notes on the Go2 Generics Draft

#39

Post by sethammons »

bitwize wrote: post #31
laumars wrote: post #5

Earlier quoted context omitted.

I keep hearing people say things like "the Go team are changing their position" but I think what a lot of people missed is that the Go team were never against implementing generics in version 2. Quite the opposite in fact as they actually often said it was a consideration for Go v2. What they repeatedly opposed was rushing generics into a v1.x build as that could break things. The real issue is that many of the "hate…

The Go team should have considered generics for Go 1.0 during the 0.x phase. It's 2018. We've done three decades of computer science since C, Oberon, or whatever the Go developers drew inspiration from. If you want your language to be taken seriously for large scale app development in the 2010s you need strong static typing, and a sophisticated, parametric type system. No exceptions. Advanced typing constructs like d…

> No exceptions

Well, apparently Go _is_ an exception. It lacks what you point out and is, undeniably, a successful language.

Re: Notes on the Go2 Generics Draft

#40

Post by cshenton »

zmanian wrote: post #30

It's impossible to defend the lack of generics in golang in the face of the fact that two of the larger open source projects both invented their own generics implementations. https://medium.com/@arschles/go-experience-report-generics-i... https://github.com/google/gvisor/blob/master/tools/go_generi...

It’s weird to see complaints about code generation causing a too big code base at compile time when code generation is exactly what a compiler will do behind the scenes for generics.
Post reply on HN