Hacker News Reader

Comment by pedrocr | Hacker News Reader

Is there some kind of target or plan for converting C/C++ to Rust in Firefox? Or is it just happening as there are people interested in working on parts of the stack?

These progress numbers are very interesting:

https://twitter.com/eroc/status/1061049330574884864

and I was wondering how directed the effort was.

View on HN

Not a specific target of having to replace C++ for the sake of replacing C++.

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)

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!

In terms of deploying rust directly to make money- Microsoft is probably the leader right now with actix used in azure iot

Did you mean this actix? https://github.com/actix/actix

Is it mature? Can you shed more light on how is it used in production?

They're referring to https://news.ycombinator.com/item?id=17433142

I don't believe that it uses Actix, though. Actix was created by and is maintained by a Microsoft employee.

He has mentioned on an HN comment that they are using it internally, but isn't allowed to disclose how.

https://news.ycombinator.com/item?id=17191454

We use actix at azure iot

Ah, something that’s not in that repo? That’s awesome!

Dropbox are also using Rust in both their storage layer, and their desktop client.

You do realize that dropbox has very small profits, right? They made all of 50m in q2

> removed C++ code that has later found to have bugs

I doubt this would ever be discovered; who would analyze code that was formerly a part of Firefox?

> who would analyze code that was formerly a part of Firefox?

People looking for bugs in Firefox ESR.

People looking for bugs in Waterfox or Pale Moon.

I know it's "extended support release" but I keep reading this as "Firefox Eric S. Raymond"

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. :)

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.

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.

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.

For a much better answer than mine: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

As far as I know there is no overarching plan, but there are many people who do hold that motivation - some are more aggressive about their intent and others are more lax, and yet others are skeptical - as with any community of developers.

The broad sentiment seems to me that it's a good thing to move over, as pragmatism allows. Personally I'm a converted skeptic - I had my doubts about the language and my initial stabs at it left me somewhat frustrated - but as I've grown to internalize its semantics and behaviour - the benefits in terms of safety and clarity of intent and optimization potential are clear (e.g. aliasing semantics are just so much better).

A mix of factors enter into whether a component moves over or not, including the views of the developer in question, the complexity of the API boundary between the main codebase and the subcomponent, and the complexity of the component logic itself.

It’s the Oxidation project: https://wiki.mozilla.org/Oxidation

So the uncrustification is done by adding rust :P

It's a protective layer.

So like aluminum then.

Reply on news.ycombinator.com