[alabhyajindal]

> This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time.

I don't like this bit. Wouldn't it be better to decide on a memory-safe language, and then commit to it by writing all new code in Rust, or whatever. This looks like doing double the work.

[nicoburns]

It doesn't have to all-or-nothing. Firefox has been a mixed C++ and Rust codebase for years now. It isn't like the code is written twice. The C++ components are written in C++, and the Rust components are written in Rust.

I suspect that'll also be what happens here. And if the use of Rust is successful, then over time more components may switch over to Rust. But each component will only ever be in one language at a time.

[fabrice_d]

You can't compare the choices made to evolve a >20 years old codebase with a brand new one. Firefox also as Rust support for XPCOM components, so you can use and write them in Rust without manual FFI (this comes with some baggage of course).

The Ladybird devs painted themselves in a corner when choosing C++ for a new web browser, with many anti-Rust folks claiming that "modern C++ was safe". Well...

[VoxPelli]

Firefox was special in that Mozilla created Rust to build Servo and then backported parts of Servo to Firefox and ultimately stopped building Servo.

Thankfully Servo has picked up speed again and if one wants a Rust based browser engine what better choice than the one the language was built to enable?

https://servo.org/

[riku_iki]

> Wouldn't it be better to decide on a memory-safe language,

it is totally possible to use some strict subset of C++, which will be memory safe.

[IshKebab]

Only in theory. In practice it never happens like that. I mean, you think Google wouldn't use that for Chrome if they could?

[LeFantome]

Ladybird already does that

[wvenable]

One could do that but then they'd lose all momentum and the project would never get finished.