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

61–70 of 210 posts

Re: Why Erlang Matters

#61

Post by Jtsummers »

pmontra wrote: post #51
catnaroek wrote: post #43

Earlier quoted context omitted.

Erlang processes are objects in their own right, not "dual" to them. The dual of object types (records of methods) are sum types: Object types are defined by how you can eliminate them (calling a method on an object), whereas sum types are defined by how you can introduce them (applying a constructor to suitable arguments).

He probably means that an Erlang process is equivalent to an object and message passing among processes is equivalent to method calls. In my experience with Elixir, objects, method calls and mutable data are easier to write than processes, messages and immutable data. It's not the mutable and immutable part, it's more about the boiler plate of spawning processes, receiving messages and matching them to dispatch them…

Yes. In the same sense that closures and objects are equivalent.

http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent

Re: Why Erlang Matters

#62

Post by im_down_w_otp »

atemerev wrote: post #47

AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge. And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggrega…

+1.

I think a preemptive scheduling model is really the only way to implement that model effectively. Any other scheduling method eventually causes the consistency of the programming model to break down as it's now pushing the cognitive burden about what to run, where, and when onto me as the developer again.

Re: Why Erlang Matters

#63

Post by adrusi »

jallmann wrote: post #58
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…

> the fundamental architecture of Erlang seems to be in conflict with big data and high speed computing Because they are different problems. Concurrency, meet parallelism. Concurrency: many smaller tasks that can be multiplexed over one core. The core doesn't need to be particularly fast; it just needs to be able to handle multiple tasks in-flight at once. Web serving, etc. Parallelism: one big, honking task that can…

I know you weren't aiming for maximum accuracy in your definitions, but I think this is worth bringing up.

Parallelism and Concurrency are not mutually exclusive terms. All parallelism is concurrent.

Concurrency is whenever more than one thing is happening at the same time conceptually. Everything from iterators to threads.

Parallelism is whenever more than one thing is happening at the same time physically. From a user-space perspective, this means threads or a coprocessor (like a GPU).

Re: Why Erlang Matters

#64

Post by bpicolo »

aaron-lebo wrote: post #45
namelezz wrote: post #42

Earlier quoted context omitted.

Sometime I wonder why Elixir tries too hard to have Ruby syntax. Erlang: loop_through([H|T]) -> io:format('~p~n', [H]), loop_through(T); loop_through([]) -> ok. It seems convenient to use ';' to separate multiple definitions of a function compared to using 'end' in Elixir(function definition continues in the next block) Elixir: def loop_through([h|t]) do IO.inspect h loop_through t end def loop_through([]) do :ok end

I believe, like Steve Yegge has said elsewhere, that programmers are lame, (and now paraphrasing) because they refuse to touch things that look odd. Erlang's syntax may be more efficient, but a lot of people won't touch it becuase the syntax is unfamiliar. Elixir has a huge advantage in this. It might not matter to you specifically, but in the realm of adoption that is huge. And honestly I really enjoy the syntax...

I mostly enjoy the syntax. Kind of hate that they made parentheses for function calls optional, especially since no-parentheses has ambiguous cases that behave weirdly (like with chaining syntax). Should be enforced.

Also, all the different import-related keywords are pretty confusing. Maybe that's improved though

Re: Why Erlang Matters

#65

Post by pramodliv1 »

pmontra wrote: post #51
catnaroek wrote: post #43

Earlier quoted context omitted.

Erlang processes are objects in their own right, not "dual" to them. The dual of object types (records of methods) are sum types: Object types are defined by how you can eliminate them (calling a method on an object), whereas sum types are defined by how you can introduce them (applying a constructor to suitable arguments).

He probably means that an Erlang process is equivalent to an object and message passing among processes is equivalent to method calls. In my experience with Elixir, objects, method calls and mutable data are easier to write than processes, messages and immutable data. It's not the mutable and immutable part, it's more about the boiler plate of spawning processes, receiving messages and matching them to dispatch them…

>> I wonder if it could be possible to have an OO language with an automatic Erlang process per object, automatic immutable data (just don't let reassign values to variables, like Erlang), and a way to define supervisor trees.

Is it possible to implement it using the metaprogramming features in Elixir?

Re: Why Erlang Matters

#66

Post by amsha »

Any programming language can do IPC, but Erlang/Elixir is the only language I've seen that makes it really easy. Erlang IPC is transparent whether you're sending messages between to local processes or remote processes. Most languages have trouble with local IPC (usually because of race conditions in data). Every other language I know of, including Go, needs custom code to handle remote IPC.

Re: Why Erlang Matters

#67

Post by angersock »

atemerev wrote: post #47

AFAIK, Erlang is still (as of 2016) the only distributed actor model implementation with preemptive scheduler. All other major implementations (including Akka) have cooperative scheduling, i.e. forbidding blocking code in actors. Erlang allows it. This is huge. And actor supervision is the best way to write reliable systems. I have wrote some code in Akka without much effort and testing (streaming market data aggrega…

It is specifically because of the preemptive scheduling that I find it worthwhile to write code that would otherwise be better suited to a different language in Elixir.

Numerical and statistical stuff, for example, is never going to be performant--but that's okay, because I'd much rather have a whole bunch of slow actors making incremental progress safely than a couple of blazing fireballs that could take down my system using NIFs or whatever.

Re: Why Erlang Matters

#68

Post by davidw »

findjashua wrote: post #57
dewiz wrote: post #56

Earlier quoted context omitted.

So is preemptive or cooperative better in your opinion ? I couldn't figure it out from your comment.

preemptive. Cooperative scheduling runs the risk that a long-running actor might starve the other actors

Note that "better" means better for some kinds of things. Preemptive scheduling has a cost, just like running a program on top of, say, Linux costs more than if you coded it specifically to run on the chip itself with no OS.

Re: Why Erlang Matters

#69

Post by nvarsj »

debacle wrote: post #36
aaron-lebo wrote: post #24

Earlier quoted context omitted.

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.

Seems like a strange view to have. The best paying work is generally in boring, enterprise approved languages. It's probably a competitive advantage for a small company to pick a niche language - I wager they would hire better quality engineers for less money.

Re: Why Erlang Matters

#70

Post by ssmoot »

strictfp wrote: post #39
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).

I guess the accidental mutability is a good point. Working in Scala, I've never encountered that.

You do learn not to close over local scopes in futures pretty quickly though.

Post reply on HN