Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Atom's Performance

blog.atom.io

Post reply on HN
Print view View original

11–20 of 293 posts

Re: The State of Atom's Performance

#11

Post by arianvanp »

urda wrote: post #8
rayiner wrote: post #4

Earlier quoted context omitted.

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

Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo

Emacs is written in Elisp which is a dynamic language just like JavaScript

Re: The State of Atom's Performance

#12

Post by rayiner »

gaius wrote: post #5
rayiner wrote: post #4

Earlier quoted context omitted.

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

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

That would impair the stated goal of "hackability."

Re: The State of Atom's Performance

#13

Post by Waterluvian »

I am not badmouthing JavaScript or bandwagoning on the "Electron is the devil. Long live native apps!" But I've been wondering more and more, especially through my own experienced biases at work: how much of the, "we chose x because y and z" is retroactive justification for the simple truth: "I wanted to use the technologies that make me enjoy my job."

I often have to fight with myself to pick the right tool for the job, not the tool that makes my job the most fun to do.

Re: The State of Atom's Performance

#15

Post by ben336 »

gaius wrote: post #5
rayiner wrote: post #4

Earlier quoted context omitted.

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

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

If you read the post, that is mostly the work that they're describing.

Re: The State of Atom's Performance

#16

Post by ninjakeyboard »

I've been learning emacs over the last 6 month or so. How is the "hackability" of atom compared to emacs? I threw away spacemacs, started over, built all my config, am starting to build plugins etc. While the learning curve was steep, the flexibility of emacs is quite amazing and I've only just scratched the surface of the extensibility. It makes me very intrigued to hear about how other people are using editors like Atom.

Re: The State of Atom's Performance

#17

Post by ninjakeyboard »

gaius wrote: post #2

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.

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.

Re: The State of Atom's Performance

#18

Post by Dowwie »

I gave VS Code a try recently for Python development. VSC almost won me over. However, in the end I found important features / packages that are available in Atom weren't available in VSC, so I moved back. For instance, autocomplete ("intellisense") failed to recognize functions that were written in files open in the editor!

Re: The State of Atom's Performance

#19

Post by ninjakeyboard »

arianvanp wrote: post #11
urda wrote: post #8

Earlier quoted context omitted.

Your point? Write slow javascript, get slow programs. It's not a crazy concept. Edit: typo

Emacs is written in Elisp which is a dynamic language just like JavaScript

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)

Re: The State of Atom's Performance

#20

Post by thramp »

gaius wrote: post #5
rayiner wrote: post #4

Earlier quoted context omitted.

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

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

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

Post reply on HN