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.
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.
I started using it around 2018. After being reasonably conversant in Objective-C, I fully adopted Swift for a new iOS app and thought it was a big improvement.
But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."
But then: "Have one source of truth." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts.
A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.
In the last years, simplistic languages such as Python and Go have “made the case” that complexity is bad, period. But when humans communicate expertly in English (Shakespeare, JK Rowling, etc) they use its vast wealth of nuance, shading and subtlety to create a better product. Sure you have to learn all the corners to have full command of the language, to wield all that expressive power (and newcomers to English are limited to the shallow end of the pool). But writing and reading are asymmetrical and a more expressive language used well can expose the code patterns and algorithms in a way that is easier for multiple maintainers to read and comprehend. We need to match the impedance of the tool to the problem. [I paraphrase Larry Wall, inventor of the gloriously expressive https://raku.org]
same. i thought it would have been as quick to pick up as rust. nowhere near. i spent weeks trying to go through every feature of the language at least once. time in which i could’ve read several rust books and already start hacking up some interesting projects. so much in swift is pointless syntax sugar. why do i need 50 ways to do exactly the same thing, it’s just nonsense. then i have to look up the language reference whenever i read a new 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.
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.
> Why did Ladybird even attempt this with Swift, but (I presume) not with Rust? I
Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.
Andreas Kling said Rust lacks OO, which he says is useful for GUI coding.
He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps
felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.
I so wholeheartedly agree. You are making a new web browser - akin to a new OS - and you want it open source for everybody but you choose swift not rust?
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++.
For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term.
It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.
Swift never felt truly open source either. That people can propose evolution points doesn’t change the fact that Apple still holds all the keys and pushes whatever priorities they need, even if they’re not a good idea (e.g. Concurrency, Swift Testing etc)
Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.
Swift has it's problems, and I certainly wouldn't use it for anything outside of development for Apple platforms, but saying they had no experts on the team is a stretch. Most Swift leads were highly regarded members of the C++ world, even if you discount Chris Lattner.
The point of Swift is not really the language, it's the standard ABI for dynamic code. The Rust folks should commit to supporting it as a kind of extern FFI/interop alongside C, at least on platforms where a standard Swift implementation exists.
Rust bros already on their way to vibecode a rustbrowser, get their rust stars on rusthub, insult anyone to point out it doesn’t work, and call it a rustday.
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.
What projects are trying something similar to Ladybird? Well, mobody really. But Servo is pretty close though they are not writing their own Javascript engine or anything.
But you should perhaps give your attention to Servo. They were founded as a project to write a modern browser in Rust. So, no hand-waving there.
No hand-waving on the Ladybird team either in my opinion. They have very strong technical leadership. The idea that building a massive application designed to process untrusted user input at scale might need a better language than C++ seems like a pretty solid technical suggestion. Making incedible progress month after month using the language you started with seems pretty good too. And deciding, given the progress buidling and the lack of progress exploring the new language, that perhaps it would be best to formally abandon the idea of a language switch...well, that seems like a pretty solid decision as well.
At least, that is my view.
Oh, and I was a massive Servo fan before the Ladybird project even began. But, given how much further Ladybird has gotten than Servo has, despite being at it for less time and taking on a larger scope...well, I am giving my attention to Ladybird these days.
[+] [-] incognitojam|1 month ago|reply
[+] [-] IMcD23|1 month ago|reply
https://github.com/LadybirdBrowser/ladybird/issues/933
[+] [-] miffy900|1 month ago|reply
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.
[+] [-] VerifiedReports|1 month ago|reply
But there's a lot of hokey, amateurish stuff in there... with more added all the time. Let's start with the arbitrary "structs are passed by value, classes by reference." And along with that: "Prefer structs over classes."
But then: "Have one source of truth." Um... you can't do that when every data structure is COPIED on every function call. So now what? I spent so much time dicking around trying to conform to Swift's contradictory "best practices" that developing became a joyless trudge with glacial progress. I finally realized that a lot of the sources I was reading didn't know WTF they were talking about and shitcanned their edicts.
A lot of the crap in Swift and SwiftUI remind me of object orientation, and how experienced programmers arrived at a distilled version of it that kept the useful parts and rejected dumb or utterly impractical ideas that were preached in the early days.
[+] [-] librasteve|1 month ago|reply
[+] [-] belmont_sup|1 month ago|reply
[+] [-] i_am_a_peasant|1 month ago|reply
[+] [-] fud101|1 month ago|reply
[+] [-] drnick1|1 month ago|reply
[+] [-] WCSTombs|1 month ago|reply
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.
[+] [-] meisel|1 month ago|reply
[+] [-] mlinksva|1 month ago|reply
[+] [-] diath|1 month ago|reply
Probably the same reason why Rust is problematic in game development. The borrow checker and idiomatic Rust do not go well together with things that demand cyclic dependencies/references. Obviously there are ways around it but they're not very ergonomic/productive.
[+] [-] lukeh|1 month ago|reply
[1] https://www.swift.org/documentation/cxx-interop/
[+] [-] jll29|1 month ago|reply
He even made an attempt at creating his own language, Jakt, under SerenityOS, but perhaps felt that C++ (earlier with, now without Swift) were the pragmatic choice for Ladybird.
[+] [-] password4321|1 month ago|reply
20240810 https://news.ycombinator.com/item?id=41208836 Ladybird browser to start using Swift language this fall
[+] [-] gardaani|1 month ago|reply
- Excellent for short-lived programs that transform input A to output B
- Clunky for long-lived programs that maintain large complex object graphs
- Really impressive ecosystem
- Toxic community
https://x.com/awesomekling/status/1822241531501162806
[+] [-] bergheim|1 month ago|reply
[+] [-] carefree-bob|1 month ago|reply
[+] [-] elcritch|1 month ago|reply
[+] [-] generalpf|1 month ago|reply
[+] [-] ozgrakkurt|1 month ago|reply
[+] [-] sparky4pro|1 month ago|reply
[+] [-] drnick1|1 month ago|reply
[+] [-] WoodenChair|1 month ago|reply
https://github.com/LadybirdBrowser/ladybird/tree/master/UI/A...
[+] [-] alper|1 month ago|reply
[+] [-] losvedir|1 month ago|reply
[+] [-] hypeatei|1 month ago|reply
[+] [-] throwaway27448|1 month ago|reply
[+] [-] refulgentis|1 month ago|reply
It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.
[+] [-] stephc_int13|1 month ago|reply
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.
[+] [-] isodev|1 month ago|reply
Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.
[+] [-] WaldoDude|1 month ago|reply
[+] [-] zozbot234|1 month ago|reply
[+] [-] TbobbyZ|1 month ago|reply
[+] [-] fud101|1 month ago|reply
[+] [-] kittbuilds|1 month ago|reply
[deleted]
[+] [-] upmind|1 month ago|reply
[+] [-] densh|1 month ago|reply
[+] [-] weedhopper|1 month ago|reply
[+] [-] qewartysuc|1 month ago|reply
[deleted]
[+] [-] KingMob|1 month ago|reply
[deleted]
[+] [-] gethly|1 month ago|reply
[deleted]
[+] [-] polliog|1 month ago|reply
[deleted]
[+] [-] noobermin|1 month ago|reply
[+] [-] xannabxlle|1 month ago|reply
[+] [-] pbohun|1 month ago|reply
Edit: I explained my position better below.
[+] [-] nylonstrung|1 month ago|reply
What are other projects trying something similar that deserve attention?
[+] [-] LeFantome|1 month ago|reply
But you should perhaps give your attention to Servo. They were founded as a project to write a modern browser in Rust. So, no hand-waving there.
No hand-waving on the Ladybird team either in my opinion. They have very strong technical leadership. The idea that building a massive application designed to process untrusted user input at scale might need a better language than C++ seems like a pretty solid technical suggestion. Making incedible progress month after month using the language you started with seems pretty good too. And deciding, given the progress buidling and the lack of progress exploring the new language, that perhaps it would be best to formally abandon the idea of a language switch...well, that seems like a pretty solid decision as well.
At least, that is my view.
Oh, and I was a massive Servo fan before the Ladybird project even began. But, given how much further Ladybird has gotten than Servo has, despite being at it for less time and taking on a larger scope...well, I am giving my attention to Ladybird these days.
This comment was written in Ladybird.
[+] [-] tredre3|1 month ago|reply
Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...