Swift isn't comfortable to use on non-Mac platforms. Because of this I can't see it taking over from Go or Rust in the server space. (I mention Rust because the language type system feels similar to Swift's and Rust is gunning for the same server space.)
If the Swift folks want adoption, they're going to have to think about the broader developer ecosystem. There's also an inherent mistrust in Apple that I think a lot of engineers have. It feels a lot like Google Dart in this respect.
I'm not sure why the discussion is always framed as Swift vs. Rust vs. Go. It's not like any of them are the dominant backend languages.
Swift can be a great choice for backends for lots of reasons (shared code between client and server, client devs become full-stack devs, etc.), and it has its drawbacks as well.
This idea that for Swift to thrive as a server language it has to win some contest against Go and Rust makes absolutely no sense to me.
> This idea that for Swift to thrive as a server language it has to win some contest against Go and Rust makes absolutely no sense to me.
That's not the point! It's that engineers have to use Mac machines to develop Swift because they're tied to a development platform. Go and Rust (simply called out as nearest neighbors) do not have this limitation. Even Microsoft has made great progress in making their tools available on other platforms.
It would be foolish to choose Swift for this reason. You're tied to Mac machines until it's been proven other platforms will have full support. It's a real handicap for Swift as a language and platform for anything beyond writing Apple software.
As it's written, this is untrue. You don't need a Mac to develop Swift. However, you really ought to have one, because the development experience is subpar on Linux:
- there is no free IDE (XCode is only for macOS, and CLion costs money - plus, it has its own bugs)
- a lot of tips and tricks on the internet (e.g. about profiling your application, etc.) heavily rely on XCode. Actually, even Apple's own documentation usually references XCode settings (or other apple tools) instead of exposing a good cross-platform interface
- the code just behaves differently on Linux than it does on the Mac (especially with Foundation)
Apart from the fact that you ignored the other two arguments I made, the LSP is not production ready. It even says so on its very own github page: https://github.com/apple/sourcekit-lsp#status
Your response to "there's no good tools for profiling Swift apps on Linux" is "you only want to do that for iOS apps anyway?" I profile server code all the time, it's simply unacceptable to think I'd ever use a language that didn't facilitate it. Go does (https://blog.golang.org/profiling-go-programs). I've not used Rust, so I can't speak to that.
You mentioned specific profiling in XCode and how that makes it necessary for server development. XCode doesn’t have much of any profiling that would be beneficial to server development - the entire topic of the submission.
But that _is_ true: the Foundation library — which because Swift has a super small core library is really kind of critical to basically any kind of program — behaves differently on Linux.
I write Swift code that runs on Linux and also on macOS or iOS, and we frequently have to have sections of "if Linux, run this code, else run this other code".
And while that's trivial to write, it's not trivial to find all the places where you have to do that.
(Nevertheless, I like Swift a lot and am using it on Linux.)
For me, lots of string and substring operations throw NotImplemented exceptions on Linux, when they just work on Mac. This kinda sucks because there’s no compiletime or linttime warning for this.
I can't even get sourcekit-lsp running without errors.
"failed to create SwiftPMWorkspace: could not find executable for 'xcrun'"
Until such time as there is a working installer that is as simple as "download XCode from the app store", I don't really consider that to be an alternative. I certainly can't recommend it to anyone on my team.
>It would be foolish to choose Swift for this reason.
There are plenty of $technology shops out there. It's trivial for a company to standardize on Apple hardware only. In fact, from the point of IT management, it makes everything easier, and when IT is easy, everyone benefits.
So I'm not sure if "foolish" is a correct assesment here.
If anything, the comparison I'd make is javascript. Just like Node, it's a nice notion that you can take your client language and use it on a server. Aside from that, does anyone think that javascript is a good language choice for backend development?
Swift has a lot more redeeming aspects than javascript does, but like this post acknowledges, they don't have its package ecosystem.
I spent the better part of last winter developing in the article author’s Vapor server-side Swift project, which I found to be absolutely delightful (shout out to Tanner and the crew, you guys are amazing!)
The following summer I got a gig doing Typescript on both client and server; mostly the experience has highlighted to me how well designed Swift feels, and how stapled on and hacked Typescript feels. Do not like.
It is stapled on, though, right? Typescript is stapled onto Javascript. There's only so much they can do. I don't mean that as an argument for Typescript, more just that there are real constraints for the language developers.
I think in some ways this is a chicken-and-egg problem. If people start working with Swift in the server space, that ecosystem will quickly evolve.
Also, Swift has great interop with the C FFI, so you have access to every C library, and every Rust library with a C API to boot.
edit:
> Aside from that, does anyone think that javascript is a good language choice for backend development?
I write a lot of swift code for personal projects, largely because it's so nice to program in, and I actually think it could be a great choice for back-end development.
I think Swift offers many of the same advantages of Rust in terms of a robust, powerful type system, and the feeling that if your code compiles, you're probably not going to have too many runtime errors (as long as you followed the rules).
Swift makes tradeoffs in favor of developer ergonomics where Rust chooses in favor of performance. In the vast majority back-end cases, Swift's performance will be good enough, and it's ease of use lets you have many of the advantages of a language like Rust but with the improved productivity of working with a higher level language.
>Also, Swift has great interop with the C FFI, so you have access to every C library, and every Rust library with a C API to boot.
I can think of maybe 3 Rust libraries that I'd want to interface with through their C api.
> I'm not sure why the discussion is always framed as Swift vs. Rust vs. Go
Because all three are in the spot of "what If I want C/C++ but better?". Even if are not direct competitors are in the space that a lot of folks wish to be (ie: Productive as scripting languages yet more performant)
Swift's ARC is also really slow compared to a lot of GC implementations, largely because it relies on a lot of atomic operations in order to work in a thread-safe manner.
It does have positive characteristics in that it's much more memory efficient than a lot of GC solutions. Also it's deterministic, which will be appreciated by anyone who's had to deal with Stop-the-world garbage collectors. It's also possible to avoid a lot of ARC overhead by avoiding reference types, which is often quite tenable due to Swift's robust support for value types. Also there's a lot of low-hanging fruit for how ARC could be optimized to cut into that overhead.
Anyway, not quite sure what I'm getting at, but the memory management story with Swift is interesting.
What you say, in other words, is that swift is biased to run on iOS. I think the tradeoff are rigth and work well in practique.
Probably if swift get more traction in server side, is where the difference from GC (that in other words, are BATCH ORIENTED memory managers vs SCALAR ORIENTED) then the need to improved things will show up.
In my case, the mistrust in Apple comes from the fact that in the almost two years I've been working on server side Swift I've seen the Swift core team constantly prioritising things that are mostly relevant for app developers (like SwiftUI and the associated function builders changes, or ABI stability), while not caring at all about things that are relevant for server side developers such as:
- coming up with an error handling solution for when your app crashes on the server that is better than "just have your load balancer restart the instance"
- creating an alternative to Foundation (recently, foundation on Linux was split into different modules, which makes the code that compiles fine on a mac break on Linux until you add additional imports ... go figure)
Have you tried breaking up your project into more, smaller modules? Incremental builds with small modules tend to be very quick.
I agree with you though regarding the priorities of the core team. I tried to reach out to several people a few months ago to get involved in contributing to improve the Linux situation, and nobody answered my messages.
Hey yes, we have a number of modules by now. Unfortunately, the reality seems to be that while splitting up reduces incremental compile time, it increases the compile time of full builds, which is especially annoying on CI (but also basically every time we update some very core module).
Also, Swift is just really not designed well for very modular apps. There are no qualified imports, there are naming conflicts, inlining stops working, etc.
The fact that Swift is at all usable on other platforms is pretty amazing, really, and it's a recent but quickly accelerating initiative.
As far as taking over from Go or Rust, I don't see someone with a greenfield project picking up Swift as the basis of some arbitrary project. Instead I see someone working on a Swift-based app -- say for iPadOS or macOS -- and needing a server-side component and deciding that it enables better skill and code re-use to implement the server-side in Swift as well.
For me, swift will be the ideal language (for syntax/style and performance ok for me). But is a deal killer that is not good on windows and no starter for android (that sadly, I need to support because is the dominant platform in my country).
If at least swift was great for backend/logic (ie: no UI on win/android/linux) it could be enough...
For what it's worth, that Reddit post is from last summer, and Swift on Linux development progresses extremely quickly. It's become pretty mature on Ubuntu by now.
I develop Swift on Linux all the time and have no issues. The only thing I don't like is that Ubuntu is the only officially supported platform. We've had to roll our own packages to support CentOS/RHEL. In spite of that, it's still quite easy to develop server-side apps using Swift on Linux. The Jetbrains CLion IDE supports it with no problem, as does VSCode.
IIRC the compiler already has internal support for coroutines. Unfortunately, I think it will probably a long time before we get user-facing features like async/await.
> Swift and Swift package manager support on Windows
Swift works on Windows with all tests passing, though I imagine it's still a lot of work to compile and run (but I haven't checked).
> Swift Package Manager resources and run scripts
I agree this would be nice. Swift PM doesn't really give you much flexibility right now.
> Backtraces
Discussed in the article (section Swift Backtrace):
> This package provides support for automatically printing crash backtraces of Swift programs on Linux. Backtraces are generated by a builtin C library libbacktrace and demangled using a private Swift runtime call. We hope to improve the implementation by adopting SE-0262 when it is approved. We are also working with the Swift core team to discuss the benefits of merging this functionality into the Swift standard library.
> Faster/incremental builds
Swift has pretty good incremental builds, especially compared to the early versions. Compile times are way better than they used to be and are continuing to improve.
We believe that a healthy open source ecosystem relies heavily on the quality its packages -> We believe that a healthy open source ecosystem relies heavily on the quality of its packages
I work for a startup that uses swift as a server language. The original idea was that both ios and the server would use the same object model which made life easier. Sadly that didn't scale as they started the android app.
We're migrating away from it slowly as we make more microservices but it's been an interesting experience.
It was my first time using swift as I am a server engineer and not an ios engineer.
Its definitely lacking in tooling and libs but it's a really nice language with a good type system (it's not great though but it's easy). It definitely has potential to be a really good server language. I'd be more comfortable using go or python but it's more fun using swift
IDLs and schema/contract definitions in common places should help with this. Stuff like protobufs are good at generating code to use/translate to object models as well.
The primary motivation for choosing the language should not be sharing object models, atleast IMO.
If you have a String that you received from elsewhere, please use
logger.info("\(stringIAlreadyHave)")
“””
Ugh.
And the payload field (think extra= in python logging) is pretty gross, you can’t even pass a [String: String] dict. Got help you if you want to dump your structured logging/data into splunk.
I am writing this from the Server Side swift conference. Despite what is said in the comments, I do not see a community waiting for Apple to push the server-side ecosystem further.
What I see is a group of passionate people building plans to move the ecosystem forward.
Yes, it is still easier to develop on MacOS than on Linux (but it is doable). Yes, having the async/await feature in the language sooner than later would help.
However, the community seems healthy and the projects are interesting and well designed.
I'm using vapor on a production app and really enjoying the experience. I do see there is a lot of work to do in the community though. Where would one start out to help with the efforts?
I would start by both getting involved in the server part of the Swift forum (https://forums.swift.org/c/server), and by checking simple tickets you could help with on those projects Github.
55 comments
[ 3.9 ms ] story [ 206 ms ] threadIf the Swift folks want adoption, they're going to have to think about the broader developer ecosystem. There's also an inherent mistrust in Apple that I think a lot of engineers have. It feels a lot like Google Dart in this respect.
https://www.jetbrains.com/objc/
Swift can be a great choice for backends for lots of reasons (shared code between client and server, client devs become full-stack devs, etc.), and it has its drawbacks as well.
This idea that for Swift to thrive as a server language it has to win some contest against Go and Rust makes absolutely no sense to me.
That's not the point! It's that engineers have to use Mac machines to develop Swift because they're tied to a development platform. Go and Rust (simply called out as nearest neighbors) do not have this limitation. Even Microsoft has made great progress in making their tools available on other platforms.
It would be foolish to choose Swift for this reason. You're tied to Mac machines until it's been proven other platforms will have full support. It's a real handicap for Swift as a language and platform for anything beyond writing Apple software.
That is patently untrue.
- there is no free IDE (XCode is only for macOS, and CLion costs money - plus, it has its own bugs)
- a lot of tips and tricks on the internet (e.g. about profiling your application, etc.) heavily rely on XCode. Actually, even Apple's own documentation usually references XCode settings (or other apple tools) instead of exposing a good cross-platform interface
- the code just behaves differently on Linux than it does on the Mac (especially with Foundation)
And what server side code “behaves differently”
Where does it say it’s not “production ready” on the GitHub link?
Spend a bit of time on the Vapor Discord channel and read about all the quirks Linux users have to deal with that the rest of us don’t.
(My impression is that it’s due to Foundation libs.)
I write Swift code that runs on Linux and also on macOS or iOS, and we frequently have to have sections of "if Linux, run this code, else run this other code".
And while that's trivial to write, it's not trivial to find all the places where you have to do that.
(Nevertheless, I like Swift a lot and am using it on Linux.)
Instruments, which ships with Xcode, is quite powerful.
For me, lots of string and substring operations throw NotImplemented exceptions on Linux, when they just work on Mac. This kinda sucks because there’s no compiletime or linttime warning for this.
You don't have XCode on linux, but I've never heard of someone being disappointed about that.
And does Apple have to be the source of all tooling? Is that how it is for Rust and Go? It's certainly not for Javascript and Python tools.
"failed to create SwiftPMWorkspace: could not find executable for 'xcrun'"
Until such time as there is a working installer that is as simple as "download XCode from the app store", I don't really consider that to be an alternative. I certainly can't recommend it to anyone on my team.
There are plenty of $technology shops out there. It's trivial for a company to standardize on Apple hardware only. In fact, from the point of IT management, it makes everything easier, and when IT is easy, everyone benefits.
So I'm not sure if "foolish" is a correct assesment here.
Swift has a lot more redeeming aspects than javascript does, but like this post acknowledges, they don't have its package ecosystem.
The following summer I got a gig doing Typescript on both client and server; mostly the experience has highlighted to me how well designed Swift feels, and how stapled on and hacked Typescript feels. Do not like.
It is stapled on, though, right? Typescript is stapled onto Javascript. There's only so much they can do. I don't mean that as an argument for Typescript, more just that there are real constraints for the language developers.
(Burn karma burn!)
I think in some ways this is a chicken-and-egg problem. If people start working with Swift in the server space, that ecosystem will quickly evolve.
Also, Swift has great interop with the C FFI, so you have access to every C library, and every Rust library with a C API to boot.
edit:
> Aside from that, does anyone think that javascript is a good language choice for backend development?
I write a lot of swift code for personal projects, largely because it's so nice to program in, and I actually think it could be a great choice for back-end development.
I think Swift offers many of the same advantages of Rust in terms of a robust, powerful type system, and the feeling that if your code compiles, you're probably not going to have too many runtime errors (as long as you followed the rules).
Swift makes tradeoffs in favor of developer ergonomics where Rust chooses in favor of performance. In the vast majority back-end cases, Swift's performance will be good enough, and it's ease of use lets you have many of the advantages of a language like Rust but with the improved productivity of working with a higher level language.
Because all three are in the spot of "what If I want C/C++ but better?". Even if are not direct competitors are in the space that a lot of folks wish to be (ie: Productive as scripting languages yet more performant)
It does have positive characteristics in that it's much more memory efficient than a lot of GC solutions. Also it's deterministic, which will be appreciated by anyone who's had to deal with Stop-the-world garbage collectors. It's also possible to avoid a lot of ARC overhead by avoiding reference types, which is often quite tenable due to Swift's robust support for value types. Also there's a lot of low-hanging fruit for how ARC could be optimized to cut into that overhead.
Anyway, not quite sure what I'm getting at, but the memory management story with Swift is interesting.
Probably if swift get more traction in server side, is where the difference from GC (that in other words, are BATCH ORIENTED memory managers vs SCALAR ORIENTED) then the need to improved things will show up.
- support for platforms beyond Ubuntu
- fixing the myriad weird bugs on Linux (here's two particularly bad examples: https://bugs.swift.org/browse/SR-10613, https://bugs.swift.org/browse/SR-10344)
- coming up with an error handling solution for when your app crashes on the server that is better than "just have your load balancer restart the instance"
- improving compile times for large applications
- improving modularisation concerns (e.g. submodules)
- creating an alternative to Foundation (recently, foundation on Linux was split into different modules, which makes the code that compiles fine on a mac break on Linux until you add additional imports ... go figure)
Have you tried breaking up your project into more, smaller modules? Incremental builds with small modules tend to be very quick.
I agree with you though regarding the priorities of the core team. I tried to reach out to several people a few months ago to get involved in contributing to improve the Linux situation, and nobody answered my messages.
Also, Swift is just really not designed well for very modular apps. There are no qualified imports, there are naming conflicts, inlining stops working, etc.
As far as taking over from Go or Rust, I don't see someone with a greenfield project picking up Swift as the basis of some arbitrary project. Instead I see someone working on a Swift-based app -- say for iPadOS or macOS -- and needing a server-side component and deciding that it enables better skill and code re-use to implement the server-side in Swift as well.
For me, swift will be the ideal language (for syntax/style and performance ok for me). But is a deal killer that is not good on windows and no starter for android (that sadly, I need to support because is the dominant platform in my country).
If at least swift was great for backend/logic (ie: no UI on win/android/linux) it could be enough...
It's definitely more rough on Windows and Android, but at least CI is set up and passing on both platforms (which wasn't the case a year ago): https://github.com/apple/swift/blob/master/README.md
- Async/Await
- Swift and Swift package manager support on Windows
- Swift Package Manager resources and run scripts
- Backtraces
- Faster/incremental builds
There's some long-term plans for concurrency: https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
IIRC the compiler already has internal support for coroutines. Unfortunately, I think it will probably a long time before we get user-facing features like async/await.
> Swift and Swift package manager support on Windows
Swift works on Windows with all tests passing, though I imagine it's still a lot of work to compile and run (but I haven't checked).
> Swift Package Manager resources and run scripts
I agree this would be nice. Swift PM doesn't really give you much flexibility right now.
> Backtraces
Discussed in the article (section Swift Backtrace):
> This package provides support for automatically printing crash backtraces of Swift programs on Linux. Backtraces are generated by a builtin C library libbacktrace and demangled using a private Swift runtime call. We hope to improve the implementation by adopting SE-0262 when it is approved. We are also working with the Swift core team to discuss the benefits of merging this functionality into the Swift standard library.
> Faster/incremental builds
Swift has pretty good incremental builds, especially compared to the early versions. Compile times are way better than they used to be and are continuing to improve.
We believe that a healthy open source ecosystem relies heavily on the quality its packages -> We believe that a healthy open source ecosystem relies heavily on the quality of its packages
We're migrating away from it slowly as we make more microservices but it's been an interesting experience.
It was my first time using swift as I am a server engineer and not an ios engineer.
Its definitely lacking in tooling and libs but it's a really nice language with a good type system (it's not great though but it's easy). It definitely has potential to be a really good server language. I'd be more comfortable using go or python but it's more fun using swift
The primary motivation for choosing the language should not be sharing object models, atleast IMO.
“””
Good:
logger.info("hello world")
Bad:
let message = "hello world"
logger.info(message)
If you have a String that you received from elsewhere, please use
logger.info("\(stringIAlreadyHave)")
“””
Ugh.
And the payload field (think extra= in python logging) is pretty gross, you can’t even pass a [String: String] dict. Got help you if you want to dump your structured logging/data into splunk.