Pushing Swift to the Server
skilled.io
skilled.io
It is that simple, tested, proven, it works, it simply works. In just a couple of weeks I developed a couple of apps in Swift and they're up and running unattended:
http://swiftforums.herokuapp.com
http://pokerduel.herokuapp.com
Repos here:
And the fact that you can also develop for the desktop, mobile, tablets, watch, TV and IoT in one language is a huge advantage.
Swift is here to stay.
Doesn't seem to work with the latest Firefox version on Mac. It loads, but clicking does nothing.
That's where we are coming to share more of SSS topics in https://www.facebook.com/ServerSideSwiftCommunity/
""" 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.
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.)
Edit: They also have a Platform Support page, where they discuss their goals/intentions on cross-platform: https://swift.org/about/#platform-support
[edit]
Yup, no mention of win32 on that page at all.
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.
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.
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 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).
https://thenextweb.com/dd/2016/04/07/google-facebook-uber-sw...
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...
Roadmap for Swift: http://researcher.watson.ibm.com/researcher/files/us-lmandel...
If they claimed 1000 times, maybe that would be something worth sitting up to take notice.
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)
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.
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...
I don't know what the future plans are for that ...
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.
* 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 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.
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.
I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.
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. Other than that you are on your own. No UI libs, nothing.
This leaves you with iOS if you need to run on mobile which is extremely restricted. Want to freely distribute an app among your colleagues on the lab? Fuck you. You have to do all sorts of acrobatics with testing devices, provisioning certificates, etc.
In Android you just compile an .apk and send the link to your colleagues to install it, like in any other platform on Earth except iOS. Even macOS.
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.
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.
This is what I meant earlier with:
> I really don't see Swift becoming a popular full stack solution outside of environments invested in iOS and macOS.
But in many enterprise, industrial, education, and scientific applications, iOS is a complete fail. Not because of iOS in itself, but because of the many restrictions Apple imposes on the development workflow and the limited hardware.
Or if you need cough mobile crossplatform cough...
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.
There is that aspect, sure.
But what I wanted to point out is the irony of IBM promoting Swift since there isn't really any obvious advantage of using it full stack unless you are using iOS. Which happens to be the product of their new friend.
That is all.
What I'm saying is that moving to swift full stack is only beneficial if you are using iOS or macOS on your clients.
Go is definitely newer than D, which came out in December 2001, though D2, which is significantly different, came out in June 2007, while Go came out in November 2009. And, in the grand scheme of things, Go isn't too much older than Rust, which came out in January 2012.
Additionally, from the point of view of "no UI libs," basically every natively compiled language is at a significant disadvantage on Android, even the originally intended native language, C++ (1983).
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
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.
He has repeated this a few times at his JavaONE presentations, a bit hard to track down which ones.
Thanks to the work of Charles Nutter on adding FFI to JRuby, and the pressure from FinTech to improve Java's mechanical sympathy, a new project was started, project Panama, where binding to native code from Java should be something like P/Invoke on the CLR. Similarly calling into Java APIs from native side should have less ceremony setting up what to call.
Additionally there should be a standard support for integrating GPGPU into Java.
As it was deemed too complex to be ready by Java 9 timeframe, it ended up being scheduled for 10+ roadmap.
For the latest status check "Going Native" at JVM Language Summit 2016.
https://www.youtube.com/watch?v=JR1zI5gLhRM&index=13&list=PL...
The only reason I see, was having an easier way to parse header files.
Node.JS with Typescript or ASP.NET with C#/F#... I doubt it :)
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.
With this logic we'd still all be using CGI scripts.
Besides, Swift is several times faster CPU wise, type safe, and modern...
Why should the frontend change when the backend changes it´s abstractions? I want to change them independently, because they have different constraints and dependencies.
If you are implementering your database schema in the frontend, you´re doing it wrong.
An API is a view against a domain, which in turn is an abstraction above the database. However the client is not aware of the entire domain and shouldn´t be.
Only thing that is a good idea to share is the domain language and the API interface, but can be solved easily by other means than share code base.
And as soon you throw in another client with an other programming platform, all the benefits is lost anyway.
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).
You can sound much more professional and less juvenile by dropping the "So," prefix when you speak or write.