Heh, I’m well known around here as the proponent for good type systems. ^.^;
I made a Gradualixir plugin for mix that lets you use gradualizer like you can use dialyzer if you are curious. 
It’s not on hex.pm (use it from github master) since gradualizer is incomplete yet and thus not on hex.pm yet, and you can’t put things on hex.pm that depend on something that’s not on hex.pm.
I think in the end, the main advantage that maps have over records, is that they contain the names of the fields they contain right there, rather than these being position-dependent.
This has great advantages for introspection, pattern-matching and dispatch.
some of that could be built on top of a tuple-based system, but not all. Most importantly, knowing the field names of a record is only possible whenever the record definition itself is in scope.
True but in a tagged tuple tagged with a module then getting the field names is just as simple as something like elem(thing, 0).fields() or whatever information you want. Plus you could have another encoding scheme that just encodes it into it, perhaps in-position like {Blah, {:a, 1}, {:b, 2}} or maybe as metadata at the end or so like {Blah, 1, 2, [:a, :b]} or there are tons of other possible format as well. Hmm, ideas…
Or maybe something like:
{{:__struct__, :a, :b}, Blah, 1, 2}
Oh, wait. That’s almost exactly how structs on top of small maps are implemented 
Lol, it is exactly, and that would work well though it decomposes into 2 elem calls then, they are quite cheap though. ^.^
There are many styles to represent such a thing, though with how rare needing the names are I’d still think just putting them on the parent module is overall best, uses much less memory in the representation and makes it far easier to serialize (though if you kept the names in the representation and maybe a version key then you could implement fairly transparent migrations, hmm, structs could do that as well…).