Top
Best
New

Posted by adius 14 hours ago

Ladybird adopts Rust(ladybird.org)
1040 points | 570 commentspage 3
jonkoops 11 hours ago|
I hope that this opens the door for collaboration between Ladybird and Servo, no need to reinvent the wheel for core components.
jabl 11 hours ago||
I thought the entire point of Ladybird was precisely to reinvent the wheel?
jonkoops 10 hours ago||
This is also the case for Servo, so it makes sense to collaborate.
VoxPelli 8 hours ago||
Servo has a distinct design goal that sets it apart from its predecessor within Mozilla and has already had offsprings that has made its way directly into Firefox.

Its purpose is not to reinvent everything. It’s not a hype project.

nicoburns 11 hours ago|||
Unfortunately licence incompatibility may prevent that. Ladybird is BSD and Servo is MPL. This is also why there is only limited collaboration between Servo and the Rust GUI ecosystem.
mudkipdev 11 hours ago||
Commenting about not reinventing the wheel on a Ladybird post is ironic
storus 5 hours ago||
This is really YOLOing as the original author doesn't know Rust well so what happens if they hit some complex production issue LLM aren't aware of? Hiring an expensive consultant to fix that until the next LLM iteration?
drakythe 4 hours ago||
I'm as anti LLM use as they come, but this appears to be migrating libraries from already funcitoning C++ code. In the case of your hypothetical I suspect the course of action will be "shelve this library port until someone with domain expertise and Rust experience can look at it". Its not like he chucked the whole codebase at the GenaI gods and said "Port it to Rust!".
etcetera1 5 hours ago||
> what happens if they hit some complex production issue

they learn Rust

it takes a couple of years

it's not that hard.

cbondurant 12 hours ago||
Based on the origins of Rust as a tool for writing the really thorny, defensive parsers of potentially actively hostile code for firefox, I have to imagine that another web browser is the most at-home place the language could ever be.
potato-peeler 13 hours ago||
Is there any discussion on why D or even Ada was not considered? These languages have been around for long time. If they were willing to use llm to break the initial barrier to entry for a new language, then a case can be made for these languages as well.
account42 13 hours ago||
They already made the mistake picking a niche language twice (first their own language, then Swift as a cross-platform language), why would you want them to make it a third time?
potato-peeler 12 hours ago|||
What kind of response is this? I was asking if there was any technical evaluation on other languages. And D and Ada are not niche. They have been battle tested in critical software.
Imustaskforhelp 12 hours ago|||
Swift had/has some problems in the language itself. It's not because of the niche nature of Swift that was the problem iirc.

I don't think this is the right response because certainly a meaningful discussion could've definitely taken place and given how they were already open to other languages which was the reason why they picked Swift in the first place.

I remember Andreas video where he talked about how people used rust in his codebase and they were so happy but later it became very difficult whereas they found with swift that it became easier to manage. That was the reason why they picked swift that time.

Certainly their goal wasn't to pick a popular language (because if that's what you want use python or JS) but rather a language that was relevant to what they were building.

So if D and Ada were relevant or not, that's the main point of discussion imo.

tgv 13 hours ago|||
I've dabbled a bit in Ada, but it wouldn't be my choice either. It's still susceptible to memory errors. It's better behaved than C, but you still have to be careful. And the tooling isn't great, and there isn't a lot in terms of libraries. I think Ladybird also has aspirations to build their own OS, so portability could also be an issue.
potato-peeler 12 hours ago||
Not the case with spark. But I understand it requires writing lot of things from scratch for browsers. But I don’t think portability will be an issue with Ada, it is cross platform.

However, this is where d shines. D has a mature ecosystem. Offers first class cpp abi and provides memory safety guarantees, which the blog mentioned as a primary factor. And d is similar to cpp, low barrier for cpp devs to pick up.

tgv 12 hours ago||
There's no dynamic memory allocation with (100%) Spark. That's really limiting. You can to write "unsafe" code, but that has the same problems as Ada.
Findecanor 3 hours ago|||
I thought SPARK got dynamic memory allocation when it adopted Rust-style ownership and borrowing in 2014.
potato-peeler 12 hours ago||||
That is true for parsers like libjs, but again crypto module or even networking, can still be written in spark, which is much more safety critical.
Rochus 12 hours ago|||
SPARK is not used for the whole system, but for the < 5% parts, which are safety/security-related in a good architecture.
yurishimo 13 hours ago|||
Probably contributing reasons? I imagine over time they will have a lot more Rust contributors than D or Ada.
Rochus 12 hours ago||
Unfortunately a really good question gets downvoted instead of causing a relevant discussion, as so often in recent HN. It would be really interesting to know, why Ada would not be considered for such a large project, especially now when the code is translated with LLMs, as you say. I was never really comfortable that they were going for the most recent C++ versions, since there are still too many differences and unimplemented parts which make cross-compiler compatibilty an issue. I hope that with Rust at least cross-compilation is possible, so that the resulting executable also runs on older systems, where the toolchain is not available.
potato-peeler 12 hours ago|||
Unfortunately some folks do get bit sensitive on rust, that can be off putting.

But what I wanted to know was about evaluation with other languages, because Andreas has written complex software.

His insight might become enriching as to shortcomings or other issues which developers not that high up in the chain, may not have encountered.

Ultimately, that will only help others to understand how to write better software or think about scalability.

Imustaskforhelp 12 hours ago|||
I personally think that people might've framed it as use Ada/D over rust comment which might have the HN people who prefer rust to respond with downvotes.

I agree that, this might be wrong behaviour and I don't think its any fault of rust itself which itself could be a blanket statement imo. There's nuance in both sides of discussions.

Coming to the main point, I feel like the real reason could be that rust is this sort of equilibra that the world has reached for, especially security related projects. Whether good or bad, this means that using rust would definitely lead to more contributor resources and the zeal of rustaceans can definitely be used as well and also third party libraries developed in rust although that itself is becoming a problem nowadays from what I hear from people in here who use rust sometimes (ie. too many dependencies)

Rust does seem to be good enough for this use case. I think the question could be on what D/Ada (Might I also add Nim/V/Odin) will add further to the project but I honestly agree that a fruitful discussion b/w other languages would've been certainly beneficial to the project (imo) and at the very least would've been very interesting to read personally

Rochus 12 hours ago||
> which might have the HN people who prefer rust to respond with downvotes.

This completely misses the purpose of the downvoting feature, which is not surprising, since upvoting seems no longer to indicate quality or truth of the comment neither.

> rust is this sort of equilibra that the world has reached for, especially security related projects

Which is amazing, since Rust only covers a fraction of safety/security concerns covered by Ada/SPARK. Of course this language has some legacy issues (e.g. the physical separation of interface and body in two separate files; we have better solutions today), but it is still in development and more robust than the C/C++ (and likely Rust) toolchain. And in the age of LLMs, robustness and features of a toolchain should matter more than the language syntax/semantics.

> Rust does seem to be good enough for this use case.

If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.

Imustaskforhelp 11 hours ago|||
> If you compare it to the very recend C++ implementations they are using, I tend to agree. But if you compare it to a much more mature technology like e.g. Ada, I have my doubts.

I agree with you in the sense that it would've definitely been interesting to read what Andreas thinks of Ada/D and the discussion surrounding it and your overall comment too.

I do wish that anyone from ladybird team/maybe even Andreas if he's on HN (not sure) could respond to the original query if possible.

I remember ladybird had a discord server I once joined, perhaps someone from the community could ask Andreas about it there if possible since It would be genuinely fascinating to read.

Although a point I am worried about is if Ladybird changes the language again let's say after a discussion of using Ada/D. It might be awkward.

Rochus 11 hours ago||
> I am worried about is if Ladybird changes the language again

In the time of good LLMs this is likely no longer a show-stopper (as e.g. the specific formating rules in C/C++ since there are good re-formating tools). The question is how long we will need programming languages at all. They were primarily invented because large assembler projects were too challenging for most people. But if all the complicated details can now be delegated to LLMs, strictly speaking, we no longer need programming languages either.

quesera 10 hours ago|||
> This completely misses the purpose of the downvoting feature

"Downvote for disagree" has been canonicalized on HN since (nearly) the beginning, by pg himself, back when he used his real-name account to comment. :)

I agree that it has undesirable consequences, but it is fully established.

bigstrat2003 9 hours ago|||
It's even worse than that. People are all too often willing to "flag for disagree". It's getting to be pretty common to see threads with comments that are [flagged][dead] which don't break the rules in any way, but merely express a view which is unpopular. Sometimes I even agree that it's a stupid position to take up, but that doesn't merit being flagged to death. I always vouch for those comments but it feels like an exercise in futility with so many people using the flag function as a "super fuck you" button.
Rochus 10 hours ago|||
Personally I would remove the downvote button entierly because apparently it is a lossy projection of an at least three-dimensional vector: agreement, quality, truth. Graying out text so it is no longer readable is a censoring measure not justified in most cases I encounter on HN in the eight years I'm here.
jvillasante 14 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 13 hours ago||
> What problems (besides the obvious) have been found in which "memory-safe languages" can help.

Why isn't that enough?

nicoburns 13 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 8 hours ago|||
Rust was pretty much created to help solve security issues in browsers: https://en.wikipedia.org/wiki/Rust_(programming_language)#20...
panstromek 13 hours ago|||
> besides the obvious

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

the_duke 11 hours ago|||
Even Chrome has started to adopt Rust due to recurring memory vulnerabilities.... that's a big enough reason.
f311a 12 hours ago|||
You don't want a browser with a bunch of RCEs that can be triggered by opening a web page...
Perz1val 4 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 12 hours ago||
I guess you will need to wait for their Feb 2026 update.
delduca 3 hours ago||
They are lost. C & C++ are absolutely fine.
npalli 11 hours ago||
If it is this easy, surely the trend is Rust output being an intermediate pass of the LLM super compiler. A security subset if you will (like other kinds of optimization), it will move from Rust specs to some deeper level of analysis and output the final executable. Some brave souls will read the intermediate Rust output (just like people used to read the assembler output from compilers) but the LLM super compiler will just translate a detailed English like spec into final executables.
Perz1val 4 hours ago|
Do you seriously think LLMs will not just spam unsafe blocks in it like they do with any task ever?
gpm 1 hour ago||
I'd generally be quite surprised to see LLMs spam unsafe blocks, both because that's behavior that I haven't observed while using them and because that contradicts my mental model of them where they imitate the styles of code that they were trained on (which in rust generally does not include spamming unsafe).
yanosc 14 hours ago||
If this means we will get an independent state-of-the-art browser engine, I'm all for it.
youngtaff 9 hours ago|
IMV Servo is going to be the independent state of the art browser
Perz1val 4 hours ago||
I have my doubts it'll ever be "finished". Servo gives strong vibes of a project that will avoid performance hacks, because they're not nice/state of the art code. I have no evidence, it's just the energy I've picked up from it
bgdkbtv 3 hours ago||
This may sound stupid, but I wonder if using GPUI for a web browser could have some performance benefits...
npn 8 hours ago|
My intuition is that they will convert to zig again when it stables. If it is possible to do it using LLM in 2 weeks for rust, then it would be the same for zig, too.

While rust is nice on paper, writting complex software in it is mentally consuming. You can not do it for a long time.

lukaslalinsky 8 hours ago|
If they are looking for a memory-safe language, why would they convert to Zig?
hu3 6 hours ago||
If they do, it could be because safety is a gradient and one variable among many in software development, albeit a very important one when it comes to browsers.
More comments...