Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I use Kakoune very extensively. I've tried out Helix a bit though. While I'm adequately informed to make an assessment about Kakoune, my opinion about Helix is more impressionistic.

My overall assessment is that Helix has the potential to run away with the Kakoune interested crowd! For a new editor Helix looks shockingly polished!

Here is what I like:

- Tree sitter is integrated into Helix. Kakoune use a lot of regexes for syntax highlighting (except when the syntax highlighting can be done by the LSP). I really like that

- LSP is built into Helix so you don't need to worry about adding extra plugins. It just works! (Worth mentioning: Kakoune has amazing LSP integration via the separate kak-lsp plugin though)

- Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

I find Kakoune as more minimalist and consistent in its editing philosophy. Helix AFAIK does not have a good plugin story yet. OTOH it is almost trivial to write a plugin in Kakoune.

Kakoune's pure-editing features (multiple cursors, selections and other primitives) seem richer and deeper. Helix has a wider selection of features "out of the box". As Kakoune has been around for a while it feels more mature. Helix is designed to be an "editor for all" and tries to be a bit like spacemacs with the spacebar as an important key. (BTW Kakoune has relegated the large spacebar key to a relatively minor functionality which is a pity).

Helix feels a bit more responsive and snappy than Kakoune on my machine. (But both are very fast). That could be because I was comparing vanilla Helix with Kakoune+plugins. However, long term, because Kakoune likes shelling out frequently, that might be a bottleneck on how responsive Kakoune will always ultimately be.

Helix seems to have a very fast pace of development. Kakoune moves much more slowly and ponderously. Kakoune's creator is quite hesitant about adding new features possibly in a desire to keep the core editor small and consistent. Kakoune also tends to be a bit opinionated about accepting features in general in its code-base.

Coming to the innards of Helix & Kakoune you can see the differences in the philosophy of both editors. The Helix code base liberally uses many rust crates to build the editor. Apart from a recent C++ compiler and a posix system Kakoune has literally _no_ dependencies -- not even ncurses or a regex library! Basically, Kakoune likes to build everything in-house. This approach has its benefits and pitfalls which I'm not going to debate here.

While Kakoune has had a lot of community contributions over the years, Helix seems to have lot of community momentum behind it currently.



> Helix is built in Rust. Kakoune is built in C++. I've encountered the occasional segfault in Kakoune and I would guess that these would be rarer in Helix simply because Rust makes it easy to write "safer" code by default

No segfaults, but Helix is definitely somewhat buggy at the moment, especially on Windows. Panics make it relatively easy to debug though.


Kakoune is gimped by the fact that Mawww had children and cannot dedicate nearly as much time to the project as they had planned to. The idea was to have monthly releases, but that quickly fell by the wayside.

Helix is interesting, and built in LSP and Treesitter is really cool, but it feels like it's missing some of the core principles of orthogonality that Kakoune has. It has the potential to overtake Kakoune very quickly simply due to how active its community is.


How did you get Kakoune to segfault?


Kakoune is built in C++. So bugs will sometimes manifest as segfaults. You could be doing some normal editing, press a sequence of editing commands that might trigger some code that may subtly wrong. Sometime later, when C++ code tries to write to memory that it shouldn't have, you will segfault.

In that respect this is true for any C/C++ application. Kakoune keeps fixing these issues as they come up.


> tries to write to memory that it shouldn’t have

To elaborate what I mean here is maybe the program tried to write to an address not mapped to its address space etc. This happens due to bugs in the program e.g. not calculating the offset into an array properly and so forth. There are many ways to mess up when using C/C++!


You can segfault in rust, too:

  fn totally_safe() -> i32 {
    unsafe { *std::ptr::null() }
  }
This commonly happens if the person who wrote 'totally safe' thinks what they're doing is fine, and it actually isn't.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: