On Fri, Jan 1, 2021 at 8:15 AM Robert Engels <reng...@ix.netcom.com> wrote:
> 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).
>
I take it. I don't have data to make quantitative statements, so I can't
argue whether or not generics are useful in 5%, or 25% or 90%.
But at least you and me seem to agree that there *are* real life use-cases
for generics (which is what this thread tried to call into question).
>
> 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
>>> <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.
>>>> 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
>>> <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/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/CAEkBMfF1g1J9gD%2Bz3A%2Bsw-Qf5gkT81uK%2BMiXiAvGZyo_zhLjYA%40mail.gmail.com
> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfF1g1J9gD%2Bz3A%2Bsw-Qf5gkT81uK%2BMiXiAvGZyo_zhLjYA%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/CAEkBMfGgD6C5T5qh747pEwzy1mjmGToYZj2jEE8koMckPk0vNA%40mail.gmail.com.
