This has proven controversial, but sometimes the Else behavior is very sensitive to which of the With expressions failed (especially for better logging) and I maintain that the least terrible approach involves augmenting the With clauses using atoms to identify each expression when it fails, ex:

For example:

    with {_, {:ok, key} } <- {:phase_key,    get_key()         },
         {_, {:ok, door}} <- {:phase_unlock, unlock(door)      },
         {_, %Thingy{}  } <- {:phase_thingy, fetch_thingy(door)},
         {_, %Widget{}  } <- {:phase_widget, fetch_widget(door)} do
    else
         {:phase_key,    {:error, _msg} = err} -> # I can tell the key was missing, rather than the lock broke
         {:phase_unlock, {:error, _msg} = err} -> # I can tell the lock broke, rather than missing a key
         {:phase_thingy, nil                 } -> # I can tell this nil value is a missing thingy, not a widget
         {:phase_widget, nil                 } -> # I can tell this nil value is a missing widget, not a thingy
    end

Pre-buttals:

"Just rewrite those 4 functions to return better somehow" -> No, that's not always practical or even possible. In the above example, the signatures of some of these functions are already perfectly fine on their own. The ambiguity comes when they get used near others in different ways, and trying to assign globally unique features to match on is a bad idea.

"Create 4 private functions to wrap things" -> Ugh, now the person reading the code has an even harder time, since they need to refer to functions elsewhere in the file, any of which might be hiding unexpected bonus behavior. Those 4 private functions might not even be useful in other with-statements in the same module, causing you to make even more private functions... and all of it still falls apart the moment your Else logging/cleanup needs to record or revert something from a prior (successful) step.

There are some third-party libraries to make working with these a little easier, but it never sat right with me. Probably being so close to the BEAM means we cannot stray very far from what Erlang is doing, but errors would be much nicer to handle with monads.

That said, pattern matching alleviates a lot of pain in many cases. If you have a pipeline of fallible steps, you can do:

    def step1({:ok, data}), do: ...
    def step1(:error), do: :error

    def step2({:ok, data), do: ...
    def step2(:error), do: :error

    etc.

In general, whenever I feel the need to differentiate errors to handle them separately like your example, with a little refactor I can usually simplify the `with` expression and avoid having to do all that ceremony.

To be honest I would prefer a return keyword and using early returns as in practice I'm not a fan of "the last statement is the return".

For non-Elixir folks, imagine something that looks like a regular function-call where expressions are evaluated and the results are passed in... but in reality all arguments are symbolic inputs to something that emits new code.

For example, you might see this unassuming line in your editor:

    describe_combo(a(foo),b(bar))

    # What might actually get compiled
    # Runtime results like "a(1)+b(2)=3"
    "a(" <> to_string(foo) <> ")+b(" <> to_string(bar) <> ")=" to_string(a(foo)+b(bar))

    foo = "haha I changed your local variable"
    IO.puts("surprise, suckers") # Prints to console
    kick_puppies()

There is also a guide on meta-programming anti patterns: https://hexdocs.pm/elixir/macro-anti-patterns.html (and unnecessary use is one of them).

Instead, I'm stuck writing applications in Go which is a language I absolutely despise but can't deny it's ability to get shit done regardless of the insane amount of boilerplate code I have to write.

Any predictions on whether Elixir will eventually gain more traction? The language and platform are rock solid and it's the best developer experience I've encountered. Phoenix is by far my favorite web framework and just feels very intuitive and complete. The lack of a good IDE is one huge pain point that I can't seem to overcome (I don't care how much people praise it, I know it's the best but VSCode is awful for Elixir development).

I just wish this language was more popular because it deserves to be!

That usually means using similar technologies, or otherwise popular, and well backed technologies. Go has that in abundance over Elixir.

For any personal project I'd take Elixir the vast majority of the time.

But I would argue the decision to adopt Elixir isn't really as simple as a "this language" or "that language". The most essential decision, I would suggest, is about Erlang... not so much the language as much as the virtual machine and OTP. If the problem you want to solve is well solved by the BEAM/OTP, then you start to look at the languages you might use with the BEAM/OTP. I think BEAM/OTP is underappreciated for many use cases and that are worth exploring; this broadens if you consider BEAM/OTP augmented with more performant programs built with a language like Rust/Zig/C/C++.

But if everyone plays the conservative game and doesn't see the risk/reward payoff with BEAM/OTP favorably... then it will be the same old boring players with only the ocassional influence from the sidelines.

I have 10 years with the language this year, much of it as a professional fulltime focus in senior IC roles.

I would be shocked to my toes if there was ever going to be even 10 times more active Elixir devs than there are today, let alone more extreme growth. And I think that hypothetical plateau is an appropriate outcome commensurate with its ecosystem's breadth, applicability and quality today.

Many libraries have single or absentee authors, even some you would assume were critical to the community, and major vendors in many verticals don't give us any thought when providing SDKs/integrations. Elixir seemingly doesn't have any major backing or adoption from large polyglot orgs or top FortuneN groups. We have failed to reach critical mass for broad mindshare, IMO.

I have no personal plans to write net-new Elixir that I wasn't explicitly hired to work on in that specific stack.

BEAM has been around for decades and has proven its worth. Elixir has been around for quite some time too, is super stable and reliable, has a pretty decent user base, real-world applications, ecosystem, etc. In many cases, it's arguably the best tool for the job. And it's not like some critical piece of puzzle is missing.

So it may stay kinda niche forever because people who fully understand the problem and fully realize how to solve it will also always be niche.

I don’t know about Elixir, but Gleam looks promising. Even less IDE support than Elixir right now though.

They’re different enough languages that it’s really difficult to just open up an elixir codebase and try to read it. Elixir, like ruby, has a lot of syntactic sugar that just won’t make sense if you approach it with a Python mindset. Elixir is also functional, which can be a pretty big mind bender.

It’s really a language that you need to start from the basics and go through the tutorials to learn the basic syntax, operators, etc and write your own small programs. If you’re like me, you’ll just end up discouraged if you expect to be able to learn Elixir just by reading existing code.

With that said, I do think because the syntax being familiar for Pythonistas and Rubyists that there’s an assumption it works like those languages and runtimes. It does not. It’s a functional language, in a purely functional VM, and that causes a lot of grief to newcomers. There are many assumptions folks bring with them that don’t hold. I think you have to take a step back when you come to a functional language with an OOP background otherwise it’ll be painful.

I’d encourage you to just write it for a while and avoid things like GenServers. Get a feel for just writing functional (pun?) code. Id also suggest to avoid reading code by people new to Elixir as it’s often weird, or irregular, because they lack the experience to write things idiomatically; relying too much on OOP principles.

As an example, in Ruby you strive to write functions less than six lines (in general)— in Elixir this can be an antipattern. Because breaking up the function will unnecessarily abstract and muddle what’s going on. That in large part is driven by the fact there are no side effects; I can see everything that is going on. Whereas with Ruby side effects and meta programming are prolific, making the code extremely dense. Writing a method that’s 20-30 lines in Ruby almost guarantees it’s violating the single responsibility principle.

The one thing that did trip me up when starting elixir, that I now love, was shadowing variables. It makes things look like they’re being mutated but they absolutely are not. It’s just reusing the same name, not the same value.

1. The syntax is significantly different than what one may be used to. Fair enough. 2. The paradigm itself is different and thus requires you to learn way of structuring your code in some pretty fundamental ways. This is a much bigger deal than one may initially give it credit for. For example, pattern matching. The mere possibility of defining multiple versions of the same functions based on the number and kind of arguments completely changes how one writes functions.

Instead of:

function hello(x) {

if (x == 2) {

// do x

} else {

// do y

}

}

We can write:

def hello(2) do

# do x

end

def hello(_) do

# do y

end

This was very disruptive to my brain at first as I was not used to reading code in this manner. My brain said "find function, read definition" but it had to learn "find function with proper arity and arguments, read definition". It's hard to put into words, but this made understanding Elixir code feel more difficult at first. However, once I did sink my teeth in , start to maneuver around code bases, and write my own modules it is hard for me to "unsee it" and go back to anything else. I love it! I think the most mind-blowing moment was when I started to pull back the covers in Phoenix and discovered that the framework wasn't some magical black box of FancilyNamedProviders but was just a collection of functions that I could actually read my way through quite simply. I never had to stop and say "wait what did that FacadeOfGoodness do again" but just traced simple functions.

No, it's the same for everyone: unfamiliar things seem "wrong" until you internalize them.

Try working in Elixir for half a year - you'll see that the syntax you now find verbose is that way for a bunch of reasons, and you'll find that you have no problems at all reading Elixir code, including in big projects.

The problem is that confronting the unfamiliar doesn't feel nice for most people and that you can't really speed up the process. On the flip side, though, half a year of weekends is not that long of a time or significant an investment. Especially since you'll get quite a few generally helpful skills out of it (working with actors, for example).

That said, I don't think it's as easy to read as Python, but the perceived verbosity and reading difficulty definitely goes down with familiarity.

Part of the verbosity is because Elixir is kind of a simple language (if you disregard the OTP stuff) and doesn't have a lot of sugar - ultimately it's just functions. Whatever else sugar is there is to nudge you towards a somewhat opinionated aesthete. In this specific regard, it's not unlike Go or Smalltalk (even if in any other way they are very different otherwise). I think the stylistic variance in how different people write Elixir is pretty low compared to how people write Perl/PHP/Ruby/Python, which is probably why reading difficulty quickly goes down with some familiarity.

Other part of verbosity is probably because culturally Elixir is kind of explicit. For example Phoenix is very convention heavy, but it's still low on framework magic. It's cool that Elixir (and Julia) has macros and that's good for library and framework authors to contain verbosity without sacrificing much of the explicitness. But as an application developer I very rarely need to reach for them either? Perhaps that's due to simplicity of language and synergy between data structure and standard library.

Though based on usage there are probably some areas where I would have preferred more sugar. For example, you just end up doing a lot of deconstructing/pattern-matching Maps. Every time I do `%{var1: var1, var2: var2} = map` I wonder if it would really be bad to have `{var1, var2} = map` like Javascript? It's not a very big deal though.

Also not to be a naysayer, there is a chance that the good feeling people have about Elixir is because they basically use it in the problem domain where the language and the runtime (and Actor Model) is an exceptionally good fit for. I mean web and network stuff is already large part of what people do, so that's not much of a con? Nevertheless would I pick Elixir for my next GUI or CLI program? I doubt it.