There is a path to upgrading library functions to generics, it will come in a later release. Looked like default generic type of the empty interface for those functions. See the other issues linked from the original.
> Still great to see things improving. It took mere 11 years.
Took that much time because of little clique of people outside the go team had way too much influence in the Go community. Let see if they dump the language like they threatened to, as the result of adding generics. Of course they won't.
Generics are there if one wants to, and they aren't like Java, but ADA. ADA got a lot of things right decades ago including the way tasks work from which Go routines should have taken a bit more inspiration .
What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess.
I'm excited about the prospect of having iterators. It will enable a different, more consistent programming style.
I'm also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.
> What will likely happen is that the users will design generic libraries themselves. There will likely be a couple, and eventually they will converge on the most useful features. Then the Go team can just get inspiration from that I guess.
Most likely yes, or as stated in the ticket, they'll take the existing proposal and implement it in golang.org/x/, where they've had some success fleshing out the design of new packages before incorporating into the standard library. It's worked out well, as early adopters can adopt and generally have a painless transition once included in the standard library.
I agree with iterators and immutable collections -- it's been painful working with trees in go, so hopefully that gets a bit easier now.
Honestly, I'm excited to see what will come of generic functions for channels. Being able to write a generic Dup(in chan T, out ...chan T), or a CtxRecv(context.Context, chan T) (T, error) to cut down on some boilerplate select statement.
Or, if history is a guide, there will be a few really nice generic libraries written and a sizable minority of developers will adopt them as pseudo standard to fill the void. Then the Go team will do what they want, fracture the community, and alienate those who expected your described path to be the one taken.
Hm, shouldn't they first update the (most important/interesting) libraries in a fork before stabilizing generics?
I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.
Yes that would be a good idea. However, they could already have a generic collection lib in the same place (branch/repo) where the generics feature is created.
Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn't define their own, as it'll take time to crawl out of that.
Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that.
> Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.
tl;dr: We're shipping generics in 1.18, it's a huge release so let's wait a little bit until they stabilise and they're used in production before changing our stdlib.
Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better!
It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually.
With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust?
EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.
Nobody "hates" on Go for the sake of it. If some people were not critical of that language, generics would have never been added at first place. I'm glad the Go team acknowledged the flaw instead of the gaslighting that has been going on for years in the go community from a few go users.
> it's taken over the system programming space for a reason
I'm curious what you define as systems programming, because Go certainly isn't a systems programming language by the classic definition.
Go has a complicated runtime and GC. It's really not in the same category as C/C++/Rust, but more like Java/C# , just without a JIT.
The only domain where Go is a go-to language is the Kubernetes ecosystem. It's also decently popular for networking heavy applications / microservices / server applications, because the runtime is well suited for those domains.
Go has taken over kuberbetes related stuff, that is all.
Although I like it being used for systems programming stuff like TinyGo on embedded or F-Secure TamaGo unikernel, that is hardly taking over the domain where C and C++ still rule, and will keep to do so for decades to come, despite the increasing usage of Rust on the domain.
That's because you can put out there why you like a language and people will upvote you. Dump on other people's choice in a systems language and you will likely suffer some down votes. Cheeky has a price.
Brad Fitzpatrick stated in one of his talks, that a version of Go coming with generics will be called 2.0 eventually. Maybe they do the version jump if there are backward-incompatible changes done to the library in 1.19.
JavaScript/TypeScript changes so much that a codebase will look very different from one year to the next. JS/TS has come a long way and needed to make substantial change, but I appreciate the slow moving, methodical nature in which the Go team moves the language and environment forward.
in HTML template, it will interpret // as a comment and return
<script>var string = `http:</script>
This is now really hard to fix; it means either rewriting the JS parser from scratch, but that is a giant change (currently the JS parser is really simple, backticks are hard to do properly without reimplementing all from scratch); the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat.
So there is basically an unfixable bug sitting in go html templates.
I was really looking forward to getting some basic generic standard library funcs. Guess what I'm getting now is a a ton of std libraries each with a slightly different approach, slightly different bugs and update cycles which will nicely inflate the amount of tech debt in existing codebases.
I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won't really hurt anyone and for those that really really want it they can enable it through build constraints.
C++17 introduced std::optional and std::variant, but they're not used by the standard library in 2021, as far as I've seen (unlike Rust which is better off for using them). It feels quite like a missed opportunity to produce more ergonomic APIs (though the inability to produce an optional<T&> is limiting, and std::variant is inefficient at compile and possibly runtime and apparently can't be fixed because ABI). I'm not a Go user, but I dislike multiple competing approaches to problems without clear guidance or fully embracing newer approaches.
Go is not in the business of copy-pasting other language designs. That much should be obvious by now.
The questions aren't around the algorithms. They're about Go specific things like how to deal with legacy std library parts that are made obsolete by generics.
the proposal isn't to not implement them at all, it's to not immediately incorporate them in a way that they're permanently frozen.
they'll implement them in some versioned package that everyone can adopt and play with, and then incorporate them.
fracturing could happen. but that could happen if they immediately included it in the standard library with warts, too. I can easily imagine people creating multiple packages to overcome shortcomings of a half baked stdlib package.
..so I don't want go to follow some fearful path because of some unquantifiable risk that may or may not come to pass, and could come to pass regardless of which path they take.
To be fair, Go has quite successfully (IMO) not implemented features, waited for the community to come up with several different implementations, and then implemented that feature in a way that they like, without fracturing the ecosystem. Examples that come to mind are `//go:embed` and dependency management via `go mod`.
[+] [-] nine_k|4 years ago|reply
OTOH this removes much of the point to use generics, and makes working with stdlib from type-parametric code more painful.
Still great to see things improving. It took mere 11 years.
[+] [-] verdverm|4 years ago|reply
[+] [-] tonetheman|4 years ago|reply
[+] [-] throw_m239339|4 years ago|reply
Took that much time because of little clique of people outside the go team had way too much influence in the Go community. Let see if they dump the language like they threatened to, as the result of adding generics. Of course they won't.
Generics are there if one wants to, and they aren't like Java, but ADA. ADA got a lot of things right decades ago including the way tasks work from which Go routines should have taken a bit more inspiration .
Congrats to the Go time anyhow.
[+] [-] kubb|4 years ago|reply
I'm excited about the prospect of having iterators. It will enable a different, more consistent programming style.
I'm also hoping for immutable collections, even though the lack of specialization will make it more difficult to implement them efficiently. They would enable a more robust way to build concurrent systems.
[+] [-] chrsig|4 years ago|reply
Most likely yes, or as stated in the ticket, they'll take the existing proposal and implement it in golang.org/x/, where they've had some success fleshing out the design of new packages before incorporating into the standard library. It's worked out well, as early adopters can adopt and generally have a painless transition once included in the standard library.
I agree with iterators and immutable collections -- it's been painful working with trees in go, so hopefully that gets a bit easier now.
Honestly, I'm excited to see what will come of generic functions for channels. Being able to write a generic Dup(in chan T, out ...chan T), or a CtxRecv(context.Context, chan T) (T, error) to cut down on some boilerplate select statement.
[+] [-] cy_hauser|4 years ago|reply
[+] [-] IceWreck|4 years ago|reply
the Go team has already made the libraries, theyre just publishing them in the /x/ namespace instead of the stdlib.
/x/ has everything that's not under the Go compatibility promise, among other things from the Go project.
[+] [-] dathinab|4 years ago|reply
I mean designing a feature in a clean room is one think, but using it a the standard library would be a good way to know if they messed up the design in some way.
[+] [-] spockz|4 years ago|reply
[+] [-] cube2222|4 years ago|reply
Though the second comment has merit too, I think it would be good to have some common abstraction right away, like we had io.Writer, io.Reader, etc. so everybody doesn't define their own, as it'll take time to crawl out of that.
Although in practice it did work out well with error wrapping which was first in libraries and then the stdlib defined an interface for them, which resulted in all libraries adopting that.
> Similarly, if constraints isn’t part of 1.18, there will be a lot of independent redefinitions of orderable types. I don’t think we’re going to learn from experience much that could change that package now.
[+] [-] sph|4 years ago|reply
Good call in my book, and I'm extremely excited to have generics finally. I thought they were going to ship with 2.0, but the sooner the better!
It's cool to hate on Go, it's taken over the system programming space for a reason, like it or not, and after working full time on Elixir it's hard not to think in map/reduce and other generic constructs, which were unreasonably verbose before in Go. Now the haters will have to focus on the "if err != nil" statement to pile on the language — though to be fair I'll expect some ergonomic improvement on that aspect as well, eventually.
With generics, Go will be my new Python, but with a decent dependency and deployment story, and I'll just need Zig for my low-level manual memory management needs. What's Rust?
EDIT: indeed being a bit cheeky with HN's favourite language isn't well received in this place.
[+] [-] throw_m239339|4 years ago|reply
criticism =/= hate
Nobody "hates" on Go for the sake of it. If some people were not critical of that language, generics would have never been added at first place. I'm glad the Go team acknowledged the flaw instead of the gaslighting that has been going on for years in the go community from a few go users.
[+] [-] the_duke|4 years ago|reply
I'm curious what you define as systems programming, because Go certainly isn't a systems programming language by the classic definition.
Go has a complicated runtime and GC. It's really not in the same category as C/C++/Rust, but more like Java/C# , just without a JIT.
The only domain where Go is a go-to language is the Kubernetes ecosystem. It's also decently popular for networking heavy applications / microservices / server applications, because the runtime is well suited for those domains.
[+] [-] cageface|4 years ago|reply
[+] [-] EdwardDiego|4 years ago|reply
[+] [-] pjmlp|4 years ago|reply
Although I like it being used for systems programming stuff like TinyGo on embedded or F-Secure TamaGo unikernel, that is hardly taking over the domain where C and C++ still rule, and will keep to do so for decades to come, despite the increasing usage of Rust on the domain.
[+] [-] stjohnswarts|4 years ago|reply
[+] [-] paedubucher|4 years ago|reply
[+] [-] another_Hans_M|4 years ago|reply
[+] [-] olingern|4 years ago|reply
[+] [-] shp0ngle|4 years ago|reply
For example, there is a bug in go’s built-in HTML templating, that it misrepresent javascript backticks.
If you do
<script> var string = `http://google.com` </script>
in HTML template, it will interpret // as a comment and return
<script>var string = `http:</script>
This is now really hard to fix; it means either rewriting the JS parser from scratch, but that is a giant change (currently the JS parser is really simple, backticks are hard to do properly without reimplementing all from scratch); the more reasonable choice would be to just ban backticks in HTML templates, but that would break backward compat.
So there is basically an unfixable bug sitting in go html templates.
https://github.com/golang/go/issues/9200
[+] [-] Zababa|4 years ago|reply
Only if you want it to change. Our codebase is plain JS/TS, we don't use many recent features, and it's fine.
[+] [-] dreyfan|4 years ago|reply
[+] [-] crnkofe|4 years ago|reply
I guess from the standpoint of a language designer it makes life a bit easier not to do anything and just cherry pick the winners of the various generic attempts that the community will create but as an app. developer I find this disturbing. Also I question the rush to a release all of a sudden. Generics took years to come to fruition. Another year for a decent stdlib won't really hurt anyone and for those that really really want it they can enable it through build constraints.
[+] [-] nyanpasu64|4 years ago|reply
[+] [-] The_rationalist|4 years ago|reply
[deleted]
[+] [-] qaq|4 years ago|reply
[deleted]
[+] [-] Strom|4 years ago|reply
The questions aren't around the algorithms. They're about Go specific things like how to deal with legacy std library parts that are made obsolete by generics.
[+] [-] chrsig|4 years ago|reply
they'll implement them in some versioned package that everyone can adopt and play with, and then incorporate them.
fracturing could happen. but that could happen if they immediately included it in the standard library with warts, too. I can easily imagine people creating multiple packages to overcome shortcomings of a half baked stdlib package.
..so I don't want go to follow some fearful path because of some unquantifiable risk that may or may not come to pass, and could come to pass regardless of which path they take.
[+] [-] jamesrr39|4 years ago|reply