Of course. But you don’t design a language (or any other product) for the 5% -
you design it for the 95 (80?} percent - if you want you have customers/users
and stay relevant (in business).
> On Dec 31, 2020, at 8:39 PM, 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
>
>
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels <reng...@ix.netcom.com> wrote:
>
>> 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”
>
> This has been brought up in That Other Thread, so let me copy what I said
> there (you didn't respond to that particular point, even though you replied
> to the E-Mail, so I assume you've already read it):
>
> Of course, this doesn't answer how we'd have managed *with* them.
>
> We did manage for decades without general purpose CPUs. We did manage for
> several decades without functions, coroutines or hashtables. We did manage
> for decades without portable programming languages or multi-tasking operating
> systems. We managed for many decades without the internet or the world wide
> web.
>
> In hindsight, though, "we managed so long without them" doesn't appear to be
> a very convincing argument to not have them today.
>
>> - depends on what you are trying to do with it and what your perspective on
>> “the right way” is.
>
> This seems to indicate some progress in mutual understanding - by saying that
> it depends on what you do with the language, you seem to imply that you
> understand that other people's use-case might benefit from generics. Am I
> reading this correctly?
>
>>
>>
>>> 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>
>>>> 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> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Thu, Dec 31, 2020 at 8:59 AM wilk <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 (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 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.
>>>>>> To view this discussion on the web visit
>>>>>> 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.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGDOqWgEE2a_B9%2BqXftPc6ebBPcs_DcpsrqOvR%2BpCZ9SQ%40mail.gmail.com.
>>>>
>>>
>>>
>>> --
>>> 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/CAEkBMfFp0ozY5BAUudH-upa7neRjdtUQ%2Bk-o-%2BGox0q0%2BhJwEQ%40mail.gmail.com.
>>
>
> --
> 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/CAEkBMfF1g1J9gD%2Bz3A%2Bsw-Qf5gkT81uK%2BMiXiAvGZyo_zhLjYA%40mail.gmail.com.
--
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/12D1F91E-02FC-4580-9D68-510E77AD7CD1%40ix.netcom.com.
