this is a very nice forum,check it out https://www.bit.ly/2M0hqJa
Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
31–40 of 59 posts
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#32This 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 specifi…
Crystal's multi threading model will eventually be exactly the same as go's, not ruby's, but yes its not done yet.
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#33Any thoughts on Cloud Haskell?
Some educated guesses here:
(1) Cloud Haskell is primarily designed for execution on distributed memory architectures where the messages pass over a network. So expect that the it would show high communication latency in the first PingPing benchmark.
(2) GHC Haskell processes are lightweight, i.e. maintained in the GHC Runtime Environment, and elsewhere in this discussion called fibres. So expect that it would have fast process creation and be able to sustain a large maximum number of processes (second benchmark).
(3) It's hard to speculate on throughput (third benchmark). The high communication latency may be hidden in a steady state by having multiple requests in the network. Haskell execution time is slower than many languages, but is probably comparable with Erlang and Scala.
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#34Any thoughts on Cloud Haskell?
Some educated guesses here: (1) Cloud Haskell is primarily designed for execution on distributed memory architectures where the messages pass over a network. So expect that the it would show high communication latency in the first PingPing benchmark. (2) GHC Haskell processes are lightweight, i.e. maintained in the GHC Runtime Environment, and elsewhere in this discussion called fibres. So expect that it would have f…
> Haskell execution tome is slower than many languages, but is probably comparable with Erlang and Scala.
Do you have specifics on that matter ?
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#35Earlier quoted context omitted.
> Scala is known for generating somewhat slower code than Java so I would expect Java with fibers to perform 2-10x better Got a source for that?
Benchmarks game used to have stats for Scala but apparently not anymore. Many of Scalas abstractions, unlike Kotlin, have runtime cost
Well, you don't have to use those abstractions. But yes, it's a sad fact that when programming in Scala, the closer to Java-style you program, the faster your program will be.
I haven't read this paper closely, but it looks like it's more measuring the performance of Akka, rather than the performance of Scala. Akka does reasonably well here compared to Erlang, so I don't think there's anything we can complain about.
Could you get all of Akka's features with better performance if it was made in Java? I doubt it. Optimized Scala and Java code should be identical.
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#36Earlier quoted context omitted.
> Scala is known for generating somewhat slower code than Java so I would expect Java with fibers to perform 2-10x better Got a source for that?
Benchmarks game used to have stats for Scala but apparently not anymore. Many of Scalas abstractions, unlike Kotlin, have runtime cost
This depends on the VM you are using.
Currently GraalVM gives Scala a huge speedup (sadly the speedup comes with startup cost, etc, which would not benefit the bechnmarks game)
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#37Earlier quoted context omitted.
Some educated guesses here: (1) Cloud Haskell is primarily designed for execution on distributed memory architectures where the messages pass over a network. So expect that the it would show high communication latency in the first PingPing benchmark. (2) GHC Haskell processes are lightweight, i.e. maintained in the GHC Runtime Environment, and elsewhere in this discussion called fibres. So expect that it would have f…
> Haskell execution tome is slower than many languages, but is probably comparable with Erlang and Scala. Do you have specifics on that matter ?
There are various multi-language benchmarks, e.g. https://benchmarksgame-team.pages.debian.net/benchmarksgame/
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#38Earlier quoted context omitted.
> Scala is known for generating somewhat slower code than Java so I would expect Java with fibers to perform 2-10x better Got a source for that?
Benchmarks game used to have stats for Scala but apparently not anymore. Many of Scalas abstractions, unlike Kotlin, have runtime cost
> Many of Scalas abstractions, unlike Kotlin, have runtime cost
Whoa there, many of Kotlin's do too. Because one uses an option class and another inserts precondition checks in a lot of places, doesn't mean the latter is zero cost. While Kotlin overall probably has less overhead with better primitive use and what not, there are cases where Scala is less because of macro support.
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#39Earlier quoted context omitted.
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.
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".
Go has a built in message passing system in the language but you can share memory between goroutines without friction, and you can lock goroutines to real os threads if you want, too. I did both in my gameswithgo stream. It was a fun time!
Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]
#40I 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 eve…
Akka is built on top of the JVM which doesn't support fibers (yet: see 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.
Quasar is Loom. Hopefully pron chimes in.