In 2014, Apple announced the release of Swift, a new programming language for all their platforms. Their programming language of choice on iOS and OSX has always been Objective-c, a language which is\u00a0a bit dated (it predates C++) and as it has had new features (and syntaxes) bolted onto it every few years, it carries quite a bit of baggage. It seems I wasn\u2019t the only one with this opinion, as the release of swift was greeted with great enthusiasm, and has been adopted very rapidly.<\/p>\n
Swift combines all the features that are fashionable in a general purpose language today, without the feeling that they were bolted on after the fact. While building an iOS client for our customer Gerimedica<\/a> in swift, I found myself wishing I could use this language on the server side as well as in the client. At WWDC 2015, Apple announced the intention to open source the language, and release a Linux version, so it looked like it could become a reality. Since december 2015, the sources have been available on github<\/a>, and builds for OSX and Ubuntu<\/a> are made available roughly twice per month.<\/p>\n PerfectLib<\/strong><\/p>\n A number of groups and companies saw an opportunity to be among the first with something that was obviously going to be big. One of the first was PerfectSoft<\/a>, a startup that aims to be the one big framework for all your server side development in swift. They started building their framework as soon as the open source release of swift was announced, and have been advertising their product everywhere. Because they started development before anyone outside Cupertino had a good idea what the release would look like, it only worked on OSX at first, and it didn\u2019t use the Swift Package Manager<\/a>, the intended default build and dependency management tool for swift. At the time, the framework compiled to one big binary, that you had to include in your build manually. They have a beautiful website and good documentation, but it just wasn\u2019t working when I tried it. I intend to try this framework out again at a later date.<\/p>\n IBM<\/strong><\/p>\n The biggest player (other than Apple) to openly jump on the swift bandwagon is IBM. As soon as the open source release of Swift was announced, IBM announced the Swift Sandbox<\/a>, their Swift based version of google\u2019s golang playground<\/a>. It is a web based repl that can be shared online by sharing a URL. Cool, but not extremely useful, as unlike go, swift already comes with a repl. The real significance of this is not the swift sandbox itself, but the message that IBM is interested in this technology and intends to be involved. IBM isn\u2019t the kind of company to back technologies just because they like them, so they either see an opportunity, or a potential strategic interest. At the moment, IBM\u2019s swift related activities seem to be associated with their PaaS solution BlueMix<\/a>, so they are likely working on the Swift \/ IBM version of google\u2019s app engine<\/a> for go. IBM offers its own web framework for swift: kitura<\/a>. Kitura turns out to be less than trivial to install and for now somewhat bare bones, but as this is IBM, it is worth dedicating another blog post to it at a later date. Also check out their overview<\/a> of the most popular, most active and most essential open source projects on github for swift.<\/p>\n <\/p>\n Google<\/strong><\/p>\n There have been rumors<\/a> all over the internet that google would be considering making swift a first class language for android. As far as I can tell, all of these rumors can be traced down to one article on thenextweb.com<\/a>, which states that \u2018sources have told…\u2019 For now, there is no indication that these rumors are anything more than rumors. It\u2019s not clear what would be in it for google, now that their own mobile platform has become so successful. It is already possible to run swift code on android<\/a>, but there is a very long way to go from there to writing an entire android app in swift.<\/p>\n Zewo<\/strong><\/p>\n The next framework I tried was Zewo<\/a>, a project started by Paulo Faria. I immediately liked the architecture: a package based approach, tied together with the Swift Package Manager. You could pick and choose the elements you wanted and simply include the dependency in the Package.swift file, and leave out the parts you don\u2019t need. Let\u2019s build a minimal server side application with Zewo. Installing zewo on Linux turns out to be very easy<\/a>.<\/p>\n Download and install swift from swift.org<\/a>. Note that these examples use the DEVELOPMENT-SNAPSHOT-2016-02-08-a snapshot<\/a>. This is relevant, because at this time, swift 3 is a moving target. It is undergoing rapid development, and every new snapshot released is likely to break your builds, with or without a deprecation warning. Kyle Fuller made swiftenv<\/a>, an elegant tool for managing installations of multiple different builds of swift. I recommend using this tool to install and manage development snapshots of swift:<\/p>\n Make sure clang<\/a> and libicu-dev<\/a> are installed.<\/p>\n Install Zewo:<\/p>\n Make a directory for your project, and in that directory type:<\/p>\n This will create the basic structure for a swift application managed by SPM. Paste the following code into Sources\/main.swift:<\/p>\n Paste the following code into Package.swift:<\/p>\n And compile and link the project by typing:<\/p>\n The swift build tool will start pulling in dependencies, and will compile and link the project. The build can take a surprisingly long time, which is an issue I will get back to later on.<\/p>\n When the build is done, you can find the executable at<\/p>\n Just run it. No JRE, application server, servlet container or other middleware needed. You should see an ascii art zewo logo and the message that our application is running and responding to port 8080. Let\u2019s try it out:<\/p>\n That\u2019s quite nice for less than 10 lines of code. Let\u2019s add some code to make it a slightly more elaborate REST service:<\/p>\n Add the following dependencies to Package.swift<\/p>\n Build and run.<\/p>\n At last count, there were over 50 Zewo projects <\/a>available, including HTTP(S)client and server, JSON serialization, support for various databases (MySQL, PostgreSQL and MongoDB), File IO, OpenSSL, an implementation of Moustache<\/a>, an SQL query DSL and ORM, Websockets, support for ZeroMQ<\/a>, logging, basic authentication and more. Not all these projects are at the same level of completion. As of the time of writing this blog, the HTTPSServer implementation is broken, and MySQL support tends to lag behind because the developers prefer Postgres.<\/p>\n Venice<\/strong><\/p>\n The star attraction of the Zewo framework is Venice<\/a>, a CSP<\/a> implementation for Swift, based on Libmill<\/a>. Libmill and Venice offer \u2018Go-style concurrency<\/a>\u2019, which is true to a point. The programming model is very similar. It is trivially easy to make huge numbers of lightweight coroutines run concurrently, and context switching is very fast. Unlike go, libmill and Venice run all coroutines in a single thread, at least for now, so this should not be mistaken for a tool to easily parallelize your code. I can recommend Rob Pike\u2019s presentation<\/a> on the subject if the difference isn\u2019t clear.<\/p>\n Here is, for example, an implementation of the famous joke algorithm SleepSort<\/a> using Venice:<\/p>\n It starts 100 coroutines that each wait a number of milliseconds before writing said number to a shared channel. At the end, the numbers are read from the channel in sorted order. It\u2019s a very easy to use, easy to reason about and lightweight model for concurrent programming.<\/p>\n All of the Zewo networking projects depend on Venice for concurrency. For now, that means they are single threaded. To facilitate parallelism, server sockets are bound with the SO_REUSEPORT<\/a> option, which allows multiple processes to bind to the same port. The OS will then take care of balancing connections between these processes.<\/p>\n XKCD 303<\/strong><\/a><\/p>\n Why is the build time for our hello world app so long when compared to, for example, the equivalent written in go? Part of the answer is in the different decisions Chris Lattner<\/a> and Rob Pike<\/a> made for the languages they designed. For google, reducing the build times of their projects was one of the main design priorities<\/a>. From the somewhat bare bones syntax of the language itself to the design of the standard libraries, usability and to some extent functionality has been sacrificed in order to reduce build times. Standard libraries typically don\u2019t contain functions that encourage you to pull in a dependency just to save you from typing or copying a few lines of code. Try looking for a round() function in the math package, for example.<\/p>\n For Apple, a great number of features had a much higher priority than build times: compatibility with existing Objective-C code being one of the most important. If Swift lacked features that existing Objective-C coders expected, or if it couldn\u2019t work well with existing Objective-C code, it would never be adopted. Another major design decision was ease of use, presumably to keep development for iOS from becoming more expensive than android development because of the learning curve of Objective-C compared to Java. I believe they simply reached a point fairly quickly where they decided that compilation times were good enough and other priorities took over.<\/p>\n The compile and link time of the Swift sources isn\u2019t the whole story. Try running a build in verbose mode to see what happens:<\/p>\n There seems to be an awful lot of repetition going on there. Let\u2019s count the top 10 most repeated statements:<\/p>\n The Swift Package Manager is based on git repositories. Those can be projects on github, or they can be local directories on your build machine, but they are git repositories. Why does SPM ask the remote origin url of every dependency dozens of times, starting \/usr\/bin\/git a total of 558 times for such a simple program? It looks like SPM currently doesn\u2019t work well with the package based design decisions the authors of the Zewo framework made. Every dependency is checked, then every transitive dependency, then every transitive dependency of those etc. A Zewo project typically depends on a number of other Zewo projects, each responsible for one small task. They seem to be working<\/a> on fixing this problem.<\/p>\n Vapor<\/strong><\/p>\n One final server side Swift framework worth mentioning is Vapor<\/a>, a project started by Tanner Nelson. When I first tried it out, I had a difficult time getting it to work on Linux, but it has been developing very rapidly, and by now it is only a matter of executing the build script. The build script is written in Swift, which illustrates another cool feature of Swift: it can be used both as a compiled language and for scripting. Because of time constraints, a detailed description of the Vapor framework will have to wait for another blog post.<\/p>\nswiftenv install DEVELOPMENT-SNAPSHOT-2016-02-08-a\nln -s ~\/.swiftenv\/shims\/* \/usr\/local\/bin\/<\/pre>\n
sudo apt-get install clang libicu-dev<\/pre>\n
echo \"deb [trusted=yes] http:\/\/apt.zewo.io\/deb .\/\" | sudo tee --append \/etc\/apt\/sources.list\nsudo apt-get update\nsudo apt-get install zewo<\/pre>\n
swift build --init<\/pre>\n
import HTTPServer\nimport Router\n\nlet router = Router { route in\n route.get(\"\/hello\") { _ in\n return Response(body: \"hello world\")\n }\n}\n\ntry Server(responder: router).start()\n<\/pre>\nimport PackageDescription\n\nlet package = Package(\n name: \"HelloWorld\",\n dependencies: [\n .Package(url: \"https:\/\/github.com\/VeniceX\/HTTPServer.git\", majorVersion: 0, minor: 3),\n .Package(url: \"https:\/\/github.com\/Zewo\/Router.git\", majorVersion: 0, minor: 3),\n ]\n)\n<\/pre>\n
swift build<\/pre>\n
.build\/debug\/HelloWorld<\/pre>\n
curl http:\/\/localhost:8080\/hello\nhello world<\/pre>\n
import HTTPServer\nimport Router\nimport ContentNegotiationMiddleware\nimport JSONMediaType\n\nlet contentNegotiation = ContentNegotiationMiddleware(mediaTypes: JSONMediaType())\n\nlet router = Router { route in\n route.get(\"\/hello\") { _ in\n return Response(body: \"hello world\")\n }\n route.get(\"\/hello\/:name\/:location\") { request in\n if let name = request.pathParameters[\"name\"],\n let location = request.pathParameters[\"location\"] {\n let data : InterchangeData = [\n \"name\" : \"\\(name)\",\n \"location\" : \"\\(location)\"\n ]\n return Response(status: .OK, content: data)\n }\n return Response(body: \"hello error world\")\n }\n}\n\ntry Server(middleware: contentNegotiation, responder: router).start()\n<\/pre>\n .Package(url: \"https:\/\/github.com\/Zewo\/ContentNegotiationMiddleware.git\", majorVersion: 0, minor: 3),\n .Package(url: \"https:\/\/github.com\/Zewo\/JSONMediaType.git\", majorVersion: 0, minor: 3),\n .Package(url: \"https:\/\/github.com\/Zewo\/InterchangeData.git\", majorVersion: 0, minor: 3),<\/pre>\n
curl -s http:\/\/localhost:8080\/hello\/rik\/amsterdam | python -m json.tool\n{\n \"location\": \"amsterdam\",\n \"name\": \"rik\"\n}<\/pre>\nimport Venice\nimport Glibc\n\nlet channel = Channel<Int>()\n\nfor i in 1...100 {\n let number = random() % 5000\n co {\n nap(Duration(number))\n channel <- number\n }\n}\n\nfor msg in channel {\n print(\"received \\(msg) from channel\")\n}\n<\/pre>\nswift build -v<\/pre>\n
swift build -v | sort | uniq -c | sort -n | tail -n 10\n 31 \/usr\/bin\/git -C ~\/Hello\/Packages\/URI-0.2.0 config --get remote.origin.url\n 33 \/usr\/bin\/git -C ~\/Hello\/Packages\/Data-0.2.2 config --get remote.origin.url\n 34 \/usr\/bin\/git -C ~\/Hello\/Packages\/CURIParser-0.2.0 config --get remote.origin.url\n 36 \/usr\/bin\/git -C ~\/Hello\/Packages\/Venice-0.2.2 config --get remote.origin.url\n 40 \/usr\/bin\/git -C ~\/Hello\/Packages\/Stream-0.2.0 config --get remote.origin.url\n 42 \/usr\/bin\/git -C ~\/Hello\/Packages\/InterchangeData-0.3.0 config --get remote.origin.url\n 42 \/usr\/bin\/git -C ~\/Hello\/Packages\/MediaType-0.3.1 config --get remote.origin.url\n 44 \/usr\/bin\/git -C ~\/Hello\/Packages\/CLibvenice-0.2.0 config --get remote.origin.url\n 46 \/usr\/bin\/git -C ~\/Hello\/Packages\/IP-0.2.1 config --get remote.origin.url\n 49 \/usr\/bin\/git -C ~\/Hello\/Packages\/System-0.2.0 config --get remote.origin.url\n<\/pre>\n