January 6, 2021

Server Workgroup Updates
1

Meeting notes 6th Jan 2021

Attendance: @varland, @tomerd, @kmahar, @0xTim, @tachyonics, @ktoso, @johannesweiss

Organisational

  • try to share the responsibilities for running the meetings and creating the agenda.

Ideas for 2021 SSWG Goals

  • @tomerd strategic vs. tactic (filling gaps, improve stuff we already have)

Buckets of ideas:

  • filling the gaps in the ecosystem: Fortunately gaps are getting smaller (eg. DB drivers)
  • documentation
    • thorough guide on C interop
    • the next level of guides after the getting started ones are done
    • making swift.org more useful
    • discoverability of docs
  • Concurrency (will help with Swift adoption because it will make it easier to use -- users don't like closures etc)
  • Work group related:
    • how do we engage more with the users
    • surveys to see what users think/need/want
    • growing the workgroup
  • Making SoS more attractive (eg. WASM)
  • Value proposition
    • there are many good options available, we need to clearly state what makes Swift on Server better: why choose Swift over Node, Java, Go, ...
    • Contrast with JS or not?
    • We need to write down and articulate the value really in one spot; and what can be done in Swift that is unique with Swift (“this is cool stuff you can do in Swift, and nothing else can achieve this”)
    • Sharing code between servers with devices, what are some things that we can provide automatically.
    • What are the "personas"? (I.e iOS developer vs Cloud Infra Engineer)
    • What are the friction points per persona? (what will be hard for someone coming from iOS development vs someone coming from the cloud?).
    • TODO: Roll this all up into a Manifesto style document
      • Write up the vision for are we now and where we’re headed
        • esp. with actors being so embedded in the language, we have some unique things Swift will be able to do in the future other runtimes can't do so well
      • Some tactical stuff will likely come out of this
  • Decide SSWG's priorities on topics like embedded systems, IoT, ...

General

  • @ktoso: SSWG and server community should be more active in the pitch/proposal review for concurrency
  • @tomerd: Should we break out special meetings for areas like concurrency? How should the SSWG organise itself for these "special focus areas" like concurrency
  • Ideas for focus areas that could be spun out into separate meetings:
    • Concurrency (most urgent)
    • Value proposition, should be written down.
      • We should clearly state what the strengths compared to the other languages are
      • What is unique about Swift that they cannot do (or is much harder) in other languages (@todd: example: If I need a backend for an iOS app, why should I have to program that in another language? )
      • New areas that Swift could tap into (IoT, edge, WASM, ...)
  • @konrad + backed up by @varland: at the moment it takes months of research to really find all the already existing gems in the Swift on Server ecosystem. We should make it much easier to see that there is a good ecosystem already available today that is improving constantly.

Concurrency

  • server-work-group: we believe that async/await is the way forward and we should recommend async functions/actors to be the public API.
    • this will be disruptive because a lot of APIs will change (although we have a pretty good migration story)
  • @tachyonics: Is SwiftNIO in the position to talk about Swift concurrency?
  • @johannesweiss: NIO 2 will be able to offer async/await support so it will be possible to use straight away. Although, the current versions of the pitches & proposals do not contain "custom executors" which would be required to run async/await code directly on NIO's I/O threads. That means in the current version, there would be a proliferation of thread hops which may affect performance negatively. But: proposals not finalised, relevant Swift team know that custom executors are very important to get the best performance on servers.
  • @0xTim: Vapor want to avoid breaking APIs in the near future if at all possible yet still adopt async/await for their APIs (but keep the EventLoopFuture APIs around to prevent breakage)
  • @tachyonics: how can we orchestrate the transition (let's do better than NIO 1 to 2; learnings from that)
  • @tomerd: we should be prescriptive (either "you should keep EventLoopFuture & async/await API" OR "you should break and and remove EventLoopFuture") to keep the ecosystem aligned and compatible.
  • consensus: SSWG should produce a document which details the move from EventLoopFutures to async/await & other concurrency primitives

Action items

  • Carry over from 11/11: @tomerd to contact Rosetta and Docker to see if more can be found out about both ARM based docker and the possibility of running x64 emulated docker on Apple Silicon.
  • Carry over from 9th Dec: @graskind will pick up getting the SQLite and MySQL libraries into the SSWG process.
  • @0xTim to confirm with Gwynne regarding pitches
  • server-work-group: change the guidance around APIs of libraries from "use EventLoopFuture" to "use async/await" [once Swift with async/await is out]
11 Likes