I worked at Google years ago and there was a presentation once done on some optimizations done on Chrome performance. This is probably 10 years ago now.
So C++ has std::string of course. C libraries however use "const char ", which has lots of problems. The C++ designers allowed you to avoid friction here by allowing you to pass a std::string to a function expending a const char . Technically, this is an operator method.
It was discovered that the Omnibar in Chrome went through many layers of translations between std::string and const char *, back and forth, such that there were approximately 25,000 string copies per keypress in the Omnibar.
So my point is that even with a ton of resources writing good, efficient and performant C++ is still nontrivial. And that's really the point of Rust (well, one of them).
It's the other way round. You can pass a const char* to a function expecting a std::string. Passing a std::string to a function expecting const char* will generate a compile error.
You need to call c_str() on the std::string if you want to pass it as a parameter to a function expecting a const char*.
Those were not difficult to understand C++ features either, but basic ones which were very well known by then. I remember reading Bulka & Mayhew’s Efficient C++ (published in 2000) which mentioned the importance of avoiding copies, calling reserve and many other techniques.
So your point is wrong. Not copying strings all over the place, calling reserve, not creating temporary containers are junior-level C++ skills.
Isn't this a bit oversimplified? IIRC the Rust support was only started as an option for writing device drivers in Rust, not actual kernel code, and even this relatively simple use case looks like a herculean effort which required changes to feed back into Rust - which is a good thing of course, but currently it looks like the Rust ecosystem benefits more from that project than the Linux ecosystem ;)
The beginning of this sentence didn’t surprise me, but the fact that it’s just Linux and Android did. Rust supports macOS and Windows really well, so I wonder what the gap is here?
> Facilities and tooling in Rust are not as rich as other languages yet.
Is this meant in the context of Chromium?
Picking just one piece: Consider that Chromium builds happen in a distributed build farm. There's multiple variants of this (goma, rbe). I'd imagine those systems would have to be modified to support the Rust toolchain for that target.
And it looks like this work is built around making GN/ninja support Rust, just using cargo directly. So that's what they likely mean by "not as rich as other languages yet."
In fact there are articles of people burning out with the release process of Chrome, left behind by the sheer speed at which the project is moving forward.
[1] https://chromium.googlesource.com/chromium/src/+/HEAD/styleg...
What are the alternatives in the context of Chromium development as a replacement for C++?
See "Using safer languages anywhere applicable".
[1] https://en.m.wikipedia.org/wiki/Rust_(programming_language)
All the chaos of the so-called web standards, decades of accumulated C++ complexity and the eccentricity and burgeoning complexity of Rust on top. Getting assigned to such a project must be akin to punishment.
