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

Why Erlang Matters

sameroom.io

Post reply on HN
Print view View original

31–40 of 210 posts

Re: Why Erlang Matters

#31

Post by tombert »

andrewfromx wrote: post #28
dboreham wrote: post #5

Doesn't the existence of Golang remove most of the reasons to use Erlang these days?

specially with this stuff http://www.jerf.org/iri/post/2930 https://github.com/thejerf/suture golang for the win!

This is certainly something useful for Go, but it's only one aspect of Erlang.

You still don't have to guarantee of thread-safety, you still don't have the immutability, you still don't have tail-call optimization, and perhaps most importantly, you don't have a REPL for hot-code updates.

Re: Why Erlang Matters

#32

Post by pcwalton »

vvanders wrote: post #23
pcwalton wrote: post #21

Earlier quoted context omitted.

Agreed. It'd be really interesting to see such a language. One language that I think is woefully underappreciated for how ubiquitous it is is GLSL. With OpenGL 4 Compute Shader you get surprisingly close to general-purpose use for the type of tasks that benefit from massive parallelism. And GLSL is really quite a nice language; driver bugs are the main things holding it back.

Eeeeeeh. I don't know. Maybe for highly SIMD stuff but it seems like pull in a bunch of baggage around GPUs, etc. On the other hand it would force you to do your data partitioning right up-front(much like the SPUs on the PS3).

Sure, it's not very good for task parallelism (though some of the extensions that AMD is introducing for APUs are very interesting!) But if you've got an embarrassingly data-parallel problem, you can't beat its performance.

Re: Why Erlang Matters

#34

Post by vvanders »

pcwalton wrote: post #32
vvanders wrote: post #23

Earlier quoted context omitted.

Eeeeeeh. I don't know. Maybe for highly SIMD stuff but it seems like pull in a bunch of baggage around GPUs, etc. On the other hand it would force you to do your data partitioning right up-front(much like the SPUs on the PS3).

Sure, it's not very good for task parallelism (though some of the extensions that AMD is introducing for APUs are very interesting!) But if you've got an embarrassingly data-parallel problem, you can't beat its performance.

That performance is largely dependent on drivers + HW though, right?

Then again I'm used to mobile GPUs where any conditional statement used to cause the shader to be evaluated 2^n for each and the gathered at the end(aka forget about any branching).

For my 2c I'm a fan of Elixir + Rust, Rust has a nice C ABI that should make it easy to embed.

Re: Why Erlang Matters

#35

Post by ssmoot »

This seems like it could've been called "Why Actor Systems Matter".

If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time.

I'm totally sold on Actor Systems and think it's something more programmers should expose themselves to. I'm just not sure there's much of an argument for Erlang vs the JVM unless you're completely sold on the notion of process isolation for some reason.

Re: Why Erlang Matters

#36

Post by debacle »

aaron-lebo wrote: post #24
rb808 wrote: post #8

I'm really tempted to use Erlang/Elixir for a project at work but unsure of its traction. Is it leading edge or trailing edge? I don't even know, but don't want to saddle the firm with a white elephant - even one that is impeccably fault-tolerant. Is Erlang too esoteric?

I think it depends on your hiring process. Do you hire people who know how to code in language X and are really good at coding in language X but nothing else? Or, do you hire people who are go-getters, want to use the best tool for the job, and want to learn? Because if the latter, Erlang/Elixir might be esoteric, but Elixir specifically is a simpler language than currently more popular languages like Python or Ruby.…

I would confidently state the bigger problem would be salary. If you hire cheap programmers you probably can't afford to do Erlang development.

Re: Why Erlang Matters

#37

Post by wcummings »

jerf wrote: post #6
jandrese wrote: post #2

I'm a very green Erlang noob, but given what I have seen from it I find articles like this kind of strange. Sure concurrent programming is difficult and we need to think hard about how to make programs run quickly in a multiprocessor environment, but the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing. It seems like a language that can scale much better, but has such…

Erlang may be useful for coordinating computation tasks, but, yes, even with HIPE it is not a good numerical language on its own. It would be interest to re-engineer a language today that tries to fit into Erlang's niche but has a stronger performance focus. Rust, Cloud Haskell, and Go all sort of cluster in the area I'm thinking about, but none are quite what I'm thinking of. Cloud Haskell is probably closest but wr…

You could write NIFs in Rust (well not sure if you can now, but I don't see any reason it couldn't be supported) for the high perf bits and use Erlang to coordinate, I figure. At least Rust code is less likely to explode and bring down the whole VM than C.

Re: Why Erlang Matters

#38

Post by wcummings »

ssmoot wrote: post #35

This seems like it could've been called "Why Actor Systems Matter". If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time. I'm totally sold on Actor Syst…

Erlang has pretty decent JVM integration. I assume this is why there's a nice Erlang IntelliJ plugin.

http://erlang.org/doc/apps/jinterface/jinterface_users_guide...

Re: Why Erlang Matters

#39

Post by strictfp »

ssmoot wrote: post #35

This seems like it could've been called "Why Actor Systems Matter". If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time. I'm totally sold on Actor Syst…

I would love process isolation on the JVM (several smaller heaps), and I'm not even into the actor model.

Plus I can imagine accidental mutability really being a problem. In my Akka course much effort was spent on explaining how to avoid side effect of it (no pun intended).

Re: Why Erlang Matters

#40

Post by vvanders »

ssmoot wrote: post #35

This seems like it could've been called "Why Actor Systems Matter". If you're on the JVM, I'm not sure what Erlang buys you in practice. It's slower and more obscure. It has a much smaller ecosystem. While process-safety is frequently touted, in the real world this is a non-issue among non-issues. It's just not an actual thing. It's not like the JVM goes around Segfaulting all the time. I'm totally sold on Actor Syst…

My Stop-The-World GCs would like to have a word with you.
Post reply on HN