There is a couple of problems with the current Erlang implementation that tends to nag me. One of the more problematic for newcomers is that the bytecode format doesn't contain line-number references from the original source. Hence, an error can not show you exactly where the problem occurs, but it can give you a backtrace. This is rather unfortunate for Erlangs adoption.
It's true, but it's far less of a problem than it may seem.
When your functions are short it's easy to find out where the error was from the error message.
When you think of all the great stuff Erlang gives you, small issues like these don't matter (and they do get fixed with time, the OTP team is very responsive).
Doesn't it sort of play against the idea that Erlang is ready for prime time though? I mean, come on: it's not like tracking line numbers in generated code is an unsolved problem. My own toy language (http://plausible.org/nasal) does this just fine, for example.
"Ready for prime time"? Erlang has been used by Ericsson in one of their flagship products for years, as well as by Motorola and T-Mobile. More recent examples are Amazon and Facebook. There are lots of people out there getting real work done with Erlang, many of whom say that doing it in anything else would be a major pain.
The line number issue may be an oversight, but in no way is it a flaw or something that's not there because the OTP team don't know how to do it. Concentrate on the real issues, such as the ones Joel Reymont is talking about.
I wonder if this guy tuned his network card. OS X default for max open sockets is 128, can make it hard to max out the cpu running network based loads generators.
Too bad it didn't help. I've run into that limit trying to use the tool "siege" to stress test apache, tomcat and different rails apps.
Hope you find what the problem is.
I think I recall one a podcast about an erlang project (i'm 70% sure it was an erlang project and not smalltalk), where they wanted to run on bsd, but eventually gave up because of some network issue and switched to linux. I'd suggest trying to boot the machine in ubuntu and give it a spin there, or see if you can max out a linux box that you already have access too. Linux has so many more users that the real world kinks are much more worked out than on OS X or BSD (I'm talking about server apps here).
I agree with a lot of these problems. The profiling woes with gen_server in particular are annoying and need to be addressed.
But I can't help but feel that this article shows someone who misses the point of Erlang. Erlang is not that fast on a single machine. In fact, it's basically equivalent to python for most common ops and much slower for string ops.
Erlang is about making scalable, concurrent software that you can horizontally scale across hardware. Getting >1k dynamic r/s processing is not something easy for anyone on one box. Quite frankly I'm shocked he got the numbers to go as high as they did on his box.
> hes also having problem fully utilizing all the cores, so adding machines wouldnt solve anything
See, that's the problem. You're also caught up in it. Multi-processing is not the same as distributed computation. People seem to think that the scaling of these systems is identical, and it's not. Even with Erlang, it's not.
joel rules. he will give any useful tech a chance. he approaches problems like an everyman. he isn't afraid to ask for help. i've watched him churn through lisp, haskell and ocaml, and now erlang.
i think he should give haskell another chance. it clobbers erlang on every performance metric, including massive concurrency, which we can now say erlang no longer "owns". otherwise i think c++ is the only option
By falling over after ten connections and pushing you to try Erlang, Python, Ruby, or any other language that might actually solve the problem a lot sooner than most other languages :)
