> However, I'm not sure it's entirely like that in this case: at the very least, this complexity here is revealed to the programmer (they have to do the same parsing switch in their head, even if it's usually fairly obvious). Additionally, this complexity applies, somewhat, to tools that work with code too, not just the compiler (e.g. limited editors trying to do syntax highlighting without running more detailed semantic analysis). This seems like such a minor thing to introduce such a heavy penalty, but maybe there's something more annoying you're finding with 'as'.

To be honest, I really think you're blowing the complexity of this way out of proportion. Plus like, it's not like Rust's grammar is this incredible thing of beauty: look at `where` clauses or lifetime syntax. If Rust were really optimizing for human readability, it's hard for me to imagine this is the result. It's purely a style thing, just like `let` instead of `var` and so on, and I don't think sacrificing programmer familiarity for a designer's idea of style is a good tradeoff.

> I really do think this is just a familiarity thing: coming from languages with a strong statement vs expression distinction it's weird, coming from mathematics/languages with out the distinction, it isn't. The language isn't particularly more complex because of it, it is just slightly different.

I disagree; I think the language is significantly more complex as a result. "Everything is an expression" leads to a lot of assigning out of `if` and `match` expressions, consequently there's a ton of pressure to dump a lot of things into them. `match` in particular is really just a regex for variables, except 100x bigger. In most ways I consider that a regression.

> It's true that Rust's target market is mostly the former set of languages, so one could argue maintaining familiarity is critical (something Rust acknowledges: {} for scope and <> for generics driven by that), but it's also an argument that would have kept us writing slightly improved assembly languages forever.

I don't think that C/C++ are being held back because they have statements though. My whole point is that Rust fixes the main issues with C and C++ (weird tricky behavior, super dangerous memory management, data races, concurrency, no/bad standard library), but then for considerably less gain tacks on a lot of functional programming ideas.

To be clear I'm not at all against functional programming. I just think most systems programmers aren't functional programmers because there really haven't been (and still aren't, as Rust isn't really functional) functional systems languages. And because Rust doesn't have the benefits of a lot of functional languages (super cool Lisp macros, etc.) I struggle to see the point beyond a style preference.

> I personally hate the C/C++ pattern of having to declare things and then initialize them later.

Like this for example. Do you hate it enough to pull all the statements out of a language? Feels like time that could be better spent somewhere else.

> Yes, what cost? I genuinely don't see a cost other requiring some people to get used to it, and I do see costs to the other approach.

The vast, vast majority of programmers come from languages with statements, and one of the main complaints about Rust is its learning curve. I think that's a significant cost.

Like, when I build an application in Java, Python, or C, "I had to initialize a variable using a function instead of an if/match statement" is nowhere on the pitfall list. That's not what our industry struggles with. It struggles with program complexity, logic errors, concurrency, and architectural confusion. "Everything is an expression" does nothing to address those issues. Lifetimes and the borrow checker do, and I think those departures are great investments for systems programming. Assigning from a match solves a problem I never had.

> I personally find the following to be so much nicer:

let name = match someEnum {
X => "...",
Y => "...",
// ...
};

Really the only reason I use `switch` so much in C is that there's not a lot of polymorphism. Otherwise I greatly prefer to have this logic internal to the thing I'm matching on:

let name = someEnum.get_name();

But again, because `match` is the way Rust does everything, look it's another match expression.

> (I also forgot to mention ternary ?: in C: it's also partly an acknowledgement that if-as-a-expression is useful.)

Aha well, as you might imagine I really dislike the ternary -- in really any language. They're hard to read, hard to edit, too easy to make a mess... basically all my arguments about `match`. Honestly just use an if.

I don't want to keep repeating myself, but my main beef isn't readability or whatever. It's that I don't understand what it gets me beyond using if. If ternaries somehow (really) solved a NULL problem, or helped me with error handling, or let me avoid use-after-free, then those are all great and welcome tradeoffs. But all it does is save a couple of lines, and because my problem has never been that I had to use a couple extra lines I just don't care about features where that's the sole virtue. I need more.

> I don't see much upside to emulating C-style manual tagged unions here.

Well I guess my point is mostly that I want to differentiate between matching on a value and implementing inside-out polymorphism. I don't like that they're smashed together in match because I think they're very different, and it leads to a lot of mixed up logic inside match expressions. The point isn't to emulate tagged unions so much as it is to separate concerns.

> [1]: This is a point where other people would complain about breaking with other practice for no good reason too (anyone who had used Haskell or OCaml or similar would find this system unnecessarily clunky).

And I would totally agree with them if Rust were a language in the vein of Haskell or OCaml, but it's not; it's a mainstream systems language. If Rust's pitch were, "Hey, do you like Haskell? You'll _LOVE_ Rust!" then they'd have a valid complaint. But Rust's pitch is, more or less, "Hey are you tired of C/C++ pitfalls or slow Python/Ruby/JS code? Give Rust a whirl!" When optimizing for familiarity and shallow learning curve you gotta pick an audience; you can't have it both ways.

> Focusing on a single value also doesn't generalize/scale: for instance, if one is making a decision that depends on more than one value:

fn maybeAdd(x: Option<i32>, y: Option<i32>) -> Option<i32> {

match (x, y) {
(Some(left), Some(right)) => Some(left + right),
(Some(left), None) => Some(left),
(None, Some(right)) => Some(right),
(None, None) => None
}

}

Oooooh, I think this is a very good point, but honestly this is just half-hearted polymorphism. These two enums should be in a struct, and this logic should be in its implementation. Then I think it's fine to do something like this:

def maybe_add(self):
if self.left and self.right:
return self.left + self.right
if self.left:
return self.left
if self.right:
return self.right

I mean, I don't want to pick apart a clear hypothetical example. My point is that we already have a tool that can handle those scaling concerns: if and encapsulation/polymorphism. And they're much, much better than match because they scale to more than 3-4 variables; past that and match is just terrifying.

> I've personally found being exposed to many very different languages has helped inform the code I write in all others. Each new one definitely takes some getting used to, but my experience is that having touched several different paradigms has made me both more flexible (less attached to any particularly way of doing things) and a deeper understanding of even the "boring" languages: the trade-offs and "whys". There's value to things being the same, but there's also value in being able to break out of that mold and doing new things even if there's not an obvious benefit when focused on the old style.

Hah, tell me about it! You should've seen me the day I discovered there were different "types" of numbers in C (coming from Python)! There's a lot to learn, no question.

But there's a reason behind C's proliferation of numeric types, one that aligns with its purpose. I don't dislike `match`, etc. because I'd never worked with it before. I dislike it because it encourages so many bad practices in order to solve a problem I never had.

> I hope that you find Rust more and more enjoyable as you use it more

I do actually. Maybe you're getting this, but I identify more as a grump when it comes to programming so I gravitate towards grumpier languages (C, Go, etc.) so Rust's eagerness about some of the ML stuff is a little off-putting. But really, compared to integer promotion in C like, `match` is nothing :)