95% was a recalled-guess. I previously linked to an academic paper that studied uses of generics in Java, and I believe that was the number - regardless it was a very, very high percentage.
Interestingly, I had a previous client that was a case-study in generics gone wrong. No kidding, they had created Couple..Sextuple using generics, so you would read code that literally looked like this. x = new Sextuple<Long,Long,Map<Long,String>,Integer,Pair<String,Map<Long,Long>>,Boolean> Then you would put these in a generic map… Ugh. Prior to generics no one would of thought of doing something like this - they would have declared concrete classes, and container wrappers - similar to Go. I’ll state for the record again, I was originally very dismayed that Go did not offer generics - after developing with it for a while that is far less of an issue to me than the error handling. I think the generics can be reasonably better solved by external code generators and go:generate - there are alternatives to “generics” as a language change. > On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > Hi, > > On Thu, Dec 31, 2020 at 8:59 AM wilk <w...@flibuste.net > <mailto:w...@flibuste.net>> wrote: > If 95% of generics are collections the current draft is overkill. > What about a simplified version with only one generic type (like we do > with interface{}), without constraint as long as it can compile ? > > • "Only one generic type" means you can't write generic maps or graph > structures > • "Without constraints" means compilation cost goes up significantly (as the > compiler needs to completely redo type-checking and compilation for each > instantiation - instead of only checking that the function adheres to the > constraints and the type-arguments fulfill it at each call-site. i.e. you > make an NxM problem out of an N+M problem). It also makes good error messages > very hard. And the constraints need to be documented anyway (in a comment, if > nothing else), so that the user knows how to call the function - might as > well have a standardized, machine-checkable way to express that. > > So even *if* we only consider containers, the complexity of the design isn't > accidental. There are very concrete (and IMO important) advantages to these > decisions. > > That being said, I also, personally, don't consider type-safe containers the > main use-case of generics. It's certainly *one*, and one that can't be solved > without them. I definitely see the advantage of being able to implement > complex data-structures like lock-free concurrent maps or sorted maps as a > library and use them in really performance-sensitive code-paths. But I also > feel that my concerns about generics mainly stem from experiences with Java > and C++ where *everything* was expressed in terms of abstract generic > containers and algorithms, cluttering the code and requiring you to > understand subtle differences between different implementations of the > implementations of the abstract versions. So, personally, I really hope > containers are *not* 95% of the use-case of generics. In fact, if type-safe > containers *where* 95% of the use-case, I would still be very much opposed to > adding generics - I don't think we really *need* type-safety for containers, > as we are usually very well aware of what's stored in them. > > Personally, the main use-case for generics I see (and I want to emphasize > that everyone sees different use-cases as more or less important, depending > on what kind of code they write) is the ability for concurrency as a library. > I think channels and goroutines are great concurrency primitives - but they > are primitives, that need to be composed to be useful. And this composition > is usually very subtle and hard to get right. So being able to solve these > composition problems once and re-use that solution, seems very exciting to > me. But, again, that focus comes from the kind of code I write. > > The third use-case I see for generics is to catch bugs by being able to > express more complicated type-invariants in code. An example of that would be > type-safety for context.Value > <https://blog.merovius.de/2020/07/20/parametric-context.html> (or, similarly > but subtly different, optional interfaces of http.ResponseWriter). However, > for this use-case, I personally don't see the value-add vs. complexity > tradeoff > <https://blog.merovius.de/2017/09/12/diminishing-returns-of-static-typing.html> > as very favorable - the type-system needs a *lot* more power to catch > significantly more bugs and more power translates into a lot of complexity. > I don't think the current draft lets us express very powerful invariants. And > while I wouldn't really advocate to make that a target, I think it would be > interesting to see more discussion of this area - i.e. more case-studies of > where Go has type-safety problems and if the current design can address them. > > > func add(x, y GenericType) GenericType { > return x + y > } > > add(1,2) // add can compile : func add(x, y int) is generated > add("abc", "def") // can compile : func add(x, y string) is generated > > add(1, "abc") // two differents type : error > > GenericType will be like interface{} but instead of casting it'll > generate on the fly, at compile time the function with the type of each > functions call. > I believe it's too easy and i miss something already discussed... > > -- > wilk > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts%2bunsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/rsk0bb%24tg6%241%40ciao.gmane.io > > <https://groups.google.com/d/msgid/golang-nuts/rsk0bb%24tg6%241%40ciao.gmane.io>. > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/FE7904D7-05AF-4CA6-8ECD-E988F9125EA9%40ix.netcom.com.
