
Languages on BEAM, the Erlang virtual machine - nkurz
https://github.com/llaisdy/beam_languages
======
iagooar
In case you are wondering what to use as your next programming language,
please consider Elixir!

It has a lot of advantages:

\- it is an easy to use, well-designed functional programming language, that
happens to boost productivity and be (a lot of!) fun at the same time

\- it is modern, with modern tooling around the language (e.g. mix, edeliver)

\- it has Phoenix, a modular web framework, ideal for APIs and traditional
MVC, very modular

\- it is rock-solid for a relatively young language

\- stack traces are clean, readable, and point you in the right direction most
times

\- performance is decent on a single-core, but since it's basically Erlang, it
scales better on multicore than most solutions out there

\- it has a world-class concurrency model powered by OTP, but more
approachable to the average programmer, lots of high-level concurrency
abstractions built-in

\- Umbrella projects for those who need or want a truly modular application
without going all-in with microservices

\- it is the only language besides Erlang proper, that runs on the ErlangVM
that seems to be getting a lot of traction (or at least a lot more compared to
the alternatives)

\- the community is very welcoming and open, lead by José Valim and Chris
McCord who are smart, pragmatic and very nice people

~~~
gamache
I love Elixir as much as the next guy, probably more, but I want to temper
your enthusiasm a bit:

> it is modern, with modern tooling around the language (e.g. mix, edeliver)

Sort of. Mix is a nice package manager. Edeliver is a series of hacks on
deliver, a five-year-old Capistrano clone. But don't expect Elixir to fit into
2015-class deployment systems just yet.

> stack traces are clean, readable, and point you in the right direction most
> times

Other times, the error happened in another process, all you see is a timeout,
and it takes some spelunking. Not uncommon in my experience.

But I'll also add a couple of points:

\- the docs system is fantastic, in particular the automatic generation of
handsome docs websites, and the `doctest` system which allows example code in
your docs to double as test code

\- I'm not sure there is anything better than supervisors for isolating and
recovering from errors. Defensive programming is one thing, but sometimes your
RAM stick gets hit by a cosmic ray. Shit happens; have a plan.

~~~
oomkiller
I am not sure how you define 2015-class, but building a release with
distillery, and running docker build on a Dockerfile that copies the tarball
(that includes everything needed to run your app (ERTS, app code, NIFs, etc))
makes a docker container that you can deploy as you'd expect. If you want to
use clustering it's a bit more setup, but I was able to get a simple phoenix
app running clustered on Google Container Engine (Kubernetes) in about 4-5
hours, starting with zero knowledge about Kubernetes or Elixir deployment. I
pushed my code to github[1], and I did a talk on it at our local Elixir
meetup[2].

Now that I have it figured out it's totally painless to upgrade, especially
because of the Kubernetes tools. Simply make a new release, build a new
container, push it to your docker registry, and then do a rolling update with
kubernetes using the new version of the container. You can also add/remove
scale on the fly, libcluster handles it all.

[1][https://github.com/bbhoss/k8sexamplephx](https://github.com/bbhoss/k8sexamplephx)

[2][https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be...](https://www.youtube.com/watch?v=SNll1r6ZtO0&feature=youtu.be&t=4788)

~~~
gamache
It fits into industry-standard deployment systems, yes, but not without
sacrificing some inherent benefits of the Erlang platform. In particular, hot
upgrades and downgrades are no longer there, as Docker images try pretty hard
to be immutable. Of course there are also the effects of flushing all server-
local cache and/or memoization upon deploys too. Probably a bunch of other
stuff I can't think of now also.

So far I've preferred to stick to the Erlang way of doing things because it
let me be laziest and it hasn't failed me, but someday I would like to see
tools that allow the Erlang way and the e.g., K8s way to work together.

~~~
vertex-four
On the other hand, most people seem never to touch hot upgrades, even in
Erlang, preferring the traditional rolling update across a cluster of
machines. A lot of libraries aren't built for it either.

~~~
andy_ppp
Yes, hot upgrades sound incredible but the other advantages of docker seem to
outweigh them. There is no reason you can't write a script to download the
release and do the hotupdate but it feels like you are treating your
containers as mutable then which is frowned upon.

------
im_down_w_otp
It's great to see this list. As an Erlanger there's one thing that's started
to bother me of late, and that's how subdued and declining the community
feels. There are a handful of passionate and capable people making great
strides to improve things (rebar3 is excellent for instance), but the momentum
seems to be all behind Elixir these days.

Most of the action around Erlang (conferences, etc.) seems rooted in nostalgia
not in finding ways to connect to new users or new use cases. Looking at the
speaker list for Erlang Factory 2017 I'm trying to figure out why there's
nobody from Whatsapp, MZ, Facebook, Amazon, Visa, Goldman Sachs, etc., and why
so many of the speakers are repeats of years past (in some cases multiple
times over multiple years past).

Despite having a ~15 year head start, and some really high-profile use cases,
it seems like the Erlang powers-that-be haven't figured out how to capitalize
on much of that, and it's a real bummer for people in my situation (and I'd
argue the industry as a whole is worse off for it too). I'd really like to
have my team use Erlang, but I'm feeling increasingly irresponsible suggesting
they invest in it instead of Elixir.

~~~
dxhdr
Erlang Just Works(tm) for me, I have a problem and I write code to solve it,
no whiz-bang new features or frameworks needed. That said I do partially
agree, in particular advancing the state-of-the art in regards to inspecting
and debugging would be great. Rebar3 is indeed excellent!

~~~
im_down_w_otp
I totally agree. It just works for me too. That's why I prefer it.

But it needs new users and new use cases to stay relevant and to be defensible
as an investment of time, money, and people in companies and enterprises that
are willing to depart from the traditional strongholds of Java or whatever the
latest thing out of Google is unfortunately. To say nothing of the more risk
averse institutions, which are vast and numerous.

Given how great it is I'm often at a loss for why it's ecosystem feels
stagnant and much of its evangelism (what little there is to begin with)
appears unable to build much excitement. :-(

Anyway, back to Erlanging and hoping more people discover how pleasant,
simple, and robust it can be.

------
solidsnack9000
The programming style encouraged by Erlang/BEAM is a good multi-computer style
as well as a good multi-core style. Everything is passed by value -- there are
no pointer or reference types to put in messages. If you want a shared value
then it has to be a key into a database.

If a company gets its major apps onto BEAM one could imagine a fairly
straightforward auto-scaling story. As the number of scheduled BEAM processes
grows for a given app, the need for CPU and memory could be expected to grow
more or less linearly with it.

------
pmontra
I'm really sad about the fate of Reia. It could have been the OO like language
that migrated millions of developers to concurrent functional languages.
Potentially much more effective at that than Elixir, which looks like Ruby at
a distance but it's very different when one sits at the keyboard.

[http://reia-lang.org/](http://reia-lang.org/)

------
sergiotapia
I read that processor makers are betting everything on multicore. More and
more cores.

Languages with great support for these hardware features will be the languages
of the future and today.

Elixir is definitely a great bet, you'll max all your cores and not break a
mental sweat about it.

Really compelling stuff and great developer UX.

------
kungfooguru
Missing Alpaca, [https://github.com/alpaca-lang/](https://github.com/alpaca-
lang/)

~~~
Ambrosia
It's there now!

------
nerdywordy
I'm diving into Elixir now to compare it with Golang for a new web app backend
I'm working on. I really enjoy the functional paradigm but from what I've seen
deployment can be a bit annoying. Whereas with Go you can compile and drop it
easily into production.

Does anyone have experience with this?

~~~
rubyn00bie
Deploying to production is a pain in the ass to setup the first time and has a
lot of gotchas. I know, I've done it.

It is getting better but right now the few things I can recommend the most
are:

• learn what an "OTP release" actually is and what it means. This alone will
save you days of your life.

• do rolling restarts, doing live upgrades is difficult and not necessary for
the vast majority of applications.

• read the prod.exs config, there's a commented out setting you'll need to
enable. I forget the name of it, but it's on my github "tehprofessor" with the
repo "flying with Phoenix" (its probably outdated in many ways but that
setting is essential).

• remember the application is compiled and then run, so you really won't get
any runtime configuration (likes Rails' environments).

• Docker can alleviate build pain a bit, as it stabilizes your environment-- I
don't use it myself but it makes building a bit more pleasant from what others
have told me.

• you'll very likely need to include all the applications, including ones
listed in your dependencies (it's a pain in the ass), in your mix.exs
applications list if you're using exrm.

... it's been a couple months as I've been on a coding hiatus for health
reasons (and a broken arm) but I believe most of the above should still be
very true.

That said and even with all the bitching I've had about it, I still love
Elixir and Erlang. Though I've been moving more to pure Erlang as time goes on
(FWIW).

Edit: clarity and note about loving me some elixir/erlang.

~~~
GrinningFool
_edit_ : my experience has been with Erlang deployments, I don't yet know what
the landscape is like for Elixir - at least the first part of my comment below
can be disregarded. I would assume it's similar to deploying an erlang
application, but I don't know for sure.

I think the second part is still possible, since if it can be done for Erlang
it can be done for Elixir.

\-- Original post --

I haven't found production deployments to be particularly painful, I'd be
interested to hear what kind of troubles you've run into.

Runtime configuration is definitely possible - you can deploy configuration
files with your application and determine which one you want to load. It's not
built-in, but it's a few lines of code to do it manually. You can also always
use environment variables, which is arguably a better approach.

------
marianoguerra
hi, here's a talk i gave called "how beams are made"

[http://marianoguerra.org/talks/beamba-buenos-aires-
meetup/#/...](http://marianoguerra.org/talks/beamba-buenos-aires-meetup/#/how-
beams-are-made)

follow the commits on this repo from the beginning to se how a fairly complete
language is built

[https://github.com/marianoguerra/otl](https://github.com/marianoguerra/otl)

------
ocschwar
So besides Elixir and Erlang, is anyone using any other language in this
family in production?

~~~
gamache
Hi Omri! No.

~~~
ocschwar
Heh. So, I'm doing smart grid stuff, and looking to see just what tools the
sector really, really needs.

For some things: Rust. For other things: BEAM/OTP

~~~
gamache
If you're interested in getting chocolate in your peanut butter, check out
Rustler:
[https://github.com/hansihe/Rustler](https://github.com/hansihe/Rustler)

~~~
ocschwar
OOh. That does cover it. Where I need safety assurance: rust. Where I need
resilience for crashes: BEAM. This does fill in the gaps.

------
xor-xor
I'll just leave this here, especially for Elixir fans:

[https://notamonadtutorial.com/interview-with-robert-
virding-...](https://notamonadtutorial.com/interview-with-robert-virding-
creator-lisp-flavored-erlang-an-alien-technology-masterpiece-c37003945c)

------
digitalzombie
Erlang community is really bad.

I went to a couple of meetups at OpenX. It's majority older programmers.

The topic of the day was how to attract new programmers to Erlang.

I've stated perhaps we need to emulate Ruby and have some killer framework
such as Rails. Their community is very vibrant.

The response was no, stay the course, we don't need to do anything. What's the
point of this talk of attracting new programmers to Erlang if the consensus
was stay the course and do nothing?

This way back before Elixir was on the radar.

Stopped going to that Erlang meetup, the programmers were out of touch.

I am mighty glad that Elixir and Phoenix is taking off. Shows them that I was
right. Either Erlang community change their mindset or stay the same.

------
bogomipz
I wanted to ask if any of you have found a market for Elixir devs and/or what
you think the state of it might be.

~~~
macintux
There was a lot of chatter in a post a few weeks ago about Ruby shops adding
Elixir to their toolkit. Erlang remains a niche, sadly, but Elixir looks
poised to be mainstream.

~~~
yellowapple
I feel like Erlang is already mainstream; it's just mainstream in a different
setting than Elixir (namely, Elixir seems to be targeting web development,
while Erlang has traditionally targeted telecom and related fields). Erlang
feels like a niche in comparison because there are a lot more companies that
need websites nowadays than there are companies that need to build their own
nine-nines-capable telecom systems.

------
jchassoul
3 days later, 146 comments and no love for lua on the beam?

~~~
etiene
it's there
[https://github.com/rvirding/luerl](https://github.com/rvirding/luerl)

~~~
jchassoul
yes! and it's awesome! (=

