What's all this fuss about Erlang? (2007) • Hacker News Board

Re: What's all this fuss about Erlang? (2007)

#131

Post by im_down_w_otp » Wed, Jan 25, 2017, 1:50 AM UTC

momerath wrote: post #8

aaron-lebo wrote: post #2

I think the "more cores == faster" benefit is overstated. Without jit Erlang is so slow that languages without concurrency support will kill it. It's even more overstated when something like Go can mostly scale as well over multiple cores but be x times faster while doing so. Not to mention it's 10 years later and we haven't seen massively parallel architectures take off. I suspect other languages are going to fold t…

Unfortunately, I think you're correct. Anecdote: I used Erlang, over the course of several years, for very-high-level bot behavior and multi-player mission control, where performance was much less important than the things Erlang provides, but I still had issues with it. Nonetheless, I felt it had given me great leverage, and I thanked Joe Armstrong profusely, when I met him at a conference. Later at the con, I asked…

(facepalm) that somewhat closely mirrors my experience. It's a bit baffling.

Re: What's all this fuss about Erlang? (2007)

#132

Post by sokoloff » Wed, Jan 25, 2017, 1:52 AM UTC

pertymcpert wrote: post #105

devishard wrote: post #86

Earlier quoted context omitted.

>> Your Erlang program should just run N times faster on an N core processor > But only if your program is embarrassingly parallel with at least N times available parallelism in the first place! If you have one of those it's already trivial to write a version that runs N times faster on N cores in C, Java, multi-process Python, whatever. You've made two claims, one irrelevant and one false: 1. only if your program is…

WTF. How do you turn a problem which cannot be reduced into parallel sub-components into an Erlang program then? Are there just a huge class of computations that cannot be done with Erlang? Of course not.

Of course you can implement an inherently serial algorithm in Erlang. It just won't run N times faster on N cores.

Re: What's all this fuss about Erlang? (2007)

#133

Post by toast0 » Wed, Jan 25, 2017, 2:27 AM UTC

ww520 wrote: post #89

lngnmn wrote: post #28

A practical language based on well-researched first principles. Details in the armstrong_thesis_2003.pdf * java is unsuitable * no pthreads, please (wrong concept) * immutable data (no locks - no problem) * isolated lightweight processes (share nothing) * communication by message-passing (grom Kay's OOP) * dynamic typing (good-enough, quick prototyping) * pattern matching (on receive) * supervision hierarchies (fault…

In the case of Erlang, how would immutable data help? The code all run in single thread execution path in each process; there's no need for lock anyway. Each process can't access data of another process.

Immutable data (along with per process heaps) makes the garbage collection very simple.

Re: What's all this fuss about Erlang? (2007)

#134

Post by jerf » Wed, Jan 25, 2017, 2:49 AM UTC

novembermike wrote: post #76

geodel wrote: post #27

Earlier quoted context omitted.

I searched many times the comparison of Erlang BEAM and JVM regarding performance but couldn't find much. May be it is not done, or maybe it is not publicly available. At my work some folks keep pushing RabbitMQ over ActiveMQ for no other good reason than it is in Erlang so we will get much better performance. I know it is not true but could not find web links to support that.

BEAM is slower than the JVM for sequential code but it doesn't have a block the world GC and it has preemptive multi processing. It'll have worse steady state performance but a lot of the worst cases that Java can have are heavily mitigated.

It's also realllly good at routing; the control logic is a somewhat slow more-or-less interpreted language speed but then the act of routing bytes around runs at native speeds (as long as you keep things in binaries and don't convert them to "strings"), with the Erlang framework making sure by the nature of how it works that there's no contention or anything getting in the way because everything's immutable.

It's sort of like how people talk about how NumPy can be so useful; Python is itself one of the slowest languages (especially since when it comes to NumPy we can't necessarily count on PyPy, though that's coming along) but it doesn't matter because you just use the slow language to script up the computation you want to do, which then goes and runs in highly-optimized assembler implementations. You can look at Erlang being very similar when being used in its native domain for networking, using a slower language to decide how to route bytes around.

So it's quite possible for competent Erlang to beat out competent Java for such a task. Java optimized to within an inch of its life can certainly beat Erlang, but it's going to be a much uglier code base to get there.

Re: What's all this fuss about Erlang? (2007)

#135

Post by kevinjcliao » Wed, Jan 25, 2017, 3:16 AM UTC

mnd wrote: post #82

kevinjcliao wrote: post #78

Earlier quoted context omitted.

Thanks for your clarification. I think 'just syntax' is a bit dismissive of the importance that well-designed syntax has on being able to reason clearly in a certain way. Elixir's "just syntax" has made it so easy for me to understand FP concepts like pattern matching and higher order functions. I've struggled with these concepts before while trying to learn Haskell, Erlang and many other FP languages. Does that make…

My point was not that everything which is written in Elixir can be written in Erlang but mostly that using a reference to a system that sustains a large amount of traffic which is implemented in Elixir and runs on top of the Erlang virtual machine as an argument for how incredible Elixir is, is naive at best, as Elixir is just a layer on top of many Erlang libraries and also the Erlang virtual machine. Yes, syntax ca…

Thanks for your reply! All points you make are incredibly valid, but I still have some pushback:

But where would you stop?

If Elixir makes it easier to write fast, concurrent for many people than Erlang, that totally can be discussed. The way you separate developer satisfaction/well-designed syntax from the VM it runs on top of is a separation I dispute.

Obviously these comparisons will never be 100% valid, but I think they make my point: Will you say that Scala is no different (or better) from Java? Will you say that Dart or Elm are no different (or better) from JavaScript? Simply because their underlying architecture is the same?

I think there is some hostility I am sensing from Erlang programmers where there is none given in return. I don't hate Erlang. I'm simply saying a language that can leverage the performance of the Erlang VM shouldn't be dismissed. Again, I never ever said I thought Elixir was better than Erlang. I was just responding to the parent commenter's assertion that all alchemists are pathetic.

Also, I think the implication that may have entered my writing was that because I personally found Elixir easier to learn (and it would be difficult to argue that I am alone in this), it is somehow a better language than Haskell, Erlang, and many other FP languages out there. If that was the implication you drew, I apologise for my a mistake in my writing. Since I learned Elixir, I'm now taking a course in Haskell at my college to better understand these programming languages. Just because I called Elixir incredible, doesn't mean I believe it's the end all be all language!

Again, thanks for your comment. I learned a lot from it.

Re: What's all this fuss about Erlang? (2007)

#136

Post by Const-me » Wed, Jan 25, 2017, 3:26 AM UTC

yellowapple wrote: post #64

Const-me wrote: post #52

Earlier quoted context omitted.

Immutability is not a silver bullet. One reason is RAM consumption: while Facebook has bought tremendous amount or RAM for caching content so those extra copies of objects don’t hurt, desktop or embedded apps have different resource constraints. Another reason is performance. Memory allocation/deallocation is not free. RAM bandwidth for copying those objects isn’t free. Also mutable objects generally more cache-frien…

"One reason is RAM consumption" You can have immutability without data duplication; in an immutable-only environment, every process/thread/whatever that uses a specific object can safely reuse a pointer to that object and always know that the object represented by that pointer cannot change under their noses. It's only when you need to "modify" that object (read: create a new copy) where you start to see RAM consumpt…

It’s all good in theory, not in practice.

> only when you need to "modify" that object

Well, unless you’re modifying your data, almost all data structures are fine for multithreaded access.

> Linked lists are an example of where this works remarkably well

Linked lists are an example of what you don’t want to use if you care about performance even a tiny bit.

On modern hardware, random memory access is slow. A ballpark estimate is 100-200 CPU cycles just to read a single value (16 bytes for dual-channel DDR) from RAM. With a linked list you pay that cost with each iteration to the next list element. Very expensive.

Re: What's all this fuss about Erlang? (2007)

#137

Post by macintux » Wed, Jan 25, 2017, 3:29 AM UTC

mnd wrote: post #44

slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it lo…

I strongly agree. I've found it tremendously convenient to have an "alien" syntax (Erlang) to help me think Erlang-y.

(Now, of course, when I see more "traditional" C/Ruby/Perl/Python/Rust syntax, I can't help but roll my eyes, but that's a slightly different subject.)

Re: What's all this fuss about Erlang? (2007)

#138

Post by inopinatus » Wed, Jan 25, 2017, 4:12 AM UTC

chrisseaton wrote: post #116

timClicks wrote: post #42

Earlier quoted context omitted.

That's true, but when I read that sentence I place the emphasis on should . I see it as aspirational. A better way to phrase this would perhaps would be to say that perfectly preemptive scheduler should be able to keep all cores hot. Blocking of one Erlang process should not halt the program's progress. As Erlang requires message passing overhead by design, it will never see perfectly linear scaling behaviour. Still,…

> That's true, but when I read that sentence I place the emphasis on should. I see it as aspirational. Despite all the arguing I'm taking part in, this is probably the true and reasonable explanation. I read 'should' as 'if it doesn't there's a problem'.

Yes, indeed, don't forget his very next line is "Is this true? Almost. It’s early still, but we’re optimistic (Wildly optimistic; I haven’t seen this kind of optimism for the last 20 years!)."

Re: What's all this fuss about Erlang? (2007)

#139

Post by digitalzombie » Wed, Jan 25, 2017, 4:27 AM UTC

mnd wrote: post #44

slashdotdash wrote: post #4

Dave Thomas has described Elixir as follows: "Elixir took the Erlang virtual machine, BEAM, and put a sensible face on it. It gives you all the power of Erlang plus a powerful macro system."[1] [1] https://startlearningelixir.com/elixir-for-rubyists

Erlang is a great programming language after one takes the time to understand the principles underlying it and its design. Everything fits very nicely into place. There are definitely things that could be done better, but then that’s the case with most programming languages and technologies after they have accumulated some dust. Elixir on the other hand, in my personal opinion, is a false prophet simply because it lo…

Elixir is prettier than Erlang but it really mess up on certain things.

Erlang have pattern matching via function with same name and you can tell if it's a group of pattern matching with semicolon and period. But with Elixir you can't tell it's just def and end.

Erlang's:

-module(recursive).

-export([fac/1]).

fac(N) when N == 0 -> 1;

fac(N) when N > 0 -> N * fac(N-1).

You can tell fac(N) both are in a group of pattern matching cause ';' and '.'. The '.' denote the last pattern matching function.

Elixir:

defmodule Factorial do

    def of(0), do: 1

    def of(n), do: n * of(n-1)

end

You can't tell because there is no ';' and '.'. This is a trivial case but when your Elixir's module have a tons of function in it, this issue become relevant.

Re: What's all this fuss about Erlang? (2007)

#140

Post by ww520 » Wed, Jan 25, 2017, 4:29 AM UTC

toast0 wrote: post #133

ww520 wrote: post #89

Earlier quoted context omitted.

In the case of Erlang, how would immutable data help? The code all run in single thread execution path in each process; there's no need for lock anyway. Each process can't access data of another process.

Immutable data (along with per process heaps) makes the garbage collection very simple.

As a developer writing code, I don't particularly care whether GC is simple or complicate, as long as it works correctly. That's the compiler writer's job.