11 ms·
One of the many reasons I left Erlang is the lack of user types. I understand how the BeamVM got there. You build into the system the idea that there may be mul
by jerf 3y ago
One of the many reasons I left Erlang is the lack of user types. I understand how the BeamVM got there. You build into the system the idea that there may be multiple nodes that communicate over the network. Those nodes will routinely pass through states where they are on different versions of code. Those types may have to be upgraded at upgrade time. Having no user types in your type system, just a fixed set of dynamic types that are relatively simple, mean that when it comes time to upgrade, you don't have to figure out how to load two method sets for the same module at the same time (and the corresponding multiplicity of states that can emerge beyond that); the new code can get the old value safely and easily since it has no methods on it, examine it, and upgrade it in a principled manner.
Nifty, powerful, and simple, like so much of Erlang.
But also like so much of Erlang, I think the modern approaches (several of them) that languages take to serialization is better. It's a good first pass cut at the problem, but I prefer all of the GRPC approach to the problem, the JSON approach to the problem, and honestly just letting the chips fall where they may with most modern serialization libraries. Treat the remote system as not entirely trusted and handle the messages with a bit of skepticism generally works out for quite a bit of scaling. And you get user types back, which means you are no longer stuck on the BeamVM's quite anemic data types.
If you look at the underlying implementations of an Erlang map, you'll see why you're not getting vectors anytime soon.
1> dict:append(a, b, dict:new()).
{dict,1,16,16,8,80,48,
{[],[],[],[],[],[],[],[],[],[],[],[],[],[],[],[]},
{{[],[[a,b]],[],[],[],[],[],[],[],[],[],[],[],[],[],[]}}}
It's a big pile of linked lists storing assoc lists held together by tuples, with all the component value being dynamically typed. It's nice they didn't cheat on that, but it is... not the most efficient approach to dictionaries, just the one enabled by their type system, such as it is.
- jolux 3y agoNote that Erlang has maps since OTP 17, which I believe are implemented more efficiently than dicts.
- jerf 3y agoGood point, though I think my point about user types still holds. It is very difficult to create any efficient user types of your own with the primitives Beam provides.
- jolux 3y agoYeah, the lack of user-defined types is definitely one of the biggest downsides of the BEAM.
- throwawaymaths 3y agoElixir builds types out of maps (using the struct) and you can build multiple dispatch operations over types using Protocol. If you want to pretty print your user types, you can implement the Inspect protocol.