Ask HN: Is Visual Studio Code the Emacs of 21st century?

vim/emacs + ssh - editing directly over remote file system. I think this use case is why people keep using vim/emacs.

VSCode isn't anywhere near "open" enough (plugin APIs may be lacking). For example: the VSCode vim plugin is one of the worst of any major editor, while the Emacs version (Evil) is arguably the best implementation of vim period.

Atom is much closer to Emacs; nearly all the functionality is provided through optional packages, and it's very open to little tweaks to make it just the way you want.

>But as a product, both of them appear to be quite similar

Not at all. Not even in the same league. Emacs is the Emacs of the 21st century. Vim is a text-editor and never claimed to be an IDE, so I don't understand the "lying to yourself" bit.

As others have said, it definitely is not. VS Code is somewhere between Emacs and Visual Studio. Not quite as configurable as Emacs, not as tied down as Visual Studio. VS Code is my editor of choice today and part of that is that they actively try to keep extension authors from destroying the editor, like what happened to Atom. Emacs does not do any sort of hand-holding and so it provides a more customizable experience at the expense of, in my opinion, ease of use. I only used Emacs for about a month before switching over to VS Code so take what I say with a grain of salt.

So long as 99.9% of vscode users are using a proprietary distribution, I wouldn't consider it comparable to emacs.

Emacs is Emacs.

Does VSCode have something like Emacs' .emacs / .init file? In one file I can load all the plugins I want and write custom code for added functionality. Rather than having to rely on other people writing a function I need, I can just hack away on my .init file to modify existing functions / create my own.

Now of course in VSCode you can create your own extensions and load it into the program to add your own functionality - but the barrier to entry for any editor (besides Vim) is much higher than Emacs. Looking at the documentation here: https://code.visualstudio.com/docs/extensions/example-hello-... - that's a lot of code and things to do to get a hello-world application working in VSCode. In emacs, that would just be a couple lines of elisp in .init.

Even if VSCode has something like .init (I got this from someone on Hacker News) - it's better to think of Emacs as basically a framework for text editors. You're able to change every single part of the application - VSCode and other editors don't hold a candle to the configuration of emacs.

VSCode isn't the successor to Emacs or a modern version of Emacs - it's just VS Code. Emacs is Emacs.

I've used both editors myself, really the best way to get what I'm saying is to use Emacs for a while until you get comfortable with it. My Emacs configuration is something I cherish and it's a joy to use everyday.

Besides programming, I use it for taking notes, a todo list, a journal, etc. Some people even use it for keeping track of finances, for drawing diagrams, for creating slideshows, etc.

All this spotlight on VS Code and no mention of Sublime Text? I view Sublime Text (even though there is a license fee) as more emacs like than VS Code. I side with others to say its no where near Emacs because Emacs is Emacs. My most cherished Sublime Text plugins began as an Emacs extension (xiki). So I would say Emacs is important to the ecosystem but there's no way Product X will be an Emacs of the 21st century.

I use VS Code. Mostly for frontend stuff. It can bork on large files. Especially if they contain lots of inline binary data. And Intellisense works probabilistically across javascript dependencies. But generally positive the experience has been.

Tangential to IDEs are tools for data science and visualization. Having a shareable workspace, akin to Azure Notebooks, can be much more user (and scientist) friendly.

Another area where I think there is potential for innovation is branded cloud IDEs that actually understand cloud native development. Not just an editor, debugger, and console. But a single interface. Where you set load balancing, firewall rules, make data queries, analyze log traffic, etc.

Emacs is the Emacs of the 21st century. VSCode is not even close to an Emacs. Part of the difference is that it's trivial to modify and customize Emacs in Elisp -- so much so that in the 1970s, secretaries were using Lisp to customize Multics Emacs, an ancestor to present-day GNU Emacs -- because Emacs is a living Lisp image tgat happens to have editing facilities bolted on. You can adapt the editor to your workflow as you work. Developing extensions for VSCode, by contrast, is a bit more involved.

I've given VSCode several tries. It is slick, and fast for an Electron editor. But I've done all of my best work in Emacs for over a quarter century, and VSCode just doesn't offer enough advantage over Emacs for me to unlearn my Emacs skills and learn how to do everything under VSCode.

The Emacs of the 21st century is undoubtedly Emacs.

Emacs has modes for every cutting edge advanced research programming language imaginable.

I wanted to use some languages from the High Productivity Computing Systems project and found that Emacs was the only editor with support for Fortress https://github.com/stokito/fortress-langhttps://en.wikipedia... and Chapel (Cascade High Productivity Language) https://chapel-lang.org/ https://en.wikipedia.org/wiki/Chapel_(programming_language)

Sadly, Visual Studio Code appears to be the Visual Basic of editors for the 21st century.ie: popular and easy to use, but used by a certain kind of developer...

One of the nice thing about emacs is that I can use the GUI with all modern features and still have the same keybindings and features when working on a remote server/computer. Even if emacs was huge before I was born, it is very lightweight for today. Atom and VS code are built with electron, which makes them much slower and heavier on RAM. Visual Studio is like a proprietary notepad++ with a gigabyte per feature it has over notepad++ (C++ compiler, Python tools, etc.).

Emacs has been around for over 40 years now, VSCode and Atom for less than 5 I think. There are many great things about VSCode et al, things that Emacs doesn't have and likely won't anytime soon (mostly envious about the Blink rendering engine).

I've considered switching but I'm not convinced it'll still be the best in a few years. I could totally see someone making another web-tech based editor that has a more universalistic design like Emacs.

I'm still hoping somebody will fork Emacs and figure out how to bolt a nicer renderer, threading[0] and better GC onto it.

That said if you haven't already bought into any ecosystem I think VS is a great choice.

[0] this one is not realistic I guess but whatever

In am a fairly loyal Emacs user, having bought the manual from FSF decades ago when that was a meaningful source of revenue for the FSF.

Now, I only use Emacs for org-mode, and for Lisp languages (Common Lisp, Scheme, and Haskel - which I consider a lisp language).

For just about everything else I now use VSCode. Recently when I discovered how even the symbolic debugger works great for Python, Java, etc., I let my yearly subscription to all of the JetBrains products lapse next year when my subscription runs out.

Love VSCode (and Emacs).

In 10 years, no one will remember VS Code. There will still be people using Emacs though.

40 years from now, you will still have emacs and vim packaged, ready to be installed or installed by default. Not sure if any other of today’s editors will be around.

There's a big market gap between terminal text editors and GUI editors. For me, a GUI editor is a non-starter.

I do think that emacs, vim, visual studio code, et al. fall into the "not quite an IDE, but not just an editor" category.

Also through the power of LSP, vim can do anything an IDE or visual studio code can.

for me vs code was easy, effective and efficient step from vs pro with notepadpp to something more like emacsvim. i do full time dev unity for dotnet core and dotnetcore for last month.

You forgot it's lispy base