Hacker News Reader

Comment by tomsmeding | Hacker News Reader

> 3. Erlang runs on beam which is a well established VM that has years of development behind it making it a robust core for your project compared to some other operating systems that you may load onto your RPI.

Not sure. Of course, the BEAM VM is robust and good for the things it's good at, but I don't think it's much more "robust" than, say, Linux, which seems pretty good, stable and robust these days. I'm not talking about software that runs on Linux; though the coreutils etc are pretty stable at this point (understatement). Linux is a fine platform to run your project on, and I claim it's no less robust than BEAM is.

Nothing against your other points though.

View on HN

I think you might be missing the point about BEAM. It's not that BEAM itself is more robust than Linux. BEAM and OTP enable the creation of highly fault tolerant services through the use of supervision trees, among other things. These restart failures from last-known-good state within microseconds. While Linux itself is certainly stable it doesn't provide any analogous facilities for creating robust services.

Linux is robust and fault tolerant by design. This comes at the cost of higher performance overhead, of course.

Besides, why are you comparing BEAM to a full-fledged OS kernel?

My understanding is that the OS is a few gigs in size and uses a lot of memory, and neves compiles to about 20 megabytes while still being resilient and easy to update.

Actually, a compiled Linux kernel is on the order of ~5 MB. A minimal root filesystem adds another ~50 MB to that. It starts to get bloated once you add kernel modules, drivers, etc.

That's 5MB compressed and also doesn't account for the fact that you'd also need an actual userspace of some description.

When I start writing applications in kernel space, i'll take "Linux" as a more serious contender for an application platform. you're the one making the comparison, so I'm pointing out that Linux provides very little in the way of application-level tools.

Edit: sorry, i see you're not the GP commenter.

> Linux is robust and fault tolerant by design.

How is Linux fault tolerant. Say a kernel driver starts overwriting kernel memory how do the rest of the kernel subsystems isolate that fault and keep going without crashing?

To clarify, Linux is fault tolerant where it needs to be: keeping userspace faults contained.

And what happens when a core module that is part of BEAM starts overwriting critical BEAM VM data structures?

A more apt comparison would be software running on top of BEAM vs. a userspace process running on top of Linux.

> To clarify, Linux is fault tolerant where it needs to be: keeping userspace faults contained.

Agreed.

> And what happens when a core module that is part of BEAM starts overwriting critical BEAM VM data structures?

Segfaults and other terrible things.

> A more apt comparison would be software running on top of BEAM vs. a userspace process running on top of Linux.

That's a better analogy of course. I've heard of BEAM VM described as an "OS for application code". Nobody would want to put their latest and greatest crown jewel production code on a Windows 3.1 platform, where one segfault in the calculator process takes down the word processor, but that is essentially what is happening when using shared memory and concurrency units (threads, goroutines, co-routines, green threads etc).

Linux is not an high integrity class kernel.

In fact in high integrity certified deployments, it is another actually robust and fault tolerant kernel running Linux kernel as yet another user process.

Kernels like INTEGRITY are robust and fault tolerant by design.

https://www.ghs.com/products/rtos/integrity.html

> , but I don't think it's much more "robust" than, say, Linux,

It is much more robust than Linux. If Linux kernel has a segfault and crashes, it takes everything with it when it panics. If one of the million Erlang processes which has an isolated heap crashes, it can probably safely restart (maybe with a few other ones it is linked with).

Bad analogy, but another commenter has already pointed this out. :)

But I do suppose that Linux has a higher chance of having a kernel panic than BEAM having an internal segmentation fault, simply since Linux has more code and thus a larger surface area for bugs.

Right, right. Agree. I think the right comparison is running on Linux vs running on BEAM VM. Linux became popular, among other reasons, because it allowed for strongly isolated processes. Those can crash, stop and that's fine. Other processes of other users don't even care or notice. Erlang VM solved the same problem for an application environment - millions of lightweight processes and run, individually crash restart because they are isolated.

To extend the analogy: running with threads that share memory between themselves is a bit like running on a Windows 3.1 machine - were if the calculator is broken it can crash and overwrite the memory used by the word processor

Reply on news.ycombinator.com