Hacker News Reader

Comment by DANK_YACHT | Hacker News Reader

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.

View on HN

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).

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.

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.

Reply on news.ycombinator.com