Live data from Hacker News

Closing this as we are no longer pursuing Swift adoption

github.com

31–40 of 332 posts

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

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

They probable mean safe code like this:

    class FontFeatureValuesMapIterationSource final
    : public PairSyncIterable::IterationSource {
    public:
    FontFeatureValuesMapIterationSource(const CSSFontFeatureValuesMap& map,
                                      const FontFeatureAliases* aliases)
      : map_(map), aliases_(aliases), iterator_(aliases->begin()) {}

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

#32
post #25

Earlier quoted context omitted.

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.

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

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

#34
post #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.

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.

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

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

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.

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

#36
post #32
post #25

Earlier quoted context omitted.

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

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.

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

#37
post #23
post #19

Earlier quoted context omitted.

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…

> 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 easily be ecosystem modules but aren't seemingly (from my perspective) because the ambition to be modular has been lost.

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

#38

Earlier quoted context omitted.

It looked to me like it was just due to recurring build issues. Lots of "swift can't import these conflicting C++ versioned libraries concurrently" and "can't use some operator due to versioning or build conflicts". Basically it sounds like trying to add swift to the project was breaking too many things, and they decided it wasn't worth it. It's a shame, I think swift is an underappreciated language, however I unders…

Looking at their integration, with cmake, they definitely took the hardmode approach to adoption.

The list of issues does not seem to stem from whether they had used this build tool (CMake) nor others (nor official build environments).

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

#39

Ah, that's too bad. Does that mean their own programming language, Jakt, is back on the table?

For their sake, I hope not. I don't think an outside-donation-financed project with this much ADD can survive in the long term.

It's frustrating to discuss. It is a wonderful case study in how not to make engineering management decisions, and yet, they've occurred over enough time, and the cause is appealing enough, that it's hard to talk about out loud in toto without sounding like a dismissive jerk.

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

#40
post #35

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.

[deleted]
Post reply on HN