100% - I use generics all the time in Java - but do these cases warrant the
inclusion of generics in Go? There is more to that than use cases - which is
why this thread is a bit misdirected. Go is strange in that way - it has a few
built-in type safe containers that are very versatile. If these were more
versatile then the number of generics use cases not covered really drops.
To Ian’s point, what if I could declare a map that had the semantics of a
concurrent hash map without adding generics? I think something like this gives
Go a leg up, rather than just making it “closer to Java” as some complain. Go’s
“other containers (i.e. sync.Map)” are very similar to Java pre-generics - and
better software engineers wrote wrappers then instead of dealing with
interface{}/Object everywhere.
At the end of the day, I think the debate should be over and Go should add them
in the next release. The sooner the better. Once it becomes part of the
language people will learn it, use it, or not. Since it is backwards compatible
I wouldn’t even wait for Go2. Sometimes the best thing to do is just move on
and deal.
> On Jan 1, 2021, at 4:23 AM, 'Axel Wagner' via golang-nuts
> <golang-nuts@googlegroups.com> wrote:
>
> On Fri, Jan 1, 2021 at 8:15 AM Robert Engels <reng...@ix.netcom.com
> <mailto: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 <mailto:golang-nuts@googlegroups.com>> wrote:
>>
>>
>> On Thu, Dec 31, 2020 at 6:51 PM robert engels <reng...@ix.netcom.com
>> <mailto: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 <mailto:golang-nuts@googlegroups.com>> wrote:
>>>
>>> On Thu, Dec 31, 2020 at 5:46 PM robert engels <reng...@ix.netcom.com
>>> <mailto: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 <mailto:golang-nuts@googlegroups.com>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On Thu, Dec 31, 2020 at 8:59 AM wilk <w...@flibuste.net
>>>> <mailto: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
>>>> <mailto:golang-nuts%2bunsubscr...@googlegroups.com>.
>>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/golang-nuts/rsk0bb%24tg6%241%40ciao.gmane.io
>>>>
>>>> <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
>>>> <mailto: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
>>> <mailto: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
>> <mailto: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
> <mailto: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/C8CF763B-5277-4638-B4C2-6FA5A1C22452%40ix.netcom.com.
