Top
Best
New

Posted by adius 16 hours ago

Ladybird adopts Rust(ladybird.org)
1081 points | 591 commentspage 4
MontagFTB 11 hours ago|
Any word on how much more memory safe the implementation is? If passing a previous test suite is the criteria for success, what has changed, really? Are there previous memory safety tests that went from failing to passing?

I am very interested to know if this time and energy spent actually improved memory safety.

Other engineers facing the same challenges want to know!

Retr0id 11 hours ago||
If the previous impl had known memory safety issues I'd imagine they'd fix them as a matter of priority. It's hard to test for memory safety issues you don't know about.

On the rust side, the question is how much `unsafe` they used (I would hope none at all, although they don't specify).

estebank 11 hours ago|||
You can look: https://github.com/LadybirdBrowser/ladybird/pull/8104/files?...

It seems like it is used mostly for FFI.

MontagFTB 11 hours ago|||
It is entirely possible a Rust port could have caught previously unknown memory safety issues. Furthermore, a Rust port that looks and feels like C++ may be peppered with unsafe calls to the point where the ROI on the port is greatly reduced.

I am not trying to dunk on the effort; quite the contrary. I am eager to hear more about the goals it originally set out to achieve.

Perz1val 6 hours ago||
None at all, the generated AST and bytecode are stated to be identical
jvillasante 15 hours ago||
> We’ve been searching for a memory-safe programming language to replace C++ in Ladybird for a while now.

The article fails to explain why. What problems (besides the obvious) have been found in which "memory-safe languages" can help. Do these problems actually explain the need of adding complexity to a project like this by adding another language?

I guess AI will be involved which, at this early point in the project would make ladybird a lot less interested (at least to me).

michaelcampbell 15 hours ago||
> What problems (besides the obvious) have been found in which "memory-safe languages" can help.

Why isn't that enough?

nicoburns 15 hours ago|||
Browsers are incredibly security-sensitive projects. Downloading untrusted code from the internet and executing is part of their intended functionality! If memory safety is needed anywhere it's in browsers.
VoxPelli 10 hours ago|||
Rust was pretty much created to help solve security issues in browsers: https://en.wikipedia.org/wiki/Rust_(programming_language)#20...
panstromek 15 hours ago|||
> besides the obvious

Well, what else is there besides the obvious? It's a browser.

the_duke 13 hours ago|||
Even Chrome has started to adopt Rust due to recurring memory vulnerabilities.... that's a big enough reason.
f311a 14 hours ago|||
You don't want a browser with a bunch of RCEs that can be triggered by opening a web page...
Perz1val 5 hours ago||
You do want a browser with RCE, but you want it to keep the it sandboxed. The hard part is executing the code safely
norman784 13 hours ago||
I guess you will need to wait for their Feb 2026 update.
artur-gawlik 9 hours ago||
Interesting in context of that some time ago Andreas said that they failed on porting TypeScript compiler from TypeScript itself to Go lang by using LLMs and they went with manual port https://youtu.be/uMqx8NNT4xY?si=Vf1PyNkg3t6tmiPp&t=1423
bgdkbtv 5 hours ago||
This may sound stupid, but I wonder if using GPUI for a web browser could have some performance benefits...
Narishma 3 hours ago|
I don't get the impression they care that much about performance. Besides, it would limit the number of platforms it could run on if it requires a recent GPU.
BirAdam 2 hours ago||
Using Rust means they’ve limited the number of platforms already… so I doubt they care.
worldsavior 15 hours ago||
Good step. It will bring many more contributors.
mghackerlady 13 hours ago||
That's a pivot, iirc they wanted to swift (I'm very glad they didn't do that). It's cool to see something like claude be useful for large scale projects like that
zozbot234 15 hours ago||
Using LibJS with servo, when?
drnick1 10 hours ago||
I wonder what is gained by this port though, if the C++ codebase already employed modern approaches to memory management. It's entirely possible that the Rust version will perform worse too as compilers are less mature.
maleldil 8 hours ago|
"modern approaches to memory management" aren't enough for complete memory safety.
drnick1 8 hours ago||
Maybe, but it's certainly possible to write memory safe code in C++. It may be more or less difficult, but it isn't typically the ONLY objective of a project. C++ has other advantages too, such as seamless integration with C APIs and codebases, idiomatic OOP, and very mature compilers and libraries.
rausr 15 hours ago||
I must admit to being somewhat confused by the article's claim that Rust and C++ emit bytecode. To my knowledge, neither do (unless they're both targeting WASM?) - is there something I'm missing or is the author just using the wrong words?

EDIT: bramhaag pointed out the error of my ways. Thanks bramhaag!

bramhaag 15 hours ago||
By 'Rust compiler' and 'C++ compiler', they refer to the LibJS bytecode generator implemented in those languages. This is about the generated JS bytecode.
rausr 15 hours ago|||
Yes, I re-read again, and I think you are correct. Thanks!
mdavid626 12 hours ago|||
Thanks! I was confused about this as well.
xwowsersx 15 hours ago|||
They're referring to LibJS's bytecode (the internal instruction stream of Ladybird’s JS engine), not to Rust/CPP output formats.
onetom 9 hours ago|
Were there any immediate benefits of this conversion, e.g. reduced memory use or lower CPU utilization?
GalaxyNova 6 hours ago|
Likely the opposite, as safe Rust has some extra safety checks for things like array bounds.
More comments...