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.
