What made me switch to VS Code (after using Emacs for 30+ years) was that I got tired of just how much of an easter egg hunt Emacs is for me now.
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)
Vim has more users than Emacs and lately neovim gained a lot of traction; they managed to coordinate the community on a direction, ask for money, fund a new generation of programmers to learn the codebase and update it to be async and use a different script engine.
Emacs has had several efforts at replacing elisp or rewriting the core in rust or what have you... But they've never been able to budge the local maximum nor coordinate the community on the new direction. Actually, I believe guix is the new emacs because..
Neovim has succeeded in retiring vimscript for lua and from there a community is emerging around fennel (a powerful lisp that compiles to lua). This is the beginning of a very interesting answer to emacs which is growing fresh from old roots and there seems to be a lot of people eager to build tools with these tools.
Although I tend to think the brand value of vim and Emacs is worth a lot I'm starting to see a lot of new editor projects that look somewhat appealing but until the packaging and configuration management gets at least an order of magnitude easier I'm reluctant to spend time with these things.
Its worth remembering that Visual Studio also used to be regarded as really good right up until it... wasn't, and then with VS code is sort of was again. Except right now it kind of isn't.
The fate of VS code seems to be really closely tied to TypeScript at the moment. If it turns out that Types really are the way forward, then these will eventually be included in the JS core. What then for TypeScript? Who even decides?
The nice thing about Emacs is that it is firmly rooted in standards and consensus. It will never be the best editor for most people at any one moment in time, but it has been a _good_ editor for decades and will continue to be so for decades to come.
>The fate of VS code seems to be really closely tied to TypeScript at the moment.
That's like saying the the fate of Emacs would be closely tied to Common Lisp (or Coq with Proof General). That's some languages Emacs where still beats anything else.
> support for TypeScript will always be best in Microsoft's Visual Studio.
That typo is actually the problem. If they don't decide to make TypeScript a Visual Studio feature.
But my point is that VS Code would not be an alternative to Emacs if you could only use it for TS and Emacs wouldn't exist any more, if all that you could do with it was programming (Common) Lisp.
Wouldn't it make more sense to design browsers where a WASM runtime interacts with the DOM (and architecturally make it look more like a device driver)? And you could just compile JS to WASM on demand (and possibly keep a cache).
> If it turns out that Types really are the way forward, then these will eventually be included in the JS core.
Not necessarily? TypeScript could easily continue being its own thing as it is now, and ECMAScript have shown absolutely 0 interest in adding types to the core language a-la TypeScript. Infact, the amount of work needed to enable types (supporting new syntax) would result in so much backwards compatibility breaking that it wouldn't even be feasible.
TypeScript is way more likely to remain its own thing.
It shouldn't be a controversial position to say that perhaps something cobbled together by an inexperienced language designer in a matter of weeks, five or six internet lifetimes ago may not be a good long term bet.
I wish browsers would set an EOL for JS support and just get on with WASM. Of course, that's never going to happen.
> I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
Emacs is really short on core developers, and core development is hampered by the de-facto requirement that no aspects of user experience should change by default for longtime users with no out-of-core customization.
That said, the improvements in Emacs 28 are tremendous. The biggest is the native compiler, which will AOT compile Emacs Lisp code to native code, so lots of things that used to be slow are now very fast. Native JSON parser (maybe was added in 27?) means that LSP support is very fast. Pure GTK frontend didn't make it into 28, but will probably make it for 29, and means that Emacs on Wayland doesn't use X11 anymore.
What I'd like to see is a "standard distribution": something not as opinionated as Spacemacs or Doom Emacs, but which will apply more modern defaults, and have something similar to the Spacemacs "layers" feature, where there's a standard, supported way to enable the needed packages for a language or common workflow.
Very different experience for me, working with Go using Emacs has been pretty smooth sailing from day one (which for me was around the Go 1.0 release).
go-mode with godef, goimports and oracle was great during the early years. I remember telling people how the simplicity and quality of tooling and the great Emacs support around them was one of the reasons I enjoyed working with Go.
The transition to module support was a bit of a pain but that was a question of updates to the tooling, not Emacs itself. And then LSP came along just around the right time to deal with that and everything else.
Other than Elisp itself and Common Lisp (SLIME) I'd say Go is my favorite language to work with using Emacs.
Edit, looking at the timeline Go 1.0 was March 2012 and it took a year before we had go-mode with godef support. I guess I managed until then, it was simpler times in the Go world.
This is unbelievable to me who has been emacs user for this long. What i have seen so far is people whos customize heavily and use as a way of life or people who don't like after trying for some time and move away to other editors. There is another category of people who use for a specific purpose regularly(like org mode users) without making any customization or learning elisp. But your case is special. What is your level of mastery in emacs and elisp?
I used to have a decent working knowledge of Emacs Lisp, but I wouldn't use words like "mastery". I could get stuff done. However, I haven't done any development in elisp for at least 15 years. Think of it has car ownership: I might have been interested in repairing my own car in the past, now I just want a car that does what it says on the tin and not have to futz around with it.
I used to have a highly customized Emacs setup with a lot of code that would automate lots of tasks for different programming languages and environments. I essentially ended up using an email reader that I found somewhere and then rewrote to include a lot of automation of the way I did my email.
Of course, things changed over time. My customizations started breaking - more and faster each year. I went from having my email delivered on a traditional mailbox file, to using IMAP. Along the way I had to use POP (because I could emulate having a mailbox file) the client needed a major rewrite to deal with IMAP and in the middle of the rewrite I gave up because something else broke. I have always worked on multiple machines, so I had to synchronize setups - sometimes between machines with different emacs versions.
I used Emacs for fewer and fewer things until it was only used for writing code and markdown files.
Heavily customizing anything is risky because at some point you become the sole maintainer of a lot of code. At one point I'd spend perhaps 2-3 days per month programming Emacs Lisp - which, at the time, was not all that great.
I don't customize software I depend on that much anymore. Including keybindings. It is cheaper to try to learn defaults, and if you put your ego aside, usually not that big of a deal. This doesn't mean you can't add functionality or customize it - it just means you shouldn't have to rewire the innards to accomplish it.
Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride. And more so the more you customize. Things are a bit too "freeform". You end up saying no to a lot of things you could have had for free because things start to clash with your customizations. "You broke it, now you own it".
I have a very clear benchmark for what might bring me back to Emacs: be able to set up Emacs from scratch in 10 minutes so that I can program in Go, have good language server support, easy access to documentation, and a lot of the things I used to have before, but which simply rotted away over the past few years.
....and then not have it break in a way that requires more than a couple of minutes of my attention for a year.
> Sadly, in Emacs, "extensions" are, to put it mildly, a rough ride.
That's because you (and each extension) has access to 'the' editor itself, whereas with for example Code, the plugin API is limited. Yes, you cannot change everything, but you also cannot break everything.
If we are to believe that the states of the two editing environments are the products of this distinction (yes, wild oversimplification, but bear with me), I would say that we kind of know which way produces the greatest good for the most users?
I presently use VS code at work as well, but not because it so nice, but rather that I can setup it from scratch to the tolerable state within 20 minutes including extension installation time and it works very similar on Linux/Mac/Windows (I need to work on all platforms and cross-platform functionality is a must). Plus it works on huge source tree like Chromium with fast file opening and whole tree search with almost no setup (VS Code hits some default limits on amount og Git modules, but that can be adjusted).
I stopped using Emacs like 10 years ago after realising that if one needs over 1000 lines of init.el then I am not the target user of the editor. I tried to reduce that via using external packages, but that has not helped much.
And for hobby projects I am happy with Geany on Linux.
This is why I've been using Spacemacs as my primary editor for years now: cross-platform support, automatic language detection, package installation, well-designed key bindings, great documentation, etc. Not to mention significant productivity gains from packages such as magit (it's always fun when people see Git time machine in action--using the n/p keys to move backwards and forwards in time to see every change to a file, along with the commit message).
And it works across all major OSes. Just copy your .spacemacs file to a new laptop, and wait for everything to install itself.
To be fair, I use VS Code pretty regularly as well. But more of a nicer alternative to TextEdit/Gedit/etc. to capture notes as I work in Spacemacs (of course, there's also the helpful scratch buffer).
The point is not to spend time writing init.el in the first place. I only need to setup few times per year and the time I spent writing my init file for Emacs is way bigger than I can save even in 100 years of using VS code.
Some people enjoy hacking their configs, but for me the changes were due to Emacs defaults not to my taste. So I got no pleasure in writing the thing.
I have not bothered to use sync as I can setup VS code fast enough without it. Plus there are settings that require platform-specific adjustments. Maybe there are some ifs in the config that covers it, but I just see no point to spend time figure out it when I know I can spent 20 minutes max few times a year and do the setup from scratch.
Go support is one example. If you set up Emacs to provide decent support for Go at different times between 2015 (when I started using Go) and today, the setup would probably last an average of 18 months or so before you lose something significant and had to sit down and bodge something together to get some replacement for functionality that just died.
I can't remember what specific functionality had just died, but I was in the process of re-doing my Go setup from scratch for the third time or so when I figured I'd give VS Code another spin.
Could that have to do something with changes in go tooling (something that you alluded to in your original comment) rather than emacs itself? I am sorry I am not familiar with the go ecosystem at all.
In my own experience, emacs developers generally have the exact opposite approach and strongly resist any changes that may break existing user workflow. Of course, externally maintained packages might take a different approach because they are developed independently of emacs.
Even if you are not yourself interested in emacs development, you can contribute by just making bug reports for these missing features or breaking changes in the packages that you use. That's just being a conscientious open source citizen.
Assuming that you are talking about Go, I don't know where you are getting that from.
Go has had excellent tooling from early on. Standard code formatting with gofmt from day 1 was HUGE. godoc, godef, goimports and oracle were also available from early on. And then when LSP came along we got multiple LSP server implementations fairly quickly.
I don't have a link around but I am fairly certain that getting the basic tooling into shape was one of the priorities before the 1.0 release.
Setting up Emacs reasonably for Go development just isn't even close to being straightforward. And with Go, go tooling and Emacs continually being changed, any setup that works will eventually stop working and you have to try to figure out how to rewrite your configuration. This happens often enough that even someone like me, who really, really didn't want to ditch emacs, eventually may do so.
I appreciate all the work that has gone into Emacs, but the feeling I get is that the project lacks enough active developers and/or the focus misses the mark. I see version numbers going up - I don't see visible improvement.
The goalposts moved. They are farther afield. Expectations of what an environment has to offer have gone up. If a decent developer experience isn't an understood priority, then Emacs isn't going to be very attractive for new developers. And it may have problems both attracting new users and developers and retaining new developers.
(That being said: VS Code is apparently going through a rough patch where things have gotten really buggy if you use it for Go development. So it isn't like VS Code is a magic bullet)