The current state of Swift for Server and Linux

Thanks, @blangmuir. This topic of Swift having a poor developer experience on Linux comes up time and time again, and the VSCode extension is a big part of it. If it could move faster, and be broadened to include more general Swift/SwiftPM-based features which don't relate to LSP by being organised as a separate repository, I think it sounds sensible to do that.

7 Likes

Thanks! Filed a bug about requirements missing from the documentation. Unfortunately it still doesn't compile, because on the snapshot compiler crashes (filed another bug), and on release toolchain it just stops without any diagnostics. :frowning:

Also the package manager sometimes flashes the text * Build Completed! at the start of the build. Filed another bug.

With regards to toolchainsā€¦ it's also a bit sad that Swift support for armv6 (i.e.: Raspberry Pi Zero) seems to be stuck at 5.1.5 for the time being. I wonder whether the core team would be interested in accepting patches to make this less of a hassle with every new release.

8 Likes

I don't understand 'swift already works great in Linux' argument. No it is not. Compare it to Rust and Go; Swift support on Linux is a joke.

Some volunteers putting a lot of effort but the trillion dollar company behind this beautiful language barely support any non-apple platform.

This 'Steve Ballmer' approach will ruin the great potential of Swift on Linux if the apple management do something about it.

2 Likes

There are many people working on Swift on Linux, both at Apple and in the broader community. I understand your annoyance, but please try to be constructive about things you'd like to see improved instead of broadly disparaging their work.

25 Likes

As someone who works full time on server-side Swift I disagree with this statement. If you feel like there are missing pieces, the SSWG would love to know your (constructive) thoughts, e.g. SSWG Annual Update 2020

14 Likes

There is an important piece you're missingā€¦ you probably meant Foundation support on Linux "is a joke" rather than Swift support per se. Which is a statement we can probably relate to, since ā€“ indeed ā€“ the reimplementation of Foundation on Linux has bugs and odd differences in semantics. That said, there are a lot of Foundation-less Swift packages which work just fine on Linux.

3 Likes

Agreed, Iā€™d view Foundation as a legacy framework when viewed in the context of swift server development which Iā€™d avoid using for new projects that go cross platform or Linux only.

Iā€™m rather happy with the progress being made on swift on Linux, but of course thereā€™s still sharp corners at places, but the SSWG (and others) are smoothening things out over time.

On another note, The important thing is to relentlessly file bugs / ergonomic issues found to the swift jira so it can be tracked, Iā€™ve in general found that at least half of the issues Iā€™ve filed actually have been fixed reasonably quickly, which isnā€™t too bad (but thatā€™s stuff in e.g. lldb support etc, not foundation).

Just moaning without filing issues (preferably reproducible ones) gives one zero points in my book.

9 Likes

I think using Swift for web applications on Linux servers is a really good thing and working well, but there seem to be missing pieces: After a constructive and very helpful discussion on the Vapor Discord channel (Vapor / Help / auth) with 0xTim and others about authentication for REST APIs and that there is no digest authentication available in Vapor, I think REST APIs are such an important thing and digest authentication (in both directions: consuming and servicing) is so important for REST APIs that maybe digest authentication (as an ā€žadd-inā€œ for SwiftNIO?) would be a nice project along the ones listed on Swift.org - Swift Server Workgroup (SSWG).

Digest authentication should be able to be implemented entirely separately of SwiftNIO, relying only on Swift Crypto. Because Digest is so relatively simple, in most language ecosystems it is implemented once per framework, as framework-specific middleware. I think this would be my recommendation here.

2 Likes

Full support for digest auth isn't really that simple given the various options it supports. So while it's not the most complex thing in the world, I think it should still have informed discussion around implementation, and that implementation should form the basis of each framework's middleware implementation. I once started an implementation but got lost in determining whether I should support the full spec or some "modern" subset, which I wasn't comfortable determining myself. I still need support, so is there some place to have that discussion? On the NIO or Vapor forums? I'd likely implement it as a Vapor middleware first and abstract out the auth later.

1 Like

Iā€™d recommend starting with Vapor: I do not particularly see a reason for this to be a NIO-scoped piece of functionality.

There's a Development channel in the Vapor discord that would probably be the best place to start discussing a Vapor implementation

1 Like

The fact is Swift as a system's programming language is not progressing particularly well. This is of course because it is tied to Apple's development goals and Xcode and Swift are very much intertwined. 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. Swift development on other platforms will always be a novelty or second-class citizen.

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

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.

1 Like

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.

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.

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.

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.

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.

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.

16 Likes

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:

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:

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

8 Likes

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 :slight_smile:

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 :slight_smile:

40 Likes

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.

33 Likes

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 :slight_smile:

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.

16 Likes

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.

16 Likes