4 ms·
.... and no vectors/arrays.
by cutler 7y ago
.... and no vectors/arrays.
- PopeDotNinja 7y agoYou're mostly right! http://erlang.org/doc/man/array.html http://erlang.org/doc/man/array.html
- enraged_camel 7y agoThere is List, which is similar (but not quite the same). Other than that, you may want to give this a read: https://elixirforum.com/t/arrays/8850/13 https://elixirforum.com/t/arrays/8850/13 tl;dr: the type of data structure that would satisfy your use case almost certainly exists in Elixir, but you need to look around a bit.
- derefr 7y agoYou've got: • http://erlang.org/doc/man/atomics.html http://erlang.org/doc/man/atomics.html and http://erlang.org/doc/man/counters.html http://erlang.org/doc/man/counters.html for cheap, mutable uint64 arrays; • The http://erlang.org/doc/man/array.html http://erlang.org/doc/man/array.html module for a functional persistent vector abstraction (similar to the one in Clojure); • ETS ordered_set tables, for mutable AVL trees (for when you want to cheaply apply a sequence of random mutations to a collection of terms without building a lot of garbage); • The process dictionary (https://www.erlang.org/course/advanced#dict https://www.erlang.org/course/advanced#dict), a mutable per-process hash-map data-structure, for when ETS ordered_set tables have too much inter-process copying overhead. All that, plus Erlang lists (singly-linked lists) are really cheap the way Erlang does them. (Each Erlang actor-process gets its own heap that gets independently GCed; short-lived processes never experience even a single GC, so allocating linked-list nodes (by consing to the beginning of a list) is just a matter of incrementing the actor-process's heap's free pointer—about the same level of optimality you'd hope to get from pushing to the end of a vector.)
- elcritch 7y agoThanks! Didn't know about some of those.