Go: Support for Generic Methods • Hacker News Board

Re: Go: Support for Generic Methods

#221

Post by dnnddidiej » Thu, May 28, 2026, 10:10 AM UTC

AdieuToLogic wrote: post #171

dnnddidiej wrote: post #137

Earlier quoted context omitted.

Can we have Exception monads? Asking for friend.

> Can we have Exception monads? Asking for friend. This is nonsensical. Monads define a strict set of behaviors formalized as "monad laws"[0]. Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions. Two exemplars of same are Haskell's Data.Either[1] and Scala's Either[2]. 0 - https://wiki.haskell.org/Monad_laws 1 - https://hackage-content.haskell.org/package/base-4.22.0.0/d…

> Perhaps what you want is a container which adheres to monad laws capable of abstracting exceptions

That is what I meant. Struggling to picture what the other "nonsensical" thing is.

Re: Go: Support for Generic Methods

#222

Post by reilyroadster » Thu, May 28, 2026, 10:25 AM UTC

stouset wrote: post #110

9rx wrote: post #107

Earlier quoted context omitted.

Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap". There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stret…

Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless. Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped thems…

Nil is not the problem, practically every language has such a concept - it's pretty much required to make things like Maybe/Optional work.

The problem is the implicitness of it and how easy it is to produce them and forget to check for them.

Re: Go: Support for Generic Methods

#223

Post by klik99 » Thu, May 28, 2026, 10:25 AM UTC

I remember lack of generics being pitched as a feature of Go initially, not a lack. The original design goal was simplicity. I don’t use Go, so have no opinion on this, just interesting that it’s going in this direction.

Re: Go: Support for Generic Methods

#224

Post by kunley » Thu, May 28, 2026, 10:32 AM UTC

the_gipsy wrote: post #136

Matl wrote: post #126

Earlier quoted context omitted.

Yeah, because software is not meant to evolve and people are not meant to either.

You're not meant to gaslight about the evolution of software.

You're not meant to apply poor man's psychology everywhere just because you have heard about a certain psychological term.

Re: Go: Support for Generic Methods

#225

Post by bborud » Thu, May 28, 2026, 10:54 AM UTC

stouset wrote: post #76

tczMUFlmoNk wrote: post #57

Earlier quoted context omitted.

> As for the detractors, from the first generics proposal this was called out as a "not now", not never. What? The post quotes the Go FAQ as saying, "we do not anticipate that Go will ever add generic methods". There is also some similar discussion of the original generics proposal, with language like "then it's much less clear why we need methods at all". (I'm omitting some context, but I don't feel that it changes…

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

You have those who obsess over feature lists for languages and then you have those who obsess over friction, productivity, ease of use and developer ergonomics.

If I were uncharitable I might call the categories "people who are somewhat removed from reality" and "people who inhabit observable reality". Avoid the former, treasure the latter.

Languages evolve for a reason and nobody should give a shit about people who do not understand why.

Re: Go: Support for Generic Methods

#226

Post by bborud » Thu, May 28, 2026, 10:58 AM UTC

jpc0 wrote: post #86

stouset wrote: post #76

Earlier quoted context omitted.

No, you’re clearly wrong; golang was always going to add support for generic functions. Everyone also wanted and accepted the need for generics. It was always something they wanted to add to the language. Rob Pike never said that that kind of abstraction isn’t what golang is for. It was always just a matter of getting the design right. Go has always been a systems language. It was one when we thought it was going to…

> term “systems program” has always meant network middleware that shuttles around JSON and transforms it. Who are we that has always defined that term that way. For any systems programmer golang has pretty much not been a solution. Systems is below layer 4 of the network stack, it is building the network stack in the first place.

"Systems program" or "systems programming" is a meaningless term because people use it differently. Discussing what it means is a waste of time. It is better to be specific.

Re: Go: Support for Generic Methods

#227

Post by apatheticonion » Thu, May 28, 2026, 11:35 AM UTC

I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking.

I moved to Rust professionally 4 years ago and haven't looked back. Mutex Option Result are all phenomenal.

I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python extensions.

Web backends use under 1mb of memory and can support hundreds of thousands of concurrent users on a $2/m VPS. Frontends can be beautifully multithreaded. Native extensions can dance between OS threads and multi-threaded runtimes.

When I review code I focus only on the logic, not sidetracked by reasoning about race conditions or anything. Great when you review the work of less experienced contributors.

The ultra strict compiler is extremely helpful with LLMs. You bounce back and forth until it compiles and, if it compiles, it's usually correct.

It's at the point where I can't really see a use case for another language - and yet, no one uses it! It's madness!

Re: Go: Support for Generic Methods

#228

Post by matthewmc3 » Thu, May 28, 2026, 11:40 AM UTC

klik99 wrote: post #223

I remember lack of generics being pitched as a feature of Go initially, not a lack. The original design goal was simplicity. I don’t use Go, so have no opinion on this, just interesting that it’s going in this direction.

Generics being omitted wasn't pitched as a feature that I ever saw. The discussion was mostly around "hic sunt dracones" with generics. The Go authors were very aware from the get-go that generics are an incredibly difficult thing to implement well, and the commitment was always to not do it until they were really ready to tackle it. The bizarre thing to me is that when they did tackle it, they left this massive implementation gap, and then what little they did implement didn't seem useful enough that anything meaningful was added to the standard library. So all this talk about generics for years was a big nothing-burger. That is, I hope, until 1.27 when this gets released. Flags is one in particular I think is in desperate need of proper generic methods.

Re: Go: Support for Generic Methods

#229

Post by root-parent » Thu, May 28, 2026, 11:50 AM UTC

apatheticonion wrote: post #227

I wrote Go professionally for years. I don't know how many hours I've spent debugging and reviewing nil pointer bugs and race conditions. Generics were sorely needed but the initial implementation was lacking. I moved to Rust professionally 4 years ago and haven't looked back. Mutex Option Result are all phenomenal. I've written everything from web backends, frontends (hurry up wasm, seriously), to Node.js and Python…

I have nothing to add to your comment, but it matches so eerily my exact experience, that I just wonder if your alias is a second account of mine :-)

Re: Go: Support for Generic Methods

#230

Post by nobleach » Thu, May 28, 2026, 12:01 PM UTC

shakow wrote: post #203

rootnod3 wrote: post #20

Earlier quoted context omitted.

ANSI CL is such a breath of fresh air nowadays. Does what you need, doesn't get in your way, comes with batteries included. And conditions are just god-tier.

> comes with batteries included I like CL, but I can't agree that a stdlib that doesn't even have a string split function is batteries-included.

And to bring it full-circle, this is the exact same thing I run into with Go. When I mention how nice it is that Lang X has feature Y, someone is quick to point out that either, "You can BUILD that in Go" or, "You don't really need feature Y". We've proven that we don't really NEED compilers either... but I would hate to have to do my job without them.