Right GRiSP has support for creating RTOS tasks in C, IIRC.

Within BEAM itself there’s no priority mechanism, however, on a RPi3 or BeagleBone you could get about an 200 uS average response time to GPIO on Linux, even under moderate load. The jitter was pretty low too, like 10-20 uS on average, but the 99.9% tail latencies could get up to hundreds of millis.

That’s fine for many use cases. Still I now prefer programming on esp32’s with Nim for anything realtime. Imperative programming just makes handling arrays easier. Just wish FreeRTOS tasks had error handling akin to OTP supervisors.

Now Beam/Elixir would be amazing for something like HomeAssistant or large networked control systems.

Erlang does have a mechanism to modify process priority, with process_flag/2,3.

As of OTP 28 there's also priority messaging that a process can opt in to. Not really related, but it's new and interesting to note.

> As of OTP 28 there's also priority messaging that a process can opt in to.

That's a very important feature. Without priority messaging you can't nicely recover from queues that start backing up.

Just a reminder that commonly "real-time" on stuff like VxWorks isn't hard realtime either. You test a bunch of scenarios, put in some execution CPU head-room you are comfortable with, and call it a day. With enough head-room and some more (or less, if you have money and time) hand-waving, you can more or less guarantee that deadlines will be kept.