[im_down_w_otp]

Erlang's BEAM, assuming no chicanery of NIFs, will use reduction counting to eventually yield a scheduler to make sure other Erlang processes get execution time. This gives you kind of a "will eventually happen" property. It can't guarantee meeting a deadline. Just that all things will be serviced at some point.

[elcritch]

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.

[harrisi]

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.

[actionfromafar]

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.