Is Erlang the language that I'm looking for?

Questions / Help
1

I really like what the BEAM brings to the table in the sense of safety and concurrency. Because I have worked with Ruby before I though that Elixir would be the answer and in some ways it was. The thing is that I found Elixir to be too big and opinionated. Is Erlang simpler than Elixir? And the big question is, from Erlang can I use the nice libraries that are available at Elixir?

5 Likes
2

Hello! Welcome to the forum.

Erlang is quite a lot simpler than Elixir in my opinion.

Sort of. You’ll have to install Elixir on your system and also configure your build tool with a plugin or such so that it knows how to compile the Elixir code.
If the library is heavily macro based (like Phoenix, Ecto, NimbleParsec etc) you won’t be able to use them outside of Elixir.

6 Likes
3

Hello! Welcome to the forum.

Thanks :man_bowing:t2:

If the library is heavily macro based (like Phoenix, Ecto, NimbleParsec etc) you won’t be able to use them outside of Elixir.

Ok, this makes things more complicated, not impossible for sure, but more complicated as I would write most of the code in Erlang and then I would have to write some Glue code to connect Erlang with Elixir.

2 Likes
4

Hiya. Honestly, even if there’s no heavy macro usage, in my experience it’s still not straightforward to use Elixir libs from erlang. (Others may disagree, YMMV, etc.)

There’s some basic hygiene stuff that’s simple but still quite noisy: you have to namespace everything as atoms in a very erlang-unnatural way (e.g. 'Elixir.Lib.Module':function()), and add metadata to maps to make them compatible commonplace Elixir structs (e.g. #{ '__struct__' => 'Elixir.Lib.StructName', k => V [...] }). Naturally you also need to have the whole Elixir toolchain installed everywhere you want to use it.

Obviously none of that is a huge deal, but neither is it the main issue, which unfortunately is IME more fundamental in terms of build and run: in short, it does work, you can do it, but the toolchain integration isn’t really there yet. It’s not totally clear which rebar plugin to use where, and it never really works straightforwardly in the way rebar3 ‘just works’ for Erlang-only projects, or mix ‘just works’ for an Elixir project. There’s always some slight mismatch between building in dev vs release, mac vs linux, local vs inside docker, getting mix set up in CI, whatever. It’s never anything totally consistent and someone else always got it working somewhere else, so you’ll always get someone saying “oh it must be your setup” - but really, it’s not, it’s just that Elixir wasn’t designed from the ground up to be interoperable with Erlang, only the other way round, and such interop that there is is kind of worked-around or retro-fitted, so it’s never going to ‘just work’ reliably everywhere.

It kind of works, and gets you tantalisingly close to being able to just pull in some neat piece of Elixir code, but in the 5 or 6 times over the last few years when I’ve tried again to see if it worked any better than previously because I wanted to use some cool Elixir library, every single time I’ve ended up giving up and either finding an erlang equivalent, or just writing my own version.

So for now, even ignoring ecto/phoenix etc (let alone wildly cool stuff like scenic that I’d love to use), I just assume it’s a no-go, and stick to straight erlang. Perfect example: the other day I wanted to do something TUI-ish and found ex_termbox which seems super handy and nicely put together, and I got it running, but using it in anger involved unwieldy #{'__struct__'}/cell mappings everywhere so that using it from erlang just feels clumsy and coding it takes longer than it should, so I ended up spending a day porting it to erlang. It’s probably more my obsessive tidiness than actual time efficiency dictating I should do that, but it feels a whole lot neater, and - more importantly - I now know I won’t ever have to mess around with mix and the problems likely associated with it, especially when working cross-platform.

As much as I prefer and plan to stick with erlang, if your two main motivations are BEAM and Elixir libraries, you might be better off biting the bullet and going with Elixir. Personally I’d say it’s worth using erlang without worrying too much about Elixir because it’s smaller, simpler, and everything around OTP etc were designed for it and there’s none of the impedance mismatch that comes along with any kind of language interop. (Maybe gleam makes it much smoother, I haven’t dug deep into it.) On the flip side, if you really don’t like Elixir’s size and opinions but can’t do without some of its libraries, then even if it is fiddly, you can probably get it working for your scenario.

Best of luck either way :four_leaf_clover:

12 Likes
5

Build tools are a big pain point. Mix “just works” with both Elixir and Erlang, so if I need both in one project I tend to use Mix.

Same goes for Gleam, if I need Gleam and Mix in a project I’ll use Mix with a plugin that support Gleam. It has been quite challenging to get Elixir packages compiling outside of a Mix project.

3 Likes