[elcritch]

Weird, on the Elixir forums and slack channels there seems to be a fair number of developers working or wanting to work in Elixir. Perhaps the initial uptake in interest outpaced the developer interests in some areas. It'd be interesting to know what the community is like in Europe.

Based on the recent formation of Dashbit [1] and larger companies like PepsiCo (?!) among others openly jumping onboard I think means Elixir has reached a clear point of sustainability for those willing to find (and train!) devs. Likely it'll never be RoR level, but I'm fine with that if it keeps the dev community more selective. Functional programming in general seems to be a bit of a self-selector.

1: https://elixirforum.com/t/jose-valim-announces-his-new-elixi...

[ericsanchez]

I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...

I see comments like

This:

>A very interesting language on powerful platform with a promising web framework... I talked with a couple of companies that jumped on it initially, but later decided to move...

And this:

>I recently had a convo with a company that moved into Elixir because they had an easier time hiring...

I see this comment pair somewhat often.

Also,

From @hajile

>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here.

>BEAM is slower than the JVM, but much more stable.

The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).

This makes a lot more sense to me:

>Functional programming in general seems to be a bit of a self-selector.

I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."

But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?

[dnautics]

Honestly I think you are doing things backward. With all due respect to the fantastic platform and vm that the erlang folks built, it's just not as joyful as elixir. And I feel like writing legible and organized code is easier in elixir since it's opinionated, about everything from directory structure to documentation to tests, and a couple of detailey things like structs are easier to read than records and macros are more sensible than string preprocessing

[cutety]

Definitely agree, though I respect the effort/desire to learn Erlang first given the fact the first time I saw Erlang code I was so confused/put off by it, the syntax was so foreign (not c-like, not lispy), variable names up capitalized, atoms are bare words, source files are just tons of functions, the tooling isn’t anything like modern languages (though since Elixir and hex/mix, that situation has gotten way better), then you’ve got all the OTP behaviors which are entirely unique to Erlang/BEAM, Erlang’s documentation though excellent and extensive isn’t by any means beginner friendly (IMO), and to top it all off, unless you’re coming from another pure functional language you have to deal with working in a new paradigm. Basically, Erlang is intimidating, which is unfortunate because how powerful BEAM and the OTP behaviors are.

However, Elixir wraps up the power of the BEAM and OTP in a much more approachable package. The syntax is much more familiar (thanks Ruby), provides tooling on par with (and better than some) popular modern languages, the language itself also provides more modern user friendly features (macros, pipe operator, protocols, etc). All with a community that is very beginner friendly and willing to help.

If you want to make use of OTP/BEAM, Elixir is by far the best way to enter. When you learn Elixir, you will also learn the major OTP behaviors and concepts (Supervisors, GenServers, Applications, Registry). Eventually you’ll find that there are even more goodies in the beam not directly exposed by Elixir (genstatem, ets/dts/menisia,timer,digraph — are a few of my favorites). Fortunately though, you can call Erlang modules/code directly from Elixir (and vice-versa), so you’ll then eventually dip your way into playing with Erlang modules as needed and when you approach the docs after having experience with OTP with Elixir, you’ll notice a lot of things are familiar and the Erlang docs become much less intimidating.

Basically Elixir is a much easier entry point to Erlang. Erlang is a great language, but very different with a lot of new concepts and which can kill your motivation to learn how awesome the BEAM is, so if you want to learn Erlang, by all means give it ago, but if you find yourself frustrated/confused with it, try Elixir for a while, then come back to Erlang and I bet it will be a lot easier.

When I initially saw Erlang, I was put off, the docs were confusing and I would avoid them at all costs, always try to look for an Elixir wrapper. Now after having worked with Elixir a lot? I frequently find myself going to the Erlang docs first to find a solution instead rather than hex or whatever. I can easily grok my way through an Erlang projects source, which previously was completely foreign to me. Will I ever likely write anything serious in pure Erlang? Probably not. Am I saying if you learn Elixir you will also just pick up Erlang? Absolutely not. What it will do though is make the process of learning Erlang (if that’s the goal), and it’s absolutely massive built in library of tools/abstractions/patterns that no language I’ve seen comes close to replicating an order of magnitude easier.

[dnautics]

You may like this: the very odd gen_statem callback pattern exists to group different callbacks by state (which you can't do because you need to group like headers together). But in Elixir, we use modules and macros to organize our code more sanely and less ad-hoc-ey:

https://hexdocs.pm/state_server/StateServer.html

[cutety]

I've only had 2 complaints with gen_statem, the docs were initially some of the most confusing/unclear and the state_functions callback mode (which I think partially is to blame for my first complaint as I was expecting a more gen_server like api with handle_* functions -- which exists but the docs use the state_functions for most of the examples and the handle_event just kinda getting some "oh by the way this exists" examples). I actually initially decided to just keep using gen_server's with a "status" or whatever value in their state as I figured it was good enough. At some point over the next few weeks I actually ended up having this talk[1] pop up in the recommend videos, and I figured I give it a watch to see if it would help make sense of gen_statem or at least just confirm that I don't need it. And while watching it, once he started explaining actions (timeouts, state_timeouts, postponing, etc) I realized that gen_statem literally solves so many problems that I've had in the back of my mind on the project I was working on like "I should figure out a way to change the state of A and do something when it doesn't receive any messages from X,Y,Z processes" (gen_statem's timeouts!) or "how should I handle messages received while attempting to recover, I guess I could put them in a queue or something..." (oh, gen_statem will let me postpone them until it's healthy!). It took a couple more re-readthroughs of the docs to fully grasp, but now it gets included in almost everything I work on, it's so useful (though I guess I should've assumed those were already solved problems by the BEAM/OTP as usual).

However, now my biggest complaint about Elixir is that gen_statem didn't get any official wrapper. StateServer looks like almost exactly what I would want out of an official Elixir wrapper. I also like to see the addition of `handle_continue` as well, because the first thing I did before migrating any of the gen_server's to gen_statem's was create a small wrapper module to a) make the handle_* return values more in like with GenServer's (basically just making it {:(no)reply, (transition|keep), data, [actions]}) and b) add a quick and dirty handle_continue callback because I use it all the time with GenServer. And this literally just looks like a more polished version of that, so thanks!

[1] https://www.youtube.com/watch?v=_4MTIffWhYI

[cthalupa]

>Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?

Blogs from the Discord team pop up occasionally. They're primarily an Elixir shop with some Rust thrown in (via NIF w/ Rustler)

https://blog.discordapp.com/tagged/elixir

[elcritch]

> I picked up _Programming Erlang_ because I like Joe. I'm trying to understand why the platform, and the accompanying language(s), aren't more widely used? People seem to speak very highly about Elixir, BEAM, and OTP. It all seems really great...

Watching videos of Joe talk super impressed me. He kept the same enthusiasm for programming as any college age programmer. That's impressive!

> From @hajile >>BEAM is about an order of magnitude faster than Cpython ...If you prefer Ruby syntax over Python, there is no contest here. >>BEAM is slower than the JVM, but much more stable. > The second quote seems to be a pretty reasonable trade off (my next question is, how much slower?).

There was a recent web-server benchmark that illustrates the performance and stability trade-off pretty well [1] (or older web-socket one [2]). The StressGrid benchmark shows Erlang/Cowboy achieving about roughly 1/2-1/3 the speed of the compiled options (Java & Go), and roughly double that of NodeJS. Erlang/Cowboy maintained very stable latency numbers after hitting it's peak however (see graph in [3]). There's an oddity with Cowboy 2, that appears to be due to HTTP/2 support but can be disabled (though HTTP/2 in theory should support faster client responses with less multiplexing of HTTP requests).

In general I'd say BEAM is on average faster than CPython, though recent CPython 3.x versions have improved a lot. Importantly BEAM is one of the few dynamic language/VM's that supports multi-core natively (Clojure & Julia for other two main ones?).

> I like functional programming, but experiences do tend to be either: "I love FP" or "Eh, not for me."

True! It seems like either you love FP or hate it. It is a bit painful if you have a bunch of mutations you need to do on a complex object, but there's usually a way to refactor it so you avoid so many mutations. But often you have to think a bit first and be more explicit. On the other hand I modified a short Python script a few weeks back and it took me an hour to find a bug with some variable scoping/shadowing corrupting my data.

> But are these it? I've been getting into erlang lately (to then get into elixir), but I feel like I've been "waiting for the other shoe to drop." As in, I'm wondering if there's some disadvantage that doesn't get talked about. Are there any engineering blogs that talk about using BEAM/Elixir/et al in production?

There certainly are gotchas, with Erlang Distribution in general or with default tools like Mnesia (split brain, 2G file limit). One gotcha I saw from a great Youtube talk (that I can't find) was when using the standard Erlang distribution to distribute jpeg images. Erlang distribution network normally only opens one connection between each node, which when you try to send lots of large binaries will get saturated. Then things like PG2, and health checks, etc which require low latency will start breaking. That team solved their issue by creating a separate connection plane for image data, a few hundred lines of code. Similar issues can (apparently) can happen with BEAM software like RabbitMQ as well since it uses Erlang distribution internally. There's plenty of stories from people recovering from errors [like 4]. Erlang Solution's has a great collection of videos and blogs on Erlang & Elixir.

I'd agree with sibling comments, learning Elixir first is just much nicer for many devs used to Ruby or Algol family syntax. Capitalized variable names confuse me to no end in Erlang code.

1: https://stressgrid.com/blog/webserver_benchmark/ 2: https://hashrocket.com/blog/posts/websocket-shootout 3: https://stressgrid.com/blog/webserver_benchmark/response_lat... 4: https://www.slideshare.net/GiltTech/riak-a-successful-failur...

[elcritch]

P.S. Hope you enjoy learning OTP style programming!

[lawik]

I think there is a touch of catch 22 in "are there enough devs? are there enough companies?"

But from my end it looks to be improving. I've gotten going with doing it professionally and I hope to maintain that focus mostly.