Live data from Hacker News

How generics are implemented in Go 1.18

github.com

221–228 of 228 posts

Re: How generics are implemented in Go 1.18

#221
post #218
post #191

Earlier quoted context omitted.

>You clearly don't have any idea who I am Why would anyone here have any idea who you are? Your username is not informative, and you don't say who you are in your profile. That's perfectly fine, of course, but you can't then expect people to recognize you as being a particular individual.

I don't hide behind nicks, my online life is relatively easy to find, and besides the tone should have started in a different way than "You clearly have no idea what Rust is for".

Well you still haven't responded to my other comment, your profile says your primary stack is Java, and a quick google revealed nothing about you the than the fact you seen to spend more time on hacker news writing comments than you do building things, so actually I was right to take your opinion on a deeply technical topic that is quite out of your wheelhouse worth a grain of salt.

Re: How generics are implemented in Go 1.18

#222
post #218

Earlier quoted context omitted.

I don't hide behind nicks, my online life is relatively easy to find, and besides the tone should have started in a different way than "You clearly have no idea what Rust is for".

Well you still haven't responded to my other comment, your profile says your primary stack is Java, and a quick google revealed nothing about you the than the fact you seen to spend more time on hacker news writing comments than you do building things, so actually I was right to take your opinion on a deeply technical topic that is quite out of your wheelhouse worth a grain of salt.

Whatever dude, you can't even read the profile properly.

Re: How generics are implemented in Go 1.18

#223

Earlier quoted context omitted.

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically ? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

I'm not saying a compiler pass is a problem: I'm pointing out that Go fanboys originally said that they needed a single compiler pass, and that was why Go couldn't have generics. But Go has abandoned single pass a long time ago, and Go still doesn't have generics, and when it does have generics, it will have an abstraction so complex that it makes adding another compiler pass look simple. If anything, I think compile…

Your example is super helpful for focusing the discussion, so firstly, thank you for taking the time.

My immediate thoughts are:

- This is rather specific. Not all programs should be using complex thread-safe data-structures. Rather, the primitives are in place to build such things, and libraries can be imported etc.

- These more sophisticated data-structures have runtime costs that are a bit less straightforward to understand as compared to arrays. They require either (a) programmers to be aware of the edge cases or (b) a higher-level language where programmers relinquish some control over runtime performance. To be clear, I personally enjoy many such languages.

Overall, your criticism is equivalent to saying "Go is too low-level". That may well be the case for many applications, but that remains to be argued more precisely.

Re: How generics are implemented in Go 1.18

#224
post #13

Earlier quoted context omitted.

Yes, with VC++ offering the best experience currently.

I am confused. Why was this downvoted? Is GCC and Clang doing better? (Or another C++ compiler?)

Because the answer is false, modules do not solve the problem of having common/shared template instantiations.

As for the comment about MSVC, it's mostly off topic, doesn't relate to the question that was asked (which had nothing to do with which compiler provides the best experience), and even if you accept that MSVC provides the best module experience, it's support for it is still very buggy and not suitable for anything other than experimenting and beta testing.

Re: How generics are implemented in Go 1.18

#225

So maybe 7-8 years ago, I got into a bunch of arguments with people on Hacker News because I said that Go's type system was ineffective without generics. At that time, Gophers leaped to defend it, going so far as to say that it's better because it's simple. Oh and it was really important to Gophers that Go compiles in a single pass (which I argued is only relevant for truly enormous codebases like Google's). A few ye…

The cycles and waves in human groups is pretty weird to witness.

Re: How generics are implemented in Go 1.18

#226
post #212

Earlier quoted context omitted.

How many times is this gonna get reposted as some sort of gotcha? He's right, and having to deal with juniors or large teams with varying competence isn't unique to Google. I've met many devs who praise Java for how simple it is to parse through for people of all experience levels (once you get used to the verbosity). In fact, two of Java's founding principles was that it had to be simple and familiar. Yet I don't se…

> having to deal with juniors or large teams with varying competence isn't unique to Google. It's good for "juniors" but not yourself? Lmao. No one can praise Go without speaking in the third person.

No post body was provided.

Re: How generics are implemented in Go 1.18

#227

Earlier quoted context omitted.

Where does this cause problems for you in practice? Where is the usefulness of goroutines limited practically ? Where is the complex notion of a compiler pass causing problems? I’m very open to the idea that I’m suffering from a problem I don’t know I have, but right now you’re just asserting that problems exist without actually telling us how to recognize them.

I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.

That's fair, except that I routinely program in:

- Go

- OCaml

- Python

- Lisp

I think I have a reasonably good sense of what each language offers and what it does not. But OP goes beyond saying "Go does not offer some features that other languages offer"; he effectively says that the language causes severe problems. Where are they?

Re: How generics are implemented in Go 1.18

#228

Earlier quoted context omitted.

I think OP didn't even start using go in practice, so the question doesn't help. But I can say that it's the same ad with natural languages. No one ever feels that their mother tongue is limiting, until they learn a new and very different language and learn a pattern/style that they cannot apply in the mother tongue.

That's fair, except that I routinely program in: - Go - OCaml - Python - Lisp I think I have a reasonably good sense of what each language offers and what it does not. But OP goes beyond saying "Go does not offer some features that other languages offer"; he effectively says that the language causes severe problems. Where are they?

"severe" is certainly subjective, so you might disagree.

From my perspective, none of the languages you listed allows for good error handling. But that is obviously only my perspective. I would call this a "severe" issue. In fact, all languages that k I know have at least one "severe" issue.

Post reply on HN