That is a double-edged sword. On one hand it makes sense because it allows teams to be more productive. Otoh, it leads to this decade where it has become okay to create a desktop application using HTML/JS (while more performant tooling exist) simply because a lot of people happen to know HTML/JS than C#/.NET, Qt/C++ etc.
What should be just one of the factors has become the most influencing factor.
It's true that performance is often ignored for no good reason at all, but it's not such a pressing concern for most applications. Very little software needs to be performant to the point that what language it's written in even matters.
VSCode is not performant, especially on startup and especially when compared to editors like vim or sublime text. I agree that the reason likely isn't language choice though it's the use of electron. I don't agree with you about software not needing to be performant either, I believe developers should strive to make their software run as efficiently as they can.
This is not realistic. Performance doesn't just happen. Within limited constraints, focusing on performance will necessarily imply less feature.
Ultimately, it's about balance. Personally I find VSC's performance to be good, and at lot of other devs find it at least good enough (it's a widespread editor). I've actually switched away from ST3 because the development of their current version stagnated, and there are unresolved bugs and limitations that affected my everyday usage.
In other words, the performance/features (and let's throw flexibility) balance of VSC is, for me, better than ST's (others may have have different requirements and different balances, of course).
Ultimately, VSC is a bad example of tradeoff performance/ease of (internal) development. If people wants to find an example, Slack is by far the best (worst).
But that's a difference between developers and engineers
here it is compared to qtcreator. it is so damn frustrating when you are used to computers responding near-instantly to have something that... takes its time or stutter to say the least
I really dislike having to use microsoft stuff. No, I don't want to install the app. no I don't want to enable what you think I should enable. No I don't want cortana reading my email messages. No I don't want to use your OTHER product too.
Start with good engineers who understand CS fundamentals. After a week or two of immersion, they’re passable in a new language. After a month or two, there’s basically no difference with a veteran.
Okay, sure there are exceptions with very different paradigms. Kotlin devs may take more time with low-level memory managed C code. C hackers may struggle with Haskell. But Pythonistas can write pretty good Typescript in their first week.
In contrast starting with wrong tool for the job, just gets continuously worse as the project progresses. The friction of constantly cutting against the grain is an accumulated drag. As the project grows more complex, the kludges and workarounds become an increasingly heavy burden on a day-to-day basis.
A good lead will demand good code and support it with mentoring, pairing and time to refactor.
It still doesn't give them license to do tech for the sake of tech. Every architectural choice and added complexity has to be justified by the value it brings.
But programming for the lowest common skill level on a team is generally a bad idea.