A few years ago, I tried to use Core Erlang as a compiler backend. It's fairly straightforward to learn even without thorough documentation. I wrote a bit about my process to try to help the next person [0]. For my particular project, I ended up abbandoning the approach and generating BEAM bytecode instead [1]. That was definitely more challenging, but it was neat to see Erlang's commitment to backwards compatibility in action. I believe that BEAM modules emitted by the first versions of Erlang are still valid on modern implementations. New functions are added and old ones are deprecated, but the actual file format version indicator hasn't changed.
I've been interested in learning Erlang, but haven't seen more than one or two jobs that hired for it. I'm probably looking in the wrong fields (back end) or locations.
Could someone point me? Is there a certain industry that has more predominant Erlang jobs?
Likewise; I've been dancing around Erlang playing with it on and off for about twenty years, but I'm at the stage in my life where to really dive into it I'd have to have a job where someone paid me to work in it (or Elixir, or both). It seems most jobs that want Erlang want specifically someone who has already been working in it, which is a bit of a specific thing, and a bit of a circular situation.
Similar thing for Rust, which I'd also really be into working with professionally as well, but won't be able to where I work right now.
(FWIW I'm a mature software engineer with experience across the stack, systems and app-level C++ mainly lately, but Java, Scala, Python prior to that. Deployed RabbitMQ at a startup many moons ago, but that's it for direct Erlang professionally)
It doesn't have the entrepreneur approval yet. Elixir is halfway between toy and legit and moving towards legit. I think we will be singing a different tune in a decade. It's hard to imagine the distributed systems status quo persisting so long. Software ideas have shorter lifespans.
As sort of an aside, that can be an interesting lens to view hiring through. A while back I was looking around, and since I have some history with Erlang, was looking for roles involving Erlang and Elixir, among other things. I've architected and written production Erlang code that's deployed in products and know the system fairly well. But I don't have a lot of Elixir experience.
Some companies were like "wow, that's a lot of BEAM experience - let's talk!".
Others were like "my checkbox says Elixir, sorry".
I'm old enough at this point to realize the latter were doing me a big favor.
Any sensible employer should treat Erlang and Elixir experience as equivalent. There are important differences, but it would only take 2 weeks for someone experienced with one to be pretty up to speed with the other.
It is, for instance, the opposite situation to C and C++. In that case, they are languages that share syntax but you should code in fundamentally different ways. Erlang and Elixir don't share syntax, but all the important core concepts are the same.
There are a few more substantial differences, like Elixir utiling binaries rather than Erlang's 'strings' that I think are nice improvements, but I was never worried about getting up to speed with Elixir. The tricky bits of working with BEAM are nicely illustrated here:
[0]: https://8thlight.com/blog/kofi-gumbs/2017/05/02/core-erlang....
[1]: https://github.com/hkgumbs/codec-beam