Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

pragprog.com

Post reply on HN
Print view View original

141–150 of 193 posts

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

#141

Post by amorphid »

brightball wrote: post #130
BeetleB wrote: post #109

Earlier quoted context omitted.

Which would make the original commenter's point valid: >Your Erlang program should just run N times faster on an N core processor No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.

Not really. Think about every object you'd have in Java that's being passed around your system. Now imagine each of those objects are their own processes and you're passing around references to them. Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation…

On top of that, Erlang has a scheduler which reduces the need to rely on the operating system's concurrency model.

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

#142

Post by [deleted] »

chrisseaton wrote: post #95
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…

> almost every program is embarrassingly parallel in Erlang I can't agree with that, and it's key to my point. There are some problems which we just don't know how to make embarrassingly parallel. Take something classic like mesh triangulation or mesh refinement. Nobody knows how to make those embarrassingly parallel. If you write it in Erlang, it's still not going to be embarrassingly parallel. And it won't scale li…

[deleted]

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

#143

Post by amorphid »

derefr wrote: post #53
lobster_johnson wrote: post #41

Earlier quoted context omitted.

I think that would help, but in my opinion, Erlang's syntax and overall projected surface has always been its biggest hurdle to wide adoption. You can have the most amazing, powerful language ever, but it still won't receive popular adoption if you're too strange and you can only attract a certain type of highly-skilled senior devs. I'm not a fan of Elixir's quasi-Ruby syntax — I think something closer to Go or Nim w…

Oh, sure, there are plenty of things getting in the way of developers being excited about using Erlang and thus deciding, in a bottom-up sense, to build more stuff in Erlang. But I think Erlang's use-case isn't really the type of software developers get excited about developing, either way. The type of software Erlang is "best at" (and where it would reduce codebase size the most) is exactly the type of big Enterpris…

Once I wrapped my head around it, I found Elixir to be much simpler than other programming languages. I'd rather use Elixir to build things if there aren't any blockers to doing so.

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

#144

Post by toast0 »

ww520 wrote: post #140
toast0 wrote: post #133

Earlier quoted context omitted.

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.

A fundamental strength of Erlang is that as many things as possible are simple, which makes it easy to know that it works correctly and under what conditions it doesn't work so well [1]. The compiler writer isn't necessarily the GC writer either; although, it's probably the same couple of people in Erlang.

[1] If you touch a lot of ref counted binaries, without generating enough garbage on the process heap to trigger GC. GC time scales with process heap, if you get a large enough backlog in your mailbox, GC may reduce the throughput to the point where you can't recover, although doing selective receives if you don't trigger the optimization for new references[2] is much more painful than GC scaling.

[2] http://erlang.org/pipermail/erlang-questions/2010-June/05175...

EDIT: from slides about r19 GC [3], it seems that both of the GC issues I mentioned have had targeted changes: for refcounted binary issues, there's now a 'virtual binary heap' to help trigger GC; for GC with a big mailbox, there are different allocation strategies available which may help.

[3] https://www.erlang-solutions.com/blog/erlang-19-0-garbage-co...

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

#145

Post by ryeguy »

digitalzombie wrote: post #139
mnd wrote: post #44

Earlier quoted context omitted.

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 patter…

How does that matter? Anyone who uses this defines them in groups one after another. You aren't looking at the punctuation at the end of the line, you're looking at the following line to see if it's the same function name.

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

#147

Post by slrz »

MaulingMonkey wrote: post #120
ww520 wrote: post #101

Earlier quoted context omitted.

Parallel programs really are not that hard to write. The hard part is figuring out how to make a problem into embarrassing parallel. Once that's figured out, the coding is simple. In this case, the language choice won't help.

> Parallel programs really are not that hard to write. Yes... but! > The hard part is figuring out how to make a problem into embarrassing parallel The other hard part is the debugging - especially when you fall short in the "embarrassingly" department. It's not until C11 that the language itself had any notion of multithreading without reaching out to a separate standard - POSIX - and various nonstandard compiler ex…

Static analysis is, of course, very restricted in what it can give you answers to, although I'd still love to have more advanced tools widely available.

What I really consider a game-changer for concurrent programming are the dynamic checkers integrated into recent versions of GCC and Clang (and the Go compilers, too). Those make it super easy to flag data races and don't have any false positives. Caveats apply, naturally, as they can only flag those races that actually happen during a particular execution of your code.

While Valgrind and similar tools could do that for years, the difference with TSan is speed. It's fast enough that you can use it all the time during development. Same for AddressSanitizer and the undefined behaviour checkers.

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

#148

Post by BeetleB »

brightball wrote: post #130
BeetleB wrote: post #109

Earlier quoted context omitted.

Which would make the original commenter's point valid: >Your Erlang program should just run N times faster on an N core processor No, it won't. It will only be true for tasks that /could/ be (completely/embarrasingly) parallel (as you say). Which is kind of circular.

Not really. Think about every object you'd have in Java that's being passed around your system. Now imagine each of those objects are their own processes and you're passing around references to them. Just on that one case, you've taken huge chunks of a linear execution pattern and parallelized it. Now make that your norm and amplify it to everything. Now realize that the message passing allows this mode of operation…

None of what you said will prevent the need for waiting for the majority of numerical algorithms.

No one's disputing Erlang's prowess at parallelism. What the critic in this thread was saying was that you can only get Nx speedup on an N core processor for a limited set of algorithms. Most parallel algorithms will not fall in this category. Amdahl's law is a general truth - it doesn't matter what your architecture/language is. There is nothing special about Erlang that will make any parallel algorithm scale linearly with nodes.

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

#149

Post by kqr »

XorNot wrote: post #72
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…

I've not found immutable data to be the big win people tout it as. In most of what I do acting on stale data is just as bad, which means I wind up needing a lock anyway. Doing a < b and taking an action based on that result is as harmful with stale data.

I'd like to tell you that stale data will always be a thing in any serious application because light only travels so fast. Therefore, you'll need to have sensible logic in the face of stale data either way, so it's not so bad as you think.

...and while that's true, I'd still like to hear the opinion of someone more knowledgeable because it's an issue that's been bugging me too.

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

#150

Post by slrz »

digitalzombie wrote: post #139
mnd wrote: post #44

Earlier quoted context omitted.

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 patter…

I think you make the Erlang definition look unnecessarily awful.

fac(0) -> 1;

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

Or is there a particular advantage to write it using guards?

Post reply on HN