
I can't keep up with idiomatic Rust - ddevault
https://timidger.github.io/posts/i-cant-keep-up-with-idiomatic-rust/
======
pornel
Rust seems to change constantly, because _it 's changing so slowly_. The 1.0
release has held back a lot of stuff to avoid stabilizing wrong things, and
it's now slowly backfilling the missing features bit by bit.

Instead of starting with a fat standard library, it started with minimal one
and now each release adds 2-3 functions that could have been there in 2015.
But none of it is idiom-changing revolution. These are mostly convenience
functions, and you don't have to use them all just because they're there.

Every addition to the language is bikeshedded to death, goes through betas,
revisions, refinements, before being stabilized _years later_. The first
experimental release of async was _4 years ago_ and it has landed last
November. So you may hear about new features a lot and they churn in
nightlies, but actual big changes reach stable rarely.

Apart from async/await, since 2015 Rust made only 2 changes to how idiomatic
code looks like (? for errors, and 2018 modules), and both of them can be
applied to code automatically. I maintain over 60 Rust crates, some of them as
old as Rust itself. All work fine as they are, and running `cargo fix` once
was enough to keep them looking idiomatic.

~~~
twic
> it's now slowly backfilling the missing features bit by bit

This isn't slow.

Java went three years, from December 1998 to February 2002, without any
language changes. And to be honest, even that wasn't that slow!

> Every addition to the language is bikeshedded to death

Not to death, because many of them don't die!

What i find annoying about Rust's changes is that some of them are so trivial
- they change the language for such small improvements. async/await is not in
that category, for sure. But Ok-wrapping actually is. The need to Ok-wrap
results is a minor annoyance at most. Ditto a bunch of the problems solved by
match ergonomics changes.

I think the root of the problem is that the changes are driven by a small core
of Rust programmers - many working on Rust itself or some of its flagship
projects - who are actively involved in the discussions around Rust. They tend
to view change as natural, and the cost of change as low. I believe there is a
larger group of Rust programmers who are not actively involved in these
discussions, and are maybe not spending 100% of their time on Rust, for who
the cost is higher. But we don't hear as much from them.

~~~
sgift
> What i find annoying about Rust's changes is that some of them are so
> trivial - they change the language for such small improvements. async/await
> is not in that category, for sure. But Ok-wrapping actually is. The need to
> Ok-wrap results is a minor annoyance at most. Ditto a bunch of the problems
> solved by match ergonomics changes.

So what? Then don't use them. The whole point of full backward compatibility
is that you don't have to use new features. This perceived need to always use
the newest feature is only in the head of some developers.

Neither in the blog post nor here do I see any reason to not make the
experience better for people who want it. Even if it's just a "minor" (very
subjective, I love the match ergonomics enhancements) annoyance that's fixed
by it.

~~~
karatestomp
You still have to understand all the new stuff to read other people’s code.
And the old way, so you can read older code. And if there are other ways to do
something that are or have recently been in common use, those too. You end up
memorizing a bunch of crap for one actual operation.

~~~
jrochkind1
Yep.

I think ruby (which in general I still love) has become a major offender of
this. "If you don't like it don't use it" is not a good answer for exactly the
reasons you explain.

~~~
sgift
I sense a goalpost moving here. The point of the blog post to which I answered
to was: I have to redo all my programs to follow the "idiomatic" way.

Now we are at "other programmers could use new features, so I still have to
learn them". And yes, that is true. And that will always be true as long as a
language has new releases. Even if all those releases were library changes and
not syntax changes/additions. The only way to stop this would be to stop all
language development.

~~~
setr
Even worse would be if someone pulled in a library... That requires much more
cognitive load and doc-reading than something like try! -> ?

Or the worst of all possible worlds -- pulling in a macro-based framework

------
ekidd
I spent today updating some production Rust code from 2016. This was a partly
automated process thanks to 'cargo fix'.

Some thoughts:

1\. Most of the superficial changes, like 'dyn' and Rust 2018, are easily
handled using automatic tools.

2\. The original Rust 'Error' trait was clunky, and it lacked useful features
like backtrace support. This led to a series of experiments and fads in error
handling (e.g., error-chain, failure), which are only starting to calm down
after recent enhancements to 'Error'. More conservative Rust users avoided
this by sticking with 'Error' and living with the limitations.

3\. Updating depencies has been surprisingly easy, with several notable
exceptions. Very early adopters of 'tokio' 0.1 had a fair bit of work to do
once 'async' stabilized. And OpenSSL has been a constant thorn in my side,
despite being a native C dependency.

One handy tip: Don't force yourself to constantly update your code to use all
the latest features. Not everything needs to be async. And it's OK to have
some rarely-touched modules that are written like it's 2015.

~~~
d1plo1d
As someone newer to Rust who has been using error-chain because it was what I
found at the time I'd be curious to hear what your preferred solution to
errors in modern rust is.

~~~
steveklabnik
[https://blog.yoshuawuyts.com/error-handling-
survey/](https://blog.yoshuawuyts.com/error-handling-survey/) is a good
summary of what's out there.

I think current rough consensus is anyhow/thiserr depending on if you're
writing an application or library. I haven't actually used them myself,
though. You don't _have_ to keep up with the cool new libraries.

~~~
matklad
Agree that there’s consensus on anyhow for applications, but I think many
folks now prefer vanilla std::error::Error for libraries (which itself got
better as a result of all the experiments in the ecosystem).

~~~
littlestymaar
The good thing with _this_error_ is that it's just a custom derive on vanilla
std::error::Error.

~~~
Arnavion
I used to maintain a custom derive crate for errors before failure came out,
but these days I just use manual impls of `std::error::Error` for libraries
and `Box<dyn std::error::Error>` for applications. I can't be bothered to keep
up with the Rust error-library-du-jour game, even if it so happens that
today's darling custom derive (thiserror) would emit the same
`std::error::Error` impl that I write by hand.

Manual impls may be tedious to write, but they change rarely after they've
been written, enough that the con of adding one more dependency that may go
away tomorrow outweighs the con of writing them manually.

~~~
jfkebwjsbx
This matches my experience as well. I want to write code that works for years
(dependencies make this hard) and is understood by everyone. So explicit is
best.

------
roca
I feel that the changes to date haven't been that significant. Adding `dyn`
was almost completely automated, removing the need for `extern crate` was
welcome and very easy to apply, likewise `try!()` to `?`. The changes to
futures were a bit of a pain but futures were always known to be in flux.
`impl Trait` is useful but failing to use it where you could is not ugly
enough to irritate.

There are some upcoming improvements --- that I'd like to see! --- that are
bigger and thus may be more challenging:

\-- Better `const fn` will make many existing `lazy_static`s become
unidiomatic. Worth it, but annoying.

\-- Const generics will make a lot of existing code non-idiomatic. Again, well
worth it, but annoying.

\-- Generic Associated Types ... probably similar.

The question is, if people decided those important features don't belong in
Rust because they would cause too much churn in code that wants to be
idiomatic ... then what? That would almost guarantee a new language ---
perhaps a fork of Rust, perhaps not --- would eventually fill that niche.
Wouldn't everyone be better off if that language was Rust itself, and people
who don't want to write that "modern code" ... don't?

~~~
CJefferson
async is huge, and I'm worried about future similar changes.

Suddenly "x.y" means member access.. except for x.await, which has a magic
different meaning I still don't really understand. And adding 'await' to a
function declaration magicly mangles it in various ways.

~~~
roca
Honestly I haven't found those things to be problems at all. ".await" really
isn't confusing. I think you meant "adding 'async'" to a function declaration
--- it seems fine, but I personally don't use it.

~~~
CJefferson
The .await is another thing one needs to teach, and fairly early on so that
people reading code examples don't get confused by where the "await" member of
structures are. It just seems like a really bizarre break in what was fairly
clean notation.

~~~
majewsky
For me, it helps that ".await" appears as a keyword because of syntax
highlighting. It _is_ an odd syntax, but the alternative way of making await a
prefix operator instead of a postfix operator would have been way worse for
readability. Compare

    
    
      let bar = list_foos().await.first().list_bars().await.first();
    

vs.

    
    
      let bar = (await (await list_foos()).first().list_bars()).first();

------
gautamcgoel
This a key difference between the Go community and the Rust community. Go is
like C 2.0: it tries to be minimal and stable. Go usually ships with no
language changes between releases. Rust is like C++ 2.0: it is constantly
being revised and expanded, supposedly to improve power, performance, and
ergonomics. When a new version of Rust is released, the core Rust devs write a
blog post gleefully explaining all the new "features" the current version has.
What these devs perhaps fail to appreciate is that not having new features can
itself be a feature.

~~~
Skunkleton
IMO Go is more like C people took a stab at making a Java. I really like go,
and it’s ethos, even if I haven’t used it much in production. Go is not
however a replacement for C in the way C++ and Rust can be. Of course Rust and
C++ aren't a replacement for C in some key ways, so maybe I don't have a point
here?

~~~
tmh88j
>IMO Go is more like C people took a stab at making a Java.

I haven't used Go beyond tutorials and some very basic programs, but I am
pretty comfortable with Java. What about Go makes you feel it's relatable to
Java? From what I've read the lack of generics is a hot topic in the Go
community, but they're pretty crucial to most programs written in Java. Is
this still true?

~~~
correct_horse
As a side note, Java also didn't ship with generics. Java was released in the
mid 90s and didn't have generics until about 10 years later with version 5.
This timing should feel familiar - Go first appeared ~10 years ago in 2009.

You may remember that in Java 1.4, `get`ting from collections (e.g. ArrayList)
always returned Object, which you were expected to cast to their runtime type
(or a class that their runtime type inherits from). I was young at the time,
correct me if I'm wrong. Contrast this with Go's solution, which seems to be
user-inaccessible compiler magic. I much prefer Go's solution to Java's, but I
also like generics.

~~~
saagarjha
I _really_ hate user-inaccessible compiler magic. Java had its fair share of
that, but Go seems to take it even further :(

~~~
Skunkleton
I think compiler magic is pretty great. Hotspot is a pretty magical compiler.
Go is less magical IMO because it is AOT compiled.

~~~
saagarjha
By compiler magic I really mean syntax reserved to the language itself; for
example, Java's String having extra operator superpowers or Go's generics that
are only available to a chosen set of standard collections.

------
cies
> The .await war was the final straw [...]

Interesting. I witnessed a constructive collaboration by which the Rust
community chose (mainly) the syntax for it's async features. I thought of it
as amazing, thoughtful, rather democratic and on point. Nothing war-like to
me.

~~~
GolDDranks
To be honest, reading mainly blog posts, RFCs and summarisation comments, it
did look like a thoughtful and organised process. However, there has been a
constant problem of tiresome work and "intellectual and emotional labour" of
reading thousands pieces of feedback, some of which are emotionally charged,
and many of which are duplicates or re-statements of similar ideas, and many
of which have misunderstanding or mis-valuations of other ideas. I've heard
that collecting and editing this huge amount of unstructured feedback into
comprehensive and balanced summaries has been a huge drain of mental energy
for the participants.

~~~
saghm
I wasn't involved at all in the discussion, but having dove deep into async
over the past few months since async/await was stabilized, I definitely am
happy with the result of that process. Writing code with postfix `.await`
feels very natural to me and it fits it much better with the surrounding code
I write than a prefix version would. I can sympathize that participating in
that process might not have been fun, but I really hope that the results of
future discussions make me as happy as this one has.

~~~
lightgreen
> Writing code with postfix `.await` feels very natural to me and it fits it
> much better with the surrounding code I write than a prefix version would.

That’s your subjective point of view, not everyone agrees with it. Part of the
problem is that Rust team failed to find a solution good enough for the most
people and failed to communicate this decision. In particular the switch to
.await syntax happened just couple weeks before it was finally stabilized.

And await is not the only controversial decision made by the Rust team.

Even if 10% of people unhappy that’s too much, because the next controversial
feature will cause 10% more of unhappy people and so on.

I hope they will do better next time.

~~~
sagichmal
> Even if 10% of people unhappy that’s too much

You realize this is an impossible standard, right? Literally impossible.

~~~
lightgreen
I might be wrong but for C++ for example every C++ fan seems to happy about
every new release (at least happy with new features, not lack of desired new
features).

Same for Java, IIRC the only controversial decision they made was the
introduction of modules.

Python 3 was a mistake, but generally Python users are happy with Python
changes.

10% is not impossible. Even if this decision is ”right”, communication could
be better: more options to play with different syntaxes, more time to get used
to new syntax before stabilizing are just two possible ways to deal with the
angry mob.

~~~
peteretep
How often is C++ adding features of that size though?

~~~
jcranmer
Major new features of this size in C++11 are lambdas, variadic templates,
auto, and move references. C++14 adds generic lambdas. C++17 adds constexpr if
and structured bindings. C++20 adds concepts, coroutines, and modules.

------
kens
> I need to now change my code in order to keep it idiomatic

I'm not a Rust person so maybe I'm missing something, but why does the OP need
to keep the code idiomatic? Can't the changing fashions in what's idiomatic be
ignored?

~~~
davidcuddeback
> _Can 't the changing fashions in what's idiomatic be ignored?_

They absolutely can, but you might be stuck on an older "edition" of Rust.
I've stuck with `try!()` for error-handling, because I think error-handling
deserves more prominence than a single character. But that means my code is
stuck on Rust 2015. If something I need is added to Rust 2018 or a later
edition, I'll be forced to update or backport.

~~~
Izkata
> But that means my code is stuck on Rust 2015.

...can't you upgrade and choose not to make that change? Did something happen
to make that not compile?

(not a Rust user)

~~~
davidcuddeback
> _Did something happen to make that not compile?_

`try` became a reserved keyword in Rust 2018 and the `try!()` macro was
dropped (edit: not dropped, see @boardwaalk's comment). I could copy the old
macro to all of my code bases and give it a new name. The two things stopping
me from doing that are (1) I don't have any reason to update to Rust 2018, and
(2) I can't think of a good name for a replacement macro. I'm thinking
`check!()`, but not sold on the name.

> _(not a Rust user)_

One thing to know about Rust 2015 vs 2018 vs future "editions" is that they're
a distinct versioning mechanism from Rust 1.23, 1.24, etc. The latest version
of the Rust compiler still supports Rust 2015 and I believe it's been promised
to be supported in perpetuity. So it's not like I run a risk of being without
a Rust 2015 compiler available.

~~~
majewsky
> I can't think of a good name for a replacement macro

What about do_or_do_not!(). After all, there is no try!(). ;)

~~~
davidcuddeback
Heh. That's the argument that was made against using Rails' `try()` method at
my last place of work. Made me laugh. Thanks. :)

------
_bxg1
I'm getting seriously concerned about feature-creep in Rust. I understand that
there was an initial period of rapid growth as the community figured out what
was needed, and that some of Rust's syntax sugar makes a very real difference
in productivity.

But Rust is already not a simple language. It already has long compile times,
and some of its syntax sugar already makes it harder to understand what's
really going on when you invoke it. I think it's important that the Rust
community start reeling in frivolous sugar, otherwise it may just become C++
all over again.

~~~
Ar-Curunir
Can you name some examples of "frivolous sugar"? Also compile times have been
a big focus of the compiler team, and have been going down YoY.

~~~
_bxg1
> Can you name some examples of "frivolous sugar"?

The one mentioned in the article seemed fairly frivolous to me. I don't know
if I can name one that's already been accepted into the language which I would
call _frivolous_ , per se, though they're all varying degrees of necessary.
But most of the "sugar" syntaxes have made the language harder to understand
for newcomers, even the ones that are arguably necessary. They all come with a
cost.

The ? syntax for Results, for example, rubs me the wrong way a little bit. In
that case it really does eliminate a large amount of code and is probably
worth the trade-off. But now instead of Results just being a monad that can be
picked apart like any other data structure, they become a Language Feature
that gets special, magical treatment not expressible by the type system. You
just have to _know_ what the question mark translates to underneath.
Worthwhile or not, this makes me sad. Async/await is a similar case.

> Also compile times have been a big focus of the compiler team, and have been
> going down YoY.

Yes but adding complexity to the language immutably increases the difficulty
of that task. Even if only by a little bit, it adds debt that will have to be
reckoned with for the rest of the language's lifetime.

~~~
dthul
> But now instead of Results just being a monad that can be picked apart like
> any other data structure, they become a Language Feature that gets special,
> magical treatment not expressible by the type system.

I believe, but please correct me if I'm wrong, that the try operator (`?`)
does nothing which lies outside of the type system. It just transforms

    
    
      let v = expr?;
    

into

    
    
      let v = match expr {
          Ok(v) => v,
          Err(e) => return Err(e.into()),
      };

~~~
dgb23
'?' is an almost completely useless language feature IMO.

The second block is much clearer and uniform. When reading the first you
implicitly read it as the second, which introduces mental overhead.

The only upside of having '?' is to write less code, which is the worst kind
of syntactic sugar: It makes the writer type less for a couple of seconds, but
the result is harder to read.

Now even if one doesn't agree with the above it is still a bad feature. Why?
Because the upside of it just doesn't outweigh the cost of having _any_
syntactic language feature like this.

And I don't just mean the energy invested in introducing it into Rust, but
also the continuous cost of having to deal and respect it in future changes.

This is a bad case of hyper-optimization within a very narrow scope combined
with bikeshedding.

~~~
Ar-Curunir
I’m not sure how much Rust code you’ve actually written, but almost uniformly
everyone in the Rust community prefers ? to try! and the explicit designating
that you suggest. The fact that other languages are adopting this [1] suggests
that your preference is not the popular one.

And I’m pretty sure there isn’t “continuous energy” being invested in
supporting this. It’s primarily a one and done feature...

[1] See for example
[https://news.ycombinator.com/item?id=20804247](https://news.ycombinator.com/item?id=20804247)

~~~
dgb23
I made it very clear that this is my personal opinion. I'm aware of the fact
that the feature made it into the language, because it had widespread support.

I still don't think it is a good feature.

> I’m not sure how much Rust code you’ve actually written

Only as much as someone who finds time on the side to learn the language.
There are many things that make this process nice, for example the compiler
messages, clippy, traits, the functional API on iterators and so on.

But I've read substantially more code than I wrote. And as I stated the ?
operator seems to be primarily a feature that makes writing more convenient.
Not easier, not clearer, just shorter.

The pattern matching syntax expresses what it does very clearly and explicitly
in a nice, tree branching like structure. And it is also documenting the code
more directly.

Again, even if you and "almost uniformly everyone" disagrees with this. There
is still the more general point of: How useful does a feature need to be to be
considered _at all_? "Most people find it nicer to write" is in my opinion too
weak.

> And I’m pretty sure there isn’t “continuous energy” being invested in
> supporting this. It’s primarily a one and done feature...

To be frank I find this to be shortsighted. Every syntactic feature adds
baggage, that has to be dealt with continuously on _some_ level. The feature
already was limiting the syntactic possibilities of async/await for example,
which is in my opinion a much more important and impactful feature. This is
the kind of evolution that is painful to see, especially since this is a
repeating pattern with evolving languages.

I like, even admire a lot of things about the language but I feel the weak
point of Rust is its syntax. Especially for such a young language there are
already too many ways to express the same thing. And this might be the
fundamental point where we disagree.

------
Manishearth
Not really going to address the rest of the post but I wanted to point out
that `impl Trait` hasn't really changed what's idiomatic. People still use
generics in argument position, and while I've seen a couple instances of
people using impl Trait in argument position it's not enough to call it an
idiom shift.

impl Trait in return position has changed how people code; but that's because
it made certain things suddenly possible, which isn't an idiom change as much
as obsoleting some old bad workarounds.

I'm curious to know why you felt like you had to change your code to be more
idiomatic with impl Trait.

\----

Nor does it seem like Ok wrapping is the kind of feature that would change
what idiomatic Rust is.

~~~
Ar-Curunir
This is an anecdote, but I'm someone who keeps up rather zealously with
language updates, and even though I write a lot of generic-heavy code, I don't
think my code contains a single instance of `impl Trait` in either argument or
return position, across over 60,000 lines of rust code

~~~
fluffything
I guess that depends on how you code.

Do you ever write code that returns, e.g., an `Iterator` ? e.g.

    
    
        fn my_map<T: Mul, I: Iter<Item=T>>(it: I, x: T) -> impl Iterator<Item=T> {
            it.map(|i| i * x)
        }
    

`impl Trait` in return position is the only way to write that kind of code,
because you can't name closures. You can workaround this by re-implementing a
custom `Map` iterator... Or if you are dealing with `Future`s, by writing a
new custom `Future` type, but with `impl Trait`, you don't need to.

I use it a lot. What before required a lot of boilerplate, now is a one liner.

~~~
Manishearth
I address this in the second paragraph:

> impl Trait in return position has changed how people code; but that's
> because it made certain things suddenly possible, which isn't an idiom
> change as much as obsoleting some old bad workarounds.

this isn't a new idiom. this is code that wasn't possible before suddenly
becoming possible, and people using it.

------
xiphias2
,,The .await war was the final straw to make me stop watching the Rust
community beyond what comes in the release notes.''

Regards the error checking syntax the article may be right, but as far as I
saw, the await addition to Rust went perfect: it became stable when the
decision was made (also a state of the art memory model was created for async
calls), and nobody had to use it (or even follow it) before that.

~~~
throwaway17_17
Can you provide any links on references to a memory model for async calls, I
would be interested in reading them.

~~~
xiphias2
I was referring to the fact that it is the only async implementation that I
know of that compiles to a state machine that doesn't need to allocate new
memory for each continuation. I think it will translate to extremely fast web
services in practice.

Pinning is of course part of the elegant solution. There are some great videos
about it:

[https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s](https://www.youtube.com/watch?v=lJ3NC-R3gSI&t=1710s)

[https://www.youtube.com/watch?v=skos4B5x7qE](https://www.youtube.com/watch?v=skos4B5x7qE)

~~~
majewsky
> I think it will translate to extremely fast web services in practice.

In practice, it's probably not going to matter all that much because the
average web service does way more time-expensive things like disk IO or SQL
queries. The more significant effect is that async-await being really really
fast enables you to use it in more places. For example, if you have a tight
computation loop where different aspects of the logic are meshed together in a
hard-to-read way, now you could try detangling it into several async actors
talking to each other to make it more readable, without utterly destroying the
performance characteristics.

------
AmrMostafa
Not sure I agree there. The language progresses with features that OP himself
says he likes, and he also says that they DO maintain backwards compatibility,
what more to ask for?

The author would be better or revisiting their code on a more relaxed cycle,
for example every 18 weeks. Or whatever works for them, or just let go of the
need to be using 100% of the latest best practices.

------
matt2000
One of the main features I look for in a language is stability. I just don't
want it to change that much other than adding functionality to the standard
library.

I know that's not the fashion currently, but it's probably one of the most
valuable things to me.

~~~
bluejekyll
Have you used Rust? Rust has made a strong guarantee to always be backward
compatible.

We don’t want dead languages, look at Java. It was stagnant for a long time,
but has now shifted to a better delivery methodology of new language features.
Rust is the same and continues to improve. Continues to make things easier and
better to use without giving up its speed and low overhead goals.

~~~
SaxonRobber
Why does a language need changes to be alive? We don’t ship languages, we ship
code written in them. It’s like claiming wood is dead because we have vinyl.

~~~
geofft
The comment you're replying to gave a good example - the history of Java.

If you're shipping code and modified code, you care about the language in
which you can make those modifications. A frozen language means that either
those modifications are harder (because potential improvements to the language
are ignored) or they require writing components in an entirely new language
and figuring out interop.

(If you're not shipping modified code, then you don't care if the language
changes after you ship, anyway. You shipped, and then you're done.)

~~~
pents90
> A frozen language means that either those modifications are harder

I don't agree that it's harder. What is definitely harder is not being able to
ship bug-fixes or modifications without ripping everything up because the
language has moved on since your last release. And that is very common when
developing for, as an example, iOS, since Swift is a fast-moving language that
doesn't maintain backwards compatibility. The benefits of having some new
language feature in Swift are far outweighed by the downside of existing
codebases being invalidated. The various languages in the Javascript family
suffer from this as well. The Python 2 -> Python 3 debacle was another example
of this.

I have dusted off 20 year old Java code which compiled and ran just fine just
fine. That is extraordinarily valuable to me, and requires a lot of discipline
by the language maintainers. In fact, the new faster pace of Java iteration
could be its downfall, time will tell.

A last note: how many language features from the past 20 years _really_
matter? How many really speed up development, improve maintainability, etc. I
would say that there are very few. In fact, perhaps the only one that passes
that bar might be async/await type threading advancements.

~~~
geofft
Yeah, there's a big difference when you're targeting platforms (iOS apparently
and to a lesser extent the web) that move. But if you're writing Python,
Python 2 works better today than it did five years ago. The most recent Python
2-compatible version of every library that existed five years ago works at
least as well as it did then, if not better.

People move to Python 3 not because Python 2 is unusable - it was perfectly
usable five years ago and the bits haven't disappeared from our world - but
because there's lots of small things that make development easier, faster,
more pleasant, and more robust. I don't think there's any single feature you
can point to, but there have certainly been countless little things where,
when I work on a Python 2 codebase these days, I say "I wish this were Python
3."

Anyway, Rust in particular committed to indefinite backwards compatibility
when they released 1.0, and the "epochs" system has been a good (post-1.0)
implementation of this. They realized they wanted some keywords that they
didn't reserve, some syntax that they didn't define, etc., so they said there
are two epochs, 2015 and 2018. The compiler handles both, but the newer syntax
only works in the 2018 epoch. If you have code that was written pre-2018,
it'll keep working indefinitely, even with new compilers.

------
steveklabnik
I've been meaning to write a blog post on this topic. Maybe I'll do it
tomorrow. But, I've been thinking about this question too, or at least a
related one: how many new features does Rust get, and how often does it get
them? I'd like to bring some data to this discussion.

In 2019, we had eight releases: 1.32 to 1.40.

\- 1.32: one language adjustment, finishing off previous module work

\- 1.33: const fn can do a few more things

\- 1.34: you can do a bit more with procedural macros

\- 1.35: a few minor details around closures

\- 1.36: NLL comes to Rust 2015. Not really a new feature so much as
backporting it to an older edition.

\- 1.37: you can #[repr(align(N))] on enums

\- 1.38: no real language changes

\- 1.39: async fn! some adjustments to match. Some more borrow checker
adjustments.

\- 1.40: #[non_exhaustive]. The 1.39 borrow checker adjustments are ported to
an older edition. Macros can go in a few more places.

Really, 1.39 was a huge release, and other than that... all language changes
were very minor, mostly sanding off some edge cases, making some things more
orthogonal, stuff like that.

Most releases these days add some standard library APIs, maybe we have some
toolchain improvements... but for all of 2019, we had one feature I'd call
truly major.

I suspect that things were a lot more hectic previously, but the language has
slowed way, way down recently. We have had two releases so far this year, and
I would argue that the only real language feature was an expansion around
match patterns. Which again, isn't so much a new feature as it is adding a
little bit to an old one.

Churn is real. It's important to keep in mind. We've said for a very long time
that Rust's churn rate would slow down. It's really pretty low at this point.
Or at least, in the language.

One person on the lang team writing two blog posts fleshing out an idea does
not mean the sky is falling.

~~~
_bxg1
My main concern is with new syntaxes. Expanding use-cases for existing ones,
loosening restrictions that can be safely loosened, etc. are all well and
good. But layering on new sugar-syntaxes that aren't truly necessary makes the
language much harder to mentally grok over time. All of a sudden you can't
just derive what's happening by studying the code, you have to add new pieces
of arbitrary information to your mental toolbelt first. The Ok(..) one
mentioned, from a quick glance, seems really unnecessary.

~~~
fluffything
The language team member you are criticizing for exploring what Ok-wrapping
could look like goes into your particular argument in quite some detail here:
[https://boats.gitlab.io/blog/post/2017-12-27-things-
explicit...](https://boats.gitlab.io/blog/post/2017-12-27-things-explicit-is-
not/)

Your general concern, which is that "new syntax makes things less explicit,
and is therefore bad", isn't logical.

Adding new syntax has many costs (not only one), but it can also have benefits
(hence why it is being proposed), and the real question is whether the
benefits outweigh the costs. That is, whether it is a trade-off worth making.

In the blog post, the author quantify the actual costs of not having Ok-
wrapping on their own code, as well as the costs of adding Ok-wrapping to the
language, and for them, their numbers suggest that the trade-off is worth it -
so they went on and implement it as a proc macro, and are using it on their
own code. They don't care whether anybody elses uses it, and they don't have
to.

You could have disagreed with their quantification, maybe you have different
numbers, and that leads to a different outcome of whether the trade-off is
worth making or not.

Instead, you just disagree, without making an argument, and others are doing
the same.

In my eyes, this kind of hurts your position, since it gives me the impression
that those against Ok-wrapping can't really argue why. Whether they just can't
argue in general, lack data to back their arguments up, or maybe even whether
they are Rust users at all, is anybody's guess.

I can't imagine a Rust application writer that is using Result idiomatically
and not doing _a lot_ of manual Ok-wrapping all over the place. I can't
imagine anybody actually enjoying that manual Ok wrapping. Looking at servo,
the Rust compiler, and all my applications, what people end up doing is
writing their own one-shot local macros to hide that manual Ok wrapping.
Having written some of these myself, it definitely did not happen because I
was "enjoying it too much". On the contrary, once or twice per function is ok,
but when I had to do it dozens of times per function, it was just too painful
both for the people writing it and those maintaining that code.

~~~
jstrong
it doesn't seem to me that your reading of brundolf's post is very generous.
the post doesn't mention explicitness at all, but says that increasing the
number of syntaxes that can be used for the same purpose increases mental
overhead for reading code. also, the post says that this particular proposal
"seems really unnecessary," strongly implying that the author does not believe
the tradeoff is worth it.

personally, while I can't claim to love writing Ok around return values, I
definitely value the enhanced readability that comes with it. rust is the most
readable language I've ever coded in, and it's not even close. when I see the
"throws" syntax that was proposed, I expect it would make it harder to read
the code because the Result type is erased from the type signature. To me,
whatever tradeoff I would gain in ease of writing code from this would be far
outweighed by the cost in reading that code.

------
jeffdavis
Given that rust is changing, I think they are managing the change well.

The question is: should it be changing?

I think the answer is yes. Rust is a new kind of language that is showing
people (like me) things I never would have thought were practical. It's
inevitable that ergonomics are going to evolve to make everything flow
together.

------
ChrisSD
For those not familiar with the Rust drama, it should be emphasized that this
blog post is very much a reaction to the linked blog post advocating for "Ok-
wrapping": [https://boats.gitlab.io/blog/post/why-ok-
wrapping/](https://boats.gitlab.io/blog/post/why-ok-wrapping/)

This is a subject that has provoked much drama in the past and looks like it
will again.

------
TazeTSchnitzel
In general, programming languages will change over time, so what matters to me
is how that change is managed. Cautious, small, gradual changes over time seem
safer than big releases every year or so, but particulary because of Rust's
approach to stability. When Rust has a new feature implemented, it does not
immediately become part of the stable language. Instead, Rust only commits to
stability for a feature once it has been properly tested. It's something I
think PHP (which I have been a significant contributor to) and other languages
could learn from, because there's no substitute for real-world experience to
decide if there are remaining rough edges on feature, or whether it is good
idea at all.

Moreover, unlike some other languages, Rust has chosen not to force people to
adapt their code to new syntax and features! They can stay on an old version
(edition) of the language forever, yet still use an up-to-date toolchain and
have others be able to make use of their code. I wish every language was like
that. Imagine if Python 2/3 had never happened.

------
MR4D
Does anybody change/update their C++ code to keep it “idiomatic”?

Not sure I really get the concept here.

~~~
roca
Yes, large projects like Firefox and Chrome are constantly updating their
code. The rate at which that change happens varies though.

Sometimes you do that because the new stuff is a significant improvement in
its own right, but you also need to do it because using an "obsolete" dialect
of C++ makes it difficult to incorporate third-party code, makes it
unattractive to new contributors, and is generally just a code smell.

------
dheera
The same can largely be said of JavaScript:

* function as class -> class

* function() {} -> ()=>{}

* callback -> promise

* var -> let, const

Every year there's something else new that you are told you are doing wrong.

~~~
krakatau1
Well of course but Javascript is in unique position to do those kind of
things, other languages have to be careful not to alienate its communities.

------
Dowwie
I appreciate that the language I'm using is evolving, as well as the libraries
and frameworks in the ecosystem. If I fail to keep up because I'm focusing on
making the most out of the tooling I committed to, that leaves opportunity for
growth. I care about creating solutions, not keeping up with the ambitions of
a large, diverse group of high achievers.

------
shruubi
Maybe it's just me, but every time I look at Rust I'm either turned off by the
community or by this constantly shifting idea of what is best practice.

A lot of comments have talked about the idea of writing Rust like it is X
year, which seems weird to me as I would imagine that a language with a strong
ecosystem would not create a situation where five-year old code that was
considered ok then is now looked back as bad code and a reason for derision.
Besides the obvious learning better ways to do things as time goes on,
shouldn't code written five years ago still be good if it works? Is code being
a few years old the only excuse we need to rebuild it?

Maybe I'm wrong here, but what I want is to not have to think to myself a year
after I build something "well, that was built in last years standard, time to
rebuild in this years standard."

~~~
Arnavion
The "community" you're paying attention to is made up of enthusiasts, so it's
to be expected that they tend to be in the camp of adopting new shiny things
as soon as they're released. The same thing happens in C++; you'll often see
reddit / stackoverflow telling you to stop using new/delete in favor of
make_shared and make_unique, stop using loops in favor of functions from
`<algorithm>`, and so on.

Regardless of whether the new additions make the language better or not (I
believe they do, in both Rust's and C++'s case), adopting them immediately in
the codebases you are responsible for is _your_ decision. You have to decide
by yourself whether the pros from adopting the changes are enough to offset
the cons of making changes. If you conclude that the cons outweigh the pros,
and if it bothers you that the "community" derides you for not tweaking your
code, then a valid solution is to stop paying attention to the "community" and
get on with your life.

------
seemslegit
Meanwhile typescript people be like: oh I see you're still using the old style
mapped quantum ensemble types introduced five weeks ago rather than the retro-
causal discriminated union types which will be introduced five hours from now
- how quaint.

------
dx87
I can't keep up with it either, but that doesn't stop my code from doing what
I want it to do. There are a lot of people who seem like they enjoy working on
Rust as a hobby, the same way some people like playing video games. They still
have a commitment to backward compatibility though, so who cares if a bunch of
people geeking out on their favorite language are fine-tuning it and making
superficial changes, the code I wrote before stil runs the same (or better)
than it did when I wrote it. The compiler doesn't care if it's idiomatic, just
that it's correct.

------
awesomepeter
Seems like it would be beneficial if codemods would accompany such features if
possible.. is it possible in rust?

~~~
steveklabnik
There are several ways of doing this, yes. Including one provided by the Rust
project itself, “rustfix.”

~~~
eindiran
Is "rustfix" what is running behind-the-scenes when you run "cargo fix" or is
it something distinct?

~~~
JoshTriplett
Yes, cargo fix just runs rustfix on all the files in your project and passes
the same flags cargo does to rustc. (Similarly, cargo fmt runs rustfmt on all
the files in your project.)

------
beetwenty
On the one hand, this is a predictable outcome if you are trying to shepherd a
large codebase through a fast-moving language. Idiomatic Python 1.6 looks
dramatically different to idiomatic Python 3.x.

On the other, Rust isn't the language I would want to write lots and lots of
code in either. There are a few projects and organizations where it makes
sense to do so(namely web browsers, databases, and other kinds of "deep
backend, large surface area" types of projects), but most of the things it
does well also act as a hindrance to feature development, compared with an
idiomatic Java, C# or Go equivalent.

------
scoot_718
I don't want a language full of special cases.

------
malkia
C++ programmers, like what I do mostly, may have to do over and over with new
standards, but don't have to for all code.

------
ilaksh
I thought that not knowing what idiomatic Rust looks like was the most
idiomatic thing about Rust.

------
crimsonalucard
I recommend that this guy switch to javascript to truly understand himself.

------
diebeforei485
I feel this way about Swift.

~~~
ViViDboarder
It’s better than Swift actually. The Swift compiler isn’t even backwards
compatible.

------
978e4721a
I recently had a thought, that language team should provide automated
migration tools for such things. It woukd made python 2 to python 3 switch
much easier and faster, that applies to rust even more.

~~~
dbrgn
They do: [https://doc.rust-lang.org/cargo/commands/cargo-
fix.html](https://doc.rust-lang.org/cargo/commands/cargo-fix.html) It works
much better than 2to3 actually.

------
demarq
just a big FAT WARNING here. C++ suffered for a long time from staleness
because people detested change.

I think tools and technologies should prioritise the future and new users than
focusing on the past and long time users. it is what is best for the survival
of the language.

if you don't want to deal with the changes then don't update your code base.
but don't update the compiler then resent the fact that it is updated.

------
adamnemecek
Rust is not the only language that changes over time. The changes in Rust are
must smaller than say C++.

~~~
jfkebwjsbx
Not even close. C++ is a language that is over 30 years old. In comparison,
Rust is way younger and has had many more changes and features added in a way
shorter period of time.

For good or bad.

~~~
saagarjha
I think the rate of changes to C++ has accelerated recently as well. Until
C++11 it wasn’t actually that unreasonable.

~~~
jfkebwjsbx
Even if you add the recent additions, it is still less stuff than Rust already
has. For instance, async.

The problem with C++ is all the bending backwards they do to keep old code
compiling _and_ working, which is a major reason for its success.

~~~
roel_v
"The problem with C++ is all the bending backwards they do to keep old code
compiling and working"

Uh, that's not a problem, it's (as you say) the main reason people use it and
why they burn out on flavor of the day languages like Rust and Go (as the OP
illustrates).

~~~
Ar-Curunir
This is funny, because with Rust you can almost certainly compile code from
Rust 1.0, unless it was relying on a soundness bug. You can also seamlessly
use dependencies that use newer editions of Rust; you don't have to adjust
your code to do this.

------
marta_morena_23
So what? Did you ever look at a production codebase? You will be hard pressed
to find an idiomatic codebase and nobody in the world is going to update
anything to be "idiomatic" every 6 weeks. I mean maybe your manager doesn't
fire you right away if you try, but you better be doing this in your spare
time lol.

For academic and self-learning use? Sure go ahead, but then please don't
complain that you can't keep up with it. Nobody should be using a feature for
the sake of using a feature. If you don't need it, don't use it. If its old
and not "idiomatic" there is literally ZERO reason to change it unless you
ain't got anything better to do.

Get your priorities straight.

------
123_throwaway__
This is what happens when a bunch of web developers are in the core team of a
supposedly "systems programming" language. Web developers are used to moving
to a new framework every week.

------
snambi
Totally agree. Rust is complicated for doing simple things.

~~~
Dowwie
This is true, as is the fact that work often demands one not do "simple
things" and in this space Rust shines

------
jtdev
Avoiding rust atm myself. Just seems too clever for its own good.

------
benbenolson
Just use C99. No need to keep up with anything.

~~~
alvarelle
Personally, I stick with K&R C. I haven't gotten around to update all my with
function signatures. whats is the thing with putting (void) all over or
specifying the return type of my functions? Really, these explicit function
declaration are just code duplication that serious programmers don't need as
they know their code. (/s)

~~~
nwxonwxo
You’re being sarcastic, I know, but you just unironically exactly described an
entire decade or more of early C programming.

------
smabie
Why not just add a fold function to Option (as all monads should have a fold)?

~~~
geofft
Fold isn't an operation on a specific monad, it's a generic operation over any
monad. Adding it to Option defeat the whole point of thinking about Option as
a monad, i.e., the ability to apply generic algorithms that work on any type
constructor that follows the monad laws.

(If the question is why no generic fold over any monad exists in Rust, the
short answer is that Rust isn't Haskell. Which is great, it means Rust can
specialize in things Haskell can't and vice versa. Personally my favorite
example is that Haskell avoids shared mutable state by avoiding mutable state,
and Rust avoids shared mutable state by avoiding shared mutability. Both have
their downsides but each works better for different applications.)

~~~
lmm
> Fold isn't an operation on a specific monad, it's a generic operation over
> any monad. Adding it to Option defeat the whole point of thinking about
> Option as a monad, i.e., the ability to apply generic algorithms that work
> on any type constructor that follows the monad laws.

Having the same function exist with the same name helps communicate with other
programmers, even if you can't express the fact that it's actually the same
function at the language level. Just like in a language without generics you
might still have add(int, int), add(decimal, decimal), add(string, string) and
add<T>(list<T>, list<T>) functions. Rust already offers a function called
"and_then" on most of its monadic types, and a programmer can see and
understand that these are all in some sense "the same function" even though
there's no way to abstract over that.

~~~
foldr
But 'fold' isn't very useful over option types as there aren't really any non-
trivial operations that you can perform on something that's either Nothing or
Just x. I think OP was probably thinking of folding over a list of option
types, which you can do easily enough in Rust.

~~~
lmm
That's the opposite of my experience; fold is probably the main way I consume
options in Scala. It's pretty much the only thing you ultimately want to do
with an option, after you've finished transforming and composing.

~~~
foldr
I'm really puzzled by this. Which Haskell 'fold' function would I ever want to
apply to a Maybe type? I think there must be some kind of terminological
variation in the use of 'fold' here.

 _edit_ : Ah yes, I see that Scala chooses to use the name 'fold' for what is
essentially the 'maybe' function in Haskell.

I don't think there is any very useful generic notion of 'fold' that
corresponds to this usage. (I see how the operation is a kind of fold, but the
type signature of the function isn't flexible enough to be used for any
foldable type.) So that is why Rust and Haskell don't name this operation
'fold'.

~~~
geofft
And here we see _exactly_ why implementing a specific function on a specific
instance of a monad isn't the answer - two users of two different, well-
respected functional languages can't communicate.

~~~
lmm
That's completely backwards - the confusion here is precisely because the
function is not implemented, if it was present in Rust (with a type signature)
then there would have been no misunderstanding. (There was also a mistake in
the original statement - fold is nothing to do with monads)

~~~
foldr
The function is implemented for option types in Rust, it's just not called
'fold', because there's no universal convention according to which functions
with that signature are folds.

[https://doc.rust-
lang.org/std/option/enum.Option.html#method...](https://doc.rust-
lang.org/std/option/enum.Option.html#method.map_or_else)

------
pjmlp
Now imagine when it gets to the 40 years of C++ existence, or 25 from Java, 20
from .NET, then one learns to value why enterprises care about backwards
compatibility.

More breaking changes are on the way, until error handling and async/await get
properly integrated into std, instead of having a couple of incompatible
crates each going its own way.

~~~
dmit
Please allow me to share my view of the conversation up to this point:

Boats: Here is an approach I use in my personal projects that has proven to be
ergonomic, consistent with other language features, and could possibly even
unlock future optimization opportunities long down the road.

OP: That's it, I'm DONE. The language moves too quickly and I can't keep up.

You: More breaking changes are on the way. They never learn.

\-----

Would you agree that this escalated way, way too quickly?

Boats didn't "move" the language with a blog post, it's not even a pre-RFC. As
pointed out elsewhere in this thread, the language hasn't been moving at all
since 1.0 - you could say the frontier has been inching forward, but that's
what frontiers do; nobody's forced to fight on the front lines all the time.
And then the cherry on top - "more breaking changes on the way", when 1) prior
changes weren't breaking; 2) it's not clear there will be any new ones; 3) if
there will, those won't be breaking either.

~~~
pjmlp
Please let us know how async/await is not going to be a breaking change, when
even Fuchsia just decided to create their own async runtime, because surely we
still don't have enough of them.

So I wonder how std will incorporate a runtime implementation that happens to
be compatible with all ongoing runtime flavours, so that those breaking
changes don't happen.

~~~
dmit
Well, either the language will leave async runtimes in the domain of third-
party libraries, which is the current approach. Or, the potential blessed one
in std will be an alternative that you may or may not want to use in your
code.

When I think of breaking changes, I think removing sun.misc.Unsafe. Which, yes
yes, was never supposed to be used, but still was. Evolution of best practices
and introduction of alternative implementations doesn't break anything.

~~~
pjmlp
It does break, because those libraries need to interoperate and async/await
doesn't work without linking to one of them.

~~~
mplanchard
I might be misunderstanding, but the third party libraries won’t be going
anywhere, right? No one will be forced to use the runtime in std, if it’s
added.

~~~
steveklabnik
That is correct. It's not clear that we'll add one to libstd, but even if we
do, it will have zero impact on folks using external runtimes. If we do add
one to libstd, it will probably be a very simple one, mostly for convenience
and prototyping, rather than something that tries to compete with the bigger
runtimes.

~~~
pjmlp
And what is the interoperability story across libraries that dependent on
different runtimes?

~~~
steveklabnik
It depends. The major pain point right now is that there's no common API for
spawning new tasks. Not every library does that though.

It's still not clear what this has to do with being a "breaking change"
though. Like, if I were to use the serde-json crate in my project, the fact
that the json crate exists, but has a slightly different API, does not mean
that somehow this is a "breaking change." Moving between two or three
different libraries is not the same thing.

------
Animats
They're _still_ fussing with the preferred error handling syntax?

Most of the hacks for not having exceptions seem to end up being worse than
exceptions.

~~~
dpc_pw
Not it didn't. Rust error handling is glorious comparing to exceptions.

Rust community is just full of perfectionist and we love to argue endlessly
about how to improve stuff even more, which is very refreshing. In many other
PLs people just keep their heads down and crawl in the mud.

~~~
smt88
> _In many other PLs people just keep their heads down and crawl in the mud._

Or, as I would put it, programming is a job for them and not also a hobby.
They have other things to spend time on, so banging out an ugly codebase in
JavaScript is "good enough" to let them clock out.

Either is fine, but I don't think it's realistic to assume everyone can or
should seek perfection in their tooling.

------
7kmph
Sad to see that rust is heading towards a wrong direction. I think everyone in
the core team should be stopping what they are doing and write Haskell for a
year. This way they can appreciate the benefit of Haskell, and know what to
avoid when they implement those ideas in rust, and anyone who trying to make
the language and the philosophy more like c++ or java should be banned from
the rust community

~~~
steveklabnik
Several folks on the language team know Haskell well.

~~~
smabie
I'm sure they do, but even you must admit that Rust has gotten less
'functional' in nature as time goes on. New syntax or ad-hoc abstractions are
being created to handle problems that have well known FP solutions. Take this
matching on an Option business. The easy solution is to just add a fold method
on the option type. Problem solved, now you never will need to match an option
ever again! The harder solution would be to implement HKT and add a real monad
trait, but let's not get into that. Another example are the async/await
syntax. Why does this syntax need to exist? What value does it provide? Why
can't a future just be a regular old class?

A long time ago I thought Rust was going to be a flexible and innovative
general purpose language. While it still is undoubtedly innovative, it seems
like the target audience has shrunk considerably. And as GCs improve and get
more tunable, I think that target audience is going to get even smaller in the
future.

~~~
steveklabnik
> even you must admit that Rust has gotten less 'functional' in nature as time
> goes on.

I don't think this is true, especially when you look at long timescales.

> New syntax or ad-hoc abstractions are being created to handle problems that
> have well known FP solutions.

They have known solutions when you have a GC and no control over memory
layout. They do not have known solutions in a language like Rust.

> Take this matching on an Option business. The easy solution is to just add a
> fold method on the option type. Problem solved, now you never will need to
> match an option ever again!

Sorry, I do not understand what you're talking about. (I coded in Haskell most
a decade ago, I'm not on the lang team.) What would fold do on an option,
specifically? Fold is usually a list operation, but an option is a list of
zero or one... so it would be a no-op?

> The harder solution would be to implement HKT and add a real monad trait,
> but let's not get into that

Again, this is "we don't know if this is possible in a language like Rust"
territory. Which is why you don't want to get into that.

> Another example are the async/await syntax. Why does this syntax need to
> exist?

Specifically because of the previous statement. It is not clear that a more
abstract option is possible. We could wait for more years until maybe it's
proven possible, or we could implement a useful feature today that we know is.

It's also _more_ significant in Rust than other languages due to borrowing.
[http://aturon.github.io/tech/2018/04/24/async-
borrowing/](http://aturon.github.io/tech/2018/04/24/async-borrowing/) is a bit
out of date but the concept is the same.

> Why can't a future just be a regular old class?

Rust doesn't have classes. Futures are a regular old typeclass.

> While it still is undoubtedly innovative, it seems like the target audience
> has shrunk considerably.

We have seen a _massive_ uptick in adoption over the past few years.
async/await, for example, has been a feature that a lot of folks have said
"I'll start using Rust once that hits stable."

~~~
saagarjha
> What would fold do on an option, specifically? Fold is usually a list
> operation, but an option is a list of zero or one... so it would be a no-op?

Presumably the fold takes advantage of the fact that the default,
"accumulator" value is chosen if the Option is empty and the collapse function
just runs what would be the Some arm of the match statement.

~~~
steveklabnik
Oh, duh. Thanks.

Thats [https://doc.rust-
lang.org/stable/std/option/enum.Option.html...](https://doc.rust-
lang.org/stable/std/option/enum.Option.html#method.map_or), I think?

~~~
saagarjha
If the team had just written Haskell for a year they would have picked the
obviously superior "fold" name for this operation. (I think you can actually
use fold here if you _really_ wanted it, since Option implements IntoIter?):

    
    
       Some(0).iter().fold("some", |_, _| "none")

~~~
dthul
For people coming from a functional programming background, `fold` might be
the superior name. But setting aside monads, `map_or` expresses the intent
much better I find.

~~~
saagarjha
(I was being mostly sarcastic.)

~~~
dthul
Rereading your comment I wonder how I could miss this!

