Tell me again about those "python performance limitations".
Personally, I admit I'm not sure that the difference is significant for this particular project.
When you're writing all of the main parts of the editor in C, at this point, why are you using python at all?
Text editors are surprisingly demanding; they require complex bulk operations like search, replace and per word highlighting, which is not inconsiderable in magnitude.
Ever tried open a 100MB log file in vim?
Now try that in atom... and javascript is easily a magnitude or more faster than pure python.
I work with python and love it; its hackable, fun to write. ...but fast it is not.
And no branching out to C, or Cython or Fortran like Numpy is not the same as Python not having those limitations.
Not exactly relevant for a text editor, though.
That's not acceptable to me, even though it would be nice to have a hackable to the core editor. But we already have emacs for that, I suppose...
Yeah exactly emacs is hackable if you want to write lisp, which has a very small audience. So sure there is absolutely a desire for an editor written in a 'nice', hackable language like Python or JS (forgive me JS haters) to prosper.
For the record, while Python's pure interpreter is always going to be slow at this type of thing, JS's overhead factor compared to C is small enough that it's certainly possible to write an editor in it that feels just as fast as vim - maybe faster in some cases, e.g. since JavaScript engines JIT compile regexes and C regex libraries generally don't, or by making relatively slow operations asynchronous/multithreaded (while vim is highly synchronous). Atom seems to be just badly designed.
I think the problem with Atom speed is using the DOM / web stack, not Javascript itself.