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

61–70 of 332 posts

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

#61

Post by zozbot234 »

refulgentis wrote: post #55
mlinksva wrote: post #49

Earlier quoted context omitted.

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

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

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

#62

Post by jabwd »

ahartmetz wrote: post #8
drnick1 wrote: 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++.

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

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

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

#63

Post by tvshtr »

rvz wrote: post #57
tvshtr wrote: post #36

Earlier quoted context omitted.

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] htt…

This is disingenuous. Servo is using RUST, language which grew together with it, pretty much, and all components surrounding it. C++ is how old, please remind me?

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

#64

Post by WaldoDude »

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

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

#65

Post by TbobbyZ »

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.

What language do you recommend?

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

#66

Post by zozbot234 »

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.

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.

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

#67

Post by [deleted] »

refulgentis wrote: post #55
mlinksva wrote: post #49

Earlier quoted context omitted.

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

[deleted]

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

#68

Post by stockresearcher »

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 doesn’t really make sense though. I thought that they hired Lattner to work on LLVM/clang so they could have a non-gpl compiler and to make whatever extensions they wanted to C/Obj-C. Remember when they added (essentially) closures to C to serve their internal purposes?

So they already got what they wanted without inventing a new language. There must be some other reason.

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

#69

Post by rvz »

zozbot234 wrote: post #61
refulgentis wrote: post #55

Earlier quoted context omitted.

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

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

I think we have seen enough since the best example of a Rust browser that is Servo, has taken them 14 years to reach v0.0.1.

So the approach of having a new language that requires a full rewrite (even with an LLM) is still a bad approach.

Fil-C likely can do the job without a massive rewrite and achieving safety for C and C++.

Job done.

EDIT: The authors of Ladybird have already dismissed using Rust, and with Servo progressing at a slow pace it clearly shows that Ladybird authors do not want something like that to happen to the project.

Post reply on HN