I see some mentions of Server API's on their website. With these libraries in place, how comparable is swift to golang?
It's already possible to do so to, by the way.
What I think go has over swift is the complete independence from platform. You can write go code on osx and compile it to a linux binary and it Just Works!
Swift on Linux is not perfect yet, though it can be made to work with some effort.
Concurrency is at the level of proposals currently, so it'll be another couple of years until they come up with something, and another couple until good server libraries/frameworks figure out how to use them properly.
It's a shame really - I imagine this could've been moving along at a faster rate had Chris Lattner stayed on with Apple and recruited some extra help.
He has written a really nice proposal for concurrency, that'll definitely influence Swift going forward. [0]
[0] https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9...
In Go, Erlang and Nodejs packages don't need to make any decisions about what kind of concurrency to use. The postgres driver in go will expose a blocking API, and the postgres driver in node will expose a continuation-passing-style API, or use promises. Everyone who uses those languages already knows how to consume those APIs. In these languages its very hard for an experienced developer to make concurrency mistakes - you can instead spend all your time thinking about the actual problem you're trying to solve.
In C, Swift and Rust this isn't true (yet). Despite all three of these languages having lots of tools for concurrency, the lack of standardisation means you can't just grab any postgres library. You also have to look at how that library does threading and figure out how to correctly integrate it with the threading model you're using in your own code. (Does it depend on tokio? Does it use posix threads? GCD? Green threads? Async?). This turns the 3rd party package ecosystem in these languages into a fragmented minefield.
As far as I know there are 4 main swift-based http server libraries[1] at the moment. Each one works slightly differently. Because they all roll their own concurrency tools, they're all mutually incompatible. Each one has implemented its own static file server, its own hsts header middleware, its own json parser, etc. I'm not sure about erlang but in node and go because the concurrency primitives are standard, they're all similar enough that you can migrate code between them or wrap a tool thats designed for one to work for another.
(Of course rust has tokio, but tokio is being rewritten[2]. Rust also has mio and raw threads. In a few years we'll probably have strong standards for both swift and rust, but until then the ecosystems will be a mess compared to the bliss of node and go.)
[1] https://medium.com/@rymcol/current-features-benefits-of-the-... [2] https://tokio.rs/blog/tokio-reform/
You can use Grand Central Dispatch, and it works. It's not as wonderful as go routines and channels, but hey, it works.
The very motivation behind creating Swift, has been to have performance, and none of the undefined behaviour (cause of innumerable security breaches and unintentional complexity in compiler design and everyday programming) [0]
To me, grand-central-dispatch feels one small step above semaphores/locks/monitors.
There has been a lot of research in distributed computing and concurrency - I'd like to see libraries, language constructs and runtimes based on research fresher than before I was born :)
[0] http://blog.llvm.org/2011/05/what-every-c-programmer-should-...
That's just false. Server-side projects that require concurrency are a tiny minority.
Also with the parent, why do you think "swift has no quality high-level concurrency primitives"? GCD and blocks along with some promise library should make it easier then goroutines and channels no?
Things like the core request loop and the DB connection pool will need to handle concurrency, but a few people will have figured out how to get that stuff working and you can just use their libraries.
1. Lattner's ability to present complex topics in an approachable way is very impressive. 2. I'm really excited for Swift 8.0 (my best guess at the first version that will include all this).
According to the documentation at perfect.org, it supports asynchronous request handling.
I've tested it locally a while ago and IIRC it could utilize multi-cores just fine.
Node became popular because now front-end devs could write their own backends.
Go became popular because of Google and it's concurrency primitives (as far as I know)
Swift is going to become popular because of Apple and... fill in the blank.
My take is that it'll take good performance, and easy to understand concurrency primitives that make writing libraries and using them a joy - that's the only way.
That'll be the differentiating factor that'll entice people to pay attention - otherwise as you have pointed out, there are plenty of alternatives.
So you are saying concurrency primitives aren't required for a successful server language?
It's a matter of time for it to get traction.
The only thing python/ruby have going for them at the moment is momentum.
Remember in 2005, Python was a fringe language on the web. Most web programming was done in php.