Hacker News new | ask | show | jobs
by Twey 23 days ago
Ironically Rust (hence the name) was originally billed as the language that did nothing novel at all, but just productized a bunch of concepts that were already well understood in the PL field :)

I think that a programming language — much less a programming language _ecosystem_ — is such a large space of decisions that statistically you're inevitably going to let a few of them slip. And even (as in Rust's case, initially) if you don't aim to do anything new, the combination of the interactions between features and the ways people want to use your language culturally can land you places you never anticipated when doing the initial language design. I don't think anybody in the early years of Rust could have anticipated how async would look today, for example, and IIRC Graydon Hoare still doesn't like where it ended up.

Then, there's the old software adage that the right decision for one level of adoption doesn't necessarily translate to another level. Because it's so hard to predict the impact of early decisions, early versions of programming languages are basically prototypes: your aim is to get out enough of the core differentiators of the language that people can start playing with it and _imagining_ what it will be like to work with the final thing. Part of that involves making the barrier to entry as small as possible (e.g. bundling a full build system into the precompiled compiler executable) but it also implies that you don't want to spend more time than necessary on things that work the same as other languages. If you can see the ‘obvious omission’ in the language then that means you can already imagine how it will work when that thing is implemented! As an implementor you can always flesh it out as you approach 1.0, or, if the right thing to do is so obvious and you have an enthusiastic open-source community, you can just wait for the community to build it for you.

Go's generics case is a bit different, I think. I don't claim to be an expert here (I haven't followed Go development much) but as far as I understand it the omission of generics from Go was a deliberate ideological choice: they hoped to get by with the absolute minimum of generic functionality, and the experiment was how little they could get away with and still have it adopted. (Unfortunately, I think the experiments Go was trying to run were stymied by Google and Kubernetes throwing their weight behind it, which led to a pattern of adoption that had little to do with the language design itself: we may never know what would have become of it if it had been left to stand on its own.)