8 ms·
It is great that Go1.20 improves compile times after generics were added in Go1.18 [1]! Overall, I think adding generics to Go was a big mistake. It brings the
by valyala 4y ago
It is great that Go1.20 improves compile times after generics were added in Go1.18 [1]!
Overall, I think adding generics to Go was a big mistake. It brings the following drawbacks:
- Slower compile times, even if generics aren't used. This slows down development pace in Go.
- The reduced code readability if generics are used. This slows down development pace in Go.
- The increased complexity of Go compiler. This slows down Go compiler development and increases chances for bugs.
- Very low adoption of generics in practice, since they aren't useful in most Go code bases. The generics are actively used in some freaky packages only after the year since they were released in Go1.18.
The only useful thing from Go generics is a syntactic sugar, which allows replacing `interface{}` with `any`.
[1] https://go.dev/doc/go1.20#compiler https://go.dev/doc/go1.20#compiler
- zeeboo 4y agoYou forgot to list the most useful feature of adding generics: people on the internet can no longer say "lol no generics", drastically reducing the amount of garbage comments about Go.
- valyala 4y agoExcept that these people now pollute the Internet with freaky packages, which use generics in esoteric ways :)
- 0x62c1b43e 4y agoBut if adoption is “very low”, then it’s not much pollution, is it?
- thunky 4y agoThose comments have now been replaced with "adding generics to Go was a big mistake".
- philosopher1234 4y agoMaybe they will, but they haven't, since this is the first time I've seen that comment. The "lol no generics" was endemic.
- 0x62c1b43e 4y agoIt’s hard to be objective because of filter bubbles, but I’ve seen it a lot on Reddit last.
- 0x62c1b43e 4y ago*lately It pops up on /r/golang sometimes. I don’t think it gets taken super seriously but there’s usually at least someone bringing it up.
- deleted 4y ago[deleted]
- SPBS 4y agoThey'll never go away, it just morphed into "Go was wrong and finally learnt the lesson that Java 5 did 19 years ago by adding in generics". Go showed that useful software could be written without user-level generics. I don't think any other language today would dare to do that. In fact most languages seem to be converging into the same thing.
- pjmlp 4y agoWe already knew how to write useful software without user-level generics, we have been doing it for decades since FORTRAN came to be in 1957, no need for Go to prove anything beyond the stubbornness of its designers.
- Macha 4y agoUseful software can also be written in asm and we have the entire early software industry to demonstrate that. That's not the same as it being a good idea
- valyala 4y agoGo is about productivity. It allows writing, extending and maintaining big codebases with lower efforts comparing to assembly or some other programming language out there. This is because of simple "what you read is what you get" syntax without implicit code execution. Generics break this feature :( Of course, there are other brilliant features in Go ecosystem, which simplify writing and maintaining non-trivial codebases in Go - tooling, standard library, fast compile times, statically linked binaries, etc.
- Macha 4y agoI mean, here's the Go 1.18 release notes and what they have to say about the dev team's level of faith in the stability of their implementation: https://go.dev/doc/go1.18 https://go.dev/doc/go1.18 Is it a surprise that the low uptake is there with a discouragement like that?
- valyala 4y agoI'm sorry, but I don't get this comment. Go is a great programming language! It is great because it is easy to write, read and maintain programs written in Go. This is because of the following features: - Simple syntax - Fast compile times - Great tooling (go fmt, go vet, go too pprof, go tool cover, race detector, ect.) - Useful standard library Generics do not improve any of these features :( They complicate syntax, they slow down compile times and they complicate internals of go compiler and tools.
- valyala 4y agoBTW, it is great to see that Go1.20 and the upcoming Go1.21 [1] return to good things instead of generics: - Performance optimizations (profile-guided optimization, GC optimizations, etc.) - Reducing compile times - Reducing binary sizes (improved linker, which can throw away unused code more aggressively) [1] https://groups.google.com/g/golang-dev/c/V8ez4YunkeE https://groups.google.com/g/golang-dev/c/V8ez4YunkeE
- philosopher1234 4y agoI doubt that was very widely read. I think it would be a mistake to attribute much of the adoption to that statement.
- iio7 4y agoExactly this! It's such a shame generics where added.
- zxcvbn4038 4y agoYou missed the highlight - the best part of go generics is it shut up all the people whining that go didn't have generics! =)
- mseepgood 4y agoYou acknowledge in the first sentence that compile times are back in line with Go 1.17 (i.e. pre generics), yet you claim that generics mean slower compile times.
- valyala 4y agoGo1.18 and Go1.19 have slower compile times comparing to Go1.17 even for codebases, which do not use generics. For example, VictoriaMetrics [1] - the project I work on, which is written in Go without generics. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/ https://github.com/VictoriaMetrics/VictoriaMetrics/
- rom-antics 4y agoYes but these are release notes for Go 1.20. (1) Make it work, (2) make it right, (3) make it fast They did 1 and 2 in the last two releases, and in Go 1.20 they did (3). So what's left to complain about?
- valyala 4y agoWhy to spend time and efforts for adding useless generics in the first place? Maybe it would be better spending this time on performance optimizations, compile times optimizations and binary size optimizations instead.
- 0x62c1b43e 4y agoI’m gonna be that guy, but do you have sources for any of this? That link shows that compiler performance is the same as before generics, for instance. Are there more bugs in the compiler? Is readability reduced, and having an effect on pace? Especially if adoption is so low to begin with? Is adoption actually so low, or just rising?
- valyala 4y agoThat link admits that the compiler performance was lower than needed in Go1.18 and Go1.19, because of generics, even when compiling Go code without generics. I can confirm this based on my own open source projects written in Go [1]. [1] https://github.com/valyala/ https://github.com/valyala/
- 0x62c1b43e 4y agoI understand, but it shows that compiler performance is the same as before generics now, so any performance hit is gone.
- valyala 4y agoBut the time spent on designing, implementing and then optimizing the generics is lost. This time could be spent on more valuable things for Go ecosystem.
- 0x62c1b43e 4y agoGenerics consistently showed up as one of the most desired features (if not the most desired) by working Go developers in the previous developer surveys, so I think it makes sense that the Go team felt the ecosystem saw much value in it relative to other features and worth the time.
- valyala 4y agoUnfortunately, the Go team was misguided by vocal minority who was using the "missing generics" argument as an excuse why they do not switch to Go from their favorite programming languages. The majority of working Go developers were happy with Go, so they didn't take part in the debates and surveys about generics. The irony is that vocal minority still do not use Go, since they have other excuses now - "bad error handling", "missing functional features", etc. But if these harmful features will be implemented in Go, the vocal minority will find another reason why they do not use Go.
- jen20 4y ago> - The reduced code readability if generics are used. This slows down development pace in Go. Speak for yourself: I prefer generics to the mess if copy-pasta or generated stuff that one had to use before.
- valyala 4y agoCould you provide a few links to popular open source projects, which switched to generics and got better code because of this?
- cpuguy83 4y agoCan you point to one that had the opposite effect?
- valyala 4y agoNo. I suppose, maintainers of popular open source projects couldn't justify introducing generics into their code. This is exactly my story - I was actively seeking places in VictoriaMetrics codebase, which could benefit from switching to generics. Unfortunately, not a single place has been found yet. There was a promising place for generics [1], but it has been appeared that it is better from readability and maintainability PoV to use plain old interfaces instead. [1] https://github.com/VictoriaMetrics/VictoriaMetrics/blob/master/lib/blockcache/blockcache.go https://github.com/VictoriaMetrics/VictoriaMetrics/blob/mast...
- cpuguy83 4y agoTacking on generics on a working code base is difficult. I effectively used it in this little experimental CLI library: https://github.com/cpuguy83/go-cli/blob/main/command.go https://github.com/cpuguy83/go-cli/blob/main/command.go It's pretty simple, but the nice thing is it can use any flag library you want (stdlib flag package, pflag, whatever).
- valyala 4y ago
- smasher164 4y agoI use generics all the time in my Go code, in particular with the exp/slices library and lo. I do not find it less readable. I think readability is subjective based on people's programming experience and familiarity with type systems.
- 12345hn6789 4y agoworse program readability is not a true con. Any codebase can have positive or negative code quality, generics do not make this worse. In fact, it can improve readability and maintainability in some cases instead of having multiple structs copy pasted everywhere.
- philosopher1234 4y ago>worse program readability is not a true con. Any codebase can have positive or negative code quality, generics do not make this worse. While true that generics are not necessarily going to make programs harder to read, it's also not very interesting to talk about theory. The question which is answerable is, "on average, were go programs easier to read before the introduction of generics". The interesting point is what actually happens, not what could.
- 12345hn6789 4y agoYou are correct that we must observe this in practice. But, the original poster of this thread purports that generics are making go worse in multiple ways. 1: Slower compile times (without evidence) and 2: have created worse code (without evidence)
- philosopher1234 4y agoSure, they haven't proven their claim. This is all the realm of speculation.
- kune 4y agoAt first I was on the fence too. I'm not use it all the time, but when I need it, it works as expected and it is much less a hassle than I remember writing C++ templates. I have not seen a lot of comments that complained about the slower compile times. In my own experience it didn't really had an impact. But I agree the compiler should not become slower over time, so I appreciate the effort of the Go team to bring the compiler speed back. I don't think that code readability is so much impacted. The square brackets work well. I find the angle brackets from C++ harder to read and there is the problem that >> is a token and cannot be used for two closing template angle brackets. The increased complexity of the compiler is an issue, but cannot be avoided if you want to support Generics. But they took the time to make it right and as I stated it works for me. I don't think that there is low adaption. Using type parameters visibly in a public API, breaks the API, which is the reason there are not a lot of uses in the standard library and with popular packages now. But this will change when maps and slices will be integrated in the standard library, which provide completely new APIs. Yesterday I found a library writing and reading parquet files, which used it quite extensively. But since I simply checked what libraries existed to assess how well the file format is supported, I cannot say much whether the use of type parameters by the library is useful.
- School-Cotton 4y ago> there is the problem that >> is a token and cannot be used for two closing template angle brackets. This was fixed years ago in C++11.
- Conscat 4y agoThey still have other issues, though. You ever had to put `template` before a templated member function called from an object of a `typename` type? Not fun, yet I have to do it all the time in my C++ code. MSVC and Comeau make this problem optional, but GCC and Clang don't (as per the standard). The chevrons also confuse all my editors, because they can't figure out whether `<` is an opening bracket pair, or if its just a less-than operator. I'm a bit miffed that Cpp2 doesn't try to replace the chevrons with something else, like D did. I'm also miffed that Rust uses the chevrons too.