So frustrating. I had high hopes going in that Elixir might be my next server-side language of choice. It’s built on the Erlang VM, after all, so concurrency should be a breeze. Ditto distributed applications and fault-tolerance. All supposedly wrapped in a more digestible syntax than Erlang provides.
Boy, was I misled.
The syntax seems to be heavily Ruby-influenced, in a bad way. There’s magic methods, black box behavior, and OOP-style features built in everywhere.
The examples in this chapter go deeply into this Ruby-flavored world, and skip entirely over what I thought were the benefits to the language. If Elixir makes writing concurrent, distributed applications easier, I have no idea, because this book doesn’t bother working examples that highlight it.
Instead, the impression I get is that this is a way to write Ruby in Erlang, an attempt to push OOP concepts into the functional programming world, resulting in a hideous language that I wouldn’t touch with a ten-foot-pole.
I miss Elm.
Day One
- biggest influences: lisp, erlang, ruby
- need to install erlang *and* elixir
- both available via brew
- syntax changing quickly, it's a young language
- if do:
- IO.puts for println
- expressions in the repl always have a return value, even if it's just :ok
- looks like it has symbols, too (but they're called atoms)
- tuples: collections of fixed size
- can use pattern matching to destructure tuples via assignment operator
- doesn't allow mutable state, but can look like it, because compiler will rename vars and shuffle things around for you if you assign something to price (say) multiple times
- weird: "pipes" |> for threading macros
- dots and parens only needed for anonymous functions (which can still be assigned to a variable)
- prints out a warning if you redefine a module, but lets you do it
- pattern matching for multiple functions definition in a single module (will run the version of the function that matches the inputs)
- can define one module's functions in terms of another's
- can use when conditions in function def as guards to regulate under what inputs the function will get run
- scripting via .exs files, can run with iex
- put_in returns an updated copy of the map, it doesn't update the map in place
- elixir's lists are linked lists, not arrays!
- char lists are not strings: dear god
- so: is_list "string" -> false, but is_list 'string' -> true (!)
- wat
- pipe to append to the head
- when destructuring a list, the number of items on each side have to match (unless you use the magic pipe)
- can use _ for matching arbitrary item
- Enum for processing lists (running arbitrary functions on them in different ways, like mapping and reducing, filtering, etc)
- for comprehensions: a lot like python's list comprehensions; takes a generator (basically ways to pull values from a list), an optional filter (filter which values from the list get used), and a function to run on the pulled values
- elixir source is on github
Day Two
- mix is built in to elixir, installing the language installs the build tool (nice)
- basic project template includes a gitignore, a readme, and test files
- source files go in lib, not src
- struct: map with fixed set of fields, that you can add behavior to via functions...sounds like an object to me :/
- iex -S mix to start iex with modules from your project
- will throw compiler errors for unknown keys, which is nice, i guess?
- since built on the erlang vm, but not erlang, we can use macros, which get expanded at compile time (presumably, to erlang code)
- should is...well...kind of a silly macro
- __using__ just to avoid a fully-qualified call seems...gross...and too implicit
- and we've got to define new macros to override compile-time behavior? i...i can't watch
- module attributes -> compile-time variables -> object attributes by another name?
- use, __using__, @before_compile -> magic, magic everywhere, so gross
- state machine's "beautiful syntax" seems more like obscure indirection to me
- can elixir make me hate macros?
- whole thing seems like...a bad example. as if the person writing it is trying to duplicate OOP-style inheritance inside a functional language.
- elixir-pipes example from the endnotes (github project) is much better at showing the motivation and usage of real macros
Day Three
- creator's main language was Ruby...and it shows :/
- spawn returns the process id of the underlying erlang process
- pattern matching applies to what to do with the messages a process receives via its inbox
- can write the code handling the inbox messages *after* the messages are sent (!)
- task -> like future in clojure, can send work off to be done in another process, then later wait for the return value
- use of Erlang's OTP built into Elixir's library
- construct the thing with start_link, but send it messages via GenServer...more indirection
- hmm...claims it's a "fully distributed server", but all i see are functions getting called that return values, no client-server relationship here?
- final example: cast works fine, but call is broken (says process not alive; same message regardless of what command sent in (:rent, :return, etc)
- oddly enough, it works *until* we make the changes to have the supervisor run everything for us behind the scenes ("like magic!")
- endnotes say we learned about protocols, but they were mentioned only once, in day two, as something we should look up on our own :/
- would have been nicer to actually *use* the concurrency features of language, to, idk, maybe use all the cores on your laptop to run a map/reduce job?
