There are two upcoming features, let chains and let else, to counter the sideways drift.

Sometimes it's also the formatter though that outputs intensely sideways drifting code: https://github.com/rust-lang/rust/blob/1.60.0/compiler/rustc...

While generally, yes, features are bloating up a language, one could argue these two particular features reduce complexity. Like why am I forbidden to use && in a if let? And why does if let support both irrefutable and refutable patterns but deconstructing let requires them to be irrefutable?

There is surely some "law" in some place of the internet that says something like: "Every programming language valid construction no matter how ugly, obscure,verbose,old,etc will find its way to lots of codebases". See C++.

Yes, John Carmack has said as much, at least in the context of syntactically and semantically valid constructs that are actually bugs making it into codebases. What does that have to do with let chains and let else?

The problem are not the new traits per se. The problem is that the complexity of a language grows super-linearly with the number of things added to it. There is beauty (and productivity) in simplicity. When you need to do 2 things and there are 2 ways of doing each, now you have 4 different combinations. All languages are more or less guilty of this (even those which promise "Just 1 way to do things") but it is undeniable that Rust is joining C++ in the right side of the complexity Bell curve.

let else and let chains aren't new traits, they are syntactical features that make things that people would expect to work, Just Work™. People keep bringing up the complexity of Rust (a valid argument to be made there) but then point at some feature that is removing an arbitrary limitation from the language. And even for cases where a new feature is being added, I can point at the case of ? for error handling that was a new feature, that "complicated" the language, but that very clearly improved the ergonomics of the language for reading and writing. Should ? have been left in the cutting floor because it didn't look like anything else and was a "redundant" feature?

Let me put it another way: what Rust feature would you remove to "simplify" the language?

As I pointed here originally, you need to be very careful about what you ADD to a language, because once the cat is out of the bag there is no going back, people are going to use that stuff. That's why I dont begrudge the attitude of the golang maintainers to be very slow in introducing stuff, because it is basically an irreversible step.

I suppose every thing in Rust has a raison d'etre but you pay with complexity that versatility. I think there is space now for a modern, memory-safe, SIMPLE, systems programming language. C has the backwards compatibility problem (although I am still bullish on its future) and a language like Zig never got any traction. Hopefully the future will bring new, interesting stuff.

Zig is still very much work-in-progress, much more so than Rust. I'd say it's too early to speak of traction there.

OK, it has been 6 years, so fair enough, let's wait and see at least for the 1.0

That's the difference between Zig and Go.

As far as I can tell, Go was kinda rushed, and they called it 1.0 before they get to add the generics it obviously needed. And I bet adding those generics in a way that preserves backward compatibility was a bear.

Zig will be done when it's done.

I think it's because of the expression focus. Isn't it easier to make the code flow like a waterfall when it's imperative, but is harder to reason about values and state.

I have noticed this tendency as well.

To counteract it, I write exit-early code like this:

    let foo_result = foo();
    if let Err(e) = foo_result {
        return Bar::Fail(e);
    }
    let foo_result = foo_result.unwrap();
    ...

Any reason why this wasn't preferred?

    let foo_result = foo()
        .map_err(Bar::Fail)?;

Bar::Fail is not wrapped in a Result type, so you can't use '?' with it (on stable at least).

You can write it like this:

  let foo_result = match foo() {
    Ok(v) => v,
    Err(e) => return Bar::Fail(e)
  };

The result type is the return from Foo -- Bar::Fail does not need to wrap Result. Foo is Result<T, E> and map_err() would convert it to Result<T, Bar::Fail>. I think GP's `map_err()?` is the most straightforward way of writing this idea (and it's generally speaking how I would suggest writing Rust code).

GP's code will return Result<_, Bar>, the original code we are trying to fix just returns Bar.

If you are writing code to handle Results, it’s going to be a lot less painful to just return Result.

I do this too, with a different spin on it:

  let foo = match foo() {
      Ok(foo) => foo,
      Err(err) => return Err(err),
  };

I was typing it out so often I made editor aliases `lmo` and `lmr` for Option and Result

let me introduce you to the famous '?' operator.

The code above can be written as:

  let foo = foo()?;

LOL you're right! I just pasted the template here, but my defaults are mostly equivalent to plain old `?`. I don't use the match if `?` would work.

Early exit code would be easier to write if Rust supported guard let.

its coming soon, already available on nightly.

   let Some(x) = foo() else { return 42 };

I'd suggest that something like that is already achievable by having foo return an Option and combining it with unwrap_or.

Like this?

    if let Ok(x) = my_func() {
        // ...
    }

Or do you mean something else?

Isn’t that a good general practice todo? Exit early

You'd be surprised. For every person that things exit early is good, you'll run into another that prefers a single exit. At worked at a C++ shop that preferred "single exit", and some methods with an ungodly amount of conditions just to make this possible. Ugh.

In my experience, a preference for single exit comes from C where you always need to make sure to clean up any resources, and an early exit is a great way to have to duplicate a bunch of cleanup logic or accidentally forget to clean things up.

Of course, that's what goto is actually good for.