Andreas Kling aka @awesomekling wrote:
We’ve been evaluating a number of C++ successor languages for @ladybirdbrowser , and the one best suited to our needs appears to be @SwiftLang 🪶
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!
Why do we like 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.
Strong ties to Apple?
Swift has historically been strongly tied to Apple and their platforms, but in the last year, there’s been a push for “swiftlang” to become more independent. (It’s now in a separate GitHub org, no longer in “apple”, for example).
Support for non-Apple platforms is also improving, as is the support for other, LSP-based development environments.
What happens next?
We aren’t able to start using it just yet, as the current release of Swift ships with a version of Clang that’s too old to grok our existing C++ codebase. But when Swift 6 comes out of beta this fall, we will begin using it!
No language is perfect, and there are a lot of things here that we don’t know yet. I’m not aware of anyone doing browser engine stuff in Swift before, so we’ll probably end up with feedback for the Swift team as well.
I’m super excited about this! We must steer Ladybird towards memory safety, and the first step is selecting a successor language that we can begin adopting very soon. 🤓🐞
Really feels like a mistake. No major language exists without a major benefactor supporting it, and Swift’s only benefactor has zero interest in cross platform anything.
Good luck 5 years from now when cross platform Swift has gone the way of cross platform Safari.
Actually, this isn’t true. Apple has a vested interest in cross platform Swift. They’ve been pushing hard for Swift on Linux because they want Swift to run on servers, and they’re right to. Look at how hard JavaScript dominates on the server-side because of one language everywhere.
So the Ladybird browser will have no trouble running on Linux servers? Great! Now how about platforms where people use web browsers? i.e. Android, and Windows… Apple has no vested interest in cross platform support to platforms that matter for a web browser.
Swift already works on Android and Windows. The support for Windows is improving and on the way to being official instead of questionable. The Browser Company is already building their app on Windows with Swift.
Swift’s governance has had some bumps in the past but is improving. Apple does have a vested interest in Swift adoption outside of their platforms. The more popular it is in general, the better the community and ecosystem get.
https://swift.org/
That same page lists cross-platform CLI and server as intended use cases.
That’s actually interesting, I learned something new today.
Will Ladybird compete against lynx? …No? I tried. Jokes aside, I don’t see why that’d matter much for end-users.
It looks to me like Apple wants Swift on Linux, but that might simply be because they understand you can’t run away from Linux when dealing with servers. That’s not necessarily the same as wanting to create a cross-platform (read: greater than Apple and Linux) ecosystem.
The text you quote literally appears under the heading “Apple Platforms”. Gee, why don’t they mention anybody else in the Apple section?
Immediately below that, there is a cross-platform section where they say “SwiftArgumentParser and Swift’s growing package ecosystem make developing cross-platform command-line tools a breeze.”
So, at worst, it sounds like the main Swift project may leave you to heft some of the GUI load yourself. Except 99% of what Ladybird does is under the hood processing that creates bitmaps for display. There is hardly any GUI really. Plus, Swift offers C++ interop.
Ladybird stems from SerenityOS where they write everything themselves. They have their own networking, GUI libraries, and crypto. Since splitting, they have adopted font rendering and media libraries from other projects ( largely available as C code I believe ).
Swift is cross-platform in all the ways the Ladybird gang needs it to be. It uses LLVM ( very cross-platform ) and the Swift compiler is meant to be cross-platform. All that will evolve and improve independent of Ladybird itself. The Ladybird team does not need many libraries from the Swift ecosystem. What they will need is pretty basic and fundamental.
Think back to Rust and Mozilla. When Mozilla rewrote the CSS parser in Rust, how much GUI rework was required? None? The CSS parser fell into the space defined by “command-line tools”.
It is compiled with LLVM and Clang. Where is the danger of losing cross-platform compatibility? It will be fine.
Also, Safari on Windows had low usage, and was probably a pain to maintain. Swift cross platform is more about abstracting out Apple specific things (like the standard library and UI toolkit). Apple has already been investing multi-year efforts into Swift on the server for longer than Safari on Windows existed. The last couple versions of Swift (~3-4years of development) have been almost entirely focused on safe concurrency, which is intended for server-side development.
I’m 90% sure the entire reason was that it would force all web developers who wanted to target iOS to buy Macs since that’s the only place you could then test against Safari / Webkit.
That doesn’t mean they’ve invested anything in getting it running on consumer operating systems.
Well that was a bad idea. I don’t test nothing for Safari and the bugs it causes on my app are always a pain in the ass for users. Gotta make them regret their choice
Apple is still very vested in the success of Swift overall and also friendly to the cross-platform agenda.
What significant beneficiary is backing Rust?
At a deeper level, they both heavily lean on LLVM which of course is heavily supported by many players ( including Apple ) and which is also deeply cross-platform.