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.
I think Swift was developed to keep a number of constituencies happy.
You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do).
A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me.
Been using it since 2014 (the day it was announced). I enjoy it.
There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.
> 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."
This is the same way that C# works and C and C++ why is this a surprise?
Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness.
You can also look at the source code for the language if any it’s confusing. It’s very readable.
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]
Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis!
Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable.
If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.
>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.
It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.
It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.
> Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.
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
well for backend development, yes - I technically never stopped as I had existing projects to maintain. But after trying out Swift a couple times, I've dropped it entirely for backend. For new backend work it's C#/.NET all the way.
I wanted to try using a native language other than C++ and Swift ostensibly seemed easier to pick up. I continue to use Swift for iOS app development though where it is much easier to use; but that has its own share of compromises and trade-offs - but not centred around Swift, around SwiftUI vs UIKit.
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.
There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.
If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. That being said, I find that most of the Web works just fine on Tor, so it's certainly possible. Most of the issues seem related to the (known) the exit IP being overused or identified as Tor.
It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it.
It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
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.
> Swift is strictly better in OO support and C++ interop
Fascinating.
They've shown the idea it is better on C++ interop is wrong.
I don't know enough to say Rust has same OO support as Swift, but I'm pretty sure it does. (my guess as a former Swift dev: "protocol oriented programming" was a buzzy thing that would have sounded novel, but amounted to "use traits" in rust parlance)
EDIT: Happy to hear a reply re: why downvotes, -3 is a little wild, given current replies don't raise any issues.
> 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 think that's fair. Funny to have a language that makes it prohibitively difficult to use most of the core computer science constructs (lists, graphs etc.).
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++.
> It's a battle tested choice and pretty much every browser actually in use is written in C++.
Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
> Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
Quickly followed by several vulnerabilities in that reference library as well; good move
TBF that's less a C++ thing and more that there have been several high profile decoder vulnerabilities over the past however many years. Enough that Google created the custom language WUFFS for the express purpose of implementing secure parsers for arbitrary file formats.
It's probably okay to solve one problem at a time: first solve the "free open source browser, developed from the Web standard specs" problem in an established language (C++), and then the "reimplement all of part of it in a more suitable (safer, higher productivity) language - yet to be devised - problem.
And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.
> a subset of C++ written with contemporary memory safety practices
What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)
Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST:
https://github.com/SerenityOS/serenity/blob/master/Documenta...
You see this reflected all the way back to the main function. Here is the main entry function for the entire browser:
If Ladybird is successful, I would not be surprised to see its standard library take off with other projects. Again, it is really the SerenityOS standard library but the SerenityOS founder left the project to focus on Ladybird. So, that is where this stuff evolves now.
memory safety isn't really much of a problem with modern C++. We have the range library now for instance. What's nice about modern C++ is you can almost avoid most manual loops and talk at the algorithm level.
Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).
Performance wasn't really the issue here though. The issue was that Swift's C++ interop is still half-baked and kept breaking the build. You can write a perfectly fast browser in Swift for the non-hot-path stuff, which is most of a browser. They killed it because the tooling wasn't ready, not because the language is slow.
Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
Hi, I'm the one who originally wrote Ladybird's AppKit UI. Just FYI, it was written long before Ladybird split from SerenityOS, and even longer before Swift was on the table. I only chose Objective-C++ because it was the language I was familiar with at the time :)
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.
Apple has been always 'transactional' when it comes to OSS - they open source things only when it serves a strategic purpose. They open-sourced Swift only because they needed the community to build an ecosystem around their platform.
Yeah, well, sure they've done some work around LLVM/Clang, WebKit, CUPS, but it's really not proportional to the size and the influence they still have.
Compare them to Google, with - TensorFlow, k8s, Android (nominally), Golang, Chrome, and a long tail of other shit. Or Meta - PyTorch and the Llama model series. Or even Microsoft, which has dramatically reversed course from its "open source is a cancer" era (yeah, they were openly saying that, can you believe it?) to becoming one of the largest contributors on GitHub.
Apple I've heard even have harshest restrictions about it - some teams are just not permitted to contribute to OSS in any way. Obsessively secretive and for what price? No wonder that Apple's software products are just horrendously bad, if not all the time - well, too often. And on their own hardware too.
I wouldn't mind if Swift dies, I'm glad Objective-C is no longer relevant. In fact, I can't wait for Swift to die sooner.
The fact that Swift is an Apple baby should indeed be considered a red flag. I know there are some Objective-C lovers out there but I think it is an abomination.
Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.
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.
I meant no Swift experts in the Ladybird team. Their expertise is C++, you may think the transition is easy, and it can be pretty painless at first, but true language expertise means knowing how to work around its flaws, and adapting your patterns to its strenghts. Cool for a hobby, but switching language in the middle of an herculean work is suicide.
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 already a stereotype that Rust people will just carpet bomb any discussion with aggressively promoting Rust, people expect it to happen at this point and it just annoys people.
So I think it probably meets the threshold of "toxic", but more importantly - it's not effective. Everyone and their dog has already heard of Rust, aggressive proselytising is not going to help drive Rust adoption, it's just pissing people off
I think they are mostly just idealists. Found a perfect programming language that allows them to claim that everything else is wrong, and rust can solve every problem under the sun.
This reads like an AI response to me. Would you elaborate? I can see no reason to believe it would achieve stability based on many of the statements in this issue.
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.
LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.
Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.
Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.
Yes. I also written a compiler and I also complained about LLVM.
LLVM is
- Slow to compile
- Breaks compilers/doesn't have a stable ABI
- Optimizes poorly (at least, worse than GCC)
Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that
Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say
> LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.
I suggest you ask around to see what the consensus is for which compiler is actually mature. Hint: for all its warts, nobody is writing a seriously optimized language in any of the options you listed besides LLVM.
Chris Lattner is definitely a genius engineer at innovation, implementation and delivery but long-term, robust, maintenable software-design doesn't appear to be in his capability set.
The latter is definitely a defining capability of Anders Hejlsberg. (C#/Typescript designer)
> Everything Chris Lattner has done has been a "successful mess".
I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean".
Why is it wrong?
LLVM is great.
Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today.
Swift is a fun language to write, hence, why they shoehorned it in, in the first place.
Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.
You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.
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.
The commit removing Swift has a little bit more detail:
https://github.com/LadybirdBrowser/ladybird/commit/e87f889e3...
Some more context here too:
https://github.com/LadybirdBrowser/ladybird/issues/933
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.
I think Swift was developed to keep a number of constituencies happy.
You can do classic OOP, FP, Protocol-Oriented Programming, etc., or mix them all (like I do).
A lot of purists get salty that it doesn’t force implementation of their choice, but I’m actually fine with it. I tend to have a “chimeric” approach, so it suits me.
Been using it since 2014 (the day it was announced). I enjoy it.
3 replies →
Prefer structs over classes != only use structs.
There are plenty of valid reasons to use classes in Swift. For example if you want to have shared state you will need to use a class so that each client has the same reference instead of a copy.
1 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."
This is the same way that C# works and C and C++ why is this a surprise?
2 replies →
> when every data structure is COPIED on every function call
Swift structs use copy on write, so they aren’t actually copied on every function call.
2 replies →
Nowhere does it say structs provide “one source of truth”. It says the opposite actually- that classes are to be used when unique instances are required. All classes have a unique ID, which is simply it’s virtual memory address. Structs by contrast get memcpy’d left and right and have no uniqueness.
You can also look at the source code for the language if any it’s confusing. It’s very readable.
5 replies →
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]
Not sure how I feel about Shakespeare and JK Rowling living in the same parenthesis!
Computer languages are the opposite of natural languages - they are for formalising and limiting thought, the exact opposite of literature. These two things are not comparable.
If natural language was so good for programs, we’d be using it - many many people have tried from literate programming onward.
10 replies →
>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.
It's exactly the opposite. Writing and reading are asymmetrical, and that's why it's important to write code that is as simple as possible.
It's easy to introduce a lot of complexity and clever hacks, because as the author you understand it. But good code is readable for people, and that's why very expressive languages like perl are abhorred.
1 reply →
Perlis's 10th epigram feels germane:
> Get into a rut early: Do the same process the same way. Accumulate idioms. Standardize. The only difference(!) between Shakespeare and you was the size of his idiom list - not the size of his vocabulary.
11 replies →
Not to mention how heated my laptop gets when I try to compile a new vapor template. On an m1.
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
So did you go back to and keep using C#/NET?
well for backend development, yes - I technically never stopped as I had existing projects to maintain. But after trying out Swift a couple times, I've dropped it entirely for backend. For new backend work it's C#/.NET all the way.
I wanted to try using a native language other than C++ and Swift ostensibly seemed easier to pick up. I continue to use Swift for iOS app development though where it is much easier to use; but that has its own share of compromises and trade-offs - but not centred around Swift, around SwiftUI vs UIKit.
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.
There's just too many defense mechanisms on popular websites that would simply make Ladybird flagged as a bot and render the website unusable. I wouldn't mind a toggle to switch between this and normal behavior but having that as a default would be bad for wider adoption.
If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. That being said, I find that most of the Web works just fine on Tor, so it's certainly possible. Most of the issues seem related to the (known) the exit IP being overused or identified as Tor.
6 replies →
Only if there is not widespread adoption.
A web browser that explicitly does its own thing regardless of web standards is the last browser in the world I would consider using.
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.
It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it.
It's a shame, I think swift is an underappreciated language, however I understand their reasoning. I think if they tried to just use swift from the beginning it would have been too ambitious, and trying to add swift to a fragile, massive project was probably too complex.
Looking at their integration, with cmake, they definitely took the hardmode approach to adoption.
1 reply →
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.
https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822239138038382684 "In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop."
Did they consider using Nim? It has great C++ interop, OO and same ARC memory management as in Swift.
> In the end it came down to Swift vs Rust, and Swift is strictly better in OO support and C++ interop
Why not D?
4 replies →
> Swift is strictly better in OO support and C++ interop
Fascinating.
They've shown the idea it is better on C++ interop is wrong.
I don't know enough to say Rust has same OO support as Swift, but I'm pretty sure it does. (my guess as a former Swift dev: "protocol oriented programming" was a buzzy thing that would have sounded novel, but amounted to "use traits" in rust parlance)
EDIT: Happy to hear a reply re: why downvotes, -3 is a little wild, given current replies don't raise any issues.
31 replies →
> 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.
Swift actually has excellent C++ interop [1] (compared to other languages, but, I guess, not good enough for Ladybird).
[1] https://www.swift.org/documentation/cxx-interop/
I actually looked into that recently (calling C++ from Swift), and I was surprised by the amount of limitations.
Said differently: the C++ interop did not support calling the C++ library I wanted to use, so I wrote a C wrapper.
4 replies →
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.
But wasn’t Rust designed specifically for being a language for developing a rendering engine / web browser?
12 replies →
It will be interesting to see any further justification; I believe Rust was rejected previously because of the DOM hierarchy/OOP but not sure IIRC.
20240810 https://news.ycombinator.com/item?id=41208836 Ladybird browser to start using Swift language this fall
Here's Andreas Kling's general thoughts on Rust:
- 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
I think that's fair. Funny to have a language that makes it prohibitively difficult to use most of the core computer science constructs (lists, graphs etc.).
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?
This experiment has shown that both are actually bad choices.
10 replies →
The ladybird developers tried Rust and Swift both and voted to adopt Swift.
Also I believe one of the core LadyBird devs was an ex Apple employee on WebKit which has been using Swift as well.
The Ladybird founder was one of the original KHTML devs and worked on Safari at Apple.
I’m not even sure he was at Apple when Swift came out. WebKit integration is very recent.
Swift doesn't use a garbage collector.
ARC is GC, Swift definitely uses GC.
It isn't a _tracing_ GC
I remember watching the project lead say something like “the developers just don’t enjoy rust”
Swift != GC
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++.
> It's a battle tested choice and pretty much every browser actually in use is written in C++.
Every browser in use is stuck with C++ because they're in way too deep at this point, but Chromium and Firefox are both chipping away at it bit by bit and replacing it with safer alternatives where they feasibly can. Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
IMO the takeaway is that although those browsers do use a ton of C++ and probably always will, their hard-won lessons have led them to wish they didn't have to, and to write a brand new browser in C++ is just asking to needlessly repeat all of the same mistakes. Chromium uses C++ because Webkit used C++ because KHTML used C++ in 1998. Today we have the benefit of hindsight.
> Chromium even blocked JPEG-XL adoption until there was a safe implementation because they saw the reference C++ decoder as such a colossal liability.
Quickly followed by several vulnerabilities in that reference library as well; good move
TBF that's less a C++ thing and more that there have been several high profile decoder vulnerabilities over the past however many years. Enough that Google created the custom language WUFFS for the express purpose of implementing secure parsers for arbitrary file formats.
1 reply →
It's probably okay to solve one problem at a time: first solve the "free open source browser, developed from the Web standard specs" problem in an established language (C++), and then the "reimplement all of part of it in a more suitable (safer, higher productivity) language - yet to be devised - problem.
And Andreas Kling already proved the naysayers wrong when he showd that a new operating system and Web browser can be written entirely from scratch, the former not even using any standard libraries; so beware when you are inclined to say 'not feasible'.
4 replies →
> a subset of C++ written with contemporary memory safety practices
What is this mythical subset of C++? Does it include use of contemporary STL features like string_view? (Don’t get me wrong — modern STL is considerably improved, but it’s not even close to being memory-safe.)
> What is this mythical subset of C++
Ladybird inherits its C++ from SerenityOS. Ladybird has an almost completely homegrown standard library including their own pointer classes and a couple of different string classes that do some interesting things with memory. But perhaps the most novel stuff are things like TRY and MUST: https://github.com/SerenityOS/serenity/blob/master/Documenta...
You see this reflected all the way back to the main function. Here is the main entry function for the entire browser:
ErrorOr<int> ladybird_main(Main::Arguments arguments).
https://github.com/LadybirdBrowser/ladybird/blob/master/UI/Q...
If Ladybird is successful, I would not be surprised to see its standard library take off with other projects. Again, it is really the SerenityOS standard library but the SerenityOS founder left the project to focus on Ladybird. So, that is where this stuff evolves now.
1 reply →
They probable mean safe code like this:
memory safety isn't really much of a problem with modern C++. We have the range library now for instance. What's nice about modern C++ is you can almost avoid most manual loops and talk at the algorithm level.
2 replies →
Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?
Only parts of it. Servo is the engine written in Rust, some of which ended up in Mozilla.
Firefox has some Rust components but it isn't written in Rust overall. Servo is written in Rust but it isn't a full browser.
3 replies →
Mozilla laid off the Servo team years ago.
9 replies →
Yes and yes. Firefox is partially written in Rust.
Well, it was a terrible idea in any case unless it was for high-level-ish code only. Swift generally can't compete with C++ in raw performance (in the same way as Java - yeah, there are benchmarks where it's faster, but it basically doesn't happen in real programs).
Performance wasn't really the issue here though. The issue was that Swift's C++ interop is still half-baked and kept breaking the build. You can write a perfectly fast browser in Swift for the non-hot-path stuff, which is most of a browser. They killed it because the tooling wasn't ready, not because the language is slow.
1 reply →
Hurray for micro benchmarks. Anyway, every language can be abused. I can make Java run slower than Ruby. Given that it runs on Microcontrollers on billions of devices, I don't think Swift is necessarily the problem in whatever case you have in mind (And yes I stole oracle's java marketing there for Swift, it is true though.)
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...
Hi, I'm the one who originally wrote Ladybird's AppKit UI. Just FYI, it was written long before Ladybird split from SerenityOS, and even longer before Swift was on the table. I only chose Objective-C++ because it was the language I was familiar with at the time :)
Swift is Apple's toy language and they cannot and will not allow it to be anything more than that.
Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?
Ladybird split from SerenityOS a while ago, Jakt is not "their" language. And no, I don't think a niche programming language is on the table.
Jfc why do they not just use rust? Is it the c++ addiction dominating?
Rust isn't OO is their main issue at this point.
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.
Maybe I misunderstand, but I thought Jakt was part of SerenityOS, not Ladybird.
From what I can tell they're pretty laser focused on making a browser (even in this issue, they're abandoning Swift).
2 replies →
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.
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 never felt truly open source either.
Apple has been always 'transactional' when it comes to OSS - they open source things only when it serves a strategic purpose. They open-sourced Swift only because they needed the community to build an ecosystem around their platform.
Yeah, well, sure they've done some work around LLVM/Clang, WebKit, CUPS, but it's really not proportional to the size and the influence they still have.
Compare them to Google, with - TensorFlow, k8s, Android (nominally), Golang, Chrome, and a long tail of other shit. Or Meta - PyTorch and the Llama model series. Or even Microsoft, which has dramatically reversed course from its "open source is a cancer" era (yeah, they were openly saying that, can you believe it?) to becoming one of the largest contributors on GitHub.
Apple I've heard even have harshest restrictions about it - some teams are just not permitted to contribute to OSS in any way. Obsessively secretive and for what price? No wonder that Apple's software products are just horrendously bad, if not all the time - well, too often. And on their own hardware too.
I wouldn't mind if Swift dies, I'm glad Objective-C is no longer relevant. In fact, I can't wait for Swift to die sooner.
9 replies →
The fact that Swift is an Apple baby should indeed be considered a red flag. I know there are some Objective-C lovers out there but I think it is an abomination.
Apple is (was?) good at hardware design and UX, but they pretty bad at producing software.
35 replies →
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.
I meant no Swift experts in the Ladybird team. Their expertise is C++, you may think the transition is easy, and it can be pretty painless at first, but true language expertise means knowing how to work around its flaws, and adapting your patterns to its strenghts. Cool for a hobby, but switching language in the middle of an herculean work is suicide.
2 replies →
I think they were meaning that there were no swift experts on the LadyBird team
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.
What language do you recommend?
The best tool for the job is the one you know and love.
5 replies →
is go the same? what is the consensus best pick right now I wonder, is it C#?
Best pick for what? It always depends, and there is certainly no consensus.
[dead]
When does the migration to Rust start? /s
It seems like today. https://news.ycombinator.com/item?id=47120899
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.
[flagged]
[flagged]
[flagged]
Bringing up Rust as an obvious alternative is not toxic.
There's already a stereotype that Rust people will just carpet bomb any discussion with aggressively promoting Rust, people expect it to happen at this point and it just annoys people.
So I think it probably meets the threshold of "toxic", but more importantly - it's not effective. Everyone and their dog has already heard of Rust, aggressive proselytising is not going to help drive Rust adoption, it's just pissing people off
2 replies →
it's toxic because of how it sometimes materializes:
- predictable
- incessant
- with belittling/reductionist/arrogant/elitist/combative phrasings
- handwaving rust shortcomings and tradeoffs
It is a genuinely strange social phenomenon. What is it about Rust specifically that attracts these people?
I think they are mostly just idealists. Found a perfect programming language that allows them to claim that everything else is wrong, and rust can solve every problem under the sun.
1 reply →
[flagged]
This reads like an AI response to me. Would you elaborate? I can see no reason to believe it would achieve stability based on many of the statements in this issue.
Their entire comment history reads like AI to me.
[flagged]
3 replies →
I hate to be the one to point this out but really, in 10 years, how many rust ports will face the same fate?
some? It can happen with any language.
none
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.
People are correct I didn't explain my position.
LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.
Swift: I was very excited with the first release of Swift. But it ultimately did not have a very focused vision outlined for it. Because of this, it has morphed into a mess. It tries to be everything for everyone, like C++, and winds up being mediocre, and slow to compile to top it off.
Mojo isn't doesn't exist for the public yet. I hope it turns out to be awesome, but I'm just not going to get my hopes up this time.
Yes. I also written a compiler and I also complained about LLVM.
LLVM is
Swift I never used but I tried compiling it once and it was the bottom 2 slowest compiler I ever tested. The only thing nearly as bad was kotlin but 1) I don't actually remember which of these are worse 2) Kotlin wasn't meant to be a CLI compiler, it was meant to compile in the background as a language server so it was designed around that
Mojo... I have things I could say... But I'll stick to this. I talked to engineers there and I asked one how they expected any python developers to use the planned borrow checker. The engineer said "Don't worry about it" ie they didn't have a plan. The nicest thing I can say is they didn't bullshit me 100% of the time when I directly asked a question privately. That's the only nice or neutral thing I could say
> LLVM: Pretty much everyone who has created a programming language with it has complained about its design. gingerbill, Jon Blow, and Andrew Kelley have all complained about it. LLVM is a good idea, but it that idea was executed better by Ken Thompson with his C compiler for Plan 9, and then again with his Go compiler design. Ken decided to create his own "architecture agnostic" assembly, which is very similar to the IR idea with LLVM.
I suggest you ask around to see what the consensus is for which compiler is actually mature. Hint: for all its warts, nobody is writing a seriously optimized language in any of the options you listed besides LLVM.
How many languages are using LLVM as its backend vs Go's?
6 replies →
Chris Lattner is definitely a genius engineer at innovation, implementation and delivery but long-term, robust, maintenable software-design doesn't appear to be in his capability set.
The latter is definitely a defining capability of Anders Hejlsberg. (C#/Typescript designer)
1 reply →
> Everything Chris Lattner has done has been a "successful mess".
I don't have an emotional reaction to this, i.e. I don't think you're being mean, but it is wrong and reductive, which people usually will concisely, and perhaps reductively, describe as "mean".
Why is it wrong?
LLVM is great.
Chris Lattner left Apple a *decade* ago, & thus has ~0 impact or responsibility on Swift interop with C++ today.
Swift is a fun language to write, hence, why they shoehorned it in, in the first place.
Mojo is fine, but I wouldn't really know how you or I would judge it. For me, I'm not super-opinionated on Python, and it doesn't diverge heavily from it afaik.
Not just LLVM, but Google's TPU seems to be doing fine also. Honestly it's an impressive track record.
2 replies →
You don't explain or support your position, you are calling Lattner names. That's not helpful to me or anyone else if we are trying to evaluate his work. Swift has millions of users as does Mojo and Modular in general. These are not trivial accomplishments.
Mojo and Modular have millions of users?
5 replies →
That's why there's nothing that comes close to LLVM and MLIR, right?
If he's such a horrible engineer then we should have lots of LLVM replacements, right?
QBE is a tiny project, but I think illustrates a better intermediate language design. https://c9x.me/compile/
1 reply →
Many compilers including my own uses C89
8 replies →
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?
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.
This comment was written in Ladybird.
> when it feels so handwavey
Carefully making decisions and then reassessing those choices later on when they prove to be problematic is the opposite of handwavey...