Sure, but I had exactly zero situations in my Elixir career – 7 years now – where in app code I had to write separate non-raising and raising function variants. I view this idea as a strictly library practice.
Absolutely, I agree. Some people are not happy that this is not obvious but work with the language and the ecosystem for a bit of time and it starts to become natural..
Agreed on that, honestly I’d rather explicitly match on {:ok, value} and have that raise if it returns anything else, than write a ! version too. Using a ! function may be helpful in pipes but “escaping the monad” can be either dangerous, or lead to code that’s hard to refactor when you actually need to handle the error case but all the code depending on that line of code assumes it always succeeds…
I like how Rust makes that smelly by forcing you to .unwrap it
I might be misunderstanding the OP, but it seems like a case for with statements to me.
I’ll steal an example from this blog post:
with true <- is_email_address?(email),
true <- String.length(code) === 6,
%EmailConfirmation{} <- EmailConfirmations.get_email_confirmation(email),
nil <- EmailAddresses.get_email_address(email),
{:ok, user} <- Users.create_user(data),
{:ok, email_address} <- EmailAddresses.create_email_address(user, email) do
...
end
The example glosses over the else statement for when the condition is not met, but I think it still serves.
I’m leaving it but I just realized how terrible the wording is in the statement “a case for with statements”; very confusing in this context. Sorry.
That’s how it should be, we the programmers love to discuss these things to death but in the end you arrive at your app’s user-facing code and you have to make sure you have covered for everything AND make sure to send logging and/or APM events to your appropriate systems if something is not (quite) right.
So I usually write most of the internal code in quite a lax manner and then do more exhaustive pattern matching in my highest level app code because there you can’t allow any slack. Users don’t want to see “app crashed” page, they want to see “this did not work, please try again shortly” and you want to receive a notification in the meantime.
Yes, and this is HUGE. Rust forces you to mark this explicitly which helps a ton with static analysis tools AND allows you to grep for it and tighten the bolts down the road. A lot of people that work predominantly with dynamic languages can’t quite appreciate how important such aspects are before they dive deeper in the static strongly typed / native-code-compiled languages. I miss this every time I write Elixir.
Absolutely, I was just talking in terms of something like that making it into the language. I have also never written a custom ! function unless it’s calling a library ! function (like, Blog.get_post!). I personally always prefer ? return a boolean but I’m certainly not going to try and police teams I’m not on 
I only quickly read the docs for Rust’s and_then but isn’t that a situation where you would want with in Elixir? I think what this thread is talking about is conditionally adding to a data structure or returning it untouched. Though I may have lost the plot a bit 
Elixir’s with – and this is also aimed at @stevensonmt’s most recent comment from a few minutes ago – suffers from lack of expressivity. Here’s how I’d rewrite his with block:
with {:check_email, true} <- is_email_address?(email),
{:check_code_length, true} <- String.length(code) === 6,
{:get_email_confirmation, %EmailConfirmation{}} <- EmailConfirmations.get_email_confirmation(email),
{:email_confirmation_should_not_exist, nil} <- EmailAddresses.get_email_address(email),
{:create_user, user} <- Users.create_user(data),
{:create_email_address, email_address} <- EmailAddresses.create_email_address(user, email) do
...
end
…because in the else block you can have a better idea what’s wrong i.e. you can pattern-match on {:check_email, false} and know exactly which step failed.
The code above is looking very much like an Ecto.Multi chain and ironically enough, I started using Ecto.Multi instead of with in no small amount of cases just for this reason. But IMO it does give you a better code readability.
To answer your question, code comprised of chains of and_then is more expressive and more readable than Elixir’s classic with usages.
This gets back to context mattering here. In your with example that is definitely better suited to a Multi! I use with generally when each stage has the same return value, mostly :ok/:error tuples, then you don’t have to care exactly which one failed. I like with when doing side effects where the database isn’t involved.
I do get that with is sort of a hacky do notion or the like, and isn’t the prettiest (I wish the formatter would let me put the do on its own line but I’m over it), but I prefer when I can see a with and know “this is a procedure where something can go wrong” and see a pipeline and think “this is just a series of immutable data transformations”.
I just have PTSD of working with someone who insisted everything be a pipeline.
Not familiar enough with Ecto but will absolutely be looking at that in the future.
With respect to with statements though, I would argue that your rewrite of the example is exactly what makes them so great. You can make them as expressive as you like. I particularly like that they allow you to handle the happy path in one chain but you can handle multiple unhappy paths in the same place. It’s like instead of having Option::Some(res) | Option::None or Result::Ok(res) | Result::Err(err) you have a de facto return type of
Happy(ness)
| NotAnEmail(res)
| WrongCodeLen(res)
| NotConfirmed(res)
| FailedCreateUser(res)
| FailedCreateEmail(res)
While this is factually correct, I’ve seen such real-world scenarios extremely rarely. Most of the time with is used when you want a pipeline of transformations and/or side effects, yes, but very often you do want to know what failed. After all, if your 7-step with pipe keeps failing at step 3 wouldn’t you the app dev want to know why?
Zealotry and pyramid hierarchy are a sad fact of life of our profession. I’ve successfully challenged and changed the minds of CTOs and VPs of Engineering but it was a rarity, most people default to ego or traumatic past experiences and will ride that until the heat death of the Universe to justify what they do.
Oh yes, I agree. Maybe I had bad luck with employers and customers (I was just taking every job and not insisting on culture fit is more accurate) but almost no team I was a part of used the more expressive with syntax, for reasons I can’t explain because they regularly had problems with part of the chain failing and them having no idea which exactly. I rewrote their with pattern-matching arms and added more clauses to else which led to us discovering the bug literally 10 minutes after deployment. And they were legitimately surprised.
…WTF, right. I think some of these practical programing-for-money practices should be put more front and center in some of Elixir’s educational material.
I love the example and yes you’re right. I’ve personally made exactly such Rust enums because we really wanted to send an APM event knowing what went wrong (we worked with a company’s 3rd party API which was super unstable and was sometimes spitting out wrong type of data).