Excellent comments! Thank you
eksperimental
eksperimental
I think this one would be a typical beginners mistake (or maybe it was just me), which is to try to pattern match on keyword lists, specially options passed to a function.
3
davedas11
As you point out, tuples are immutable. The reasons for having immutable types apply to tuples:
- copy efficiency: rather than copying an immutable object, you can alias it (bind a variable to a reference)
- comparison efficiency: when you’re using copy-by-reference, you can compare two variables by comparing location, rather than content
- interning: you need to store at most one copy of any immutable value
- there’s no need to synchronize access to immutable objects in concurrent code
- const correctness: some values shouldn’t be allowed to change. This (to me) is the main reason for immutable types.
Note that a particular Python implementation may not make use of all of the above features.
1
nocivus
Tuples are amazing to help your code grow while still maintaining order in the chaos. I have found over the years that having almost all your (especially business) functions returning either {:ok, some_object} or {:error, some_error_reason} helps keep code consistent and easy to understand.
And when you pair it with the with keyword, which allows you to specify multiple statements/operations in series and returns the inside of the block when everything succeeds but returns the non-matching result when one of the operations fails is amazing behavior that keeps everything very predictable.
Like with most software development, YMMV, but overall i love tuples as function returns 
2
nocivus
Here’s what i mean:
with {:ok, object_1} <- operation_1(),
{:ok, object_2} <- operation_2(object_1) do
final_operation(object_2)
end
If all pattern matching goes ok, the result of final_operation/1 is returned. If any of the others fail, you get the certainty that with will return {:error, some_error} as long as all functions have the same type of return.
2
Will-W
While they look a lot like them, tuples are not an alternative to lists, they are an alternative to structs.
The usecase for tuples and structs is to group together several values that belong together, e.g. because they’re different attributes of the same thing. You know in advance how many attributes there are, and what they mean.
A list is for a collection of things that are the same ‘shape’. Usually they’re the same type - i.e. all integers, or all the same type of struct, or all functions. If they’re different types then they’re still expected to be handled in the same way. If you have “some number of things that are all similar but I don’t know how many in advance” then you want a list, e.g. if you’re reading in a file and you separate it into each line, then you would use a list (of strings).
To go back to tuples and structs, the classic ‘person’ example in so many code examples is good here. For our purposes a person has two attributes - name (a string) and age (a number). Here is how to return each of the options from a function:
As a tuple:
def func() do
{"John", 33}
end
As a struct:
defmodule Person do
defstruct [:name, :age]
end
def func() do
%Person{name: "John", age: 33}
end
The tuple is easiest: you don’t have to declare anything in advance you just create it. Users of this function then have to know (e.g. through documentation or convention) that the first element is the name, and the second element is the age. They also get unwieldy when you’ve got more than a few elements - you end up with difficult to read code accessing elements. Adding an extra parameter also usually required touching a lot of code Tuples are excellent for pairing up 2 or 3 things together, and passing them around locally (e.g. internal to a module), or where there is a good convention (e.g. the {:error, message} return convention).
For anything more complicated than a couple of elements you want a struct - rather than having to know which position is which member the fields are named. Structs enforce that you haven’t forgotten any of the members, allow you to add new members without affecting most code and provide more information to autocomplete and type checking (also pattern matching if you want). Structs are a great choice a lot of the time.
You could also use a map for this purpose, but you usually don’t want to. A map is closer to a list in that it’s a collection of an unknown number of items, but rather than looking them up by position in an array, you look them up by name. Structs are actually implemented ‘under the hood’ as maps, but to use them in the way I’m talking about above you want the guarantees that structs provide. For example, when using a struct you can guarantee that a given field in the struct is present (because Elixir ensures that), whereas with a map you would always have to check in case you were passed a malformed one.
3