Generics enabled by default in Go tip • Hacker News Board

Re: Generics enabled by default in Go tip

#281

Post by masklinn » Sat, Aug 21, 2021, 2:59 PM UTC

SideburnsOfDoom wrote: post #278

masklinn wrote: post #274

Earlier quoted context omitted.

> Generics are not in 2021 a "bleeding edge" feature, that _might_ be useful later. They are established and proven in ways that they were not when Java v1 or C# v1 shipped - both added generics in later releases, with associated compromises. Generics were hardly bleeding edge by 2002. Doesn't mean the average developer understood the point, but that's hardly a benchmark, and really most people have a hard time under…

> Generics were hardly bleeding edge by 2002. yes and no. It's clear from the history at the time that they were not a proven, obvious win. > Generics for .NET and C# in their current form almost didn't happen > being told by product team members that "generics is for academics only" https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge... My argument is that this particular question has, since then, been sett…

> I was already in the habit of when declaring Customer class adding a strongly CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List etc was such a clear win.

TBF a common rejoinder back then was that this specific pattern made the opportunity cost of domain-specific operations very low, so you could better those collection interfaces to the specific needs.

Of course 95% of the time they extended the corresponding class or implemented the interface so that wasn't actually true.

Re: Generics enabled by default in Go tip

#282

Post by masklinn » Sat, Aug 21, 2021, 3:01 PM UTC

4ad wrote: post #263

brundolf wrote: post #43

I've never used Go, and from the outside I take a lot of issues with its design choices. But even without having used it I always thought the lack of generics was very interesting and I could see how it was desirable. It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to p…

> It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to. Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called ge…

> Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called generics).

The biggest reason was probably that it had bespoke generics for a bunch of core collections, significantly mitigating the need for userland generics.

Without the builtin generic slice, map, and channel, the issue would have been significantly less tenable on both efficiency and convenience fronts.

It's not like "we have interfaces and we still need generics" is a new thing.

Re: Generics enabled by default in Go tip

#283

Post by 4ad » Sat, Aug 21, 2021, 3:09 PM UTC

masklinn wrote: post #280

4ad wrote: post #261

Earlier quoted context omitted.

True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. In fact, once OCaml gets implicit modules, this won't be true anymore of OCaml either.

> True of OCaml and Rust (and many others), but Haskell certainly has overloaded functions through type classes. That's no more overloading than Rust has through traits.

It absolutely is, because class methods in Haskell are top level declarations. Not only this is not true in Rust, but it doesn't even matter as Rust doesn't have polymorphic values, only polymorphic types and functions.

In Rust, unlike in Haskell or ML type inference stops at function boundary.

Re: Generics enabled by default in Go tip

#284

Post by 4ad » Sat, Aug 21, 2021, 3:22 PM UTC

masklinn wrote: post #282

4ad wrote: post #263

Earlier quoted context omitted.

> It's fascinating to me that Go has gotten as far as it has without them (proving that it's possible to), and the mindset shift people describe having around them seems like a really important thing to pay attention to. Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called ge…

> Yes, the mindset of the people was certainly a key part of this, but another key part is that Go has interfaces, which are existential types, which are dual to universal types (colloquially called generics). The biggest reason was probably that it had bespoke generics for a bunch of core collections, significantly mitigating the need for userland generics. Without the builtin generic slice, map, and channel, the is…

This argument is often repeated but doesn't make any sense.

The value of generics is quantifications over types. In particular univeral quantification. "Generic" slices don't give you that, because the values are "generic", but there are no non-static type constructors. Go slices are "generic" only in the same sense than arrays in C are generic, or (if we go to the degenerate case) that a variable is "generic" because you can declare it with any type. I'm sorry, what?

Go has existential quantification, something which C lacks. Go is very unusual that it started with existential types. Languages based on System Fω have universal quantification as a native operation and implement existential types as higher rank universals. The fact that Go had existentials from the beggining is not some technical nitpick, it is what gives it type-level expressive power over languages like C. Ignoring this in arguments about generics is missing the point completely.

Re: Generics enabled by default in Go tip

#285

Post by SideburnsOfDoom » Sat, Aug 21, 2021, 3:33 PM UTC

masklinn wrote: post #281

SideburnsOfDoom wrote: post #278

Earlier quoted context omitted.

> Generics were hardly bleeding edge by 2002. yes and no. It's clear from the history at the time that they were not a proven, obvious win. > Generics for .NET and C# in their current form almost didn't happen > being told by product team members that "generics is for academics only" https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge... My argument is that this particular question has, since then, been sett…

> I was already in the habit of when declaring Customer class adding a strongly CustomerList class, for their address, an Addess class, followed by the AddressList, and Orders needs OrderList and OrderItemList. Reducing this repetitive "plug in the type" code to List etc was such a clear win. TBF a common rejoinder back then was that this specific pattern made the opportunity cost of domain-specific operations very l…

> this specific pattern made the opportunity cost of domain-specific operations very low,

Yes, I did miss the "added value" operations declared on that list class, e.g. AddressList typically contained a "GetCustomerPrimaryAddress", etc.

But there were ways to bring that back, by subclassing or (later) extension method on that list. Indeed, 95% of the code was tedious forwarding to the non-generic non-typesafe "list of objects".

Around the same time the dominant pattern of saving or loading data to a data store moved from "active record" where these methods were common, to "repository and DTO" where they were not. Might be co-incidence.

Re: Generics enabled by default in Go tip

#286

Post by c-cube » Sat, Aug 21, 2021, 3:34 PM UTC

tephra wrote: post #166

adamlett wrote: post #162

Earlier quoted context omitted.

C

C11 introduced type generic expressions.

Not in the commonly understood sense of "generics", no. You get to switch on a type, but you don't have generic functions or types. A reusable, type-safe Vec or HashMap are still not possible in C...

Re: Generics enabled by default in Go tip

#287

Post by c-cube » Sat, Aug 21, 2021, 3:37 PM UTC

jshen wrote: post #95

rustc wrote: post #86

Earlier quoted context omitted.

Are generics really considered as "esoteric comp sci topics"?

If you want coding to be accessible to people without comp sci degrees, and those who are NOT employed as full time developers.

If people can understand functions, they can understand generics. Nothing more complicated, generics are just functions on a few type arguments.

Re: Generics enabled by default in Go tip

#288

Post by Someone » Sat, Aug 21, 2021, 3:38 PM UTC

papito wrote: post #267

_ph_ wrote: post #250

I like Go very much, a huge role plays its simplicity. In my career, I have been much more often bitten by having to deal with the complexity of a language then by not being able to do things, because a language feature is missing. That is, why I like Go so much. It strikes a great balance between important high-level features (GC, first class functions and closures) and still being a simple language (like Scheme is,…

I roll my eyes when someone claims "I learned Go over the weekend". It's one thing to learn basic syntax, and completely another to learn the customs of your new environment so most can understand what you are doing. Go is one of the hardest languages to learn. First of all, some concepts in it are very different from "mainstream" languages, and it takes a while to get used to them. Simple things that exist in almost…

IMO, “learning the language” and “getting used to it” are different things.

The first is a purely theoretical exercise, the second a applied one that involves not only the language but also its ecosystem (implementation(s), library of functions and tooling)

Re: Generics enabled by default in Go tip

#289

Post by 4ad » Sat, Aug 21, 2021, 3:53 PM UTC

masklinn wrote: post #279

4ad wrote: post #259

Earlier quoted context omitted.

Because it can only be a type parameter. There is no specialization. (TBH I think that's a mistake because if prevents a solution to the Expression Problem.)

I don't think that's an issue, specialisation is a real edge case (e.g. Rust still doesn't have userland specialisation despite having always had generics) and it's easy to make mistakes with it (e.g. C++'s `vector ` though it's probably less of an issue if you can only specialise functions). That methods can't be parametric is still annoying though because it means utility methods can't have generic parameters unrel…

Adding it later is not impossible, but unfortunately is not that easy either. Ignoring the very high bar for changing Go in general, doing it this way has implementation consequences that would have to be undone. Also the spec change is not just a matter of adding more stuff, but it requires reformalization of the existing semantics because interfaces are already rank-2 types, you just can't see it yet. This feature interacts with interfaces.

It's very unfortunate thay didn't do this from the start. The original paper that introduced Go generics had this and used to to solve the Expression Problem.

Re: Generics enabled by default in Go tip

#290

Post by silisili » Sat, Aug 21, 2021, 4:04 PM UTC

rustc wrote: post #179

silisili wrote: post #145

Earlier quoted context omitted.

I don't mean to be negative only, and appreciate your reply. But I know what happens in real codebases. Before long, scammy tutorials pop up showing Go as an essentially dynamic language, and that's what bootcampers write. As of today, they are forced to write simple, boring code. I never mind a carefully added thing, for carefully thought of situations, as this probably was. The problem is that I see the abuse from…

> Before long, scammy tutorials pop up showing Go as an essentially dynamic language Sorry are you saying adding generics to Go makes Go closer to dynamic languages? Shouldn't that be the opposite? > I knew a person who insisted on a lot of things when working in a Go code base...one of which was mixed typed tuples. It was ugly, awful code of interfaces all the way down. It's ugly and Go let you know that. A voice of…

So, mixed typed tuples was the idea, but Go doesn't support either of those things, so it ended up as a [][10]interface{} or some such. So for each item in the slice, type assert all 10 things inside the subarray. Luckily the comments had a key of expected types of each.