Comment by drnick1
7 days ago
Not too surprising. Swift is too tied to Apple and it's not really clear what the benefit would be relative to a subset of C++ written with contemporary memory safety practices. It's a battle tested choice and pretty much every browser actually in use is written in C++.
> It's a battle tested choice and pretty much every browser actually in use is written in C++.
Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
> Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
Quickly followed by several vulnerabilities in that reference library as well; good move
TBF that's less a C++ thing and more that there have been several high profile decoder vulnerabilities over the past however many years. Enough that Google created the custom language WUFFS for the express purpose of implementing secure parsers for arbitrary file formats.
It's emblematic of C++ devs penchant for not implementing error handling on invalid input because of the "safety net" of exceptions and not bothering to properly handle errors or exceptions.
It's probably okay to solve one problem at a time: first solve the "free open source browser, developed from the Web standard specs" problem in an established language (C++), and then the "reimplement all of part of it in a more suitable (safer, higher productivity) language - yet to be devised - problem.
And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.
Maybe? I feel like there's been lots of efforts to migrate large C++ codebases over the years, and few actually complete the migration. Heck, Google is even making Carbon to try to solve this.
3 replies →
> a subset of C++ written with contemporary memory safety practices
What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)
> What is this mythical subset of C++
Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST: https://github.com/SerenityOS/serenity/blob/master/Documenta...
You see this reflected all the way back to the main function. Here is the main entry function for the entire browser:
ErrorOr<int> ladybird_main(Main::Arguments arguments).
https://github.com/LadybirdBrowser/ladybird/blob/master/UI/Q...
If Ladybird is successful, I would not be surprised to see its standard library take off with other projects. Again, it is really the SerenityOS standard library but the SerenityOS founder left the project to focus on Ladybird. So, that is where this stuff evolves now.
So interesting to hear about the internals of the browser, how it evolved from a standard library in an OS project. It's the kind of insight that's rarely documented, spoken about, or even known to anybody other than the author.
I can totally imagine how a prolific and ambitious developer would create a world of their own, essentially another language with domain-specific vocabulary and primitives. People often talk about using a "subset of C++" to make it manageable for mortals, and I think the somewhat unusual consideration of Swift was related to this desire for an ergonomic language to express and solve the needs of the project.
They probable mean safe code like this:
memory safety isn't really much of a problem with modern C++. We have the range library now for instance. What's nice about modern C++ is you can almost avoid most manual loops and talk at the algorithm level.
Are we talking about the same range library? The one that showed up in C++20 and is basically just iterator pairs dressed up nicely? The one where somehow the standard thought all memory safety issues with iterations could be summed up with a single “borrowed” bit? The one where instead of having a nice loop you can also build a little loop body pipeline and pass it as a parameter and have exactly the same iterator invalidation and borrowing problems that C++ has had since day 1?
Ranges are not memory safe. Sorry.
And yet in practice, it's been less than a week since a major CVE in Chromium due to memory unsafety: https://chromereleases.googleblog.com/2026/02/stable-channel...
Having a checklist of "things not to do" is historically a pretty in effectiveway to ensure memory safety, which is why the parent comment was asking for details. The fact that this type of thing gets dismissed as a non-issue is honestly a huge part of the problem in my opinion; it's time to move on from pretending this is a skill issue.
Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?
Only parts of it. Servo is the engine written in Rust, some of which ended up in Mozilla.
Firefox has some Rust components but it isn't written in Rust overall. Servo is written in Rust but it isn't a full browser.
Servo is slowly but steadily getting there. The thing with Servo is that it's highly modularized and some of its components are widely used by the larger Rust ecosystem, even it the whole browser engine isn't. So there's multi-pronged vested interest in developing it.
Moreover, Servo aims to be embeddable (there are some working examples already), which is where other non-Chrome/ium browsers are failing (and Firefox too). Thanks to this it has much better chance at wider adoption and actually spawning multiple browsers.
2 replies →
Mozilla laid off the Servo team years ago.
Servo was passed onto Linux Foundation and is still being developed, some of its components are shared with Firefox.
8 replies →
Yes and yes. Firefox is partially written in Rust.
Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).
Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
[dead]
It wasn't the reason why it was removed, but, well we agree, it would have been a problem if used indiscriminately. I didn't do any additional research, but what I read in public was simply "Ladybird is going to use Swift".