Yeah, this. I'm just getting started with Erlang and I already feel like an idiot for not using it sooner. When I think of some of the things I've done to try to achieve what the BEAM does out-of-the-box...
RPC is basically built in, so you'll probably never use REST internally. There's an in memory database built in (ETS) that will replace redis for most key value storage cases. There's easy recovery from crashes via supervision trees and associated features. You can do hot upgrades while your system is fully operational.
A few protips: hot reloads are outside of a few corner cases generally unnecessary these days. Be careful about erlang rpc if you expose it in any fashion over the network and follow the eef security working group guidelines re: erlang term format. I use Elixir's plug.crypto.non_executable_binary_to_term/2
to be fair, the guidelines are hot off the presses. I literally went to CodeBEAM, ran into to Bram Verburg (whose fantastic X509 library i had just found a week prior) and he told me about those guidelines, which had just hit hours before we spoke. Bram is great, he's very modest, and was amused that I thought he was some sort of superstar.
When I used Erlang in 2005, there was a problem with message queues growing and OOM-ing the process. The standard solution to that is RPC flow control and backpressure. Does this problem exist with modern Erlang?
Google's gRPC/Stubby has the same problem. It's one reason why gRPC servers are never deployed on the public Internet and always use hefty reverse proxies.
I always feel like Erlang and more generally BEAM is the language for a lot of today’s problems but will never see any kind of traction because of “worse is better”.
Can you share something on this reliability? Is it more reliable than the JVM? Or is it more predictable in terms of performance? I’ve found the jvm itself to be rock solid as well.
Erlang/OTP and BEAM have been around a long time and is probably just as mature as the JVM and Java, but they have slightly different goals: very low tail latency, easy error recovery, and easy distributed compute in erlang vs. better customization and median performance for the JVM. I'm sure there's more differences and more nuance than that, but I'd be very happy to use either language/VM in production.
It's also harder to write abjectly wrong code in the BEAM. I found out that my code was effectively self-forkbombing, because I had hooked up an error reporter (I adapted myself because the version I wanted had bitrotted) to rollbar which (very rarely, when the service was in outage) cause a crash, which would try to report, crash, and exponentially grow. Amazingly, this caused no service degradation for our customers.
