Swift 6 released

> In general I think Swift is an underrated choice for a compiled / systems programming language on Linux and other non-Apple platforms.

I think it might be, but it's hard to know because it's hard to find good materials for learning the language. I'm looking for a book, not online tutorials.

And I won't read ebooks because I spend enough time staring at computer screens already, so don't recommend "The Swift Programming Lanugage" which is an ebook only. I bought "Mastering Swift 5.3" but it's filled with errors and has no programming exercises; after reading the whole thing, I haven't actually learned very much. There are only a couple other books available. Did I just buy the wrong one? A good programming language book should at minimum contain a few exercises to encourage the reader to actually build some simple programs.

"The Rust Programming Language" is an example of a good programming language book with basic exercises.

Having used Swift professionally for several years on Apple platforms, it's an interesting language and may have potential, but there are some fairly severe caveats.

The primary caveat is that Swift is actually two things in practice; a language, and the surrounding platform ecosystem. If you aren't inside Apple's walled garden, you don't get the platform ecosystem part, and the platform ecosystem has a lot of the functionality. A lot of the documentation is written either by Apple or by people within the walled garden who don't realize the split exists. I'm not sure how much the community beyond the walls has stepped up to build the modern GNUStep equivalent.

Some of the ecosystem stuff is (relatively) obvious; I'm pretty sure you don't get SwiftUI or any of the UIKit/AppKit (GUI) stuff. A lot is less obvious; I'm not sure, for instance, if any of the run queue stuff (that is, for scheduling async tasks) is available outside the wall. It might be? Likewise, I'm not sure if the schemes for versioning/deprecation (`@available`, `#available`...) are capable of useful operation outside the wall.

The next caveat is that the language is still evolving. They're getting better about breaking changes, but any web search for "how I mine for fish in swift" is going to lead you inevitably to stackoverflow archaeology where you'll find a page that starts with a question and a few answers. As you read down, the answers become "That doesn't work in Swift 2, new solution:", and then "No longer works in Swift 3, now you...", with the same for Swift 4, Swift 5, and presumably shortly Swift 6.

Some (well, a lot...) of the breakage is ecosystem-related, so may not apply to work outside the wall; someone at Apple seems to have an absolute mania for cosmetic changes to function signatures. Many breaking changes are things like `doFoo(foo: thing, withBar: other)` becoming `do(foo foo: thing, with bar: other)`; same arguments, just screwing around with the function signature to make it more englishy.

The last caveat (at least for this message) is: I'd argue that Swift is a "systems programming language" only in the most blurry, expansive sense. You might be able to roll your own memory allocator, for instance, but anything that uses it will probably result in a lot of call site boilerplate. I think it's potentially a decent language for writing tools and apps, but I'd be hesitant about writing an OS in Swift. It's worth noting that under the hood, ios and macos are still essentially FreeBSD (mostly C) with some C++ hardware drivers. Some of that is legacy, but some of it is also essentially unsolved problems with the ObjC/Swift model.

As an example, you can't unload a shared library that contains ObjC or Swift once it has been loaded. There may be multiple reasons for this, but at least one is that ObjC/Swift allow extensions to objects; you can runtime patch methods into an object. This means if you load a shared library, it might (say) extend `Data` (a buffer object, basically) with a `base64decode()` method. There doesn't appear to be any mechanism for removing that extension at runtime, so if you could unload the shared library, `base64decode()` would presumably become a stale pointer to who knows what. So they don't allow that.

None of this is to say that Swift is a bad language (although some of the syntax choices... `guard let foo = foo else {return}`), particularly if you're writing something that isn't going to be doing system level stuff. But there are definitely things to be aware of.

https://www.swift.org/documentation/ has more info, and if you want to learn the language:
https://docs.swift.org/swift-book/documentation/the-swift...

For the LWN editors: A "Current State of Swift in Linux: What Can You Actually Do With It?" article would be appreciated.

"Swift is an underrated choice for a compiled / systems programming language on Linux and other non-Apple platforms. It was fairly explicitly designed as a language that works with existing libraries/frameworks that expose C (or Objective-C) ABIs, but is significantly safer to write, but also has a tractable learning curve for the average busy programmer trying to get something shipped."

When it was introduced I was critical, but all that is true for Ada too, which has a very mature ecosystem, and in retrospect it is a tragedy that it was never used outside a few sectors. Rust and Go and Swift etc. are interesting, but if there had been a substantial switch to Ada instead of C++ so many current programming issues would simply not happen. Surely there were other languages of which many of the same things could be said, but Ada had the advantage of having a solid core user and developer base over most of them.

Actually it is not too late to start using Ada, which is a lot more familiar to average programmers than Rust. BTW I think that most Rust sources I have seen and written by Rust experts are written in a too-clever non-Rusty but Java-ish style, which is sad.

Are you familiar with the Java GCC frontend? It was removed in 2016, and the libraries never reached Java 1.2 support. I'm pretty sure a Swift frontend would meet the same fate. The only way to chase a fast changing standard like Java or Swift is serious funding or possibly a huge amount of volunteer support, and there wasn't really enough to clone Java or QT before upstreams released those under free licenses. GCJ at least had the argument of compiling Java to native machine code; what's the motive for a GCC based Swift frontend?