Advice for using nightly-only features in production

i had a long and (in my opinion, unproductive) debate at my workplace today over an API design problem that does not need to be discussed in detail here. suffice to say, it was a problem that would have been solved in full by typed throws. however, typed throws only exists in nightly toolchains, and so we spent a lot of time litigating unsatisfactory alternatives that use existing language features only.

i left the discussion pondering if the real strategy was to just give up on Swift 5.10 and figure out a way to use Swift nightlies in production. since we don’t deploy applications to end users, only to “server” targets, this feels tantalizingly within reach for us.

in my mind, there are three principal obstacles to using nightlies in production besides the standard “THIS IS UNSTABLE UNTESTED UNSAFE SOFTWARE” disclaimer.

  1. we need to compile our own toolchains, due to Swift’s lack of support for Amazon Linux 2023. this is feasible if we stick to released versions of Swift only, as i can actually do this at home twice a year and upload the artifact somewhere. but this workflow doesn’t scale to a weekly tempo.

  2. we need to store and distribute our own toolchains, again due to Swift’s lack of platform support. right now we are doing this pretty ad-hoc, with a private S3 bucket and an installer script. i am also having trouble imagining how we could scale this to a weekly tempo.

  3. we need to ensure that the installed version of the runtime matches the nightly version the applications were compiled with. right now, the runtimes almost always outlive the hosts, as they only change twice each year. but presumably, if we use nightlies, we need a process for upgrading the runtimes on existing hosts without having to perform a company-wide server migration every week.

has anyone had any experience with using nightlies on the server in production? if so, how did it go, and what worked for you?

2 Likes