Hacker News Reader

Comment by drnick1 | Hacker News Reader

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++.

View on HN

> 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.

migrating any large project is going to be billions of dollars worth of labor. Language isn't a large factor in that cost, you can save few tens of millions at most with a better language.

Can you give me some reasoning behind this statement ("language isn't a large factor in the cost of migrating a large project")?

I'm struggling to think of a larger factor

The large factor is the amount of work to create everything again. Plenty has been written about large re-writes, they can and have worked out in the long run, but generally it takes a decade for the new to be as good as the old - either it is missing critical features or it has too many bugs.

> 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:

    class FontFeatureValuesMapIterationSource final
    : public PairSyncIterable<CSSFontFeatureValuesMap>::IterationSource {
    public:
    FontFeatureValuesMapIterationSource(const CSSFontFeatureValuesMap& map,
                                      const FontFeatureAliases* aliases)
      : map_(map), aliases_(aliases), iterator_(aliases->begin()) {}

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.

> 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.

Alas not nearly as modularized as it could be. I think it's mainly just Stylo and WebRender (the components that got pulled into Firefox), and html5ever (the HTML parser) that are externally consumable.

Text and layout support are two things that could easily be ecosystem modules but aren't seemingly (from my perspective) because the ambition to be modular has been lost.

I've seen recent talk about swappable js engine, so I'm unsure about the ambition being lost. I'm eyeing Blitz too (actually tried to use it in one of my projects but the deps fucked me up).

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.

Yet, after all these years its browser is quite frankly pre-historic.

Servo's history is much more complicated and originally was planned to be used for the holo lens before the layoff. Comparing trajectory doesn't make sense they had completely different goals and directions.

What are you talking about? It doesn't have a "browser", it has a testing shell. For a time there was actual attempt with the Verso experiment but it got shelved just recently. Servo is working at being embeddable at the same time when Rust GUI toolkits are maturing. Once it gets embedding stabilized that will be the time for a full blown browser developement.

> It doesn't have a "browser", it has a testing shell.

So, yes it is still pre-historic.

> Once it gets embedding stabilized that will be the time for a full blown browser developement.

Servo development began in 2012. [0] 14 years later we get a v0.0.1.

At this point, Ladybird will likely reach 1.0 faster than Servo could, and the latter is not even remotely close to being usable even in 14 years of waiting.

[0] https://en.wikipedia.org/wiki/Servo_(software)

> At this point, Ladybird will likely reach 1.0 faster than Servo could, and the latter is not even remotely close to being usable even in 14 years of waiting.

When Servo is done, it's going to be a beast.

It's getting hundreds of commits per week:

https://github.com/servo/servo/graphs/commit-activity

It's by no means accurate, but the comparative histories of Ladybird vs. Servo sure has some parallels with Linux vs. GNU Hurd.

This is disingenuous. Servo is using RUST, language which grew together with it, pretty much, and all components surrounding it. C++ is how old, please remind me?

You could make almost any non-C non-C++ project good by that metric.

And no, they're not being disingenuous.

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.)

Reply on news.ycombinator.com