<p>Hi all, </p>
<p>We're creating a public API to our content in the coming months, it needs to handle a lot of traffic. It's going to be serving our mobile app. We're having a debate next week on what language to use. </p>
<p>I've been using Go for about a year now, our old API's are PHP. I've fallen in love with Go due to it's speed, type safety, compilation to a single binary, concurrency model etc, etc. So I'm very much making the case for Go. </p>
<p>Someone else in my team is making the case for Node. That's quite easy to trump, given it's single threaded, performs fairly poorly in benchmarks from what I've seen against Go. </p>
<p>However, my boss is advocating for Swift on the server. Which seems to perform fairly well against Go, and has similar concurrency models as well as type safety. </p>
<p>Apart from the obvious lack of native support, on Linux servers, and the overall 'newness' of Swift on the server. Does anyone have any good arguments for using Go over say, Node or Swift? </p>
<p>Thanks in advance! </p>
<hr/>**评论：**<br/><br/>p7r: <pre><p>We've deployed Swift on the server to a low-traffic production service at least once - this was a few months back, we think we may have been the first site in the World to do it outside of IBM or Apple. </p>
<p>We're sticking with Go for now. Why? Well, there's so much missing at the moment in Swift's Linux land, that when you think "OK, now I need to talk to this MySQL DB", you realise <em>you</em> are going to be writing the lib/driver for MySQL. My colleague ended up implementing UDP in Swift for one application. Yes, UDP. Really.</p>
<p>That's fun, perhaps, but, you know… life is short.</p>
<p>It'll get better, and we <em>think</em> we'll re-evaluate it in the middle of 2017, but for now it's obvious we stay with Go.</p>
<p>Node, we've seen that roll out in a couple of places. JS bunnies love it, obvious, so that's fine. Those of us who spend more time in languages that actually make sense tend to eye those micro-services more suspiciously than their authors do.</p></pre>itsmontoya: <pre><p>Swift doesn't support async http yet. It shouldn't even be in the running. </p></pre>DeedleFake: <pre><p>Just that newness I think should be enough. Swift not only has basically nonexistent Linux support, it also apparently introduces breaking changes at irregular intervals. Not great for a production setting.</p></pre>NeverUse-YouPromised: <pre><p><a href="http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=swift" rel="nofollow">Go vs Swift benchmark</a>.</p>
<p><a href="http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=node" rel="nofollow">Go vs Node benchmark</a>.</p></pre>geodel: <pre><p>Swift benchmark is surprising. I expected it to be slow but it also use more memory than Go. Considering Swift author claimed GC'd languages use 3-4x more memory than ARC languages like Swift.</p>
<p><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html" rel="nofollow">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160208/009422.html</a></p></pre>devsquid: <pre><p>Those benchmarks don't represent real world usages either. The Swift code is compiled with the unsafe flag which you definitely wouldn't want to do in a real world scenario.</p>
<p>The benchmark sites fun, but be wary drawing conclusions from it.</p></pre>igouy: <pre><p>There's a URL for that! :-)</p>
<p><a href="http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html" rel="nofollow">http://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html</a></p></pre>TheMerovius: <pre><p>Note that most claims made in that post aren't about throughput and speed, but about latency and predictability.</p></pre>brokenprogram: <pre><p>Go is 'easier' than Swift because the GC helps the programmer more but everything has a cost, don't you think? Swift is more deterministic which makes a lot of sense for its use case. For example a DSP/audio application would be a good use case for Swift and bad for Go and it happens that there are a lot of such apps.</p>
<p>Gamming/animations is another domain where Swift fits better than Go due its determinism. Swift can use less memory because you have more control over the allocation/free but that depends much about how the benchmark/program is written.</p>
<p>It's also worth to note that Go is more mature so you may want to review the benchmarks in 1 -2 years from now.</p></pre>igouy: <pre><p><em>"Will your … program be faster if you write it in a different programming language? It depends how you write it!"</em></p>
<p><code>UnsafeMutablePointer</code></p></pre>int32_t: <pre><p>For one thing, Swift on Linux (or platforms other than Apple's) is still a second-class citizen. It's relatively difficult to find public resources when things are not that smooth as advertised. When searching solutions on the internet, most information you will find is about iOS development or the usage of the NS* APIs. The support of IDEs or editors plugins (again, other than Xcode) is comparably primitive compared with Go, particularly from the perspective of a Vim user.</p>
<p>If you find yourself are building the toolchain and/or the std libs more than once, either for catching up with newer versions for bug fixes or debugging your own apps by penetrating into the under-the-hood, the commitment required for Go to do that is also much more tolerable than Swift due partly to the simpler dependencies and partly to the compilation speed. Also the language and implementation of Swift does not seem to be completely settled down. Some glitches like build time have made profiling and speeding up <em>compilation</em> time a popular blog posts topic.</p>
<p>After bad-mouthing Swift a little bit, I am going to say the some good parts if you don't mind (given that you're not asking for it). First, the interoperability with libs written in other languages, aka FFI, is much easier and probably (no benchmarking attempted though) more efficient than Go. If your use cases prefer shared libraries to static binary, Swift might be simpler to work with out-of-box as well. Finally, Swift is designed to fit REPL well in mind. A static ,compiled language capable of being used naturally in REPL is rare and really appealing.</p></pre>Martinjnh: <pre><p>IBM proves love for Swift, releases Kitura web server framework for Linux</p>
<p>"Kitura itself has the ability to respond to web requests, so it does not require a web server such as Apache or Nginx. It runs on Linux or on OS X, so developers can run it locally."</p>
<p><a href="http://www.theregister.co.uk/2016/02/23/ibm_releases_kitura_a_swift_web_server_framework_for_linux/" rel="nofollow">http://www.theregister.co.uk/2016/02/23/ibm_releases_kitura_a_swift_web_server_framework_for_linux/</a></p></pre>SeerUD: <pre><p>I thought Swift 3 supported Linux? It seems to do at least: <a href="https://swift.org/download/#releases" rel="nofollow">https://swift.org/download/#releases</a></p>
<p>Swift does get around many of the issues that I have with Go, with a lot of the perks that Go has. It doesn't have all of them though, and I haven't been able to evaluate much of Swift yet compared to Go.</p>
<p>My biggest concern with Swift right now is the lack of a standard library like Go's, and also a lack of third-party, server-side libraries. Things will not be as mature as Go yet, but I really do honestly think that Swift will become much more of a serious contender against Go in coming months / years.</p></pre>kaeshiwaza: <pre><p>Simplicity ?</p></pre>Yojihito: <pre><blockquote>
<p>Apart from the obvious lack of native support, on Linux servers</p>
</blockquote>
<p>Uhhh .... I guess the server is running Linux so ... no-brainer to NOT choose Swift at the moment?</p></pre>brokenprogram: <pre><p>I think you can't go wrong with either one but Go is more stable and mature. The best part of Swift is its frontend/UI ecosystem.</p>
<p>That being said if your team already works on the frontend with Swift it makes sense to use Swift on the server too otherwise there is no reason to choose it over Go. </p>
<p>Node is a no-go as far as I'm concerned. </p></pre>Martinjnh: <pre><p>There are frameworks for Swift: Perfect, Vapor, Kitura...</p>
<p><a href="https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.g2bwoxrr8" rel="nofollow">https://medium.com/@qutheory/server-side-swift-vs-the-other-guys-2-speed-ca65b2f79505#.g2bwoxrr8</a></p></pre>kaeshiwaza: <pre><p>That you need a framework with swift is a reason to prefer Go...</p></pre>Martinjnh: <pre><p>Kitura, vapor or Perfect are the reason why a big amount of ios developers are going to use Swift in the backend rather than Go.</p>
<p>Just one language.</p></pre>Tikiatua: <pre><p>I do quite a lot programming in swift for ios apps and golang for servers and would personally always choose go for the server as the language itself is already much less complex and thus more comprehensible and the standard libraries and tools included allow for a wicked fast development (especially in regards to formatting and testing). </p>
<p>Swift is nice in the context of creating UIs, but for api development nothing beats golang for me currently. It is also very easy to deploy on different operating systems - and I did also develop in C#, Java, PHP and a lot of javascript (node and browser).</p></pre>Martinjnh: <pre><p>IBM Says Server-Side Swift 'Ready for the Enterprise'</p>
<p>"With this release, IBM has fully enabled enterprises to build next-generation apps in native Swift from end-to-end, client side to server side, on the IBM Cloud." </p>
<p><a href="https://adtmag.com/articles/2016/09/26/ibm-swift-enterprise.aspx" rel="nofollow">https://adtmag.com/articles/2016/09/26/ibm-swift-enterprise.aspx</a></p></pre>igouy: <pre><blockquote>
<p>our old API's are PHP</p>
</blockquote>
<p>So you shouldn't encounter too many surprises transitioning to Hack ;-)</p></pre>mallocc: <pre><p>"A lot of traffic" is a banal qualification. If you want meaningful feedback, give some meaningful measure of expected latency per request, requests per second and per host throughout expectations. </p>
<p>Go, JVM, and various C/C++ modules depending on your environment will all do the job. Node can be made to jam a square peg into a round hole depending on requirements but if you're even entertaining Swift you're not dealing with serious load so your choice is likely irrelevant. </p></pre>devsquid: <pre><p>You might look into Kotlin. It has all the maturity, support, Anne performance of the JVM backing it and a simple to learn language with similar syntax to Swift.</p></pre>
