The current state of Swift for Server and Linux

[stevapple (YR Chen)]

@palmerc

This is of course because it is tied to Apple's development goals and Xcode and Swift are very much intertwined.

Apple’s development goals didn’t affect the Swift Server efforts, neither did Xcode. Xcode is a good Swift IDE — but it’s certainly not the only one, and yet to be the inevitably best one. Swift can be used stand-alone, or with other editors and IDEs, like many of us do every day.

@palmerc

The idea of it becoming a System's programming language is predicated on an open-source effort to bring it to other platforms, but like Objective-C on other platforms, it strongly dependent on Apple libraries and tooling that will never be brought to other platforms.

We have a completely open-source standard library, extensions to it, and an open-source implementation of Foundation. No Apple-specific libraries are required. Even if some types are still prefixed with NS or CG, we certainly don’t need AppKit or CoreGraphics to use them.

I also doubt why you say that “will never be brought to other platforms”. Are you just ignoring the efforts of System and DocC and many other open-sourced libraries from Apple? Linux users are already benefiting from these efforts, and Windows will certainly follow up once some critical problems are solved.

@palmerc

Swift development on other platforms will always be a novelty or second-class citizen.

Swift on Linux and Windows is already in production. Win32 developers will find Swift developing experience just at home and much safer, thanks to the type system and naming convention. Businesses are already using Swift on Linux servers. Apple itself is using it too. Swift.org is also built on server-side Swift.

@palmerc

If Apple was serious about supporting better development tools they would help develop, for example, third-party IDE support and project support in tools like CMake.

Swift has first-class support for third-party IDEs since the beginning. With sourcekit-lsp, modern editors can be easily transformed into a powerful Swift IDE. We’ve also got CLion, and the experience is nearly perfect. Swift has its IDE support built-in the compiler, and you can even tailor the experience by patching the compiler and building your custom toolchain.

CMake has already supported Swift since its 3.15 release. Swift 5.3 demos for Windows are exactly built upon CMake since SwiftPM was not ready at that time. I just don’t know why you say that. Apple cannot do everything, neither does it have to do. That’s against the spirit of open-source. We should be glad to see such an active community.

@palmerc

That just currently isn't happening which means Swift development on non-Apple devices, much like Objective-C before it, is a second-class citizen.

This is completely a pseudo conclusion. Platforms officially supported by Swift have the same, first-class support. Linux support is increasingly popular among the community and there are more and more cross-platform packages in Swift.

@palmerc

As an Apple ecosystem developer, I don't have a problem with this per se, but Apple's lack of a server oriented OS and hardware really push you into some hard choices once you go beyond trivial app development.

Given that Apple is also using many of the SSWG projects, and it has a dedicated team for Swift on Server, how can one just conclude Apple’s lack of support from “lack of a server oriented OS and hardware”? The only thing you have to do is to jump out of the trivial “Apple ecosystem” and to embrace the far wider world of server-side Swift.

[Tino]

Moaning doesn't help much, but lying to ourselves doesn't help either… it's quite common here that people rave how fast Swift is, and how great Swift performs in server side development, or in AI — but this bubble actually doesn't matter for the rest of the world.
You can give as much hearts as you want to those "this is fine" comments, but when you want to improve, first step should always be acknowledging shortcomings, so that you can decide on which to spend resources in the most efficient way (low effort, high impact).

Luckily, many people who are in charge seem to be aware of the existing flaws, but obviously, there is a strong pressure to focus changes relevant for their employer…

So, when you want to see the real picture, take off the rose-coloured classes and look beyond the ivory tower:

Swift for TensorFlow project shuts down

Who Killed IBM Kitura?

https://docs.vapor.cloud/shutdown/
...

I'm pretty sure someone will come up with "explanations" why each of those links is actually good news for Swift, but I don't think those could convince neutral observers (I'll probably not even respond to flawed arguments).
It's still remarkable how fast the project got traction, but I think the opportunity for Swift beyond Apple passed away; it is really hard to establish a programming language, so maybe focussing on iOS is not that bad.

It would have been really nice if Swift did become the thriving open source project I hoped for years ago, but for the hard reality, you don't even have to look far:

So, how exactly do you compile the compiler?

it’s been almost two weeks since the stack corruption bugs were fixed, but for whatever reason, there have not been any nightly toolchains posted to swift.org containing the fix. this is still a blocker for me, so i’ve been looking into building the swift compiler locally. however, the instructions on github seem out of date. i can only get as far as the $ ./swift/utils/build-toolchain $BUNDLE_PREFIX command in the README, which fails with --- Building earlyswiftdriver --- + swift/swift-driv…

Compared with contenders like Go, it's just incredibly hard to get Swift up and running on you own

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

Thanks for the feedback -- I don't think there's a need to point by point answer here, but what I can say is that we're very much aware of all the pain points and actively working on many of them. Believe it or not, we ourselfes are large consumers of the Swift on Server ecosystem after all, which was confirmed publicly in a number of official interviews.

And we certainly should not just "sugar coat" things, instead we focus on continued progress; and hope to avoid issues like the corruption one pointed out above -- for what it's worth sadly we had a number of bugs like this in the runtime/compiler in the async work - and they're not really Linux specific.

Progress may seem slow, but it is steady and an ongoing commitment to server and other platforms.

We have had a rough start, but we're still going for it. That's about it

For me personally we're still in a "the best is yet to come" phase, and I understand it feels slow, but we're building something truly great here

[Karl]

I think a lot of Swift's issues attracting developers from outside the Apple ecosystem is that:

(a) It's a more competitive environment, without the benefit of tight SDK integration
(b) We don't do a good-enough job at selling Swift

swift.org is thoroughly boring and doesn't get you excited to try the language. Compare it to rust-lang.org, UX-101. Apologies for the number of images.

---

Firstly, rust-lang clearly spells out the benefits of the language in short bullet points and large, striking type.

swift.org itself has a short paragraph. Basically, it says "Welcome! Swift is a programming language", and not much more than that:

Clicking "About Swift" presents you with a wall of text (zoomed out to capture as much as I could. It's even longer than this):

---

Just below the bullet-points, rust-lang.org tries to specialise for its target audience - what are you looking to develop?

Again, low information density, images, striking colours. All super easy to follow.

I'm interested in building a server. Let's click "Networking".

Meanwhile, over on swift.org, if I scroll the sidebar all the way down to the bottom, the very last entry says "Swift on Server":

---

Boom. I've scaled it down, but these graphics are enormous. This is rust-lang.org, making it very, very, very clear what the language has to offer server developers.

Sounds interesting! And just below that, some simple code snippets and links to libraries I might want to investigate:

Looks nice! That's then followed up by some meaningful testimonials:

Wow! Nice pitch - I'm interested.

Meanwhile, over at swift.org...

Would you believe it? It's another wall of text! We're on a streak, here.

That page is also extremely short and doesn't really give me many leads to follow if I want to learn more.

And at the bottom? This:

I think this is from that time we said we needed better documentation for how to get started. Admittedly, the debugging documents are really helpful, but the whole section is sort of pitiful - swept away in a dark corner where only the bravest might venture.

---

Anyway, that's enough to hopefully make the point. swift.org is not doing enough as the landing page for newcomers to the language right now. It needs an overhaul.

[ktoso (Konrad 'ktoso' Malawski 🐟🏴‍☠️)]

Thanks Karl, yes this is another thing we're quite aware of. The website could be doing a better job representing the server efforts.

---

On the point of making other ecosystems aware of the viability of Swift on the server, it might be worth pointing out that we've been working towards that and as soon as next week I'll be presenting at the well-known Scale by the Bay, a conference focused on scalable systems and functional programming. This is, to the best of my knowlage, the first time we, as the Swift team, really are going out of our "usual circles" and out to a strictly server and scalable systems conference.

• Feel free to check out my talk live (if able to) Distributed Systems with Swift or later on once the recorded sessions will be published.
• and @0xTim from the SSWG / Vapor / BrokenHands is also presenting about Swift Distributed Tracing efforts and our unique TaskLocal features there.
  • We've been collaborating on the talk and I'm excited to see his experience with Swift in production in the talk

Again, this might seem like "small" steps, but it goes hand in hand with the slow but steady meaningful progress we want to keep pushing on.

The website point is taken though -- again, something we're aware of and perhaps would be able to improve in the future.

None of this is to discard the pointed out various issues. I do want to make the thread aware of a few initiatives we have going though, like the talks linked up there.

[Karl]

It isn't just the server part of it, it just doesn't feel like swift.org is a really independent website doing its best to push the Swift language in every domain - it feels like some markdown files with a vaguely Apple-ish stylesheet.

I just find it strange because if you've seen an Apple product webpage recently, it's clear that Apple have designers who can do incredible things on the web. It's understandable that Apple doesn't treat Swift like a "product" it has to "sell", but for swift.org itself it is precisely a product which it is trying to sell, in a competitive environment.

[Max_Desiatov]

Another problem I'd like to highlight is there's no publicly hosted documentation for Swift standard library other than Featured | Apple Developer Documentation. No matter how I try to convince any of my friends and acquaintances even vaguely interested in server-side that Swift isn't "Apple-only language", all these efforts come to a halt when they start looking for basic documentation.

VSCode still doesn't have a fresh SourceKit-LSP extension published on Visual Studio Marketplace. The only one available has been last updated two years ago, and is "unofficial", receiving no support whatsoever.

I've highlighted these issues before multiple times before during the last few years, but the only response I've seen (if any) was akin to "yeah, we're aware of these issues, can't comment on this yet". And then nothing happens.

I totally understand the frustration voiced in this thread. I personally stopped following server-side Swift ecosystem long time ago due to the lack of any movement with these basic developer experience issues. I would love things to change, but the slow progress over the recent years coupled with multiple projects being shutdown doesn't make me hopeful.

I'm glad that Apple is the biggest user of Swift on the server, but I don't think that's a good indicator of the health of the ecosystem. I'm not aware of a single job board dedicated to server-side Swift. When looking for server-side Swift jobs, I'm not able to find anything here in the UK, or remote for that matter. And this is 5 years after Vapor 1.0 was released.

Do we even have a vague understanding how many companies use Swift on the server? Dozens, hundreds? I personally don't have a feeling that this number is growing, if it isn't shrinking.

The only proxy metric I could find is comparing 2019 and 2020 iOS dev surveys:

2019:

It’s also much harder for businesses to change anything as fundamental as their server-side language, so it should be no surprise to see that the level of interest is significantly lower than people’s personal opinions. Even so, it’s impossible to avoid the fact that the overwhelming majority of companies have little to no interest in Swift on the server right now.

In 2019 65.7% of responses had their interest in server-side Swift expressed as 1 out of 10.

Here's 2020:

Swift on the server is a far less popular option – particularly in the professional projects of respondents. Sixty-five percent shared that their team has no interest in exploring Swift on the server.

And these were iOS devs surveyed, who already have enough interest in Swift.

---

Important to note: I deeply appreciate all of the work that SourceKit-LSP, SwiftNIO, Vapor, SSWG and all other folks in this area are doing. I wish I could help in any way, I wish I were able to get more people involved. But we also have to admit the issues we already have. I think a lot of these issues are quantifiable. The number of open server-side Swift jobs, number of contributors to core projects are one of the few metrics we could employ.

Based on these, one could come up with some sort of strategy roadmap for how to move forward. But it seems with a lot of these points the wider community won't be able to help.

I'm glad that Karl mentioned the rust-lang.org website. It's fully open-source, and I'm pretty sure that Swift community could find good designers and copywriters in a heartbeat if swift.org was open-source as well.

Similarly, I'm not sure what's blocking SourceKit-LSP from being officially published on VSCode Marketplace. I could publish one myself, but I don't think that having two unofficial extensions is better than having one that's official.

And until these issues are resolved, I hope we could some more transparency with regards to what work is being done to resolve them (if any), and what the community could expect in the future if it can't get involved in any capacity. Of course, these are only a few issues that may not buck the trend, but I think they're some of the most important.

Without such transparency we'll continue to see frustrated posts here and there. I promise this one is the last from me personally, but I see I'm not the only one being unhappy with the trend so far.

[nikitamounier]

@ktoso

Feel free to check out my talk live (if able to) Distributed Systems with Swift

Super excited for this! I'll be sure to watch this, hopefully live if I'm able to

[nikitamounier]

And yes, fully agree that the Swift landing page could do much more in terms of "marketing" / visual candy. The landing page for Swift on the Apple developer documentation itself is infinitely more eye-catching and engaging. Are there any plans to open source swift.org itself? It feels weird to me, that for an open source project, the website where people get their first impressions of this huge collaborative project isn't itself also open source (unless there is some security issue which I do not know about). I think it could go a long way into showing to the outside world what the community really thinks Swift should represent, and engage the community into agreeing on a concrete image of what they want Swift to be.

[taylorswift]

@Tino

Compared with contenders like Go, it's just incredibly hard to get Swift up and running on you own

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…

[jonprescott (Jonathan Prescott)]

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?

[vine]

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?

[MPLewis (Mike Lewis)]

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

[stevapple (YR Chen)]

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.

[palmerc (Cameron Lowell Palmer)]

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.

[BigSur ({ @MainActor  in M1.Ultra }(Swift))]

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

@kmahar

@tomerd suggests we kick off a "swiftup" effort similar to rustup,

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

• 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.

[stevapple (YR Chen)]

@BigSur

furthermore Apple should provide official Linux repos for swift-lang and windows packages through windows store/winget delivery.

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.

[futurejones (Neil Jones)]

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.

[liuliu]

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?

[rnantes (Reid Nantes)]

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.