5 ms·

I don't believe Go is about to get faster, at least not in an especially unique way compared to past releases. Historically the Go compiler has been seeing per

I don't believe Go is about to get faster, at least not in an especially unique way compared to past releases. Historically the Go compiler has been seeing performance improvements every release, so historically, Go has always been getting faster. When it comes to Generics, the benefits are not so straightforward as simply recompiling with a new binary. I just rebuilt one of our larger services with Go 1.17 and compared it to 1.18 and the benchmarks come out roughly the same after variance. There is a slight improvement, but what's interesting is that we don't use generics anywhere. My employer has a blanket ban on Generics in Go until at least the next release. I know others that do too. There is also nothing in our code base that is screaming to be rewritten with Generics. We collectively thought about it and no one could come up with anything worthwhile. Internally, we're still not sure when they're even warranted. Sure, there's a few three line for-loops that could be removed, but none of those are in a hot path. Yawn. If Go generics radically change the Go ecosystem overnight, they will ruin the language. The ecosystem prefers stability and compatibility over features, and it's pervasive and good. I update Java and JavaScript dependencies regularly and it's a fucking nightmare compared to Go. Lastly, Go had attracted a large community of developers who eschew unnecessary abstractions. It's lovely and refreshing. I can't say the same about Rust or Swift or Scala, where complexity is sometimes celebrated as simplicity when it's really just convenience wearing lipstick.

SPBS 5y ago
> eschew unnecessary abstractions The problem is, no one can agree on what is the 'necessary level of abstraction'. Where you stand on that scale determines whether you love or hate Go as a language.
throw6622 5y ago
If I understand correctly, what you’re saying is “Go won’t immediately get faster with this release, it will immediately get faster with the next and subsequent releases”. Whether your employer uses generics or not, it’s very likely large parts of the standard library will get rewritten with them soon, and if OP is correct, it will improve the performance greatly of certain operations.
- xyzzy_plugh 5y ago
  > it’s very likely large parts of the standard library will get rewritten with them soon It's not. The Go 1 backwards compatibility promise means existing interfaces won't change. Take the Math package for instance: I'm not aware of any planned breaking changes -- if you are, please share. If they were to add support for non-int64 operations, they would likely be separate functions or a new package. This, without sweeping code changes, nothing changes.
  - stitched2gethr 5y ago
    The Go team has been discussing converting some functions to generics _if_ they can maintain the compatibility guarantee. Without verifying, I believe this was discussed in Go Time ep 216.
tgv 5y ago
I also do hope the eco-system stays as dependable and conservative as it is. There's no practical need to overhaul it, and in the end, it's about what works. Don't mess it up. I do have some use for generics in my code: I've got a few conversion functions too many, but since they're narrowly typed, I don't expect a speed improvement, just a shorter file. Perhaps some of the (un)marshalling can be done more efficiently, too. Nothing worth losing any sleep over, so waiting another version sounds like a good strategy. I'll just play around with it a bit.
Wilem82 5y ago
Java was released in 1996. It got generics in 2004, 8 years later. I don't remember anyone panicking and yelling from every corner that the world is ending. Everyone understood the benefits and it was a much awaited feature. And yes, after Java got them, it became easier and more typesafe to use. End of story. And by the way, Java too was a very simple language and generics didn't ruin it.
- badsectoracula 5y ago
  I never liked generics in Java - or basically the stuff they added together with them, like annotations and autoboxing - i felt they complicated and "ruined" the original language which was conceptually very simple. But by the time Java 5 became mainstream (i was working on desktop software so i had to keep compatibility with older runtimes anyway - not that i minded at all) i had already moved off Java aside from some of minor projects of my own (but i dropped even those after Oracle's acquisition of Sun as i didn't feel like relying on it). I do remember getting annoyed with NetBeans and Eclipse "helpfully" adding little squiggles everywhere in my code about how i could "improve" it with ranged fors, replacing typecasts in container usage with generics and adding those ugly @override annotations (which i manually removed whenever NetBeans added them on its own when it was creating code via the GUI editor). I guess i could disable them but as i wrote, i moved on after that anyway. Of course i never panicked or yelled about it nor really even bothered mentioning it (aside from on HN now and then, usually in Go posts since the whole "generics in go" remind me of that time :-P). But me not doing that doesn't mean i didn't think of it and i'm guessing others did too. My guess is that nowadays you see more complaints about generics in Go because Go largely attracted a higher percentage of people who liked its simplicity than Java ever had (and more people in absolute numbers in general as i'd bet that there are way more programmers nowadays than in late 90s/early 2000s, so you're bound to hear more voices). After all in terms of features as a language Go didn't had anything to offer over Java whereas Java had a lot to offer back in the late 90s/early 2000s. (amusingly the language i use most nowadays is Free Pascal which is a hodgepodge of arbitrary features and a far cry from the original Java simplicity - though i do often find annoying how much of a "mess" it is)
kasi_hasi 5y ago
This article is about optimized algorithms. Those could be written as specialized implementations without generics, but with generics people can build reusable libraries. Did you even read the article?

SPBS 5y ago

> eschew unnecessary abstractions The problem is, no one can agree on what is the 'necessary level of abstraction'. Where you stand on that scale determines whether you love or hate Go as a language.

throw6622 5y ago

If I understand correctly, what you’re saying is “Go won’t immediately get faster with this release, it will immediately get faster with the next and subsequent releases”. Whether your employer uses generics or not, it’s very likely large parts of the standard library will get rewritten with them soon, and if OP is correct, it will improve the performance greatly of certain operations.

xyzzy_plugh 5y ago
> it’s very likely large parts of the standard library will get rewritten with them soon It's not. The Go 1 backwards compatibility promise means existing interfaces won't change. Take the Math package for instance: I'm not aware of any planned breaking changes -- if you are, please share. If they were to add support for non-int64 operations, they would likely be separate functions or a new package. This, without sweeping code changes, nothing changes.
- stitched2gethr 5y ago
  The Go team has been discussing converting some functions to generics _if_ they can maintain the compatibility guarantee. Without verifying, I believe this was discussed in Go Time ep 216.

tgv 5y ago

I also do hope the eco-system stays as dependable and conservative as it is. There's no practical need to overhaul it, and in the end, it's about what works. Don't mess it up. I do have some use for generics in my code: I've got a few conversion functions too many, but since they're narrowly typed, I don't expect a speed improvement, just a shorter file. Perhaps some of the (un)marshalling can be done more efficiently, too. Nothing worth losing any sleep over, so waiting another version sounds like a good strategy. I'll just play around with it a bit.

Wilem82 5y ago

Java was released in 1996. It got generics in 2004, 8 years later. I don't remember anyone panicking and yelling from every corner that the world is ending. Everyone understood the benefits and it was a much awaited feature. And yes, after Java got them, it became easier and more typesafe to use. End of story. And by the way, Java too was a very simple language and generics didn't ruin it.

badsectoracula 5y ago
I never liked generics in Java - or basically the stuff they added together with them, like annotations and autoboxing - i felt they complicated and "ruined" the original language which was conceptually very simple. But by the time Java 5 became mainstream (i was working on desktop software so i had to keep compatibility with older runtimes anyway - not that i minded at all) i had already moved off Java aside from some of minor projects of my own (but i dropped even those after Oracle's acquisition of Sun as i didn't feel like relying on it). I do remember getting annoyed with NetBeans and Eclipse "helpfully" adding little squiggles everywhere in my code about how i could "improve" it with ranged fors, replacing typecasts in container usage with generics and adding those ugly @override annotations (which i manually removed whenever NetBeans added them on its own when it was creating code via the GUI editor). I guess i could disable them but as i wrote, i moved on after that anyway. Of course i never panicked or yelled about it nor really even bothered mentioning it (aside from on HN now and then, usually in Go posts since the whole "generics in go" remind me of that time :-P). But me not doing that doesn't mean i didn't think of it and i'm guessing others did too. My guess is that nowadays you see more complaints about generics in Go because Go largely attracted a higher percentage of people who liked its simplicity than Java ever had (and more people in absolute numbers in general as i'd bet that there are way more programmers nowadays than in late 90s/early 2000s, so you're bound to hear more voices). After all in terms of features as a language Go didn't had anything to offer over Java whereas Java had a lot to offer back in the late 90s/early 2000s. (amusingly the language i use most nowadays is Free Pascal which is a hodgepodge of arbitrary features and a far cry from the original Java simplicity - though i do often find annoying how much of a "mess" it is)

kasi_hasi 5y ago

This article is about optimized algorithms. Those could be written as specialized implementations without generics, but with generics people can build reusable libraries. Did you even read the article?