You are talking about 16 GB of RAM, rights? My emacs is very happy with 32 MB of RAM and my vim with even less.

I understand that Atom is doing a lot, but if you need 16 GB of RAM to run your text editor, this simply means that the developers have not been using the right data structures to manage the state of the application or maybe the new code editors have an implementation of an AI coding for you so you can outsource yourself.

I was going to say that my emacs uses an awful lot more memory than that, but actually it's got 190 files open in at least 3 languages and it's using 89.8 Mb of RAM at the moment.

Atom is at a fundamental disadvantage - it's built on a much more complicated and abstracted stack of technologies. Javascript engines do spectacular things these days but they have a harder job to do than executing compiled lisp, and that's before you look at the whole of the rest of the stack involved.

I've been an avid Sublime user for many years and still am, and this is what puts me off any electron based editor or app in general. The requirements for the most trivial things are so high, it is insane. Try running Atom on a AMD E1 laptop. TLDR, not very nice.

And to think people used to say emacs stood for Eight Megabytes And Constantly Swapping.

And let's not forget:

Editor for Middle Aged Computer Scientists

Escape-Meta-Alt-Control-Shift

Tt's still my favourite, though.

Many people use full IDE's to do their work - JetBrains, VS, etc - which are dramatically more resource intensive than Atom.

Yes but they are IDEs, while Atom/Vim/Emacs are plain text editors.

> plain text editors

I don't think that's a fair assessment given the what is now minimum expectations around syntax highlighting, syntax/grammar validation, autocomplete, etc. We're no longer dealing with "plain text".

So that's even less of an excuse for Atom's resource hogging. Vim and neovim use so little memory and are probably the most responsive editors I've ever used.

... and Emacs really is an IDE; the distinction between it and GUI IDEs has more to do with user interface than any limitation of Emacs.

e.g. live libclang-based code completion for Emacs: https://github.com/Sarcasm/irony-mode

Atom is essentially the same class of editor as emacs. Both have designs that can accomodate IDE features (so does vim, but it's more of an afterthought in that case), but normal usage is not IDE-like. Atom is essentially emacs built atop javascript+web rather than lisp+unix.

This is more holy war material than anything really. Emacs is just an editor.

>> Many people use full IDE's to do their work - JetBrains, VS, etc - which are dramatically more resource intensive than Atom. reply

My Visual Studio doesn't need 16 GB of ram... I have enough with 4 on Windows ;)

It's new paradigm - bloatier than an IDE, as slow as a web page but without the advantage of storing / running anything i n the cloud.

That's the price you pay for Electron.

The reason we're talking about Atom on this thread is because VSCode, which also uses electron, does not have performance issues.

Which makes me think, Atom is giving Electron a really bad reputation for its speed. Sure, it consumes tons of RAM, but it's not that slow by default.

Last time I seriously tried using it, it seemed unnecessarily CPU-hungry and my battery life suffered as a result. That fact alone was enough to get me to stop using it. I have a weird thing about inefficient software in general, but in this case its inefficiency was actually inconveniencing me. With my good old Vim+tmux workflow, my 12" Macbook claims it'll go for 14-15 hours, though I haven't ever fully tested that claim.

I used Atom for 3 months over New Year's on a 4 GB 2015 MBA.

I had no issues whatsoever.

Interestingly enough, Atom seems to really struggle on my Windows laptop, it's often incredibly choppy. It actually runs better in a Linux VM than natively on Windows.

The only consistent issue that I have had with Atom since I started using it in late 2014 was the handling of large files. It has gotten incrementally better, as others have stated, but trying to open up, for instance, a JSON file larger than 10-20 megabytes in the editor causes the editor to be brought to a grinding halt.