Comment by istvan__ | Hacker News Reader

Comment by istvan__ | Hacker News Reader

Parent Full thread

"However, they will not replace Go for a rather simple reason. Erlang is an application runtime first and a language second. It's not meant to play with the native OS all that well, instead relying on its own scheduling, semantics, process constructs and the OTP framework. It exports a minimum set of OS libs for things like file system interaction, but you wouldn't write a Unix subsystem daemon in it. Though, you certainly can - if you want to hack with NIFs, port drivers and C nodes. But then you put the global VM state at risk if some native caller blows up."

I have to disagree here. One of the best applications of modern times ever written in Erlang is Riak. It has lots os system services, they do IO a lot (it is a key-value store after all) and it works beautifully. It is using LevelDB under the hood for storing the data on disk and it is written in C++. Erlang makes it possible to have a distributed service using Erlang for the distributed parts and C++ for the disk IO combining the best of both worlds.

You are right about the potential NIF problems, but one shortcoming that can be possible worked around does not invalidate the rest of the system that is cutting edge.

How can you be sure that Erlang is great? Just look into projects like Akka and many more Scala project, they pick up features from Erlang because it simply works, easy to understand and reason about.

The notion of Erlang replacing Go is funny anyways because Erlang existed for much longer time than GO and even if you are looking in the web stack in Erlang it is pretty cool. Webmachine is one of the most stable tools out there, providing absolutely amazing latency and a state machine to handle HTTP requests.

Go as a language is new and certain way immature (like debugging and generics for example). It is an ok environment to develop in, but I would use Erlang/Elixir much more willingly for HTTP services (saying this after tried to use Go for a while but I just gave up, it was too much hassle for not too much gain).

For the record, I don't need any convincing of Erlang's greatness. I know that and I'm a big fan of programming in it.

Nor did I ever deny that Erlang excels at I/O, that much is obvious. I made it clear the various ways of interfacing with native code, as well.

But I wasn't talking about more abstract distributed services, rather stuff that brutally exploits POSIX and kernel-specific APIs. Using Erlang would probably be inconvenient for most people, so they'd use a language that seamlessly interacts with its host and has a small runtime, understandably. Not that you couldn't reap benefits from supervision, multi-node distribution, hot reloading and other things if you made the effort to do some elaborate hacking with ports and NIFs.

Erlang/OTP blows Scala/Akka out of the water for me, personally.

Heh it was coming through at the first sight, you know it very well.

" I know that and I'm a big fan of programming in it." Me too btw. :)

I see your point, yes that is absolutely true. I think one reason why Erlang is great because they realized that exposing the POSIX threading APIs to software developers is harmful. :) Why would you ever want to know how many cores you are running on? If you know it you have to keep track of it and adjust it on different systems and bunch of other issues. On the top of that POSIX threads are so expensive that it totally did not make any sense to implement a system that allows the developer to create a thread. I think Joe & team made an excellent decision there. On the other side, you can't really access these low level primitives so this is I guess what you are talking about. For the low level stuff you need a systems language (C,Go whatever).

Oh, yeah, JVM based actors are kind of interesting. I am not sure how can they meet any latency SLA. The GC is skewing the response time potentially, right? In Erlang/OTP it does not happen because of the GC implementation as you know.

I've used the JVM and actors on top of it for real-time bidding, which is normally a soft real-time job because you usually have contracts in which you have to promise to reply to requests in 100 or 200 ms maximum, including the network roundtrip, otherwise you'll be taken off the grid. Our system was replying to over 33,000 of such requests per second on only a couple of instances hosted on AWS.

The garbage collector was a problem and as usually it required us to profile and pay attention to memory access patterns, plus a lot of tuning of that garbage collector. But truth be told, we were also much sloppier than what people do in the financial industry. For example we did use Scala, functional programming and immutable data-structures, which ca bring with it significant overhead, since the profile of persistent collections does not match the assumptions of current generational garbage collectors. But on the JVM you also have options not available on other platforms. The G1 GC is pretty advanced and at scale the commercial Azul Zing promises a pauseless GC and has been used successfully in the financial industry.

I also used Erlang and in my experience the JVM can achieve much lower latency and better throughput. Where Erlang systems tend to shine is in being more resilient and adaptable.

Everything can be done, you can invest a lot of time to make your code run better on JVM and tune the GC settings etc. If you make the same investment into the Erlang ecosystem (like for example WhatsApp guys did) I think you could match the JVM performance in terms of handling number of connections and staying responsive. If your code does numeric calculation most of the time you are probably having a better time on the JVM though.

http://www.erlang-factory.com/upload/presentations/558/efsf2...

Reply on news.ycombinator.com