Your comment and the grandparent comment have both really validated me. I know that's weird to say, but I really thought I was just Wrong about the linters/LSPs and unfinished lines or unused variables. Thank you :)

Those that implemented the unused variable feature are completely unaware that there are two modalities of programming: exploring a problem space, and building a solid product.

When you're exploring, you don't want your compiler to stop you in your tracks to warn you about pedantic nonsense. It's not a syntax error that prevents your compiler from understanding, it's just arbitrary restriction that the compiler decides to pester your about, a sort of a robotic grammar nazi.

Computers are obtuse, the worst thing they can do is ignore your perfectly parseable and valid instructions for arbitrary reasons. Machine, if you know I'm not using a variable, kindly let me know and carry on doing your job.

I'm certain they're aware of the second modality; I just think that Go is narrowly focused in design and it's not really for that other kind of user.

it is vanishingly unlikely that ken thompson and rob pike are unaware that people sometimes program to explore a problem space

Ken's first language is pretty tolerant of programmer silliness, maybe too much.

do you mean ibm 709 assembly or what

i don't actually know what he was hacking on at berkeley

You are wrong, just like these other people.

You guys want to have your cake and eat it too -- to be correct despite being lazy and sloppy.

It makes no sense. Bite the bullet. Don't have unused variables. There's no such thing as "exploration". After you've "explored" enough (where "explored" means "coded sloppily"), you've quickly exhausted your mental buffer, and it's suddenly expensive to go back and polish what you've done, making yesterday's exploration today's (hopefully not too creaky) foundation.

It is trivial to ignore unused variables, early returns leaving dead code and so forth while editing and then check&reject them before applying to production. Fix whitespace in the same git hook.

This is one where faster local development (because you don't have to repeatedly, jarringly stop what you're doing and patch up something that doesn't matter) and clean source in a common repo are both possible and very easy to achieve.

But whatever. Yay go.

My hype for Zig died the day Andrew decided to push for that nonsense.

For it was the use of @, Objective-C style, and not having an answer for use-after-free.

If I need to use analysers to fix that, I already have those for C and C++ for the last 30 years.