Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

21–30 of 332 posts

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

#21
post #15
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++.

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.

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

#22
post #15
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++.

Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?

Mozilla laid off the Servo team years ago.

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

#23
post #19
post #15

Earlier quoted context omitted.

Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?

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.

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 too). Thanks to this it has much better chance at wider adoption and actually spawning multiple browsers.

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

#24
post #10
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]

Sunk cost fallacy. It didn't work out, the decision was made, they move on. I like that.

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

#25
post #15

Earlier quoted context omitted.

Wasn't Rust developed specifically for Mozilla? Isn't mozilla written in Rust?

Mozilla laid off the Servo team years ago.

Servo was passed onto Linux Foundation and is still being developed, some of its components are shared with Firefox.

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

#26
post #11
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++.

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

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

#27
post #6
post #2

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

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

#28
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…

> 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

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

#29
post #10
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]

> so why throw away all that time?

https://en.wikipedia.org/wiki/Sunk_cost

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

#30

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.

Post reply on HN