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.
Agreed on all points. I’ve been using Vapor for a small work project for a couple of years and overall it’s been a good experience.
I think a lot of the author’s problems started when he bailed on Vapor and went down into the depths of SwiftNIO. I’m not really sure this was necessary. I could be wrong, but it feels to me like Vapor should let you do pretty much everything that you would need for an ActivityPub server.
Writing request handlers in Vapor with async/await is delightful - it’s really not any harder than writing Flask code. But going down below that level is pain. Lots and lots of pain.
I've actually tried to write an ActivityPub server in Vapor! I must admit I didn't get very far on the outbound part using Vapor, as the inbound part took up most of my time. My impression was that ActivityPub is way too poorly specified for a good ecosystem to develop, which is probably why we see a monoculture of Mastodon for post-based ActivityPub, and similar semi-independent monocultures for things like Reddit replacements (Lemmy?).
You're right about the NIO part. I've had to dig into it a few times, but rarely found it productive in solving problems. Vapor is pretty flexible if you drop past it's first layer of abstractions, and as long as you pick one of futures/async and stick to it, it's fairly straightforward.
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.
Strongly second the GP. I ramped up over the past year and I compare it to C# or TypeScript as far as the type safety and async features go. That whole time I kept running into QoL features and sugar that were just a joy to use.
The best side benefit for our Java heavy org was that the migration risk is very low due to excellent JVM/Java integration.
I started using Kotlin in Java 8 before the "record" keyword existed to be able to use "data class" instances. This provided very nice semantics for defining immutable structures, and the resulting classes could be imported into the existing Java codebase.
As the project progressed we started adding more in Kotlin and it massively improved developer experience.
If you work in Java and like the syntax of Swift, then you should consider using Scala. Of course convincing coworkers and managers to use it can be a problem.
Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages. I see your point about Scala, there are niceties to it in my (brief) experience, however it's not so much the syntax as it is the way that software tends to be written in Swift given the language features – I didn't find the same in Scala, it tended to be more complex than I wanted.
> Scala isn't a language I can use here, we have too much Java tooling and are conservative on new languages.
Most Java tooling works with Scala out of the box or at most needs a plugin added, and interop when calling Java from Scala is very smooth. Even if it wouldn't be acceptable for production code you might consider trying it for migration scripts, admin tools, testing etc. (though personally I'd stay away from ScalaTest et al) - that's how I got my start with Scala many years ago.
I'm at Google and we have a very consistent set of tooling across a large engineering org. I can certainly "play" with Scala, but realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with, and anything else is going to need so much work to integrate with our frameworks and systems that it's unlikely to happen.
> realistically my exploratory coding is Python notebooks or SQL – neither of which Scala is going to help with
FWIW Scala can actually be pretty useful in that space with Zeppelin - it's not quite as smooth as some of the Python-only notebooks out there, but sometimes being able to use your Java libraries in your notebooks makes up for a bit of clunkiness.
That's handy to know for the future. At the moment we have plenty of infrastructure built around Python notebooks, things like Colab, so not really feasible here I think.
How's the Scala community doing? I had the impression a couple years ago that they were losing momentum. But I also heard that Scala 3 fixed a lot of footguns that Scala developers hated, so maybe that gave them a second wind...
Scala has lost its hype status, and hype chasers will more likely use Go or Rust. Kotlin has encroached on the "better Java" category (and of course Java is now better). One of the great Scala success stories was Twitter, which has been eviscerated by an impulsive man-child, and their commitment to Scala is in doubt.
The community is a bit worried over these developments, and there has been some sniping over the disruption caused by Scala 3 (mainly to projects that relied on macros, even though macros were marked as an experimental feature).
IMO Scala is still the best language on the JVM, and last I checked there were plenty of jobs for experienced Scala devs. The foot guns weren't that severe, or at least I am used to them (in my opinion, Java coding has more foot guns due to nulls and mutable state everywhere, YMMV).
Scala 3 was more incremental, than radical, and was massively less disruptive than you see with other attempts to clean up a language (Python 3, Perl 6, anything involving PHP) due to good design, careful planning and backwards compatibility options.
I find the performance tooling and package management situation in Swift via Xcode and Instruments is, in my experience, much better than a typical out-of-the-box Java setup with a popular IDE. IDE features may be better in something like Intellij (I'm not a fan personally), but the language tooling isn't better in my experience. The swift+llvm+lldb setup is nice, Swift Package Manager is really nice, much nicer than Maven/Gradle in my experience. So yeah, better at the low end.
Linux/Windows tooling is lacking, I'll give you that, but given where Swift started from I feel like they're already outside the norm for Swift development and debatably "low end" on complexity (although not deployment, I haven't had a problem with Linux deployment).
By "high end" I mean anything that is trying to do complex runtime analysis, and the sort of tuning that you can do on the JVM that is way outside my comfort zone.
Concretely, the whole Instruments suite is far beyond anything I've managed to get out of a JetBrains IDE. I realise they have some of this stuff, but in my experience it's far from easy to use, and it costs money, which Xcode/Instruments do not.
I thought the "low end" would mean the ability to skip the huge XCode and building your project with a popular text editor/ide (that's also where Linux/Windows wouldn't have to lack)
Ah, no, I mean more the lowest barrier to entry end, i.e. what early tutorials will focus on, what newcomers to the ecosystem are expected to be using.
"Install Xcode, click New Project" is a much lower barrier to entry than setting up the toolchain in other ways.
I had a similar chuckle/double-take; admittedly it's been a few years since I looked at XCode, but it didn't strike me as much more than a Notepad wrapper around a toolchain.
> Overall, I'm loving it for a personal project. Would I use it as the foundation of a new startup? Probably not.
I know of a medium-size startup that is (attempting) building an industrial/IoT software stack on just Swift. Last I heard things weren't going great...
Adding to the recommendations for other languages you're already getting on this thread: have you tried Rust? It's type system and syntax are very similar to Swifts. You do have to deal with the borrow checker, but that typically isn't too challenging for backend web development work where logic tends to be pretty linear anyway, and in return you get a much more developed ecosystem.
Maybe I just haven't looked at the right codebases, but most of the Rust I've seen reminds me more of C++, being more dense, technical, and "noisy". The language most similar in syntax to Swift I've seen is Kotlin, but it's still more quirky and rigid than Swift is.
I think this does a disservice to Rust, but I do agree with the thrust of your point. Rust appeals to my desire for perfect engineering, Swift appeals to that side enough, but with a healthy dose of pragmatic engineering. On a perfect to pragmatic scale, Swift is in a better place than Rust in my opinion.
That roughly matches my experience trying to use Swift outside Mac and iOS development. I really like the language but the tooling and library ecosystem just aren't there. Go or Rust are not as nice to write in different ways but much more easy to get work done with. On the Rust side the language is more fiddly than Rust but with the help of Copilot the gap is not that big.
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.
Sure because most people sensibly prefer meaningful backtraces and secure and easy APIs (especially string manipulation) over saving a couple of MB of disk space.
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...
Sure, a framework that insists on building BoringSSL (on the first build, but not on incremental builds) has no impact on the long initial compile time.
> 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.
Since Go came up earlier, likely it is being contrasted with Go in this case, where Go has a fast and robust crypto library in the standard library.
And yeah, safety is clearly a continuum: hardware is not perfect, operating systems are not perfect, etc. However, being defeatist about this point is not really the way to go. We should aim to replace less safe things, especially in safety-critical parts of applications like the cryptographic operations and TLS implementations, with safer things. That's definitely why in the Rust ecosystem there's been a huge emphasis on pushing rustls forward; it's a shame to put all of the work into making safe and robust software, only to have a giant OpenSSL or BoringSSL-shaped liability sitting in the same address space as your program. Battle testing alone has proven insufficient over and over and over and over, whereas statically verifying the absence of (at least some kinds of) flaws remains very promising still.
In practice I'm sure it's obvious that to make any application secure and/or robust it's going to take multiple layers of defense where ideally there is no single point of failure. But to make progress, you have to... you know, make progress. Programming languages, toolchains, and standard libraries can't stop your operating system from being insecure, but they do have the ability to not put less safe/verified things into your address space.
Maybe some day, all of these safe Go/Rust/Swift programs will have much more robust hardware and operating systems to run in that are, themselves, "verified" to have certain security assurances. For that to really be all that meaningful, though, the programs themselves have to actually be "safe".
And hopefully, even when standard library code can't be proven to be "safe" using the language's normal mechanisms, we can still prove it using heavier duty tools. But, it certainly isn't happening over night...
> Maybe some day, all of these safe Go/Rust/Swift programs will have much more robust hardware and operating systems to run in that are, themselves, "verified" to have certain security assurances. For that to really be all that meaningful, though, the programs themselves have to actually be "safe".
On some older operating systems, the system was safer in some ways.
On the Genera operating system for Lisp machines, almost all code ran in a single address space, which was possible because Lisp is garbage collected and doesn't allow arbitrary reads and writes through arbitrary pointers. You could still write code in unsafe languages like C, but those programs did need their own address space, like in traditional OSes.
On the Burroughs MCP operating system from 1961, it had a similar mechanism. It was written in the language NEWP, which had certain unsafe constructs marked, and if code used unsafe constructs, it had to be approved by the system administrator to be executed.
That’s true, but Swift moves out of Swift code way before it has to interact with system libraries.
If you use Java, your xml parser, json parser, character encoder, date/time formatter, jdbc library, etc. likely are mostly written in a JVM language.
If you use Swift, they were (at least in the first versions) almost entirely written in (Objective-)C, so the amount of unsafe code is larger. Wrapping that in a safe language doesn’t remove all security concerns of that code.
Recently I was looking at how to do streaming I/O in Swift, reading a file line by line (but not the whole file at once). In C on Linux, this is one function, fgets, which does the buffering itself and uses SIMD-accelerated memchr to look for the newline. You call it with a file handle and it's done.
In Swift the best advice I found was https://forums.swift.org/t/read-text-file-line-by-line/28852...: use the C functions. I experimented with using FileHandle in Swift and manually scanning the return Data value for newlines, and found it added a 6x slowdown. The loop for scanning the newline does not optimize even the array access, it was calling a lookup function for every byte and there was of course no SIMD acceleration. Converting the Data value to a native Swift array did at least eliminate most of the lookup overhead, but from the profile it seems like it still does bounds checking on every access, so it doesn't optimize to SIMD or anything like that.
So that's the issue - the Foundation library isn't a portable wrapper over the native system calls, it is a thick wad of gunk that adds significant overhead to even simple programs. There was an effort to make a better API, https://github.com/apple/swift-system/, but it seems to have stalled (or perhaps an improved cross-platform API was never its goal).
Swift is currently safe in terms of type safety and dealing with pointer, I think that they've done an overall great job there. There's just few architectural decisions where doing things like accessing an array out of it's bounds crashes the app by design. In the server world, one might prefer throwing an exception you can capture instead of bringing the whole process down.
What Swift currently isn't is thread safe. They're working on it for Swift 6, but it's still probably years away, and will be a massive breaking change. Vapor has done a great job putting a thread-safe layer on top of this mess, but once you go down to say that mentioned SwiftNio level, you really need careful with concurrent memory access.
> Every language ends up having to deal with either hardware or system libraries
There's a big difference between using a C library which does extra processing + maybe uses some syscalls and doing the syscalls directly. The interface is much stricter for the system interface and the memory ownership is better defined. You don't have to think about the library using a different allocator than the app does.
The OpenBSD way of one blessed libc as the interface to the operating system is perfectly fine for their project.
The Linux kernel is a separate project from the several different libc implementations and the Linux kernel project treats the syscall API as a first class contract. If a language wants to use it directly for some reason that is an option on the table.
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.
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.
No, the critique (as I understand it) is that it's not using the system library but building it from scratch. From the description it's not binding his BoringSSL .so or .dll that exists on the system and building it, it's compiling its own pinned version and using that.
If it was using the system library and a vulnerability was found in it and the distro shipped a fixed package, then the swift coding using it would benefit from that fix without any recompilation needed (for back-patching distros at least, which is from my experience what people use in production systems). Ideally, even if you manually compiled BoringSSL for your system and the distro wasn't providing it, you could build again from a newer version or at worst patch the source of the library you originally built and rebuild it. Automatically building a specific version of a library, which may not be (and likely won't be) the latest version of that library with the latest security fixes, is a real problem.
Now, I don't know if BoringSSL was pulled in from vapor, or a dependency vapor relies on, but it is problematic to have the language libraries do this, at least if there isn't an option to do otherwise (and maybe there was, and it just wasn't surfaced through the layers as vapor built its dependencies). This might very well also be a problem with vapor and not swift, as it could be other swift modules do the right thing.
This is a good call-out, the issue around vendoring, but it seemed to me that the complaint was about using BoringSSL at all. It is a very valid complaint if dependencies are vendoring their dependencies, side-stepping your system. On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box.
> but it seemed to me that the complaint was about using BoringSSL at all.
From the article: "but it raises the bigger question of why are we compiling BoringSSL in the first place?" (emphasis mine). I think the "compiled" part of that is doing the heavy lifting.
> On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version.
This is probably a good middle ground, but it might be more harmful than helpful than if it instead just linked to direction for how to install it yourself (at the simplest level it's almost always ./configure; make; make install), because then at least it's obvious what happened and what libs are being used and you can find them (in /usr/local or wherever).
> I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box.
Anything that the install process can automate should be easy enough to provide directions and maybe some simple helper scripts for. If it's too complicated for someone to do, how is it able to be done in an automated fashion by a dependent in a way that seems to work for most people? (and if it doesn't work for most people, why even offer it)
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".
> 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).
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.
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.
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)
Yes, Swift is definitely losing the mindshare race for server side compiled languages, but to be fair it started way behind. However, just because it is not winning mindshare doesn't mean it isn't useable or that it is a failure.
The real story of server side Swift is a small but dedicated working group [0] continuing to make real measurable progress. Most of the frameworks have fallen out of favor or have been abandoned, except for Vapor, but the workgroup is active with representatives from several major tech companies. Obviously the workgroup's scope is much broader than just a single framework, and their current initiatives identify and address most of the shortcomings noted in the article. [1]
> However, just because it is not winning mindshare doesn't mean it isn't useable or that it is a failure.
A supposedly wise man once said "...you can not fool all of the people all of the time." [0] Plenty of things that are usable are also failures (e.g. Microsoft Zune was, by all accounts, a competent media device). Any technology that is not winning [sufficient] mindshare over time will be considered a failure soon enough.
[0] What, you don't know who said this? Copy pasta plus a three-second search on any search site or AI chat will set you straight.
This seems pretty reductionist and zero-sum thinking. Taking your line of reasoning to its end, one would expect there to be a single web framework, and that is evidentially not the case. Additionally you are mixing current state with future state, and most of my comment was focused at the current state of server-side Swift.
Defining "sufficient" here is important, and I think that server side Swift's progress meets a bar here that prevents it from being a failure. That might not last though.
The team developing Arc browser seems to be making a lot of headway on making Swift work for native Windows development, which is promising. Not server side, but not Apple stuff either. If they succeed and open source their work I can see using it myself for Windows desktop development.
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...
Swift is pretty clearly Lattner's baby. It's not usual for language parents to just stick around indefinitely, Bjarne Stroustrup's helicopter parenting of C++ is the exception not the rule. You won't find Kernighan at WG14 meetings, Eich isn't a key member of TC39, Hoare isn't in Rust's core team. van Rossum was BDFL for over 20 years, but did give it up.
I am reminded of the Black Mirror episode "Arkangel". Children are their own people, they're meant to go into the world and be themselves. A programming language isn't a person but its destiny is distinct from yours, and it deserves the opportunity to be its own thing and develop without you hovering over it constantly.
Mostly I was just snarking at Bjarne. My take is, Bjane wanted 1980s Unix programmers to like his semicolon language because it was kinda-sorta C compatible, but most of them didn't. And so, he's been trying to change their minds for ~40 years. It's not OK to still be here in 2023 trying to make it happen, a lot of them have retired, some of them are dead, it's not going to happen.
He tried leaving many times, and other people convinced him to stay in WG21. Your posts are nonsense and you know nothing of C++ history or semicolons.
I have like messing with server-side Swift, and I asked it at the WWDC Swift table. I was pretty much met with blank stares. Either they just have no interest in it, or I ran into the wrong engineers.
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.
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?
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.
I don't have a valid opinion on the current state of Vapor - 2017 was a long time ago, and the people developing it have worked very hard to improve it in that time.
I’m honestly surprised you got this far with swift 3 on Linux, as swift 2, 3, and 4 on Linux were all bug ridden messes. You couldn’t reasonably compile between minor versions, let alone major ones, and expect your same lines of code to have consistent behavior.
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.
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.
> 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.
"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
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.
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) 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.
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.
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).
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.
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.
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.
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.
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)
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.
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.
> 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.
I do it all the time. It is useful test to see practical use of a language on actual project at hand. If a language is not productive quickly and need lot of background there maybe nothing wrong with language. But at same time nothing wrong with devs trying to see where it takes.
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.
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.
I've worked with Xcode since it was Project Builder. And I worked with Visual C++ from the days when it was two disparate versions, one 16-bit and one 32-bit.
I used to love Visual Studio. Not MFC and its crap-heap of hokey macros, but the IDE. Project Builder was primitive as hell by comparison.
Fast-forward 20 years, and Visual Studio is still plagued by the same ridiculous UI defects it suffered from in the '90s, and Xcode is vastly improved from Project Builder.
I've heard (and evidence bears it out) that there's no one left at Apple who understands how Xcode works at this point. The giant piles of settings, many of which are specified in multiple places in multiple ways, and the corruptibility of the project files... once your project goes wrong there's often no coming back. Granted, this is far less frequent than it used to be, but still... this thing needs a ground-up rewrite behind the scenes.
I work in Xcode daily, and I would be open to trying something else if I thought it would fully integrate all of the non-coding BS that encrusts development. Specifically things like code-signing, certificates, SDK locations, simulator integration... Do third-party IDEs offer seamless support for all that stuff?
Thanks. That's why I haven't bothered to explore anything like that. It's enough of a PITA in Apple's own tools, without troubleshooting third-party hacks.
On the other hand, I did a desktop project in Qt and was shocked at how decently it generated and built an Xcode project. I did have to write a script to sign and package the app for distribution, but it wasn't as painful as plain-old iPhone development used to be simply because of the wildly unreliable certificate BS in Xcode.
Yeah some developers can't be bothered to use productive tools, there is nothing like being able to light up fire with bones and sticks, feel in control of the universe. /s
How was what I posted an anti-IDE rant when I spoke clearly about using AppCode?
The problem with XCode isn't that it's an IDE. It's that it's a shitty one, and Apple keeps trying to shove it on people by coupling the dev experience with their own IDE.
The right thing for platform makers to do is provide tools and infrastructure which can be used in a modular fashion by an ecosystem of third party tools. Offering their own IDE is fine, too, but it should not be required. This is best for the long term health of the platform, and best for developers, too.
He did not do it again. He complained that Apple tied development to ITS OWN IDE, hampering people from using OTHER IDEs.
And he is correct. The problem is that Apple's development environment is such a pile of poorly-understood spaghetti and band-aided shit that I don't think anyone at Apple has the chops (or certainly the time) to clean it up.
"The right thing for platform makers to do is provide tools and infrastructure which can be used in a modular fashion by an ecosystem of third party tools."
I'd dare to say that I have a decent experience with server-side swift using vapor at this point, shipping few production apps. I'd historically always use Xcode, but decided to try to give using Visual Studio Code with that swift extension a shot.
It's been fine, but not an order of magnitude better than using Xcode. Having copilot is nice, but the auto completion is somehow worse than Xcode from my experience so far. And the list goes on, some things are better in vscode, some in Xcode. I might eventually switch back to just using Xcode.
That Package.swift file is the build configuration file. No Xcode required. It describes how to build your program, like a Makefile. Plus, the file is itself a Swift program, where the PackageDescription API serves as a kind of domain-specific language for declaratively describing your dependencies, etc: https://developer.apple.com/documentation/packagedescription
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.