4 ms·

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and b

> Go adds generics. HN thread: I don't want this If generics are a good idea for a language, then it's better to add them in version 0.01 of the language and build up from there with generics as an intrinsic part of the language and standard libraries. No, I don't want _tacked on_ generics. 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. Now, you can and should choose upfront if your language needs them, or to choose a different route. There's no need to repeat that history. YMMV, people have different preferences in programming languages, I have always preferred strongly typed languages. Generics suit me, but pick your lane. And if you're at version 0.01 of a language, while you're at it, look at being immutable by default, not null by default. Those things can be opt-in for when you need them.

R0b0t1 5y ago
These don't seem tacked on. They spent so long on them specifically so they don't seem tacked on. The issue with Go is if you're not shuffling around binary data it has horrible developer ergonomics. Network data is usually untyped, but if you start needing to care about what is in that data and need typed datastructures built around it you stop having fun quick. Same issue with C, really.
- pjmlp 5y ago
  There is lots of fun to had when debugging mismatched dynamic structures sent around the network. It is no wonder that any new format introduced with hype to release developers from type safety boilerplate chains, a few years in production ends up getting its own flavour of schema definition.
iainmerrick 5y ago
No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.
- spion 5y ago
  The libraries are better because they're designed with generics in mind. Most C# libraries in use today were built after generics were added, and there never was a large ecosystem already developed at the time Java has had lots of libraries thrown away due to initial lack of generics and a lot of painful migration e.g. https://docs.oracle.com/javase/tutorial/extra/generics/convert.html https://docs.oracle.com/javase/tutorial/extra/generics/conve... A good parallel would be async-await in JS and nodejs. The entire core library and a huge percentage of the ecosystem ended up being really awkward to use after the introduction of async await. The whole ecosystem is now one big giant mess.
  - spion 5y ago
    The ecocystem did start moving forward, but it will take a long time for the older pre async-await libraries to fade away and there will always be some strangeness resulting from the fact a lot of the libraries you find use a totally different API convention that you have to call via promisifying tools.
- SideburnsOfDoom 5y ago
  > What languages in your opinion have good, non-tacked-on generics? It's cliche, but it's clear that generics like Result ( https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/ ) and Option ( https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/ ) are fundamental to Rust's design from the start. > some pretty successful languages that gained generics after maturity I'm very familiar with C#, of course it is a "pretty successful language", no kidding. I did not say otherwise, I said that there are "compromises" associated with adding generics in V2. And there are: e.g. starting with collection types, interfaces and base types in pairs, such as List<T> and List, IList<T> and IList, IEnumerable<T> and IEnumerable, etc ad nauseam. Then Delegates that precede Func<T> and Action<T>. I suggest that you reread my comment above; the point is not just that adding generics later causes complication (historic record is clear that it does). The point is that generics were _not_ proven in mainstream OO programming when c# 1.0 was released in 2002, but this has changed; now they are. Designs done in the last few years can avoid this complication: Ether your language wants them from the start, or it intends other ways to deal with the same kinds of problems.
masklinn 5y ago
> 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 understanding what they have no experience with. And work on .net generics had been going on since 1998, and by the release of 1.0, generics were going to land in 2.0. It simply wasn't done at that point: "Design and Implementation of Generics for the .NET Common Language Runtime" dates back to early 2001, but by late 2001 the spec was still incomplete and debated (https://docs.microsoft.com/en-gb/archive/blogs/dsyme/some-history-2001-gc-research-project-draft-from-the-msr-cambridge-team https://docs.microsoft.com/en-gb/archive/blogs/dsyme/some-hi... used to have a link but it's dead).
- SideburnsOfDoom 5y ago
  > 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-generics-history-some-photos-from-feb-1999 https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge... My argument is that this particular question has, since then, been settled in favour of generics, outside of academia, and in mainstream languages such as c#. Generics are now "established and proven" in ways that they were not then. Hindsight: https://twitter.com/matthewwarren/status/920667986108846080 https://twitter.com/matthewwarren/status/920667986108846080 C# is IMHO mainstream, deliberately so. Features in it typically come from other languages. It is a "populariser" of promising programming language ideas for mainstream productivity, not a testbed. > Doesn't mean the average developer understood the point at the time as a junior dev, I got the point inside a minute: I was already in the habit of when declaring Customer class adding a strongly typed 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<Customer> etc was such a clear win.

R0b0t1 5y ago

These don't seem tacked on. They spent so long on them specifically so they don't seem tacked on. The issue with Go is if you're not shuffling around binary data it has horrible developer ergonomics. Network data is usually untyped, but if you start needing to care about what is in that data and need typed datastructures built around it you stop having fun quick. Same issue with C, really.

pjmlp 5y ago
There is lots of fun to had when debugging mismatched dynamic structures sent around the network. It is no wonder that any new format introduced with hype to release developers from type safety boilerplate chains, a few years in production ends up getting its own flavour of schema definition.

iainmerrick 5y ago

No, I don't want _tacked on_ generics. What languages in your opinion have good, non-tacked-on generics? Are they generally better than other languages? Here are some pretty successful languages that gained generics after maturity: C++, Java, C#, TypeScript (based on JavaScript), Objective-C, even Python.

spion 5y ago
The libraries are better because they're designed with generics in mind. Most C# libraries in use today were built after generics were added, and there never was a large ecosystem already developed at the time Java has had lots of libraries thrown away due to initial lack of generics and a lot of painful migration e.g. https://docs.oracle.com/javase/tutorial/extra/generics/convert.html https://docs.oracle.com/javase/tutorial/extra/generics/conve... A good parallel would be async-await in JS and nodejs. The entire core library and a huge percentage of the ecosystem ended up being really awkward to use after the introduction of async await. The whole ecosystem is now one big giant mess.
- spion 5y ago
  The ecocystem did start moving forward, but it will take a long time for the older pre async-await libraries to fade away and there will always be some strangeness resulting from the fact a lot of the libraries you find use a totally different API convention that you have to call via promisifying tools.
SideburnsOfDoom 5y ago
> What languages in your opinion have good, non-tacked-on generics? It's cliche, but it's clear that generics like Result ( https://doc.rust-lang.org/std/result/ https://doc.rust-lang.org/std/result/ ) and Option ( https://doc.rust-lang.org/std/option/ https://doc.rust-lang.org/std/option/ ) are fundamental to Rust's design from the start. > some pretty successful languages that gained generics after maturity I'm very familiar with C#, of course it is a "pretty successful language", no kidding. I did not say otherwise, I said that there are "compromises" associated with adding generics in V2. And there are: e.g. starting with collection types, interfaces and base types in pairs, such as List<T> and List, IList<T> and IList, IEnumerable<T> and IEnumerable, etc ad nauseam. Then Delegates that precede Func<T> and Action<T>. I suggest that you reread my comment above; the point is not just that adding generics later causes complication (historic record is clear that it does). The point is that generics were _not_ proven in mainstream OO programming when c# 1.0 was released in 2002, but this has changed; now they are. Designs done in the last few years can avoid this complication: Ether your language wants them from the start, or it intends other ways to deal with the same kinds of problems.

masklinn 5y ago

> 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 understanding what they have no experience with. And work on .net generics had been going on since 1998, and by the release of 1.0, generics were going to land in 2.0. It simply wasn't done at that point: "Design and Implementation of Generics for the .NET Common Language Runtime" dates back to early 2001, but by late 2001 the spec was still incomplete and debated (https://docs.microsoft.com/en-gb/archive/blogs/dsyme/some-history-2001-gc-research-project-draft-from-the-msr-cambridge-team https://docs.microsoft.com/en-gb/archive/blogs/dsyme/some-hi... used to have a link but it's dead).

SideburnsOfDoom 5y ago
> 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-generics-history-some-photos-from-feb-1999 https://docs.microsoft.com/en-gb/archive/blogs/dsyme/netc-ge... My argument is that this particular question has, since then, been settled in favour of generics, outside of academia, and in mainstream languages such as c#. Generics are now "established and proven" in ways that they were not then. Hindsight: https://twitter.com/matthewwarren/status/920667986108846080 https://twitter.com/matthewwarren/status/920667986108846080 C# is IMHO mainstream, deliberately so. Features in it typically come from other languages. It is a "populariser" of promising programming language ideas for mainstream productivity, not a testbed. > Doesn't mean the average developer understood the point at the time as a junior dev, I got the point inside a minute: I was already in the habit of when declaring Customer class adding a strongly typed 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<Customer> etc was such a clear win.