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

111–120 of 210 posts

Re: Why Erlang Matters

#111

Post by statictype »

bitmadness wrote: post #53

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?

Because at some point the volume of 'work' you process will be more than what a single CPU can handle.

I think of it like big corps vs startups. Startups may have more efficient engineers and development cycles and produce higher quality work because of the selectivity of their employees, but the sheer amount of work a big Corp can do is significantly more.

(Just an example, not saying big corps don't have talent - far from it)

When designing your system you need to decide which model it needs to follow. There are places for both.

Re: Why Erlang Matters

#112

Post by jlarky2012 »

waf wrote: post #108

I'm really interested in BEAM languages, but the fault-tolerance / supervisor aspect of it doesn't speak to me. Aren't all modern application fault-tolerant, as long as you don't design something really poorly? For example, I've never had a single HTTP request bring down an entire website -- that's already isolated. Same with message-queue listening processes. For general batch applications, I've always had them shor…

How fault-tolerant is your web server when datacenter has power outage? You can't build fault-tolerant system with one computing node by definition.

That means that if you planning to provide proper availability you want to work with system of applications, not just one. That means you should look into creating networking architecture that can handle all of that.

Most of the time it means that people just use tools that solve that for you, like load balancers. But it doesn't mean that somehow all modern applications are immune to failures.

Re: Why Erlang Matters

#113

Post by toast0 »

arh68 wrote: post #77
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.

Any idea if a network-level FFI has been started? I'm thinking along the lines of the Haskell erlang-ffi [0]. Speaks the Erlang network protocol and impersonates an Erlang node on the network. Fully capable of bi-directional communication with Erlang. NIFs still limit you to [0] https://hackage.haskell.org/package/erlang

Have you seen c nodes[1]? That may be what you're looking for?

[1] http://erlang.org/doc/tutorial/cnode.html

Re: Why Erlang Matters

#114

Post by wocram »

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…

Care to elaborate on 'streaming market data aggregation'?

Re: Why Erlang Matters

#115

Post by daveguy »

incepted wrote: post #105
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…

> And actor supervision is the best way to write reliable systems. Need some citation there, because we've been writing extremely reliable systems (multiple nines) for decades in various languages (mostly C, C++ and Java). All these languages (including Erlang) come with pros and cons to write such systems, but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

> but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

Speaking of citations...

Re: Why Erlang Matters

#116

Post by jallmann »

adrusi wrote: post #92
jallmann wrote: post #80

Earlier quoted context omitted.

Yes. The intuition is a good one of parallelism being a deliberate way of designing a system to run its parts simultaneously (physically), with concurrency being a property of a system that may or may not have its parts running simultaneously (conceptually, 'overlapping', whether physically or logically). There are many, many ways to think about this difference, and it's fun (and beneficial!) to do so every once in a…

Well obviously threads aren't always running at the same time since each cpu can do only one thing at a time (or a finite number, if we're counting hardware threads) and you can have more threads than cpus. It's the fact that they might run at the same time. Also from the perspective of the programmer, there's no difference between two threads running at the same time or by time sharing, since preemptive multitasking…

I think we're talking about different things? You seem to be referring to parallelism in the literal, general sense of the word, while I'm referring to computational parallelism. Basically, if Amdahl's Law doesn't apply, then you're looking at concurrency. So this statement

> from the perspective of the programmer, there's no difference between two threads running at the same time or by time sharing

is incorrect when you're talking about computational parallelism (as OP was), because you're not going to realize any speedups with time sharing. In that case, you're using threads as a concurrency mechanism -- not for parallelism.

Re: Why Erlang Matters

#117

Post by jeffdavis »

rdtsc wrote: post #96
jandrese wrote: post #14

Earlier quoted context omitted.

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…

> By decentralizing your state, you've increased your inter-process synchronization requirements. But you've also increased your reliabily as well. Who cares if the tight single threaded application with a shared heap cand handle 100K connections, if as soon as one of those connection leads to a segfault, all the other 99999 crash as well.

A single Erlang server can handle 2M connections[1].

[1] https://blog.whatsapp.com/196/1-million-is-so-2011?

Re: Why Erlang Matters

#118

Post by rdtsc »

incepted wrote: post #105
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…

> And actor supervision is the best way to write reliable systems. Need some citation there, because we've been writing extremely reliable systems (multiple nines) for decades in various languages (mostly C, C++ and Java). All these languages (including Erlang) come with pros and cons to write such systems, but so far, Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

> Erlang has failed to deliver on most of the promises that its advocates repeatedly make.

Need some citation there,

Re: Why Erlang Matters

#119

Post by fantasticsid »

rdtsc wrote: post #103
devbug wrote: post #71

Earlier quoted context omitted.

This unfortunately breaks down with (bad acting) NIFs. Thankfully you can mark 'em as the dirty evil little things that they are (with negligible overhead): ERL_NIF_DIRTY_JOB_CPU_BOUND. [1] I implore anyone interested in Erlang or its surrounding languages, to read its source code. [2] More specifically, the BEAM. I'll warn you that it's very 80's hackeresque, but in a good way. Incredibly pragmatic. The way they ach…

> I'll warn you that it's very 80's hackeresque, but in a good way. Incredibly pragmatic. I consider the BEAM VM as one of the marvels of software engineering. You know it is good, when you explain to other programmers that you can have something like an isolated memory process just like an OS process, with preemption and only a few Ks of memory, with a low latency GC, with distribution across machines built in -- an…

I'm interested. How does the preemptive scheduling work with blocking system calls? So if an Erlang process tries to read from standard input using the read syscall (suppose we haven't set non blocking mode on the fd), why does it not block the scheduler that it runs on? Or does Erlang implements its own set of syscall wrappers that uses epoll under the hood?

Re: Why Erlang Matters

#120

Post by crymer11 »

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

Still pretty new to Elixir, so I welcome any suggestions, but from my understanding (and based on Elixir's guides [1]), I think that the more idiomatic way to approach this is to avoid writing such a loop_through/1 function and instead just use:

  Enum.each(, &IO.inspect(&1))
or likely

   |> Enum.each(&IO.inspect(&1))
Both return the :ok at the end of the loop, so Enum.each/2 looks to be functionally equivalent.

1 - http://elixir-lang.org/getting-started/recursion.html

Post reply on HN