What are the pain points of deploying Swift on Server applications?

[taylorswift]

@sliemeobn

To me, way bigger hurdles to having Swift shine on the server are still tooling and ecosystem. I am thinking about things like

to compare notes, here’s what i am currently doing

@sliemeobn

swiftly being still in its infancy

i currently do not use swiftly, i just use Docker for my development environment.

@sliemeobn

SwiftPM just barely holding it together at times

i currently use SwiftPM, as there is no real alternative to it. i believe there is broad consensus on what the missing pieces in SwiftPM are but for note-keeping i’ll list them below:

• no support for shallow git clone
• cannot build app in debug mode but dependencies in release mode
• cannot use pre-built dependencies
• does not check for explicit target dependency by default, still requires a long-winded command line flag that i can never remember the spelling of
• cache invalidation for local package dependencies doesn’t seem to work very reliably at the moment

@sliemeobn

Foundation/FoundationEssentials and their platform story (despite truly heroic efforts)

i currently avoid both, but largely because they increase binary size by a lot, which also increases baseline memory consumption by the same amount.

the platform portability aspect is less important to me, mostly because a lot of this code is server-specific and therefore Linux-only.

the swift-async-algorithms package has a similar issue, which i currently solve by just copying and pasting the source code of the AsyncChannel implementation into my projects.

@sliemeobn

Data vs. ByteBuffer, "how to files?"

i currently use ArraySlice<UInt8> everywhere. it really works!

@sliemeobn

rather underwhelming guidance on "how to deploy" or even "which build settings do I need"

i use Docker to deploy, which took me a long time to figure out but it’s pretty nice once you’ve got it set up. sadly, this stuff is sparsely documented, especially the cross-compilation aspect, and i only figured it out because many kind folks on these Forums spent time helping me.

i believe we as a project need to consider documentation as a blocking requirement for evolution proposals, as we have gotten into the habit of shipping a lot of complex features while treating the educational aspect as an afterthought.

@sliemeobn

confusion around XCode... (with its own toolchain, and its own build system, and its own everything...)

i use VSCode

@sliemeobn

ecosystem struggling to keep up with rapid evolution (concurrency, ownership, macros, ...)

i write and maintain a lot of my own libraries, and open-source many of them. but obviously that’s not a scalable practice. we need to see more (financial!) investment from Apple in the library ecosystem.