Apple Open-Sources Swift System, Adds Linux Support

[bug77]

I think it's an attempt to provide developers of apps that use lower level functions of the system a common shim so that they will be easier to port to the new ARM architecture in the future. It's useless if only Mac apps use it.

I don't understand. How is it useless if only Mac apps use it? Only Mac apps are making the switch.
Anyway, I'm not planning on using this, so it makes no difference to me.

[cyring]

Good and easy object programming which produces (arm) assembly code as fast as native.
Swift without the UIkit and other Apple frameworks will be less appealing. That's the Apple challenge to port their eco-system as open-source.

[portablenuke]

I'm rather shocked at the negativity with respect to Swift on Linux.

The FOSS community has a weird relationship with Apple. Apple is an ally (not a perfect ally, but better then others), and they could be a good strategic partner since there is base of commonality (Openstep, Posix) between MacOS and Linux/BSDs. Instead, they'd rather spend all of their time and energy focusing on MS (Wine, Mono, window manager design) and bashing Apple.

It's a weird, dysfunctional relationship that's unhealthy.

It could easily morph into the ideal app development tool for Linux development. The release of this system library is just another step forward to a language that allows complete high level development without the decent into C interfaces that cause so much problem with programmers.

Useful is another consideration, I can see Swift as being the long term replacement for Python when it comes to programmer productivity, ease of maintenance and support for new programming features. Swift disposes of some of the notorious constructs that make C++ a maintenance headache while eliminating some of the shortcomings of languages like Python when it comes to app development. I like to call it hitting the high middle ground between Python and C++ with respect to readability.

I agree. I like Swift as client language since it's built to be a client language. I've written clients in Go, and as much as I like Go the way it is for services, it's not a great client language. Languages like Python are much better client languages, but Swift changes that. Swift makes writing clients easy since that's what it's built to do.

Frankly I don't see it as a C/C++ replacement, rather it is a replacement for Python, Java and other higher level languages. The fact that it has some potential to replace C++ is just icing on the cake. Now Swift certainly needs more support on Linux and frankly it isn't completely there on Mac OS, but that does take some effort on the part of developers in the Linux community, just like any other open source product.

People are forgetting Apple uses Linux on their servers, iCloud isn't backed by Mac Minis running MacOS, and releasing this makes the code more portable. People can just write code, and not have to deal with platform differences, as much. (Crazy idea right?) Their devs can develop on MacOS and deploy on Linux.

Swift is still a work in progress. The BSD support is still basically non-existent, and I'd like to see that change before really investing in it.

Swift, Go, Rust, and Zig make for an interesting cohort of new languages.

No language is perfect but I've yet to see a rational dismissal of Swift on Linux. The community should be embracing Swift instead and by doing so we might actually see a step change in app quality and the number of apps available.

I feel a similar way about GNUstep/Openstep and Objective-C, but that's not the direction people went. As nice as Swift is, it's potential will probably be ignored in favor of something less optimal.

Meanwhile, people are going gaga over Linux becoming a first class citizen of .NET, and most desktop clients are web pages running in a hacked up Chromium browser.

[Michael_S]

The FOSS community has a weird relationship with Apple. Apple is an ally (not a perfect ally, but better then others), and they could be a good strategic partner since there is base of commonality (Openstep, Posix) between MacOS and Linux/BSDs. Instead, they'd rather spend all of their time and energy focusing on MS (Wine, Mono, window manager design) and bashing Apple.

It's a weird, dysfunctional relationship that's unhealthy.

1. As an aside, I'm not that familiar with MacOS but I believe Elementary Linux tries to copy a lot of their design aesthetic. Their stuff isn't, in my humble opinion, quite as pretty but it's still beautiful.

2. A lot of FOSS contributors are older and focused on desktop operating systems, and in those environments Microsoft was dominant for a long time. Only recently have the three way combo of Macs, iPads, and Chrome OS devices started to whittle away at that. We remember, and that's what keeps Windows as a target.

3. This spawns a thousand debates and flame wars, but Apple products are expensive. The company motto might as well be "Elegant Computing For the Upper Class". I hate them for that, I refuse to use a set of products that I can't recommend to my friends and relatives that earn less than $50k per year.

Apple should be the anti-Google for the whole world. Instead, it's the anti-Google for people able to pay through the nose.

4. Nobody is stopping you, me, or anyone else from contributing to GNUStep/OpenStep or building kickass Swift apps for Linux. Just like we don't have a right to make everyone use Rust, or make everyone dump Rust, we can't push them towards the ideas we want. For anyone that cares about Swift adoption in FOSS, the best thing to do is start writing Swift FOSS apps.

most desktop clients are web pages running in a hacked up Chromium browser.

That's a problem with our industry as a whole, and capitalism in general. Time to market outweighs almost all other concerns, and the result is endless bloat because nobody is willing to pay a higher price for efficiency.

One of the first computers I built for myself had 768 MB of RAM, and at the time that was above average. Today the task managers in Chrome and Firefox both indicate that a single Jira (a ticketing system) browser tab on my work computer uses that much memory.

[Aeder]

I don't understand. How is it useless if only Mac apps use it? Only Mac apps are making the switch.
Anyway, I'm not planning on using this, so it makes no difference to me.

If you have a multiplatform app and only the Mac version migrates to this, then it's basically the same amount of effort as just making the new system calls directly. If all your versions migrate to this, you are moving to a common code base, where you only have to account for smaller differences. This makes porting an app between platforms easier and less of a maintenance burden, and mainly benefits Apple who is the one making the bigger change to their product right now.

It's a two step process where they get devs to use an easier tool and then make that tool simplify going from win/linux to ARM mac.

[gnarlin]

Can this release of Swift help the Darling developers?

https://www.darlinghq.org/

[skierpage]

People are forgetting Apple uses Linux on their servers, iCloud isn't backed by Mac Minis running MacOS, and releasing this makes the code more portable. People can just write code, and not have to deal with platform differences, as much. (Crazy idea right?) Their devs can develop on MacOS and deploy on Linux.

Well, "as much" is key. From the announcement:

"System is a multi-platform library, not a cross-platform one. It provides a separate set of APIs and behaviors on every supported platform, closely reflecting the underlying OS interfaces. A single import will pull in the native platform interfaces specific for the targeted OS.

Our immediate goal is to simplify building cross-platform libraries and applications such as SwiftNIO and the Swift Package Manager. System does not eliminate the need for #if os() conditionals to implement cross-platform abstractions, but it does make it safer and more expressive to fill out the platform-specific parts."

So writing the Linux code paths is cleaner, but developers still have to write them.