
Ask HN: Is Visual Studio Code the Emacs of 21st century? - gsaga
I would state up front that I&#x27;m a vim user and don&#x27;t have much experience with either emacs or vs code. But as a product, both of them appear to be quite similar:<p>1. Programmable<p>2. Configurable<p>3. Can be used for programming in a variety of languages and frameworks<p>4. Bloated(?)<p>Hell, there&#x27;s even an org mode plugin for vs code!<p>So, is it reasonable to view vs code (and atom?) as the successors of emacs, or as the emacs of modern day?<p>And if I&#x27;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-...](https://code.visualstudio.com/docs/extensions/example-hello-world)
\- 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
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
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
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
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](https://github.com/jwiegley/use-package)

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

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

------
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...](https://github.com/stokito/fortress-
langhttps://en.wikipedia.org/wiki/Fortress_\(programming_language\)) and
Chapel (Cascade High Productivity Language) [https://chapel-
lang.org/](https://chapel-lang.org/)
[https://en.wikipedia.org/wiki/Chapel_(programming_language)](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...

------
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
> 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](https://github.com/gregsexton/ob-
> ipython)

------
neurotrace
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
How exactly do they "try to keep extension authors from destroying the
editor"?

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

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

~~~
jjeaff
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
It's not open limitations but about extra Microsoft spyware included and
making you agree with Microsoft Privacy Terms
[https://code.visualstudio.com/License/](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.

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

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

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

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

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

------
comonad-colaboy
You forgot it's lispy base

