This paper covers all the mainstream languages but I feel an "alternatives considered" section is missing. I would love to know what's the author's input on Swift server side, Elixir and Crystal.
For the benchmarks done in the paper, elixir should basically benchmark identically to erlang, since if there's any performance regression, it's a very thin wrapper.
I doubt crystal is mature enough in its multithreading model (which is still nascent, and IIRC not fully supported in the current rev, and inherited from ruby's in concept) to perform well at all in this. Erlang, Go and Akka were all conceived of specifically to handle multithreaded connections.
There were many languages that we would like to have considered. We do expect the performance of Elixir to be pretty similar to Erlang as it runs on the same VM (BEAM).
With regards the "alternatives considered", Section 2 outlines key characteristics of server languages, and Table 1 analyses a selection of languages against these characteristics.
We welcome others to report results for other languages using the benchmarks.
One thing you might find interesting - a small, crude experiment suggests that changing maxBlocking.erl to use process hibernation for those dormant processes could almost double the max number of processes Erlang can support.
I changed maxBlocking.erl's final few lines to read
Mainstream? It does not cover Java and C# and makes false assumptions on them. I have to assume that the detail selection group was not determined out of the 12 others but pre-defined. This paper is academic.
I strongly feel that once Swift makes it to be open sourced the path from iOS native to Android (cross) will become much simpler then (go:logic, java:android UI, objc:iOS UI).
I think Google is more interested in Dart as a cross platform language.
See the Sky project https://github.com/domokit/sky_sdk/ which uses Dart as the UI framework. Currently runs on Android- but I believe the intent is to have it run on iOS as well.
From my perspective, Dart makes a lot more sense as an application language when compared to Go.
Basically there aren’t much reasons besides security considerations to use net/http multiplexer at all.
The baseline was profiled under STATICALL as the default net/http multiplexer does not support dynamic paths http://golang.org/pkg/net/http/#ServeMux. The benchmark is named BenchmarkHttpServeMux_StaticAll you can read the code at https://github.com/julienschmidt/go-http-routing-benchmark/b.... Frankly, net/http it not a very good http router. The results show that julienschmidt/httprouter trie based implementing outperforms net/http by 60x.
That’s a good and very viable option to consideration, and is a factor for when you start focusing on the direction but I think it’s unwise to being with narrowing down the options based on such constrains as IMHO this does not lead to the optimal solution but instead to a compromise.
// (btw, totally OT) If you’d like to know where I’ve learned about this reasoning, kindly introduce self to http://hpmor.com (chapter 35-45, can’t remember more specific than that).
I'm also interested in peopels opinions of Neptune in that domain.
Mostly for medical reasoning on RDF OWL ontologies such as "Ontology Development and Debugging in Protégé using the OntoDebug Plugin"[1]
[1] https://www.youtube.com/watch?v=vHmC-rRuMYM