8 ms·

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

by gaius 9y ago

rayiner 9y ago
Emacs' display engine, input handling, etc., are written in C.
- gaius 9y ago
  So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. Their problem is not technical, it’s ideological
  - rayiner 9y ago
    That would impair the stated goal of "hackability."
    - mr_overalls 9y ago
      Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.
  - ben336 9y ago
    If you read the post, that is mostly the work that they're describing.
  - thramp 9y ago
    > There’s no reason the Atom team couldn’t optimize their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.
- urda 9y ago
  Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo
  - arianvanp 9y ago
    Emacs is written in Elisp which is a dynamic language just like JavaScript
    - ninjakeyboard 9y ago
      emacs core is written in C. All of your extensions are mostly in elisp. A few run servers and talk to them though. (Eg ensime)
    - camus2 9y ago
      > Emacs is written in Elisp which is a dynamic language just like JavaScript All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.
- tomjakubowski 9y ago
  And Electron’s are written in C++, so I’m unsure what your point is.
  - rayiner 9y ago
    Yes and no. E.g. Atom does its line layout and rendering in Javascript, which manipulates the DOM, and Electron then renders things using C++ code: http://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html http://blog.atom.io/2017/06/22/a-new-approach-to-text-render.... Emacs' display loop is tens of thousands of lines of C that directly calls the native text-rendering API: https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102 https://www.facebook.com/notes/daniel-colascione/buttery-smo....
ninjakeyboard 9y ago
emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.
- hsitz 9y ago
  > it doesn't really matter because you just run a daemon and connect to it. I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post. As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds. Here's blog post that describes this feature: https://brainlessdeveloper.com/2017/12/27/making-emacs-work-like-my-vim-setup/ https://brainlessdeveloper.com/2017/12/27/making-emacs-work-... The blog post above actually overstates how difficult it is to start working with Emacs in this way. It's dead easy.
  - michaelsbradley 9y ago
    On macOS, I have the following defined in ~/.bashrc: alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw" alias e="et" alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\"" alias et="emacsclient -t -a ''" Explanation of the `-a ''` option per `emacsclient --help`: -a EDITOR, --alternate-editor=EDITOR Editor to fallback to if the server is not running If EDITOR is the empty string, start Emacs in daemon mode and try connecting again
  - deleted 9y ago
    [deleted]
valarauca1 9y ago
Emacs is very slow to start. Especially once you have a few extensions and addons. Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. But many people still run Emacs in a daemon. This preserves your sessions between “running the editor” and prevents ever having to restart.
- dragonwriter 9y ago
  > Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. The changes Atom is looking at regarding user-side snapshots seems conceptually similar.
  - valarauca1 9y ago
    This really scares me because the emacs unexec operation has had a ton of safety related bugs.
    - c256 9y ago
      Also, it’s a portability PITA, and it can be a serious impediment to bringing new developers on-board. Emacs is looking (in the long-term, serious project sense) to replace or remove dumping and unexec if it can.
Veedrac 9y ago
Emacs doesn't offer a fraction of the graphical flexibility that Atom does. How would you do any of the below? https://benmccormick.org/2016/01/11/the-most-interesting-atom-packages-ive-found-so-far/ https://benmccormick.org/2016/01/11/the-most-interesting-ato...
- taeric 9y ago
  The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs. It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.
  - Veedrac 9y ago
    Forgive me for being skeptical. Where is this git-time-machine equivalent?
    - brlewis 9y ago
      What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit https://www.emacswiki.org/emacs/Magit
      - Veedrac 9y ago
        The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.
        brlewis 9y ago
        The first question was "How would you do any of the below?" which is easier to answer when it's apparent what problem an extension is solving. The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part. I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.
mr_toad 9y ago
These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.
- pjmlp 9y ago
  So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.
  - gaius 9y ago
    The old joke was Emacs meant Eight Megs And Constantly Swapping. Except now you get less functionality in 800M at least https://jinolabs.com/article/12232554/atom-editor-uses-more-than-800-megabytes-for-one-file https://jinolabs.com/article/12232554/atom-editor-uses-more-...

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

by gaius 9y ago

Atom takes longer to start up than text editors like Vim and Sublime Text because of the dynamic architecture of the app And yet Emacs is fast, hmmm.

rayiner 9y ago

Emacs' display engine, input handling, etc., are written in C.

gaius 9y ago
So what? There’s no reason the Atom team couldn’t optimise their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. Their problem is not technical, it’s ideological
- rayiner 9y ago
  That would impair the stated goal of "hackability."
  - mr_overalls 9y ago
    Emacs and vim are perhaps the most configurable and extensible editors/IDEs in existence. Fast doesn't mean unhackable.
- ben336 9y ago
  If you read the post, that is mostly the work that they're describing.
- thramp 9y ago
  > There’s no reason the Atom team couldn’t optimize their critical paths while retaining extensibility and cross-platform-ness, and the proof is that Emacs has already done it. I believe that's what the Atom team is doing. They've detailed several critical paths that can and will be rewritten in C++/Rust in the linked post.
urda 9y ago
Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo
- arianvanp 9y ago
  Emacs is written in Elisp which is a dynamic language just like JavaScript
  - ninjakeyboard 9y ago
    emacs core is written in C. All of your extensions are mostly in elisp. A few run servers and talk to them though. (Eg ensime)
  - camus2 9y ago
    > Emacs is written in Elisp which is a dynamic language just like JavaScript All dynamic languages are not born equal when it comes to performance. 2 implementations of the same language aren't even equal. While V8 is a fast JS engine, the DOM isn't. Emacs doesn't rely on the DOM unlike Atom or VSCode.
tomjakubowski 9y ago
And Electron’s are written in C++, so I’m unsure what your point is.
- rayiner 9y ago
  Yes and no. E.g. Atom does its line layout and rendering in Javascript, which manipulates the DOM, and Electron then renders things using C++ code: http://blog.atom.io/2017/06/22/a-new-approach-to-text-rendering.html http://blog.atom.io/2017/06/22/a-new-approach-to-text-render.... Emacs' display loop is tens of thousands of lines of C that directly calls the native text-rendering API: https://www.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102 https://www.facebook.com/notes/daniel-colascione/buttery-smo....

ninjakeyboard 9y ago

emacs can be very slow to start if you install everything and the kitchen sink. I had spacemacs installed with everything for working with elixir and it took maybe 5 or 6 seconds to start. I started over from a blank init.el and I have it much quicker but it doesn't really matter because you just run a daemon and connect to it.

hsitz 9y ago
> it doesn't really matter because you just run a daemon and connect to it. I'm writing this because I think many people are unaware of this feature of Emacs and might gloss over it in your post. As far as I'm concerned startup time is next to irrelevant in Emacs, since you can start an Emacs server once when you boot up and then just run clients that open and connect instantaneously. That is, you can then run 'emacsclient' from the command line in any terminal you want, and it will open a working Emacs instance in a few milliseconds. Here's blog post that describes this feature: https://brainlessdeveloper.com/2017/12/27/making-emacs-work-like-my-vim-setup/ https://brainlessdeveloper.com/2017/12/27/making-emacs-work-... The blog post above actually overstates how difficult it is to start working with Emacs in this way. It's dead easy.
- michaelsbradley 9y ago
  On macOS, I have the following defined in ~/.bashrc: alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw" alias e="et" alias eb="/Applications/Emacs.app/Contents/MacOS/Emacs -nw -Q --eval \"(load-theme 'misterioso)\"" alias et="emacsclient -t -a ''" Explanation of the `-a ''` option per `emacsclient --help`: -a EDITOR, --alternate-editor=EDITOR Editor to fallback to if the server is not running If EDITOR is the empty string, start Emacs in daemon mode and try connecting again
- deleted 9y ago
  [deleted]

valarauca1 9y ago

Emacs is very slow to start. Especially once you have a few extensions and addons. Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. But many people still run Emacs in a daemon. This preserves your sessions between “running the editor” and prevents ever having to restart.

dragonwriter 9y ago
> Emacs does an “unexec” operation to save its entire memory map to disk so its startup looks faster. The changes Atom is looking at regarding user-side snapshots seems conceptually similar.
- valarauca1 9y ago
  This really scares me because the emacs unexec operation has had a ton of safety related bugs.
  - c256 9y ago
    Also, it’s a portability PITA, and it can be a serious impediment to bringing new developers on-board. Emacs is looking (in the long-term, serious project sense) to replace or remove dumping and unexec if it can.

Veedrac 9y ago

Emacs doesn't offer a fraction of the graphical flexibility that Atom does. How would you do any of the below? https://benmccormick.org/2016/01/11/the-most-interesting-atom-packages-ive-found-so-far/ https://benmccormick.org/2016/01/11/the-most-interesting-ato...

taeric 9y ago
The only one of those I'm not sure on is the expose one. The rest seem like they already exist in emacs. It is probably mentioned in every editor thread, but org-mode is enough magic with an editor to mystify most developers. Syntax highlighting for multiple languages in a single file is already stretching most boundaries.
- Veedrac 9y ago
  Forgive me for being skeptical. Where is this git-time-machine equivalent?
  - brlewis 9y ago
    What's the point of the graphics in git-time-machine? The bubble plot seems less useful to me than a readable log. If it were useful there would probably be an equivalent findable from https://www.emacswiki.org/emacs/Magit https://www.emacswiki.org/emacs/Magit
    - Veedrac 9y ago
      The question isn't "do I like these extensions?" It's "does Emacs let you build these extensions?" The Atom developers thought that providing this flexibility was important, which is at least in part why they used the technology they did.
      - brlewis 9y ago
        The first question was "How would you do any of the below?" which is easier to answer when it's apparent what problem an extension is solving. The second question was "Where is this git-time-machine equivalent?" which is easier to answer when one knows what a user is expected to accomplish by using it, specifically the graphical part. I think the Atom developers are doing the right thing now by focusing on performance more than useless graphics. Right now I recommend vscode to other people even though I'll probably always use emacs myself.

mr_toad 9y ago

These days. 20 years ago people hated on Emacs for the same reasons they hate on Atom now.

pjmlp 9y ago
So we are getting a text editor with the features of a 20 years old application, using enough memory to run several Emacs instances.
- gaius 9y ago
  The old joke was Emacs meant Eight Megs And Constantly Swapping. Except now you get less functionality in 800M at least https://jinolabs.com/article/12232554/atom-editor-uses-more-than-800-megabytes-for-one-file https://jinolabs.com/article/12232554/atom-editor-uses-more-...