[echelon]

Is Swift on the server a good idea? I don't own (or plan to own) a Mac. Does Apple support cross-platform tooling? I honestly don't know, but given their history, my default assumption is to be skeptical.

Why would you choose this over Go or Rust? (Rust is totally sweet for server dev, and I've spun up a few Rust servers for things.)

[mahyarm]

I don't use swift in a backend context, but from the iOS side:

* The debugger & indexer fails often.

* Build times are slow and source kit (the 'IDE features' server/library) has performance/stability problems.

* Scaling your CI is pretty bad since your stuck with apple hardware & their OS. There isn't an 'AWS' for apple hardware. MacStadium is so-so.

* You also don't have full control over your build chain, and decisions made by apple xcode can screw you over in when they change something in an update.

* Migrating your code from one version to the next can be a multi-week event.

I wouldn't use swift until it matures as a language in a few years. On backend you rarely need something that is not garbage collected. I would stick with python, golang & java. Maybe use rust or C++ if you need it.

[valuearb]

I've been developing on iOS for 7 years and Swift for 3. (Half of my 8 store APIs are in Swift)

While I agree with most of your criticisms I'll say it's never taken me more than an hour to update any code base when Swift versions change, it's a mostly automatic process.

Also I'd say anyone doing iOS development in Objective C instead Swift nowadays is doing themselves a grave mis-service. It's much easier and faster to build higher quality apps in Swift.

[mahyarm]

Apple's target is the 1-5 person developer team with maybe 50kloc of code & 1 mac mini acting as a CI box. Xcode scales ok in these cases.

Backend development tends to feature a lot more developers with a lot more code. Swift starts getting really painful when you hit those numbers. Go look at presentations done by larger swift codebases like linked-in, uber, lyft & airbnb to see where it starts happening.

[SiVal]

Of course, all dev gets more painful with more devs and larger code, so I assume you're saying that it increases more steeply with Swift than with...what? Java maybe? Or something else that the presentations you mention were comparing it to?

[mahyarm]

Objective-C, Objective-C++, Java, Javascript/Node, Python, Ruby, Golang, C++, C, C#. Build times increase significantly, the indexer takes 15-30m, sourcekit crashes, xcode UX freezes for 5s repeatedly, the debugger cannot print values when you hit a break point. On and on and on.

[wmil]

While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time.

The target market is really iOS devs who want the same language on the back end.

That's a perfectly reasonable engineering goal for an iOS-first shop.

But they're a vocal group and like to hype up server Swift as the next big thing for everyone. That's just not going to happen.

[jstapels]

https://www.jetbrains.com/objc/

[JimDabell]

AppCode only runs on macOS and requires Xcode to be installed. It's no help to people who aren't running macOS.

[msie]

Given all the complaints about XCode & Swift, I would say that it's not a huge advantage.

[coldtea]

>While Swift will compile on different backends now, XCode is still the premiere Swift dev environment and will be for a good while. So a non Mac Swift dev won't be having a great time

They won't have any worse time than someone using Go or Rust or D anywhere else..., that is, languages without "premiere Dev environments" and IDEs...

[antfarm]

For a while, there was a Swift plugin for JetBrain's CLion. https://blog.jetbrains.com/clion/2015/12/swift-plugin-for-cl...

I don't know what the future plans are for that ...

[Shank]

The Swift Open Source community is quite vibrant. They're already building it on Linux + macOS. See: https://github.com/apple/swift

Edit: They also have a Platform Support page, where they discuss their goals/intentions on cross-platform: https://swift.org/about/#platform-support

[vvanders]

There's quite a few windows developers out there as well for which I don't think we'll see Swift any time soon. In contrast Rust has fantastic windows support.

[edit]

Yup, no mention of win32 on that page at all.

[purple-dragon]

Is it as mature or have as large of a (server-focused) community? No, but I might consider this over Go or Rust because I already know Swift (from iOS development), and I haven't used Go or Rust at all. Fluency and confidence speed development time.

In all honesty though, even though I really like Swift, I'd probably choose something else I already know well like ASP.NET Core until the Swift-on-the-server scene matures.

As for cross-platform capabilities, IBM has contributed a lot of effort to running Swift on Linux and in the cloud. They even have a web-based REPL you can check out.

[leshow]

Swift and Rust are remarkably similar if you're familiar with what Swift calls "protocol oriented development" (I think it's called). Really, it's just a version of Haskell's typeclasses in disguise.

[ssscommunity]

Go and Rust are fine for some use case. Swift is fine for iOS and macOS developers as they are all backed by strong communities.

Roadmap for Swift: http://researcher.watson.ibm.com/researcher/files/us-lmandel...

[kawsper]

The consultancy Nodes reports that their framework Vapor[0] that is written in Swift is "around 100 times faster" than other frameworks written in PHP, Ruby and Python, you can see his bold claim 4 minutes in here: https://vimeo.com/193549098, but of course no benchmarks have been presented.

[0] https://vapor.codes/

[always_good]

I'm not sure how Vapor is ready for production.

Try its hello world locally and then bench it with `wrk`. You'll get a lot of failed requests with a concurrency > 1. (I didn't test concurrency = 1)

[thehardsphere]

Even assuming it's true, that's not an impressive claim. Frameworks in those three languages are not known for their speediness.

If they claimed 1000 times, maybe that would be something worth sitting up to take notice.

[coldtea]

Because having 100 less resources with similarly convenient language is something to sneer at...

[thehardsphere]

When there are at least 4 such languages/runtime implementations that exist already and have more libraries that also "have 100 less resources" then, yes, that one claim is a lot less special.

[floatboth]

Pretty much anything that compiles to good native code can be 100 times faster than "frameworks written in PHP, Ruby and Python". At least if we're talking MRI/CRuby and CPython, and especially without running multiple workers in those languages.

[mahyarm]

They really should be comparing against golang and java.

[tgragnato]

For the clever design of the language: coding with optionals is a breeze, it defaults to thread-safe reference counting, a cleaner syntax (IMHO only), .... .

For the unifying potential of the language: swift on the server (currently linux / freebsd limited), swift on mobile (Google seems to be moving in this direction too), swift on the desktop (macOS only).

[mderazon]

> Google seems to be moving in this direction too Source ?

[tgragnato]

The press made a lot of fuss about this claim. Unfortunately we have no confirmations nor denials, it would be nice to hear an internal about this.

http://thehackernews.com/2016/04/android-swift-programming.h...

http://www.dday.it/redazione/19590/app-android-scritte-con-s...

http://www.webnews.it/2016/04/08/google-apple-swift-android/

http://android.hdblog.it/n429420/Google-Swift-di-Apple-lingu...

https://www.tomshw.it/android-google-pensa-swift-apple-posto...

[DopamineHigh]

Here's the original article that sparked this claim. They say that "Sources tell The Next Web".

https://thenextweb.com/dd/2016/04/07/google-facebook-uber-sw...

[geodel]

It is great convenience for LOB applications when client macOS/iOS app and server backend both written in Swift. Team which knows Swift can be utilized for client/server side of products.

I am afraid that Rust might go Scala way where above average smart dev(s) decide on behalf of team what is best technology. Hence only very small teams and individual developers will use it. Larger teams with mixed skills and multiple locations might stick with boring but reliable technology like Java.

[igor_filippov]

This reminds me of "Javascript everywhere". Technically yes, but I don't think that language is a main issue for being able to develop both client and server part of the app. Languages can be picked up in a matter of weeks, concepts like good api design, choosing the right database, deployment etc are the real challenge.

[geodel]

You are right of course. I still think it is great proposition for at least Apple platform. For client side Apple will push it for greatness for server side it is still too early.

[warcher]

"Boring but reliable" is often underrated.

[simonh]

For you, if you don't own a Mac as you say and are not interested in iOS development, at this stage almost certainly not. You should probably stick with more mature existing tools.

One day Swift on the server, or other platforms, might be interesting completely aside from the Apple ecosystems, but for now I think it's main attraction on the server side is for people already using Swift for MacOS or iOS development.

[nicoburns]

I think it probably is a good idea (and yes Swift is cross-platform). Mainly just because Swift is really nice language. Personally I would probably prefer to use Rust, but for a developer who is already familiar with Swift it makes a lot of sense.

[jstapels]

I think that Swift as a language has a lot of promise and if it can be proven to work well on the server, it's something that one of the thousands of iOS developers can easily migrate into.

[hacker_9]

Why would it matter if it was cross platform if it is running on a server?

[cwyers]

Because the officially supported platform, macOS/iOS, isn't a server platform anymore.

[gibbitz]

Previous investment in Windows architecture for one. Cross operability with locally running Windows applications for another. Unfortunately though there are obvious solutions to these problems, those who make decisions about spending are often not as concerned about doing it right (IE they already invested in Windows). It's a selling point for adoption. I suspected that with Linux Shell in future Windows Servers Kitura will just run there, but I'm sure there will be performance hiccups doing that (at least compared to native environments).

[coldtea]

Obviously because you don't want to have servers running OS X?

[valuearb]

Swift on Server runs on a Linux.

[coldtea]

I know that. The parent asked why it matters that it's multi-platform.

Hence my answer: that it matters because if it wasn't, then you'd have to run Mac OS X to use Swift on the server side.

[Cthulhu_]

Developing on Mac, deploying on Linux, which could be x86 or ARM, etc? MacOS isn't really a server platform, definitely not a cloud OS.

[freehunter]

Case in point, Apple's iCloud runs on basically anything but Apple systems (most notably, IMO, Microsoft Azure).

[echelon]

It matters that the same development tooling is available on Linux.

[dzonga]

if you've linux you're good to go. Just a text editor like atom or sublime and do everything via CLI. Very fast and expressive too