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.

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.

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.

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

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

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.

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

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.

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

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

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

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.

I would love to know your thoughts on this.

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.

I joke! In all seriousness, did you find your concentration improved as you didn't feel the desire to constantly check for text messages or emails?

Then I was sitting down reading a book (Speaker for the Dead by Orson Scott Card) and realised I'd blown 4 hours on it rather than doing any work. Rushed and grabbed the laptop and nothing was broken, on fire and no one had emailed me. Then I did a two hour coding binge. Did more on that day than any other and it has just got better and better.

Concentration has improved as has tolerance and patience. I also read a lot more because I have the time to.

I'm only posting on here because I'm waiting for compile cycles :)

Windows 8.1 Pro with Lenovo power manager installed via windows update.

Dual boot.

I would check the Lenovo recall page (google it) before paying for one. That's where I got my new one from - they replaced it free of charge ;-)

Performance isn't an issue really even though its an i5. If it is too slow, I ship the problem elsewhere (the feck off great big 24 core E5 HP Z620 in the office).

Sure there may be 10% difference between BSD and Linux but that's negligible these days versus the positives (like being able to just pkg install ruby21 without having to bugger around with rvm or wait three years for debian to pick it up in stable)

This isn't a total give away, this is a loss leader which is just selling an editing front end for the files, not anything like the power of the full product.

However, I really think that Office on the desktop is a turd but it does make automation pretty easy but slightly awkward and painful. Perhaps this is bitterness from converting VSTO and Word interop to late binding all morning but I'm not a fan.

This is "meh" even to someone as embedded into the ecosystem like myself.

I'd rather give up on Office entirely, but its relative ubiquity plus free apps mean I'll let the camel stick its nose back under my tent.

It's surprisingly common. Even my wife who is a complete luddite has a couple of scripts for excel she copied off a web site to do a tax calculation.

Not bitter at all. Nope.

It's now a nice clean late-bound C# command line tool and powershell cmdlet.

These are all real problems I've had to work around.

Now, it's post-PC. This is opening up Office to a whole new generation of users who have found their home in tablets.

While it is a solid move for Microsoft, that whole generation of new users wont see much of a difference between 2014 office for ipad and numbers.

I bought my wife a Chromebook as a stopgap when her last Windows laptop died, and although she still has to use Windows for work, she now swears by Drive for working on shared documents.

I'm just as bad really but I've kept it down to a mere 18Gb and it spans back to my first serious programs on Acorn RISCOS in BASIC and ARM assembly. I still fire up and emulator and fix bugs in them occasionally. They are still useful despite being old.

Nostalgia is painful sometimes however as not all those files are readable and perfectly preserved.

And that's exactly how it should be.

I will say that this time is only available from ruthless automation and organisation.

I spend the other 20 hours making sure I only have to do 20 hour weeks forever (startup).