Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

Post reply on HN
Print view View original

41–50 of 332 posts

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

#41

Post by manbash »

polliog wrote: post #10
tomcam wrote: post #6

Earlier quoted context omitted.

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.

[flagged]

Chiming in: indeed, the response is very dry, and raises suspicion. It states the obvious facts and then makes a boring statement, lacking any nuance of the conversation. It is not argumentative in the very least.

Time has been spend, yes. But the topic at hand is after so much time the conclusion to abandon this path is justified.

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

#42

Post by tvshtr »

nicoburns wrote: post #37
tvshtr wrote: post #23

Earlier quoted context omitted.

Servo is slowly but steadily getting there. The thing with Servo is that it's highly modularized and some of its components are widely used by the larger Rust ecosystem, even it the whole browser engine isn't. So there's multi-pronged vested interest in developing it. Moreover, Servo aims to be embeddable (there are some working examples already), which is where other non-Chrome/ium browsers are failing (and Firefox…

> The thing with Servo is that it's highly modularized and some of its components are widely used by the larger Rust ecosystem, even it the whole browser engine isn't. Alas not nearly as modularized as it could be. I think it's mainly just Stylo and WebRender (the components that got pulled into Firefox), and html5ever (the HTML parser) that are externally consumable. Text and layout support are two things that could…

I've seen recent talk about swappable js engine, so I'm unsure about the ambition being lost. I'm eyeing Blitz too (actually tried to use it in one of my projects but the deps fucked me up).

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

#44

Post by saghm »

mempko wrote: post #26
amluto wrote: post #11

Earlier quoted context omitted.

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

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.

And yet in practice, it's been less than a week since a major CVE in Chromium due to memory unsafety: https://chromereleases.googleblog.com/2026/02/stable-channel...

Having a checklist of "things not to do" is historically a pretty in effectiveway to ensure memory safety, which is why the parent comment was asking for details. The fact that this type of thing gets dismissed as a non-issue is honestly a huge part of the problem in my opinion; it's time to move on from pretending this is a skill issue.

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

#45

Post by hypeatei »

losvedir wrote: post #13

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.

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

#46

Post by meisel »

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.

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

#47

Post by SirFatty »

isodev wrote: post #35
stephc_int13 wrote: post #34

Earlier quoted context omitted.

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.

Some refer to the “Tim Cook doctrine” as a reason for Swift’s existence. It’s not meant to be good, just to fulfill the purpose of controlling that part of their products, so they don’t have to rely on someone else’s tooling.

That sounds like Microsoft's doctrine!

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

#48

Post by refulgentis »

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.

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

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

#49

Post by mlinksva »

meisel wrote: post #46

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

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

#50

Post by iLemming »

isodev wrote: post #30
stephc_int13 wrote: post #17

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.

Post reply on HN