1

Present:

  • adam-fowler, ktoso, tachyonics , 0xTim , varland , tomerd

  • @0xTim: github actions carry over; no action yet

  • @ktoso to merge async guide Swift Concurrency adoption guidelines for Swift Server Libraries by fabianfett · Pull Request #70 · swift-server/guides · GitHub it got enough review

    • done

  • Associate with Swift installers

    • reviewing the swift installer / rpm discussion

  • Static linking

    • more optimal linking
      • bigger binary but the binary works better by itself
      • uploading is easier, just one executable
      • in lambda, we could use layers, but layers are still dynamic linking time on startup and it hurts startup time of the lambda
      • dynamic linking: system where many swift excecutables can then share the runtime libraries
        • but we don’t really do that in server
    • other angle:
      • on macOS the swift runtime ships with the runtime
      • the OS contains these libraries, binaries are smaller
      • but on Linux we don’t “ship” anything; so we need to carry it with the binary; it is complex for users

  • Improving Swift and Lambda together

    • if we had a custom supported runtime
    • Todd:
      • what if AWS hosted and maintained layers for Swift?
    • Fabian:
      • that’s too hard, people would have to learn about layers and many other tools; it is too complex for people
        • Too much complexity with the layers; they need to pick the right
        • that causes link delay at startup
    • @tomerd
      • layers are not a solution
      • if it’s the menu there could be a workable solution
    • @ktoso
      • an additional complication is lack of ABI on Linux; so but we could do an image per version
    • We’d need to compare a bit, if the dynamic linking is important or not
      • Smaller binary is countered by linking time etc.
      • We summarized ideas here a bit
        • if AWS does some fancy cache already maybe we can do something like that?§
    • Docker container idea also works well
      • adds complexity though
    • Optimally we'd like Swift to be just an option in the "dropdown list" of supported platforms and we are looking into how to make this happen.
    • Summing up, there are two topics:
      • first:
        • static linking is good, regardless of other things
        • we can kill off the slim images etc
      • second:
        • how to make lambda deployment simpler

  • Amazon CDK

    • @0xTim read a bit, latest swift example;
    • first half is pretty confusing because it talks about NPM install
    • would be better to do it all on swift
    • we are stretched on time to do it though
    • Proposal: Post on forums if someone can take it
    • @varland: is that the example by Dave Mosser(?)?
      • @0xTim: yes.
      • @varland: this was the attempted simplified version
        • CDK would have to be a real community thing… so we need to call to arms

  • Swift Documentation

  • docc moved to swift.org
    • in general interested in suggesting adoption to libraries, but we don't have specific plans yet
    • docc is still maturing for our server libs use cases, so please track the proposals :slight_smile:
  • XCTest async
    • PR is open, we’re trying to address this
    • the change should be landing very soon according to the PR though
    • Vapor CI is broken right now
      • people verifying things locally
      • Some issues with Thread Sanitizer were supposedly fixed in 5.5.1
  • Swiftly — what next?
    • General consensus: Let's start making progress on coding and designing
      • Assume the RPMs and Debs will be there, design with that in mind
        • Tool still required
          • Maybe just defining interface and filling out later…?
          • Put together a design, some goals, etc?
            • Then we start coding!
        • @Adam-Fowler / Patrick can kick off a design
  • MQTTNIO - GitHub - adam-fowler/mqtt-nio: A Swift NIO MQTT v3.1.1 and v5.0 Client
  • know at least one member to pitch it
  • @adamfowler pitch it, do it :-)
  • GraphQL
4 Likes