This is it, the final piece I wanted. Looking forward to the further stages. Apart from that, the language is 100% feature-complete as far as I am concerned.
Last time I looked at Elixir, it seemed like the consensus was "you're going to need to do Erlang too". Is that still the case, or is dipping down into Erlang no longer required?
I occasionally end up reading Erlang so I can see what's going on in some library. I haven't had to write very much.
If you have decent familiarity with Elixir, understanding Erlang isn't very difficult. You spend 20 minutes grokking the slightly weird syntax and then it's generally just a subset of Elixir. This is of course a bit of a simplification, but it's close enough for when you're trying to understand someone's Erlang code.
We have a four year old application, 10+ developers, 2500+ PRs, and I don’t think a line of erlang has been written by us. Maybe there’s one or two instances of calling an Erlang function in Elixir, but we’re 94.7% Elixir, 3.7% HTML, 1.1% JS, and 0.5% Other in our monorepo, full application.
I call Erlang functions or libraries very often, but in ~10 years of writing BEAM software I've never actually written Erlang code. Reading it is a useful skill and occasionally necessary, as is being able to consume its documentation for things like gen_statem.
As elixir noob I find I reach into erlang often, mostly for things like sets, queues.
Do people often end up writing erlang alongside elixir code in the same project?
I'd say it's uncommon but you'll often use Elixir wrappers around OTP stuff or Erlang libraries. Sometimes there isn't a wrapper for the library you want so you'd just call into the Erlang library directly, which is much easier and "noob"-friendly than FFI:s usually are.
For sets it's usually recommended to use Elixir MapSet. There is a Queue-wrapper around the FIFO-queue in OTP as well. For fun and learning you can also implement your own queues, or things like process pooling around the tooling already available.