On removing let and let mut

Minor correction:

final variables in Java can and do change value. They start default initialized, then are assigned at most once. This is a collosal pain in the neck for people writing multithreaded code.

You can also observe the partially initialized final change value in single threaded code by invoking partially initialized stuff around during initialization.

Incidentally, I'm not personally very fond of "assigning an if-expression to a variable" since it disconnects the variable name from the value it gets. An example with two variables illustrates the point:

  let (value, weight) =             let (value, weight)
    if values.empty() {             if values.empty() {
      (0, 1.0)                        value = 0
    } else {                          weight = 1.0
      (values[0], 1/values.len())   } else {
    }                                 value = values[0]
                                      weight = 1/values.len()
                                    }

I think the right (the "old way") is more readable. However it requires the variables be mutable or declaration be separable from initialization.

> To our great surprise, we've found that our codebases have a lot more declarations than assignments, so it makes sense to require the extra keyword on assignments because they're rarer.

I actually love this statistical approach to language design, draws parallels to something I read that CPU designers make optimisations to the innerworkings their instructionset based on heuristics such as average number of functions arguments etc.

Does Vale’s parser tolerate syntax errors well?

Keywords are great because they provide redundancy in the grammar that allows for good syntax error messages and recovery.

I recently lamented the absence of a let token in Ruby while working on making Sorbet’s parser more tolerant of syntax errors. Consider this Ruby program:

    x.
    y = 0

It doesn’t have a syntax error. Ruby treats this as if the user had written

    x.y=(0)

But because of how the line is broken, probably the user meant to have two separate statements, and is in the middle of inserting a new call like

    x.foo()
    y = 1

Or consider another:

    class
    y = 1

The syntax error Ruby reports here is “class names must start with a capital letter.” It then fails to produce any parse result because there is no end keyword to match the class, throwing away the (properly parsing) `x = 1` subexpression in the parse tree.

In these cases it’s frequently possible to hack around the issues with weird contortions. But in basically every such case, if Ruby had used an explicit let keyword it would have been much easier to for the parser to both report syntax errors in places that might otherwise be ambiguous as well as produce some parse tree for the ones that don’t parse.

Probably a good choice to not go with a! = 0 which could easily be confused with a != 0 (which would of course throw a compiler error on ‘a’ used but not defined).

That being said I’ve never had a problem with python’s variable definition and assignment syntax being the same where TFA claims it was a failure. Honestly, I even support the walrus operator for the specific reason it was introduced — heresy, I know…

I'd be very worried about accidental shadowing.

    x = 4
    if (cond) {
        x = 8
        log("x is now: ", x)
    }
    process(x)

Looks right, but it's wrong.

The thesis for rust is something like "C++ level performance without the pain". The Zig thesis might be "low level as C without the pain".

What is Vale's thesis?

See also Prolog and Erlang where assignment is both an assertion test and an initial binding where no binding is there to assert.