3 ms·

> Let's skip over "low-latency", because virtually all programming languages and VMs are "low-latency". It's not fair to skip that one, because the way the bea

> Let's skip over "low-latency", because virtually all programming languages and VMs are "low-latency". It's not fair to skip that one, because the way the beam scheduler works is pretty dang magical. My (admittedly naive) understanding is that rather than hoping that 'yielding' constructs in a given language play well with the code, erlang/elixir processes are given a certain number of 'quantums' in the scheduler. [0] The other thing worth considering here, is that it is fair; there are benchmarks out there [1] that show other languages may have lower latency in some cases, but the overall fairness of the BEAM scheduler is better, and per above has less traps/footguns. As for the 'distributed' part, Erlang/Elixir have very specific rules about BEAM process inter-communication; with a few exceptions things are always copied by value, so you don't have to worry about mutation/etc. YES other languages may have similar concepts but BEAM specifically has a certain level of optimization around these cases so that the penalties are less in many cases. > It's also not me advocating corporate Java (shudder) - I'm just using it as an example of a common technology that also seems to tick all the same boxes as Erlang and Elixir as far as these claims go. I'd argue that the closest you'd get to Erlang/Elixir in the JVM world is Akka. And while I've only worked on/with Akka.Net directly [2] I can say that also having worked on an Elixir App, Elixir is far simpler even if the language has it's own idiosyncrasies [3] [0] - My understanding is that yes, poorly written FFI (AKA C library calls) -could- cause problems still, but thankfully the elixir community does a good job of making sure such things are handled well. [1] - Can't remember where but I've seen them. [2] - I've definitely looked at enough pre-license-change JVM Akka code to be able to read Scala (if not write), for whatever that's worth. [3] - tl;dr- Due to Elixir's typing/argument binding model, your best bet in most cases is to use Maps everywhere.

toast0 3y ago
> My (admittedly naive) understanding is that rather than hoping that 'yielding' constructs in a given language play well with the code, erlang/elixir processes are given a certain number of 'quantums' in the scheduler. [0] IMHO, the secret sauce here is that all function calls are potential yield points and construction of BEAM languages prevents avoiding function calls (you have to write loops as recursion), which makes yielding effectively preemptive. In most other languages, you have to choose between OS threads which are actually preemptive but at significant cost, or hoping none of your green threads loop without I/O. (Yes, you can break this in FFI)
pdpi 3y ago
> The other thing worth considering here, is that it is fair; there are benchmarks out there [1] that show other languages may have lower latency in some cases, but the overall fairness of the BEAM scheduler is better, and per above has less traps/footguns. This is a recurring topic in a lot of engineering problems: optimising for the best average case possible, versus optimising for the best worst case possible. Like e.g. a game that averages 200fps but has occasional dips to 20 fps versus a game that is rock-solid at 100fps and never dips. The absence of dips matters more than the peak performance.

toast0 3y ago

> My (admittedly naive) understanding is that rather than hoping that 'yielding' constructs in a given language play well with the code, erlang/elixir processes are given a certain number of 'quantums' in the scheduler. [0] IMHO, the secret sauce here is that all function calls are potential yield points and construction of BEAM languages prevents avoiding function calls (you have to write loops as recursion), which makes yielding effectively preemptive. In most other languages, you have to choose between OS threads which are actually preemptive but at significant cost, or hoping none of your green threads loop without I/O. (Yes, you can break this in FFI)

pdpi 3y ago

> The other thing worth considering here, is that it is fair; there are benchmarks out there [1] that show other languages may have lower latency in some cases, but the overall fairness of the BEAM scheduler is better, and per above has less traps/footguns. This is a recurring topic in a lot of engineering problems: optimising for the best average case possible, versus optimising for the best worst case possible. Like e.g. a game that averages 200fps but has occasional dips to 20 fps versus a game that is rock-solid at 100fps and never dips. The absence of dips matters more than the peak performance.