Get the top HN stories in your inbox every day.
pronik
skydhash
VSCode is familiar in its UX. Here is the file tree, here is the editor. oh that's the terminal, or I can complete with tab, and these are extensions that I can install? And that's pretty much the extent of the interaction most people have with it. If it does not come out of the box or prepackaged into an easily extensible extension, they are not using it.
iLemming
> VSCode is familiar in its UX
That's by design. It must have appealing looks and employ every trick from psychology books to get you to try it and keep using it.
You don't have to be a genius to realize that a for-profit corporation with a $3 trillion market cap, spending millions on building a code editor with no direct licensing model; that they are distributing for "free" is not some kind of unseen goodwill; That shit eventually will generate billions in downstream Azure/services revenue. What is it if not a trivial ROI? It is a "loss leader" in traditional business terms, but a strategic necessity for cloud/services dominance.
VSCode is essentially a Trojan horse for the Microsoft developer services ecosystem - a mental prison that is designed to be easy to get in but hard to escape.
In comparison - vim/emacs have not a single profit motive; their network effect works differently; Yes, there's no entity with trillion dollar market cap to keep the pace with vscode, but no deprecation risks, no corporate pivot that ever is a treat to lock-in your data or your workflow or compatibility with older hardware. Vim & Emacs win by not being a loss leader for anything.
Who can ever predict what happens 5–10–20 years from now? Who can guarantee that some evil CEO wouldn't replace Nadella and secretly start implementing changes in the strategy that would change the essence and the meaning of being a programmer? It is already assumed that every dev has to use GitHub and to know VSCode at least on some basic level today. What if tomorrow your employers would be able to analyze your telemetry data to "measure" your performance? What if the use of anything but VSCode as the code editor would simply be banned?
nsonha
Does not take any coding ability configue it. Out of the box you can search for any setting and even if you edit the json config directly you get autocomplete.
kace91
Every piece of software that’s effectively a professional workbench (IDEs, DAWs, video editing, etc) is going to have some complexity.
I can’t imagine the argument that vscode’s level of complexity is even in the same order of magnitude as vim or eMacs though. A 2 minute tutorial or half an hour or fiddling will get you sorted with vscode, I needed a full ebook for neovim.
skydhash
VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.
kace91
What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.
My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.
For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).
slaymaker1907
You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.
pxc
I'm also a daily Emacs user. I'm no wizard; I've leaned on starter kits like Spacemacs and Doom my whole Emacs life.
Likewise, I find VSCode overstimulating and, for lack of a better word, rude.
I just tried setting up RustRover for a side project at work on Friday. It's my first time using an IDE since I was a Scala developer near the beginning of my professional career. I only had an hour or two to play, but I ended up unable to get a working run configuration, or at least one that showed me anything at all except sometimes when it failed. It was a lot of clicking around.
I'll sort it out next week, I'm sure. But pointy-clicky turned out not to be as ez-pz as I'd hoped it would be.
t_mahmood
IntelliJ shines when you use the command pallet, keyboard shortcuts, and IdeaVIM
Double shift, to bring up the pallet, and start typing. Though it also have a ton of shortcuts, and shortcuts can be assigned for almost every command.
Try this: https://plugins.jetbrains.com/plugin/9792-key-promoter-x/
Whenever you don't use keyboard shortcut for any action, this suggests you the available keyboard shortcut.
iLemming
IntelliJ is an amazing feat of software engineering, there's no denying that. I'm not saying that to make you (or any other WebStorm/Pycharm/etc. user) feel better - I know that from years of dedicated use.
I just want to share my anecdotal, personal story. I used IntelliJ professionally for almost a decade. I learned some advanced and undocumented features. I've collaborated with Jetbrains team members to help improving the features. It felt like I work for them. I still occasionally receive YouTrack notification emails for the bugs I posted circa 2009, that are still not fixed today, btw.
IntelliJ is to blame for why my transition to Emacs took me two years - I carried the fear of investing too much into a new thing. I feared of liking it, and someday not finding some features I was so attached to in IntelliJ. I was scared that I will be intellectually and emotionally "locked in", while I was already vendor locked-in and condemned to be using IntelliJ forever.
I was so wrong - not only have I found everything I needed, and more, I have developed a true hacker's mindset. Honestly, the only regret I still carry today, even after years of Emacs use, is that I did not attempt to learn it sooner. I no longer experience FOMO - I can easily pick up IntelliJ whenever I want again, I just haven't found a real, pragmatic reason to do so. In fact, I do fire it up on occasion, just to get the feel of how things evolving there, to steal some good ideas, etc.
> and IdeaVIM
Gary Bernhardt famously said - "There's no such thing as vim-mode". And to the degree, he was right - pretty much every editor/IDE that tries to integrate Vim features invariable ends up having glaring deficiencies. IdeaVIM is good enough, but only to the point - for an expert vimmer it may feel annoying. VSCode vim experience is similar, and Sublime as well - there's really no good comparison between them to say which one is really "better", they all have a spectrum of weird, quirky behaviors. There's one notable exception - Evil-mode in Emacs is fantastically good - sometimes you even forget that it's not a built-in feature, but a third-party extension, an afterthought.
> shortcuts can be assigned for almost every command
In Emacs, you can bind keys to anything, conversely - everything is a command - every keypress, every mouse click and mouse-scroll. And since Emacs is inherently a modal editor, you can do stuff like binding commands to a double, triple, etc. keypresses. Like for example, when I'm typing fast, to autofix most recent typo I'd just tap comma twice - this is just one example of unbelievably fast way to stay focused.
Most devs, once they find their favorite tool would settle with it and don't even explore other options. "I don't have time for that.", "I don't want to be building my editor", "I am already so good with what I have, why?", they would say. My suggestion is to always stay skeptical of current choices and curious about unknown. It's not the concrete implementations, but rather abstract ideas that may grant some surprising and unexpected benefits.
frumplestlatz
I’ve been using emacs for very many years, and have a configuration that has evolved over a decade.
I was able to pick up VSCode in an hour. It’s not complicated. I’m using it with the Haskell extension and it’s great.
Honestly, I’m tired of Emacs’ performance, bugs, complexity, and poor UI that requires an enormous amount of hacking to make a usable IDE.
VSCode is a breath of fresh air. The only things I’m not using it for are languages that don’t have extensions yet — Cryptol and SAW.
iLemming
> requires an enormous amount of hacking to make a usable IDE.
When you're using it for one, specific purpose, like an IDE for specific language(s), then yes, sure, it may feel like that.
Yet Emacs is so much more. It's not an IDE (but it could be); it's not [the best] source control tool; it's not [greatest] note taking app; it's not an [amazing] mail client; it's not [most beautiful] pdf reader; nor a [feature rich] terminal app; etc. Emacs is not even an editor, to be brutally honest. It's not the greatest concrete implementation of any of these things.
What Emacs actually is - it's a concrete implementation of an abstract idea - a Lisp REPL with a baked-in text editor into it. That, for a second, is an absolutely fascinating commodity. Once you grok the essence of that idea, it's really difficult not to see the extreme value of it.
I'm sorry, I just have hard time to believe anyone who says: "used it for many years... yet abandoned it anyway".
It typically means that they've been using it from a narrow, small focused point of view, without ever exploring the possibilities that "true" Lisp REPL can grant them. I just don't see myself ever escaping Emacs, because there's simply no practical, comparable alternatives to it. Comparing VSCode to Emacs is like comparing it to Thunderbird - you didn't like how Emacs handled your emails and now using something else? Congrats, and that's just fine, only it's not fair and proper comparison by any means.
frumplestlatz
I have a job to get done, and my job isn’t screwing around with my Emacs configuration.
And honestly, even if that was my job, I wouldn’t want to spend all my time messing around with a fragile, slow, untyped lisp REPL in the first place.
I used Emacs because it helped me get my job done, not because I have any particular affinity for lisp. I truly do not — in fact, I have even less affinity for it now that I’ve wasted so much time making Emacs usable for my purposes.
jrm4
Here's the thing (as someone who did Emacs for a year and then gave it up)
The possibility and ease of interoperability with other general program styles is far more important that the idea is given.
Look, there are too many other good tools out there that do things like have a standard file picker, use CUA bindings etc. This is primarily why I left Emacs for non programmy things (and am happier with a hacked zim-wiki, though I imagine obsidian et al might work too)
cholantesh
>that thing is overwhelming with all its popups, hovers, sidebars etc.
I think it's fairly normal if you're coming from heavy IDE use, eg: Eclipse. If you've spent most of your time editing using tmux/[vi|nano|emacs]], maybe that's not the case, but I can't really speak to that as I've never really worked that way.
totetsu
I get so frustrated watching people fuss around in VSCode because they're stuck in it and they've never had the opportunity to see all the intuitive and more workable tools that a.. just part of the basic OS they are using. .. like keeping their console a tab taking up 1/4 the screen and trying to read a stack-trace ..
jasperry
As a long-time Emacs user, I'm surprised by how easy it has become lately to configure Emacs as an IDE, mainly due to the built-in eglot. You need a lot less elisp code than you used to. A working Python setup is like one line of config.
Which is to say, this project isn't really for me, because I'm already familiar with Emacs keybindings. And as for a new user, they're going to eventually have to deal with the underlying configuration. Maybe it's a gateway drug?
bionsystem
I used emacs at school some 15 years ago and I remember it being pretty seemless, I had an OCaml repl for one course and a 68000 emulator with memory inspection for another, and gdb integrated for C ; I do NOT remember hours of configuring that, maybe put some files at the right places and that was it. Switched to vim due to work (that was what's installed on remote machines), kept it for years because of the ubiquity.
More recently in a new gig I'm finally able to install stuff on my machine (with homebrew) and not just work remotely, wanted to revisit my choice between (neo)vim and emacs again, but I guess muscle memory is too strong and still chose the former, although trying emacs I can tell that it is maybe even better polished now with the package manager and everything. Turns out neovim has the same with lazyvim, mason, etc. Just a bit more friction sometimes maybe.
My main pain point right now is the lack of tooling for devops/sre in general. Yes we have LSPs for ansible, groovy, terraform... But they do not cover the entirety of plugins and modules that can be used, and I'm not aware of good tools for testing and debugging. Yes there is teamcity but that needs a license and I can't have that at work apparently. I don't think it is at the editor level though, just the ecosystem is lacking.
jamesgill
Emacs for programming is definitely one important use case. This tool seems to focus on that use case, though I think I can get 75% of it by just using Emacs keybindings with regular VSCode.
But Emacs is so much more than an ‘IDE’. I realize some don’t like the Emacs approach of ‘here’s a box of parts and tools, build it the way you want’, but that’s the point of Emacs.
Besides the functional approach, of course, there is the philosophical stance: freedom.
Emacs is an elegant weapon from a more civilized age. But some people prefer blasters, and that’s okay.
skulk
> Besides the functional approach
Nitpick, but emacs and emacs lisp don't seem remotely "functional" to me insofar as expressing computation in terms of pure functions and immutable datatypes. The core datastructures that an elisp program interacts with (buffers, variables) are all mutable and functions (setq, buffer-string, etc) are decidedly impure.
jamesgill
I wasn't talking about programming.
eamonnsullivan
I love these packages (like this, Spacemacs, Doom, etc.), even though I've used Emacs for over 30 years. I don't use them directly, but they give me ideas and alert me to packages I haven't heard of (eat?). And that gives me an excuse to go on another round of config-tweaking, which any Emacs user loves.
finnjohnsen2
Hear hear. I poked around at almost all the packages on the top of that idemacs page. «minimap» stood out, and is such a brilliant name for its purpose. I enjoyed that discovery and the smirk it gave me today.
giancarlostoro
I would love to see a project that rebuilds the Emacs UI but keeps the underlying core to give it a modern facelift, some things in emacs blend together and are a pain for my eyes to figure out whats what. It would be nice if the UI was modernized but the core was left as-is. I'm reminded of some of my favorite editors that are niche being Lisp related ones, where if you held down ctrl it would show you shortcuts in the UI itself and what they lead to. I also always enjoyed Racket's import arrows and other small things that are visually amazingly impressive despite being so simple.
koiueo
I'd argue the opposite. UI is ok, it can be configured to look timeless (not modern).
But the core with its single thread processing and constant hangs, requiring you to repeatedly hit C-g at least once a day, is first in line for "facelift".
Myrmornis
You can make it look modern: get rid of all menus and bars so that there is nothing on screen except for the text you're editing. (e.g. search for minimal.el) It looks indistinguishable from any other modern editor / IDE in zen mode. Menus and bars are not necessary in these sorts of applications if you use then daily -- more efficient and powerful to use the command palette and key bindings.
ffaser5gxlsll
Second this. The "ui" is perhaps useful when learning to use emacs, but every emacs user I've seen after a while has all of it disabled.
I've been using emacs with the "lucid" build since forever, as it's the leanest build that still gets a graphical window working on X11 and see none of the actual "toolkit".
I guess the pgtk build is required nowdays for native wayland support.
koiueo
> nothing on screen except for the text you're editing
Just wanted to clarify, to me that's timeless. Modern would be having modern menus, pop-up configuration screen et al.. All the candy that appeals to a less experienced user, who worked with Idea, Sublime of VS code before.
yvdriess
Agree, those hangs are especially bad when programming with eglot or project management over a slow Tramp (remote) connection. An auto save hijacking your time for two seconds at random is flow breakingly frustrating. It's something that could perfectly well run in the background.
setopt
> requiring you to repeatedly hit C-g at least once a day
And bind `pkill -SIGUSR2 emacs` or similar to a OS-level keybinding…
volemo
So we all agree we need Emacs 2.0™, rewriting both the UI and the guts? /j
NoGravitas
I don't agree with everything in their approach, but Lem (https://github.com/lem-project/lem) is a modern editor that has the Emacs Nature.
chiffaa
It's not exactly what you're looking for but you might be interested in Lem[0]. It's an emacs-style editor but written completely in Common Lisp on top of curses/SDL2. I haven't used it that much (same for Emacs itself, really), but it looks like a very solid foundation
giancarlostoro
Does look interesting, in the meantime I've been hooked on Zed which has users building support for missing Vim features, they claim their goal isn't to 100% emulate Vim functionality, but I would not be shocked if it just winds up having most if not everything most people like about Vim fully baked in.
pama
You mean something like which-key? It existed for a long time as an external package and was added to main emacs recently. https://github.com/emacs-mirror/emacs/commit/fa4203300fde682...
tiu
Alternatively beside which-key, hydras exist which are very nice for certain contexts (dired in the particular case for me) and provide a nice shortcut interface whenever activated. Demo at [0].
setopt
As far as I know, which-key only helps with key sequences. If you press C-c in Org-mode it will show you keys like C-c C-e, but if you hold Ctrl down it won’t show you C-RET for example.
iLemming
Emacs can't do that for historic reasons. It just can't distinguish between keypress and keyup events. It receives input events from the terminal/OS. Terminals are text-oriented: They evolved to transmit characters, not hardware events.
It's not some technical impossibility - I think it would make sense to make this possible, at least in GUI Emacs. I suppose there was never a strong incentive to tackle this problem.
skydhash
A good shortcut is "C-h m" which shows the help for the major mode (and current active minor modes). It will also shows all the bindings that those modes define.
pama
If you want all keybindings, C-h b typically helps, and you can search within the single buffer it returns. Every key in Emacs is bound to something, but a plain modifier key event like Ctrl will not be sent from a terminal to any command that runs inside it, eg Emacs, only the modified key. (There exist modifications/extensions of this protocol, eg kitty, but most combinations wouldnt see these events.)
znpy
I would actually change as little as possible.
The current UI has it quirks, but has the great advantage that it looks the same irrespective of whether you're in an graphical environment (Xorg/Wayland/Windows/MacOS) on in a terminal (either local or remote via ssh).
I *love* that treemacs looks pretty much the same everywhere.
setopt
It doesn’t really look the same by default.
Most new users end up disabling the toolbar, menu bar, scroll bars, etc. and only then does it look the same in the terminal. Even then, many themes and packages frivolously change font sizes or switch to non-monospace fonts in some GUI contexts, so for users that like the uniformity of the interface you need to do extra work to disable these features.
(I personally like the terminal aesthetic, and configure the GUI to look like a terminal. That basically required advising load-theme to loop over all faces and disable font properties I don’t like after each theme change…)
tiffanyh
I was always bummed OniVim v2 didn't take off.
It was a native IDE but fully supported VS Code plugin system.
https://web.archive.org/web/20210627210456/https://v2.onivim...
arbitrandomuser
onivim also seperated the core functionality of the vim editor into a seperate library libvim , this would have been great for other people looking to make their own gui frontend to vim .
neovim does not give a libneovim, but exposes an rpc where you communicate with neovim running as another process, this I would have thought have more latency but apparently is fast enough , this is how the vscode plugin for neovim is able to provide a near complete vim experience. Other neovim guis like neovide use this too
koiueo
From a quick glance, I can't understand the target audience.
Vim users would be annoyed by bizarre input lag of an electron application and perhaps by EULA. VS code users don't really care about Vim...
forgotpwd16
>of an electron application
It isn't an Electron application*, that's why GP said native. The EULA part though was probably a block to adoption.
*It uses Revery, a, made by OniVim's devs, cross-platform GUI framework (similar to Flutter but build on Reason/OCaml).
koiueo
Oh, ok, now I'm curious to try it despite EULA (although these days the wide choice of (neo)vim distributions utilizing LSP makes their offering less appealing). Thanks for the clarification.
The site doesn't stress the not-electron part enough, maybe that contributed to the failure.
iLemming
> VS code users don't really care about Vim
I disagree. vim-navigation is imperative for a huge number of devs. It's an amazing, practical, beautiful model. I would've never tried emacs if Evil-mode wasn't so fantastic. And that yet another reason for why vscode never is appealing to me - every one and each vim extension for it has tons of glaring deficiencies.
koiueo
I'm not sure what you disagree with. I'm saying VS Code isn't targeting Vim users, and core VS Code user base doesn't care about Vim.
I too can't take a seriously an editor which doesn't have Vim keybindigns at least in a very basic form.
imiric
This is great to see, and I'm sure it will nudge some people to give Emacs a try who wouldn't have otherwise.
I've been using Emacs with a custom configuration for many years now, but when I needed a good IDE for working with modern frontend stacks about a year ago, I decided to give VSCodium a try, since the TS/LSP integration wasn't that great in Emacs. And funnily enough, I did the reverse of what this project does: I tried to make VSCodium look and behave more like my Emacs setup.
It turns out that this is incredibly difficult. Decluttering the UI was easy enough; getting my Vim/evil-mode key bindings to work was relatively straightforward, though not perfect; but it was practically impossible to make VSCode work with the concept of buffers, instead of tabs and tab groups.
There are some extensions that emulate this to an extent, but it requires at least one change[1] to work properly that's been ignored for almost 2 years now.
So, that, general jank and unresponsiveness, and the idea of my editor being a web browser with all the security concerns of installing random JS extensions, put me off it for good. I went back to my "inferior" Emacs setup, spent some more time on configuring it for TS, and I think it's not so bad right now. Though I switched projects in the meantime, so it probably needs to be brought up to date again.
Moral of the story: Emacs is life. I'm sorry I ever doubted it. <3
aaravchen
I did exactly the same, though I wasn't an Evil mode user. I quickly found VSCod(e|ium) lacks the internals to even do many of the basic useful things of Emacs.
BTW, if you're an Evil mode user, Zed is probably your better choice. It has more focus on Vim-style keybindings.
hollerith
Similar story here. I used vscode for about 3 months for all my editing needs without even having Emacs installed, but returned to Emacs because of how hard it was to learn how to modify vscode (I'm not a web dev) compared to modifying Emacs and because of a vague impression that vscode is slower in responding to my inputs.
aaravchen
It's definitely slower when doing any intensive background activities that Emacs would normally offload. But I've found VSCode has features readily available as one-click installs that are very difficult and convoluted to setup in Emacs. For some of those you end up either settling for less-ideal tools in Emacs, or because you're not an expert in the specifics of the tool being integrated, you end up with a much less optimized integration. And in either case you can actually end up with a net-worse performance in Emacs, even though the VSCode core is in a far less performant language than Emacs.
noelwelsh
This won't take me away from Doom Emacs---I prefer the keyboard centric approach of Doom---but I'm really happy to see this. I feel that Emacs has some really innovative UI plugins (things like Vertico) but the out-of-the-box experience is pretty bad. If this makes Emacs more accessible to a different group of people I think it's great.
kleiba
Long-time (25+ years) Emacs user. The first thing I do on a new installation is turn off the GUI features (like, menus and toolbars) - no-one I know who uses Emacs uses the mouse.
femiagbabiaka
VSCode users, especially new ones, do. The best property of Emacs is that you can modify the lisp machine to do whatever you want.
pxc
If you use an editor or IDE at work for a year, you might work with it for a thousand hours that first year alone. But a noisy GUI like VSCode's is optimized for just that first 30 minutes of playing around.
For me, at least, that kind of thing doesn't end up being very enjoyable long-term.
DonaldPShimoda
> the lisp machine
I wonder whether this was intentional or a coincidence, but for others (and maybe you) the "Lisp Machine" was a real hardware architecture unrelated to emacs: https://en.wikipedia.org/wiki/Lisp_machine
globular-toast
Another long time (15+ years) Emacs user here. I similarly use it completely keyboard driven. I have seen someone use it with the mouse, though. My PhD supervisor used completely stock Emacs to do LaTeX and actually used all the menus to do stuff. Quite eye opening for me.
undefined
undefined
trenchpilgrim
This would have been great when I was learning Lisp in school! I tried emacs but due to joint issues the keybinds were painful to use, so I gave up and did the course in vim+SBCL's REPL instead.
yvdriess
It is fairly common for emacs users to bind Ctrl or Meta to caps lock for improved ergonomics. There's also a bunch of RSI sufferers that are using foot pedals, which actually makes a lot of sense.
I personally switched to emacs for more than just Lisp when I started developing early signs for RSI. Switching to a purely KB driven interface has saved my wrists.
contrapunctus
I use kmonad to make Space act as Control when held, and it's absolutely life-changing - not just in Emacs, but in all applications.
This is my configuration -
https://codeberg.org/contrapunctus/dotfiles/src/branch/produ...
And here's my blog post about it -
https://contrapunctus.codeberg.page/blog/keyboard-machinatio...
yvdriess
I will absolutely try this one out, it looks a lot more useful than binding caps lock.
qiine
wait foot pedals ?
newcup
Or an accordion! https://x.com/ykarikos/status/1038145486618861573
yvdriess
It pops up a surprising number of times.
Keysets or chorded keyboards have been around since The Mother of all Demos, but never really seemed to have caught on. It makes sense to me to put them at your feet to chord some common actions or modifiers.
dmead
Which joint issues? Have you tried evil mode?
trenchpilgrim
> Which joint issues?
Pretty sure it's rheumatoid arthritis.
> Have you tried evil mode?
This was like fifteen years ago and I just went back to my working Vim setup I was already using for all my other classes.
dmead
Sorry to hear that. I have a family history of that as well. I think I'm starting to show signs of it.
Vim forever I guess. Im typing on a full split with cherry reds (very soft). What are you on?
musebox35
As a 15+ years emacs user the only item on my wishlist is client-server remote editing mode similar to that of vs code. Then I can go back to using emacs on cloud VMs. Does anyone know a solution to this that works as good as VS Code even when your latency is high? Hopefully, I will be pissed off with all the weird configuration flags of VS Code enough to write one myself ;-) To be fair its python integration is quite good at least for the usual stuff.
PessimalDecimal
Two approaches might work here:
1) Run Emacs on your local machine and use Tramp to edit the remote files
2) Run Emacs on the remote machine with the files you're editing. This likely means running in the terminal itself (emacs -nw or requivalently emacs -t).undefined
Get the top HN stories in your inbox every day.
Whoever thinks that VSCode does not have any learning curve or is somehow magically easy, needs to take a reality check, that thing is overwhelming with all its popups, hovers, sidebars etc. beyond all reason when you first run it (and later too). I'm an Emacs user and I don't in any way support the notion it's somehow easy or intuitively workable, it's most definitely not and never has been. I just think that VSCode is not it either, it's just the more popular tool right now.