An aborted experiment with server Swift

This is a nice critique of the Swift toolchain UX on Linux, but perhaps not of the server-side Swift developer experience in general. Each of these problems looks like the sort of thing that you solve quickly once and move on from.<p>I have recently been developing a server-side Swift application, a few months of sporadic evenings and weekends. My starting point was having a year or so of professional iOS experience and a ton of web&#x2F;server&#x2F;infra experience.<p>My experience with it has certainly been mixed, but in many ways a breath of fresh air compared to some web development ecosystems. At work I&#x27;m mostly using Java on the backend and I think Swift could be a really nice replacement for that for larger systems – the type system is better, the ergonomics are better, the developer tooling is much better at the lower end (although there&#x27;s plenty of specialist JVM tooling that is better).<p>Ecosystem-wise, Swift has few but high quality libraries available in general. Apple&#x27;s first party libraries are exceptional. Vapor is in a weird place though. Some parts are really mature and well considered for their relatively young age (e.g. parts of the ORM, async stack), others feel very early days for things that have been around for a number of years now (e.g. queues). Others feel like an impedance mismatch in the framework design – I find the Content system both too limiting and not providing enough.<p>Overall, I&#x27;m loving it for a personal project. Would I use it as the foundation of a new startup? Probably not. Would I use it in a iOS heavy company? Yeah probably. I think you can do productive, high-quality backend engineering in Swift, today.

I found this write-up hilarious.<p>I have been toying with the idea of experimenting with Swift under Linux myself for a while now. I guess this puts that idea to rest.<p>I&#x27;m not even talking about the illegal instruction thing or the capricious looking syntax changes. Just the fact that his hello world app caused 350MB of build artifacts in the filesystem, and the five minute build time for the project, are enough to turn me off of Swift.<p>I come from the good old Turbo Pascal under MS-DOS days. Building even complex applications took mere seconds on an 16 Mhz 80286 with 1 MB (yes, one megabyte) of RAM. I see no excuse for binaries to be big. This is turning me off of Go and Rust, too.<p>Gotta admire the cojones on those people to call their product &quot;Swift&quot;.<p>I come from a time where the whole application fit into 512 KB RAM. It had to. And it was good that way, because the human brain can&#x27;t grog that much context at the same time. Nowadays people are pulling in javascript frameworks larger than the whole payroll system of those old days without even a second thought.

&gt; Swift was sold to me as a safe language. But I think it would be more accurate to describe it as a thin veneer of safety over a deep pit of peril. The linux version of swift replicates a large number of native mac frameworks using whatever mix of C and C++ gets the job done.<p>I still don&#x27;t understand why this argument is used as much as it is. <i>Every</i> language ends up having to deal with either hardware or system libraries, which means that any language that provides further assurances beyond what the platform does has to have glue code to maintain its invariants. Whenever these languages have to dereference pointers they use runtime checks which would otherwise not hold its invariants. Interfacing with existing libraries is the same. Using a C library from Swift doesn&#x27;t make it an &quot;unsafe language&quot;, it makes it a flexible one that can leverage the existing ecosystem without reinventing every wheel.

&gt; The linux version of swift replicates a large number of native mac frameworks using whatever mix of C and C++ gets the job done.<p>Note that this is changing, on Darwin and Linux alike. Foundation.framework is transitioning from being a Swift interface over a C &#x2F; Objective-C implementation to an Objective-C interface over a Swift implementation (<a href="https:&#x2F;&#x2F;github.com&#x2F;apple&#x2F;swift-foundation">https:&#x2F;&#x2F;github.com&#x2F;apple&#x2F;swift-foundation</a>).<p>The language still has native C interop, and is gaining the same for C++, so it can delegate stuff like crypto to existing solutions like BoringSSL, but Swift-native solutions are becoming more common.

Correct me if I&#x27;m wrong, but adoption of &quot;server-side&quot; (aka non-App) Swift by people who weren&#x27;t already Mac&#x2F;iOS app developers seems to have been microscopic. Surely the language must be considered a colossal failure in that regard, because the goals espoused in the early years went far beyond just being an Apple person language.<p>(Or to summarise the situation in another way, it got mercilessly shunned in terms of wider community enthusiasm versus Rust)

I tried out Swift + Vapor back in 2017 when I was still a Mac user and a Swift enthusiast. I remember that at the time, I had quite a positive experience with Vapor 2 on Swift 3. I built a backend websocket server[1] for a hobby project[2], and managed to get it mostly working even though I was quite inexperienced in general.<p>The pain came later. They eventually deprecated Vapor 2, and I found that the new version of Vapor required essentially a complete rewrite, using some kind of async paradigm I couldn&#x27;t quite grok. I kept using the program I wrote for longer than I anticipated, and more pain came when I could no longer figure out how to set up the toolchain needed to even build the thing. Eventually the only way to build and run it was to use an old Ubuntu 16.04 installation.<p>This experience left me with a distaste for modern tooling with lots of churn, so last year I decided to rewrite the thing in C with minimal dependencies, so it&#x27;s guaranteed to compile with minimal modifications even in 30 years time. Really happy with the result[3]. I added new features, optimized the websocket messaging with binary messages and zlib compression, and generally made it way faster than needed.<p>It compiles in less than a second vs. the minutes it took to build the Vapor version, and the resulting binary is 324K with debug symbols, 144K when stripped + -Os, and 68K when UPX-compressed. It also uses a local SQLite db instead of a separate MySQL server, which makes deployment quite trivial (git clone &amp;&amp; make run). The web client is still built with React, I&#x27;ve been thinking of rebuilding it with a single .html file and minimal JavaScript.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;vkoskiv&#x2F;NoMansCanvas">https:&#x2F;&#x2F;github.com&#x2F;vkoskiv&#x2F;NoMansCanvas</a><p>[2] <a href="https:&#x2F;&#x2F;pixel.vkoskiv.com" rel="nofollow noreferrer">https:&#x2F;&#x2F;pixel.vkoskiv.com</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;vkoskiv&#x2F;nmc2">https:&#x2F;&#x2F;github.com&#x2F;vkoskiv&#x2F;nmc2</a>

Using swift feels like you are living in a house that once had a interior designer build it from the ground up, but then his meth head friends come over for a party one weekend and never left.<p>The direction of the language is of breaking changes that really should be breaking, secret development of features that then get thrown onto the community during a keynote and just an unfathomable amount of complexity and cruft building up in every corner. Seriously, I would hate to learn Swift now, I barely tolerate it having grown up with it.<p>Swift 3 was almost perfect. I loved it. If they had of added async&#x2F;await to Swift 3 I would use it for everything.

&quot;A hard to kill web server sounds like a feature&quot;, nope, sounds like a misbehaving application. Even a server which has some checks in place to clean up after a while shouldn&#x27;t be taking that long.<p>Trap signal -&gt; stop handling new requests -&gt; wait for the requests to finish -&gt; (force children to quit if needed at timeout -&gt; exit

Swift is a great language for the Apple ecosystem, and the use cases desired by Apple, replacing C, C++ and Objective-C on their platforms.<p>Outside of it, is as good as trying to ship a GNUStep application in Objective-C 1.0, while catching up NeXTSTEP and OS X evolution.

Such a shame. Swift has many beautiful language features.<p>I give swift a try every once in a while.<p>Problems of my last attempt:<p>- The Swift REPL (lldb to be precise) depends on libpython-dev (v3.8). WSL (ubuntu 22.04) comes with 2.7 and 3.10, so the lldb dependency depends on an old python version. The fix was to copy the 3.10 binary to the directory where lldb expects it, and rename it to libpython3.8.so. It seems that it&#x27;s backwards compatible so it worked on my machine.<p>- I tried to compile and statically link a hummingbird (web framework, more light weight than vapot, <a href="https:&#x2F;&#x2F;github.com&#x2F;hummingbird-project&#x2F;hummingbird">https:&#x2F;&#x2F;github.com&#x2F;hummingbird-project&#x2F;hummingbird</a>) hello-world example. I had a liking error. Luckilly someone in the swift forums helped me. The problem was that my package.swift file had the &quot;-static-stdlib&quot; flag only as a swiftSettings. It needed to be also a linkerSetting.<p>In the end I was able to build my example. But at this point I already spent multiple days debugging problems that are unrelated to my applicationn or the Swift language.<p>It&#x27;s a shame because I see its potential. Fixing the (linux&#x2F;windows) tooling problems would probably only take &quot;some&quot; developers. Apple has near infinite money and could sponsor them if they wanted to, but they gain little by it. Besides them, not many are invested in it.

It is a compiled language. The first time I tried Go (~10 years ago now), the core dump is even more cryptic.<p>It is a OK language if you don&#x27;t want to worry every memory allocations and wants a simpler &#x2F; effective language to work with. From the other path (scripting language and expect to see performance improvements by moving to compiled language), you will be disappointed. Honestly, bun.js &#x2F; deno with TypeScript is much more pleasant.

I&#x27;ve had a few run-ins with Swift Server (vapor) and other OSs &#x2F; arches. Most problems can be fixed with docker, however, I think different architectures are still broken even with the buildx commands. It&#x27;s caused me to abandon a lot of AWS compute services in favor of graviton instances. This means you usually lose access to Lightsail (which helps with bandwidth) and Lambda.

The binary size is outrageous but Swift is a decent language. For many of us who want a good client (iOS) and server language, Swift is a good choice. You can work in a single IDE for both and even compile to WASM if that&#x27;s your thing.<p>The alternative is Kotlyn but it comes with its own set of issues. Gradle, for one, although I see that you don&#x27;t need to use Groovy any more (Good!). However, it remains a rather messy language with a lot of necessary Java interop. And by confusing I mean that everyone is trying to use the language to build their own DSL.<p>You can also use TypeScript, if Web clients are your thing. It&#x27;s pretty performant and the build systems are somewhat easier to understand. Just stay away from ReactNative.<p>The rest, Go, C#, etc, are great server-side languages but you have to use a second or third language if you want a native app and web interface.

If you love Swift and want to use it for server workloads but find Rust too involved&#x2F;verbose, try C# which shares many features and newer code often looks very similar to what you would see written with Swift in cleaner&#x2F;simpler part of codebases.

The library safety issue comes up in the Rust article that&#x27;s currently on the front page too. A safe language isn&#x27;t really safe if half the libraries you use are just thin wrappers around a C library.<p>This is one area where the JVM ecosystem definitely takes a huge lead. There just isn&#x27;t much use of native code in that space. And often a library that does use native code will only use it optionally, for extra performance if you want, but there&#x27;s a pure Java implementation available as well that runs well enough most of the time.<p>That may start to change now binding to native code is getting easier, but it also may not. It&#x27;s a culture thing as much as a tech thing.

The title is more apt than it might appear; (server-side) Linux Swift was in the early days outcome from the short-lived aborted experiment by IBM to make it happen. Idk how much of that work has relevance on todays situation, but I found the double-meaning funny (and clever if intentional)

This is great. I was wondering why Apple doesn&#x27;t make any daemons on Swift for their cloud yet - as much as I see stuff bring built on Java.<p>This sort of exercise needs to get done to bring Swift up to date with other native stacks, be it runtime or tooling.

s&#x2F;Swift&#x2F;Rust&#x2F; and you have pretty much my first, last and only Rust experience.<p>But also, I remember being highly motivated to learn Go and debugged my way all the way through the runtime to memory allocation stuff in order to understand why I accidentally made an endless loop of type conversions that filled RAM.<p>Learning is hard. Some learning contexts (Swift today on Linux apparently) are harder than others.

I have thought of doing projects with server side swift but only because I know Swift so well. It does seem like the worst thing to do is to try and learn Swift in the non-golden case of being within MacOS.<p>But ultimately this does seem to be standard issues you might see working with swift and lacking inference but the dev didn&#x27;t know much about Swift to work his way out of it.<p>I do agree that the way Package.swift works and how it relates to your imports is really confusing. Not to mention how the name in the Package.swift relates to the package names your importing (they don&#x27;t, they relate to the repo or directory instead of the Package names in the repo&#x27;s Package.swift).<p>It seems like the dev just kind of randomly plugged away and they weren&#x27;t really willing to learn anything and is holding everything at arm&#x27;s length.