I really wish I had been exposed to Erlang/Elixir much sooner in my career. The inherent pragmatism and the overall desire to consolidate as much as possible within the BEAM makes for a very pleasant developer experience.
Thankfully writing them is kind of straightforward. Topics I've been interested in before and already know enough to write a bit about.
Anyone know the name of these pretenders, I'd like to have a look.
[1] Laravel Livewire: https://laravel-livewire.com/
[2] Ruby on Rails - StimulusReflex: https://docs.stimulusreflex.com/hello-world/
It's not that hard to accidentally exhaust the thread pool of some runtimes whereas you have to end up in pretty deep pathological areas in Erlang in order to do so. Notably `term_to_binary` on massive structures has historically been mis-bookkept (if you can call it that) by the runtime and will only count as one function call despite its high cost. This means the scheduler can't preempt it and wouldn't be able to nicely schedule N processes (where N is the amount of schedulers you have currently running, i.e. usually your core count) that were executing it.
But again, these are much deeper pathological cases than you'd find causing issues in most runtimes.
This especially applies to UDP, Erlang and any other distributed computing system.
Send many small non-blocking notification messages, usually delta state, not huge blocking RPC data structures.
if it's good enough for a hedge fund HFT platform, it's good enough for anyone aiming for low latency
https://medium.com/hybrid-cloud-engineering/beam-otp-on-ocp-...
https://hackernoon.com/successful-companies-use-erlang-and-e...
> Erlang is used as part of the real-time monitoring solution for this distributed trading system.
http://zerohedge.blogspot.com/2009/07/is-case-of-quant-tradi...
> Implemented a real-time monitoring solution for the distributed trading system using a combination of technologies (SNMP, Erlang/OTP, boost, ACE, TibcoRV, real-time distributed replicated database, etc) to monitor load and health of trading processes in the mother-ship and co-located sites so that trading decisions can be prioritized based on congestion and queuing delays.
They might be forwarding non latency sensitive client/internal orders through a system written in erlang, or using erlang for an orchestration layer, but they’re not competing with other hft traders in one.
Source: I work in the field and have built <5us systems.
https://m.youtube.com/watch?v=NH1Tta7purM Is a free great watch about the things you have to do to very reliably have such low latencies
It’s not very good for “make packet in to packet out as fast as possible at the cost of all else”. All of the abstraction layers come at a performance cost and aren’t all useful in the first place for low latency trading systems.
Genuine question.
From https://elixir-lang.org/crash-course.html "Erlang/Elixir Syntax: A Crash Course"
If you trully want low latency you need to use C/C++.
So it depends where you are looking from.
If you are a ruby shop and your regular out of the box latency is in the hundreds of milliseconds which under load falls apart into at first some and then all taking seconds or tens of seconds then the BEAM is fantastic, you go down to single-double digit responses and under load the latencies start to grow but very gradually. Every request gets more or less same latency.
When you come from microsecond latencies then it looks like the BEAM is doing a lot but is mostly in your way in achieving the lowest latency possible.
Completely different problem sets which gets confused by the writer not giving the necessary context for their claim.
In the Nerves/IoT/HW space one pattern used is to use Elixir for all the soft-realtime stuff and enjoy the QoL and other benefits of the BEAM and use other tools more suitable for hard-realtime tasks.
Hence I would guess 20 from the selection.