
Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf] - jxub
http://www.dcs.gla.ac.uk/~trinder/papers/sac-18.pdf
======
thermodynthrway
I appreciate the time obviously spent on this, but i see a couple errors and
ommissions. C# and F# are VM languages that run on the CLR which is extremely
similar to the JVM.

Also, Go and Erlang use fiber blocking threads (userspace threads). A fair
comparison would use fiber blocking in Scala/Java as well using Comsat/Quasar.

I have a feeling JVM based languages would perform far better than Erlang, and
possibly even as fast as Go if fiber blocking threads were used.

Edit: they're using Akka which (I believe) IS fiber blocking so part of my
critique may not apply. However, Scala is known for generating somewhat slower
code than Java so I would expect Java with fibers to perform 2-10x better

~~~
richdougherty
Akka is built on top of the JVM which doesn't support fibers (yet: see
[http://openjdk.java.net/projects/loom/](http://openjdk.java.net/projects/loom/)).
Akka implements its own scheduling atop Java's fork-join thread pool. Fibers
at the JVM layer would be faster.

~~~
stephen123
Not only that, its non blocking. Meaning you can have a very small thread pool
with great performance. Think 1 thread per core.

------
ehonda
I recently switched the core pages of my website (a small search engine) to Go
from PHP. Have not implemented any goroutines yet, just focused on a line-by-
line port for now, and it was overall a fun experience. I would highly
recommend Go. Only downside is the smaller (but growing) community of
developers, so you might spend a little more time finding answers. Also I wish
it didn't force you to comment out unused libraries or unused variables when
you're trying to troubleshoot something. It should be allowed when running,
but keep it restricted when building maybe?

~~~
jxub
Look up the vscode-go extension. It adds/removes unused imports automatically
and thus removes most of the friction.

Regarding unused variables, the only solutions I am aware of involve renaming
to underscore, commenting out or passing to a function like fmt.Println.

~~~
Xeoncross
Atom IDE, vim, and just about anything that uses goimports, gocode, and the
other packages works great.

------
ramchip
> In the experiments we use the following versions of the languages:
> Erlang/OTP 19.0, Go 1.7.1, Scala 2.12.0 with Akka 2.4.12.

These are pretty outdated, it would be interesting to see numbers on the
latest versions. I'd be especially curious to compare with Erlang/OTP 21.0
(coming out today) as they did a lot of optimization work on the attributes
tested in this benchmark.

------
partycoder
Any thoughts on Cloud Haskell?

~~~
_k3an
If you are comparing to Go then just regular Haskell has all the same
capabilities and more (lightweight threads and communication primitives, plus
extra cool stuff like software transactional memory). Cloud Haskell is trying
to put it more in the Erlang camp where you can distribute beyond a single
process transparently, but I don't think it is well maintained or really
production ready.

~~~
partycoder
More specifically, thoughts comparing Akka, Erlang and Cloud Haskell, which
are 3 different implementations of the actor model.

------
maximveksler
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.

~~~
dnautics
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.

~~~
RX14
Crystal's multi threading model will eventually be exactly the same as go's,
not ruby's, but yes its not done yet.

------
bullen
Only C++ and Java(C#) can share memory between threads. If you are going to
compare things you probably should understand that and design the test so that
it shows the difference. If the application is so simple it can scale on
different machines, the performance doesn't really matter.

~~~
gameswithgo
Am I misunderstanding what you mean?

C#, F#, Go, and Rust can share memory between threads. Those are just ones on
the list I am sure about.

~~~
bullen
C# can, it's design is copied from Java. Go and Rust can't share memory
natively, they need to copy data.

So you probably should not make "games with go".

~~~
whiteandnerdy
Go prefers message passing of copies using channels, but absolutely does
permit shared state if you want it. I've written multithreaded code with
shared state in Go myself. You just need to pass a pointer to the state across
a channel, and can then control access using synchronisation primitives such
as mutexes in exactly the same way you would in Java or C.

