Hacker News Reader

Comment by mseepgood | Hacker News Reader

You 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.

View on HN

Go1.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/

Yes 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?

Why 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.

Because I would rather write one generic container library than n slightly different ones for each data type of deal with screwing around with casting interfaces?

This sounds good in theory. What about practice? Could you provide a few links to popular Go packages, which benefit from using generics?

Because it's extremely useful to have adaptable data structures, without byzantine code generation?

Could you provide links to a few Go packages, which implement useful generic-based data structures?

Try google.

Because they’re not useless.

Thanks for very strong argument :)

No weaker than yours :)

Reply on news.ycombinator.com