Closing this as we are no longer pursuing Swift adoption • Hacker News Board

Re: Closing this as we are no longer pursuing Swift adoption

#171

Post by LeFantome » Thu, Feb 19, 2026, 3:13 AM UTC

nicoburns wrote: post #145

pbohun wrote: post #112

Earlier quoted context omitted.

As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to. You could imagine creating a modified Go assembler that is more generic and not tied to Go's ABI…

> As far as I know, only Go uses Go's back end because it was specifically designed for Go. But the architecture is such that it makes it trivial for Go to cross compile for any OS and architecture. This is something that LLVM cannot do. You have to compile a new compiler for every OS and arch combo you wish to compile to. I don't think that's true. Zig have a cross-compiler (that also compiles C and C++) based on LL…

I do not have enough knowledge to say anything bad about LLVM. As an "amateur" compiler writer, it did confuse me a bit though.

What I will say is that it seem popular to start with LLVM and then move away from it. Zig is doign that. Rust is heading in the direction perhaps with Cranelift. It feels that, if LLVM had completely nailed its mission, these kinds of projects would be less common.

It is also notable that the Dragonegg project to bring GCC languages to LLVM died but we have multiple projects porting Rust to GCC.

Re: Closing this as we are no longer pursuing Swift adoption

#172

Post by levodelellis » Thu, Feb 19, 2026, 3:13 AM UTC

dismalaf wrote: post #53

pbohun wrote: post #43

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.

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?

Many compilers including my own uses C89

Re: Closing this as we are no longer pursuing Swift adoption

#173

Post by drnick1 » Thu, Feb 19, 2026, 3:17 AM UTC

diath wrote: post #131

drnick1 wrote: post #126

Earlier quoted context omitted.

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.

> If those "popular websites" are the likes of Facebook and Instagram, I don't see that as a big loss. Personally I wouldn't mind either but my point is that they probably want to cater to the average person, and not just security conscious tech savvy people, and if that's the case, then you really can't exclude FB/IG/YT and others from working properly in your browser.

Firefox tries to position itself as that secure and private alternative, but this is mostly marketing. For a long time, Chromium had better site isolation, and the default Firefox settings are permissive when it comes to fingerprinting. Out of the box, it seems that Brave wins here, but for now using Brave means accepting a lot of extra commercial stuff that should not be in a browser in the first place (and that increases the attack surface). I have been using the Arkenfox user.js for Firefox, but it's unclear how much good it does or if it isn't counterproductive (by making the the user stand out).

Re: Closing this as we are no longer pursuing Swift adoption

#174

Post by zozbot234 » Thu, Feb 19, 2026, 3:18 AM UTC

9rx wrote: post #170

zozbot234 wrote: post #61

Earlier quoted context omitted.

Rust has straightforward support for every part of OOP other than implementation inheritance, and even implementation inheritance can be rephrased elegantly as the generic typestate pattern. (The two are effectively one and the same; if anything, generic typestate is likely more general.)

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try. Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby…

You just need to define a trait, then you can use dynamic dispatch.

Re: Closing this as we are no longer pursuing Swift adoption

#175

Post by 9rx » Thu, Feb 19, 2026, 3:21 AM UTC

zozbot234 wrote: post #174

9rx wrote: post #170

Earlier quoted context omitted.

> Rust has straightforward support for every part of OOP other than implementation inheritance Except the only thing that makes OOP OOP: Message passing. Granted, Swift only just barely supports it, and only for the sake of interop with Objective-C. Still, Swift has better OO support because of it. Rust doesn't even try. Not that OOP is much of a goal. There is likely good reason why Smalltalk, Objective-C, and Ruby…

You just need to define a trait, then you can use dynamic dispatch.

You can, but then you don't get any of what OOP actually offers. Message passing isn't the same thing as dynamic dispatch. OOP is a very different paradigm.

Re: Closing this as we are no longer pursuing Swift adoption

#176

Post by LeFantome » Thu, Feb 19, 2026, 3:22 AM UTC

nylonstrung wrote: post #95

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.

Re: Closing this as we are no longer pursuing Swift adoption

#177

Post by LeFantome » Thu, Feb 19, 2026, 3:34 AM UTC

stingraycharles wrote: post #91

jll29 wrote: post #87

Earlier quoted context omitted.

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?

> Rust designed specifically for being a language for developing a rendering engine

Rust was born at Mozilla, sort of. It was created by a Mozilla employee. The first "real" project to put it into action was Servo of which parts were adopted into Firefox. While Rust may not have been developed "specifically" to create a browser, it is a fair comment.

That said, Ladybird was started as part of the SerenityOS project. That entire project was built using C++. If the original goal of Serenity was to build an opeerating system, C++ would have felt like a reasonable choice at the time.

By the time Ladybird was looking for "better" languages than C++, Ladybird was already a large project and was making very heavy use of traditional OOP. Rust was evaluated but rejected because it did not support OOP well. Or, at least, it did not support integration into a large, C++ based, OOP project.

Perhaps, if Ladybird had first selected a languge to write a browser from scratch, they would have gone with Rust. We will never know,

We do know that Mozilla, despite being the de facto stewards of Rust at the time, and having a prototype web browser written in Rust (Servo), decided to drop both Rust and Servo. So, perhaps using Rust for browsers is not as open and shut as you imply.

Re: Closing this as we are no longer pursuing Swift adoption

#178

Post by hippo22 » Thu, Feb 19, 2026, 3:38 AM UTC

satvikpendem wrote: post #165

bunderbunder wrote: post #164

Earlier quoted context omitted.

Assuming you mean C (C++ is an 80s child), that’s trivially true because devices with an ObjC SDK are a strict subset of devices that are running on C.

Yes, that is why I don't find it "insane" like the grandparent does, like yeah, devices run old languages because those languages work well for their intended purpose.

You should feel that C’s longevity is insane. How many languages have come and gone in the meantime? C is truly an impressive language that profoundly moved humanity forward. If that’s not insane (used colloquially) to you, then what is?

Re: Closing this as we are no longer pursuing Swift adoption

#179

Post by belmont_sup » Thu, Feb 19, 2026, 3:38 AM UTC

miffy900 wrote: post #161

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 S…

Not to mention how heated my laptop gets when I try to compile a new vapor template. On an m1.

Re: Closing this as we are no longer pursuing Swift adoption

#180

Post by VerifiedReports » Thu, Feb 19, 2026, 3:53 AM UTC

miffy900 wrote: post #161

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 S…

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.