Who would have thought that a brand new language wouldn't have the features, library support and optimization that the more popular languages have? Should be obvious, but then you read through HN posts with people dismissing languages like C++ and Java as 'too old' or something and that you need to use some brand new untested language to be worth talking about.
Never select a language based off hearing about it on HN or blogs. Either stick with what you know or use a tool that has very specific optimizations for the problem you're going to tackle (and no, concurrency is not a good option to jump off the JVM as it has incredible concurrency support already: see https://github.com/LMAX-Exchange/disruptor for the fastest concurrent bus I've seen in any language). Of course, there is nothing wrong with testing out golang or haskell - just don't force your paying client to test it out with you or you might be one less client shortly.
Haskell (and Lisp) will always be 'new'. Especially going by HN posts which seem to think that Haskell is some brand new language created last week to solve the problem of 'side effects' and in a few months time everyone will be using it.
Built by a company with the time, money, and motivation to train new hires on an esoteric language that happens to be specifically designed for their unique application.
(Incidentally, my mobile phone calls are quite rare. Voice communication sucks. If your intent was to show that Erlang is important to me, you chose a poor example.)
The genious behind LMAX is the way they bend Java's object layout features; they achieve nice performance in spite of using Java, not because of it. Some decade old message passing libraries (OpenMP et al.) will probably outperform LMAX without even trying.
Actually, i doubt it. The machine code that ends up running at the heart of a disruptor is pretty minimal, and it executes precisely zero lock or atomic operations when handing an object from one side to the other. I am not aware of any other message-passing system that lightweight. I would be genuinely interested to hear about one.
>Who would have thought that a brand new language wouldn't have the features, library support and optimization that the more popular languages have?
Because there are "brand new languages" out there that are more mature than Go, and better than it for his needs. Scala and Clojure come to mind, but even something like Nimrod would be perfectly capable.
You mention it as if being "new" is some kind of excuse.
Never select a language based off hearing about it on HN or blogs. Either stick with what you know or use a tool that has very specific optimizations for the problem you're going to tackle (and no, concurrency is not a good option to jump off the JVM as it has incredible concurrency support already: see https://github.com/LMAX-Exchange/disruptor for the fastest concurrent bus I've seen in any language). Of course, there is nothing wrong with testing out golang or haskell - just don't force your paying client to test it out with you or you might be one less client shortly.