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?
Closing this as we are no longer pursuing Swift adoption
21–30 of 332 posts
Re: Closing this as we are no longer pursuing Swift adoption
#22Not 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?
Re: Closing this as we are no longer pursuing Swift adoption
#23Earlier 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.
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
#24Earlier 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]
Re: Closing this as we are no longer pursuing Swift adoption
#25Re: Closing this as we are no longer pursuing Swift adoption
#26Not 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.)
Re: Closing this as we are no longer pursuing Swift adoption
#27Re: Closing this as we are no longer pursuing Swift adoption
#28Not 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…
Quickly followed by several vulnerabilities in that reference library as well; good move
Re: Closing this as we are no longer pursuing Swift adoption
#29Earlier 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]
Re: Closing this as we are no longer pursuing Swift adoption
#30I 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.
Also funny enough, all cross platform work is with small work groups, some even looking for funding … anyway.