Personally the lack of return keyword is not in the pro column 
It’s not only about early returns, I just think it has better readability, especially when reading/interacting with code you didn’t write.
I find reviewing PRs in Elixir harder than other languages for example.
But I prefer to use the idiomatic way of the language to do it rather than use throw or other clever tricks to simulate it.
What? Compared to what language? I have to review code in OOP languages and it is just horrible. A class that inherits from a generic class, that implements some kind of logic and some interfaces.
In elixir you have functions that return some data, of course if the function is 300+ lines I can see how it can get hard very fast.
That usually means the functions are too big. Address that and it gets significantly easier.
I disagree with this. I think it’s much less readable having to scan a function/method for return which could occur at any position or even in multiple positions or not at all (at least in Rust). With Elixir you can just start at the bottom and boom, you know what the return should be. Even in a more complex case where the last expression is a conditional of some form you still only have to look through that conditional expression and not worry about the things that came before it. Of course if you’re nesting conditionals 5 deep this is unreadable but that’s not fixable with early returns.
Early returns fixes it for me in a lot of cases… 
This discussion has been helpful to me, even if I don’t agree with a lot of y’all. I think what I’m realizing is that I don’t like having lots of small functions, which seems to be the answer to early returns.
I’m curious what you mean by “fixes” because I think we are thinking about different issues. I think you mean early returns allow you to avoid nesting conditionals, but I just meant that sprinkling returns throughout the conditional branches does not improve readability. I recognize readability is totally subjective so maybe that is where we differ.
Yes, that’s what I meant. It reduces the nesting and makes it more readable to me.
Also to recap, I don’t want to use early returns pervasively. As most people, I typically reach for with or even nested case statements (and my tolerance for nesting is probably higher than most here).
But in some cases, I think it helps a lot. In our pretty large codebase, I found only two instances where I found early returns compelling. But imo, it made a big difference in these two cases.
defmodule Utils do
def check(condition, error \\ :failed_check) do
if condition, do: :ok, else: {:error, error}
end
end
import Utils
with :ok <- check(foo > 42),
:ok <- check(velocity.x < 27, :too_fast) do
profit!()
end
(?)
Edit: I don’t personally do this but I do have the muscle memory of writing “checks” to make it easier to use with and not have to “tag” the steps
As with anything it’s not always the most ergonomic way and compromises are made
It’s really interesting how widely varied the stylistic choices one person might like versus another are. I would find that sort of check style much worse than tagging the steps of a with clause. I actually kind of love the pattern of
with {:ok, foo} <- some_foo_stuff(),
{:ok, bar} <- some_bar_stuff(foo),
profit!(bar)
else
{:foo_error, error} -> handle_foo_error(error)
{:bar_error, error} -> handle_bar_error(error)
_ -> just_blow_it_up_but_be_nice_about_it()
end
One thing about the particular snippet I posted is that the hypothetic check function wraps a conditional, to avoid ad hoc patterns like this:
with {:foo, true} <- {:foo, foo > 42},
more_steps_here do
profit!()
else,
{:foo, false} -> ...
end
so instead you’d do this:
with :ok <- check(foo > 42, :too_low),
more_steps_here do
profit!()
else
{:error, :too_low} -> ...
end
Your snippet assumes you already wrote functions that play nicely with with, while mine is more about the ad-hoc use cases, like checking for a bunch of predicates that are so mundane extracting them too functions would just add lots of verbosity and noise for the sake of using with
Related, I don’t particularly like having a specific tag like :foo_error instead of just :error with a more descriptive value because it makes it harder to write helpers that can just assume a normalized ok/error tuple. This is one thing I do find useful about ADTs like some people mentioned early, if you can assume normalized shapes, it’s easier to write composable functions.