There basically is no other usable compiler than the official rust compiler. So it has this 'leadership' thing that ... C never really needed
There basically is no other usable compiler than the official rust compiler. So it has this 'leadership' thing that ... C never really needed
Hmm, not sure about that one. Rust has an enormous hype component to it, more than any other language I'm aware of.
It may have strong technical leadership, but saying it's gaining market share "precisely" because of it is precisely misleading.
No, Rust is winning because it is 40 years younger than C and 30 years younger than C++. Rust incorporates advances in computer language design that C/C++ cannot adopt without breaking backwards compatibility. Rust is winning despite its leadership rather than because of it.
EDIT: elaborated a bit more.
It seems likely that there are other important factors. It's debatable what they are, but clearly there is a difference of opinion about how much Rust's leadership accounts for why Rust is succeeding more than most.
Conflict resolution is hard! I struggle with it as an engineer who wants to please everyone, but I also recognize that it isn't possible to.
Whoever had objections to the talk and was not able to express those objections to their teammates in the proper forum before taking action without their approval is just... immature. It violated trust amongst the Rust leadership team, and trust is everything.
It’s actually even worse, because this person also wielded enough power to represent Rust to RustConf, and did so incorrectly. They seem problematic.
Leading people is always messy and requires the maturity to deal with failures gracefully, and a catastrophic failure from a simple task is not confidence-inspiring. I love Rust, so I hope they get their shit together.
There was no "leadership team" for Rust at Mozilla as far as I know. It was originally a one-person side project like C++ or Python, then it was elevated to an official Mozilla internal project as its potential in the context Gecko was understood by the higher-ups. But again, as far as I know, whatever culture formed around the project did so organically, but also as a conscious attempt to avoid many cultural issues seen in other OS projects. And mark my words, the Rust community as a whole is genuinely friendly and welcoming compared to almost any other internet community of similar extent, and there's nothing sinister underlying that friendliness as far as I can see.
When Mozilla got rid of Rust, the leading technical contributors continued as they had always done (albeit now with considerably fewer full-time paid contributors), as an independent self-organizing entity, but now even less accountable – in regard to technical decisions – for any external stakeholders but the Rust community itself. But some organization was required to foster Rust's growth, to manage all the inconvenient legal things, the interaction with the now several large stakeholders and funders such as Google and Amazon, and so on. So the Rust Foundation was created to manage all that. But the foundation's jurisdiction ends where the technical aspect of Rust begins – all the technical teams are still exactly what they used to be, accountable only to the greater community.
At any point, anyone could have experimented with different implementations with no "committee" saying what to do, but let's face it: first, modern compilers, even simple ones, are extraordinarily complex compared to an early C compiler running on a PDP-11, and second, in light of the first, Rust didn't grow in popularity nearly fast enough for anyone else bothering to write an implementation to experiment on.
No matter, the point is that nothing has ever stopped anyone from writing a competing Rust compiler, certainly not any imaginary "committee." Nothing except the fact that, besides mrustc, nobody has bothered because why would you do that?
Like many other modern languages, Rust is a mono-implementation, where the same organization is both developer and standards committee, while at the same time trying to fund itself (without revenue from either standards docs or the compiler) and balance external commercial and non-commercial interests.
There are advantages and disadvantages to each approach, but they are very, very different. (and in a world of cutting edge open-source compiler technology, I'm not sure the approach which resulted in ANSI C is even viable today)