never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right?
and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.
> 1. The current proposals for generics are bloated and don't fit properly with our vision for Go.
> 2. We will do heaps and heaps of work over many years until we get something we like.
I suppose repeatedly suffering the pain of not having generics until you finally get enough of your community to admit generics aren't just bloat can be described as "heaps and heaps of work". ;)
I'd love to hear what meaningful differences you think exist between early proposals for Go generics, and later proposals for Go generics. Or Go generics and generics which had existed in other languages for decades, for that matter.
The result of this silly delay will be felt basically forever, because millions of lines of go were written with error codes, which could have been much-less error-prone option types. I'm not sure it would even be a good idea to start using option types at this point because it would create such inconsistencies in codebases.
> Also, AFAIK Go is not a single-pass compiler, at least not in the way I learned about compilers.
Correct! But it was single pass and that was very important because multiple passes were bloat. But multiple passes aren't bloat any more, because now Go has multiple passes and Go doesn't have the bloat of other languages. See how that works?
"The past was alterable. The past never had been altered. Oceania was at war with Eurasia. Oceania had always been at war with Eurasia."
Quoting 1984 when discussing the history of a programming language really detracts from any point you’re trying to make.
It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
> It’s not like we’ve seen some massive regression in compiler performance. Circumstances changed, and the Go developers changed their minds. What would you do?
1. Yes, we didn't see a massive regression in compiler performance. Which begs the question why they didn't benchmark the options to see that might be the case.
2. Circumstances didn't change. The options for how to implement generics are roughly now what they were in 2009. What we need from languages in Go's sphere, is roughly the same as well.
3. What would I have done? a) Benchmark before making claims about speed. b) Assess features from other languages to see what works and what hasn't (literally nothing about the problems with lacking generics was unforseeable--I was talking about them early on and I'm not some sort of prophet). c) Admit rejecting generics was a mistake instead of pretending they were part of the plan all along.
This conversation feels like it’s in bad faith. Pike wrote in 2013 that generics were a “weakness” in Go [0].
In terms of changed circumstances, obviously something caused them to spend the time and effort to get it done. Maybe they thought modules were more important? Features don’t just magically appear, they need resourcing. The rest of your points are asinine. You mention benchmarking twice which begs the question, how did they maintain good compiler performance for all these years? Was it just luck?
This feels a lot like those conversations where the winners get what they ostensibly wanted, but then they want a pound of flesh to go with it. If you don’t like Go then use something else. The world is full of wonderful programming languages.
> If you don’t like Go then use something else. The world is full of wonderful programming languages.
Yes, exactly--wonderful programming languages whose mind share and funding is stolen by Go, a language with a few famous programmers and Googles' names attached, and almost no actual innovation. In fact, in reinventing the wheel Go seems insistent on re-making all the same mistakes other programming languages already made, and take us backwards. Part of the problem is exemplified in this conversation: the Go community's refusal to even acknowledge mistakes were made.
And sure, I can go use another language, if I can find a job that uses it. Luckily I'm fairly proficient in a few languages which are in no short demand, but none of them are new or interesting.
I would love if there was significant job stability in Elixir, for example. But there isn't. Meanwhile Go has the 11th spot on the IEEE list[1], through no deserving qualities of its own.
I'm not a winner getting what I wanted, and then wanting a pound of flesh in addition. I'm more of a frustrated loser here--sure, I was right about Go needing generics, but it's a Pyrrhic victory, because Go still has a bunch of market share while better languages languish in obscurity. And it's not just me losing: we all lose if we have to use poorly-designed languages and the lower-quality programs which result from them.
Yeah - Go is way up there with… PHP and sh! The horror!
Seriously tho, take a break. Go has strengths and weaknesses like any language; generics is a weirdly specific thing to get hung up on, especially since they admitted it was a weakness and they fixed it.
I mean, Java didn’t have generics for, what, 10 years? And Java generics are - in my opinion - a shitshow. And Java is #5 on your list.
I mean - just look at the top five languages. C doesn’t even have generics, and it’s number 2. C++… not gonna go there. I have never used c# in anger so can’t comment. And I’ve tried to use Python and I hate it for all the reasons I enjoy Go - and it’s number 1.
So what? Each of these languages fills a niche. It’s not worth getting upset about it.
I’ve been developing software for a very long time, and I’ve forgotten more languages than most people ever learn. I like Go and I think they have made perfectly reasonable trade offs.
You’re welcome to your opinion, but complaining about a moderately popular language stealing mind share is kinda weird.
> Seriously tho, take a break. Go has strengths and weaknesses like any language; generics is a weirdly specific thing to get hung up on, especially since they admitted it was a weakness and they fixed it.
It's too late, some problems caused by not having generics are unfixable at this point. As I said before, we're stuck with error codes for the forseeable future, because they chose to go with 1980s solutions to problems and not prioritize generics when everybody with a brain said they were needed.
> I mean - just look at the top five languages. C doesn’t even have generics, and it’s number 2. C++… not gonna go there. I have never used c# in anger so can’t comment. And I’ve tried to use Python and I hate it for all the reasons I enjoy Go - and it’s number 1.
Yes, those languages have problems. My point isn't to give you the opportunity to point the finger at other people, it's that we need better languages. This is why it's so fucking irritating that people latched onto Go, instead of one of the many amazing languages which isn't total shite. We need languages that have fixed these problems, but what we got was another shite language which learned almost nothing from the past.
At least C and Python have the excuse that they are products of their time. At least they learned from and fixed the mistakes of their predecessors. Go brings 0 innovation to the table: its best features, like coroutines and message queues, have existed in other languages for decades, and meanwhile they've made obvious mistakes that other languages already made and learned from. If I'm going to have to write code in a shite language, I might as well use one of the ones that knows and admits its problems, and has well-known solutions to them.
Yes, many of those languages made mistakes--a minimum of 10 years before Go existed. So why didn't Go learn from those mistakes?
> I mean, Java didn’t have generics for, what, 10 years? And Java generics are - in my opinion - a shitshow. And Java is #5 on your list.
My list? Bruh, this is a list of the most popular languages list. I didn't pick these, and I wouldn't pick those if I was making a list of the best languages. If you think that's what I'm saying, you're completely missing the point.
What you seem to be missing about Java is that their generics were a big step up from C++ templates--they were an improvement when they came out. They made mistakes, and C# learned from them, and brought in a better version of generics. You know, progress! Unlike Go which went with error codes and went with C-style casting and/or code generation which were already obviously problematic in the 80s, in 2009. Great language you got there, 25 years behind when it started.
> You’re welcome to your opinion, but complaining about a moderately popular language stealing mind share is kinda weird.
And you're welcome to yours, but defending an overhyped, innovation-less language that doesn't deserve its popularity is kinda weird too. We're both just wasting time.
> never mind than MANY people dont need generics, and that generics have a significant compilation and runtime cost, in terms of time and memory. who cares right?
I'm saying that I wanted them...? I didn't say need. I was able to operate without them. I simply _wanted_ them.
Also maybe consider the way you're communicating? I didn't say Go was wrong. I said I didn't enjoy it. I'm allowed to not like things, and I'm allowed to post about them.
_Also_ this concept of "need" is amusing to me. You don't _need_ a garbage collector, or a statically linked binary, or static typing, or IDE support, or a debugger, or, or ,or.
And yet, people _want_ them.
> and never mind that Go has had generics for over a year now right?
Their generics implementation is pretty bad IME. Interfaces lacking type parameters seems pretty untenable to me. I'd rather just not use them.
> sometimes having a small, stripped down language
Of all the things Go is, I wouldn't say its either of these.
But also, if you respond, please try to not be so defensive. You can like Go, that is a valid thing to do.
Very good points about need vs want. Every time I hear a response to a reasonable software request at work with, "Well, do you really need it?". I pat my left leg. It's a good leg; I like it; Very helpful, but, sadly not strictly necessary.
It's still on my "I keep meaning to play with this" list because I keep getting distracted by other shiny things but you might find gomacro interesting.
Many people don't need generics? Significant runtime cost? I would argue that everyone should be using type-safe collections like maps, lists, etc. (I know these are built into the language in Go, but they're basically special-cased generics). And, if anything, not having generics has more cost because you end up boxing your values to place into collections rather than letting the compiler monomorphize it. The compilation cost can be more expensive, yes, but it saves a lot of work you would be doing by hand.
While Go has had generics for a while now, the vast swath of existing Go code doesn't. The situation is definitely improving but there is still a lot of non-generic legacy cruft.
> you end up boxing your values to place into collections rather than letting the compiler monomorphize it.
you know that Go has interfaces right? and I dont just mean the "any" interface. you can write your own interface similar to io.Reader and others, then add types that implement that interface, then no type matching is needed.
> non-generic legacy cruft
AKA normal, fine code. generic code is not some magic pixie dust that makes bad code into good code. plenty of awful bloated slow generic code around as well.
If you are using interfaces, the value is necessarily boxed as the storage for the value may be heterogeneous. Once a value is typed as e.g. `io.Reader`, dispatching to its methods necessarily requires a vtable lookup (i.e. runtime cost!). Compare this to parametric polymorphism where you can avoid the type erasure and perform static dispatch at compile time. Though, unfortunately, Go's implementation of generics ("GC shape with stenciling" instead of full monomorphization) still ends up incurring some runtime cost.
With regards to your second point, there are definitely situations where generics are vastly preferred: type-safe collections being a big one. For instance, the standard library containers (https://pkg.go.dev/container) are still non-generic with no generic versions in the standard library yet. This is the kind of cruft I mean: generic collections can be turned into concrete collections with type safety, but not the other way around. I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and more safe.
> I make no claims about use of generics making your code being absolutely good or bad, but I do make claims that use of generics can make your code less error-prone and safe.
Right. this is the issue right here. people only see that Go didn't have generics, and they never stop for a second to think WHY Go didn't have them. Generics have an implementation cost for the Go project, and maintenance cost for the Go project, and end user negative impacts in regards to time and memory. but advocates often dont know or care about these drawback, and only howl that GENERICS ARE MISSING until they are added, consequences be damned.
I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".
> stop for a second to think WHY Go didn't have them
I have thought about this. I concluded that Go doesn't have generics because it's a poorly designed language whose designers elected to ignore decades of progress in programming language design for... reasons. Hence why you have to do the moral equivalent of passing around void pointers and checking return codes in $current_year
> I'm just saying that while generics are useful in some cases, they are not always the right answer, and it shouldn't just be assumed that every language needs them, nor that any non-generic language "sucks".
It's funny to me, because this comment chain exists because I said I got tired of rewriting the same functions with minute changes, the exact problem generics is intended to solve. I didn't say anything sucked, or even that I didn't like Go, just that this one aspect got tiring.
And yet, this small comment lead into a person feeling their language was being attacked.
If you like Go, that’s great. But stop pretending people don’t know what they’re talking about when they talk about generics or haven’t thought about it.
What kind of argument is this? Nobody says it’s “magical pixie dust that makes bad code into good code.” It’s a way to avoid writing repetitive code over and over and the runtime cost can be insignificant depending on implementation.
and never mind that Go has had generics for over a year now right? sometimes having a small, stripped down language is better than having a huge bloated monster. I would point to examples, but you know what they are.