I was comparing nested tuples with nested maps.
AFAIK in maps only the path to changed pair needs to be rebuilt, and with tuples all tuples in its path need to be copied.
If you check out this post Elixir vs. Erlang benchmarks - is one faster than the other? it describes that the internal implementation of maps varies depending on their size. For small maps, < 32, they are basically a pair of arrays containing the keys and the values. So for updating an existing key it would at least mean copying the value array while for adding/deleting a key it would mean copying both arrays. I am guessing they can share unchanged arrays.
For larger maps it is more complex and how long and how wide the path will of course affect how copying there needs to be done. Here again I am guessing they can share unchanged parts.
I am also guessing that they have tested to find the best methods and limits. 
However you do it with maps you still have to search for the right place at runtime while with records the calculation is done at compile time. There is not much you can do about that as that is a property of maps. When maps were introduced some in the Erlang community said that now we can get rid of records and use maps instead, but they don’t really solve the same problem.
Of course both records and structs are a way of adding user-defined data types to a system which doesn’t have them.
3 Likes
Yep, what @michalmuskala said. 
That is only because of the language syntactical constructs. If it use, say, Haskell’y record accessors then it would still be readable (although a function call instead of a . access, I.E. instead of blah.bloop it would instead of be bloop(blah), which would remove a case from . accesses thus making it near imperceptibly faster ^.^).
I wish the Record module in Elixir was implemented that way, it’s pretty close as it is, but not ‘quite’ there (it likes the KW access of a single function instead).
As for debugging, it would not be hard to in the inspector check if the first element of a tuple is an atom, and if it is check if it is a valid module, and if it is then format it like a record from that module (there could be a default-implemented to_string/1 function and/or to_repr/1 on record modules for example). This seems purely a language restriction and not something intrinsic to them being records as it is an Erlang standard ‘construct’ (not type though).
This right here. All cases of Elixir ‘Structs’ are small and thus better suited for an internal implementation as records (especially as I really exceptionally don’t like the ruby-ish style of random field-name accessing without knowing the proper and full type of something).
It’s really like the difference between OCaml Records and Objects, an OCaml record is, internally, just a C-like struct, no names, tightly packed, where an OCaml object is internally a dictionary, thus slower but more introspectable, and yet Objects in OCaml are touched in easily less than 1% of all library code just because Records are so easy to use, and the syntactical differences between them is a single character for usage, although Objects are a bit more verbose to define compared to records (opposite in Elixir where their definitions are almost identical but their usages are very different), however OCaml’s objects can fulfill multiple object implementations at once (think Rust/Go/Etc… style traits and implementations). Syntax is what makes all the difference, and the reason maps are so often used in Elixir compared to tuples/records is that the language support for records is and has been bad compared to maps (even something as basic is checking if the first element is a module-atom and checking that the record is valid as such to display is better, of which the inspect protocol already does a lot of special-casing like that so there was no reason not to…).
For larger non-structs, like actually storing larger amounts of data, I’d use maps the whole way. It’s just a thing of using the right type for the right code, and for small static things static records work far better, where maps are better for larger and/or dynamic work.
We need a BEAM VM that supports type declarations, falling back to an unchecked dynamic type that everything is be default, would be a huge boon for adding typed languages on the BEAM and especially for generating better internal code for when types are already known (like if you know a couple bindings are unsigned integers of 32-bit width and you add them, well that’s just a simple single assembly instruction then, no boxing or anything needed until they get passed back to 'dynamic’lly typed code, kind of like ASM.js of the javascript world, even matchers and guards would be able to infer a lot of typing around otherwise dynamic to make their internal bits more efficient).
3 Likes
According to some comments, there’s “no difference,” but clearly there is. I’m interested in using Erlang and/or Elixir in production. However, I’d like to get some straightforward answers. I will continue to read through the comments here.
When you say there are no differences, do you mean no as in “none” or no as in “some, but they’re not significant.” If the latter is the case, do you have any recommendations for any benchmarks I could view?
Thank you! I know this is a couple years old, but yeah ha. Just to add, I’m new to the community and I really enjoy Erlang and Elixir.
There are no differences at the language level.
Can you elaborate?
EDIT:
Also, welcome!
Hi 
thanks for taking the time to respond. I guess I meant your comment said there were no differences, but reading through other comments there seems to be some differences. After reading the comments more carefully I can see that the situation is nuanced in specific cases.
For context, I’m trying to build out a list of some pros and cons of using Elixir vs Erlang (in a context where syntax is not a deciding factor). I’m trying to develop a good answer to, “why use Elixir when you could use Erlang directly?”
Your comment was pretty concise and says about what I’d like to say. Do you have any suggestions on how I could show this? E.g. can I compare the byte code of elixir & erlang for similarity? Or would you say if there are any differences, they’re negligible?
Sure, let me make this a bit more concrete.
When you write literally the same code, you get literally the same bytecode. Examples:
-module(math).
-export([factorial/1]).
factorial(0) ->
1;
factorial(X) when X > 0 ->
X * factorial(X-1).
Will produce exactly the same bytecode as
defmodule Factorial do
def factorial(0), do: 1
def factorial(x) when x > 0, do: x * factorial(x - 1)
end
Literally 100% the same. Now, the Elixir standard library sometimes favors certain patterns of abstractions that provide a negligible, but not technically 0 cost compared to an erlang alternative. So for example:
Enum.map(list, fn x -> x * 2 end)
has 1 function call more over head (1 period, not 1 per item) than:
lists:map(fun(X) -> 2*X end, List).
because the Enum.map function will convert non list things to a list in order to map over them. If it is a list, it will just call that same function, which you can do yourself:
# this is elixir code
:lists.map(fn x -> x * 2 end, items)
and that ^ is again byte for byte identical with the erlang code.
So in terms of which one is faster, what it really boils down to is the approaches that each library takes. Certain things that Elixir macros let you do for example make certain high performance strategies a lot easier or more ergonomic than in erlang, and so it can actually be faster. Other times the desire to create friendly APIs in Elixir can sometimes introduce slightly more indirection, which can introduce small if technically non zero overhead.
Fundamentally though whether your Elixir code has overhead WRT erlang is entirely a question of what Elixir code you write. They compile to time same core structure, and end up as the same bytes.
8 Likes
Well said. Thank you for this, I really appreciate the explanation. You’ve helped a lot! (I feel bad leaving such a short comment given you took the time on a good example, so thanks again! ha)
3 Likes
