Go has been in existence for 10+ years and has fairly wide adoption in some areas - so it is not hard to make the case that generics are “not an important thing” - depends on what you are trying to do with it and what your perspective on “the right way” is.
> On Dec 31, 2020, at 10:54 AM, 'Axel Wagner' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > On Thu, Dec 31, 2020 at 5:46 PM robert engels <reng...@ix.netcom.com > <mailto:reng...@ix.netcom.com>> wrote: > 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. > > Just to illustrate that the plural of "anecdote" isn't "data": I was > originally very vehemently opposed to generics in Go, but after using Go for > a bunch of years, I've been missing them often enough that I think they > provide a net-benefit (despite my criticism of this specific design). > > Generics just isn't a "if you use Go long enough you learn they are not > important" thing. > > >> On Dec 31, 2020, at 4:25 AM, 'Axel Wagner' via golang-nuts >> <golang-nuts@googlegroups.com <mailto: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 > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFp0ozY5BAUudH-upa7neRjdtUQ%2Bk-o-%2BGox0q0%2BhJwEQ%40mail.gmail.com > > <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFp0ozY5BAUudH-upa7neRjdtUQ%2Bk-o-%2BGox0q0%2BhJwEQ%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/928F4805-B2B9-46CE-AEC9-DAEB260C3889%40ix.netcom.com.
