Learning Elixir, part 2
Continuing on with working my way through the Elixir introduction. I’m trying to figure out how to keep this from taking forever (especially since I’m only doing this in little bits of free time here and there), so there’ll be a bit less commentary than last time.
Binaries, strings, and charlists
I love that you can use
? to show the code point in front of a character literal. (Not that
"a".charCodeAt(0) is all that harder.)
Pattern matching on binaries and bitstrings is good.
Keyword lists and maps
I like being able to use atoms as the keys in keyword lists and maps. It’s a small thing, but it’s nice.
do-blocks are just syntactic sugar. (Apparently I really like it when control flow statements are just special syntax on top of lower-level constructs like keyword lists.)
Modules and functions
Okay, like in Rust, modules are named in code (with
defmodule) rather than named implicitly by whatever the containing file is called. I think I like that it’s explicit.
I don’t think I’ve seen private functions specified by changing the function definition keyword (
defp in this case). Usually what I’ve seen is a separate keyword (
private) or private-by-default (Rust) or capitalization change (Go) or mere convention with underscores (Python). Cool.
Ooh, guards on function definitions. I like this. Function overloading++. (Har har.) I know you can get the same behavior with conditional statements in a single function body, and that’s probably less verbose, but still. This seems easier to reason about.
Function capturing is interesting. I guess it’s needed because the parentheses in function calls are optional.
Default arguments with
\\. Huh. Moving things up to a function head if there’s more than one default argument is also interesting. Brings back the old C/C++ days with header files.
Guards on function definitions: great for recursion. I like being able to separate out the base/termination case like that.
I think multiple function clauses might be clearer than
Enum.reduce for writing reduce algorithms. (Though I do like having the function at the end with
Enumerables and streams
The famed pipe operator at last! Looking forward to using it in practice, since it does seem like it makes chains of function calls easier to understand.
Streams look nice.
Okay, so these are kind of like lightweight threads, similar to goroutines in Go. That makes more sense (referencing my questions in the last post). I like the
receive syntax a bit more than Go’s channel syntax, too.
after timeout! I really like that that’s built in.
The docs on linked processes make it sound like you build your own supervisors in Elixir, which sounds amazing. Can’t wait to learn more about that. (I’ve always used external processes like
This bit about sending messages to and from processes being the normal way to maintain application state? That’s really intriguing — something I haven’t really seen before. (At least not from the perspective of being built in to the language.) Looking forward to seeing what this looks like in practice.
IO and the file system
The names of
File.rm_rf/1 make me irrationally happy. Especially given the danger of the latter. Ha.
Oh interesting, files are processes under the hood. Beginning to suspect this may be an everything-is-a-process type language. Which is new to me and very interesting.
Okay, we’ll stop there for now. Halfway through the introduction!
Reply via email or office hours