I'm working on making the dialyzer error messages better, too, in Dialyxir[0] and Erlex[1] =).
[0] https://github.com/jeremyjh/dialyxir [1] https://github.com/asummers/erlex
Out of curiosity, have you seen anything in Dialyzer for dealing with typing GenServer messages and handlers? I haven’t figured out a way to spec message handlers as dialyzer seems to only check that you have any `handle_cast` implemented and adding a behavior doesn’t compose. Given the key role GenServer plays in OTP, it’s a big lack IMHO. I’ve wondered if the new named guards in Elixir could help with it somehow.
I think this key. There are issues, and there are parts of the platform that are crap, but Erlang (via Elixir as well in my case, I'm not sure if feel the same way if it was purely Erlang) is on balance the most useful and usable tool I've ever used for building networked services
You might want to check out Grisp - https://www.grisp.org/ - Erlang VM ported to RTEMS. They also offer devboards with ample resources designed to run this thingy.
Also, you should take a big look at the Pony language if you haven’t yet. It’s much earlier days than Rust, but comes from people who know and love Erlang.
While this whole comment thread has turned into a bit of flame war, I appreciate your candidness and think you’ve tried to fairly express your opinion. As someone who likes semi-obscure languages and systems it’s valuable to see when and where system designs fail for people. Personally without Elixir I wouldn’t want to delve into Erlang/OTP for many of the problems you mentioned. The Erlang syntax seems "elegant" upfront on small problems, but digging into say CouchDB or Riak it’s a bit of a pain to follow. The lack of good name spacing, etc, I find to be a pain.
Elixir is overall a syntax that works well for me, at least as well as Rust’s. The Elixir team have made great strides in providing good compiler error messages, and are actively improving the distribution/ packaging story. Hex and mix are fantastic, and on par with what I’ve use in cargo.
> It depends on your needs. My issue is that it is enormously hard to fix the BEAM once you have built something successful with it. It's hard to hire for. Working with it involves lots of esoteric knowledge.
Not sure I follow this. I’ve dug into the BEAM source and found it to be well designed and relatively easy to follow. Especially compared to CPython, but not as nice as Lua. Presuming you’re meaning fixing dist_erl and such, that’d make more sense. But how would it be any different than say tweaking consuld
> We also know that people are adopting highly reliable and scaleable systems. It's just not Erlang. Cloud enables this. Containerization enables this. Instead of Erlang's IPC, you can use an IDL and an RPC compiler. Instead of pids, you can have a service registry using etcd or DNS. You don't have to hand roll any of that.
Exactly! Except it works two directions. Having to learn and deploy say k8s, consul, and then learn gRPC and figure out how to route messages, etc is a lot of work. While I’ve not deployed a large cluster on BEAM, it’s clear that I wouldn’t want to scale a BEAM cluster more than a few dozen nodes. However, a few dozen nodes can handle the workload for probably 90% of companies. Being in small startups if I can effectively get binary RPC, distributed namespacing, etc, for free it saves a lot of trouble and effort. I’ve also found it’s not to hard to entirely replace the distributed namespace mechanism, with projects like Lasp or Swarm, or heck, likely shunt it off to consuld in the future.
All that said I like Rust and plan on using it in the future where I can, likely, in conjunction with Elixir via rustler. My work is primarily doing IoT work, where Rust is slowly evolving. I’d love to have a Rust "OTP" and actor system for IoT devices where Beam doesn’t fit.