Closing this as we are no longer pursuing Swift adoption

As someone who first began using Swift in 2021, after almost 10 years in C#/.NET land, I was already a bit grumpy at how complex C# was, (C# was 21 years at that point), but then coming to Swift, I couldn't believe how complex Swift was compared to C# - Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than C#?

And this was me trying to use Swift for a data access layer + backend web API. There's barely any guidance or existing knowledge on using Swift for backend APIs, let alone a web browser of all projects.

There's no precedent or existing implementation you can look at for reference; known best practices in Swift are geared almost entirely towards using it with Apple platform APIs, so tons of knowledge about using the language itself simply cannot be applied outside the domain of building client-running apps for Apple hardware.

To use swift outside its usual domain is to become a pioneer, and try something truly untested. It was always a longshot.

The commit removing Swift has a little bit more detail:

    Everywhere: Abandon Swift adoption

    After making no progress on this for a very long time, let's acknowledge
    it's not going anywhere and remove it from the codebase.

Regardless of the language it is written in, one thing that I hope Ladybird will focus on when the time comes is a user-respecting Javascript implementation. Regardless of what the Web standards say, it is unacceptable that websites can (ab)use JS against the users for things such as monitoring presence/activity, disabling paste, and extracting device information beyond what is strictly necessary for an acceptably formatted website. One approach could be to report standardized (spoofed) values across the user base so that Ladybird users are essentially indistinguishable from each other (beyond the originating IP). This is more or less the approach taken by Tor, and where a project like Ladybird could make a real difference.

That's interesting, what happened? They don't explain it there.

For the record, I don't have a dog in this fight. As long as it runs on Linux, I'm willing to test drive it when it's ready.

Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?

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

Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? If they're going to go to the trouble of adding another language, does Rust not have a better history of C++ interop? Not to mention, Swift's GC doesn't seem great for the browser's performance.

Their Mac UI is a thin layer of AppKit. Even there they're currently using Objective-C++ it looks like, not Swift:

https://github.com/LadybirdBrowser/ladybird/tree/master/UI/A...

I remember mocking the switch to Swift back then.

Swift is a poorly designed language, slow to compile, visibly not on path to be major system language, and they had no expert on the team.

I am glad they are cutting their losses.

[dead]

When does the migration to Rust start? /s

[flagged]

[flagged]

I hate to be the one to point this out but really, in 10 years, how many rust ports will face the same fate?

Great, some languages do not need to be hack into a project.

There's no way to say this without sounding mean: Everything Chris Lattner has done has been a "successful mess". He's obviously smart, but a horrible engineer. No one should allow him to design anything.

Edit: I explained my position better below.

Hard to feel excited for this project when it feels so handwavey and when basic technical decisions have never been nailed down.

What are other projects trying something similar that deserve attention?