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

51–60 of 210 posts

Re: Why Erlang Matters

#51

Post by pmontra »

catnaroek wrote: post #43
Jtsummers wrote: post #7

Earlier quoted context omitted.

> even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not d…

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 to the appropriate functions. Ruby's and Python's class and method definitions are much more compact and less error prone. Unfortunately they are not as good at parallelism. 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.

Re: Why Erlang Matters

#52

Post by vvanders »

kibwen wrote: post #41
wcummings wrote: post #37

Earlier quoted context omitted.

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.

There seem to be at least a few people looking to build NIFs in Rust, e.g. https://github.com/hansihe/Rustler (found at https://news.ycombinator.com/item?id=11220615 ).

That looks really nice. Codegen + panic catchers makes is pretty compelling.

Re: Why Erlang Matters

#53

Post by bitmadness »

Erlang is glacially slow. Even on a 20 core machine, a multithreaded Erlang implementation will usually be trounced by a good singlethreaded C++/Go/Java implementation. All this stuff about multicore scaling is baloney - who cares it is scales and is still slow?

Re: Why Erlang Matters

#54

Post by catnaroek »

jandrese wrote: post #14
Jtsummers wrote: post #7

Earlier quoted context omitted.

> even strongly typed. A nit: Erlang is strongly typed. You cannot (ok, excluding numbers) almost transparently convert a string into a number into a tuple like you could in C, to which everything is merely memory so casting allows trivial but potentially erroneous conversions. Erlang is dynamically typed, not statically typed. Dialyzer + type annotations (and some inferred) allows for static analysis, but it's not d…

You've hit on the tradeoff though. By decentralizing your state, you've increased your inter-process synchronization requirements. In the worst case everything ends up being tightly bound and your application runs like a single threaded application because everything is always blocked waiting for the state update from a remote thread. Huge parallelism is easy if your data and processes are largely independent, but th…

> In the worst case everything ends up being tightly bound (...)

Your tradeoff is between “tightly bound by shared data structures” vs. “tightly bound by process synchronization”. I don't see how either is better than the other.

> the real world is rarely so kind

In the real world, from what I've seen, while everything is interconnected to everything else, not all the connections are equally strong or important. If you want to compute exact results, without possibility of failure, no matter what the computational cost, then sure, you need to take all the connections into account. If you can trade some accuracy for performance gains in the average case, you'll probably want to find ways to prevent minor failures from bringing down the entire system.

Re: Why Erlang Matters

#55

Post by vvanders »

namelezz wrote: post #42
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.…

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

Does do/end make it much easier to build macros with Elixir?

I don't find either syntax to be off-putting but that's just me.

Re: Why Erlang Matters

#56

Post by dewiz »

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…

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

Re: Why Erlang Matters

#57

Post by findjashua »

dewiz wrote: post #56
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…

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

Re: Why Erlang Matters

#58

Post by jallmann »

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 be split over multiple cores (or nodes), and each core needs all the horsepower you can eke out, so it can finish its part of the task quicker. Big Data, etc.

Erlang is not particularly fast (bad for parallelism), but it excels at concurrency.

> I know people do some big data stuff with Erlang

Not sure who is doing big data with Erlang, or why anyone would want to -- unless they have some very fundamental misconceptions about the problem at hand and the tools available.

> compromise some of the ideals espoused in this article to make it work

The article was really nonsense. Most of the terms it throws around have nothing to do with Erlang specifically, and proclamations like Erlang being used for a hypothetical "data center on a chip" are... what? The author's gist basically boils down to this: Use supervision trees with unikernels. I have had the same fantasy, for what it's worth.

Re: Why Erlang Matters

#59

Post by adrusi »

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…

I think you might be underestimating Erlang's performance. Running on the same single machine, Erlang's perfomance is comparable to python on benchmarks [1] [2]. Its performance obstacles aren't really that different from scheme's, and Racket does a little better than Erlang on benchmarks, so there's definitely room for improvement [3].

But Erlang isn't really for doing computation, it's for communication. If you have an existing erlang system that has a lot of data and you want to perform some computations on all of it, you'd probably use erlang to get the data onto the appropriate servers and then spawn another process, that can compute efficiently, with numpy or just C or similar.

Distributed systems aren't just a way of scaling performance beyond the number of CPUs you can have using the same memory. It's about reliability. Erlang's design enables you to create network services that have decades of uptime. It achieves this through its concurrency model, through its error handling approach, by allowing hotswapping code (an operation that's relatively easy to reason about without mutable state), and probably more ways that I as an outsider am not aware of.

[1] http://benchmarksgame.alioth.debian.org/u64q/measurements.ph...

[2] http://benchmarksgame.alioth.debian.org/u64q/measurements.ph...

[3] http://benchmarksgame.alioth.debian.org/u64q/measurements.ph...

Re: Why Erlang Matters

#60

Post by andy_ppp »

jlouis wrote: post #29
dboreham wrote: post #5

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

I was wondering this when Go came out. But time has shown they solve problems very differently, so they are not really direct competitors. Erlangs primary difference over Go is that it can gracefully handle the case where a programmer has made an error in the program by accident. A typical Go program cannot gracefully recover from an error which were unforseen and never considered by the programmer. The Erlang equiva…

https://github.com/thejerf/suture

Supervisors for golang. It looks excellent. I personally have fallen for Elixir and think the syntax, immutability, community and class functionality like Phoenix.Presence make me bet that it'll be bigger than Python for jobs in 5 years.

Post reply on HN