41–50 of 59 posts
Earlier quoted context omitted.
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.
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.
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 li…
Regarding unused variables, the only solutions I am aware of involve renaming to underscore, commenting out or passing to a function like fmt.Println.
Earlier quoted context omitted.
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.…
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 li…
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.
Any thoughts on Cloud Haskell?
Earlier quoted context omitted.
> 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/
GHC Haskell is an advanced optimising compiler that will produce considerably faster functional code than both Erlang and Java. For maximum performance, it is perfectly possible to write imperative array-oriented code in Haskell, in which case performance should be comparable to Java.
Earlier quoted context omitted.
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.
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.
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 benc…
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
p() ->
erlang:hibernate(?MODULE, q, []).
q() ->
receive
"hello" ->
io:format("Hello")
end.