[cowabunga]

Not sure I agree with the conclusions:

1. Binaries: this isn't really an issue. We ship the JVM with anything that we do in Java. Unzip, run, done. Go is probably ideal there but it doesn't support embedded resources without some hideous hacks so you're still going to be deploying more than just a single binary in a lot of cases. CLR is pretty good at this as well.

2. Sockets: 0MQ/WCF/JMS/any stream abstraction wired up correctly.

3. ASN.1: Everything has ASN.1 libraries these days. I've never had to use one in the real world in any of the sectors I've worked in.

3. Let it crash: we do this. In fact we force threads to crash if they do anything bad by throwing an exception that isn't caught. All threads are designed to be idempotent, restartable and transaction aware. This is true in JVM/CLR at least.

4. Supervision: New thread, new state, no shared state. Not hard. PHP does this...

5. Inspection: I've seen the Erlang toolchain and it's pretty good but I'm not joking but inspecting and debugging the state of a system is better when there is lots of pooled knowledge (google) and lots of diverse tools. JVM wins there every time.

7. Messaging is not RPC: It's not in JMS either or WCF. It abstracts the transport away. In fact we have inproc transports in some cases that use concurrent collections to throw messages around.

8. Dialyzer: compiler, static typing (Java is less strong here to be honest than say C#).

I really like the idea of Erlang but the worse is better mantra applies here. It's easier to get staff, the knowledge when something goes pop is available, we benefit from the reuse of billions of lines of code written and tested by others if we pick a JVM. If we have to think a bit or throw some more kit at it, so be it.

Edit: just to add, I'm not knocking Erlang and quite like it in principle (I spent 2 months disassembling CouchDB to see if we could maintain it so it's not a foreign language to me), but the justifications in the reply aren't particularly unique ones nor are they major advantages.

[dozzie]

1. I don't see how this is related to working with binary data.

2. Apparently you haven't worked with Erlang. The point here is you don't write much networking, you write message handling exactly in the same manner as you would for communicating inside the application, without any networking. 0MQ, WCF and JMS don't even remotely resemble the operation model for network connectivity in Erlang.

3? (Let it crash) And you needed to specifically design your application, including supervision (you do have it, right?). Erlang provides all that already.

4. You didn't get what supervision is about. It's about restarting process when it crashes, crashing all the related processes and aborting when restarts are too frequent.

> It's easier to get staff,

It's easier to get some staff, but it may be much harder to get good staff. Signal-to-noise ratio is very bad among Java programmers. And it's quite hard to find bad Erlang programmer once you find somebody who can write in Erlang (or learn it quickly).

It's not that Erlang provides one specific killer feature that makes it great choice. It's that Erlang provides plenty of nice things already built in, and all that sums up to a platform that one would want to use every day. You don't have good binaries syntax on top of JVM. You don't have good logging framework in standard JVM. You still need external libraries for sensible network programming. You have to design your application specifically to handle thread failures. You can't just spawn a thread for every request running and be done with the job. You don't have a distributed soft real-time database. And the list goes on.

You just need to do much work before you even start programming, and then to manage all that (which is no easy task), just because your platform doesn't provide any of the mentioned things and its working model is less convenient for writing network services.

[dschiptsov]

Comparing "features" side-by-side is a naive, "consumer-mindset" approach. Instead one should try to understand design-decisions and how they fit together - the subtleties. Devil is in the details.

For example, having an receive expression and pattern-matching and simple typing (like everything is a term - self-evaluating or an expression or a list of terms) makes your code shorter, self-evident, easy testable.

Now let's look one level down. Pattern-matching on binary data (alternative to costly parsing) is so quick that in OTP they do matching on TCP packets in real-time.

Conversion from terms to binary and back is also quick. So the the "central idiom" - message-passing - is just sending and receiving a list of terms (atoms) on a language-level (guarded pattern-matching, like on function arguments) while messages will be encoded into efficient binary form and delivered by Erlang's runtime.

Again, almost everything in Erlang fits together pretty well because it is layered system founded on proper principles and design decisions. Immutable data, share-nothing process isolation, light-weight processes, common and simple data-representation format based on simple types, pattern-matching on everything, etc.

It is almost like industry-strength Lisp system - a few layers of DSLs, using which one describes the real-world abstractions on different levels on different sub-languages (based on special forms and function composition).

gen_server is the most common example of such kind of "vertical" decomposition. You have to write only "pattern-matching on receive", while lower layers of abstraction (encoding, protocols) and upper levels (process supervision) are clearly separated with proper abstraction barriers.

Of course, it is possible to code something like this in Java, but there are the subtleties. GC for mutable data could not be as efficient as one for immutable data. No mutable state, no sharing, no locking, no problem. These aren't just slogans.

So, Erlang is a small language designed around proper concepts. It "wins" not only in terms of lines of code, but in efficiency, resource usage (Erlang runs on 16Mb RAM).

I could go on, but I hope the idea is already clear. It is not a "list of features" what matters, but which ones we have and especially don't have, and how they are fit together. In small mostly-functional languages like Lisps or Erlang or ML-family they fit perfectly.

http://www.erlang.org/doc/man/gen_server.html

[pjmlp]

> Erlang runs on 16Mb RAM

I imagine you are referring to the full stack, as JVM and CLR implementations do exist which require a few hundred KB.

As for the rest I fully agree.

[davidw]

He's talking about dealing with binary data when he says 'binaries':

http://www.erlang.org/doc/efficiency_guide/binaryhandling.ht...

http://www.erlang.org/doc/programming_examples/bit_syntax.ht...

Erlang is really strong for that.

As to Java, sure, you can do anything with it, and do a decent job of it. But sometimes, as a startup, you are resource constrained, so if you can do more with less because you have a good grasp of a tool like Rails, or Erlang or Lua or whatever, that might make the difference. For a large company, Java is definitely a safe pick - no one ever got fired for choosing it: you'll be able to get whatever you need done, and "If we have to think a bit or throw some more kit at it, so be it." For a group like WhatsApp, Erlang seems to have been a good pick.

[rwmj]

I copied my OCaml bitmatch library from Erlang. It's a really great feature of Erlang.

https://code.google.com/p/bitstring/

[cowabunga]

Thanks for the clarification! My bad.

Yes it is far superior from a representation point of view at least there. I have no doubts about that.

[jacquesm]

Besides the various mis-interpretations in your comment you are comparing features, but instead you should be comparing systems. Erlang is not a language, it is better thought of as an operating system with a very large amount of work and experience thrown behind two goals: reliability and scalability.

The difference between having such goals stated during the design phase and then keeping sight of them during all future development and say you forcing a thread to crash in the JVM is that in Erlang this is the way to do it, in Java you're going to have to re-implement your supervisor and clean-up yourself. And you'll probably get it subtly wrong.

Erlang is not a bunch of features that you can get elsewhere, it's an integrated whole on a very solid foundation with decades of proof of reliability behind it.

[daleharvey]

> 1. Binaries: this isn't really an issue. We ship the JVM with anything that we do in Java. Unzip, run, done. Go is probably ideal there but it doesn't support embedded resources without some hideous hacks so you're still going to be deploying more than just a single binary in a lot of cases. CLR is pretty good at this as well.

Not sure you read / understood what that point was about, due to its native binary types, tail recursion and pattern matching make dealing with binaries easier in erlang than most other languages

As far as most of the other points, you are mostly agreeing with the statement "nothing is impossible with other languages compared to erlang, but its better designed for this"

PHP does not so long process thread supervision (I mean it can but close to 0 people use it that way), Being able to inspect running processes is useful as well as the fact google is helpful, the JVM's entire ecosystem isnt based around a let it crash concurrent process isolation philosophy and java in particular is one of the worst offenders at having to ember error handling code at almost every point of your application logic

[cowabunga]

Yes thank you for the clarification.

My point is more that regardless of the syntax, runtime or approach, the same outcome is possible without having to enter a risky niche.

PHP does nothing, but if you throw it in a prefork MPM module in apache, it does that.

Sure we don't let it physically crash and we handle the exception at the base of the thread and decide what to do, but the outcome is the same. Java error handling is absolutely fine and in some cases, far less painful that the "err" semantics of Go.

[platz]

The difference is that Erlang decouples the handler of the exception (the supervisor) from the caller.

In most other languages, the caller is forced to deal the the exception, which litters the responsibility to resolve the exception across all consumers.

This is qualitatively different from erlang

[marianoguerra]

1. Binaries refers to binary pattern matching, not how you build/deploy the software

3. it's not only letting it crash, it's supervisors, restarts, cascading crashes when the parents retried enought times. Yes you can do it in other languages, but in erlang it's already done and battle tested.

4. that's not supervision

7. in erlang sending a message to a process in the same cpu and in another server has the same syntax and it's the common way of building software, in other languages calling a method and doing a jms message are two different things that you have to deal differently.

8. I would add quick check to the mix, but yes, dialyzer is just a kind of progressive typing

[brickcap]

>I spent 2 months disassembling CouchDB to see if we could maintain it

I would love to know your thoughts on this.

[octo_t]

wrt point 1, that's poor phrasing, when he says binaries, I think he means binary data, not executables.

[seiji]

1. Binaries: this isn't really an issue. We ship the JVM with anything that we do in Java.

That comment is just about the exact definition of the blub paradox.

When presented with a more advanced idea, there's no underlying context to join the discussion, so the brain jumps to what it "already knows" instead of a more advanced concept of what's actually being talked about.