Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

dcs.gla.ac.uk

Post reply on HN
Print view View original

11–20 of 59 posts

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

#11

Post by thermodynthrway »

monksy wrote: post #7
thermodynthrway wrote: post #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 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?

Benchmarks game used to have stats for Scala but apparently not anymore.

Many of Scalas abstractions, unlike Kotlin, have runtime cost

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

#12

Post by whiteandnerdy »

bullen wrote: post #10
gameswithgo wrote: post #9

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

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

#13

Post by thermodynthrway »

richdougherty wrote: post #4
thermodynthrway wrote: post #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 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.

Similar to Quasar then I assume. I'm sure native fibers would be faster, but bytecode is fairly close to ASM and i don't think the performance difference is large.

Benchmarks I've seen for Quasar show no performance difference to regular threads at low paralellism but it can scale much higher

Found a great article comparing Akka's Actors vs Quasar http://blog.paralleluniverse.co/2015/05/21/quasar-vs-akka/

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

#14

Post by DavidTNcl »

thermodynthrway wrote: post #11
monksy wrote: post #7

Earlier 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

Got a source for that?

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

#15

Post by zokier »

bullen wrote: post #10
gameswithgo wrote: post #9

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

Obviously Rust can share memory between threads. Just see the docs for mutex as an example:

https://doc.rust-lang.org/std/sync/struct.Mutex.html

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

#16

Post by beefsack »

bullen wrote: post #10
gameswithgo wrote: post #9

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

This comment is terribly misinformed. You absolutely can share memory between threads in Rust and can do it without race conditions (eg Arc pointers and Mutex).

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

#17

Post by [deleted] »

thermodynthrway wrote: post #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 eve…

[deleted]

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

#18

Post by pjmlp »

gameswithgo wrote: post #6
thermodynthrway wrote: post #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 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.

Actually you can compile VB.NET, C#, Managed C++ (latter C++/CLI) and eventually F# to native since .NET exists, but many seem to keep forgetting about NGEN, as it requires strong assemblies.

Likewise Java always had AOT compilers to native code, but since Sun was religious against it, only commercial third party JDKs offered it as option. It is quite common in embedded deployments.

But as usual among recent trends regarding dev tools, very few were willing to pay for them.

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

#19

Post by stephen123 »

richdougherty wrote: post #4
thermodynthrway wrote: post #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 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.

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

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

#20

Post by jacquesm »

dnautics wrote: post #5
thermodynthrway wrote: post #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 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.

Erlang does not preempt, a reduction is always completed before the scheduler decides on whether or not to move on to another thread. Reductions are small enough that this isn't a problem.
Post reply on HN