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.
