Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- 22 years late, but better late than never.by valcron1000
- On one hand I'm glad to see this being added, but its becoming obvious building generics into the language as-is just isn't a good fit. Hopefully Go v2 can solve this at a more foundational level while still allowing interop or easy porting form current go code.by athorax
- Why is it becoming obvious?by orf
- I thought the status of Go v2 was that the devs weren't saying it will never happen, but also were not working on it. There was some momentum that seemed to sputter out once generics were added.
"when should we expect the Go 2 specification that breaks old Go 1 programs?
The answer is never. Go 2, in the sense of breaking with the past and no longer compiling old programs, is never going to happen. Go 2 in the sense of being the major revision of Go 1 we started toward in 2017 has already happened."[1]
Granted, this post was more about if there will someday be a Go that will break backward compatibility. But it sort of answers where Go 2 is as a side effect.
by bananamogul - Why isn't it a good fit? The design prioritises readability of code that uses generics vs writing generic code (which is in line with the overall language philosophy). It also does it in a way that doesn't impact compilation speed or add too much complexity, which is also in line with the language philosophy.
If you don't like the fact that not all of standard library has been refactored to support the new language features -- I think it'll come over time. Once these features land into the standard library they can't be taken away, so the language authors take their time to make sure it's designed well.
I don't see anything going obviously wrong here.
by nasretdinov - > Since the addition of generics in Go 1.18 and iterators in Go 1.23, it has become possible for library-defined types to achieve comparable ergonomics to built-in types ...
For those who've been following Golang more diligently than myself: Is there a way now to define a slice-based type that enforces strict typing of its index, and yet preserves the compactness of the standard syntax "s[i]"?
- > Is there a way now to define a slice-based type that enforces strict typing of its index
Nope, no way to do that.
I wonder about ergonomics. I can imagine "academic" usage, but I shudder at the perspective of the impact on a typical CRUD app.
by kubanczyk - What do you mean by "strict typing of its index"?by bheadmaster
- No reference to Canadian Aboriginal characters in the comments :(by alfiedotwtf
- Welcome to Java, where Collections are the bread and butter of every programmer since 1998.
While you are at it, I humbly suggest to add composable streams too, that we had in 2014, and that make working with collections way more pleasant.
(Jokes aside, in Java it is very nice that you can start with a generic ArrayList and turn it into a linked list with one single keyword change and no code needs changing, or that you can turn any collection into a synchtonized or readonly doppelganger with one line of code. Collections are nice and I miss them in Golang)
by kamma4434 - Java? No thanks. I have some horrible memories from the ugliness, verbosity of Java. The cherry on the cake is the huge hog of an runtime called the JVM. Also java semi-forces you to have some bulky IDE. Last i looked there was no core java lsp server bundled in the tooling.
Java is the enterprise language that make programming suck.
by shikck200 - People use Go vs Java not because of the language differences but because of massive improvement that GO runtime is compared to JVM.
It is crazy that people still don't understand why JVM sucks, and why GO's approach to minimize GC pause latency is far superior design decision compared to whatever JVM has been trying to do with its GC iterations for god knows how many years with gazzillion different variants that all suck in different ways.
by tzone - Actually welcome to Smalltalk, 1980's, because that is where collections, and iteration with blocks, comes from as inspiration to Java, and all the folks that think LINQ was a .NET invention.by pjmlp
- First they said they won't add generics. They violently defended that decision. Developers bent over backwards to make it work without generics. Some even wrote long blog posts defending Rob Pike's decision. Some wrote posts arguing against it. Now the Golang team adds them. Why waste so much developer time? It's not a few months. It's several years. This industry is seriously a clown show tbh.
- Violently?by saturn_vk
- Huh? First they said they would: https://youtu.be/rKnDgT73v8s?t=3267 After a decade of nobody coming up with a solution that did turn to believing that Go would never be able to add generics. That is true. The air of defeat did become quite strong. But the Haskell guy did eventually came along to share his expertise and the rest is history.by win311fwg
- What’s wrong with meeting demand?
- At this point, the "damage" has been done and even skeptics of generics/iterators should applaud this proposal since it means burying some of that added complexity behind straightforward stdlib interfaces.
Unless they are just here to complain, of course.
by pphysch - Core members of the language team (Robert Griesemer and Ian Lance Taylor) argued for generics from the very beginning. The team resisted because they didn't know how to do it without sacrificing speed of compilation.
Rob Pike did a lot of defensive work to deflect it but I'll quote him here on the issue when he said "There are no plans for generics. I said we're going to leave the language; we're done":
"I meant there are no plans for generics. That's not the same as saying we plan not to do generics. It just means we don't have a plan."
You take it as a conspiracy against developers when it's really a small team trying to find their way the best they can.
by pstuart - Well, finally!
I wish they wouldn’t mix mutation methods in there, but ok.
by jiehong - It's cool that they're doing this but with iterators and soon in 1.27 generic method parameters, you can already DIY most of this with little effort. I've got iterators at work for nearly everything I could want, small libraries for extra mapping, filtering etc operations, and with agents going back and actually refactoring old code to use them is easier than ever.by dgunay
- Well adding the language features is a prerequisite to making these libraries possible.by ncruces
- Go is rediscovering Guy Steele's Growing a Language from first principles, at a much slower pace: https://youtu.be/_ahvzDzKdB0?is=qZdfiT3792XyHxSJby troupo
- Sounds like a win to me. I'd assume that many PL decisions come with with costs of either implementation or readability, and Go's conservative evolution takes that into account. Disclaimer: not a PL designer, just a codemonkey.
It's not a perfect language, and the process has not been without its pain points, but work like this makes the language more powerful and I feel like I get my money's worth when I use it.
Yes, I'm a Go fanboy but I'm not interested in language wars (e.g., yes Rust is more performant and correct but sometimes "good enough" is good enough).
by pstuart - It's sad that such basic stuff took this long. If we're lucky we might even see a `Map` function in our lifetimes.by silverwind
- I find it so sad that people wasted millions of hours and lines of code rewriting over and over basic constructs that should have been on the language in the first place. How many years before we finally get sum types?by vander_elst
- It's not like your idea is bad, is that each abstraction eats in one of the fundamental strengths of Go (simplicity and compilation times).by epolanski
- Well, better late than never. Stuff like sets or a typed heap is long overdue. Maybe they'll even add iterator API for database/sql results this decade too (something like my pull request for sqlx https://github.com/jmoiron/sqlx/pull/990 but maybe more polished)by nasretdinov
- Better late and well designed, than early and poorly designedby Ferret7446
- You’d have a better chance of getting your PR accepted into https://github.com/Vinovest/sqlxby smithcoin