Swift Server Work Group Annual Update
swift.org
swift.org
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.
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.
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'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.
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
“””
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.