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.
