4 ms·

Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space

by zelly 7y ago

Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.

todd3834 7y ago
I recently tried to use Swift for a UDP server that was meant to run on Linux. I quickly realized the Network Framework is for iOS/MacOS/iPadOS only. I ended up using Go and I'm happy with it. I really wanted to do full stack Swift though. Just so I could become better at the language.
- favorited 7y ago
  Honestly that's no different than realizing that AVFoundation or CoreGraphics is Apple-platform-only... Network.framework is an Objective-C framework (I'm honestly surprised I don't seen any C++ symbols in the binary) – it was never supposed to be a cross-platform framework. SwiftNIO is the official base of the OSS Swift cross-platform networking toolchain. It's the equivalent of Java's Jetty package.
  - ynx 7y ago
    Netty, not Jetty.
    - favorited 7y ago
      Right, thanks!
- deleted 7y ago
  [deleted]
manojlds 7y ago
There's a lot of work being done to make Swift a good choice for ML. TensorFlow for Swift for example - https://www.tensorflow.org/swift https://www.tensorflow.org/swift
- pjmlp 7y ago
  Still no Windows binaries.
thanatos_dem 7y ago
The issue with swift on the server currently is that it’s an entirely different compilation toolchain to that run on MacOS and iOS, so the language has different bugs than those that exist for app development, and gets less attention from swift developers. If you want to take a stab at server side swift, I’d recommend looking at the swift port of Netty that Apple released called swift-nio (after the name “swetty” was nixed by Apple marketing and communications) - https://github.com/apple/swift-nio https://github.com/apple/swift-nio
- vyshane 7y ago
  The NIO version of Swift gRPC is currently at v1.0.0-alpha.6. Hopefully we'll see a 1.0 version soon. Swift gRPC repo: https://github.com/grpc/grpc-swift https://github.com/grpc/grpc-swift
  - vyshane 7y ago
    This post on the Swift forums gives a good overview of Swift gRPC: https://forums.swift.org/t/discussion-grpc-swift/29584 https://forums.swift.org/t/discussion-grpc-swift/29584
bluk 7y ago
I've pushed a few admittedly minor backend services in Swift to production. It is ok. You basically have one viable non-Apple OS platform (Ubuntu) to deploy on. This means that your basic Golang service is a 10MB Docker image while it can be over 100MB for a basic Swift service. There are frameworks like Swift NIO which is based on Java's Netty (and there are some Apple developers who work on Netty also working on Swift NIO). It works well enough but in most benchmarks, Swift is not even close to Netty ( https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json&l=uirbzz-f https://www.techempower.com/benchmarks/#section=data-r18&hw=... ), so if you're pushing the code expecting high performance, I would think twice. Swift gRPC (latest version based on Swift NIO) is also available, and while I think it works very well, it is still relatively new. As far as tooling, Swift is very immature IMO if you step outside Xcode. There are efforts to get a LSP service fully working (SourceKit-LSP), but I find it to be ok at best (performance and code completion suggestions are often very hit or miss). From benchmarking to diagnostics/backtraces to logging and metrics frameworks to shared common knowledge/answers on Stack Overflow, it is still very early days for Swift. Golang is so far ahead here that I personally think (at least today) the only reason you should launch a Swift service into production is because you want to reuse code that you have in your app. If you like Swift's type system and want a backend service equivalent, I would strongly recommend looking into Rust. IMO, Rust is a version of Swift where the programmer is given more control of what the code is actually doing (along with the associated responsibility). It sounds like a lot of trouble, but I find most Swift code naturally translates to Rust code (especially if you follow the "value vs reference" semantics ideology that the Swift compiler team advocates). At worst, if you learn Rust, you will understand Swift a lot better (like what really is an escaping vs. non-escaping closure or what is the difference if I use a generic versus a dynamic protocol type (dyn trait in Rust) in a function definition).

by zelly 7y ago

Does anyone use Swift (in production) for backend services not related at all to the Apple ecosystem? It seems like a better Golang to me, but the tooling space only targets Apple stuff.

todd3834 7y ago

I recently tried to use Swift for a UDP server that was meant to run on Linux. I quickly realized the Network Framework is for iOS/MacOS/iPadOS only. I ended up using Go and I'm happy with it. I really wanted to do full stack Swift though. Just so I could become better at the language.

favorited 7y ago
Honestly that's no different than realizing that AVFoundation or CoreGraphics is Apple-platform-only... Network.framework is an Objective-C framework (I'm honestly surprised I don't seen any C++ symbols in the binary) – it was never supposed to be a cross-platform framework. SwiftNIO is the official base of the OSS Swift cross-platform networking toolchain. It's the equivalent of Java's Jetty package.
- ynx 7y ago
  Netty, not Jetty.
  - favorited 7y ago
    Right, thanks!
deleted 7y ago
[deleted]

manojlds 7y ago

There's a lot of work being done to make Swift a good choice for ML. TensorFlow for Swift for example - https://www.tensorflow.org/swift https://www.tensorflow.org/swift

pjmlp 7y ago
Still no Windows binaries.

thanatos_dem 7y ago

The issue with swift on the server currently is that it’s an entirely different compilation toolchain to that run on MacOS and iOS, so the language has different bugs than those that exist for app development, and gets less attention from swift developers. If you want to take a stab at server side swift, I’d recommend looking at the swift port of Netty that Apple released called swift-nio (after the name “swetty” was nixed by Apple marketing and communications) - https://github.com/apple/swift-nio https://github.com/apple/swift-nio

vyshane 7y ago
The NIO version of Swift gRPC is currently at v1.0.0-alpha.6. Hopefully we'll see a 1.0 version soon. Swift gRPC repo: https://github.com/grpc/grpc-swift https://github.com/grpc/grpc-swift
- vyshane 7y ago
  This post on the Swift forums gives a good overview of Swift gRPC: https://forums.swift.org/t/discussion-grpc-swift/29584 https://forums.swift.org/t/discussion-grpc-swift/29584

bluk 7y ago

I've pushed a few admittedly minor backend services in Swift to production. It is ok. You basically have one viable non-Apple OS platform (Ubuntu) to deploy on. This means that your basic Golang service is a 10MB Docker image while it can be over 100MB for a basic Swift service. There are frameworks like Swift NIO which is based on Java's Netty (and there are some Apple developers who work on Netty also working on Swift NIO). It works well enough but in most benchmarks, Swift is not even close to Netty ( https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=json&l=uirbzz-f https://www.techempower.com/benchmarks/#section=data-r18&hw=... ), so if you're pushing the code expecting high performance, I would think twice. Swift gRPC (latest version based on Swift NIO) is also available, and while I think it works very well, it is still relatively new. As far as tooling, Swift is very immature IMO if you step outside Xcode. There are efforts to get a LSP service fully working (SourceKit-LSP), but I find it to be ok at best (performance and code completion suggestions are often very hit or miss). From benchmarking to diagnostics/backtraces to logging and metrics frameworks to shared common knowledge/answers on Stack Overflow, it is still very early days for Swift. Golang is so far ahead here that I personally think (at least today) the only reason you should launch a Swift service into production is because you want to reuse code that you have in your app. If you like Swift's type system and want a backend service equivalent, I would strongly recommend looking into Rust. IMO, Rust is a version of Swift where the programmer is given more control of what the code is actually doing (along with the associated responsibility). It sounds like a lot of trouble, but I find most Swift code naturally translates to Rust code (especially if you follow the "value vs reference" semantics ideology that the Swift compiler team advocates). At worst, if you learn Rust, you will understand Swift a lot better (like what really is an escaping vs. non-escaping closure or what is the difference if I use a generic versus a dynamic protocol type (dyn trait in Rust) in a function definition).