This is, IMvHO, such old news that it feels... weird to still read about it in a year with the prefix of 20.
Every programmer who has ever single-handedly written a 100,000+ LOC software system will tell you the same thing: shift as much responsibility on the compiler as you can and have the compiler check the code you write to any extent technologically possible.
Getting rid of bugs by experiencing, diagnosing and fixing them takes at least ten times more effort than getting rid of bugs by not making them in the first place, through expressing the problem at hand with a strong type system.
When you also consider the never ending necessity to introduce change to an already written software system, thus the necessity to refactor code (in the sense of altering the previously assumed meaning of its idioms), the critical advantage of a strong type system becomes self-evident.
(Yes, Rust 4ev3r! ;))
I’d take this further.
I was listening to the John Carmack episode of Lex Fridman from the summer, and he makes a comment about being frustrated that in the Valley there’s an almost religious opposition to IDEs, debuggers, and static analysis.
Some of those tools have only become more powerful over time and I’m perplexed as to the mindset that would make a person averse to automating the drudgiest parts of their job in a career that is almost entirely based around automating things.
When I graduated college in the '00s I thought Vim was the most amazing thing I'd ever learned. Then a colleague at my first job showed me what happend when you typed . after a variable name in Visual Studio. Code completion, inline documentation...my mind was blown, and I never looked back. When I meet a young chap extolling the benefits of Vim or Emacs or really anything that doesn't have stepped debugging and code competition...well, there are no bonus points for doing things the hard way.
Kudos on the people who have ported this to Vim[2], but I suspect the support for LSP features will still be better in VS Code