Hacker News Reader

Comment by johnnujler | Hacker News Reader

Great thing but I feel these companies are just too clever for Rust. Rust is a developer’s delight and I don’t want it to become like C++, and I feel the C++ standard got worse especially after these so-called great companies became a part of the standards committee. Or take the example of Web, made worse after the Googles and the Apples of the world got in.

So I have mixed feelings about too many clever people doing too many clever things to an awesome language.

View on HN

> Rust is a developer’s delight and I don’t want it to become like C++, and I feel the C++ standard got worse especially after these so-called great companies became a part of the standards committee.

On the Rust language team, we are extremely mindful of managing complexity, and we typically err on the side of not including a feature (even if it's desired) if it feels like it adds too much complexity or surface area to the language. We've also paid attention to other language design processes and learned from them.

The biggest problem here, though, is that look at Google in web standards: the web is now what Google say it is, IE 6 style. If Googlers don't get their way with the Rust language team, they'll just attack the language team head-on, or bypass them. Google have zero interest in collaboration.

Google employees have actively gotten involved in collaborating within the Rust project rather than bypassing it. Of course, anything can change at any time, but this absolutist statement doesn't correlate with experiences so far.

(Also, these organizations are huge! The web standards folks and the Fuchsia folks are, as far as I know, basically disjoint, so even talking about companies like Google as a monolithic entity is fraught with issues.)

In their own spare time, or as part of their paid work at Google?

I am not 100% sure, but given that the features were directly relevant to their work, I would hope that they were given time to do it on the job.

That's why we're all using dart

> If Googlers don't get their way with the Rust language team, they'll just attack the language team head-on, or bypass them.

We work directly with Google folks. This has not been our experience in any way. Likewise for other large companies interested in specific Rust features or improvements.

The language team is the sole group of people who decides how the language itself changes over time. Entry into that team is determined by the consensus of the team itself. Anyone can comment on proposals, and of course, a company could hire those individuals, but it's not possible to become a decision maker (or stay one) without the explict consent of the existing set of decision makers.

That being said, we (that is, the Rust team broadly, I am not on the language team) do weigh companies' desires fairly heavily, because we want Rust to be used for real, important things by companies. But it's always a balance. Famously, the lang team even resisted some proposals by the Servo team way back in the day, even though most people involved on all sides were Mozilla employees at the time.

I am genuinely curious to know more about this. Some of these companies dedicate multiple teams towards an OSS project, which I’ve seen first hand with projects like llvm. So isn’t it possible that the involvement of these companies could actually systemically turn things as most of the people working would be their employees and that the scales could be manipulated easily by these companies(need not be intentional). For example I remember “std::string_view” in c++ being one example which Google pushed and even got into the C++17 standards despite its bad design. Although I might be wrong, but my guess here is that Google had a use for it(which we know it had) and that lot of people on the standards committee being from Google led to a systemic bias. Couldn’t that happen with Rust?

In very broad strokes, changes to the language work like this:

* Anyone may write a proposal

* Anyone may comment an open proposals

* The people on the Rust team decide to accept, reject, or postpone a proposal.

Those people on the team have the power to gate any major decision about the language itself. Some big company could hire 500 Rust developers (let's make it ridiculous on purpose), have them write 1000 proposals for new features, but that doesn't mean that those changes will happen: it requires that team of people to sign off on the decision. That group of people is added to only with the consent of all of the existing members. Additionally, making decisions is a consensus based process, so a single "no" vote will mean the proposal is not accepted.

Now, that doesn't mean the process is immune to companies suggesting things. For example, a company could try and hire literally every member of the team. That would be... aggressive. They can use their resources to give more people more time to do the work of making a great proposal, building consensus, and making changes they want to see happen. That is actually an ideal situation, and has been working pretty well historically. (Google employees were key in getting async/await to work out, for example. This is also basically what Mozilla's influence on Rust was for its entire history of working on things.) This is the way I'd personally love to see Amazon (and others) contribute.

From the article:

> Let’s be clear: We understand that we are net beneficiaries of the exceptional work that others have done to make Rust thrive. AWS didn’t start Rust or make it the success that it is today, but we’d like to contribute to its future success.

Reply on news.ycombinator.com