Every HN thread about go: go is useless because it lacks generics.
Go adds generics.
HN thread: I don't want this.
Good case study about the people drawn to comment on a topic.
Go adds generics.
HN thread: I don't want this.
Good case study about the people drawn to comment on a topic.
When go didn't have generics, those in favor commented. Now that it will, those against are commenting.
It sounds funny at face value but I don't see the insight.
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.
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.
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.
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-hi... used to have a link but it's dead).
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 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
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.
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.
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.
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.
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/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.
The parsing rules for templates alone probably make a decent door stopper. They can also trivially kill compile times. The bloat from page long symbol names also isn't something to ignore, just std::map<std::string,std::string>::find() results in a decent chunk once the compiler is done expanding it.
> Java
That is a can of worms, haven't professionally worked with Java in some time, but from memory:
* Compile time only, reflection or serialization heavy code will get raw Object types, yay type safety.
* They do not support primitive types, resulting in object boxing and null-ability issues by default as well as third party copy paste libraries that provide collections specialized for primitives.
* You cannot create an object or array using a generic type as that is unknown at runtime, as result some methods require a concrete array as argument just so they can create their own array with the correct runtime type.
* It is fully backwards compatible, so nothing will tell you if you have a compiled library that uses raw types somewhere in your application dumping Integers into a List that should only contain Strings.
* Calling code has to verify object types using runtime casts, you may not want to pay the cost of that.
I could probably go on ...
> Python
Aren't those just hints that the interpreter completely ignores? I have a python 3 toy project that could have benefited from better type checking - the contents of its sqlite database are a mess.
It's cliche, but it's clear that generics like Result ( https://doc.rust-lang.org/std/result/ ) and 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.
In fact, so much research and Go generics are mostly similar to CLU.
ML and its derivatives, Haskell, Rust, Nim.
You see this a lot in web design, everyone thinks they’re an expert at what makes a good website - simply because they are a consumer of them. Even if they only have minimal experience building one IRL.
Yet even C supports lightweight generics, so they must be worth something.
You hit the nail on the head. This is broadly true across virtually everything--at least in most of Western culture (as this is the only one I'm most familiar with).
Anger seems to provoke a more actionable response whereas satisfaction does not (generally speaking). Is someone more apt to call a business over lousy service or great service? Why is it that giving a compliment to someone in customer service sometimes provokes a brief reaction of surprise? I try to do my part as a positive force when I can, but I usually fall short. Besides, is one happy person likely to make that much of a difference over the course of a day? Maybe, maybe not.
FWIW I actually like the idea of generics in Go and have a few use cases where they'd be exceptionally helpful in cutting down the amount of code I have floating around in some libraries. I just don't feel strongly enough about it to jump into a thread to rush to its defense.
It is possible to change though, patiently putting your own focus on positive things, which there are so many of. Takes work, but sooo worth it. Life is more fun that way too.
Go compile times, while great, weren't any novelty to old timers before the .com wave that brought scripting languages into the spotlight and Sun's gigantic Java push.
Thankfully the 20 years detour seems to be getting over.
Tooling is available, books are available, 30 years of libraries are around.
If with all of that you can't find a team, it certainly isn't because of tooling.
Go could easily fuck it up tho - that's fair.
When Go first came out, it seemed interesting, but when I checked it out it felt more like throwing out the baby with the bathwater than introducing anything of value. Not every idea since 1972 is bad. So I tried to force myself to use it for a project or two, got frustrated by exactly the things people were complaining about, and never looked at it again.
I haven’t seen any meaningful adoption, so my hypothesis is that by not having the features mainstream users want, Go missed its window of opportunity and the world moved on. It’s neat that they’re adding them now, but.. well.. let’s just say that I was an absolute die-hard Perl fan for a long time so I’m familiar with this pattern.
You must live in a different world. Go has been an immense success since its inception. Cloud, DevOps and SRE are nowadays unthinkable without it.
The only people who care about Go now are the ones who convinced themselves that casting from empty interfaces was okay.