8 ms·

Swift Server Work Group Annual Update

84 points by Austin_Conlon 7y ago

echelon 7y ago
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.
- melling 7y ago
  I imagine if there’s a demand, AppCode could be made available on other platforms: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
- favorited 7y ago
  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.
  - echelon 7y ago
    > 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.
    - Razengan 7y ago
      > It's that engineers have to use Mac machines to develop Swift That is patently untrue.
      - Tainnor 7y ago
        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)
        scarface74 7y ago
        This is server side Swift. It supports the LSP and is supported by Visual Studio Code.
        Tainnor 7y ago
        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 https://github.com/apple/sourcekit-lsp#status
        scarface74 7y ago
        The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. And what server side code “behaves differently” Where does it say it’s not “production ready” on the GitHub link?
        7y ago
  - wlesieutre 7y ago
    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.
    - nielsbot 7y ago
      TypeScript makes a big difference here...
      - ElFitz 7y ago
        There is a world between the two when it comes to types. Even more so at run time.
      - Eric_WVGG 7y ago
        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.
        vosper 7y ago
        > how stapled on and hacked Typescript feels 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.
    - eecc 7y ago
      I’ll burn a candle in favor of giving Node the Adobe Flash treatment it deserves. (Burn karma burn!)
    - 7y ago
  - mamcx 7y ago
    > 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)
    - pjmlp 7y ago
      Just like OCaml, Java (AOT compiled), C#/F# (AOT compiled), D, Nim, Ada, FreePascal.
      - mamcx 7y ago
        Maybe not the ones with GC?
        pjmlp 7y ago
        Swift also has a GC by CS definition of automatic memory management algorithms.
        skohan 7y ago
        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.
        mamcx 7y ago
        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.
- Tainnor 7y ago
  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: - 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-10613, https://bugs.swift.org/browse/SR-10344 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)
  - skohan 7y ago
    > improving compile times for large applications 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.
    - Tainnor 7y ago
      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.
- endorphone 7y ago
  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.
- mamcx 7y ago
  I agree. I even asked https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/ https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif.... 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...
  - NobodyNada 7y ago
    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. 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 https://github.com/apple/swift/blob/master/README.md
- pharaohgeek 7y ago
  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.
trollian 7y ago
Still no plans for concurrency? Such a waste.
rnantes 7y ago
I love Swift and I think it could be one of the best languages on the server. However here are a few things that I think would make it better: - Async/Await - Swift and Swift package manager support on Windows - Swift Package Manager resources and run scripts - Backtraces - Faster/incremental builds
- NobodyNada 7y ago
  > Async/Await There's some long-term plans for concurrency: https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 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.
elpakal 7y ago
Hey Tanner - there's a typo right away: 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
conradludgate 7y ago
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
- mdev 7y ago
  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.
- technics256 7y ago
  Did you look at typescript? I've used swift and typescript and think you could have gotten a lot of runway with typescript/node and react native.
Redoubts 7y ago
Not gonna lie, this logging api is a howler. “”” 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.
jaunkst 7y ago
No thanks.
mickael 7y ago
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.
- jamil7 7y ago
  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?
  - mickael 7y ago
    I would start by both getting involved in the server part of the Swift forum (https://forums.swift.org/c/server https://forums.swift.org/c/server), and by checking simple tickets you could help with on those projects Github.

84 points by Austin_Conlon 7y ago

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.

melling 7y ago
I imagine if there’s a demand, AppCode could be made available on other platforms: https://www.jetbrains.com/objc/ https://www.jetbrains.com/objc/
favorited 7y ago
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.
- echelon 7y ago
  > 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.
  - Razengan 7y ago
    > It's that engineers have to use Mac machines to develop Swift That is patently untrue.
    - Tainnor 7y ago
      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)
      - scarface74 7y ago
        This is server side Swift. It supports the LSP and is supported by Visual Studio Code.
        Tainnor 7y ago
        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 https://github.com/apple/sourcekit-lsp#status
        scarface74 7y ago
        The XCode profiling is mostly for iOS apps - not server side code. You wouldn’t really be better off using a Mac for profiling server side code. And what server side code “behaves differently” Where does it say it’s not “production ready” on the GitHub link?
        7y ago
- wlesieutre 7y ago
  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.
  - nielsbot 7y ago
    TypeScript makes a big difference here...
    - ElFitz 7y ago
      There is a world between the two when it comes to types. Even more so at run time.
    - Eric_WVGG 7y ago
      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.
      - vosper 7y ago
        > how stapled on and hacked Typescript feels 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.
  - eecc 7y ago
    I’ll burn a candle in favor of giving Node the Adobe Flash treatment it deserves. (Burn karma burn!)
  - 7y ago
- mamcx 7y ago
  > 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)
  - pjmlp 7y ago
    Just like OCaml, Java (AOT compiled), C#/F# (AOT compiled), D, Nim, Ada, FreePascal.
    - mamcx 7y ago
      Maybe not the ones with GC?
      - pjmlp 7y ago
        Swift also has a GC by CS definition of automatic memory management algorithms.
        skohan 7y ago
        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.
        mamcx 7y ago
        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.
Tainnor 7y ago
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: - 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-10613, https://bugs.swift.org/browse/SR-10344 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)
- skohan 7y ago
  > improving compile times for large applications 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.
  - Tainnor 7y ago
    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.
endorphone 7y ago
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.
mamcx 7y ago
I agree. I even asked https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swift_for_androidlinuxwindows_on_2018/ https://www.reddit.com/r/swift/comments/8zb9y1/state_of_swif.... 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...
- NobodyNada 7y ago
  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. 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 https://github.com/apple/swift/blob/master/README.md
pharaohgeek 7y ago
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.

trollian 7y ago

Still no plans for concurrency? Such a waste.

rnantes 7y ago

I love Swift and I think it could be one of the best languages on the server. However here are a few things that I think would make it better: - Async/Await - Swift and Swift package manager support on Windows - Swift Package Manager resources and run scripts - Backtraces - Faster/incremental builds

NobodyNada 7y ago
> Async/Await There's some long-term plans for concurrency: https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782 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.

elpakal 7y ago

Hey Tanner - there's a typo right away: 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

conradludgate 7y ago

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

mdev 7y ago
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.
technics256 7y ago
Did you look at typescript? I've used swift and typescript and think you could have gotten a lot of runway with typescript/node and react native.

Redoubts 7y ago

Not gonna lie, this logging api is a howler. “”” 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.

jaunkst 7y ago

No thanks.

mickael 7y ago

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.

jamil7 7y ago
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?
- mickael 7y ago
  I would start by both getting involved in the server part of the Swift forum (https://forums.swift.org/c/server https://forums.swift.org/c/server), and by checking simple tickets you could help with on those projects Github.