3 ms·

From the article: "- 13 x 10 % => 130 " Good grief, I hope not! :D Unless there is some subtle difference in Erlang between - 13 and -13 (one - might be

From the article: "- 13 x 10 % => 130 " Good grief, I hope not! :D Unless there is some subtle difference in Erlang between - 13 and -13 (one - might be the negation operator and the other might be the subtraction operator for instance). Hopefully this is just a typo. With respect to the atoms, since they are basically a bunch of constants that never get dereferenced and so cannot be garbage collected, wouldn't a better way to handle this be to create some kind of out-of-memory look up table, preferably one with good caching of commonly used values? My understanding of one of the core reasons that erlang is valuable is because of its robustness in a multi-threaded environment. It would be a shame to undermine that robustness by having it blow up because of too many global constants.

jerf 16y ago
"With respect to the atoms..." The only sane choice here is for Elixir atoms to be Erlang atoms, in the fullest sense of "to be", so that restriction is coming from Erlang, not Elixir. Erlang does exactly what you say; the memory leak in question is when you blow out that table. The Erlang language and runtime permit dynamic atom construction, which is useful because atoms are also the way functions and modules are referenced and it's nice to be able to dynamically compute such things, but if you continuously generate new atoms, you'll run out of memory.
josevalim 16y ago
From the article: "- 13 x 10 % => 130 " That was a silly mistake in the README. I just fixed it, thanks for pointing it out.