To Nerves from Elixir | Hacker News Reader

To Nerves from Elixir

underjord.io

162 pointslawik37 comments

what piqued my interest: nerves boots with only barebones linux and the otp/beam vm, effectively turning elixir into the embedded os [0]

[0] https://wiki.alopex.li/NervesNotes

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 :)

There is the AtomVM, a (mini)BEAM for microcontrollers https://www.atomvm.net/ There is also integration for Elixir and AtomVM.

Atom even compiles into wasm or at least should.

I'm curious if AtomVM is compatible with Erlang nodes.

Could you have a Pi on Nerves talking to microcontrollers?

I've never really worked with hardware but this all looks fascinating.

https://www.grisp.org/

There's a maniac/genius who made the BEAM VM boot directly on some hardware through his GRiSP project: https://www.grisp.org/

Hard real-time Erlang. It's siiiick.

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?

I'm pretty sure it ran on VRTX.

He automated some Rexroth production with it.

https://www.stritzinger.com

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.

Suggestion for the blog. After "I adore Nerves", put a comma and a brief description of what Nerves is.

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.

So how does one get a job in Elixir or erlang without doing erlang for the last 1,2,5,10 years?

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.

(edit: fix a spelling)

Sneakily introduce it at your current workplace for a specific project, and then after a year you have commercial experience

That's the standard way, that one I know.

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.

Nah, there actually aren’t that many Elixir jobs. You can tell from browsing the #jobs channel on the Elixir Slack workspace, and the jobs sub forum.

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.

Mini Phoenix? What? And I run the full Phoenix web framework on Nerves. This comment does not make sense to me, as the author. Sorry.

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.

https://nerves-project.org/

What kinds of cool things are people doing with this?

Not sure if they still do, but farm.bot was using Nerves.

I once built a firmware for the Pimoroni Keybow with it: https://xn--gckvb8fzb.com/projects/kiwi/

Beautiful webpage!

Thank you!

Here in Japan, we have a elixir nerves group. It isn't too active, but have made some stuff.

https://www.google.com/url?sa=t&source=web&rct=j&opi=8997844...

Interestingly enough it’s actually super nice for making touch screen kiosks. Not to say it can’t do much, much more.

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.

My friend made his own Nerves powered sprinkler system: https://www.youtube.com/watch?v=MS3Iap-2umQ

I believe he's still using it to this day.

I (author) have been dealing with the ReTerminal DM from Seeed Studio which in spite of being industrial is a fairly fun device:

https://elixirforum.com/t/bringing-up-cool-hardware-with-ner...

I have also done a bunch Nerves stuff on that blog as well as my YouTube. Some of it cool.

I know the Nerves Meetup recently posted a video covering a rotary telephone using Nerves: https://youtu.be/U4hetzVpjmo?si=Wc7QZ1SG0TPyjnaJ

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.

I built:

- a clock with an internal task scheduler (e.g. send me an email digest every morning), based on https://shop.pimoroni.com/products/scroll-bot-pi-zero-w-proj...

- a lamp that follows the solar cycle for the given location (e.g. it turns purple at twilight), based on https://shop.pimoroni.com/products/mood-light-pi-zero-w-proj...

I’ve also got some impression (https://shop.pimoroni.com/search?q=impression&stock=true) kits that I want to program for a family photo tree kinda thing.

A summary of my experience:

- 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.

Reply on news.ycombinator.com