lol, ya! It’s actually someone pointing out on this forum a few years ago that {:ok, response} is a monad is what made me finally understand wtf a monad is. I had a decent, most-of-the-way understanding already, but it never quite clicked. I said this recently but I really see Elixir as “elegant yet scrappy” and I love that about it. I am also a big fan of convention and really dislike codebases that are a mish-mash of styles. I have a love/hate relationship with reading code and and dealing with a frustrating bug is not when I want to be met with someone’s creative coding around a straightforward problem.
@dorgan there is actually a lot to respond to there since you touch on a few things I find myself thinking about a lot.
Warning: Lots of stream-of-consciousness word vomit ahead… please feel free to skip 
The easiest to address it that my only problem with with as it is how the formatter handles it. I wish it would let you just put the do on its own line! It’s literally the only thing about the formatter I really dislike.
Otherwise, the whole “extracting private functions” thing has been on my mind a lot recently. I feel that a lot of people coming to Elixir from OO, particularly Ruby, have been burned by the gross overuse of single-use private functions. I feels that many have the perfectly common human response to revolt by going too much the other direction. I try and just extract private functions when the meaning starts to get muddled. I’ve never actually thought too much about how they will get used by other functions in the module and honestly, this is because I don’t much experience working alongside other Elixir developers (only about 8 months-worth). What I’m getting at is that I really only use with with library functions that have consistent return types or each step is itself a significant local function (or in another module that I own). If I can’t do that I just don’t use with, although I don’t have any good examples of what that looks like.
Otherwise, I do think it’s great to be able to mold the language around so people can experiment with new ideas. But for me, it’s not really about big names it’s more whether or not it will ever make it into the language that I would continue to use it. It’s funny you mention the transact thread because I’ve been following along and, even though Ecto is a library itself and I do find Ecto.Multi a bit clunky at times, it’s so ubiquitous that I’d have a hard time adopting transact in my own projects. I also actually found myself needing to compose multis in a recent project which was my immediate question when first reading that thread and it got answered without my asking 
In any event, maybe it’s a little closed-minded of me but I like to keep dependencies lean and I’d much rather pull in libraries that are solving the tough application problems I don’t want to deal with.
One thing I am very interested in is using macros to mold the language into a DSL for your business domain. From what I understand this was one of the original ideas behind LISP that has never caught on (and I do think I understand why). To me that would be well worth coming onto a project and learning. But when teams pull in libraries just to make something “a little more like other functional languages” I find it a bit annoying. It means I’m going to get used to random little things and then probably miss them when they are gone, ha. As I said earlier, I really love the scrappy side of Elixir and that a lot of stuff is left up to convention.
