3 ms·

It is fallacious to pretend erlang is slow because otherwise you have to write bad, unoptimized C code. First of all, unoptimized C is still an order of magnit

It is fallacious to pretend erlang is slow because otherwise you have to write bad, unoptimized C code. First of all, unoptimized C is still an order of magnitude faster than erlang (or more!). Second, there are other languages besides just erlang and C. For example, compared to erlang I can write the same thing in haskell instead, have it written faster, have fewer bugs make their way into production, and have it run faster.

jlouis 14y ago
If your C code is doing linear scans over arrays where a dictionary style lookup is really needed, then there is no way in hell the C code is going to beat the Erlang code. I've seen this again and again in C programs. As for your Haskell program, you are right. But you will spend the next 3 months trying to fix memory leaks due to lazy evaluation :) I think the bottom line, one we can agree on, is that a program written is not the end of development. It needs maintenance and where certain programming languages makes it easy to do something, other languages have a harder fare, and vice versa. Erlang has a state-of-the-art interpreter. And a runtime written in C. It is not a slow language if you have a program that spends most of its time waiting for other things to complete or in the runtime. In fact, that is where it shines. That said, don't write CPU-bound jobs where constant factors matter in Erlang. It is a bad fit for this, because of its interpretation overhead.
- papsosouid 14y ago
  So now we're not just comparing optimized erlang to unoptimized C, but optimized erlang doing X to unoptimized C doing Y. You can write the wrong code in erlang too, C does not have any special (mis)features that encourage doing the wrong thing. It dishonest to say "erlang isn't slow" and use "I can write slower C code if I do it on purpose" as evidence.
  - jlouis 14y ago
    The thing is that "slow" is naturally relative. I hate it when people claim that a tool is slow. By far the most important factor in getting programs that work isn't the technology but the mind behind the code. This is true for any programming language. I guess the succinct answer is: No, Erlang isn't slow if you know what you are doing, barring the Caveat about CPU-bound problems. The message I am trying to convey is that there is more to fast programs than the execution speed of the technology at hand. It is a factor, admittedly, but it is not the sole factor.
klibertp 14y ago
> unoptimized C is still an order of magnitude faster than erlang Even JITed(or just compiled to native code) erlang? I'm really curious.
- papsosouid 14y ago
  Unless there's something better than HiPE that I'm not aware of (which may very well be the case, I am far from an erlang expert).
reddit_clone 14y ago
When your C code has to do all the stuff that Erlang already does, it would also be suitably slow.

jlouis 14y ago

If your C code is doing linear scans over arrays where a dictionary style lookup is really needed, then there is no way in hell the C code is going to beat the Erlang code. I've seen this again and again in C programs. As for your Haskell program, you are right. But you will spend the next 3 months trying to fix memory leaks due to lazy evaluation :) I think the bottom line, one we can agree on, is that a program written is not the end of development. It needs maintenance and where certain programming languages makes it easy to do something, other languages have a harder fare, and vice versa. Erlang has a state-of-the-art interpreter. And a runtime written in C. It is not a slow language if you have a program that spends most of its time waiting for other things to complete or in the runtime. In fact, that is where it shines. That said, don't write CPU-bound jobs where constant factors matter in Erlang. It is a bad fit for this, because of its interpretation overhead.

papsosouid 14y ago
So now we're not just comparing optimized erlang to unoptimized C, but optimized erlang doing X to unoptimized C doing Y. You can write the wrong code in erlang too, C does not have any special (mis)features that encourage doing the wrong thing. It dishonest to say "erlang isn't slow" and use "I can write slower C code if I do it on purpose" as evidence.
- jlouis 14y ago
  The thing is that "slow" is naturally relative. I hate it when people claim that a tool is slow. By far the most important factor in getting programs that work isn't the technology but the mind behind the code. This is true for any programming language. I guess the succinct answer is: No, Erlang isn't slow if you know what you are doing, barring the Caveat about CPU-bound problems. The message I am trying to convey is that there is more to fast programs than the execution speed of the technology at hand. It is a factor, admittedly, but it is not the sole factor.

klibertp 14y ago

> unoptimized C is still an order of magnitude faster than erlang Even JITed(or just compiled to native code) erlang? I'm really curious.

papsosouid 14y ago
Unless there's something better than HiPE that I'm not aware of (which may very well be the case, I am far from an erlang expert).

reddit_clone 14y ago

When your C code has to do all the stuff that Erlang already does, it would also be suitably slow.