Swift Container Plugin
github.com
github.com
I'd like to think that if things went just a little bit better it would have beed the ideal programming language for anything cloud / backend related.
It's actually very surprising they managed to get that language work at all given the size of it. In that regard, i wouldn't say execution was bad. It was just unrealistic, and too much was asked from it.
My recent point of comparison is rust, which feels like a much much smaller language, despite sharing a lot of the philosophy (struct + trait, which is very similar to what swift recommends to use nowadays, and limit the use of class).
I’m not sure of the “worst execution” part. Is it even possible to make a Swift compiler that doesn’t occasionally hit those “humans immediately see what this code does, but it takes ages to compile this” moments?
I think there’s something about Swift’s type system that makes those moments unavoidable. If so, Swift is more “good idea, but too flexible to build a compiler for”, and they should have killed some of their darlings to get a better language.
If you run into trouble, you can usually improve the dev experience by declaring types. This is usually only an issue if you're using a lot of generics or overloaded methods.
let x = y.fruit(ripeness: 0.9) // <- instead of this
let x: Banana = y.fruit(ripeness: 0.9) // <- do this
Related to the above, generics are powerful, but I strongly feel they should only be used if they clarify the code. Often they obfuscate and complicate what's going on, especially if you have the interaction of two generic types.
Maybe, but in my most recent attempt to use vapor (~a year ago?), the project it created with `vapor new` had inscrutable compilation errors off the bat, and so I immediately gave up.
I think I’ve seen a C compiler crash once or maybe twice, ever.
But to be fair that front has been hugely enhanced; it’s been a very long while since I’ve since the Swift compiler crash (and I do weird stuff too).
I had to introduce a lot of helper variables to break up my longer transformation pipelines to make the compiler happy.
I hope Swift is not going the way of Scala any further, which I enjoyed a lot when I adopted it early on, but eventually turned into a monster of a language.
Btw., for recreational coding, I moved on to Elixir in the meanwhile.
It means absolutely nothing, and infuriates me, whenever I get it.
It’s usually some kind of simple syntax error, but it could be absolutely anywhere in the indicated block of code.
When I get one of those, the way I debug, is to comment out the entire block, then uncomment, in steps, until I encounter the issue.
At that point, I usually just have to spend a bunch of time, staring at the offending section, until I figure it out.
That said... It really just makes me bummed about the lack of good support for container and sandboxing technology on macOS. I know, totally different thing. But still, we'll probably never have a "native" Docker/Podman/etc. on macOS, and things like the Bazel or Nix sandbox are significantly less effective on macOS due to there just being less kernel APIs for isolating resources. e.g. There are no network namespaces. I get why, but it's surprising how limiting not having network namespaces is once you have used a platform that has an equivalent to this. For Nix it's really tricky since a lot of things need at least a working localhost inside the sandbox. I am sure increasing the surface area of XNU is not a serious consideration, for good reasons, but it's a bit of a shame.
IMO it's kind of good to have Linux as a unified container platform. It's easy to run Linux application in Windows or macOS VM. It's hard form the licensing perspective to run Windows VM and it's very hard to run macOS VM.
Typical examples, Sitecore, Sharepoint, Dynamics, Optimizelly, COM services, SQL Server.
An easy solution to the licensing issue is just having an open source userland that you can use, which Darwin sorta does. That said, since XNU syscalls are not stable, there is some awkwardness here. Either they would need to be made stable somehow (e.g. by providing something like personalities, where different processes get different syscall behavior) or the runtime would need to drop libc/base libraries in from the sky and containers would just need to assume they're available at a specific location. Either thing seems quite viable if Apple wanted to do it, IMO.
Then, using docker/orbstack, I’ve created an easy chroot shell on steroids. It mounts the current dir to a container. Great for development or sandboxing
On Linux, network namespaces allow you to get an entire separate networking environment, including a separate loopback, separate IP tables rules, etc. This is very powerful. An example of why it matters: Let's say you want to run some fully hermetic, isolated build. Sometimes it is very useful to have a network stack even if there is no actual access to a network. An example from Nix is that you can shim central package repo protocols and provide vendored packages over localhost. On macOS, the sandbox can't give you an isolated localhost, so instead Nix has an escape hatch that lets you just give specific derivations access to the regular localhost, only in the Darwin sandbox. (This obviously has the downsides you'd expect; you might connect to other processes on the machine by mistake, and you might run into port conflicts trying to listen on ports.)
Can this be resolved without more macOS features? Honestly, I bet you could do it. You'd probably need to inject a usermode network stack somehow, though, and that might just be a bit tricky to do on Darwin. Ultimately, I fully understand why Apple won't implement something like network namespaces in the kernel (it's complicated and it introduces a large surface area for bugs) but not having them is a bummer. They're awesome. I use them for a variety of things. An end user use case that I think is really cool is isolating processes into a network jail where the only route out is a Wireguard VPN tunnel.
(And to be clear, I'm not saying if Darwin had network namespaces it'd suddenly be on the same level as everything else, but it would be a great start IMO.)
OrbStack runs a (lightweight) VM internally, so it's not completely the same. That said, I personally don't want nix on my system. I'd either want it overlayed (similar to what orbstack does), or as the OS itself. Cluttering my os with nix, or any development installations drives me nuts. I prefer having my shell tool, and have many isolated / COW-toolsets for my use.
Almost no (cli/*nix) application requires more access than the CWD, and depending on how much I distrust it, I'll block network access as well.
That said, Swift and SwiftUI is super nice, so I know they know how to make great software for their OS-es. Almost. Once they fix XCode.
100%! Everyone repeat after me: "macOS Is Not A Server OS"
macOS is approximately the worst OS you can run a server on:
1. It is buggy. We had a bug in Sonoma where our CI machines would freeze on some filesystem access. The bug was fixed during Sonoma's lifetime... but only released in Sequoia. Before that we had a rare bug that plagued us for years (once every few months across several CI machines) where a process would fail to execute with "/bin/sh: cannot execute binary file", indicating an erroneous ENOEXEC from the kernel (that bug quietly disappeared)
2. It has no LTS version. See above filesystem hang. Want a fix? Cool, it comes only in the next major OS version, along with a host other changes you didn't want, and new bugs! (see point 4 below)
3. It is just poorly documented. Apple's doc are awful, poorly searcheable, they will change things and not document it, you're left with the community trying to reverse-engineer everything (I cannot recommend eclecticlight.co enough!)
4. It's just bloated with cruft for consumers. Upgrade to Sequoia 15.3? You got a free download of "Apple Intelligence" models, there go a few GBs! Again rely on the community to come up with the magic settings to disable stuff.
Ask me how I feel about macOS as a server.
(I lament the death of XServe, which could've driven more server-focused software quality)
It does not matter, Swift server-side can run (and be built) on Linux (or Windows BTW, or even embedded platforms (a subset of the language anyway))…
They have a lot of server-side projects going on. They are also increasingly using Swift on the server themselves (not on macOS).
Finally, small nitpick, but it shows you don’t care, it’s written Xcode.
It’s 11-years old and I don’t see it talked about much on HN (except for discussion on Apple libraries & bugs).
Do people like it as a language, and why?
It's the only language I've used where I have never asked "but why?". Every language feature and stdlib API just does what it says and acts in the way that makes the most sense. You're basically forced to handle every case (null, any type of error, switch cases, etc). It's highly dynamic, yet code tends to stay understandable. Apple is thoughtful about naming things and designing APIs. It's the only language I almost never need to write utility functions for - generally the type you're operating on has a method to do what you want, which you can easily discover with auto completion. Strings are sequences of graphemes, not code units or code points, and their API reflects this.
It's not perfect, but nothing else comes as close. One of the most prominent complaints - compile time explosion - really only happens in contrived examples where you're using a bunch of literals in one expression, which isn't realistic.
However, it's stuck in a single ecosystem. And let's not talk about some of the newer frameworks. Oh, and Xcode is a joke.
"Why are tuple not Hashable ?!"
Which means that you cannot have a tuple of Int `(1, 1)` as a key in a dict, and you have to make a struct that implement Hashable instead.
And
"Why do they not have a `.sum()` and I have to do `.reduce(0, +)` every time instead."
Or implement it yourself
extension Sequence where Element: AdditiveArithmetic {
func sum() -> Element { reduce(.zero, +) }
}And it is usually a pretty basic iterator standard to have it so that someone maybe not as familiar with concepts like reduce can just sum the sequence.
Or if someone not familiar with reduce read your code, and is like "what is that `.reduce(0, +)` thing everywhere!?" while instead it should be a no brainer `.sum()` <-- "yup make sense"
The compile time issues I have mainly come from TCA, but I still see them from time to time in normal code.
I have a few other syntax gripes, but largely see it as competitive with Typescript and Rust in terms of how nice it is to use. TS and Rust blow it out of the water with tooling, though.
TS to me is just an awkward patch on top of JS. It's really great! But only compared to JS. The mental model of its type system is difficult to form completely.
But yes, Swift's tooling doesn't compare.
I know you should have defined validators for every single external API, library and database, but at some level it feels silly to do all of this extra work.
In new projects, I've found that it's now very rare to come across a library that doesn't provide typings, or violates the interface.
As a side note, for some reason people like to bitch Xcode just out of habit perhaps. It's a kind of base line statement. Not my experience either. It's an excellent IDE for the current year of 2025. Helps me a lot and I build end-user facing apps, the proof is the love that users give to my apps. In other words, I have skin in the game.
I've used a lot of IDEs, and spend plenty of time using XCode. It's the worst I've used by far, and the only one where I feel it necessary to edit the majority of code in a separate editor.
Writing apps that people love makes you a good developer, but says little about the tools you use.
By the way, I am impressed by speed of Swift 6 project builds on Apple Silicon Macs. My non-trivial apps using a mix of Swift/C++/C files (hundreds and hundreds) get compiled in nearly real time. Feels good.
> ...give it some room to breathe by adding a clarifying type definition
Right, but that's the problem - it's the only language I've used where this is something you have to worry about, and it's not like the type system is more powerful. And often, the issues stem from external libraries outside my control. Better compiler errors would help mitigate the issue.
There's a lot to like about Swift, but I also think it's productive to identify the parts that compare unfavorably to other languages.
Yesterday I changed the signature of a method, and instead of complaining at the callsites I got a ”ambiguous method” error for a built in SwiftUI view modifier. Kinda hard to track down if you’re not completely aware of the changes you’ve made
* But why I cannot use @Published and other decorators in protocol declarations?
* But why must generics always be a pain in the ass, compared to .net, even in the most recent versions? 5 ways to do things, never the one you need
* But why is the person that designed the if case let value = .variable syntax not flagellated in a public square?
* But why is modern concurrency and SPM so undocumented?
It's not fool-proof either. Microsoft started the .NET Foundation, but that hasn't stopped them from causing drama by pushing self-serving decisions from the top-down. I don't really fear the same sort of behavior from Apple very much, but I definitely worry that Apple might eventually lose interest on the cross platform part for sure.
This is especially troubling because it is a fairly innovative language. If you get trapped on an unmaintained port of it, moving off of it seems like it might be hard. It's got a lot of clever ideas I haven't seen elsewhere.
I'm not sure how much of the standard library is available on the server side. However, I it's more about the engineers' interest than it is Apple's, and in that respect, the Swift ecosystem has been evolving constantly, e.g., the Swift toolchain was entirely divested from Xcode a month ago.
I can't speak for the .NET ecosystem, but your fears are unfounded. Whether Swift is useful in a cross-platform context is another question, however.
As for server side, the standard library is entirely available on other platforms, with a subset available for embedded Swift. However, it's fairly limited when compared to something like Python, and cross platform support for the other libraries like swift-foundation or SwiftNIO is more limited (IIRC SwiftNIO still doesn't support Windows properly).
I'm not sure what you're talking about with the tool chain. Apple has been producing toolchains that can run on macOS outside Xcode for years. Do you mean integration of swiftly? I think that just brought swiftly support to macOS for the first time.
Ultimately I agree with jchw; Swift would be in a much better position if it wasn't controlled by Apple's process. Features could get more than a few months work at a time. We could have dedicated teams for maintenance intensive parts of the compiler, like the type checker or the diagnostics engine, rather than a single person, or a few people that switch between focus areas.
Secondly, I don't really feel like this sort of analysis does much to assuage fears, as Apple's business strategy is always going to take priority over what its engineers individually want. Apple of today doesn't have any obvious reason to just go and axe cross-platform Swift, but if that ever changes in the future, they could do it overnight, like it was never there. Could do it tomorrow. It's not much different than an employee getting laid off abruptly.
This is especially true because in truth Apple doesn't really have a strong incentive in the grand scheme of things to support Swift on non-Apple platforms. Even if they use it in this way today, it's certainly not core to their business, and it costs them to maintain, costs that they may eventually decide benefits their competitors more than it helps them.
There's no exact heuristic here, either. Go is entirely controlled by Google and does just fine, though it has the advantage of no conflict-of-interest regarding platforms. Nobody writing Go on Linux servers really has much reason to be concerned about its future; Partly because Google has quite a lot of Go running on Linux today, and given how long it took them to e.g. transition to Python 3 internally, I can just about guarantee you that if Go died it would probably not be abrupt. Even if it was, because of the massive amount of external stakeholders there are, it would quickly be picked up by some of the large orgs that have adopted it, like Uber or Digital Ocean. The risk analysis with Go is solid: Google has no particular conflict of interest here, as they don't control the platforms that Go is primarily used on; Google has business reasons to not abruptly discontinue it and especially not on Linux servers; there are multiple massive stakeholders with a lot of skin in the game who could pick up the pieces if they called it quits.
I believe Apple could also get to that point with Swift, but they might need a different route to get there, as Swift is still largely seen as "That Apple Thing" for now, by a lot of outsiders, and that's why I think they need to cede some control. Even if they did fund a Swift foundation, they could still remain substantially in control of the language; but at least having other stakeholders with skin in the game having a seat at the table would do a lot to assuage fears about Swift's future and decouple aspects of governance from Apple in ways that would probably ultimately benefit Swift for everyone.
P.S.: And I'm not singling Apple out here, because I think any rational company has to make tough decisions sometimes, but it's obvious from their past that they definitely don't fear changes of plan. Look all the way back to OpenDoc. Being willing to make bold changes of plan feels like it's a part of their company DNA.
It has some challenges that it needs to solve to do great as a cross platform "general-purpose" programming language.
It's paradoxically high level with its syntax and ergonomics but is tied down to the same cross platform headaches like in low level languages (e.g. cpp). Linking across cross platforms requires lots of careful thought and testing. Unlike cpp, it's not super portable. It requires a hefty 30 MB runtime for some features of the language to work. Try static executable hello world.
That being said, it's possible. You can build cross platform applications with Swift, but you'd still have some of the same kinds of portability issues like in cpp but with nicer syntax and ergonomics.
Swift offers convincing ease for writing abstractions that underpin the app layer. You can be as clever or as simple as you wish, it's up to you. I prefer to keep it simple.
The other huge win for me is its ability to combine multiple language codebases at the SOURCE CODE LEVEL under a single project umbrella. Many of my projects use a mix of:
- Swift
- C++
- C
Compile time is really fast for me with Swift 6 onwards.
I use Xcode (and I am fine with it, it compiles really fast in year 2025) or VSCode (with Swift plugin) — both achieve the same thing in my experience.
Want to build a Docker Linux container? Very simple too. I fine tune and debug the project on dev macOS machine then use a Docker Linux container to build it for Linux (on a Mac or Linux) and deploy the binary. It's a single binary file by default, all libs inside. Then copy it to my NAS or deploy to remote Linux server and enjoy the speed.
Low friction, easy abstraction, fast delivery and binary machine code executable. That's what speaks to me.
I, personally, don't like it and I prefer Objective C. But I'm not professional iOS developer, so take my words with grain of salt.
[1] https://github.com/xcode-actions/swift-sh
PS: Yes, it’s a fork, but at the point I’m at there is nothing left from the original implementation. Even the way the program works is different.
It stands with .NET on Windows, or Kotlin on Android, however outside Apple is at tooling level of .NET Core early days, think .NET Core 2.0.
Mostly usable for Apple shops that need to deploy into Linux servers for their app backends, and share code.
You would think that being constrained by one company would ensure the project remains lean, but apple actually had the opposite effect. Instead of focusing on real cross-platform support, or strong language foundations, they kept piling on features that nobody asked but made nice developer conference demos.
Also Swift now has real cross-platform support. All of the libraries I create I test on macOS, Linux, Windows, android and WASM/WASI.
the swift wasm project still uses a forked compiler IIRC…
No <https://forums.swift.org/t/stdlib-and-runtime-tests-for-wasm...>.
Like I told you, I cross compile to all of the targets directly on my Mac (except windows that I do technically on my Mac, but on a VM). I could use Linux all the same.
Swift now has the concept of Swift SDK (`swift sdk install …`) and it is possible to target whatever (that has an SDK) easily. Yes, they took their sweet time, but it now works properly.
Rust also has a very extensive set of tools to generate bindings ( wasm bindgen & uniffi), and a wide ecosystem of crate for all platforms (rustsqlite, web_sys, reqwest, etc).
What's the experience like in swift for you ? What part of the swift libraries ecosystem can you use in practice, and how does bindings work ?
Let's say i want to expose an async call to a local sqlite instance on android. How would that work, and how would that look like from kotlin pov ?
Also, how is the size of the wasm packages ? how much cruft does swift need to embed ?
PS: reading the thread a bit more, it seems like you still need some special options, and some specific version of the toolchain. Is it still the case, or can i try it with the default toolchain distributed with xcode ?
I don’t know, I don’t do android dev. I just made sure my library was running on it then moved on. I know Swift is working on having bidirectional interoperability with Java[1], so I guess when they do it’ll just work? But I did not dig more on the subject.
Regarding the size I’m not sure as I never compiled a binary that is actually useful. I make sure everything runs, but as I’m building a library this goes to building the tests then running them on WASI and that’s it.
Regarding the Swift toolchain version, using swiftly[2] is recommended nowadays if you don’t need Xcode. Using the default toolchain provided by Xcode usually brings trouble when using SDKs. Using swiftly you’ll get the same experience as on Linux basically. (This will probably change, but it is like so currently.)
I'm confused..
Swift helps those who want to build end-user products.
Swift may not fit more pure paradigms.
In other words, Swift is extremely PRACTICAL – meaning create, deploy and earn living – and is squarely focused on people who need that. Naturally, not everybody will resonate with its core mission statement.
For instance, last week, I was working on bit manipulation and realized that Swift has methods to count 1 and 0 bits:
let value: UInt8 = 0b11010101
let count = value.nonzeroBitCount
One can say it achieves maximum user interaction speed.
For most critical calculations, one can easily integrate C++/C libraries – at the source code level – which Swift can compile, link and call directly.
Or drop down to unsafe features of Swift and achieve speeds comparable to C++. But that's not really needed in most of real life use cases. Convenience is what really matters when it comes to Swift.
But I gotcha now, mistook "I wonder" as "I suspect it's not"
Shame there's no macos native container system or way to make one (my understanding is the kernel isolation primitives are not there)
Plenty of work done on virtualization, and you can see the VR and GenAI roadmaps playing out to the point where they want devs building for the Apple ecosystem to be able to run stuff securely in cloud, which means they will want a cloud offering to compete, which means they'll want their own container runtime with macOS APIs but in Apple's DCs.
This is an interesting first step though - it means devs who now want to build something that talks to cloud functionality in AWS or GCP have the option to stay in a single language. If it gets traction, you can imagine they'll accelerate investment.
You lost me there.
swift package --swift-sdk x86_64-swift-linux-musl build-container-image --repository registry.example.com/myservice
No idea how to use it.