Remix.run Logo
jchw 16 hours ago

I find it intriguing but have so far been unwilling to convince myself to give it a try on anything. It has a lot of good ideas, but I think Apple needs to relinquish more control over its future and direction for me to feel like a future plan change at Apple won't jeopardize its usefulness outside of Apple platforms. Presumably the reason why they want to keep it under their own organization is specifically so they can control their own destiny better, since Apple is heavily using Swift themselves; totally understandable, but trusting it for something that needs to be crossplatform in the long term seems potentially unwise.

It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure.

This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.

pm 15 hours ago | parent [-]

Swift evolution and governance is open and publicly documented. It will always be dominated by Apple engineers, but the evolution of the language is largely orthogonal to Apple's OS releases.

I'm not sure how much of the standard library is available on the server side. However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago.

I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.

jshier 14 hours ago | parent | next [-]

Orthogonal? Odd thing to say given Swift's evolution and release timeline are entirely constrained by Apple's OS release schedule. We're currently going through the spike in evolution proposals by Apple engineers in preparation for the branching of Swift 6.2 next month before WWDC in June.

As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly).

I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time.

Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.

jchw 13 hours ago | parent | prev [-]

Firstly, I believe the fears are founded; these fears are a good starting point, since learning and adopting a programming language is a big investment, and you should be careful when making big investments. To say they're unfounded suggests that they have no basis. Disagreed.

Secondly, I don't really feel like this sort of analysis does much to assuage fears, as Apple's business strategy is always going to take priority over what its engineers individually want. Apple of today doesn't have any obvious reason to just go and axe cross-platform Swift, but if that ever changes in the future, they could do it overnight, like it was never there. Could do it tomorrow. It's not much different than an employee getting laid off abruptly.

This is especially true because in truth Apple doesn't really have a strong incentive in the grand scheme of things to support Swift on non-Apple platforms. Even if they use it in this way today, it's certainly not core to their business, and it costs them to maintain, costs that they may eventually decide benefits their competitors more than it helps them.

There's no exact heuristic here, either. Go is entirely controlled by Google and does just fine, though it has the advantage of no conflict-of-interest regarding platforms. Nobody writing Go on Linux servers really has much reason to be concerned about its future; Partly because Google has quite a lot of Go running on Linux today, and given how long it took them to e.g. transition to Python 3 internally, I can just about guarantee you that if Go died it would probably not be abrupt. Even if it was, because of the massive amount of external stakeholders there are, it would quickly be picked up by some of the large orgs that have adopted it, like Uber or Digital Ocean. The risk analysis with Go is solid: Google has no particular conflict of interest here, as they don't control the platforms that Go is primarily used on; Google has business reasons to not abruptly discontinue it and especially not on Linux servers; there are multiple massive stakeholders with a lot of skin in the game who could pick up the pieces if they called it quits.

I believe Apple could also get to that point with Swift, but they might need a different route to get there, as Swift is still largely seen as "That Apple Thing" for now, by a lot of outsiders, and that's why I think they need to cede some control. Even if they did fund a Swift foundation, they could still remain substantially in control of the language; but at least having other stakeholders with skin in the game having a seat at the table would do a lot to assuage fears about Swift's future and decouple aspects of governance from Apple in ways that would probably ultimately benefit Swift for everyone.

P.S.: And I'm not singling Apple out here, because I think any rational company has to make tough decisions sometimes, but it's obvious from their past that they definitely don't fear changes of plan. Look all the way back to OpenDoc. Being willing to make bold changes of plan feels like it's a part of their company DNA.