11 ms·

An aborted experiment with server Swift

207 points by ibotty 3y ago

liuliu 3y ago
It is a compiled language. The first time I tried Go (~10 years ago now), the core dump is even more cryptic. It is a OK language if you don't want to worry every memory allocations and wants a simpler / 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 / deno with TypeScript is much more pleasant.
- novok 3y ago
  > It is a OK language if ... Honestly, bun.js / deno with TypeScript is much more pleasant. Do you mean Swift or Golang? If golang, why is bun.js more pleasant? I'm asking as someone who doesn't know either stack.
  - liuliu 3y ago
    I meant Swift. Golang compiles fast enough to be comparable with interpreted languages coding patterns. Swift by being a compiled language, also have awkwardness here and there when it comes to type-checking where TypeScript is much more reasonable. (Go is being reasonable on type-checking by doing less on type-checking in general. Swift tries to do a lot but there are just some coherency in how certain types were treated, most infamously the existential types v.s. non-existential types).
anonymouse008 3y ago
I've had a few run-ins with Swift Server (vapor) and other OSs / arches. Most problems can be fixed with docker, however, I think different architectures are still broken even with the buildx commands. It'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.
- krhinkson 3y ago
  Doesn’t lambda support Graviton instances?
favorited 3y ago
> The linux version of swift replicates a large number of native mac frameworks using whatever mix of C and C++ gets the job done. Note that this is changing, on Darwin and Linux alike. Foundation.framework is transitioning from being a Swift interface over a C / Objective-C implementation to an Objective-C interface over a Swift implementation (https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation). 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.
- BrianHenryIE 3y ago
  > like BoringSSL, but Swift-native solutions are becoming more common. I've seen this one, "Move away from BoringSSL", actively in development (PR opened two weeks ago): https://github.com/vapor/jwt-kit/pull/99 https://github.com/vapor/jwt-kit/pull/99
  - favorited 3y ago
    Nice! It looks like they were vendoring their own copy of it, and don't have to anymore. Now they're using `swift-certificates` and `swift-asn1`, which both got open-sourced in May. That's why I try to push back when people say Apple "doesn't care" about server-side Swift – they're regularly releasing these packages that they wouldn't bother open-sourcing and maintaining if they "didn't care." Things like NIO-based implementations of IMAP and SSH, an OpenAPI generator & runtime, HTTP type abstractions, a Cassandra client, etc. Most of those are from the last year, in addition to those certificate packages. They're paying teams of full-time employee salaries to work on this stuff, including open-sourcing it.
frou_dh 3y ago
Correct me if I'm wrong, but adoption of "server-side" (aka non-App) Swift by people who weren't already Mac/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. (Or to summarise the situation in another way, it got mercilessly shunned in terms of wider community enthusiasm versus Rust)
- seec 3y ago
  Considering Apple's approach to most things it seems about right. Even if the language was extremely good and better at many non-Apple stuff, you would still be right to question its viability. Apple doing what is best for Apple regardless of what people need or what you could expect from a reasonable partner is the only reason you need to not bother with swift anywhere else than on Apple hardware. This is a company that switched off the ability to execute 32bits software on hardware that was natively capable just with an arbitrary OS update. I used to be very naive, but I would not rely on anything Apple that is not clearly linked to their hardware (so that their interest at least somewhat aligne with yours). Nowadays I would go as far as saying that if you do not directly make money from using Apple hardware, you should not bother at all. I believe most end up learning this either the hard way or by simple observation ; and one cannot come to any other conclusion than avoid Apple stuff outside of Apple hardware...
- nickpeterson 3y ago
  I seem to remember something about the original designer leaving Apple and a bit of bad blood but I might be misremembering.
  - b3morales 3y ago
    You are probably thinking of this by Chris Lattner: https://forums.swift.org/t/core-team-to-form-language-workgroup/55455/6 https://forums.swift.org/t/core-team-to-form-language-workgr... (on HN here: https://news.ycombinator.com/item?id=30416070 https://news.ycombinator.com/item?id=30416070) Swift has always been developed by a team of course, but he was the lead and probably the most public face.
danpalmer 3y ago
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. 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/server/infra experience. 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'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's plenty of specialist JVM tooling that is better). Ecosystem-wise, Swift has few but high quality libraries available in general. Apple'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. Overall, I'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.
- joe_fishfish 3y ago
  Have you looked at Kotlin? Very, very similar to Swift and interoperates very well with Java.
  - danpalmer 3y ago
    Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.
    - foobarian 3y ago
napierzaza 3y ago
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. But ultimately this does seem to be standard issues you might see working with swift and lacking inference but the dev didn't know much about Swift to work his way out of it. 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't, they relate to the repo or directory instead of the Package names in the repo's Package.swift). It seems like the dev just kind of randomly plugged away and they weren't really willing to learn anything and is holding everything at arm's length.
- ShadowBanThis01 3y ago
  I've been developing in Swift for years and have never looked in Package.swift. I also would not have known what to do about pretty much any of the problems he encountered.
  - MBCook 3y ago
    For most people Xcode just handles it for you. I’ve never touched it by hand. It can be, it’s designed for that (as opposed to something like an Xcode project file), but it doesn’t come up for most of us. Obviously it’s different if you’re not developing on a Mac. But given the usual audience of Swift users, I bet it’s hard to find good tutorials for this kind of stuff.
    - chairhairair 3y ago
      I absolutely hate the reliance on XCode for Apple stuff. I don’t want to blindly search for some checkbox widget, please just give me a config file.
      - cmrdporcupine 3y ago
        This. And this was a problem with MS/Windows development for years, too, over-reliance on Visual Studio... In fact, XCode reminds me a lot of older versions of Visual Studio, complete with terrible giant configuration dialogs, generated code galore, and subpar refactoring and external tooling support. I really don't get Mac/iOS developer's weird stockholm syndrome with XCode -- when I worked doing iOS for a period of time, I used JetBrain's AppCode and it helped take the edge off things. Granted, I haven't ventured into XCode & iOS dev since Swift came on the scene. That does look to have improved things.
jbverschoor 3y ago
"A hard to kill web server sounds like a feature", nope, sounds like a misbehaving application. Even a server which has some checks in place to clean up after a while shouldn't be taking that long. Trap signal -> stop handling new requests -> wait for the requests to finish -> (force children to quit if needed at timeout -> exit
- andoma 3y ago
  For SIGTERM I agree that it should perform a clean shutdown. Though for all software I write, I make sure that SIGINT is either not trapped at all (so the process just exits via the default signal handler) or pretty much _exit() from inside the signal handler. I can't stand programs that linger when I ^C them.
- geodel 3y ago
  I thought it was slightly tongue-in-cheek comment on Swift webserver's unreliability.
estebank 3y ago
> 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. I still don't understand why this argument is used as much as it is. Every 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't make it an "unsafe language", it makes it a flexible one that can leverage the existing ecosystem without reinventing every wheel.
- woodruffw 3y ago
  I don’t know much about Swift, but the “normal” way to handle those invariants in safe programming languages is safe constructions: unsafe operations are wrapped in safe abstractions that cannot violate the language’s semantics, no matter how they’re misused. It’s of course possible to build those abstractions incorrectly, but there’s a large language design space between “you can build safe abstractions” and “all correctly implemented abstractions are safe by construction.” If Swift falls into the first category (maybe it doesn’t!), then this seems like a fair criticism to me.
  - estebank 3y ago
    The critique was that it relies on C code for cryptography at all, no further investigation on whether the usage of those APIs is limited to providing safe abstractions. That's what I take issue with.
    - geodel 3y ago
      Well, did you see this in article copied from swift website: swift, a general-purpose programming language built using a modern approach to safety, performance, and software design patterns, to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. With these rather expansive pronouncements, one can reasonably assume Swift won't drop to C++ in the very next program after "Hello World".
pjmlp 3y ago
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. 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.
fefe23 3y ago
I found this write-up hilarious. 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. I'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. 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. Gotta admire the cojones on those people to call their product "Swift". 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'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.
- codr7 3y ago
  That's most likely 5 min for the initial build of the dependencies though, a one time thing. I find the build times on Linux quite reasonable.
  - IshKebab 3y ago
    Does that include the Swift compiler or standard library or something? I can't think of a single other language that has a 5 minute compile time for hello world...
    - Jtsummers 3y ago
      It wasn't a hello world, he said he created a hello world web app. Those are two different scopes.
      - taeric 3y ago
        I'm not sure that really changes the criticism, though? 5 minute builds for a hello world application in most any context sounds scary.
vkoskiv 3y ago
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. 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'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. 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'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. 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 && make run). The web client is still built with React, I've been thinking of rebuilding it with a single .html file and minimal JavaScript. [1] https://github.com/vkoskiv/NoMansCanvas https://github.com/vkoskiv/NoMansCanvas [2] https://pixel.vkoskiv.com https://pixel.vkoskiv.com [3] https://github.com/vkoskiv/nmc2 https://github.com/vkoskiv/nmc2
- cco 3y ago
  So funny that this came up today! I just had a developer reach out to me about whether we had a backend Swift SDK at my current company (stytch.com), or if we'd seen anybody else use us with Vapor. Googled around to get some more context on Vapor's history and sure enough, found this thread from today. Sounds like I should point him away from Vapor in your opinion?
  - favorited 3y ago
    I'm not the person you asked, but Vapor hasn't had a major version change since 2020 (Vapor 4). Vapor 5 is at least another year out, probably more like 2 or 3. Vapor 5 is definitely going to be a breaking change, but that's not a bad thing. The current major version predates async/await, actors, Sendable, macros, move-only types, variadic generics, and lots of other language features. It's been able to adopt some in incremental releases, but it wasn't designed with those things in mind.
AJRF 3y ago
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. 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. Swift 3 was almost perfect. I loved it. If they had of added async/await to Swift 3 I would use it for everything.
- miffy900 3y ago
  They tried to reinvent C++, when really they should've reinvented C and sprinkled Obj-C classes and protocols on top.
  - pjmlp 3y ago
    Christian Laettner is quite clear that Swift was a reinventation of Objective-C, and most Objective-C 2.0 improvements and latter ones, were already with Swift interoperability in mind. As for C remark, our computers have long stopped being a PDP-11 clone.
    - miffy900 3y ago
      > Christian Laettner is quite clear that Swift was a reinventation of Objective-C, and most Objective-C 2.0 improvements and latter ones, were already with Swift interoperability in mind. Yeah, I'm sure he said that at the outset in 2014 when Swift launched, but in 2023, that's not where Swift ended up. > As for C remark, our computers have long stopped being a PDP-11 clone. There is absolutely no need for a language like Swift to be as complex and bloated as it is; browse the language spec, and about 50% could be discarded and you'd still have a very complex langauge. The Swift team would do well to take inspiration from C and keep it simple; just stop adding new langauge features and let the existing language breathe. Full stop. Each new release keeps adding new features without any regard to how new ones negatively interact with previous ones. It's a language being designed by compiler engineers and not app developers. And don't get me started on the bloated language parser - editing Swift projects beyond a certain size in Xcode still gets abysmally slow. All they need to do is lock down a core subset of the language and just fix bugs; make the compiler engineers speed up the parser. That's it.
zokier 3y ago
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)
redkin 3y ago
[dead]
neonsunset 3y ago
If you love Swift and want to use it for server workloads but find Rust too involved/verbose, try C# which shares many features and newer code often looks very similar to what you would see written with Swift in cleaner/simpler part of codebases.
ppeetteerr 3y ago
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's your thing. The alternative is Kotlyn but it comes with its own set of issues. Gradle, for one, although I see that you don'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. You can also use TypeScript, if Web clients are your thing. It's pretty performant and the build systems are somewhat easier to understand. Just stay away from ReactNative. 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.
- pjmlp 3y ago
  I am quite sure you can use C# for all those use cases.
  - ppeetteerr 3y ago
    You can, but through layers of abstraction, and UI abstraction layers just complicate everything and lead you into unexpected corners.
zapnuk 3y ago
Such a shame. Swift has many beautiful language features. I give swift a try every once in a while. Problems of my last attempt: - 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's backwards compatible so it worked on my machine. - I tried to compile and statically link a hummingbird (web framework, more light weight than vapot, https://github.com/hummingbird-project/hummingbird https://github.com/hummingbird-project/hummingbird) 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 "-static-stdlib" flag only as a swiftSettings. It needed to be also a linkerSetting. 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. It's a shame because I see its potential. Fixing the (linux/windows) tooling problems would probably only take "some" 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.
vkaku 3y ago
This is great. I was wondering why Apple doesn't make any daemons on Swift for their cloud yet - as much as I see stuff bring built on Java. This sort of exercise needs to get done to bring Swift up to date with other native stacks, be it runtime or tooling.
nvm0n2 3y ago
The library safety issue comes up in the Rust article that's currently on the front page too. A safe language isn't really safe if half the libraries you use are just thin wrappers around a C library. This is one area where the JVM ecosystem definitely takes a huge lead. There just isn'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's a pure Java implementation available as well that runs well enough most of the time. That may start to change now binding to native code is getting easier, but it also may not. It's a culture thing as much as a tech thing.
jeffrallen 3y ago
s/Swift/Rust/ and you have pretty much my first, last and only Rust experience. 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. Learning is hard. Some learning contexts (Swift today on Linux apparently) are harder than others.

207 points by ibotty 3y ago

It is a compiled language. The first time I tried Go (~10 years ago now), the core dump is even more cryptic. It is a OK language if you don't want to worry every memory allocations and wants a simpler / 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 / deno with TypeScript is much more pleasant.

novok 3y ago
> It is a OK language if ... Honestly, bun.js / deno with TypeScript is much more pleasant. Do you mean Swift or Golang? If golang, why is bun.js more pleasant? I'm asking as someone who doesn't know either stack.
- liuliu 3y ago
  I meant Swift. Golang compiles fast enough to be comparable with interpreted languages coding patterns. Swift by being a compiled language, also have awkwardness here and there when it comes to type-checking where TypeScript is much more reasonable. (Go is being reasonable on type-checking by doing less on type-checking in general. Swift tries to do a lot but there are just some coherency in how certain types were treated, most infamously the existential types v.s. non-existential types).

anonymouse008 3y ago

I've had a few run-ins with Swift Server (vapor) and other OSs / arches. Most problems can be fixed with docker, however, I think different architectures are still broken even with the buildx commands. It'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.

krhinkson 3y ago
Doesn’t lambda support Graviton instances?

favorited 3y ago

> The linux version of swift replicates a large number of native mac frameworks using whatever mix of C and C++ gets the job done. Note that this is changing, on Darwin and Linux alike. Foundation.framework is transitioning from being a Swift interface over a C / Objective-C implementation to an Objective-C interface over a Swift implementation (https://github.com/apple/swift-foundation https://github.com/apple/swift-foundation). 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.

BrianHenryIE 3y ago
> like BoringSSL, but Swift-native solutions are becoming more common. I've seen this one, "Move away from BoringSSL", actively in development (PR opened two weeks ago): https://github.com/vapor/jwt-kit/pull/99 https://github.com/vapor/jwt-kit/pull/99
- favorited 3y ago
  Nice! It looks like they were vendoring their own copy of it, and don't have to anymore. Now they're using `swift-certificates` and `swift-asn1`, which both got open-sourced in May. That's why I try to push back when people say Apple "doesn't care" about server-side Swift – they're regularly releasing these packages that they wouldn't bother open-sourcing and maintaining if they "didn't care." Things like NIO-based implementations of IMAP and SSH, an OpenAPI generator & runtime, HTTP type abstractions, a Cassandra client, etc. Most of those are from the last year, in addition to those certificate packages. They're paying teams of full-time employee salaries to work on this stuff, including open-sourcing it.

frou_dh 3y ago

Correct me if I'm wrong, but adoption of "server-side" (aka non-App) Swift by people who weren't already Mac/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. (Or to summarise the situation in another way, it got mercilessly shunned in terms of wider community enthusiasm versus Rust)

seec 3y ago
Considering Apple's approach to most things it seems about right. Even if the language was extremely good and better at many non-Apple stuff, you would still be right to question its viability. Apple doing what is best for Apple regardless of what people need or what you could expect from a reasonable partner is the only reason you need to not bother with swift anywhere else than on Apple hardware. This is a company that switched off the ability to execute 32bits software on hardware that was natively capable just with an arbitrary OS update. I used to be very naive, but I would not rely on anything Apple that is not clearly linked to their hardware (so that their interest at least somewhat aligne with yours). Nowadays I would go as far as saying that if you do not directly make money from using Apple hardware, you should not bother at all. I believe most end up learning this either the hard way or by simple observation ; and one cannot come to any other conclusion than avoid Apple stuff outside of Apple hardware...
nickpeterson 3y ago
I seem to remember something about the original designer leaving Apple and a bit of bad blood but I might be misremembering.
- b3morales 3y ago
  You are probably thinking of this by Chris Lattner: https://forums.swift.org/t/core-team-to-form-language-workgroup/55455/6 https://forums.swift.org/t/core-team-to-form-language-workgr... (on HN here: https://news.ycombinator.com/item?id=30416070 https://news.ycombinator.com/item?id=30416070) Swift has always been developed by a team of course, but he was the lead and probably the most public face.

danpalmer 3y ago

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. 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/server/infra experience. 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'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's plenty of specialist JVM tooling that is better). Ecosystem-wise, Swift has few but high quality libraries available in general. Apple'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. Overall, I'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.

joe_fishfish 3y ago
Have you looked at Kotlin? Very, very similar to Swift and interoperates very well with Java.
- danpalmer 3y ago
  Briefly. There are Kotlin areas in the codebases I work on, particularly in Android code. It's not something I've needed to use yet, but I've heard good things and I'm interested to get into it once we start using it more.
  - foobarian 3y ago

napierzaza 3y ago

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. But ultimately this does seem to be standard issues you might see working with swift and lacking inference but the dev didn't know much about Swift to work his way out of it. 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't, they relate to the repo or directory instead of the Package names in the repo's Package.swift). It seems like the dev just kind of randomly plugged away and they weren't really willing to learn anything and is holding everything at arm's length.

ShadowBanThis01 3y ago
I've been developing in Swift for years and have never looked in Package.swift. I also would not have known what to do about pretty much any of the problems he encountered.
- MBCook 3y ago
  For most people Xcode just handles it for you. I’ve never touched it by hand. It can be, it’s designed for that (as opposed to something like an Xcode project file), but it doesn’t come up for most of us. Obviously it’s different if you’re not developing on a Mac. But given the usual audience of Swift users, I bet it’s hard to find good tutorials for this kind of stuff.
  - chairhairair 3y ago
    I absolutely hate the reliance on XCode for Apple stuff. I don’t want to blindly search for some checkbox widget, please just give me a config file.
    - cmrdporcupine 3y ago
      This. And this was a problem with MS/Windows development for years, too, over-reliance on Visual Studio... In fact, XCode reminds me a lot of older versions of Visual Studio, complete with terrible giant configuration dialogs, generated code galore, and subpar refactoring and external tooling support. I really don't get Mac/iOS developer's weird stockholm syndrome with XCode -- when I worked doing iOS for a period of time, I used JetBrain's AppCode and it helped take the edge off things. Granted, I haven't ventured into XCode & iOS dev since Swift came on the scene. That does look to have improved things.

jbverschoor 3y ago

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

andoma 3y ago
For SIGTERM I agree that it should perform a clean shutdown. Though for all software I write, I make sure that SIGINT is either not trapped at all (so the process just exits via the default signal handler) or pretty much _exit() from inside the signal handler. I can't stand programs that linger when I ^C them.
geodel 3y ago
I thought it was slightly tongue-in-cheek comment on Swift webserver's unreliability.

estebank 3y ago

> 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. I still don't understand why this argument is used as much as it is. Every 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't make it an "unsafe language", it makes it a flexible one that can leverage the existing ecosystem without reinventing every wheel.

woodruffw 3y ago
I don’t know much about Swift, but the “normal” way to handle those invariants in safe programming languages is safe constructions: unsafe operations are wrapped in safe abstractions that cannot violate the language’s semantics, no matter how they’re misused. It’s of course possible to build those abstractions incorrectly, but there’s a large language design space between “you can build safe abstractions” and “all correctly implemented abstractions are safe by construction.” If Swift falls into the first category (maybe it doesn’t!), then this seems like a fair criticism to me.
- estebank 3y ago
  The critique was that it relies on C code for cryptography at all, no further investigation on whether the usage of those APIs is limited to providing safe abstractions. That's what I take issue with.
  - geodel 3y ago
    Well, did you see this in article copied from swift website: swift, a general-purpose programming language built using a modern approach to safety, performance, and software design patterns, to create the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services. With these rather expansive pronouncements, one can reasonably assume Swift won't drop to C++ in the very next program after "Hello World".

pjmlp 3y ago

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. 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.

fefe23 3y ago

I found this write-up hilarious. 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. I'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. 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. Gotta admire the cojones on those people to call their product "Swift". 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'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.

codr7 3y ago
That's most likely 5 min for the initial build of the dependencies though, a one time thing. I find the build times on Linux quite reasonable.
- IshKebab 3y ago
  Does that include the Swift compiler or standard library or something? I can't think of a single other language that has a 5 minute compile time for hello world...
  - Jtsummers 3y ago
    It wasn't a hello world, he said he created a hello world web app. Those are two different scopes.
    - taeric 3y ago
      I'm not sure that really changes the criticism, though? 5 minute builds for a hello world application in most any context sounds scary.

vkoskiv 3y ago

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. 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'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. 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'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. 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 && make run). The web client is still built with React, I've been thinking of rebuilding it with a single .html file and minimal JavaScript. [1] https://github.com/vkoskiv/NoMansCanvas https://github.com/vkoskiv/NoMansCanvas [2] https://pixel.vkoskiv.com https://pixel.vkoskiv.com [3] https://github.com/vkoskiv/nmc2 https://github.com/vkoskiv/nmc2

cco 3y ago
So funny that this came up today! I just had a developer reach out to me about whether we had a backend Swift SDK at my current company (stytch.com), or if we'd seen anybody else use us with Vapor. Googled around to get some more context on Vapor's history and sure enough, found this thread from today. Sounds like I should point him away from Vapor in your opinion?
- favorited 3y ago
  I'm not the person you asked, but Vapor hasn't had a major version change since 2020 (Vapor 4). Vapor 5 is at least another year out, probably more like 2 or 3. Vapor 5 is definitely going to be a breaking change, but that's not a bad thing. The current major version predates async/await, actors, Sendable, macros, move-only types, variadic generics, and lots of other language features. It's been able to adopt some in incremental releases, but it wasn't designed with those things in mind.

AJRF 3y ago

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. 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. Swift 3 was almost perfect. I loved it. If they had of added async/await to Swift 3 I would use it for everything.

miffy900 3y ago
They tried to reinvent C++, when really they should've reinvented C and sprinkled Obj-C classes and protocols on top.
- pjmlp 3y ago
  Christian Laettner is quite clear that Swift was a reinventation of Objective-C, and most Objective-C 2.0 improvements and latter ones, were already with Swift interoperability in mind. As for C remark, our computers have long stopped being a PDP-11 clone.
  - miffy900 3y ago
    > Christian Laettner is quite clear that Swift was a reinventation of Objective-C, and most Objective-C 2.0 improvements and latter ones, were already with Swift interoperability in mind. Yeah, I'm sure he said that at the outset in 2014 when Swift launched, but in 2023, that's not where Swift ended up. > As for C remark, our computers have long stopped being a PDP-11 clone. There is absolutely no need for a language like Swift to be as complex and bloated as it is; browse the language spec, and about 50% could be discarded and you'd still have a very complex langauge. The Swift team would do well to take inspiration from C and keep it simple; just stop adding new langauge features and let the existing language breathe. Full stop. Each new release keeps adding new features without any regard to how new ones negatively interact with previous ones. It's a language being designed by compiler engineers and not app developers. And don't get me started on the bloated language parser - editing Swift projects beyond a certain size in Xcode still gets abysmally slow. All they need to do is lock down a core subset of the language and just fix bugs; make the compiler engineers speed up the parser. That's it.

zokier 3y ago

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)

redkin 3y ago

[dead]

neonsunset 3y ago

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

ppeetteerr 3y ago

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's your thing. The alternative is Kotlyn but it comes with its own set of issues. Gradle, for one, although I see that you don'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. You can also use TypeScript, if Web clients are your thing. It's pretty performant and the build systems are somewhat easier to understand. Just stay away from ReactNative. 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.

pjmlp 3y ago
I am quite sure you can use C# for all those use cases.
- ppeetteerr 3y ago
  You can, but through layers of abstraction, and UI abstraction layers just complicate everything and lead you into unexpected corners.

zapnuk 3y ago

Such a shame. Swift has many beautiful language features. I give swift a try every once in a while. Problems of my last attempt: - 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's backwards compatible so it worked on my machine. - I tried to compile and statically link a hummingbird (web framework, more light weight than vapot, https://github.com/hummingbird-project/hummingbird https://github.com/hummingbird-project/hummingbird) 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 "-static-stdlib" flag only as a swiftSettings. It needed to be also a linkerSetting. 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. It's a shame because I see its potential. Fixing the (linux/windows) tooling problems would probably only take "some" 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.

vkaku 3y ago

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

nvm0n2 3y ago

The library safety issue comes up in the Rust article that's currently on the front page too. A safe language isn't really safe if half the libraries you use are just thin wrappers around a C library. This is one area where the JVM ecosystem definitely takes a huge lead. There just isn'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's a pure Java implementation available as well that runs well enough most of the time. That may start to change now binding to native code is getting easier, but it also may not. It's a culture thing as much as a tech thing.

jeffrallen 3y ago

s/Swift/Rust/ and you have pretty much my first, last and only Rust experience. 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. Learning is hard. Some learning contexts (Swift today on Linux apparently) are harder than others.