Joel Reymont's frustration with Erlang | Hacker News Reader

Joel Reymont's frustration with Erlang

groups.google.com

55 pointsluccastera24 comments

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.

Why did this get modded down? It seems informative and it's on topic. I don't know Erlang. Is this information incorrect or something?

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).

(I didn't mod jlouis down just to be clear.)

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.

Erlang has reached prime time decades ago...

"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.

That is unfortunate - having "played" on and off for erlang for a little while, I have noticed they steadily improve usability things like that.

However a bytecode thing is a bit more serious, but I am sure they will address that given time.

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.

sudo sysctl -w kern.ipc.somaxconn=512

http://www.macgeekery.com/tips/configuration/mac_os_x_networ...

Looks like you might be right from the update he posted on his blog.

http://www.wagerlabs.com/blog/2008/09/erlang-sucks.html#more

Tried this. Still got timeouts.

I much prefer Hacker News, btw, compare the coverage on Reddit ;-).

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).

Scaling something to 10K isn't easy no matter what system you use. Erlang isn't a silver bullet.

Right.

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.

I think his point was finding the points of contention should be easier, not about its speed

hes also having problem fully utilizing all the cores, so adding machines wouldnt solve anything

> 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.

Then how about educating us about the specifics of how multiprocessing differs from distributed computation (honest question)?

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

Haskell is by far faster on a single core but does not scale as well across multiple cores (due to garbage collection differences).

It will soon, though. See http://hackage.haskell.org/trac/ghc/wiki/Status/Releases and "Parallel garbage collection".

A release candidate of ghc 6.10 should be out in a few weeks.

None of this would help Joel, I suppose, since he decided to move away from Haskell to Erlang for other reasons.

The new gc will be an improvement but is is till not as good as Erlang's garbage collection, which is per process.

I'd be interested to know if his problems went away on a similar Linux setup.

And this is supposed to replace java? ;)

How would JAVA do any of this better?

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 :)

Reply on news.ycombinator.com