Live data from Hacker News

Go: Support for Generic Methods

github.com

161–170 of 288 posts

Re: Go: Support for Generic Methods

#161
post #148

> Go doesn't support such generic interface methods because we don't know how to implement (calls of) them, or at least we don't know how to implement them efficiently. I don't really understand this argument. I read the discussion linked to[1], and yeah, monomorphization approaches (whether at compile time, link time, or runtime with JIT) are obviously going to be difficult or impossible, but the reason against usin…

> Of course it's also possible there is some detail I've missed.

Can't speak too deeply for Go specifically, but I do know on .NET one of the big reasons generic methods where T is a structure gets monomorphized per type, is so that stack size is adjusted and potentially even arg passing (i.e. large struct) as far as the caller/callee.

Re: Go: Support for Generic Methods

#162
post #16

Earlier quoted context omitted.

Of course, if you go back and watch the original Go announcement it said that it would need generics once they figured out how to do it. And when the first version of generics landed it was said that generic methods would be added later, once they figured out how to do it. So that isn't applicable here. The need was always recognized.

If Go had just taken an off-the-shelf implementation of generics in 2009 then they could have spent the last 16 years deliberating over something useful, rather than attempting to reinvent programming language theory. The impression I have always gotten from Go's designers is that they are rather arrogant and averse to the idea of using other people's work. They want to develop everything from first principles, but b…

> and averse to the idea of using other people's work.

They did use someone else's work, though. If you recall, Philip Wadler (of Haskell fame) designed Go's generics.

> but by so doing end up with poor reinventions of well-studied concepts.

Which is funny as there is probably nobody on earth that would be more capable than Wadler to get the job done. His pedigree in that area of work is pretty astounding. If he couldn't do more than create a poor reinvention, what hope did the laymen working on the Go core team have?

Answer: They had no hope. It's not like they weren't trying. Ian Lance Taylor, for instance, is well known for beginning work on generics in Go before it was even first released to the public. He, among others, quite simply, were unable to figure it out.

Everything looks easy and straightforward when observed comfortably from an armchair, I suppose.

Re: Go: Support for Generic Methods

#163
post #92

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science. Everything comes fill circle.

Re: Go: Support for Generic Methods

#164
post #144

Earlier quoted context omitted.

Is it because of the kinda built-in duck typing, for want of a better word? The thing where if you have a method (or methods) that matches the signature of method(s) of an interface, you implement the interface without explicitly declaring so?

> for want of a better word Structural typing is the term typically used to describe "static duck typing".

I’d describe structural typing as a special case of duck typing FWIW.

Re: Go: Support for Generic Methods

#166
post #158

Earlier quoted context omitted.

Watching Go's development is like reliving the development of Java (which also didn't have generics at first), but over decades instead of years. Cannot wait for Go to implement an error handling system in the 2030s.

Its very funny watching certain segments of the programming industry rediscovering incredibly basic programming principles, after railing against them for so long. The AI people are starting to try and create formal specs to force the AI to generate an exact output, which is absolutely hilarious to me Dynamically typed/untyped languages finding that strict and visible typing is actually good is another

I feel like there was a name for formal specs that produce an exact output, but it escapes me…

Re: Go: Support for Generic Methods

#167
post #64

Earlier quoted context omitted.

They didn't say they never wanted to do generics, but that they did want to take their time and do them right. Debatable how much they have been "right", although this gets them somewhat closer. And I think they have not been "wrong" in the ways they wanted to avoid (they referenced some issues with Java generics as prior art, although I forget the details).

From another commenter here: > The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods".

> “What do you think? There was a man who had two sons. He went to the first and said, ‘Son, go and work today in the vineyard.’ “ ‘I will not,’ he answered, but later he changed his mind and went. “Then the father went to the other son and said the same thing. He answered, ‘I will, sir,’ but he did not go. “Which of the two did what his father wanted?” “The first,” they answered. Jesus said to them, “Truly I tell you, the tax collectors and the prostitutes and the Go language maintainers are entering the kingdom of God ahead of you.

https://www.bible.com/bible/compare/MAT.21.28-31

Re: Go: Support for Generic Methods

#168
post #144

Earlier quoted context omitted.

> for want of a better word Structural typing is the term typically used to describe "static duck typing".

I’d describe structural typing as a special case of duck typing FWIW.

I suppose. That special case is that it is evaluated statically, whereas duck typing is evaluated dynamically. That's the whole difference between them. They are otherwise identical concepts.

But who is to say that dynamic evaluation isn't the special case?

Re: Go: Support for Generic Methods

#170
post #163
post #92

This will finally let me make the monad library I've been dreaming of for years. Be afraid.

Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science. Everything comes fill circle.

> Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science.

No contributor to Go is responsible for "introducing monads to computer science", as the Monad concept is a member of (or defined by if you prefer) Category Theory[0].

0 - https://en.wikipedia.org/wiki/Category_theory

Post reply on HN