When yarn/react/next.js/amplify breaks in some new and idiotic way, Claude is helpful more often than not. Why spend hours googling and sifting through github/stack overflow/etc when Claude can tell me what option to tweak to fix it in a fraction of the time?

Boring, tedious shit that doesn’t require brainpower, just time, when fixing whatever comes out of the LLM is less annoying than doing it myself.

IMO that list is the obvious answer to “which packages can’t be removed without breaking the system”. Sufficiently obvious that I consider your insistence on specific “requirements” to be obnoxious. Though for that specific phrasing I would not include the terminal emulator or file browser. Using a system without them would be annoying but entirely doable.

I thought it was clear I was saying JavaScript is not a sane language for this very reason

Sure, there are worse languages and environments to get stuck with. But I can avoid those jobs. And if I get hired as a SomeLang developer and they force me to work in Java or whatever, it’s time to dust off the resume.

async/await infecting all of my code, being unable to create a get myField() method that involves a hash calculation. It may be standard to do heavy lifting concurrently, but async hash functions are certainly not standard in any of the languages I've used (which is quite a few).

It’s hard to distinguish whether a line is wrongly indented or not.

That’s very much not my experience. I use YAML regularly and while I’ve had copy paste indentation errors when I look at the offending line it’s always obvious to me how to fix the indentation. The only indentation thing that’s ever given me trouble is embedding YAML as a string within a file that uses tabs.

I agree that it is a very useful skill to know how to use the CLI. I agree that every senior developer should know how and every junior should be capable of learning. I vehemently disagree that developers should use the CLI as their regular means of interacting with Git if that is not their preference.

*when I'm doing debugging that requires commenting out code.

Most of the time, I don't comment out code. I run the code in a debugger, step through it, and see how the behavior deviates from what I expect. I mostly only resort to commenting out code if I'm having trouble figuring out where the problem is coming from, which isn't that often.

I'm definitely biased because I love the language, but I think Go is a good place to start. The authors talk about the language design more than I've seen for other languages. The Go blog occasionally has posts like that but Russ Cox's blog is the place to go for the gnarly details. Another good place is the proposals repo, e.g. the generics proposal. I also browse issues on GitHub and look for ones with interesting discussions.

including the syntax, which I know most nerds dismiss as superficial.

Syntax is mostly irrelevant as far as what is possible with a language, but it is a critical aspect of how easy/hard it is to use a language, and most critically how easy/hard it is to read code written in that language. IMO the only thing that's more important than readability is whether the code works as intended.

You get used to it. The only time I really notice it these days is when I’m debugging and commenting out code.

Did I find another Sanderfan in the wild?