You would use const, unless you wanted to reassign the variable later in the same scope.

Correct. Example doesn't show modification of the variables later, better to use const.

Const is a complete waste of time for non-primitive types. I defy anyone to show me a single bug in a popular program that could have been prevented by using const for a function local object. It can’t be done. There are bugs caused by mutatable state. There are bugs caused by reassigning globals. There has never been a bug caused by reassigning a function local variable while leaving it mutable.

Using the more restrictive construct until you actually need additional features (like identifier rebinding) is just engineering 101.

I think the onus would be on you to prove that using a less restrictive concept is worthwhile because it saves you two keystrokes. That, in contrast, seems like the opposite of good engineering. Like using classes over structs because class is shorter to type.

The more I think about your post, the more absurd it becomes.

I think it can be argued both ways. I've seen a large TypeScript codebase with a pre-commit hook that enforces use of const on all non-reassigned variables. With that being done everywhere, it made for easy reading - whether a variable was being reassigned or not effectively became annotated in its declaration.

On the other hand, there are some good reasons not to use use const everywhere we can. Paul Sweeney lists a few here: https://medium.com/@PepsRyuu/use-let-by-default-not-const-58...

I'm not sure where I land yet. Perhaps it's a decision to make separately for each codebase.

I don't think I'd call any of those reasons good; the main thrust of them is "const doesn't do everything, so don't let it do anything". If that line of reasoning is appealing, then one might as well continue using var.

The main benefit of let/const over var is that it's block scoped. The benefit of const over let is pretty much nothing, much. It only prevents some limited form of re-binding. You can still easily re-bind const variables from inside a function:

    const x = 1;
    (function() {
        const x = 2;
        console.log(x);
    })()

or from an argument:

    const x = 1;
    (function(x) {
        console.log(x);
    })(2)

So it has limited value in any code that uses closures.

Shadowing isn't rebinding?

If you've declared const x = 1, then that will hold for your scope?

If you go into a separate scope... Well, then you're in a separate scope?

Neither of those rebind the `const x`, which will continue to hold the value it was given.

The const keyword has absolutely nothing to do with state mutability, that is a misconception. const in es6 is a keyword meant to explicitly prohibit identifier reassignment and it does indeed reduce bugs because it communicates developer intention regarding how a variable reference is expected to behave in a section of code. Further, use of const by default is a best practice because it leaves less room for error in cases where a reassignment must never occur and increases readability by convention of the let keyword signaling that a reference will behave in a volatile way in proximal logic.

My whole argument was premised on const not having anything to do with mutability.

By waste of time do you mean performance or coding time? I feel like writing a character more is not a waste of time, if you are just following the convention that anything that is not going to be muted should be signed explicitly. It's not to prevent bugs, but for readability and ease of use.

Time deciding if you can/should rebind a variable or not is a waste of developer time.

You will know ahead of time whether you're going to be rebinding a variable. The use of const is a hint to the next person reading your code, since they won't be privy to your thought process.

In an ideal world, const would be the default, and you would have to opt into non-const.

Then when you will have to change or debug the same code instead of writing new, you will have to spend more time understanding what variable is the source of a state change, for example inside a loop. That is more of a waste of time to me.

I sort of agree; I solve this by never using let and never rebinding :) No need to think about it at all.

Then you end up playing this game of jumping through hoops to omit variables. It's a tempting waste of time because it feels productive.

Strangely it turns out that rebinding variables is a really uncommon need, so there's pretty much zero game playing.

> There are bugs caused by mutatable state.

> There has never been a bug caused by reassigning a function local variable while leaving it mutable.

The latter _is_ mutable state. const doesn't prevent all mutations, but it does prevent some, while let prevents none. I'll take the limited protections of const (with awareness of its limitations; many examples of let are of confused devs trying to avoid making their objects immutable).

I'm with you. Though typing `if (a = 1) {}` happens to me sometimes, and const may catch this earlier. I don't use a linter anymore, but I suppose any serious linter would warn about assignement in a condition, anyway.

Why have you stopped using a linter?

The popular airbnb eslint rules[1] require the use of const where a variable is not reassigned, which I've occasionally found handy.

[1] https://github.com/airbnb/javascript#references--prefer-cons...