4 ms·

> We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. So, even though they want the co

> We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time. So, even though they want the code base to be in Rust, they will continue writing new code in C++ and then translating it to Rust later to remove the C++ they just added. There must be a really good reason for this, such as Rust doesn’t interop well with C++, otherwise this seems like a poor decision.

yreg 9mo ago
Isn't the reason simply that they want to code in C++? This is a passion project.
- andsoitis 9mo ago
  > Isn't the reason simply that they want to code in C++? I don't know that that is the reason, given the opening lines of the article: We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now. We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story. The ecosystem is far more mature for systems programming, and many of our contributors already know the language. Going forward, we are rewriting parts of Ladybird in Rust.
  - yreg 9mo ago
    That does not explain why they plan to continue writing it in C++.
panstromek 9mo ago
> There must be a really good reason for this, such as Rust doesn’t interop well with C++ Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction. This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it). If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/ https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.

yreg 9mo ago

Isn't the reason simply that they want to code in C++? This is a passion project.

andsoitis 9mo ago
> Isn't the reason simply that they want to code in C++? I don't know that that is the reason, given the opening lines of the article: We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now. We previously explored Swift, but the C++ interop never quite got there, and platform support outside the Apple ecosystem was limited. Rust is a different story. The ecosystem is far more mature for systems programming, and many of our contributors already know the language. Going forward, we are rewriting parts of Ladybird in Rust.
- yreg 9mo ago
  That does not explain why they plan to continue writing it in C++.

panstromek 9mo ago

> There must be a really good reason for this, such as Rust doesn’t interop well with C++ Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction. This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it). If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/ https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.