Ladybird no longer pursuing adoption of the (memory safe) Swift language

   Everywhere: Abandon Swift adoption

   After making no progress on this for a very long time, let's acknowledge
   it's not going anywhere and remove it from the codebase.
1 Like

Well that’s incredibly disappointing.

11 Likes

Not to be the “rewrite in Rust” guy, but this really seemed like a Rust project. Not sure why Swift would have been chosen, especially without a strong Swift lead seeing the migration effort. Another C++ browser doesn’t seem like the ideal secure future.

9 Likes

In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop.

https://xcancel.com/i/status/1822239138038382684

6 Likes

Rust isn’t a silver bullet against programming errors, and memory safety bugs are only a relatively small part of critical vulnerabilities. C++ is a battle-tested choice for software of this scale, and has arguably better ergonomics than Rust such as true OOP. Most importantly, the project already consists of half a million lines of C++ and the authors are experts at it.

1 Like

For what it’s worth Servo seems to be attempting to fill the same niche as Ladybird, but is actually written in Rust.

5 Likes

Unfortunately, they are not progressing nearly as quickly and presumably are having to share a small slice of the same funding pie as Ladybird.

2 Likes

Not true. They make up the majority of critical vulnerabilities now.

https://media.defense.gov/2025/Jun/23/2003742198/-1/-1/0/CSI_MEMORY_SAFE_LANGUAGES_REDUCING_VULNERABILITIES_IN_MODERN_SOFTWARE_DEVELOPMENT.PDF

4 Likes

You are free to write your own browser in Rust if the benefits are so clear, or to port Ladybird. Let us know how far you get. (My point is that the developers are aware of such options and tradeoffs, and I have chosen not to take this path for a reason.)

1 Like

citation needed?

Google’s Project Zero reports that memory safety vulnerabilities—security defects caused by subtle coding errors related to how a program accesses memory—have been “the standard for attacking software for the last few decades and it’s still how attackers are having success”. Their analysis shows two thirds of 0-day exploits detected in the wild used memory corruption vulnerabilities.

Known mercenary spyware chains used against iOS share a common denominator with those targeting Windows and Android: they exploit memory safety vulnerabilities, which are interchangeable, powerful, and exist throughout the industry.

4 Likes

It will make more sense to use CHERI when it becomes widely available rather than rewriting battle-tested software anyways.

But right now, Ladybird is writing yet another C++ browser. If they aren’t even pursuing memory safety as a USP compared to existing browsers, then what is their reason for existing?

If it’s solely for ideological reasons, then Servo is also in development while being written in memory-safe Rust, so that point is largely moot, in my opinion.

6 Likes

Aren’t 70% of critical bugs caused by memory problems?

4 Likes

I don’t personally like Rust, but try reading some of the Firefox C++ code. It would have been nice to have a browser attempt something different compared to the C++ mess we already have in existing browsers.

4 Likes

Well that’s a bummer, but I can’t say that I’m surprised. After all the browser is already very advanced and they want to make a first public alpha release for 2026 so they must have a decent browser by then and that would never happen if they rewrote the whole thing in rust. Despite being yet another C++ web browser, it is still a new performance, free of ads forever, free of AI, free of a company leading the project that can turn bad, so as a user of browsers it is always good to have more choice and I’m still very interested in their project! Many software you install on your computer are written in C/C++ anyway so the memory unsafe language problem is still going to be around for a while with or without ladybird.

2 Likes

My reply was better answered from the linked rationale by @any1

And yes, porting to a new language is always a crapshoot at a project of their size. But from my biased view, Swift just doesn’t have the same number of eyes on it as a systems language as Rust does, and therefore necessary support for complex build needs they ran into, even if those needs weren’t met in Rust initially. But this is also me (and everyone else here) arm chair rationalizing from afar, and Rust may never have actually been viable, and really just banter honestly. Hence why I find:

a poor faith argument, and rude.

4 Likes