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

[gsaga]

I would state up front that I'm a vim user and don't have much experience with either emacs or vs code. But as a product, both of them appear to be quite similar:

1. Programmable

2. Configurable

3. Can be used for programming in a variety of languages and frameworks

4. Bloated(?)

Hell, there's even an org mode plugin for vs code!

So, is it reasonable to view vs code (and atom?) as the successors of emacs, or as the emacs of modern day?

And if I'm thinking about jumping to something more feature rich than vim, should I jump to emacs or vs code(atom?)? I know that vim can be made feature rich with plugins, but you are lying to yourself if you say that vim can do anything an IDE can.

[bashmydotfiles]

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.

[lerax → bashmydotfiles]

I'm glad to see a sane comment here. Emacs is Emacs. Vs code is yet just another editor.

[bitwize]

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.

[GeordiePowers]

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.

[snazz → GeordiePowers]

Agreed. I use Evil exclusively (effectively pretending that I’m using Vim, except that I get to use the awesome features that Emacs has for programming in Lispy languages) and would love to start learning Emacs proper, except that Evil is so good that I really don’t need to.

Atom feels sort of like Emacs except that you have to deal with JavaScript instead of Lisp. I prefer using Elisp over JS, and Emacs is much faster, and Emacs works without an X server, and Emacs has a better Vim mode. Until one of the Electron editors can compete, I’ll stick to Emacs with Evil.

[codyb → snazz]

ViM user here who used SpaceMacs for a while for Clojure development.

I'm not sure if SpaceMacs uses evil but it's a similar concept. That being said, I tried learning regular Emacs to see what the fuss is all about and much prefer modal editing to pressing control constantly even with caps lock mapped to control.

Your mileage may vary but if you're already editing quickly modally and have all the features you like in Emacs I'm not certain there's much upside to learning how to do a lot of the same stuff the Emacs way.

Tmux plus tmuxp was a much greater improvement for me. Being able to restart iTerm2 for updates and maintain all my sessions, no rage after accidentally quitting a session, and writing short and simple tmuxp yaml files to launch a whole environment with one command is really awesome.

I enjoy the ViM mode in IntelliJ which I assume is similar to the one in Visual Studio Code, but mostly I prefer the terminal. Everyone loves VS Code that's for sure, so they must be doing something right!

I'd probably actually write plugins for ViM if it used Lisp and in a way I'm kind of glad I don't want to learn ViMScript as I've already spent so much time over the years playing with my vimrc as it is.

[sirn → codyb]

Spacemacs does indeed use evil.

I found Spacemacs to be great starting point for someone new to Emacs, but after a while I highly recommend extracting your workflow from Spacemacs to vanilla Emacs.

Thanks to use-package[1] (that Spacemacs also uses), most of the extracting would be just copy and pasting things from Spacemacs repo. The hardest part would be figuring out which package is responsible for which functionality. A starting point would be just put this in ~/.emacs.d/init.el:

    (require 'package)
    (setq package-enable-at-startup nil)
    (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/"))

    (package-initialize)
    (unless (package-installed-p 'use-package)
      (package-refresh-contents)
      (package-install 'use-package))

    (eval-when-compile
      (require 'use-package))

    (use-package evil
      :ensure t
      :config
      (evil-mode t)

And now you got a working vanilla Emacs with evil auto-installed, ready to be put in VCS. After extracting work is done, it will open up a new world of customization (even a low-level things such as replacing package.el with straight.el[2] to enjoy configuration reproducibility) as you now know exactly how every piece fits together. :-)

[1]: https://github.com/jwiegley/use-package

[2]: https://github.com/raxod502/straight.el

[arduinomancer → GeordiePowers]

Agreed. Had to uninstall it as somehow it became so laggy to the point of there being a 3-5 second delay between typing and text showing up in the editor.

[Ice_cream_suit]

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...

[tehaugmenter]

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.

[ry_ry → tehaugmenter]

I've always been a huge fan of sublime, i use it daily as a text editor. It's largely a visual clipboard for me.

However as a development environment its lacking. The interface for installing and configuring plugins is needlessly arcane, and whilst it's fast I find myself defaulting to vscode for pure productivity reasons. I don't even particularly like vscode - largely electron snobbishness tbh - but it's the best to for my particular job (frontend dweeb for a well known site with a very modern stack)

I've used intellij, visual studio, vscode, sublime and dozens of other apps extensively professionally as my day to day (eclipse and atom were low points) and all have their merits but as a fast, easy, cohesive environment that is easily setup a combination of zsh and vscode is absolutely my goto the days.

Edit. People calling vscode bloated does amuse me though. it's not exactly vim but it's a million miles away from its bigger brother.

[antoineMoPa]

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.).

[throwaway8879]

>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.

[gsaga → throwaway8879]

Well some people claim that vim can do whatever an IDE can, which is just not true. That comment was directed towards those people.

[hatsubai → gsaga]

I believe they're referring to the fact that vim + the OS itself (generally some flavor of *nix) can do whatever an IDE can do. From a terminal, one can call vim, gdb, valgrind, navigate file trees, utilize grep for searching codebases for a string, and so on.

[auganov]

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

[mark_l_watson]

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).

[ArtWomb]

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.

[d0mine → ArtWomb]

> tools for data science and visualization Org-mode with code blocks could be used to run code and display its results e.g., ob-ipython https://github.com/gregsexton/ob-ipython

[zelly]

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

[mcluck]

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.

[gtklocker → mcluck]

How exactly do they "try to keep extension authors from destroying the editor"?

[bitwize → gtklocker]

VSCode extensions are sandboxed and can only call routines from the provided extension API.

[atmosx]

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.

[sethish]

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

[jjeaff → sethish]

The only thing proprietary about the main distribution of be code, that i can tell, is the configuration. I'm not aware of any differing functionality or limitations on the open source code. MS states that their distro is the same code but with their own configuration in the product.json file.

[Natela → jjeaff]

It's not open limitations but about extra Microsoft spyware included and making you agree with Microsoft Privacy Terms https://code.visualstudio.com/License/

"The software may collect information about you and your use of the software, and send that to Microsoft. Microsoft may use this information to provide services and improve our products and services. You may opt-out of many of these scenarios, but not all, as described in the product documentation."

[ilovecaching]

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.

[dlahoda]

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.

[diimdeep]

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

[bashmydotfiles → diimdeep]

There's also tramp mode for emacs - where you can set up a buffer in emacs to access code over ssh/whatever connection you want.

[sgillen → bashmydotfiles]

Yup, but I’ve had some issues pop up using that before.

I’m a longtime emacs user and this seems to be a common theme for me. I try some feature in emacs, it works great but breaks on some edge case or something, and then I have to find a workaround.

The advanatage of emacs of course is that you can basically always find and implement said workaround if you try at it.

[tln → diimdeep]

There's an extension for that :)

https://marketplace.visualstudio.com/items?itemName=rafaelma...

[Camillo → diimdeep]

You can use sshfs and any editor.

[comonad-colaboy]

You forgot it's lispy base