Obviously there are many types of security vulnerabilities, but one thing that should start paying off for Ladybird eventually is the move to a memory and race safe language (Swift). Of course, that will be a gradual process (they haven't really started yet and they will be using the Swift C++ interop so there will be C++ parts of the browser for years to come).
They do also benefit from using off-the-shelf libraries like Skia, OpenSSL, image libraries etc. that the other browsers are using too. Previously they were rolling their own for everything but changed after the split from SerenityOS.
I don't think they'd use Swift for GUI building. Ladybird's GUI's are platform-dependent (Qt on Linux, AppKit on Mac, etc). From what I understand they want to use Swift as a replacement for C++.
I haven't done a lot of Swift, but I did play around with it recently, and it seems to work fine even outside of the Apple ecosystem. It has a LSP you can use so you don't need XCode, they even develop a first-class plugin for VSCode.
The idea of a future where Swift can be productive on non-Apple systems is definitely in place. The reality is that it will be several years before the tooling is mature enough to consider for time/cost sensitive endeavours. That is, if Apple maintains their interest in that direction by then.
> It isn't as if Swift developer experience is that great outside Apple's ecosystem.
I keep hearing this - and have for years - but is it actually still true? Sure, you're never going to get Cocoa on non-Apple platforms, but with first-party VS Code support and a lot of the surrounding tooling open-sourced, is it all still [~that much worse than XCode~] as bad as all that?
Yes, unless you only care about doing CLI applications using the standard library, or having something to be Webserver endpoint.
Naturally most packages on the ecosystem assume libraries that don't exist outside Apple ecosystem.
Just like in the early .NET Core days, there were tons (and still are, hence businesses stuck in .NET Framework) that were actually wrappers to DLLs and COM based libraries.
Even Swift website acknowledges that the best use cases are command line and server stuff, the sweet spot is for server side applications for developers on Apple ecosystem, after all macOS servers are no longer something Apple sells.
They do also benefit from using off-the-shelf libraries like Skia, OpenSSL, image libraries etc. that the other browsers are using too. Previously they were rolling their own for everything but changed after the split from SerenityOS.