The Emacs Lock-In Effect or the Emacs Sunk Cost Fallacy
I&#x27;ve used Emacs for 32-33 years and I can&#x27;t even imagine how many lines of code I&#x27;ve written in it.<p>Every 2-3 years since the early 2000s I would try an IDE for 1-2 months, but then go back to Emacs again because I was simply faster in Emacs and because the IDEs were supremely ugly, resource intensive and slow.<p>A few years ago things started to change.  IDEs started to become less clumsy.  Less horrible to de-fang to the point where they became tolerable. They might have gotten a bit faster too.<p>Then some time around february this year I felt it was time to give IDEs a try again so I spent about a week configuring VS Code to where it was tolerable.  Mostly by removing visual noise.  All keyboard bindings etc are standard because I think you ought to learn how to use a tool as close to its default configuration as possible because that means you can make use of the knowledge of other people.<p>Now, about 6 months later I think I might stick to VS Code for programming in the foreseeable future.  Here are some reasons why:<p>- The support for various languages in Emacs just isn&#x27;t being maintained.  Every so many months my setup for Go would break hard, and along the way small things would constantly stop working and I would have to figure out &quot;what the heck happened now&quot; and hack my way around it.  Or shrug and say &quot;okay, so that&#x27;s gone&quot;.  This was no different in C&#x2F;C++, Java and other languages in the past.<p>- Emacs doesn&#x27;t have a sufficiently large active developer base.  Not only does this lead to poorly maintained language support, but it kind of goes against one of my basic rules for choosing tools: no marginal stuff(1).  And Emacs has become marginal.  So while I love Emacs, it no longer qualifies as a viable tool in my eyes.<p>- Emacs isn&#x27;t going to catch up with VS Code.  And I don&#x27;t think many long time Emacs users want to.  They just want to be left alone.  Emacs has too many failed attempts at making configuration and adding third party code work well (it really doesn&#x27;t) and even work with the reams of elisp code each of us tend to end up with after years of trying to get broken stuff to work.  Enough for us to develop Stockholm syndrome and thing we want all this chewing gum and duct tape holding things together.<p>- I don&#x27;t like JS and its derivatives (like TS) and my dislike is almost militant -- but it beats elisp hands down on every metric that actually matters in the real world:  chief among them the number of decent developers who will write and maintain extensions.<p>As I said, I still love Emacs and I&#x27;ve written close to 100% of my code in it for 30+ years.  But I&#x27;ve kind of arrived at the conclusion that it isn&#x27;t going to evolve fast enough for it to be an attractive option.<p>VS Code is far from ideal.  For one it is written in a language I detest.  But it is better for programming Go, and C++, and C and probably java (I haven&#x27;t written a line of Java for 4 years so I don&#x27;t know).  Yes, it has shortcomings, but fewer than Emacs if your focus is to be a productive programmer and not muck about fixing poorly maintained bits that suddenly stop working.<p>If people think 30+ years of using Emacs represents an investment they can&#x27;t afford to throw out I seriously doubt they have really tried. I also think people underestimate their own ability to rewire their brains.  I turned 50 this year.  I&#x27;m extremely conservative when it comes to tools, languages, operating systems because I&#x27;m just not that interested in wasting time tinkering with my environment: if it works it doesn&#x27;t need messing with.<p>If I can get comfortable with a different environment for programming in a matter of weeks, so can anyone else.<p>(1) I try to avoid using tools and software that has too few users.  Sure, there may be better tools, but tools with small audiences tend to not be well maintained over time.  Few users also means fewer solutions you can find online to problems you might have.  Pick tools that have large audiences and you will find people that have had the exact problem you are trying to solve.  I apply this when choosing OS, language, hardware, tooling etc.