
The Soul of Erlang and Elixir [video] - tosh
https://www.youtube.com/watch?v=JvBT4XBdoUE
======
mikece
BEAM is such an awesome and beautiful VM. Not only is concurrency at a scale
unimaginable in other languages the norm for BEAM, but the isolation of
running processes didn't hit me until I asked an Elixir dev about running BEAM
in Docker. The confused look told me I was asking an odd question: processes
in BEAM are as isolated from each other as console apps running in different
VMs in VMWare server. These processes can send messages to each other but they
cannot access each other's memory. It was truly a mind-blowing revelation!

~~~
kerkeslager
> The confused look told me I was asking an odd question: processes in BEAM
> are as isolated from each other as console apps running in different VMs in
> VMWare server. These processes can send messages to each other but they
> cannot access each other's memory. It was truly a mind-blowing revelation!

Not quite: the messages sent are kept in shared memory (which is reference-
counted). Cycles can't occur due to immutability. But with everything else,
you're correct. One reason for this, is that every thread has its own garbage
collector! This allows multithreaded garbage collection without stop-the-world
pauses.

Source: Did a bunch of research into BEAM for implementing my own
multithreaded GC.

BEAM really is beautiful!

~~~
vvanders
> This allows multithreaded garbage collection without stop-the-world pauses.

This was one of the things that really floored me when I learned about how
BEAM was designed. It's incredible that how all the seemingly small changes
come together in a way that works _really_ well for the problem domains Erlang
was used for.

~~~
arthurcolle
Anyone interested in this subject would be extremely well-served by picking up
a copy of the late, great Joe Armstrong's "Programming Erlang." Putting
together a minimal "server" and then slowly evolving it into a GenServer is
incredibly fun and rewarding. And then the kicker is you get hot-swapping for
(almost) free! Learning about Erlang hot-swapping was probably one of my most
favorite moments in my brief time using Erlang before moving onto Elixir,
where you get it all right out of the box.

BEAM is truly a modern engineering marvel.

------
albydarned
BEAM is amazing. The scaling is insane. I built a business texting platform
using it ([https://pigeonsms.com](https://pigeonsms.com)).

As we brought on our first few customers I kept expecting we would need to
increase our hosting capacity. Here we are 2 years later and we are still
running the whole thing with our initial hosting setup.

~~~
ak47surve
Interesting. Mind sharing a little bit about your production hosting setup?

------
brianpgordon
In the talk he glosses over what he sees as serious flaws in Erlang
distribution. I did some digging and it turns out that he elaborated on
Reddit:

[https://www.reddit.com/r/elixir/comments/bronlx/discover_wha...](https://www.reddit.com/r/elixir/comments/bronlx/discover_what_makes_beam_languages_such_as_erlang/eohwr3r/)

~~~
olah_1
>First, in my opinion distributed BEAM is mostly intended to run on a network
which is fast and more reliable (such as local network). While in theory it
can also work on a less reliable/slower network (e.g. geographically dispersed
machines connected via Internet), in practice you might experience more
frequent netsplits which could cause various problems, such as worse
performance or less consistency.

This is exactly why I wasn't excited about LiveView[1]. It felt like a step
backwards in terms of human-centric design. Another tool that makes us
consider our network bars first and our life second.

In general, I'm kind of disappointed that Elixir isn't leading the way on
decentralized and offline-first technology, but I guess it's a limitation of
BEAM running on small/low-powered devices?

[1]:
[https://github.com/phoenixframework/phoenix_live_view](https://github.com/phoenixframework/phoenix_live_view)

~~~
brightball
I guess the question is how low powered and small you want to go? Nerves seems
to be flourishing.

~~~
olah_1
That's a good point. But does Nerves advance any kind of offline-first design?
It still assumes a constant and high quality network connection, right?

~~~
brightball
Nerves doesn’t make any assumptions about connectivity.

[https://nerves-project.org/](https://nerves-project.org/)

------
rramadass
See also: Erlang for bare-metal embedded systems -
[https://www.grisp.org/](https://www.grisp.org/)

Has anybody here played/worked with this ?

~~~
elcritch
Not with the GRiSP board, but I’m working with Nerves and embedded Elixir.
Even using Erlang distribution to communicate between devices over an internal
Ethernet lan. Works pretty well actually.

------
bmalehorn
The speaker mentions that Redis, MongoDB and background jobs were replaced by
Erlang.

What does he mean by that exactly? Erlang provides some persistent state
storage? Or is he just saying he used Erlang database drivers to access Redis
/ MongoDB?

~~~
bennyp101
You can use ETS and Mnesia, and overall it is built to be distributed so you
can pass messages between processes/nodes without needing something like
RabbitMQ.

Most of the time Erlang and OTP provide what you need already without having
to reach for an external tool. (Obviously depending on your use case)

~~~
namelosw
Furthermore, job processing is much easier with Erlang because the processes
and the scheduling mechanism - there could be no job, only processes doing
their things.

------
davidw
Looks interesting; wish there were a transcript. Example code appears to be
here:
[https://github.com/sasa1977/demo_system/tree/master/example_...](https://github.com/sasa1977/demo_system/tree/master/example_system)

------
foobar_
How does this compare to Go?

~~~
lostjohnny
Immutable, share nothing, completely separated architecture.

Go has no such guarantees.

------
kuzee
This is magic

