Not providing generics was already a mistake > 25 years ago. Coming from C++ with its templates, I was astonished when Java came out without generics in 1995. It was dumbfounding, because parametric polymorphism was so obviously an essential feature for static typing (otherwise one has to resort to runtime type-casts all the time, relinquishing compile-time type safety), and Java was positioned as an alternative to C++. It took ten years for generics to finally be added to Java. (And another four years later Go came out, again without generics…) I later read an article or interview that one of the original Java implementers actually pushed for generics, but it was too much work/complexity and they wanted to get the language out.
Don't forget C# 1.0 which also shipped without generics. The people designing these langs were not inexperienced, far from it. Yet the mistake keeps being repeated every decade. I feel like the industry would be a lot further along if we paid more attention to these lessons from the past.
> Don't forget C# 1.0 which also shipped without generics.
That's true, but work to support them was already underway and when C# 2.0 shipped with generics, the bytecode and VM already supported it. That's why C# generics support specialization for non-reference types. Don Syme and company knew they wanted generics, but it takes time to design a system like that, so they shipped C# before that work was complete.
Anders Hejlsberg, who designed C#, had previously designed Delphi, which has some support for generics (and I believe it had them before he left for Microsoft). I think the case may be that they're not making the same mistakes, but that they're just trying to ship software. Maybe though you would reply that generics are part of the minimum viable product of a programming language and it shouldn't ship without them. I can't say I disagree.
When C# first came out it was in competition with Java, which at that point didn’t have generics yet either. That was probably a relevant consideration for shipping the first version without generics.
It seems that these languages without genetics keep getting popular. Perhaps they get popular in part because they don’t support generics at first, and so seem to be simpler?
It seems to be inevitable. Few languages can remain simple forever because they run into the realities of large scale systems development. If they remain simple, they either force the programs to become more complex or effectively constrain the complexity of the systems that are developed.
The question is for how long, if they hadn’t added generics at some point. There’s certainly a lot of pressure e.g. for Go to have added generics, and Rust and Swift likely wouldn’t have been as successful as they are if they didn’t include generics.
This is anecdotal, but Java 5 adding generics was crucial for me to staying with a Java job. Without generics, working with generic algorithms and facilities was just miserable, and there was great temptation to use code generators based on some sort of templated Java as a workaround.
Perhaps it's necessary to add generics to keep users, but my takeaway is this: if you have innovative language features, then you don't need generics to attract a passionate set of early adopters. If you don't have innovative language features, people won't use your language regardless of generics support.
Yeah, as I already said I don’t think Rust’s borrowing semantics would have been quite enough for it to be as successful without generics, and Swift as a modern replacement for Objectice-C also wouldn’t have been quite as convincing without generics support (which was a pain point in Objective-C).
I can’t exclude the possibility of new innovative language features outweighing the penalty of not having generics (like Go’s concurrency support did for a while) even today, but I believe it’s becoming increasingly unlikely (for statically typed languages, obviously).
You can't do Rust without generics at all, they're utterly fundamental. Take the for loop. Rust's for loop is literally sugar for the infinite loop over an Iterator (a generic type) which emits an Option generic, with a break for None.
Rust calls such types "langitems" and they're required for the core Rust language. An allocator (for heap memory) isn't mandatory, fancy file I/O and networking aren't mandatory... But the langitems, and thus generic types, are mandatory.
Rust could conceivably have worked similar to C, where you have to cast void* to the correct type. You could still have borrowing annotations on such generic pointers, similar to how C(++) has const. Having borrowing semantics doesn’t necessarily imply a general-purpose generics feature. Stuff like iterators and option types would obviously be different then.
You could build a completely different language with some of Rust's features, if you go back a few years before Rust 1.0 there are lots of possibilities, but what I was getting at is that Rust itself is much more tightly wedded to the generics than many of the languages people associate with generics, a "Rust without generics" isn't Rust at all.
Even in C++ the generics are a later addition, Stroustrup's early 1980s language doesn't have generic types, templates were a proposal added to what would become the C++ 98 standard and the Standard Template Library presents generic types for containers in C++ years after the C++ language was first popularized.
I don’t think we really disagree. I was originally reaponding to the claim by DANK_YACHT stating that a (statically typed) language can be successful without having generics as long as it has other sufficiently innovative features. As a “counterexample” I hypothesized a version of Rust without generics but with the borrow checker (arguably the innovative feature most decisive for Rust’s success) and argued that I would doubt that this version would have been very successful, exactly because its lack of generics (which I believe aligns with what you are arguing). I’m not sure if you’re arguing that this hypothetical scenario isn’t a valid counterargument to the original claim I was responding to.
Yes, technically you can do that but it makes no sense from a design point of view to have a language that cares so much about safety it adds a borrowing system but then says "fuck it" to type safety.
You have to have type safety to have memory safety and that was the whole point of Rust.
Rust's value proposition is being a modern language capable of low-level programming. Surely, the low-level part is essential, and the borrowing semantics brings it, but it wouldn't have much value if it hadn't modern features.
Just starting with C and adding a borrow checker would have had some value (and there are some linters that doggedly try to do this). I agree I’d much rather have Rust, though.
Both Java and Go are developed by mega corporations though. Hard to disentangle their successes from that. It's not hard to be successful (when success is measured as adoption) when you literally can't fail due to the giant pile and of never-ending cash and army of developers fueling your growth. Even if your language is terrible people will adopt it, if for no other reason than Google or Oracle are behind the project.
If Oracle were to disappear tomorrow I imagine Java would persist for quite a while as it's so embedded by now. It's the introductory language in schools across the US, so it's not going anywhere for now.
Go on the other hand I don't think would last very long (maybe a decade?) if Google decided to divorce themselves of the language, as it doesn't have the installed userbase of Java, but that's just my opinion. Who knows what would happen.
Yes, considering the impact to the standard library, but generics are very hard to do well. The C++ language committee is still 30 years later dealing with the fallout from the underspecified initial template implementation. Java's implementation seems to get mixed reviews.
Yes, it’s not easy, but not designing them in from the beginning only imposes further restrictions on the eventual design. And the lesson has been that generics will have to be designed in at some point for the language to stay relevant. Nowadays we at least have more existing languages — and advances in type theory — to learn from.
I would say that C++ templates have been extremely successful. The reason that the committee keeps tinkering with them is that users keep asking for even more features (very very few languages have all comparable features, so it is certainly not a matter of catching up).
It might have been understandable in 1995, because by then C++ already was mind-boggingly complex for a lot of applications, and it might not have been entirely clear which of it's features were the worst in that regard. But I was only starting programming with QBasic in 1995, so this is just a thought, not a fact.
Ada generics are easy to understand and were at least publicly known for ~12 years in 1995 (going by the publication date of the first Ada standard, older if we go to drafts and discussions prior to that standard's release). Generics aren't hard to use, and they aren't novel. That there's any debate nearly 40 years after at least one major procedural language introduced them is mind-boggling to me.
People really ought to look into Ada more. The language has a pretty neat type system (ranges are neat!), and it even has proper language constructs to do concurrent programming in it (had it for quite a while!). FWIW, search for "generic" here: https://en.wikibooks.org/wiki/Ada_Style_Guide/Concurrency
