
Adopting Erlang - ProfDreamer
https://adoptingerlang.org/
======
mononcqc
One of the authors here. This website is still a work in progress.

It's an ongoing effort to gather all the resources that will help you use
Erlang in a business. The booksite is divided in three sections focusing
particularly on Erlang/OTP’s higher level concepts in the current open source
ecosystem, how to use it in production (while setting up a pipeline for
continuous development and delivery), and how to build a team when you’re
starting from scratch.

We're working mostly linearly in each section, but they're not all progressing
at the same pace. We have nothing yet on "building a team" although our
outlines are all planned; the "hard things to get right" chapter was supposed
to come in later but we saw enough questions about these topics to rush it
out.

We might release things from each section as they are ready and we see fit. In
the meanwhile, we're always appreciating feedback and people checking in to
see what's new in terms of content.

~~~
hinkley
One of the things I've learned from many attempts to document internal
processes at organizations, is that often the authors are least equipped to
explain things.

They know too much, they often don't recognize how many pieces of assumed
information they're injecting into their so-called explanations. You often get
circular explanations in addition to circular reasoning and it can be off-
putting.

A better use of time is to get someone who is just started to exhibit
competence to write the docs. They won't assume the jargon, they can't assume
deep knowledge, and because they're living right at the pain point they can be
especially sympathetic. And if what they explain is dead wrong, this is your
chance to correct a horrible misunderstanding before they get too far along.
Pointing out the 'false friends' in a system early on can be pretty powerful.
Educationally or as an opportunity for improving the system.

In other words, I'd encourage you to invite new people to contribute. Just
keep an eye on what they do and be ready to jump in with corrections.

~~~
dmix
Can't people just remember what it was like to learn the things they know?
They were all those newbies at one point.

~~~
mononcqc
Yes and no. Some of the struggles are fresher than others, and in some cases
you do internalize things to the point they feel like a second nature.

The effort mentioned here of getting newer people to read the content and/or
produce it is something I've done a lot in the past, and one of the ways I've
used in on-boarding people as well. We (the co-authors of Adopting Erlang)
tend to do it with topics where we don't know everything the other authors
know, and provide feedback to each other about things that lack clarity.

I've also taught Erlang stuff in multiple places and started knowing some of
the things people find confusing as a kind of pattern, which may get easier to
address early on with time.

The thing that can never be done well, though, is predicting the things
someone with an entirely different background from yours would find confusing;
the context carried by their experience influences the things they understand
and the information they extract from a text. Teaching to a functional
programmer is different from teaching to a developer who has done OO their
entire career. Teaching to someone doing front-end work is going to be a
different experience from teaching to someone doing mobile or back-end work.
The same may often extend to sociological, economical, or cultural factors as
well.

All of this means that each teaching experience has new surprises as well and
you can't just cover them by thinking very hard. Frequent reviews, both
technical and from editors can help, though, along with your own experience
when teaching.

------
dxhdr
This is amazing, thanks for all of your hard work! It's very encouraging to
see continual effort put into the Erlang ecosystem. I haven't used Erlang in
around 5 years so this looks right up my alley for getting up to date with the
latest best practices.

As an aside, it's been a little bittersweet seeing all of the attention and
momentum going into Elixir. Yes it's great for BEAM and Erlang certainly
benefits from those contributions as well. But there's just something so
beautiful about Erlang, it deserves more attention than it gets. Thanks for
keeping the dream alive!

------
shijie
As an Elixir dev for coming up on four (four! Jeez where has the time gone?)
years, I’ve yet to really delve into Erlang. I can read the syntax well enough
to figure out why my Hackney request is doing odd things with my HTTP headers
etc..., but that’s about it. To all Erlangers out there, what
advantages/niceties/powers do you have in Erlang that make you reach for the
language over Elixir?

~~~
mononcqc
Mostly I just like it better. But otherwise in my day-to-day off the top of my
head:

Less “magic” (fewer macros that may change semantics, straightforward config
handling), focus on declarativeness, no variable re-binding, more powerful
test framework (common_test), seamless Dialyzer support, better logging
framework for structured logging, simpler/minimal syntax, personal preferences
for tooling (until recently, direct support for releases was lacking in
Elixir), and force of habit.

------
dynamite-ready
I've noticed there's a section in there about deploying with Docker. I know
many other development communities swear by Docker, but a number of the
OTP/BEAM devs I've spoken to seem unsure about it.

I also tend to believe Docker makes little sense, where OTP releases are the
alternative.

What's the opinion here? This question only pertains to OTP development.

~~~
whalesalad
It’s difficult to deploy Erlang apps in Erlang-style using Docker. The style I
speak of is zero downtime deploys where the VM is never turned off, but is
updated with new software as a living organism.

You can run BEAM apps in a container the same way you’d run any other app.
It’s possible. But BEAM is less like a PHP/Python/Ruby etc interpreter and
more like an abstraction for the OS (some might even consider it to be one).
When you’re in Erlang you think in Erlang and the runtime abstracts things
like processes, threads, and network partitions away... so you tend to want a
big beast BEAM instance (or a few big beasts) rather than a lot of tiny ones
(as one might scale up a horizontally scaled app like one on Heroku dynos).

It can be done. It’s just kinda going against the grain.

~~~
dynamite-ready
This is what I've been thinking. At the very least, I know that Docker
interferes with the BEAM VM's default behaviour for port management, and node
discovery. Docker containers require developers to select which ports
containers communicate through. Isn't that right?

~~~
mononcqc
This is ultimately not very different than what you would get with any
firewall or network rules in any business, and it's an issue shared by most
deployments regardless of whether you get containerized or not.

------
sb8244
Great stuff, as always. I liked this quote:

> If you expect failure to happen on an external service, do not make its
> presence a guarantee of your system. We’re dealing with the real world here,
> and failure of external dependencies is always an option.

------
btbuildem
I've always kludged my way through making Erlang applications. I still do, but
having had a good read of this, I'm encouraged. Thanks!

------
rsrsrs86
What is the use case for erlang given the current container technology and
cloud providers? I mean many problems that erlang solved (and beautifully did
it) can be dealt with docker and kubernetes

~~~
mononcqc
The Docker chapter does mention similar things, and José Valim recently wrote
the following blog post on this:
[http://blog.plataformatec.com.br/2019/10/kubernetes-and-
the-...](http://blog.plataformatec.com.br/2019/10/kubernetes-and-the-erlang-
vm-orchestration-on-the-large-and-the-small/)

In a nutshell, docker and k8s are to OTP what region failover is to k8s tech.
They operate on different layers of abstraction and impact distinct
components.

OTP allows handling partial failures WITHIN an instance, something K8s can’t
help with.

