Pushing Swift to the Server

you always need at least compiler/interpreter to execute your code... unless write bytecode in your editor

You can do that today with iOS apps theoretically too & just use command line xcodebuild. You'll be missing all of the IDE things that swift is struggling with although.

I think stability and maturity and is what Swift is missing now to qualify for many domains you mentioned(i.e IoT/systems programming)

> http://pokerduel.herokuapp.com

Doesn't seem to work with the latest Firefox version on Mac. It loads, but clicking does nothing.

Are you developing any iOS apps in Swift? How might I contact you to ask about your experience so far?

proven?

This submission reminds me of "Satirical hacker news post"

""" The Muskonauts figured out why their shit exploded. Hackernews, literally all of whom are actual rocket scientists, wonders if unit tests could have helped. """

Also conveniently forgetting that Computer Scientists are yet to solve types <===> physical dimensions mapping in practical programming language.

https://hackage.haskell.org/package/dimensional

Similar for (roughly) "we ran one benchmark and can now say that swift is similar to java in performance and uses half the memory generally, for all things". No reference to the benchmark either.

Yeah, the Mars mission loss is also really well-worn at this point. I've heard this example in contexts ranging from cross-org communication, to software APIs, and unit checking (as in SI, USCS, etc.). Now I can add "language X is better than language Y" to that list!

What's worse is that the whole "story" wasn't even tied in to the rest of the talk. So basically, the guy spent 10 minutes talking about an interesting anecdote that had almost nothing to do with the rest of the talk.

Exactly. I'm a fan of Swift on the server, but this is the best they can do with marketing?

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.

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.

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

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.

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...

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/

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).

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.

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.

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.

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.

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

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

> Swift is fast

Not really. Apple's propaganda is fast, Swift can sometimes be almost kinda fast if the stars align just right, but in general it is quite slow. For example, last I checked, Kitura's HTTP parser is written in C. And has to be.

Another one: the various JSON "parsers" that wrap the built-in NSJSONSerialization API add about an order of magnitude overhead. That is after all the actual parsing and conversion to a property list, which isn't exactly the most efficient representation in the first place.

The Big Nerd Ranch guys realized that the only way to get a "high performance" JSON parser is to do it 100% in Swift. They did that and the result is significantly faster than the wrappers. And only 4x slower than NSJSONSerialization, which again isn't exactly a very efficient parsing model (think XML DOM parser).

https://github.com/bignerdranch/Freddy/wiki/JSONParser

I do a more in-depth analysis in my book, "iOS and macOS Performance Tuning"

https://www.amazon.com/gp/product/0321842847/ref=as_li_tl?ie...

EDIT: I forgot the link to Freddy

I do not say this to defend Apple, as this is itself a form of "fuck you" "acrobatics" forced on you by Apple, but if you download Cydia Impactor (a program I develop that has a horrible UI which is about to get at least somewhat better in the next couple days), you can drag the IPA file to the device and it will have you log in with your Apple account (even if you are not a registered developer) and can then automate the entire 7-day free provisioning and installation process, helping this use case.

Also, while I am leaving a comment: the server space is different from Android in that 1) you don't need a UI and 2) there apparently is a sponsor working on the open source project (and it is my understanding that IBM is actually putting in more time than Apple) to make it useful there: Ruby is a language that is going to be a problem for you building either Android or iOS apps, and yet that is certainly not a reason to claim it would be a bad choice of language for coding a website backend.

>Swift is fast and the language is nice and all, but this feels more like propaganda. Let's not forget IBM and Apple have become friends recently.

Let's not forget it. How does that make presenting their product propaganda any more so than any other product presentation? Heck, they even use it themselves for their backend.

>I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.

Doesn't Apple becoming friends with IBM ensure that it will be used at least by many IBM customers? Which is quite a large potential base (and not all are happy for how Oracle moves with Java).

I also don't see why a top notch, statically compiled, very fast language, with automatic memory management, and support from a huge vendor AND a huge community AND open source, wont catch up.

>Swift can indeed run on a multitude of systems but that doesn't mean it's a good option. For example it's not even close to being ready for Android. It can run, but that's it.

That's because the work for porting properly there hasn't been done yet. But it's more or less the same with Google's own Go, which is much older than Swift, Rust, D, etc.

While it's not as easy as android it's not exactly complicated to distribute an app internally

https://developer.apple.com/library/content/documentation/ID...

Most of this is talking about getting up and running the first time too so it has length but it's not complicated.

> You have to do all sorts of acrobatics with testing devices...

A problem completely unheard of in Android land.

Ok, so maybe you can find a few situations in which Android might be a better solution that iOS. Congratulations. Android for the win. But there are many, many craptons of successful iOS apps out there that might like to be able to use services running on e.g. Linux. The existence of useful roles for Android devices won't make those go away.

The times are changing, hence why Java 10 has better support for some form of value types, improved generics, JNI replacement and AOT compilation on its roadmap.

Agreed, every languages do established and growth into a mature language. Swift was born and constantly learns every languages for the last 30 years of pros and cons including Rust, Go and Ruby.

Swift is built on LLVM (Compiler designer) and CLang which both are developed by the same group but they do not forget children who can learns Swift from young age for robotics, electronics, 3D and many things could be done with Swift.

More is need to be done on tooling before Swift will be on par as Java and C ecosystem.

In the same analogy, why choose Tesla or electric powered vehicles when other car manufacturers are established? Keep learning and improve it.

Well, neither Python and Ruby (prior to 2005-6) nor Node.js (prior to 2010-11) had any "established frameworks".

With this logic we'd still all be using CGI scripts.

Besides, Swift is several times faster CPU wise, type safe, and modern...

Speed, types, etc.

For now, i wouldn't. But swift is both a fantastic language, with enough felixibility to code generic code, and type safety to provide the best reliability ( no other language i know makes it that easy writing null pointer exception safe code), and one of the fastest( much faster than python or rails).

Mainly because you are already writing your MacOS or iOS app in Swift anyway and might even be able to re-use some code. If you aren't, no real reason for now to be honest.

I completely agree with the general point, however at the minimum this lets client and server share the same exchanged models ( what the server sends to the client is defined once, as well as the opposite).

There may be technologies like protobuf to define those structures in one place, but i can still imagine there are cases where it could be useful ( business rules and validation, etc).

Are you suggesting something like http://espresso.caffei.net/ ?

Wow! I was shocked to see no matches for "also", et al.