Swift is slowly evolving into a formidable competitor to C++, and Rust. SwiftNIO, Swift on Windows and now this multiplatform System library, Swift is truly on its way to become a mainstream systems language. Exciting Tim times indeed!
At this point I don't even care about how good their language is. Apple has a very, very long way to go before I can trust them on anything of that magnitude. I would instead assume they WILL pull the rug from under developers for any random reason.
(And I say this as an iOS developer)
Most Linux users here likely use one or two out of three of these on a weekly basis. Many likely use all three on a weekly basis. Some use all three daily.
WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink instead.
LLVM is developed by many companies these days, including Intel, Sony and Google.
Wrong. Upstream CUPS on Apple's github has support for everything, even systemd.
> WebKit is probably pretty rare outside macos, most browsers will be built from Chromium/Blink
GTK's WebView (and browsers like Epiphany aka GNOME Web) use WebKit, complete with Apple's web inspector / devtools.
> GTK's WebView (and browsers like Epiphany aka GNOME Web) use WebKit, complete with Apple's web inspector / devtools.
Good point, Qt's legacy HTML engine (Qt WebKit) is, well, WebKit, too. The newer Qt WebEngine uses Blink. I suspect this is a common pattern with components built on KHTML/WebKit before Chromium became Blink. In any case, Blink is clearly the fork that won.
However, for the project I was on, when I was working on it, Swift on Linux was a massive pain in the ass, mostly due to documentation and dependency hell. Documentation was extremely useless; the number of times I was told "oh yes there's a swift way to do that!" only to find out the 'swift' way was to wrap a Cocoa library or just drop in some Objective-C module. If I recall correctly, there was an issue with pthreads not being properly implemented at the time, relying on some hacks to get it to 'work' while they figured out a 1.0 implementation. We got it to work, eventually, but the hoops we had to jump through really pushed our team to Rust as our general purpose systems language.
I'm glad they seem to have got it working, but I'm never subjecting myself to trying to get Apple's nonesense working outside of iOS or macOS again.
I think the Linux support that already exists is an awesome start. But the only realistic way to see more from Apple on this is if they themselves start to deploy critical Swift web-services on their own backend infra. (I'm assuming here that they run Linux systems somewhere in their stack.) That will give them the incentive to take it to the next level. Until then it's largely left to the community to find the energy and time to do this.
Apple has enough in the bank to do it as well.
If you've been putting up with the [lack of] iOS API ergonomics for years, by all means, Swift will look like a substantial step forward. If you're used to thoughtful and quality APIs, the marriage between Swift and NSDrunkApiDesign is an incredibly unattractive proposition.
I really just refuse to tolerate those APIs on platforms (.Net) and languages (Rust stdlib) where more sensible APIs are available. If there were an alternative stdlib for Swift that lacked/wrapped the iOS quirks, I'd probably be all for it.
You can still say it's a facade when using things like UIKit, but as we've seen in the past few years w/ SwiftUI that is changing. It's already no longer the case if you're doing anything related to heavy duty computation [Accelerate, Metal & others have Swift-specific APIs now] or networking [SwiftNIO].
.Net has done that, with multiple platforms.
Dart has done that, with multiple platforms.
Apple doesn't care for anything except iOS. That is why Swift won't be taken seriously on anything except iOS.
I especially like that you have file operations defined on String type.
Also, how is it that a "well-designed and polished" standard library doesn't have a means to write to a file?
If you're not targeting an apple UI the choice of swift is entirely confusing because it has even less of an ecosystem to build off of than where it's popular.
"Swift uses Automatic Reference Counting (ARC) to manage memory."
Rust's Rc/Arc can still selectively use borrowing, which guarantees the level of efficiency that in Swift may or may not happen depending on the optimizer. A borrowed Arc can often stay borrowed across many non-inlined method calls, which you're unlikely to get in Swift.
https://github.com/quicwg/base-drafts/wiki/Implementations
Phrased another way, your language should be participating in the future of HTTP, which is HTTP3 aka HTTP-over-QUIC. Swift's absence here indicates, to me, that Swift does not take itself seriously as a tool for delivering server side systems.
IBM dropping swift was another pretty strong indicator to me. They really tried, they wanted to believe. But this seems like an insular, closed off world, however much they keep going through long lengths like this effort here to open themselves up & make themselves accessible to the rest of the world. Their attempts to build bridges haven't seemed to make people be very interested in transitting over to their parcel of land, the advantages aren't clear, choices of language just don't seem that relevant, there's some advantages but overall the day to day won't be radically different except that you'll be an outsider hanging out with a bunch of people mostly entirely doing iOS. I'd be happy to be wrong, seems decent enough, maybe there's some real differentiation that truly improves life, but it also seems like it's a C# type situation, where it exists & is developed only to keep the natives in spirits & from getting restless.
I want to re-iterate that I think Swift seems pretty ok. More than not-bad. But languages just don't seem that relevant to me any more. Rust is being extra-strict, but otherwise, the feature-sets of languages doesn't seem very notable. There's some preferences & styles, some community favor that distinguishes languages, but by & large the work is not that different. I'm not sure what I would suggest to Swift to help themselves rise above, to underscore their own meaningfulness, in this kind of murky abyss-like scenario I've painted. I do think trying to win some AI champions makes sense; python seems to be unshakeable there, but that also means there's opportunity for better/different. Trying to get some web-developers web-platform folk on your side is usually a pretty big win, but not easy, & very factionalized already. It's weird days for languages.
Nah. It's fine to leave any networking to external libraries.
Some trivia, not necessarily a recommendation: Node.js is the only language I know of working towards HTTP3 support in the platform (also in this link, evidence that I may be biased in my priorities):