I share some of the OP's concerns. At the moment, I am horrified at the
syntax of some of the more advanced generics examples in the proposals,
particularly when you throw contracts, methods and stuffs into the mix.
There are just way too many brackets to my liking. In a typical IDEs, they
use different colors, line breaks, and all sorts of guides to indicate
which bracket belongs to which, because *brackets hinder readability*,
especially when you have too many of them in a single line. Stop throwing
more brackets.
I have no problem with the concept of generics itself, but I don't see a
clean way to implement a full-blown generics into Go syntax-wise.
I prefer features to simplify writing generators. Generators not only solve
generics problem, it also solves the need for macros, etc.
On Friday, January 1, 2021 at 8:37:59 PM UTC+7 Space A. wrote:
> > 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.
> One of the key Go values is simplicity. Keeping langage spec relatively
> small and code clean and readable. So if you justify from that angle you
> should say stop to any form of generic programming.
>
> > 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.
>
> There is no real world problem *in this thread*. That's true. However,
> there are some in the universe, that's for sure. Even if there weren't you
> could have always invented one. =) Problem is not in proving that, but that
> generics will be used mostly to fight with ephemeral "interfaces are bad",
> "we have a type safety problem" (what?), reducing amount of "repetitive"
> code, abandoning "clear is better than clever" principle, and for infinite
> micro optimizations for every single nanosecond.
>
>
> пт, 1 янв. 2021 г. в 16:20, Axel Wagner <axel.wa...@googlemail.com>:
>
>> On Fri, Jan 1, 2021 at 2:14 PM Space A. <reexi...@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 <
>>> golan...@googlegroups.com>:
>>>
>>>> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels <ren...@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 <
>>>>> golan...@googlegroups.com> wrote:
>>>>>
>>>>>
>>>>> On Thu, Dec 31, 2020 at 6:51 PM robert engels <ren...@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 <
>>>>>> golan...@googlegroups.com> wrote:
>>>>>>
>>>>>> On Thu, Dec 31, 2020 at 5:46 PM robert engels <ren...@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 <
>>>>>>> golan...@googlegroups.com> wrote:
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On Thu, Dec 31, 2020 at 8:59 AM wilk <wi...@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...@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...@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...@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...@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...@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/f1edc424-1e68-4440-b174-f8d98d1b7fe9n%40googlegroups.com.
