I've wondered about something related and the origin of Erlang in the 80s/90s. Back then when it was running on the telephone switches etc, was it running bare metal? Or did those switches run an OS like some form of Unix or something else?
Not to downplay it or anything, but it is "just" the normal Erlang BEAM VM compiled together with the real time OS RTEMS (which basically implements all POSIX things that the VM needs). Of course, getting it to work needed a lot of research and and experimentation, but the end result is surprisingly simple for what it is. The maniac/genius part is coming up with the idea in the first place and actually pushing through until it works, not many people have the stamina and focus for that.
Source: I was part of the original core team, and I developed the first version of the Erlang support library and runtime.
I guess I’ve been a bit disappointed Nerves doesn’t run on microcontrollers, though, such as an Arduino or Raspberry Pi Pico. Basically,
once you have Linux, you can run nearly anything already.
It was never intended to. The BEAM is not a good fit for that environment. I find it a bit bewildering that people are disappointed about that but I think it comes from having had the difference between microcontroller and embedded linux device clear to me from the early Pi and Arduino days.
You can look at AtomVM for a way to run Erlang and Elixir on an MCU. It just isn't Nerves. Nerves is a Linux :)
Part of my job is reviewing software design docs (we plan to solve problem x by doing a, b, c with some diagrams). I am constantly pointing out "please introduce acronyms, tools, vendors, and other $nouns; assume your audience includes an intern"
Doesn't even have to be an intern. Joining a new company, especially a big one, is always the same struggle -- the soup of acronyms and weird proper nouns. Everybody knows that $colorname is a UI library and $malename is an authentication server and three letter acronym refers to a specific department, maybe in a different company.
There usually is a phonebook to look it up, but pre-feeding some context is always nice.
The years help. As they do everywhere. Competitive job market all around right now.
Taking the question at face value, I don't know your intent, and not as a bitter commentary on the experience of trying to find a job with tech one likes:
I know people that did embedded C++ that got recruited into doing Elixir on a Nerves project.
I know lots of people who have just switched their web work in Ruby or Python to Elixir. Either by finding the job or doing the work for getting the tech adoption OK:ed at current employer.
Most Elixir devs I know did not have prior Erlang experience. But most did have prior dev experience. The BEAM ecosystems solve problems you mostly encounter with some experience.
I have also seen and onboarded several junior folks into the ecosystem and jobs as their first professional thing.
Connecting and collaborating with people who could vouch for you when the opportunity comes is a good starting point. But there are many paths.
Just hired a elixir dev recently. Assuming you already have experience developing in another platform, learn elixir and My advice would be to be active on the elixir slack and to have a few projects. Develop experience with ecto/oban/phoenix. theres plenty of jobs. There just aren't many people that know elixir well.
I tried Nerves a while back... device programming is brutal, Nerves makes it a lot simpler but it is still brutal and makes you wonder how it looks in C. That Mini Phoenix they mention... hahaha, seriously, unless they did some major work it is not a Phoenix.
So, that is all to say that device programming is really another level of difficulty. I am too sensitive to deal with that.
You mean Naked Phoenix? It refers to the poncho project setup where Phoenix is added as a dependency to the Nerves project (as opposed to creating an umbrella project). It's really just normal Phoenix.
I once wrote a system to interface with Mettler-Toledo postal scales, with the goal of replacing an ancient vbscriot based interface we were using at work.
I built a few hobby projects, and have another one in the pipeline for when I have time. All of them are based on Raspberry PI Zero kits from Pimoroni (shop.pimoroni.com) and sadly some of them are not in stock, and won’t be stocked again according to their support.
- these are not complex projects, and required (in the worst case scenario) some porting of the original python examples provided by pimoroni to interface with the hardware.
- deploying via ssh is fast and reliable
- can quickly experiment by pasting a new version of a module in the device shell. Got an editor keybinding to do that by targeting a tmux pane.
- OTP constructs help structuring code beyond the standard infinite loop that you have in other languages. And you can have pub-sub and state machines just with the standard library.
- it’s easy to abstract the hardware bits away using dependency injection, so that you can work on the host machine if needed.
- working with time and time zones is possible thanks to the ecosystem packages.
- any dependency with native extension can be a problem if not built with cross compilation in mind, and if it crashes on device that’s where debugging becomes a bit harder (might need a serial cable).
- if needed, I usually add a simple web yo for config/customization.
- there are great tools in the ecosystem to troubleshoot memory issues etc.
- sometimes I have WiFi issues and I suspect it’s related to power management, but I haven’t checked thoroughly yet.
[0] https://wiki.alopex.li/NervesNotes