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

Go: Support for Generic Methods

github.com

Post reply on HN
Print view View original

271–280 of 288 posts

Re: Go: Support for Generic Methods

#271

Post by foldr »

tines wrote: post #254
piekvorst wrote: post #193

Earlier quoted context omitted.

What’s the correction? The two claims are not in conflict. Saying “we don’t expect to ever add X” is not equivalent to “we never wanted to add X.” It simply means that they didn’t think it would happen, which can coexist with an underlying willingness to consider it if a suitable approach appeared.

You added the word "want", the OP said "need". "We don't ever expect to add X" implies "we don't think we need X."

Clearly we don’t need this feature. Just because the Go team decides to implement a feature doesn’t imply that they must think that the language needs the feature. You’re searching for contradictions where none exist.

Re: Go: Support for Generic Methods

#272

Post by Mawr »

pjmlp wrote: post #183
zarzavat wrote: post #149

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.

Thankfully we already have Java, so using Go is really for the scenarios where it cannot be avoided.

Thankfully some of us have taste.

Re: Go: Support for Generic Methods

#273

Post by tines »

entrope wrote: post #262
tines wrote: post #75

Earlier quoted context omitted.

Hi! I'm a human being that is trying to understand the world and make friends along the way. I see you are too! Pleased to meet you. You asked the question > Where did "they" say "we" didn't need generics? And I (re)posted a quote from them, which sounds to me like, at the time, they believed that "we" Go users didn't need generics. They may have changed their mind, which is totally fine! But I do think it sounds lik…

Hi! If you want people to think you are a human, you should not mistake one of them for an entirely different one, and you should not refer to yourself in the third person.

Ah, I guess to err isn't human after all :)

Re: Go: Support for Generic Methods

#274

Post by rustyzig »

AdieuToLogic wrote: post #269
rustyzig wrote: post #172

Earlier quoted context omitted.

As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. The paper usually credited with that is: https://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/b... Which the parent rightfully points out was written by the same person primarily responsible for the design of generics in Go: https://home…

> As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares: The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotatio…

And with full respect also given to Moggi, introductions are only introductions if they are heard.

If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, by all appearances, what caught the attention of the computer science community. "Monads for functional programming" is regularly cited as the seminal paper. They are strongly associated with Haskell. It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.

If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.

Re: Go: Support for Generic Methods

#275

Post by shakow »

j_w wrote: post #235
shakow wrote: post #202

Earlier quoted context omitted.

> Even in c++ could you not just define some int [1000][1000]foo? If it fits on the stack, yes. Typical code using MD-arrays is scientific code, and the data they manipulate generally do not fit there.

Would the compiler not allocate the memory contiguously on the heap in that case then? Seems like a reasonable thing to do.

Nope. The C++ memory models is designed around no hidden/non-deterministic memory allocation.

If you try to allocate 10MB on the stack, that's the dev problem if the program fails, it's not the compiler job to guesstimate whether something will fit there or not (and it's impossible anyway, the compiler can't know all the stack sizes a program will ever run on).

Re: Go: Support for Generic Methods

#276

Post by shakow »

foldr wrote: post #261
shakow wrote: post #214

Earlier quoted context omitted.

Your second paragraph doesn't hold after one minute spent reading the CVEs list.

Nil references in Go aren't likely to be a source of CVEs. Dereferencing a nil reference is not undefined behavior in Go; it's guaranteed to panic.

Not all CVEs are RCE. This one[1] for instance is go's nil-dereference caused.

[1] https://access.redhat.com/security/cve/cve-2025-29785

Re: Go: Support for Generic Methods

#277

Post by AdieuToLogic »

rustyzig wrote: post #274
AdieuToLogic wrote: post #269

Earlier quoted context omitted.

> As you point out, monads come from category theory, not native to computer science. Thus there had to be someone to introduce approaches to applying monads in computer science. With full respect given to Wadler and his contributions to computer science, the very paper you cite authored by Wadler declares: The concept of a monad, which arises from category theory, has been applied by Moggi to structure the denotatio…

And with full respect also given to Moggi, introductions are only introductions if they are heard. If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, b…

> If we were talking about the first person to discover monads, Wadler clearly would not be he.

We are not. Remember what the OP stated, to which I originally replied:

  Funnily enough, Go's generics were designed by the same guy 
  who introduced monads to computer science.
This is demonstrably incorrect, as Wadler did not "introduce monads to computer science" and is what I disagreed with alone.

Did Wadler take monads to new and important levels in both computer science and software engineering? Absolutely!

> It would even appear from the previous comment that you only came to learn about Moggi because of Wadler making his introduction, which echos Moggi not being particularly influential socially.

I quoted the Moggi attribution due to it being present in the paper you kindly provided. Whether Moggi has any influence socially is irrelevant as it pertains to the original thesis discussed above.

> If you have evidence to suggest that Moggi played a bigger role in introducing (not inventing) the concepts, I am definitely keen to learn about it.

Again, this is not germane to the aforementioned OP statement.

Re: Go: Support for Generic Methods

#278

Post by rustyzig »

AdieuToLogic wrote: post #277
rustyzig wrote: post #274

Earlier quoted context omitted.

And with full respect also given to Moggi, introductions are only introductions if they are heard. If we were talking about the first person to discover monads, Wadler clearly would not be he. Wadler was but a wee toddler barely sputtering out his first words when the term "monad" was coined. As we are talking about who introduced monads to computer science, the signs I see continue to point to Wadler. His work is, b…

> If we were talking about the first person to discover monads, Wadler clearly would not be he. We are not. Remember what the OP stated, to which I originally replied: Funnily enough, Go's generics were designed by the same guy who introduced monads to computer science. This is demonstrably incorrect, as Wadler did not "introduce monads to computer science" and is what I disagreed with alone. Did Wadler take monads t…

Moggi's social influence is everything as introductions can only happen in the social realm. It continues that all evidence I can find suggests that his work went unnoticed until Wadler pushed it into view. In other words, people came to learn about his work only because of Wadler making the introduction. Nobody, except where one may find it trying to be implied in https://news.ycombinator.com/item?id=48304692, has suggested Wadler invented monads. The OP clearly wrote "introduced", not "invented".

Re: Go: Support for Generic Methods

#279

Post by foldr »

shakow wrote: post #276
foldr wrote: post #261

Earlier quoted context omitted.

Nil references in Go aren't likely to be a source of CVEs. Dereferencing a nil reference is not undefined behavior in Go; it's guaranteed to panic.

Not all CVEs are RCE. This one[1] for instance is go's nil-dereference caused. [1] https://access.redhat.com/security/cve/cve-2025-29785

This is a bug that could also happen in Rust if someone used 'unwrap', or if the code panicked for any other reason. You can have logic bugs in any language. Remember the Cloudflare outage of Nov 2025.

It's also worth noting that the vulnerability you link to is a denial of service vulnerability. While yes, this is technically a vulnerability, it's not the sort of thing that people are usually worrying about in the context of null pointers. If features that give rise to DoS vulnerabilities are the ones to worry about, top of the list would have to be backtracking regex engines: https://owasp.org/www-community/attacks/Regular_expression_D...

Re: Go: Support for Generic Methods

#280

Post by Ferret7446 »

tines wrote: post #64
CamouflagedKiwi wrote: post #32

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".

There's a critical difference between "we don't think we will add it" (what you quoted) and "we won't add it because we think you don't need it" (what OP claims)
Post reply on HN