Is anyone aware of secondary effects this has had? e.g.
removed C++ code that has later found to have bugs, or newly re-written crates now more useful to the wider community than the same code locked up in C++.
> e.g. removed C++ code that has later found to have bugs
The article links to a longer article (https://hsivonen.fi/encoding_rs/) about encoding_rs. The longer article mentions a bug that got fixed in Firefox ESR after the code had been replaced with encoding_rs in non-ESR Firefox. (I wrote the bug, too, though.)
> or newly re-written crates now more useful to the wider community than the same code locked up in C++.
encoding_rs is an example of a crate developed for Firefox but also developed as a crates.io crate from the start. ripgrep is probably the best-known Rust-only app that uses encoding_rs. Since Visual Studio Code bundles ripgrep, I believe Microsoft shipped encoding_rs before Mozilla did!
There's actually a lot of people who want actual, experimental data to back a language's claims about safety. A subset of them use C and C++. I occasionally argue with them about safety benefits of other languages. They demand more proof than the design, esp field data. I do keep stuff like this as experimental evidence that will add up for such empiricists over time. Although, I prefer controlled experiments where you teach amateurs C, modern C++, and Rust over a specific time followed by testing (esp fuzzing) of their code to test the safety claims. Run it in a dozen different places to see if results are consistent.
There's also folks that just study these things to identify patterns in problems created, prevented, or detected (at what effectiveness) in various languages and techniques in software development. Along similar vein, each bug report also provides (in theory) a test case for automated tools that detect bugs. It's very important to have a huge, diverse pile of code to test those tools with. That's because each one's algorithms might have blind spots missing bugs. The more code and bugs we have, the better we can assess those algorithms' accuracy. And then build better algorithms. :)
It seems fairly obvious that if Language A's design prevents a certain class of bugs possible in Language B's design, A is safer than B. If someone isn't satisfied by this, they probably are biased against Language A. I'd tell the hypothetical person to try writing a buffer overflow vulnerability in safe Rust.
That said, I can't find the source right now but I believe the quote is something along the lines a sizable percentage of Firefox's security bugs would be less severe or nonexistent in Rust vs. C++.
Usually with the argumentation that nicksecurity is referring to, they eventually switch to is "but Language A still allows for bugs class type X thus why bother".
So one then needs to resort to statistics and other stuff as argument validation.
For example, even after being proven wrong with Godbolt that it is possible to write safer code in C++, while keeping the same or even less hardware requirements, many embedded C devs still argue that it is not worthwhile for safer code.
Rust, just like other (almost) memory safe systems languages will get the same human judgement.
Don't get me wrong, I love Rust, but I think any programming beginner starting with Rust as a first language is pretty likely to fail.
Ownership is a hugely important part of designing programs, and it's something people need to come to terms with eventually, but a language where you can't do even hello world without understanding ownership adds a lot of mental overhead to the learning process when someone is still not even comfortable with for loops and function calls.
`cargo new $project_name` literally generates a hello world program so it is misleading to say you need to understand ownership to write `hello world`.
That being said ownership is rather hard, but liberal usage of `.clone()` can get you pretty far.
That's a different subject entirely. Beginners should learn from resources teaching fundamentals, both primitives and patterns like abstraction/decomposition, using a simple language with minimal, incidental complexity. Once they grok that, my next recommendation is using another simple, but real-world, language like Python or Go with lots of code they can practice on. Read, modify, and debug. Then, with key skills, they can tackle hard stuff like C, C++, and Rust.
Pyret at pyret.org is a good candidate since there's a group called Bootstrap successfully teaching it to middle schoolers. That's bootstrapworld.org.
Far as Rust, Ill also note people exploring the language or doing quick-and-dirty coding can just use reference counting if they want. Rust supports that. There's a performance hit but that's probably fine in those use cases.
Why is Mozilla trying to replace components of Firefox with Servo, rather than trying to complete Servo as a full and compliant engine? I.e. it looks like browser.html is not very usable, since Servo itself is quite behind in actual features support compared to Firefox.
I would say that there are only downsides in going that way.
If you take on a full rewrite you lose a lot: you can't show that you are incrementally better, you cannot show that it will be a good long term investment, you must rewrite even well maintained core parts that works fine, you don't get to improve the original engine with the good parts and essentially you get nothing in return.
The way Rust code gets added includes:
* A new feature needs an identifiable library, so the new library can be written in Rust to begin with. (Example: U2F token USB integration.)
* Old code needs a rewrite anyway, so the rewrite can be in Rust. (Example: Character encoding converters.)
* Servo has proven a component, so it makes sense to bring it over. (Examples: Stylo and WebRender)
* History of vulnerabilities in code that was replaced. (Example: MP4 metadata parser)