
The Erlang Runtime System - mattw1810
https://happi.github.io/theBeamBook/
======
andy_ppp
The thing that gets me about Erlang and Elixir is that it has transparent and
simple to use microservices out of the box. These services are machine
transparent, can be called locally and remotely, provide bounded contexts
within your application, are robust and supervised against crashes, are
simpler to deploy and far far simpler to develop, can be discovered using a
variety of solutions or your own code. They also don’t require hundreds of
containers interacting to work locally. I would go so far as to suggest that
you shouldn’t build a microservices system without looking at the huge time,
cost and complexity savings that Elixir or Erlang will give you.

~~~
nrser
If it's feasible to write (most) all of your app backend in Elixir, then I
think it's a pretty great option. I feel like language context switches tend
to be very expensive and error prone for developers, plus the increased hiring
and on-boarding cost associated.

I think the core advantages of micro-services are:

1\. Polyglot applications. There often is _some_ library in a language for a
use case, but there is also often _the_ library in a specific language - the
one that has a far larger community around it, very active development,
considerable battle testing, a wealth of examples and guides and support
available online. If you use this library in this language, you just kind of
_know_ it will work as best and easily as possible. The trail is well trodden.
You now have a new problem of API contracts and versioning and such, but
pretty much every language can at least HTTP and JSON reasonably at this
point, so it's fairly tractable.

2\. You already _have_ code written in another language that pretty much
works, either because of (1) or for historic reasons. If you go all-Elixir,
you're going to need to re-write that hairy-ass black-box of a Go service that
interfaces with Chinese SMS delivery. But it pretty much works, and if you can
just chat with that over HTTP you can keep going. However, you probably want
something to turn that thing back on every week-or-two when it inevitably eats
it for whatever reason, and K8S gives you a _really_ nice interface for this.

In general, I think - and this was an opinion I read on this forum at some
point - that when building from scratch it's best to build a mono-service and
then break small things off from that as the need arises, and Elixir would
probably be at the top of my current list.

However, if you can run that mono-service in a micro-service environment -
Kubernetes and containers - then you're well prepared for breaking pieces off
or rolling new isolated components using the "right tool for the job".

I know there are difficulties around BEAM and K8S with both kind-of trying to
do a lot of the same things, and that's something to definitely be aware of...
people that have worked with it seem divided on where it falls between
terrible and not really that bad of an idea (if you're paying attention and
have some idea what you're doing).

~~~
cube2222
That's exactly the problem I have with elixir, or akka for that matter. It's
definitely a very convenient abstraction for building microservices and
distributed systems, but at the same time it's a heavy language lock-in you're
getting yourself into, the moment you start your project.

And especially now, when there are the de facto standard libraries to do
various tasks (like TF in Python) I think language lock-in can be a terrible
idea.

~~~
dqv
I don't think it's heavy language lock in at all.

If I need to do something in Python, I have options like pyrlang[0] and
rabbitmq[1].

In fact, parsing in Elixir is not nearly as mature as what is provided in
Python. I need to parse emails. Python has `email.parser` which is perfect for
my use case. I can easily use Pyrlang to do this. But Elixir is still much
better at being an email client (or many email clients). The end result is an
email client in Elixir that uses Python to parse the emails.

When I started with Elixir, my goal was to use it as much as possible, but
delegate as soon as the task is better handled in another language.

[0]:[https://github.com/esl/Pyrlang](https://github.com/esl/Pyrlang)
[1]:[https://www.rabbitmq.com/](https://www.rabbitmq.com/)

------
lytedev
The more I learn about erlang, elixir, and all the pieces that make them tick,
the more fascinating and appealing it all seems. It's also arguably my first
deeper dive into a compiler and all the ways you can get it to go the extra
mile. It's pretty amazing stuff the technology that goes into a modern
compiler.

------
stevedomin
You can download a PDF version from here:
[https://github.com/happi/theBeamBook/releases](https://github.com/happi/theBeamBook/releases)

------
vimal7370
Erlang is awesome! This book as well. Learned a ton about ERTS. Must read for
everyone who works in erlang.

------
abenedic
Due to its crash tolerant nature the Erlang runtime system always seemed a
little odd. I like this introduction though. I don't write much Erlang, but I
have to run a lot of it.

------
dmead
Thanks for this, the last time I read a straightforward language tutorial in
this spirt was "A Gentle introduction to Haskell" around 2004-2005.

------
signa11
dupe:
[https://news.ycombinator.com/item?id=16952311](https://news.ycombinator.com/item?id=16952311)

~~~
promopacket
Submissions without discussion aren't duplicates.

~~~
always_good
Especially not on a forum where new posts don't bump the topic. Commenting on
that 7-day-old topic means your post goes unread indefinitely. Which is about
as fulfilling as typing your comments into your diary.

