4 ms·

Joel Reymont's frustration with Erlang

55 points by luccastera 18y ago

hapless 18y ago
And this is supposed to replace java? ;)
- schtog 18y ago
  How would JAVA do any of this better?
  - evgen 18y ago
    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 :)
cypress-hill 18y ago
i like joel, his posts always get to the heart of what "everyman" coders deal with and he isn't pompous about anything i've watched him move through lisp, adopt/drop haskell, claim ocaml was the way to go, and jump on erlang my guess is that he has discovered what others have - erlang is half-baked in many ways. the community is microscopic even compared to those for lisp, haskell and ocaml. erlang is slow. haskell is faster at everything erlang does, including massive concurrency. everywhere but concurrency, ocaml and haskell destroy erlang performance by a substantial margin. haskell lisp have robust and well-used packaging systems and tools.i really don't know why erlang is so hyped. my guess is that in the end, joel will end up on c++ or back on haskell.
jlouis 18y ago
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.
- jm4 18y ago
  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?
  - hassy 18y ago
    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.)
    - ajross 18y ago
      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 http://plausible.org/nasal) does this just fine, for example.
      - yariv 18y ago
        Erlang has reached prime time decades ago...
      - hassy 18y 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.
- michaelneale 18y ago
  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.
shutter 18y ago
Scaling something to 10K isn't easy no matter what system you use. Erlang isn't a silver bullet.
- KirinDave 18y ago
  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.
  - daleharvey 18y ago
    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
    - KirinDave 18y ago
      > 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.
      - Hexstream 18y ago
        Then how about educating us about the specifics of how multiprocessing differs from distributed computation (honest question)?
sunkencity 18y ago
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_network_tuning_guide_revisited http://www.macgeekery.com/tips/configuration/mac_os_x_networ...
- cjenkins 18y ago
  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 http://www.wagerlabs.com/blog/2008/09/erlang-sucks.html#more
  - wagerlabs 18y ago
    Tried this. Still got timeouts. I much prefer Hacker News, btw, compare the coverage on Reddit ;-).
    - sunkencity 18y ago
      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).
quasomojo 18y ago
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
- gregwebs 18y ago
  Haskell is by far faster on a single core but does not scale as well across multiple cores (due to garbage collection differences).
  - vegai 18y ago
    It will soon, though. See http://hackage.haskell.org/trac/ghc/wiki/Status/Releases 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.
    - gregwebs 18y ago
      The new gc will be an improvement but is is till not as good as Erlang's garbage collection, which is per process.
vegai 18y ago
I'd be interested to know if his problems went away on a similar Linux setup.

55 points by luccastera 18y ago

hapless 18y ago

And this is supposed to replace java? ;)

schtog 18y ago
How would JAVA do any of this better?
- evgen 18y ago
  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 :)

cypress-hill 18y ago

i like joel, his posts always get to the heart of what "everyman" coders deal with and he isn't pompous about anything i've watched him move through lisp, adopt/drop haskell, claim ocaml was the way to go, and jump on erlang my guess is that he has discovered what others have - erlang is half-baked in many ways. the community is microscopic even compared to those for lisp, haskell and ocaml. erlang is slow. haskell is faster at everything erlang does, including massive concurrency. everywhere but concurrency, ocaml and haskell destroy erlang performance by a substantial margin. haskell lisp have robust and well-used packaging systems and tools.i really don't know why erlang is so hyped. my guess is that in the end, joel will end up on c++ or back on haskell.

jlouis 18y ago

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.

jm4 18y ago
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?
- hassy 18y ago
  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.)
  - ajross 18y ago
    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 http://plausible.org/nasal) does this just fine, for example.
    - yariv 18y ago
      Erlang has reached prime time decades ago...
    - hassy 18y 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.
michaelneale 18y ago
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.

shutter 18y ago

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

KirinDave 18y ago
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.
- daleharvey 18y ago
  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
  - KirinDave 18y ago
    > 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.
    - Hexstream 18y ago
      Then how about educating us about the specifics of how multiprocessing differs from distributed computation (honest question)?

sunkencity 18y ago

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_network_tuning_guide_revisited http://www.macgeekery.com/tips/configuration/mac_os_x_networ...

cjenkins 18y ago
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 http://www.wagerlabs.com/blog/2008/09/erlang-sucks.html#more
- wagerlabs 18y ago
  Tried this. Still got timeouts. I much prefer Hacker News, btw, compare the coverage on Reddit ;-).
  - sunkencity 18y ago
    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).

quasomojo 18y ago

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

gregwebs 18y ago
Haskell is by far faster on a single core but does not scale as well across multiple cores (due to garbage collection differences).
- vegai 18y ago
  It will soon, though. See http://hackage.haskell.org/trac/ghc/wiki/Status/Releases 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.
  - gregwebs 18y ago
    The new gc will be an improvement but is is till not as good as Erlang's garbage collection, which is per process.

vegai 18y ago

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