On Fri, Jan 1, 2021 at 2:14 PM Space A. <reexist...@gmail.com> wrote:
> So magic here is being able to say "stop".
>
The real magic is being able to discern what the things are that can be
useful enough to justify their cost, not just to stop. Stopping is trivial
- you could just set the Go repository to archive mode and it will never
change again.
This thread, however, asserted that there are *no* real-world use-cases for
generics. That's clearly wrong. The next thread might try to instead make
the argument that there are not *enough* real-world use-cases. As I said, I
can't really argue about that, I'm lacking quantitative data. But I'm
looking forward to someone providing that.
Code in these bloated ecosystems over time becomes unreadable so that in
> many many cases it's easier to rewrite even very complex applications with
> thousands of man hours spent on, just from the scratch, than to try to
> read, understand and improve it evolutionarily. That's the reality. On the
> other hand Go has never been posed to benefit everyone. Covering each and
> every use case is not in its values. "Less is exponentially more".
>
> пт, 1 янв. 2021 г. в 13:24, 'Axel Wagner' via golang-nuts <
> golang-nuts@googlegroups.com>:
>
>> 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 a topic in the
>> Google Groups "golang-nuts" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/golang-nuts/bj6kMQBTqUY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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
>> <https://groups.google.com/d/msgid/golang-nuts/CAEkBMfGgD6C5T5qh747pEwzy1mjmGToYZj2jEE8koMckPk0vNA%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/CAEkBMfE4Fw6Ahk%3DkkU-jF8bRhDu7V3FHjHb2Try4KtOGcj-x0g%40mail.gmail.com.
