13 ms·

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

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?
        badrequest 7y ago
        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 https://blog.golang.org/profiling-go-programs). I've not used Rust, so I can't speak to that.
        scarface74 7y ago
        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.
        Eric_WVGG 7y ago
        > And what server side code “behaves differently” [mean] 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.)
- wlesieutre 7y ago
  The language server runs on linux and works with VS Code. Is there something in particular you're missing? 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.
  - Tainnor 7y ago
    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.
    - mickael 7y ago
      You can use VS Code + remote & Docker: https://medium.com/@ianpartridge/swift-development-in-docker-using-visual-studio-code-remote-b84d035e70db https://medium.com/@ianpartridge/swift-development-in-docker...
- duregin 7y ago
  >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.
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.

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?
        badrequest 7y ago
        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 https://blog.golang.org/profiling-go-programs). I've not used Rust, so I can't speak to that.
        scarface74 7y ago
        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.
        Eric_WVGG 7y ago
        > And what server side code “behaves differently” [mean] 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.)
wlesieutre 7y ago
The language server runs on linux and works with VS Code. Is there something in particular you're missing? 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.
- Tainnor 7y ago
  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.
  - mickael 7y ago
    You can use VS Code + remote & Docker: https://medium.com/@ianpartridge/swift-development-in-docker-using-visual-studio-code-remote-b84d035e70db https://medium.com/@ianpartridge/swift-development-in-docker...
duregin 7y ago
>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.

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.