[fatneckbeard]

Yeah I worry about this. There was no "C leadership", it was simple enough that dozens of people created their own compilers within a few years of C existing. this was back before the internet. they had companies sprouting up like Borland just making C compilers for personal home computers. C just ... spread. All these kids learning Arduino in school, they are learning C.

There basically is no other usable compiler than the official rust compiler. So it has this 'leadership' thing that ... C never really needed

[xyzzyz]

Rust is winning market from C and C++ precisely because of strong technical leadership and direction. It couldn’t have made much progress by taking similar hands off approach as C, because C is already more than good enough C.

[lr1970]

> Rust is winning market from C and C++ precisely because of strong technical leadership and direction.

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.

[cbsmith]

In fairness, this reasoning would suggest that any new language developed 40 years younger than C and 30 years younger than C++, that incorporates advances in computer language design that C/C++ cannot adopt without breaking backwards compatibility would enjoy the same success, if not more, than Rust.

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.

[conradev]

These things can be true simultaneously. The Rust team can have extremely strong technical leadership and direction while also being incredibly immature when it comes to conflict resolution.

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.

[snovv_crash]

Rust is winning marketshare because it was built ground-up to take advantage of the massive progression of Moore's Law at compile time. Compiling programs written in Rust would have been completely infeasible 20 years ago, it would have simply been too slow.

[adrianN]

C++ doesn't compile that much faster than Rust.

[snovv_crash]

Modern C++, I agree. C++98 is a lot faster to compile though, even the same code using the same standard library calls.

[adrianN]

Having worked on a modestly sized C++98 codebase in the recent past, I don't think I agree. But of course it would need proper benchmarks.

[pphysch]

> Rust is winning market from C and C++ precisely because of strong technical leadership and direction.

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.

[patrick451]

The hype around Julia definitely gives Rust a run for it's money.

[pphysch]

"in Julia" yields 25 pages of results on HN, while "in Rust" has >100 pages alongside other popular langs.

[patrick451]

What's your point? The target market of Julia is mostly scientific, not general purpose computing. That market is almost certain to have a smaller representation on HN. I'd actually contend that for a language with such a targeted to have 25 pages of results HN supports my point rather than debunks it.

[cookieperson]

Julia doesn't even operate in the same space as rust... Julia is closer to go lang than it is to rust and I wouldn't say those two languages are similar at all. Also if I were picking a language on community alone, I'd pick rust. The issues going on here are not reminiscent of the community at all. Julia also had drama over conferences and allowing members to speak...

[patrick451]

So what? Nothing you have said has anything to whatsoever to do with hype.

[deterministic]

Nope. Most languages have strong leadership and zero chance of taking anything from C/C++. And it will takes a very long time for Rust to get even 5% of the C/C++ market. There are more than 6 million C++ programmers out there. And new C++ projects are started every day.

[bluejekyll]

Wouldn’t you consider the C standards committee as the leadership of C?

[pjdesno]

Note that the "C committee" was actually the X3J11 committee of ANSI, the American National Standards Institute. In other words, it was just one committee within an organization with a long history of developing cross-industry standards. As such, their job in theory wasn't to invent new technology, but rather to adjudicate between technologies proposed and demonstrated by competing industry vendors.

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)

[djbusby]

The C committee started after the various compiler implementations. Rust seems to have had the committee before the compiler.

[Sharlin]

Definitely not. C was born in a different context, and these days it's not common for any language to have multiple competing implementations, certainly not in its early years. C needed the standard because there were many implementations, JavaScript needed a standard because there were many implementations, but Python or C# or Rust or Java don't have a standard (although there are technical specifications of different degrees of rigor) because the standard is what the reference toolset does, modulo what are accepted as bugs by the technical team.

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.

[ryao]

There were plenty of different FORTRAN compilers back then too.

[Sharlin]

It just was a completely different era. There was no consept of what we today call open source, no compilers freely available over the internet, no internet to speak of for that matter, no cross-platform/multi-platform compilers to speak of, more platform diversity than now, FORTRAN was also a vastly smaller language so you could have implemented a compiler in a reasonable time if you didn't want to shell out $BIGBUCKS to buy one, optimizers (which are deep magic and really hard to write from scratch) weren't yet a thing, there were no standardization bodies that worked on programming languages, everything was vastly less connected than today. That obviously leads to redundant work.

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?