[seaal]

Seems like most nerds that are looking for an alternative browser engine are instead moving towards Ladybird.

Last year they passed Servo in WPT and recently passed Servo in stars.

As of January, Ladybird has been able to successfully render Gmail[0], so I imagine this year it will be able to solve most users daily-driver requirements.

[0] https://www.youtube.com/watch?v=-l8epGysffQ

[neilv]

Interesting. Has Ladybird solved memory bugs somehow, or is the situation going to be the usual constant security vulnerabilities and frequent security updates?

I have mixed feelings about Rust, but it's one way to improve the current culture of tolerating numerous memory defects in C and C++ desktop application programs and userland libraries. So that would be a point in Servo's favor, unless they've Rusted themselves into a borrowing/lifetimes/async development complexity corner that makes moving forward too slow.

[zamalek]

I haven't seen anything on memory vulnerability issues. The project originated within a larger project to implement an operating system from scratch - including all dependencies (e.g. font parsing/shaping, image parsing, libc, you name it). That means that the project itself, and every single one of its dependencies, need to go through that whole cycle.

[nicce]

> I haven't seen anything on memory vulnerability issues.

The issue is that barely nobody uses the Ladybird yet, so there are zero interests for anyone serious party to test that security. So nothing gets published about the issues. I don't even know if Ladybird runs in Google's Clusterfuzz.

Memory safety is their long term plan (according to them), and they are going to use Swift for that. Let's see what happens.

[neilv]

Has/will Swift be sufficiently disentangled from Apple influence?

And is this redirecting open source in an essentially proprietary direction (which has happened many times), on the key piece of software that is the Web browser?

Why I'm asking: For a startup, I've used Swift (and SwiftUI, various Apple APIs, "entitlements", developer-hostile App Store experience, often nonexistent documentation). The core language is OK overall (not great). But most of the rest of the developer experience was awful, due to Apple. And you need a lot of pieces beyond the core language.

Ultimately, the people who fund/do the work get to decide how they do it.

I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.

[ndiddy]

> I personally wouldn't invest in increasing open source adoption of an Apple property like that, unless someone has a compelling new argument for that.

See here for his reasoning for picking Swift: https://x.com/awesomekling/status/1822236888188498031

> Over the last few months, I've asked a bunch of folks to pick some little part of our project and try rewriting it in the different languages we were evaluating. The feedback was very clear: everyone preferred Swift!

> First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.

> Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.

> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.

[nicce]

Here is a lot of discussion about the same concerns: https://news.ycombinator.com/item?id=41208836