Live data from Hacker News

Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

dcs.gla.ac.uk

1–10 of 59 posts

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#2
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

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#3

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 eve…

[deleted]

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#4

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

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#5

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 eve…

I don't think erlang procs are fibers, they are allotted a certain timeslice and if the instructions for the function exceed the timeslice the function is preempted and the VM comes back to it later, it's also preempted if it blocks on io or waiting for a message, of course.

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#6

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 eve…

>C# and F# are VM languages that run on the CLR

well normally, there are some cases where you can compile C# and f# native now:

mono can do it, that is how it targets IOS microsoft has tooling that does it for universal apps and coming soon! AOT native compilation for anything you want.

But yes, the normal way of things with C# and F# is just like Java, and Java has special cases where you can do AOT compilation too.

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#7

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 eve…

> 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?

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#8
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.

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#9
post #8

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.

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.

Re: Comparing Languages for Engineering Server Software: Erlang, Go, and Scala/Akka [pdf]

#10
post #8

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.

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

Post reply on HN