but what I can say is, I personally sat down one evening and said "I think Rust can be the next great systems programming language" and then dedicated the next ~10 years of my life to making that happen
Oh by the way I was so swamped with replies that I actually didn’t say what I wanted to hear: one of those things I recognized needing to be done was marketing. And so I set out to do that work. I don’t think enough languages have folks dedicated to doing that. It helps.
I made sure the Twitter was engaged, I was present on hacker news and Reddit, in the early days I managed to submit every blog post about rust everywhere, I wrote posts of my own and encouraged others to.
* rust for rubyists, ~50 pages
* TRPL first edition, ~175 pages
* TRPL second edition which confusingly is the first edition of the published book, with Carol’s help of course, ~540 pages
I like this! My version of this is that most successful languages have to be no more than "20%" away from convention. Less than 20% and it's not worth it; more than 20% and it's too strange. (This is a sort-of restatement of the Blub paradox.) Rust may have gotten away with ~40% because of the need.
The "endless theorizing on the next thing" IS what gave rise to the "weird / academic" concepts that Rust borrowed from. Without that "endless theorizing", there would have been no need to invent those ideas, and we'd still be living in C-land.
At the point where these things rolled into Rust, they were already old concepts, and yet they'd stayed in academic realms. Rust took the at-the-time stable concepts and leveraged them right then, versus letting them percolate more.
My point is: when Rust leveraged this stuff, a lot it was ready to go, often proven, but not in the mainstream. Seen as weird / academic.
Theorizing on the next thing is good, but not instead of actually applying the backlog you already have. That's when it becomes "endless", which can be bad.
one of my favorite examples of this that has nothing to do with me: when async/await syntax was being decided, there were two very entrenched camps: await(expr) vs expr.await . A very serious argument levied by the pro "prefix await" side was that that's how JS does it, and that people expect it.
anyway, lots of other factors than these. but i don't think a lot of language teams view their language as explicitly in these terms, and I think that made a lot of difference for us
Comments
https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=37227674e0e9b609f0869164e7ac43199317a2d9
I gotta stop posting lmao
* rust for rubyists, ~50 pages
* TRPL first edition, ~175 pages
* TRPL second edition which confusingly is the first edition of the published book, with Carol’s help of course, ~540 pages
rust was the language where "weird / academic" concepts were put into pragmatic use, in a way that made them feel day-to-day.
like, it was made of the pragmatism of the right-now-uses vs the endless theorizing on the next thing.
At the point where these things rolled into Rust, they were already old concepts, and yet they'd stayed in academic realms. Rust took the at-the-time stable concepts and leveraged them right then, versus letting them percolate more.
I don't believe there's any contention, here.
Theorizing on the next thing is good, but not instead of actually applying the backlog you already have. That's when it becomes "endless", which can be bad.
in practice, a solution was found: have the rust compiler parse both, and spit out an error showing you how to do it https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=98040af61d15b49c2ceb8edec9de8101