4 ms·
> Elixir has also done a good job of translating it for people who like Ruby-style syntax, I prefer the flexibility of the more verbose Erlang. The really big
by unoti 11y ago
> Elixir has also done a good job of translating it for people who like Ruby-style syntax, I prefer the flexibility of the more verbose Erlang.
The really big deal about Elixir is the ability to do LISP-style runtime code execution and generation. Lots of the Elixir language is implemented as macros, and the beauty and power of it is evident when studying the source of Elixir itself and Phoenix. A good example of where this comes into play is implementing a gen_server: in Erlang, this is always a good bit of boilerplate. In Elixir it can be done with a couple of lines, with automatic default implementations provided.
The Elixir syntax is a nice bonus, but the runtime code-generation Elixir brings to the table is a game-changer that takes it to the next level.
- strmpnk 11y agoWhile I like this idea, I think the parent's point is that the utter simplicity of the language is worth living without these things. I personally prefer Erlang to Elixir aesthetically. The big wins I see from Elixir are protocols and standardized tooling (though I have high hopes for rebar3). Parse transforms are overkill for most things but that's about how often I need things like macros in the world of Erlang. Even still, today's Erlang ecosystem is about the BEAM and it's great to have so many options. Erlang, Elixir, LFE, Lua, Joxa, &c.
- sjtgraham 11y agoElixir macros are compile time.
- unoti 11y agoYes, sorry, I meant compile time!
- ngrilly 11y agoAre macros an obstacle to having code completion for Elixir?
- dave_ops 11y agoYou can now do this in a sanctioned way in Erlang as of v18. They're including merl as part of the standard distribution now.
- unoti 11y agoThis is a very big deal. Thank you for telling me about it! As is so often the case, there's more value in the HN comments than the articles.