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

151–160 of 210 posts

Re: Why Erlang Matters

#151

Post by rdtsc »

simoncion wrote: post #149
rdtsc wrote: post #141

Earlier quoted context omitted.

I am excited for a continued improvement and enhancement to the language. Erlang 18 brought maps, people complained about that for years. Erlang 18 also brought (via a feature flag) dirty schedulers so can have long running C function embedded in without messing up process scheduling also an often requested features. Probably the best thought-out handling of time in any language I've seen so far ( synchronization, wa…

mnesia_leveldb is scheduled for OTP 19? That's great news! I can't tell you how many times I've cursed at the overfilled-hours-ago-but-mnesia-didnt-care DETS table shard. Getting a on-disk backend that can store more than 2GB at a time will be great! It'll be even better if the writer code actually notices failures to write to the backing store and aborts transactions when they happen! [0] :) [0] Seriously, who thoug…

I think this is the PR so far:

https://github.com/erlang/otp/pull/858

Re: Why Erlang Matters

#152

Post by bojo »

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…

> Not sure who is doing big data with Erlang, or why anyone would want to

Riak?

Re: Why Erlang Matters

#153

Post by ngrilly »

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…

Erlang's fault-tolerance becomes really useful when you wrote a server that manage hundreds of thousands of simultaneous connections (a chat server being the typical example). With Erlang, each connection is managed by its own lightweight process (no callbacks, no promises, etc.). If a lightweight process fails, it doesn't bring down the other processes. Moreover, BEAM can signal other processes about the failed process (Erlang' supervision trees are based on this mechanism).

In a traditional architecture, you would use one thread for each connection (let's ignore the issue of the memory used by each thread), but when one thread fails, it would bring down all connections instead of just the failing one.

Re: Why Erlang Matters

#154

Post by ngrilly »

spriggan3 wrote: post #135
dboreham wrote: post #5

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

Go isn't fault tolerant, doesn't support hot swapping and a lot of stuff Erlang do support. The only thing Go and Erlang share is channels.

The main thing Go and Erlang share is their approach to concurrency: write synchronous code using lightweight processes, instead of writing asynchronous code with callbacks/promises/futures/etc. The main difference is the the fault tolerance Erlang brings (thanks to immutability and absence of memory sharing).

Re: Why Erlang Matters

#155

Post by im_down_w_otp »

incepted wrote: post #128
DasIch wrote: post #122

Earlier quoted context omitted.

Erlang was developed for developing telecommunication systems and is still used heavily in that area today. When was the last time you heard of someone unable to make a phone call because a phone network went down?

That would be a powerful argument if you could prove the code path enabling this uses Erlang. According to Wikipedia, shortly after Armstrong was let go of Ericsson, the company quickly ripped out Erlang from all its products and replaced it with C and C++.

You literally have no idea what you're talking about, said the guy who knows several people on the current OTP team at Ericsson.

Re: Why Erlang Matters

#156

Post by mbrock »

mistercow wrote: post #121
jeremyjh wrote: post #84

Earlier quoted context omitted.

There is one other. Haskell has green threads, a preemptive scheduler, and it has a pretty decent implementation of Erlang-inspired multi-node concurrency primitives and higher-level framework including supervisors, gen_server equivalent etc in the Cloud Haskell project. It does NOT have Erlangs deployment base and track record but it is still a very promising framework and very appealing if you like Haskell's type s…

I've been confused for some time as to why people get excited about green threads. From what I've read, the main advantage seems to be that you can have threads on hardware that doesn't support threads natively, which is cool if you're on that kind of hardware. There's also some spin-up advantages I guess? But they don't get load-balanced across cores, right? I feel like I'm missing something important.

Green threads aren't just a substitute for when you don't have system level threads. Instead, they're a way of structuring code that allows you to express highly concurrent programs without requiring the heavy overhead of launching and switching between operating system threads.

Linux switches between threads at some frequency, I think it used to be 100 Hz. It involves swapping out the process registers, doing some kernel bookkeeping, etc—this is called a "context switch" and it's quite costly. Also, Linux threads allocate at least one memory page (4 KB) for the stack. [If I'm wrong about these details, please correct me!]

Basically, the cost associated with an operating system thread comes from the fact that it has to be isolated from other system threads on a low level... whereas language runtimes that offer green threads impose their own safety via language construction, e.g., Erlang processes can't reach in and mess with other processes memory (without C hacks).

So green threads can be much more efficient, but they require some care in the implementation, especially to support I/O, and to have fair and efficient load balancing, etc. Then you run N operating system threads to get balancing across cores, and distribute green thread work.

Re: Why Erlang Matters

#157

Post by mbrock »

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'll just put this here in case anyone's interested.

https://github.com/mbrock/HBEAM

It's a Haskell executor of .beam programs, in very early prototype stage, and I abandoned working on it 5 years ago (apparently).

Of course it's not meant to be competitive in any way, it's basically just for fun, and because I wanted to learn more about how Erlang works.

The function `interpret1` in the middle of this file has the main opcode switch.

https://github.com/mbrock/HBEAM/blob/master/src/Language/Erl...

I think it's about the smallest subset needed to run a factorial program, but also to implement the very basics of mailboxes with send/receive/timeout.

It uses GHC's shared transactional memory for the mailboxes:

https://github.com/mbrock/HBEAM/blob/master/src/Language/Erl...

Someone, fork it and finish it! :-)

Re: Why Erlang Matters

#158

Post by tomp »

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 as well! How does it work then?

(1) How does it preempt threads (my guess: it doesn't actually preempt threads, the interpreter yields after a certain number of instructors, or (if compiled) the compiler inserts conditional yields in each loop/function call/return)?

(2) How are memory spaces isolated (my guess: they aren't really, it's just that the memory allocator doesn't mix memory allocated by different threads)?

Re: Why Erlang Matters

#159

Post by SpacemanSpiff »

ccozan wrote: post #30
SpacemanSpiff wrote: post #17

Earlier quoted context omitted.

Embedded systems programmer here. I'm learning Elixir and am very excited about the nerves project: http://nerves-project.org/ https://www.youtube.com/watch?v=kpzQrFC55q4 Edit: There also seems to be a good Elixir/Erlang community here in Berlin Germany where I live at the moment.

Do you have some link or contacts in/to this community? I am in process to develop a quite interesting application on Erlang and I am struggling to find a community (in Germany) where I can either ask questions or have a pool of possible people to hire.

Hi, I'm quite new to the community myself, so I don't have any established contacts to share at the moment. I recommend checking here: http://www.meetup.com/Elixir-Berlin/ This company also has an office in Berlin now: https://www.erlang-solutions.com/contact.html

Re: Why Erlang Matters

#160

Post by SEMW »

tomp wrote: post #158
rdtsc wrote: post #103

Earlier quoted context omitted.

> 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 as well! How does it work then? (1) How does it preempt threads (my guess: it doesn't actually preempt threads, the interpreter yields after a certain number of instructors, or (if compiled) the compiler inserts conditional yields in each loop/function call/return)? (2) How are memory spaces isolated (my guess: they aren't really , it's just that the memory allocator doesn't mix memory allocated by dif…

> (1) How does it preempt threads (my guess: it doesn't actually preempt threads, the interpreter yields after a certain number of instructors, or (if compiled) the compiler inserts conditional yields in each loop/function call/return)?

Yep. The interpreter lets each thread do 2000 reductions (roughly == function calls), or until it waits for new messages if that's sooner.

Post reply on HN