Rust and C++ Interoperability in Chrome
chromium.org
chromium.org
> For a Rustacean, this is controversial - all C++ is unsafe!
Isn't this just a fundamental misunderstanding of what unsafe really means, and as such a nonsense goal that doesn't gain anything?
Unsafe is a Rust language definition, and defines whether the rust compiler can vouch for the safety of some code. As such, calling to a library in some other language will always be unsafe, by definition, because the Rust language cannot vouch for it.
If it makes you feel better, replace "unsafe" in your head (or with a macro) with "rustc_cannot_vouch_for" and carry on with your day. It means the same thing, and isn't really telling you that your C++ code sucks even if it looks like it at first glance, so who cares?
If you really want to reduce the unsafe keyword from being seen in most regular code, you create and interface that maps the C++ function and exposes it as a rust function, and you've hidden away your unsafe usage to one spot per function. If you have enough confidence in your C++ code, there's no downside to this (and if you don't, then maybe you shouldn't be complaining that unsafe is unneeded).
Oh... no, no, that's... very unsafe lol.
Jokes aside, making that their #1 goal was very strange. Agreed it appears to be a fundamental misunderstanding of what "unsafe" means. It doesn't mean that it's literally not safe to call that function, just that it's unchecked. "unchecked" might be a better annotation come to think of it.
Yeah, it's come up before in discussions here. Depending on the context you're coming from/working in, unchecked either makes more sense, or less sense than unsafe. When working within Rust, unsafe makes sense, it maps to how people think about what they are doing, because rustc is checking everything. When working between Rust and other languages/libraries, it's a bit less accurate, and "unchecked" makes more sense.
“We are happy to empower our younger colleagues. We only ask they have 25 years of experience.”
Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one. The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs.
Whether that’s the right call, I don’t know. I see the practical argument, but I also think that a lot of common Rust idioms, especially around memory management, depend on these safety guarantees. For example, field destruction order in Rust is weird and you often don’t control it as carefully as you would in C++. That’s usually fine in normal Rust code, but might not be if lots of marked-as-safe-but-actually-unsafe code is flying around.
This is well-defined, as being dropped in the order that they are declared.
Yeah, the fact that it's the opposite in C++ was a huge point of contention before we defined it; changing what was there risked breaking a lot of code, and there are good reasons for either order. But yeah, I had to go and look at the RFC for exactly the reasons you state; it just isn't normal to care about this at all, so it's easy to not remember.
Don't you just define a destructor[1] and make it explicit? Or maybe I'm missing something subtle here?
Yes, because "safety" in English is not analogous to "unsafe" in Rust in any real manner. They are linked only in the loosest conceptual way. Rust's "safety" and "unsafe" are well defined and exact, and can be objectively determined. In the English language it is by its nature subjective.
> The usual understanding is that an unsafe function is any function that can, if passed the wrong arguments, cause Undefined Behavior.
That is, specifically AFAIK, not what it means in Rust. It's well defined there, so there's no need to resort to "the usual understanding". This causes a lot of confusion, but it doesn't need to. If someone is talking about the unsafe keyword in Rust, they're talking about Rust's definition of it and what it entails, or they're using incorrect terminology.
> Presumably, the C++ wrappers suggested here would not even be safe in that sense. They would use a lot of pointers, and cause UB if passed the wrong one.
Then there's not a lot of point in using Rust if they refuse to change that usage. It's not about using Rust to check off a box that you use some buzzword technology, it's about leveraging what it can provide that other languages can't, or can't do as well.
If someone finally decides to put a firewall in front of a server but decides its' too hard to actually limit traffic in any way so allows 0.0.0.0/0 any port, you don't congratulate them on their firewall, you tell them they just wasted everyone's time and money.
> The article argues that using unsafe correctly is impractical for Chromium because basically every Rust function would have to be marked unsafe to call into these raw C++ APIs.
To my knowledge, the way Firefox did it was to pick a system or library, provide a Rust replacement that C/C++ could call, and allow it to be moved into place. That's sane. Using rust and C++ functions on the same memory and expecting Rust to deal with C++'s pointer shenanigans may not be, in the same way I wouldn't expect mixing small amounts of Java in the JVM into a big C++ would just work unless you had hard rules about who controlled what memory/objects and made sure you never broke them.
I can't help but feel they're approach is likely to cause them more problems than needed because they're not willing to commit the sane minimal amount to make a lot of these problems not matter (replace a small self contained system). If they don't actually have any small self contained system, and they really are just passing stuff around and using some complex pointer control, and aren't willing to change that, maybe Rust isn't a good candidate to extend their project languages with.
I'd say that Rust is using incorrect terminology, since it is at loggerheads with "the usual understanding" (which should be the default, not something "resorted to"). Rust could have chosen a different word than safe/un-safe, but they didn't.
Languages get to define their own terms. It's not rare for two languages to use terminology in similar, but different in fundamental ways, concepts. An extremely common example would be "threads".
In the case of "unsafe", we're not even really staying within the realm of software engineering to find a terminology mismatch in this case, we're going back to the English language itself (in which case almost all the keywords in any language might have a similar problem).
Isn't that what they did? Through the use of https://github.com/dtolnay/cxx
Agreed the article expressed the concern in a rather clumsy manner, but they seem to have a point for their particular use case, and they addressed it appropriately.
I'm not sure whether it's actually better to abstract all the unsafe away, or force it to shown where it's used. In one respect, they may be right, it might lesson the impact of unsafe and it gets used more freely. On the other, it also means that it's not necessarily immediately obvious when you're crossing boundaries, since the obvious bits and intentionally hidden away.
Though I'll freely admit my initial responses were a bit hyperbolic and... testy. :)
There would need to be domain understanding baked into each wrapper and some contract about what is happening on the other side of the ffi wall for it to qualify as both safe and sane, and I’m not sure their approach meets that high burden.
Yeah you can mentally substitute 'rustc_cannot_vouch_for' but why can't Rust use a word closer in meaning to that in the first place?
We tend to misuse everyday meanings I think. I reminded of
1. the msdos warning that 'this program has used an illegal instruction and will be shut down'
2. That DNS names with underscore are 'illegal'. This one caused an amusing kerfuffle at one company I worked at.
3. That certain crypto algos are 'broken'
This is inevitable. We either invent new words, or we use existing words from the natural language. The latter will always lead to confusion at some point, because the domain-specific concept doesn't exist in the rest of the world. To represent such a concept, a word would need to deviate from its everyday usage.
I think Rust's "unsafe" is an okay choice; the "vouching" is a feature about memory safety after all.
"safe" is entirely relative in it's everyday meaning. To one person skydiving is safe, to another it is extremely unsafe. When you're a child your parent will tell you what is safe or not, but what your parent considers safe is based on their personal definition of safety.
The rust language will tell you if what you've done is safe based on its very well defined criteria for what that is, and won't let you proceed with something that doesn't match that criteria unless you vouch for it yourself. unsafe makes just as much sense here as any other word, it only seems a wrong fit when you look at it from a context it's not meant to be used in.
I think the use of "unsafe" is exactly what is a common case. That is declaring, "I know what I am doing," and that for most people do do this may be a bad idea.
Is this different from the Firefox integration with Rust in some meaningful way?
It looks like the cxx library is going to be critical for this. I’m curious how helpful others have found cxx for interop with C++?
> For a Rustacean, this is controversial - all C++ is unsafe! But “unsafe” should be a really bad code smell. If “unsafe” is needed for all C++ calls, there will be thousands of them, and the “unsafe” keyword will lose its meaning.
I don’t think the attitude about unsafe usage differs from the general Rust community. If there’s a lot of it, then it definitely is a code smell.
#define CPP_CALL unsafe
"No boilerplate or redeclarations. No C++ annotations. Ideally, no allowlist."
This seems like an unpractical approach. How do you even call C++ code from Rust without extern "C" linkage.
macro_rules! cpp_call {
($($tt:tt)*) => {
unsafe { $($tt)* }
}
}
Seriously though, maybe comment annotation would be better than abusing the macros like that. I though there was a more direct cpp way. (Edit: As in the c preprocessor, not C++.)
Is that not pretty much what Rust's procedural macros are? [0]
Except for the fact that they do not allow emitting invalid token streams (which is something you don't want anyways), it can do any arbitrary manipulation of source code, but in a way that is integrated with the compiler and less prone to breaking the program.
[0] https://doc.rust-lang.org/reference/procedural-macros.html
Textual substitution is less rigorous. It tells the compiler to replace a string with another, wherever it is seen. There's no restriction that it must be valid token input to be replaced or that it needs to be an explicit usage of the macro.
cpp_call! { fn foo() { ... } }
#[cpp_call] fn foo() { ... }
Reminds me of some of stringification abused in the Linux kernel. What looks like a function call passing the literal text param1## as an argument, where it would then trigger a different stringification in a subsequent preprocessor pass that prepended ##foo to the passed argument.
I mean, I get it, these are all things which can be used to very easily cause chaos and shoot yourself in the foot. I look at code that I've written, though, and see so many challenges to writing the same thing in Rust.
I spend 99% of my time in embedded Linux or bare metal, though, so maybe my view point is a bit skewed.
There seem to be very few GUI libraries which can be used in Rust as well. I'll keep checking https://areweguiyet.com/
Like if you're doing #define PI 3.14159 you're asking to get chirped in code review.
#define PI 3.1415927410125732421875
inline double pi()
{
__asm fldpi;
}
Which actually highlights that many things you want to use for practical purposes are C rather than C++, predate innovations such as const or namespaces, etc. It's possible and common to understand the downsides and still reach for the macro.
(It took me a while to write back to you because I am busy writing bare-metal embedded Rust, btw. Including using some macros!)
Hiding the word "unsafe" doesn't make it any less unsafe.
The Rust compiler can't guarantee that the C++ code being called doesn't have use-after-free bugs or buffer overflows.
The Rust compiler can't guarantee that pointers being returned from C++ code aren't just wild pointers that point in the middle of nowhere.
The Rust compiler can't guarantee that the C++ code isn't mutating into an immutable reference.
The Rust compiler can't guarantee that the C++ code isn't holding onto a reference to an object that it will later mutate when Rust thinks it is now the sole owner of that object.
The Rust compiler can't guarantee that the C++ code isn't sending un-Send objects across threads, or that it isn't deallocating objects that it isn't supposed to deallocate.
Rust makes a lot of guarantees about code written in Rust, which is why people are so passionate about it. The Rust compiler feels like having the world's best static code analyzer at your fingertips. It's really nice.
C and C++, on the other hand, are each full of an assortment of powerful footguns. Well-written C or C++ code interops very nicely with Rust, but the problem is that programmers are only human, and humans have been repeatedly shown to make mistakes.
So, calling C++ code is unsafe, and unsafe is a code smell because it is an opportunity for guarantees to be violated, which is undefined behavior.
Ideally, you build an abstraction around the unsafe interop layer that rigorously enforces every requirement that the C or C++ code expects (but that the C and C++ compilers cannot enforce), so that the external code will behave as well as it can.
The Chromium document is right to call their idea controversial. Hiding the unsafety of the C++ code without actually doing anything to protect against malformed calls to that C++ code is a loaded footgun. It might be the right call for this specific case, though.
I think that’s the reason that doc discusses using cxx, right?
> The Chromium document is right to call their idea controversial. Hiding the unsafety of the C++ code without actually doing anything to protect against malformed calls to that C++ code is a loaded footgun.
I agree with you, but at the same time, I think in this context, single codebase, abstractions built by the teams making the guarantees at the FFI boundaries... it feels like they would meet the requirements here? It definitely is less strict than Rust, but the way I interpret it is that they are saying they will guarantee the C++ is safe behind the abstractions (maybe they can mark the C++ In some way to state this), and that’s not all that different than what we say in general in Rust when we claim an unsafe call is in fact safe when we wrap it in unsafe.
What I mean by mark, is potentially use some annotation in C++ that cxx would only call into when that annotation is present.
cxx can only really do as much as the C++ compiler can. It's certainly better than nothing. In my experience, a non-trivial amount of C++ code will have additional requirements on how and when you're allowed to call various functions; requirements that aren't enforced by the compiler.
>> It might be the right call for this specific case, though.
> I agree with you, but at the same time, I think in this context, single codebase, abstractions built by the teams making the guarantees at the FFI boundaries... it feels like they would meet the requirements here? It definitely is less strict than Rust, but the way I interpret it is that they are saying they will guarantee the C++ is safe behind the abstractions (maybe they can mark the C++ In some way to state this), and that’s not all that different than what we say in general in Rust when we claim an unsafe call is in fact safe when we wrap it in unsafe.
That's why I said it might be the right call in this specific situation. Normally, I don't think this is the right approach, but it's probably the sensible thing to do here, especially since it's likely the same team of people on both sides of the FFI boundary.
But they want "No C++ annotations". I believe they should have annotations in the Rust code to make it clear that the Rust/C/Cpp borders are crossed.
Which is why unsafe is considered a code smell, and why people in the Rust community get upset when unsafe is used unnecessarily. That's why some people might find it controversial to hide the unsafety of the C++ code being used here. I've used Rust professionally for years, and I don't remember ever having to write any unsafe code in a professional context apart from FFI, and even then... the glue code to wrap around that unsafe FFI was very strictly written to make things as comfortable as possible for the FFI code and minimize the chance of bad things happening on the other side of the FFI barrier.
However, even then, your statement is not entirely correct. Unsafe Rust is extremely similar to safe Rust, enforcing the vast majority of safety requirements automatically. Unsafe code is very limited in what bad things it can do compared to C++ code.
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html#unsa...
- Dereference a raw pointer
- Call an unsafe function or method
- Access or modify a mutable static variable
- Implement an unsafe trait
- Access fields of unions
Those are the only things unsafe Rust can do that safe Rust can't. It doesn't turn off the borrow checker or anything else. There are a lot of mistakes that can be made in normal C++ code that you can't make in regular, safe Rust.
> All this document says is that the C++/Rust boundary should be considered another place where you are asserting "I promise this code is actually being used in a safe way".
The problem is that C++ compilers are much less capable of enforcing safety (inherently, due to legacy design decisions and backwards compatibility), so you often want a layer of glue code that only allows you to use C++ code in ways that are known to be safe, not just any arbitrary way that the function might be callable.
I already said I agree Chromium's team seems to be making the right call for this specific situation. It's not the right call most of the time. C++ code isn't fungible as being "just as good" as safe Rust code. The unsafety needs to be obvious, just like it is with unsafe Rust, so that you can recognize that the external C++ code (or unsafe Rsut) is a loaded footgun, and to treat it with appropriate care.
To be clear: Rust isn't a perfect language, and you can get the vast majority of the safety benefits by using almost any garbage collected language. What makes Rust awesome is that you can bring the memory safety of garbage collected languages into the realm of consistent performance requirements that previously was inhabited mostly by C and C++. Rust is a nice language, but so are a lot of other languages.
You can do serious damage with those things though. One tactic I have done is to expand the lifetime of a reference by laundering it through a raw pointer, since the function to convert a raw pointer to a reference allows you to choose any lifetime you want.
Unlike C or C++, where it can sometimes be harder to tell what the lifetime of something should be, or whether you’re extending the lifetime of a reference beyond the point that it is safe.
Unsafe definitely gives you loaded footguns... which for the umpteenth time is why it is considered a code smell. Sometimes you have to write smelly code, but it’s something to be avoided.
do you think more than a few percent of the "foundational" OSS projects where we find all the classical CVEs have any code review process ?
Yes, when there is too much unsafe in a Rust codebase then the unsafe label inflates and the safety guarantees aren't as good. But the conclusion of that shouldn't involve changing definitions of what's unsafe and what isn't, but using less unsafe overall.
Rust can interface with C++, but it isn't well suited for too intimate interfacing. That's not where its strengths lie.
Doing this a lot in pure Rust is a bad smell because you usually have other options and you're opening yourself up to risk. In this case the code exists and you already own all that risk so it's perfectly reasonable.
This is good documentation on the safety of the library: https://github.com/dtolnay/cxx#safety
What is indeed bad is code that sprinkles unsafe all over the place without explanation and if you check a random segment fails to handle common error cases that pure Rust would force you to handle.
Never fails, and will also never fail in the future as other code changes. There are certainly situations where you can be sufficiently confident of that, but it's something to think about.
Eg if you have a heap allocated thing that is passed between Rust and C++, who frees it? I ended up hacking something together, but it didn't feel right.
Isn't this an issue regardless? Forget crossing the rust/c++ boundary, lets say you pass something to another class in c++, you need to have a contract of who frees what when, right? Maybe I'm not understanding the issue.
C++ allows to be more clear: unique_ptrs allow to move ownership, references mean this is definitely not owned, and the remaining questions are around normal pointers.
With pure C there is however zero distinction. A pointer can mean ownership is transferred, it is meant to be a reference, it could be a static reference to something in constant memory, etc.
I've done to many C++ wrappers with C linkage of C++ libs to call from C, that convert exceptions to error codes and free_obj() wrappers to run destructors.
The standard doesn't specify memory layout or ABI so as a general rule you can't do this. You can get around it by depending on implementation details like what is implicitly done by chromium
The Gcc and libstdc++ maintainers are extremely careful to maintain ABI compatibility between widely-separated releases, where permitted by the Standard. You can happily call between code compiled with gcc-6 and gcc-10, release or debug, optimized or not.
It is possible to deliberately vary ABI with compiler options, but nobody uses those for shared libraries they distribute, for obvious reasons, with the unique exception of choosing pre-C++11 vs post-C++11 ABI.
this is chromium, everything is built from source with the same compiler, there is zero issue with doing that.
This only does not work when using a DLL built with, say, visual studio 2008 and another built with 2015.
If we become convinced this sort of interoperability is possible, we’ll revisit widespread use of Rust in Chrome, and at that point we plan to work hard to achieve this with robust production-quality solutions.
Would it be wrong to take away from this that in some teams within Google, using Rust in places where C++ would have been used, is something that is being considered seriously?
Suck it up and get used to it. Rust is absolutely the future of systems development; every major C or C++ project -- including the kernel -- is going to have a Rust interoperability story, and eventually, major components that implement desirable features written entirely in Rust, so in the interim, until the desirable but currently unrealistic goal of migrating all extant C and C++ code to Rust is achieved, you will need to have both C(++) and Rust tooling (and whatever else) to build the project.
What's the point of using Rust in a C++ code base if C++ is the 800lb gorilla as the article implies. If C++ is so important, then just stick to that?!
A journey of a thousand miles begins with a single step ...
Legacy is a thing. Replacing it piecemeal is the only way to get it replaced.
In addition, you can prioritize pieces. If a particular piece is very likely to be a security problem or has lots of bugs, you can rewrite just that piece into Rust.
1. The main program will remain C++ (or anyway Google's hobbled subset). New code you choose to get done in Rust will be lower-level code, implementing specific new features, or re-implementing low-level stuff too toxic to fix. So, the main task is not Rust calling into C++ code, but C++ calling Rust. That doesn't mean the Rust code won't ever need to call out to utility code, but: You are coding in Rust for an actual, you know, reason, right? Maybe that utility stuff should be RIIR, first? Otherwise what was the point, again?
2. It is all very well to talk about Rust calling C-like functions and virtual functions, but that only takes us up to 1985. We all know (I hope) that the overwhelming majority of useful power in C++ code is in features wholly inaccessible to Rust, even in principle. How will Rust do overload resolution? Inlines? (Also 1985.) Template instantiation? Exception handling? (That takes us to 1992.) Template function overloading and partial specialization? (1998). I could go on, right up to 2020.
There are other fundamental problems, but this seems like enough for now. No sense piling on. At least point 1 makes point 2 less a problem.
Therefore, a tendentious distraction from the topic. Chris, I shall expect better from you in the future.
They should focus on integrating Rust in portions of the API instead of exposing a gigantic unsafe API surface, essentially making all their code unsafe. Unless the Chrome codebase is really such a mess that they can't do anything without exposing this giant API surface. In that case they should rewrite it to... not do that.
"We can't use Rust unless it allows us to write all our code in C++ without showing unsafe warnings"
While the Chrome authors will not be protected from memory unsafety in the wrapped C++ APIs, the usage of those APIs in the new code they write on top will be safe, which is better than nothing. Similarly, much of the Rust standard library and many popular crates are "safe" wrappers around unsafe code, like calls to libc, winapi, openssl, etc. If there is a memory unsafety issue in one of those libraries, Rust won't save you.
Yes. It's turtles all the way down. Applying this line of thought to its logical conclusion, it wouldn't be worth it until we have written the OS itself and all firmware in Rust.
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
Unnecessary overcomplication on the codebase, making it more difficult to understand. (Rust and C++ are complex beasts)
The only thing i could think of, is to replace the tools that are mostly in Python.. But this will be a lot of work.
I guess maybe Google wants to employ good Rust enginneers and need to have some "playground" for them.
Swift on the other way, will have native C++ interop, and soon will give the ability to manage the memory ownership the same way C++ and Rust does (not just defaulting to ref-count)..
Once Swift have those properties we will have one more good contender in the same arena as C++, Rust and Zig.
Chromium codebase is a massive codebase. It works, its efficient and fast, its sophisticated and complex, its well tested, had all sort of bugs that was taken out of them. Its really well written C++ code with modern ownership semantics. So a lot of mistakes that are used as boogeyman to convince people to use Rust are barely problems you really face.
And no matter what wonders Rust promisses, a lot of bugs would get back there in case of rewriting things.
Rust can make a very good point when the thing to be rewritten is in C (if is not a billion dollar codebase like Linux). But with big codebases, well written and modern C++ it doesnt make sense at all.
I get it why someone would start a new project in Rust though.. but the things dont add up when we talk about big codebases already coded with good C++ practices.
https://bugs.chromium.org/p/project-zero/issues/list?q=produ...
This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust - both OOB accesses, one with a helping of data racing.
Chromium is an incredibly security-sensitive piece of software, and that really is an excellent fit for Rust. It's not a boogeyman argument and the Chromium team themselves are the ones pursuing it, it's not being forced on them.
Giving the time it is alive, all the engineering hours, investiments, tools, etc.. most of the bugs that Rust could have prevented right on the beggining are already covered (Chrome also uses fuzzers and static analysis tools to automate C++ code)
> This year alone saw 2 issues from Project Zero in Chrome that would have been prevented by Rust
Thanks for making my point even clearer. If you really knew the size of the codebase, having only 2 issues on Project Zero is kind of a compliment to Chrome.
By the way, it was yesterday, that i´ve saw a research with fuzzers applied in C, C++ and Rust codebases.
In that research, Rust had the same overall count of bugs and even some 'zero day' sort of ones not any different from C++ and C codebases (maybe just better than the C one).
Its a pitty i can find where it is (I´ve saw it on Twitter, but its pretty recent).
> Chromium is an incredibly security-sensitive piece of software, and that really is an excellent fit for Rust. It's not a boogeyman argument and the Chromium team themselves are the ones pursuing it, it's not being forced on them.
A Chrome started from zero in 2020? probably.. but thats not the reality here. Millions of lines of C++ code, and its not just a matter of language, but the knowledge and people with the know-how to write those pieces..
Thats why im saying is not worth it..
Again thats why im saying that if the project would start now in 2020, all of those would be pretty good points. Right now is too late for that.
As another example, you can get just the V8 VM for instance. For start, with the ammount of solid code out there it would be nuts to talk over a rewrite..
Now imagine if we add to that, that the knowledge on JIT compilers is so difficult to grasp, that you would also need to have those same great engineers in the new language/platform you are planning the rewrite.
Giving the age of Rust, and giving you already have a bad time of finding those in the much older C++, imagine the time it takes to have the same quality people in Rust.
I know a lot of people are bully about Rust, but in reality things are not that simple.
(On the bright side, is not that hard to taught a C++ engineer to code in Rust)
Actually, the people who are really experienced at writing secure code in C++ understand that they can't do it reliably, and an increasing number of them (like me) would much rather write Rust code instead for that reason. So for secure code the hiring advantage is tilting away from C++ towards Rust.
It's too early to see how the Chromium team will begin to work on this given it's only a plan, but maybe the unsafety and security issues are enough motivation to actually use Rust to C++ interop or a rewrite. But once again, this has been tried by some other projects and by just looking at the effort of a rewrite, they later concluded that it is not worth it. [1] [2]
Even better, just improve Servo instead. But I guess they would rather create their own fork, just like they did with WebKit.
[0] https://arxiv.org/pdf/2003.03296.pdf
[1] https://blogs.dust3d.org/2019/03/13/why-i-rewrote-the-mesh-g...
[2] http://way-cooler.org/blog/2019/04/29/rewriting-way-cooler-i...
Im not even taken this research for granted, and are waiting for further work to really prove the points, or even going against them.
Im just using as a cautionary tale for people going too fast on some assumptions, and not taking care to study sample by sample.
I have no doubt that Rust have a great future ahead of it. But it will take more time and lines of code to turn all of those wishes people have into reality.
That's actually not entirely true. One of the problems was the program taking too long to compete due to suboptimal algorithm. The GitHub repo showed that the tests were run using debug version of the Rust binary. It worked fine when people tried to reproduce using the release version.
For the other two problems, not many details were given, but both programs panicked immediately with the given input. That's still better than any kind of undefined behaviour or silent error.
This isn't even close to true...
https://chromereleases.googleblog.com/2020/08/stable-channel...
Here's one from just this month.
Here's another from just this month with another fifteen issues: https://chromereleases.googleblog.com/2020/08/stable-channel...
There are hundreds a year like this. I could find many, many, many more.
To elaborate on the other commenter, the majority of bugs found in chromium are bugs that rust would avoid (memory safety issues that rust makes ~impossible).
Right now the Chromium codebase have less bugs than if it was written in Rust, because of how many hours and efforts that were spent on the codebase to make it work smoothly.
Also the particular engineers with particular know-hows work with a particular tool. Its not easy to find them especially if you are forcing to use a new language in a giving project. It will take years and even decades to have the same quality people you already have in C and/or C++ in Rust.
So it will take time to have an engineer that can make, lets say, a multi-process compositor in Rust. What about many people with that particular special knowledge that take years to be good at.
So in real life its not just a matter of a language being a better fit. Theres a lot of other vectors to take into account.
https://www.joelonsoftware.com/2000/04/06/things-you-should-...
The Chromium team does not believe you. https://www.chromium.org/Home/chromium-security/memory-safet...
More as "system language" category, where you can code OS´s, JIT compilers, Browsers or any time/memory sensitive kind of software. Thats why they were packed together.
Classically, those sort of things could be only coded in C and C++ as the attempts in doing them in "higher level" languages mostly failed.
> We think the hardest part of this is imagining a safe way to pass types between Rust and C++. That requires auto-generated shim code on both the Rust and C++ side.
I'll be very surprised if they'll be able to make a production-quality solution. The languages are just too different, and Rust's OOP support is one of these issues.