
Server APIs Project - OberstKrueger
https://swift.org/server-apis/
======
ruddct
Great. Great great great. A thousand times great. We've been slowly converting
our iOS projects over to Swift over the past year and the results have been
tremendous (a ~40% drop in LOC from ObjC, among many other benefits). Really
the only language-level feature that feels missing for server development is
first-class support for asynchronous/concurrent operations, but that's coming.

Swift is truly a 'best of most worlds' language. Typed, but without the
boilerplate seen in a lot of typed languages. Syntax that makes sense and is
consistent. Immutability strongly encouraged, but not required. OO if you want
it. First class functions. Etc, etc, etc. It's truly a dream to work in, can't
wait for server-side to get a little more mature.

~~~
sacheendra
I think most languages thatare popular today are 'best of most worlds' for
their users. For example, Scala has all the features you specified and has an
even larger ecosystem of libraries for the server side.

I am still happy that this has been done as I know having a common API to
program against does ease development and creates a great ecosystem as
evidenced by node.JS.

~~~
hota_mazi
The problem with Scala is not that it has all the features of Swift, it's that
it has way more. Scala developers see this as an advantage, everybody else
sees that as a liability.

Swift and Kotin manage to capture the perfect amount of "a few new features
but not too many" of all languages I've played with these past ten years.

They are both the perfect example of languages that hit the right compromise
in many dimensions.

~~~
threeseed
I am terrified of working with experienced Scala developers.

The code they write is less about implementing some business functionality in
the most elegant way possible. But rather it's an exercise in who can use the
most obscure parts of the language.

And unfortunately there are far too many obscure parts.

~~~
premium-concern
I have never seen this.

~~~
threeseed
The levels of enlightenment: [http://www.scala-
lang.org/old/node/8610](http://www.scala-lang.org/old/node/8610)

Most Scala developers are in the A bracket. The experts are in the L. The code
written by either is so different they could almost be different languages.
You don't get this sort of split in Swift, Java etc.

~~~
premium-concern
This is more of a split between techniques for programming-in-the-small vs.
programming-in-the-large.

All languages have this. You could write more or less the same list for Swift
or Java with minimal changes.

Again, do you have any actual experience with this, or is this just your
assumption? Because I have never seen this issue in the wild.

~~~
timv
I have absolutely seen it in the wild, but at least in my case it seemed to be
more a case of _" People who wish they were writing Haskell, but found more
commercial opportunities with Scala"_ compared with _" People who found Scala
to be an improvement over Java"_.

At the extreme of the first group you'd have people for whom it seemed like
every problem was best solved with a higher-kinded-type. And while it might
well have been technically (and mathematically) elegant, the rest of the team
was left scratching their heads trying to understand it.

------
rpeden
This looks like a very organized project with well defined goals, both of
which are points that will help it succeed.

It seems there's a bit of a trend back toward compiled languages (Go, Rust,
Swift) that don't rely on the JVM or .NET CLR to run. I think that these are
all great languages, though I almost wish for something like a better, more
modern, cross-platform COM to easily share libraries among the languages.

I've only had to work with COM very, very occasionally though. If I'd had to
work with it for any extended period of time, I probably wouldn't be wishing
for it, or anything like it. Perhaps sharing functionality between languages
is better accomplished by separate services communicating via something like
0MQ.

~~~
pjmlp
OS/2 had its own version of COM, called SOM.

The best thing about it, was that it also supported metaclasses Smalltalk
style. So one could go crazy with OO metaprogramming.

Sadly it died with OS/2.

Then there was the other multi-platform OO ABI project from Apple, Sun and
IBM, Taligent. Also not that successful.

COM is ok to work with, when done from .NET or now UWP point of view. C++/CX
and the recently announced C++/WinRT are still ok, even if a bit more wordy.

The real pain starts increasingly with C++ WTL, C++ ATL, C++ MFC or for the
real masochists pure C with COM related macros and the COM IDL compiler.

Then there was that other thing called CORBA, which makes the initial versions
of Java EE feel like being in heaven.

~~~
rpeden
I've mostly used COM from .NET, and as you said, it's fairly painless.

At one point, we were having issues with a COM DLL we were using from .NET, so
I thought it might be fun and useful to dive in and learn more about COM. I
bought Don Box's COM book, and tackled _COM in Plain C_ :
[http://www.codeproject.com/Articles/13601/COM-in-
plain-C](http://www.codeproject.com/Articles/13601/COM-in-plain-C)

It was somewhat less fun than I'd hoped it would be.

XPCOM seems to be (somewhat) alive and kicking:
[https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XPCOM](https://developer.mozilla.org/en-
US/docs/Mozilla/Tech/XPCOM) ; Firefox and VirtualBox are the only apps I've
seen that use it, though I imagine at least a few others do as well.

~~~
teh_klev
I still go back and dip into _Essential COM_ now and again. I bought my copy
because I was involved with a project to build a COM/CORBA bridge and needed
to get my head around COM's infrastructure. Also back in the day I used to
write a lot of code that ran under Microsoft Transaction Server (MTS) and
COM+.

Another interesting book by Mr Box and co-authored by Chris Sells, purely from
a historical perspective now as it's fairly ancient, is _Essential .NET Vol.
1_ [0]. Sadly they never got around to writing a second volume.

As a humourous aside, who remembers Don's lecture he did from a bath tub?:

[https://blog.mattmags.com/2011/05/19/don-box-the-bathtub-
lec...](https://blog.mattmags.com/2011/05/19/don-box-the-bathtub-lecture/)

[0]:
[https://www.amazon.co.uk/dp/0201734117](https://www.amazon.co.uk/dp/0201734117)

------
jaybuff
My team at Apple is hiring in San Francisco.
[https://jobs.apple.com/us/search?#location&ss=47424189&t=0&s...](https://jobs.apple.com/us/search?#location&ss=47424189&t=0&so=&lo=0*USA&pN=0&openJobId=47424189)

If you're interested, please email jaybuff@apple.com with [Swift Server] in
the email subject line.

~~~
rayshan
FYI the job description says Seattle, Washington

~~~
jaybuff
Thanks for pointing that out. We're hiring in SF, Seattle and London for this
role.

------
timanglade
Sweet to see an official push from the Swift project behind server-side use-
cases (and of course in a cross-platform way, as is Swift already [0]). Looks
like this spirit is taking hold community-wide too, with projects like
CocoaPods tinkering with Linux support this week [1]. The future looks bright
for Swift!

[0]:
[https://swift.org/download/#releases](https://swift.org/download/#releases)

[1]:
[https://twitter.com/segiddins/status/790326153051447296](https://twitter.com/segiddins/status/790326153051447296)

------
octref
What editor is everyone using for Swift?

Last time I played with Swift I stopped after XCode crashed 2 times in an hour
for me. It is also very slow. But none other editors seem to support auto
completion which is a deal-breaker for me. Without it it's hard to consume all
the APIs.

I hope Apple can follow Rust's path by making a language server[0] for Swift,
if Apple is serious about providing cross-platform support for it. This will
enable better support in editors such as find definition, refactor and auto
completion.

[0]: [https://internals.rust-lang.org/t/introducing-rust-
language-...](https://internals.rust-lang.org/t/introducing-rust-language-
server-source-release/4209)

~~~
grayrest
Last time I messed with Swift, I was using a vim plugin based on
SourceKitten[1] but it was a couple months ago over a weekend and I honestly
can't remember how well it worked. If you were inclined, it seems like it'd
get you most of the way to a language server.

[1]
[https://github.com/jpsim/SourceKitten](https://github.com/jpsim/SourceKitten)

~~~
favorited
The SourceKit daemon _is_ a language server. I wonder if anyone will adapt it
to support the MS protocol.

------
squiguy7
I have been following Rust's push into server-side development and can tell it
is still green. There is a great foundation with the hyper library but quite a
bit of fragmentation with frameworks and the async side of things.

It will be interesting to see where swift goes with all this. I know Rust has
a lot of traction now with cross-platform support and language features, but I
think swift is poised to offer a much different experience for server-side
development.

~~~
steveklabnik
The async side is all coalescing around Tokio and its various sub-projects.

I too am excited to see where this goes; Swift is a great language.

------
nodesocket
I like that they are taking the same sort of mantra as Node.js by providing
the core building blocks and letting the community develop web frameworks.
This was something that Ryan Dahl got absolutely right with Node, minimal
functionality, sugar on top of system calls.

------
seanparsons
Having spent 10 months working in Swift, this is probably the last thing on
earth I want to see right now.

Pretty much every part of the entire toolchain has been a pain, from Xcode
being Xcode, to compiler bugs and crashes, crappy package management and bad
language design.

Having built servers in Java/C#/Scala/Haskell, I'd pick Haskell over those
options and Swift every single time.

~~~
bluejekyll
What is it about Haskell? I'm currently heavily invested in Rust and have very
briefly looked at Haskell, but find it to have some oddities that I can wrap
my head around.

~~~
seanparsons
So I only know a minimal amount about Rust, so if there's things which are the
same there, then I'll probably be blindly ignorant about them.

First thing is that with the build tool Stack and now with recent versions of
Cabal the process of having a nice repeatable consistent build is pretty
smooth. I also used a tool called ghcid to get sub-second feedback on my
changes as I make them.

Haskell has started at the opposite end of the spectrum to most programming
languages, as in "How do I represent functions mathematically?" rather than
"How do I flip this bit in the accumulator register?". Which is probably
somewhat to your point about oddities, for me coming from an OOP background
there was a huge mental shift that had to happen to "get it". I've found that
things tend to just slot together so much more easily as a result. Curried
functions for example was a revelation for me, being able to pass (== 10) to a
list filter isn't some special case syntactic sugar it just falls out by
default.

Now much more people have gotten to grips with it there are amazing things
like the servant libraries which allow you to define a HTTP service(url, query
params, request method, etc.) with a type. You can implement a service against
that type and get all the appropriate checks, which is great. But then the
incredible part is that you can get it to create functions for each endpoint
in that service totally automatically at compile time:
[https://hackage.haskell.org/package/servant-
client#readme](https://hackage.haskell.org/package/servant-client#readme)

~~~
tome
Minor nitpick: "(==) 0" wouldn't be syntactic sugar, but "(== 0)" is. But I
agree it's a very natural consequence of the way the language is designed.

~~~
seanparsons
I'm not sure I understand, is there some special casing going on with "(==
10)"? As I'm admittedly not aware of it.

~~~
tome
Not anything major. It's just syntactic sugar for "\x -> x == 10".

~~~
seanparsons
How is it syntactic sugar? It's just applying "10" to the first parameter of
"==".

~~~
dllthomas
Without parentheses, == is infix. (== 10) is an "operator section", and
applies 10 to the _second_ parameter of ==. (10 ==) would be the first
parameter.

~~~
seanparsons
Ah yes, very true.

------
dschiptsov
I hope they will look at Erlang/OTP instead of Java EE for inspiration.

~~~
tormeh
I've seen people try to recreate Erlang/OTP in Java. See OpenCloud Rhino. They
never really get there. It's kind of sad to watch.

I mean, it's useful if you absolutely have to use Java, but it's expensive and
a pale imitation of Erlang/OTP. I'm confident that it will remain so until it
dies.

~~~
qaq
Trying to emulate Erlang/OTP on JVM is just a form of a cargo cult :)

------
mozumder
Some future server APIs should include database connectors, machine learning
libraries, & image/video processing.

Standardize on these before everything gets out-of-hand.

~~~
boterock
But maybe that is what they suggest should be handled by web frameworks.

Is like asking WSGI api in Python to handle all those things. It just handle
raw connections and is an interface for web frameworks to worry about content
and not low level stuff. Maybe database connectors would be a good inclusion
as well, but in Python I believe it is not part of WSGI

On the other hand, Apple has libraries for handling image and video for macOS
and iOS, are written in C but Swift interfaces so easily with C, but I don't
see them releasing that stuff.

~~~
dom0
His point is probably more concerned with hardware-accelerated machine
learning and the like. Much like eg. OpenCL for machine learning.

------
ldayley
Dumb question: I'd love to learn more about Swift and try out writing Swift
code, but is development still limited to XCode/macOS?

~~~
harisamin
You can play with swift on linux via docker too.
[https://github.com/swiftdocker/docker-
swift](https://github.com/swiftdocker/docker-swift) I'm one of the maintainers
:)

~~~
sp33der89
I usually start learning a new programming language making various GUI
programs, maybe using a library like SDL if needed. But I can't seem to find
anything like SDL for swift on linux! Most beginner resources assume you're
using XCode on a Mac.

Or does Cocoa work on Linux too(last time I checked this is highly not
plausible)?

------
xenihn
Does the inclusion of Vapor members mean we can finally declare Vapor the
"winner" over Perfect?

------
ohstopitu
I wonder what happened to the rumors that Google was planning on supporting
Swift on Android officially [0].

Also, are there any good tutorials/courses to get started with Swift & iOS
development? (having programmed in other languages, I can pick up fast, and
I've lost interest in tutorials that start out very slowly and take time to
get to the point.)

[0] [http://thenextweb.com/dd/2016/04/07/google-facebook-uber-
swi...](http://thenextweb.com/dd/2016/04/07/google-facebook-uber-swift/)

~~~
dom0
I guess it would make more sense to support Kotlin officially, but then again
it already works fine on Android.

~~~
achikin
As far as I understand Kotlin is reliant on Java Standard Library and is
dependent on Java infrastructure(maven, jvm, xml and friends), which makes no
sense for me as an iOS developer and can only benefit Java developers as it
was mentioned earlier.

------
speedkills
Is there anyway to build on Linux yet? Having to use a Mac to build and deploy
is really inconvenient for some continuous integration setups.

~~~
eyuelt
Swift has had Linux support ever since it was open sourced.

~~~
speedkills
Just not with Xcode projects? I was looking for something like xcodebuild that
I could run in a docker container and never found anything. Can you point me
in the right direction?

~~~
harisamin
I'm one of the maintainers of this [https://github.com/swiftdocker/docker-
swift](https://github.com/swiftdocker/docker-swift) :)

------
rgovind
Has anyone here made a living/killing selling compiler modification services?
I want to contribute to Rust/Swift/Some other language with a view of selling
consulting services. Can anyone here comment about their success in this
regard?

~~~
steveklabnik
[http://integer32.com/](http://integer32.com/) is the first Rust-focused
consultancy I know of.

------
akerro
So what makes Swift better than Java/C# for server-side development? I'm
getting tired with some languages and I'm looking for (fun) replacements.
Yesterday I was reading about Elixir. Why and when should I adopt Swift?

------
geodel
Amazing. Instead of talking about Swift server APIs, gaps or features desired,
this thread gets hijacked by Scala enthusiasts.

------
saosebastiao
No mention of multicore, threads, or asynchrony. I would hope that is part of
this.

~~~
adamnemecek
Those are already coming in Swift 4.

~~~
Zoon
This is now unexpected to be in Swift 4 :(

------
lcfcjs
Thank goodness, I just made an app last week and it was surprising how
difficult it was to actually make an http request and handle the response.

~~~
martijn_himself
Making an HTTP request would be part of the client (Cocoa?) libraries, this is
discussing Server APIs?

------
amelius
Nice, but I prefer a language which runs both on client and server, because
that means I can share code, and e.g. I can do prerendering on the server and
stuff like that.

~~~
K0nserv
But Swift does run on both the client and the server. Not when the client is
web, but when the client is an iOS or macOS app.

~~~
panic
Good luck pre-rendering a UIKit app on your server, though.

