4 ms·
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
by valyala 4y ago
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/ 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.
- oauea 4y agoBecause it's extremely useful to have adaptable data structures, without byzantine code generation?
- girvo 4y agoBecause they’re not useless.
- vlowther 4y agoBecause 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?
- valyala 4y agoThis sounds good in theory. What about practice? Could you provide a few links to popular Go packages, which benefit from using generics?