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.
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.
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.
> 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-hi... used to have a link but it's dead).
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.
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.
> 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<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.
> 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.
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.
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 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.
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.
> 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.
From what I have seen over the years, the "I don't want generics" crowd showed up just as often as the "Go is useless without generics" crowd. This time, though, only one of those groups can reasonably continue to comment.
You’re making it sound like these are the same group of people and they’re just really fickle, whiny and impossible to please. But my memory of these older go/generics threads were that commenters were split between “I love go, I wish it had generics” and “I love go, I don’t think it needs generics”. The former have no need to comment anymore, the latter will still want to express their feelings.
This is why you have to be a tough leader when you’re the designer of anything. But especially languages which naturally draw an endless barrage of comparisons and tribal opinions.
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.
Or good case study of squeaky wheels. I never wanted generics. I never thought to spam the development lists about how much I liked how things were going.
a couple high profile projects (k8s) needed generics, there are limited use cases outlined in the planning docs that detail the holes in the language they're filling, it wasn't just squeaky wheels.
Maybe you can get rid of some runtime.Object casting here and there (I suspect at the cost of major compilation time penalty) but pretty sure the codegen is here to stay
UNIX was re-written in a clunky unsafe systems programming language, by being free beer due to legal impositions on research work, its adoption settled the future of this language across the industry.
Yet even C supports lightweight generics, so they must be worth something.
The thing is, Google is paying most of the development costs for Go and Google controls Go too. It makes sense to adapt the language to their needs. They already do stuff like creating new network protocols because it will reduce their costs.
I've heard multiple times that Google Cloud has the best support for k8s, and that people moved to it because of that. Is that what you meant by making a market?
That’s because “HN threads” represents a lot of different people with different needs and opinions. It’s not a monolithic block at all, and people are more likely to react to complain.
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.
My guess would be it has biological/physiological reasons. Negative stimuli create a greater urge to act. Tabloids selling more newspapers with bad news than good ones, because the individuals that gave higher weight to birdsong than the signs of a predator approaching did not procreate, evolution at work.
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.
I am okay with generics as long as they are not affecting compile time. I love Go for blazing fast builds and testing and afraid generics will degrade it. Otherwise, generics are adding some cognitive complexity to code, but I don't have to use them and will just occasionaly have to figure them out in libraries.
Check ML languages with its multiple backends, Eiffel or Delphi/FreePascal.
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.
I don’t know, at this point my guess is that most people just don’t care, so those that can be bothered to comment are a bit fringe.
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.
Yes and no. I dropped go after a short but tumultous love/hate relation, but decided to take a fresh look if generics had a decent answer. There's a lot to like about go. So I'll look back soon.
My employer has not moved on and it’s steadily encroaching more even on strong Scala/Java teams, so I’m glad to see the worst impediments start getting fixed.
Go adds generics.
HN thread: I don't want this.
Good case study about the people drawn to comment on a topic.