6 ms·

I find that Rust tends to have code that goes sideways more than downward. I prefer the latter and most C code bases, that I find elegant are like that. It is

• est31 4y ago
  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_borrowck/src/diagnostics/region_name.rs#L772-L794 https://github.com/rust-lang/rust/blob/1.60.0/compiler/rustc...
  • UmbertoNoEco 4y ago
    • est31 4y ago
      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?
      • UmbertoNoEco 4y ago
        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++.
        • estebank 4y ago
          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?
          • UmbertoNoEco 4y ago
            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.
            • estebank 4y ago
              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?
              • UmbertoNoEco 4y ago
                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.
• kzrdude 4y ago
  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.
• aaron_m04 4y ago
  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(); ...
  • ntoskrnl 4y ago
    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
    • veber-alex 4y ago
      let me introduce you to the famous '?' operator. The code above can be written as: let foo = foo()?;
      • ntoskrnl 4y ago
        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.
  • mathstuf 4y ago
    Any reason why this wasn't preferred? let foo_result = foo() .map_err(Bar::Fail)?;
    • veber-alex 4y ago
      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) };
      • loeg 4y ago
        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).