well done. Thank you. Clearly a lot of work to do to make this actually good for programmers new to Swift on the server.
1 Like
The 14th April SSWG meeting has already set a goal of better tooling (basically, better toolchain installation experience) for 2021. I’m really looking forward to official tools like rustup for Swift toolchains so I can retire my swiftbox :)
Also, cross-compilation is useful (not necessary because we have Docker) for server side. The current toolchain layout is not doing very well with such use case (the Windows one is better than Linux and Darwin, thanks to @compnerd). I would expect a unified layout (and build script) for all platforms, which has a place for SDKs of different OS versions or completely different targets; and also standalone runtime distributions for a larger range of OSes.
6 Likes
While the concept of Sourcekit-LSP is great, in practice, I think there is room to criticise the way it has been maintained. I've seen quite a few PRs from community members that would really improve the experience with VSCode, but they seem to go unreviewed until the authors give up hope and abandons them.
Some examples:
VSCode task providers: Add vscode extension task provider by satishbabariya · Pull Request #159 · apple/sourcekit-lsp · GitHub
This would give you easy access to common commands like building a project or running tests. Currently, you need to run the command line manually in the built-in terminal or manually configure a bunch of tasks (basically, a JSON file with the command lines) for each and every project. I mean, come on... that's a pretty awful experience. There is no way Apple would accept that kind of developer experience on their platform.
It's disheartening that somebody took the time to work on it, and their work was just left to rot. I think we should be ashamed and embarrassed at how that was handled. I mean, look at this:
Anybody who has tried to use Swift with VSCode knows what an enormous improvement this would have been.
Another one, document formatting: implement DocumentFormattingRequest by Trzyipolkostkicukru · Pull Request #361 · apple/sourcekit-lsp · GitHub
The original PR is from January 2020. The author even said at that time "I am used to waiting weeks and months" 
They took the time to rebase it, but even that new PR has been sitting around since January (it is now May), and nobody has taken the time to review it.
Perhaps SourceKit-LSP needs a new maintainer, because the current situation really should not be considered acceptable. Lots of great engineers are doing fantastic work to take Swift forward, but this project is just not pulling its weight. And it's not because the community aren't interested in improving it.
28 Likes
Hi @Karl
It's fair to say the communication from me on the two PRs you brought up was poor. Thanks for bringing it up. Taking them in reverse order,
I'll follow up on the PR to summarize what I think is blocking this integration. Part of that information was on the original PR (the situation with testing swift-format). But looking back at it, I also see that I didn't write down all the issues that I had in my head. I'll do that now.
VSCode task providers: Add vscode extension task provider by satishbabariya · Pull Request #159 · apple/sourcekit-lsp · GitHub
This is more a question of VSCode integration for SwiftPM than about sourcekit-lsp itself. If someone is interested in moving this forward, I think it probably needs to be a separate thread on the forums. I would want to have feedback from the SwiftPM folks on what they think of the integration itself, and whether SourceKit-LSP's VSCode plugin is an appropriate home for it. I apologize for not following up on that PR.
Ben
14 Likes
@blangmuir thanks for bringing it up, in my opinion we need one separate repo for VSCode extension, separate from sourcekit-lsp, where contributors can work and improve the VS Extension primarily. and can be distributed to marketplace.
for example: GitHub - rust-lang/vscode-rust: Rust extension for Visual Studio Code which is separate form GitHub - rust-lang/rls: Repository for the Rust Language Server (aka RLS) and has great feature integration with vscode.
6 Likes
+1 to separate repos for SourceKit-LSP and a VSCode integration.
As an FYI to SSWG incubation process covers tools (like a VSCode plugin) as well as libraries and we'd be very happy to see something like that pitched!
10 Likes
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. 
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