April 14th, 2021

Yeah I'm fine with Discord or Slack, I am more just +1 for a community in general

-1 for discord. The lack of threads makes interleaved conversations very confusing.


Just one short feedback on:

  • How can we make Swift-on-Server more visible? Are we doing enough?

and given threads like this one about the state of swift on the server

I think it would be highly valuable to set up a repo with just markdown documents with a short intro to Linux development (most server work will be deployed there at the end of the day...) with Swift and giving links to useful technology (IDE:s, debugging tools, cross-platform considerations, ...) as well as to framework useful for server-side stuff.

I am sure there are a lot of people who could provide input to that and provide PR:s - it would become a knowledge repo for server-side development and provide a simple anchoring point / link that can be provided to anyone working with server-side Swift. I am sure there are a lot of us who keeps a link of bookmarks to useful stuff...

To start with, it could just be a structured link archive but topics could be expanded and original text written as needed going forward.

Edit: It would need to be blessed by the SSWG and perhaps linked to from swift.org too...


I don't think Swift on the server has a visibility issue, it has a perception issue. This is for many reasons, including platform support (Swift should be installable like any other package) and tooling. Real progress in overcoming those issues would go a long way towards organically increasing the visibility of Swift on the server.


Well, I can only reflect as someone who recently (in 2021) started evaluating Swift on the server - definitely agree that there are friction in getting a toolchain and up and running properly (although looking forward to try a clean 5.4 soon).

I strongly believe perception is guided by visibility - just take the linked forum discussion above - VS Code should be a clear option, but how do someone who wants to do server development find that information in the first place if they don't even know there are options? Would be nice to give people a starting point.

I can only say that from my experience there was a significant visibility issue where a lot of useful information needs a fair amount of digging and perseverance.

I found tools like heaptrack, the ability to use TSAN, found a bunch of frameworks, had to build a custom toolchain for LLDB to not trigger asserts (thanks @johannesweiss for assistance), just to mention a few things... I would have loved to have that in one place and would be happy to share such hints (like used custom memory allocators interposed and seen that it gives a nice performance boost for many use cases?)

How many people know that there is a Slack that can be joined?

Personally, I totally don't care about web related development, so references to various web frameworks which are plentiful is not very useful, but information about working server-side tools is useful!

(Server development != Web/HTTP services/apps/servers...)

And to reference the talking points at the top:

  • if we advertise a central Slack, we should take action items to make guides from recurring questions

Those guides could be hosted in this same repo for sure.

So I would propose something like the Swift Server Development Guide repo ;-)


Do you know about: GitHub - swift-server/guides: Guides for building, debugging and deploying Swift Server applications


Thanks @fabianfett - of course I don't! :joy:

Seems to be fundamentally what I propose with some massaging :slight_smile: .

Plus adding a link from Swift.org - Platform Support and/or Swift.org - Getting Started so it'd be easier to find.


So, have done a few PR:s now to that repo sharing some initial experiences, more later... Thanks for pointing it out @fabianfett - hope it can expand and get a more prominent linkage from swift.org in the future.


better tooling to get started

+1 to this! Would be amazing if on linux it was a 1 liner to install latest swift version (sudo apt-get install swift5.4).

Also quick VSCode setup on linux/macOS would be a game changer IMO. The current lsp installation process is decently hefty and still doesn't seem to autocomplete in larger packages (maybe I'm doing something wrong).

I'd imagine server devs having to screw around with getting swift set up or download Xcode just to tinker around causes a lot of interest drop-off.

So many cool things coming down the pipeline in Swift & Swift on the server it would be a shame if it was hard to start using them :)


Was this discussed? Curious what the end goal is here. @0xTim

Simply to have a guide for how to get Swift set up and deployed in Azure, similar to the AWS Guide

1 Like

It seems the biggest part is to buy and set up an instance. Swift-related parts are almost the same across all cloud providers.

I would expect more specific cases like serverless functions, container deployment, connecting to cloud-based DBs and so on. These are the really different parts between cloud providers and they also represent future directions.

This is what it is used in github actions and Azure Devops images. There are probably better ways to install latest swift virtual-environments/swift.sh at main · actions/virtual-environments (github.com)

I completely agree that a big problem is the difficulty to install Swift tooling on Unix.

I work in a cloud company called Clever Cloud, and we package our own Exherbo distributions for the exact environments we provide. As a Swift enthusiast, working a lot with Server Side Swift (mainly with Vapor), I proposed my colleagues to add Swift support.

Even though they are really experienced in Exherbo packaging, they told me it was a real pain to add Swift support, and paused it until it’s easier.

I think it’s by being present in front of people that SSS will be better known.

I really look forward to a Swift version easier to install.


thanks @RemiBardon, could you elaborate what was the difficulties they ran into? This could help prioritization in this space.


I asked them, and one said:

THE thing that is really missing and that would simplify everything and make the task a lot less unpleasant:
A real full release tarball that doesn't force you to download 20 others and extract them in the right place.

I hope this helps :crossed_fingers:t2:

thanks @RemiBardon maybe you can share with them the docker recipe we use, e.g.: swift-docker/Dockerfile at main · apple/swift-docker · GitHub

it basically does 3 steps:

  1. installs required dependencies with apt-get install
  2. downloads the release tarball (there is only one) & verifies its pgp signature
  3. extracts the tarball

I shared them the link, I'll tell you if it helps with the problem.

@tomerd Your Dockerfile says maintainers are swift-infrastructure@swift.org, my colleagues will contact this email directly to avoid polluting this topic.

But TL;DR, they'd like a tarball with all the dependencies' tarballs already inside, not a script which downloads them because the script doesn't have network access at build time.

Hey all, as someone who has started and never finished a few server side Swift projects (both Vapor and Kitura), I'll like to share my thoughts on server side Swift visibility. It is not my intention to throw cold water on the efforts for the working group, or the developers that build frameworks such as Vapor. This is just one man's opinion of the state of Swift on the server and its ability to gain a foot hold in the market.

There are a few core audiences that would utilize these frameworks: mobile developers who need an API, "modern" web app developers who are using React/Angular front ends, and developers who focus on building more traditional web apps where the server is compiling and returning HTML. I'm sure there are other use cases, but this is what I primarily deal with so I'll stick to them.

To me the current server side Swift frameworks work best for individuals building APIs to connect to mobile applications. Developers in the Apple ecosystem can easily pick up the skills necessary build APIs and necessary infrastructure to power their apps. The tutorials and examples on the web favor this use case.

The reality is that even mobile application developers need web apps, so the ability to launch web apps with server side Swift is paramount.

"Modern" web applications built using client side JavaScript libraries such as React and Angular drastically increase the complexity of developing web applications. The client side libraries require a complex build system (babel, webpack, etc) to be setup in conjunction with the server side language of choice. Not only is the development environment more complex, but deploying to the application to the cloud becomes more complex as now the client side JS needs to be complied and deployed along with the server side Swift. For novice developers this becomes an obstacle. The complexity of the environment and deployment becomes and obstacle do building/playing around with a framework. Most tutorials on the internet will focus building React/Vue/Angular apps with node back ends, so naturally new developers gravitate towards that ecosystem. From a server side Swift perspective, it would be helpful for newbies if there was more information on how structure, develop and deploy such apps as a whole. In its current state, server side swift seems like it would be a good fit for these types of applications, but it has to contend with a large body of tutorials and documentation that focuses on other languages.

For more traditional web applications where HTML is compiled and sent to the browser for rendering the current server side Swift frameworks feel incomplete. While there are templating languages such as Leaf that make it easy to build dynamic pages, there is a fair amount of infrastructure missing. For example: how do I compile/minify ES6; how do I incorporate external JavaScript libraries; how do I integrate SASS; how do I render object validation errors within a response from the server? Experienced developers may be able to piece together a solution for these issues, but the novice developers will find the experience frustrating and leave for a different framework.

My recommendation would be to focus onboarding new developers to server side Swift. Focus on making it easier for developers to build "Modern" and traditional web applications through improving integration within the development environments, building the tooling they need to make onboarding easier, and making a major push in the publishing of tutorials.


I can remember when Ruby on Rails was just released. One of the first tutorials was build a blog in 15 minutes. Before Rails a fair amount of time was needed to setup a development environment. The configuration of a Java spring application wasn't exactly a trivial task. Building a ColdFusion app still required the developer to setup databases, learn connection strings, and write SQL. Rails changed all that. The power of seeing an application with models, views, validation, etc build in 15 minutes was industry changing.

Fast forward to today. Our development environments are more complex than they ever have been. The industry ripe for a technology to simplify the process. If you want market penetration, focus on helping developers get to market easier and faster.