Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

51–60 of 332 posts

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

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

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/

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

#52
post #30

Earlier quoted context omitted.

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.

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.

For what it’s worth, ObjC is not Apple’s brainchild. It just came along for the ride when they chose NEXTSTEP as the basis for Mac OS X.

I haven’t used it in a couple decades, but I do remember it fondly. I also suspect I’d hate it nowadays. Its roots are in a language that seemed revolutionary in the 80s and 90s - Smalltalk - and the melding of it with C also seemed revolutionary at the time. But the very same features that made it great then probably (just speculating - again I haven’t used it in a couple decades) aren’t so great now because a different evolutionary tree leapfrogged ahead of it. So most investment went into developing different solutions to the same problems, and ObjC, like Smalltalk, ends up being a weird anachronism that doesn’t play so nicely with modern tooling.

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

#53
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?

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

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

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?

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

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

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

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

#56
post #30

Earlier quoted context omitted.

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.

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.

Years ago I wrote a toy Lisp implementation in Objective-C, ignoring Apple’s standard library and implementing my own class hierarchy. At that point it was basically standard C plus Smalltalk object dispatch, and it was a very cool language for that type of project.

I haven’t used it in Apple’s ecosystem, so maybe I am way off base here. But it seems to me that it was Apple’s effort to evolve the language away from its systems roots into a more suitable applications language that caused all the ugliness.

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

#57
post #36
post #32

Earlier quoted context omitted.

Yet, after all these years its browser is quite frankly pre-historic.

What are you talking about? It doesn't have a "browser", it has a testing shell. For a time there was actual attempt with the Verso experiment but it got shelved just recently. Servo is working at being embeddable at the same time when Rust GUI toolkits are maturing. Once it gets embedding stabilized that will be the time for a full blown browser developement.

> It doesn't have a "browser", it has a testing shell.

So, yes it is still pre-historic.

> Once it gets embedding stabilized that will be the time for a full blown browser developement.

Servo development began in 2012. [0] 14 years later we get a v0.0.1.

At this point, Ladybird will likely reach 1.0 faster than Servo could, and the latter is not even remotely close to being usable even in 14 years of waiting.

[0] https://en.wikipedia.org/wiki/Servo_(software)

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

#58
post #9
post #4

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…

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.

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

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

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.

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

#60
post #51
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.

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.

Post reply on HN