The current state of Swift for Server and Linux

the toolchain building issue was annoying for me, but it’s not really something i anticipate having to do often, or something i would consider a real impediment to swift adoption. however, i agree that the current tooling situation is truly dreadful. swift is really difficult to use with any editor besides Xcode, which is a big problem for anyone doing linux development as i am. i’m currently stuck between Atom, which has syntax highlighting, but no LSP support, and VSCode, which has LSP support, but no syntax highlighting…

2 Likes

As a general question, what organization do you feel should be improving the Linux tooling? Has anyone tried to write an Eclipse plug-in for Swift? What organization with a vested interest in Linux should be approached about developing better tooling?

1 Like

I have been paying attention since 2017. Progress is indeed slow. There is no good general editor, and documentation.
In addition, what are the advantages of swift. Not just feelings.
How to recommend swift server to others. Am I just an iOS developer?

I've had great success with syntax highlighting with this extension: Swift Language - Visual Studio Marketplace

1 Like

If you don’t want to stick to the official plugin, Maintained Swift Development Environment delivers a nearly perfect experience on VS Code, and it’s still in active maintenance.

CLion is also a great IDE for Swift, especially on Linux and Windows — just despite the subscription fee.

5 Likes

I understand your angle, but for me, and I think a lot of people want Swift (if I'm going to use it) to be a C or C++ replacement. I'm not interested in the niche of 'server-side' Swift and there is certainly plenty of competition in that space. When I say, and a I think this applies to a lot of people, we want to write cross-platform code that includes Apple OS support on Linux or whatever, compile it and have it work. We do this today with C, C++ and to some extent Objective-C. I want the CI to be running whatever is best for the CI and targeting the platform of interest. When it comes to swift and the apple ecosystem, there is a lot of work to be done with the tooling to make it work.

I was just playing with generating a pure Swift framework without Xcode and it is truly absurd. Single compile per architecture per SDK, emitting and wrangling modules, headers and interfaces, lipo-ing results rolling those into an xcframework. Working in C and C++ this basically just works. In Swift it is DIY.

2 Likes

I think currently Swift really face some serious issues mentioned upthread, poor toolchain installation/update experience, slow progress of official support(if any) for third party IDE/tools, and lack of better open-source documentation in swift.org.

Some advices and thoughts listed below.

  • Swift.org official web site design need an overhaul, open source is a better option, but redesign is a must.

  • Swiftup project should be established ASAP, like

said; furthermore Apple should provide official Linux repos for swift-lang and windows packages through windows store/winget delivery. Swiftup should have stable/beta/dev channels like rustup and updates weekly or biweekly for community.

  • Much more investment and engagement for non-Apple developer tools such as vscode emacs vim.. and official extension like rust-analyzer is very welcome. Of course, if we can have a lightweight portable Xcode edition for Linux/Windows would be excellent, great language needs great IDE. (like C#, Java) - Microsoft already have VS for Mac :blush:

  • SwiftPM also needs better integration with Xcode and smooth cross-platform support, there're lo..ots of various swift package manager problems reported in this forum, that's NOT good. We need a cargo/crates.io similar wonderful experience, perhaps official swift.io registry is the fit target.

  • Swift.dev - an official swift playground web interface for swift compiler to experiment with the latest language. Or play.swift.org/dev.swift.org equivalents. Try https://play.rust-lang.org/

  • Besides that, does Apple have plan to make a Swift foundation like Rust Foundation from Mozilla and . NET Foundation from Microsoft? Swift foundation can help industry and community to better treat Swift a non-Apple driven language, more collaboration wider leadership involvement. See Rust core team update

Long story short, we know Apple and the core team are trying hard in making Swift, step by step.. but as for now, still not good enough to face the competitive challenge from other open source lang projects. Hurry up, fixing the piled problems, we need to change.

9 Likes

Just respond to these points:

  • Official Linux packages are under active development in apple/swift-installer-scripts, and repo work is included. I can see new pull requests being merged almost every day. For more updates, you may track this thread: RPM and Debs for Swift: Call for the Community
  • winget support is already available since Swift 5.4.2. It’s a one-line-command installing and updating experience if you run the shell as Administrator.
5 Likes

If you are looking for easy sudo apt install of .deb packages for Ubuntu and Debian based Linux distributions you can find them on the new Swift Community Apt Repository. All the latest Swift releases are available for x86 and arm64 as well as Developer Snapshots.

7 Likes

While echoing people's frustrations here. There are some silver-lining. C++ interop is coming together, C interop is great, and Python interop through PythonKit is usable to great (if use my fork, which added closure, Date, unbounded range, GIL support: GitHub - liuliu/PythonKit: Swift framework to interact with Python.). Using Bazel rules_swift on Linux is painless (SPM is pretty much Swift-only).

Installation is bad but if you use popular distribution, it is OK. VSCode / Vim support is passable with language servers, but again, it is pretty SPM centric and there is no movement on supporting more build systems (I have to resort to compile_commands.json for Bazel).

There are two bigger issues to me, in order of importance:

  1. Foundation libraries are simply not ergonomic. Comparing basic things you can do with more productive languages, it is more lines of code to do with Foundation libraries: date conversion / moving forward / backward in date, read and write files, launch a new process, parsing data with regular expression. The APIs have too much Objective-C baggage. While I appreciate the thoroughness of these APIs (Calendar / Date is really thorough!), simple uses are just not ergonomic with too much dances between objects.

  2. Deployment story. There seems to not have a good deployment story around Swift. No popular guide on cloud deployment on Swift, comparing to what I can find with Go, or how easy it is to have static binary from Rust.

None of problems above are show-stoppers, but it does accumulate. One way to resolve some of the pain points, probably is to have some business other than Apple invested in Swift on server in public manner.

It is really hard for me to resolve 1 because I don't know, out of so many convenience Swift packages, which one to trust and which one is blessed. Maybe something like folly / abseil kind kitchen sink approach would work?

5 Likes

The biggest roadblock for server-side Swift has been async/await, but thankfully this has been solved and is a great developer experience. In my mind what is still lacking are 3 things:

  1. Cross-platform Swift development especially on Windows needs to be easier to setup
  2. 3rd party IDE integration especially in VS Code needs to be improved
  3. Async tests on Linux are still not available (although there is a PR up in swift-corelibs-xctest)

Once these issues are addressed I think it is just a matter of getting the word out about how the safety, ease of use, and ergonomics of Swift make server development with it advantageous. The fundamentals are there, async/await was the catalyst, now to just smooth out those rough patches.

4 Likes

I completely agree with you about the hassle that Foundation is. I mostly try to avoid it and really feel that there is too much Objective-C ballast there.

But, thankfully, there are many people actively working on these problems. Take a look e.g. at this and this pitch. These two are focused on two of the main pain points of current Swift where we still have to rely on Foundation today and they seem to gain quite much traction and positive feedback so I hope that they will probably accepted and implemented soon(ish).
IMHO we probably need similar solutions for the other problems like file I/O, etc., but all of these pitches require a lot of time to write and implement and people are doing it in their free time so it isn’t really the fastest process. But you can clearly see that Swift is making some good progress.

4 Likes

Could you elaborate on what part of it you find difficult currently? I think that the Swift development on Windows has been getting smoother, but I am curious as to what issues you are running into with Swift 5.5.

2 Likes

I’m a little curious about the state of SwiftNIO on Windows. This is currently the biggest obstacle for Swift server development on Windows, from my point. Not everyone has access to / is accustomed to developing in Docker/WSL.

There was a fair amount of trouble with the necessary changes to NIO to get it working on Windows. All of the work that I had done for it is on GH right now on the repo (in the form of PRs). I suspect that NIO will stress the async support on WIndows, which means that it will be more difficult to get this working now. In the mean time, Id say that apple/swift-nio#1673 would be good to address first before trying to make progress again on the NIO front. The timezone difference and lack of CI integration made it difficult to continue pushing forward with everything else to be done as this work is unrelated to my actual full time job.

7 Likes

Yup, this is accurate. I will say that it's a lot easier to consider doing a smaller thunk to NIO than it was the last time @compnerd took a run at it, as we've split out the Posix I/O layer from the core NIO abstractions. This should mean that, in principle, a windows version can simply be an IOCP-based channel and loop instead of needing to make the socket-based one work.

2 Likes

I couldn't agree more. I currently try to rewrite old python code into swift script on Linux - not server based ,rather text parser and MySQL importer but after searching for documentation I see it's a big no-go and I probably end rewriting things in PHP. Very hard to find documentation, all examples I found on internet are for MacOS platform, some elements of standard libary not working on Linux, and the code provided for Apple platform cannot be simply copied and paste even if it only uses Foundation.

So I am symphatising with you and I regret I wasted over a week believing something beside mobile application can be achieved in Swift - language well-thought but not well-executed.

2 Likes

What in the standard library doesn’t work on Linux?

can’t agree more. considering how mature a project Swift NIO is, it’s shocking how little documentation there is on it. API docs are not a substitute for basic getting started guides and tutorials…

10 Likes

I mentioned this in another thread but it's probably worth repeating as part of this discussion:

Obviously Xcode's roadmap is up to Apple's Xcode team and is not something this community can steer, but I think it would be worth the SSWG reaching out to them and asking what more Swift's premier IDE can do to better support Swift packages on Linux.

I'm sure many SSWG members themselves would love to be able to build code for Linux using Xcode on their Macs, if it was even a fraction as integrated as building code for iOS.

All we'd really need is a way to set the flags Xcode uses to talk to the toolchain's compiler/sourcekit-lsp/etc, so that we could set a custom target, sysroot, and resource-dir (for the standard library). If we could bundle those in a configuration file along with the packaged sysroot/custom toolchain, that should be enough to provide a pretty great experience when building Swift programs for other platforms.

So yeah - it's clear that support for editing on Linux needs to improve, but perhaps it's also true that support for cross-platform development on the Mac also could be improved?

10 Likes