3 ms·
> For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a l
by gwd 10mo ago
> For Go, I wouldn't say that the choice to avoid generics was either intentional or minimalist by nature. From what I recall, they were just struggling for a long time with a difficult decision, which trade-offs to make.
Indeed, in 2009 Russ Cox laid out clearly the problem they had [1], summed up thus:
> The generic dilemma is this: do you want slow programmers, slow compilers and bloated binaries, or slow execution times?
My understanding is that they were eventually able to come up with something clever under the hood to mitigate that dilemma to their satisfaction.
[1] https://research.swtch.com/generic https://research.swtch.com/generic
- deleted 10mo ago[deleted]
- mirashii 10mo agoI’m not sure there’s anything clever that resolved the issues, they just settled on slow execution times by accepting a dynamic dispatch on generics.
- gwd 10mo agoNot according to this post: > Go generics combines concepts from "monomorphisation" (stenciling) and "boxing" (dynamic dispatch) and is implemented using GCshape stenciling and dictionaries. This allows Go to have fast compile times and smaller binaries while having generics. https://deepsource.com/blog/go-1-18-generics-implementation https://deepsource.com/blog/go-1-18-generics-implementation
- nasretdinov 10mo agoYes, note lack of mention of speed :)
- zozbot234 10mo agoIronically, the latest research by Google has now conclusively shown that Rust programmers aren't really any "slower" or less productive than Go programmers. That's especially true once you account for the entire software lifecycle, including production support and maintenance.
- samdoesnothing 10mo ago"research", it's a bunch of rust fans at google who are claiming it, without any real serious methodology.
- gwd 10mo agoIn this context, the the "slow programmer" option was the "no generics" option (i.e., C, and Go before 1.18) -- that is, the programmer has to re-implement code for each separate type, rather than being able to implement generic code once. Rust, as I understand it, followed C++'s path and chose the "slow compile time and bloated binaries" option (in order to achieve an optimized final binary). They call it "zero cost abstractions", but it's really moving the cost from runtime to compile time. (Which, as TFA says, is a tradeoff.)
- hu3 10mo agoCould you point the research? I only found a blog-like post with bold claims and no statistical significance.