Get the top HN stories in your inbox every day.
exDM69
MontyCarloHall
>I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.
Do you have some supernatural ability to quickly (re)learn muscle memory for new keybindings? I’d consider myself a fairly advanced vim user, and it took me literally a couple years to get to the point of fluently using complex navigation/editing commands.
I took a look at the Helix documentation, and while it’s definitely “vim inspired,” it’s different enough [0] that I would have to rewire years of muscle memory to be as productive as I am in vim. There are some very fundamental differences, e.g. the verb/object syntax is reversed in Helix; `dw` in vim is `wd` in Helix. When I want to rewrite a string in vim, I unconsciously type `ci"`; it would take me a long time with Helix to regain that level of fluency.
[0] https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...
jarbus
I’ve got the same question. One of the major reasons I invest time into vim is because it’s everywhere and so powerful. If I invested time into learning a different set of keys for an editor that isn’t always available, I wouldn’t be able to leverage that power and fluency all the time, and furthermore, would need to switch back and forth between vim and helix keys
haarts
I've switch from years of Vim to years of Kakoune and am now trying Helix. While annoying I find I pick up the right keys fairly quick. A week until I get decent productivity back and a couple of months tops to truly get the hang of it.
I find it immensely helpful that Kakoune and Helix _make sense_. It is also a great boon that there's visual feedback.
lifehasleft
This how I feel about vim too. I’m sure there are editors I would like more but I work on remote servers every day, some of them lightweight, and vim is already going to be on all 500+ of them as part of the OS install.
exDM69
The keybindings are pretty similar, the paradigm change from verb-noun to noun-verb and the multiple cursor paradigm are bigger changes. I got used to it with my brief affair with Kakoune.
The Vim muscle memory will be quite helpful and not a whole lot of unlearning is necessary. hjkl navigation and other familiar concepts are similar in Helix and Vim.
Vim ci" translates to Helix mi"c. After the first key press (m), a help dialog pops up.
hamburglar
hjkl are definitely table stakes for a vim-ish editor, but I also can’t live without 0 and $. Making me move my hand over to find home and end misses the point of hjkl entirely.
Casperin
After 20 years of vim I decided to try out Helix back in Feb and never looked back, so I guess I can chime in here.
Sure, it took a few days (maybe weeks?) of feeling uncomfortable, but unlike vim, Helix is very approachable. I think you have to be okay with a certain level of feeling uncomfortable if you want to do or learn anything new though. If learning a new editor isn't your thing, then don't. :)
I get this same question a lot when people realize that I use Dvorak layout. Sure, yes, it took time to learn. But I was curious if there was something better for me on the other side. It seemed plausible that there would be, so I gave it a shot. In both cases I have been happy with my investment.
vlmutolo
Slightly off-topic: how do you manage using an alternative layout with an editor like vim/Helix? I've been trying to figure out how/if to remap the keys in the editor condig.
If you remap hjkl to your right-hand home row, that could cause a cascade of other remappings. If you don't, you lose basic navigation with hjkl.
jerpint
This was my same impression when trying out helix. Really nice and shiny, but all the shortcuts I've spent time creating over the years are gone and not easily reconfigured.
Casperin
Don't even try to reconfigure them. Try to learn the editor first as it is.
If you think that's crazy-talk, then imagine someone saying they'd like to learn vim, but they find it hard to configure the shortcuts to be like Eclipse. They aren't wrong, but it also doesn't seem like the right approach to learn vim either.
pigcat
what does `ci"` do in vim? I'm decent with vim, but it didn't make sense to me - then I tried it and it didn't do anything.
thegeomaster
Deletes text inside the nearest quotes and puts you in insert mode. You probably tried it without being inside a quoted string, that's why it did nothing.
torarvid
Change inside doublequotes. You can also do `ci{` or similar to Change inside curly-braces or `di[` to Delete inside square brackets
Agentlien
ci is "change inner ..."
If we use | to mark our cursor, and you have your cursor inside quote: '"he|re"'
ci" would replace everything inside giving you '"|"' and putting you in insert mode.
cab would aso remove the quotation marks and give you '|'
With ce or cw you'd get '"he"' and cE or cW would give you '"he'
exDM69
Cursor needs to be between double quotes (e.g. inside string literal) for ci" to work. See `:help text-objects`.
harryposner
> But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.
For me, coming from writing Clojure with Neovim + vim-sexp + vim-fireplace, I would need Paredit and REPL integration.
Paredit is doable with Treesitter, and I'm actually really excited about Helix's Treesitter integration--- every time I write a non-Lisp language, I miss structural editing, so it'll be nice for other languages catch up to Lisp on that front. It doesn't really look like it's quite there yet, though. The built-operations that use Treesitter are spare [0], and while you could implement operations like promote, slurp, and barf with them, you'd have to clobber some register. I don't see at all how you could implement splice without an actual language, since you would need a way to select all siblings of the current node.
REPL integration absolutely needs a plugin language. Unlike the LSP, there isn't a standard protocol for communicating with a REPL, so each language requires its own REPL client. Unless they want to ship a REPL client for every language under the sun, they'll have to provide some way for users to implement their own clients. That said, every time I look at Conjure, they've added REPL clients for more and more languages [1], so maybe it is feasible to have it built into the editor.
exDM69
> Paredit is doable with Treesitter
Yes, indeed.
Helix has built-in paredit-like navigation using tree-sitter, the default keybindings are alt-i, alt-o, alt-n and alt-p.
Maybe the Debug Adapter Protocol (DAP) used by vscode will solve the REPL issue in the future. Helix has experimental DAP support but it's still quite rough (but no Clojure DAP server yet).
eating555
I think the fact that helix doesn't really need a plugin/extension system is beautiful. It means that it's simple enough to config yet still powerful. Helix smooth out the learning curve in this good way and I hope it won't become complicated and make learning curve as deep as vim/nvim.
WuxiFingerHold
My personal deal breaker is the lack of snippets support. Is there a workaround or don't you use snippets at all?
archseer
We're working on snippets! It'll take a while longer to get there though.
p-e-w
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Helix is built from the ground up around Tree-Sitter and LSP. This means you get the best syntax highlighting available, and IDE-like functionality, with zero configuration required other than installing the appropriate language server.
Those are by far the most important features for a text editor to have, and crucially, they are fully integrated into Helix, but are an afterthought in (Neo)vim and Kakoune. The quality difference is obvious the moment you try it side by side. Nothing else really matters. Vim's and Kakoune's syntax highlighting is terrible, and while Neovim can now use Tree-Sitter as well, there always seem to be some additional hoops the user needs to jump through in order to get it to work. Not so with Helix.
Regrettably, Helix has inherited Vim's worst design flaw, namely being unusable with non-English keyboard layouts, but all other Vim derivatives share this flaw as well so I don't see that stopping Helix from steamrolling the competition once it matures and the word spreads.
Accacin
I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch, well they might go to Helix but there's a lot of vim resources out there, so I'm not sure all of them will go to Helix.
Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
Voklen
I've tried to make the switch to Neovim from Vscodium before but there was so much configuration for all the language stuff (and I'm not the biggest fan of Lua). But after seeing this post and installing Helix it's been pretty painless so far and I think this can actually help me make the switch. I am about to try some configuration for Rust debugging but that shouldn't be needed once they've got full DAP support. I use Neovim as my standard text editor so the navigation and bindings aren't a problem, lets see if Helix can make my IDE be in the terminal too.
rjzzleep
For the longest time I was using YouCompleteMe with vim and then tried all sorts of LSP servers. And while I'm still using them, I feel like that YouCompleteMe solution back in the day had a lot less fiddling involved. Sure they have more features and more selection and variety nowadays, but I have spent so much more time configuring things that I kinda regret it now.
least
> I just can't see if ever taking off, if I'm honest. The people that use neo/vim are going to continue using it, even if Helix is better.
I would think that helix probably is better because I'm certain that the verb->text object paradigm in vim could be much better. It may in fact make more sense to do the 'text object' first like it seems to do in both helix and kakoune. But is it better enough for me to switch off something that I've used for years now? Only if it sees mass adoption and you see many developers adopting it. Like if you see it in VS Code as an option to use helix bindings, then it is probably safe to consider adopting it.
> Honestly, language servers are a bit of a faff to set up, but that's tooling and it's getting easier and easier to get these installed now. I expect that will continue.
I've been pleasantly surprised with how much better LSP setup in neovim has gotten, as I've transitioned over to the native LSP from CoC, which is also excellent. It's still not pain-free to setup, but it's much easier than it was and I suspect you're right that it'll continue to get easier... though I doubt it'll get anywhere close to how easy VS Code is to use any time soon.
HowardStark
While I was going through the effort to set up DAP support, I discovered [mason.nvim](https://github.com/williamboman/mason.nvim) which has been a game-changer for LSP, DAP, and linter setups.
There had previously been fragmented plugins (williamboman/nvim-lsp-installer was Mason's predecessor and is a good example) that solved the problem of installation and management for each of these. With Mason, I feel that the story for managing different language environments has jumped to be extremely close to VSCode's extensions.
the_mitsuhiko
> The people that use neo/vim are going to continue using it, even if Helix is better. The people who aren't yet using it will use vs-code and the few that do switch
I'm not so sure. I have been using vim for years and I still do, but in the last few years the majority of my use has been vscode with the vim plugin. I have seen the same pattern in many others.
Helix is right up my alley and I'm definitely playing with it. It's not a straight vim replacement for many reasons and it's also not yet a vscode replacement for me, but I'm very excited about it and I can absolutely see it replacing my use of vim sooner or later.
alwillis
I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
Yeah, that’s not going to happen.
It’s cool to have choices, but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
I’ve been super impressed with the progress of Neovim and the team behind it. It’s only at version 0.8 but they’ve done some amazing things already.
I expect Neovim will get to the “batteries included” stage with Treesitter and LSP; it’s not far from there right now. And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included. Helix sounds like it’s similar to one of these Neovim distributions.
Again, Neovim gives you choices: you can configure and tweak it to your heart’s content if you want or you can get something pre-configured with all the goodies installed and configured. Or you can use it headless from a different frontend (VS Code, browser, etc.) if that’s what’s needed.
Perhaps the best thing about Neovim is how great it is for both longtime Vim/Vi users and brand new users who are ready to graduate from Notepad and Nano.
kamaal
>>And there are several Neovim distributions (LunarVim, Nvchad, etc.) that have all of the bells and whistles included.
Problem with distributions is as the contributions decrease they start becoming abandonware with time.
Leaving you with with vim and having to work through the configuration hell on the long term for yourself.
>>Again, Neovim gives you choices: you can configure and tweak it to your heart’s content
Trust me this is negative thing, not exactly something most programmers want. Most programmers don't enjoy configuring their IDE/Editors as a full time project together with your regular day job.
Corrado
I agree with this. I spend most of my days on newly created systems (AWS EC2 instances) that are bone stock. I don't use any vim plugins at all because they wouldn't be the same everywhere and it's not worth configuring a system I'll only use for 2 hours. If I could get a full featured IDE installed by default on my systems I would ditch vim in a heartbeat.
dagw
but you wouldn’t be the first person to think a new editor is going to replace Vim/Neovim. Vim is literally on every Unix/Linux server; every sysadmin can count on it being there.
Even that is a new(ish) development. For a long time people where saying exactly that about vim. I'm not _that_ old, and I was told early in my career not to get too dependent on either vim or the GNU tools since they probably won't be installed on most systems you connect to.
michaelcampbell
> every sysadmin can count on it being there.
Ah, this old chestnut.
I don't disagree with your overall point, but that audience is pretty small, and the number of people who text edit a lot that a) need to float between machines frequently AND b) don't have enough access to install what they want is even smaller.
dahfizz
> Those are by far the most important features for a text editor to have
To you, maybe. The most important features of an editor for me, and for many people, is that it is stable, dependable, and ubiquitous.
There is no way I am going to re-learn years of muscle memory for a "post-modern" editor. Cool and trendy is the exact opposite of what I want in my tools. What happens with the authors get bored and move on to the next shiny thing?
Vim is available on ~every machine I could possibly interact with. There is a vim mode in every single mainstream editor / IDE. My Vim muscle memory will keep me productive for the rest of my life.
IMO, making something slightly nicer to configure is never going to overcome the inertia of a project like Vim. The new editor would have to be like 3x better to convince everyone to make the switch, not 1.1x better in some specific areas.
BanazirGalbasi
> Vim is available on ~every machine I could possibly interact with.
This is my exact reasoning for sticking with Vim. I use Neovim on my desktop, but I work with servers and have a homelab where I just want the greatest common factor. Nano is also an option, but just like you, my Vim muscle memory is embedded and I end up with :wq everywhere.
Is Helix cool? Absolutely. Will it replace [Neo]Vim? Not until it's installed by default everywhere, and that won't happen unless it has a compatibility mode for Vim shortcuts.
kovac
Exactly. The features OP described are IDE like features that many vim users like myself don't want in my basic text editor. Adding extra features via plugins is not an afterthought but design. He clearly doesn't understand the vim/neovim crowd and the design philosophy.
Small correction though, vi is available on every machine, not vim. But indeed this is big reason why I use vim for my own stuff.
ratorx
Do you have any specific examples of things helix does better than neovim?
I think the neovim implementation of LSP and treesitter is quite nice. It was not that polished when I tried it last, but I think once it becomes mature, it will be really flexible. Tree sitter specifically is still considered experimental, but I think the timeline for that to be better integrated will be significantly faster than it takes for any new editor to get a decently sized community around it.
The zero config part of it is nice, but I think you’d be competing with e.g. VSCode with modal bindings on that note. Vim/Neovim have always had a fairly steep learning curve, and I can’t see that aspect of it mattering as significantly, especially since I only see LSP/Treesitter support improving in neovim.
p-e-w
There's a difference between having a "learning curve" and having to spend effort setting up things that work out of the box in another editor.
Vim advocates generally claim that investing time learning the Vim keybindings pays off as saved time during later work. But that's not what's happening here. If LSP just works in Helix, and requires fiddling with config files in Neovim, then Neovim is wasting my time, not teaching me something that will be valuable later on.
ratorx
Yeah, learning curve may not be the best way to phrase it. But I think that is the price of flexibility to be able to create an editor in which you don’t have to use LSP if you don’t want to.
Personally, I think keeping Neovim the editor separate from something like nvim-lspconfig is pretty nice right now, to be able to update them separately, which is nice for new languages and language server changes. Maybe it (and the broader LSP ecosystem) will eventually be mature enough to be included by default.
I’d also say that if you want zero config, just using a config framework (there are a few), gets you most of the way there, whilst retaining more of the flexibility but that’s not a strong point in favour of Neovim.
Still, until Helix gets a comparable community and some features over a properly configured neovim, I think it will be hard to displace it (and Vim, EMacs etc.) because Helix doesn’t currently doesn’t as anything significant for existing users.
dahfizz
This may be a factor for brand new devs, but everyone who uses vim already has it setup, by definition.
One time setup cost is a small factor in choosing an editor. Stability and ubiquity are more important IMO.
rjzzleep
Sometimes treesitter has problems. Indenting has gotten worse and configuration is a lot more complex.
I have the same config with some neovim / vim specifics and I find myself using vim more often even though the neovim features are "cooler".
I wonder if it will ever become "mature". It doesn't crash for that matter, but you have to keep everything updated constantly. Vim doesn't really have that problem.
Helix looks cool too, but I was looking for what it has that the others don't have and I can't figure it out. The website just makes it seem like it's cooler than the others.
ratorx
Treesitter is still a bit iffy. LSP is a bit better, but is still not amazingly mature (but some of this is to do with the LSP servers themselves not being that mature).
Other than that, I haven’t had any problems with Neovim. Everything else has been rock solid, and I haven’t needed to update frequently for anything else. Have you experienced other issues?
However, these are the larger “killer” features of neovim, so at this point there’s not that much over Vim. However, there aren’t any Vim features I use that are missing in Neovim either. There are a couple of minor things that push Neovim over though (`inccommand`, Lua is marginally nicer, Neovim plugin scene has exploded recently).
So since Neovim (for me) has feature parity and equal reliability, with some really nice added frills and some moderately reliable, but maybe not incredibly mature, killer features it still beats Vim in my book.
norman784
For me personally is better because it works out of the box and their built in features are most of the things I need, fuzzy finder for files in the project, opened buffers, LSP, syntax highlight, etc.
If you are an old vim/nvim user, you already know deeply your editor/ecosystem and your config file is very solid, you definitely won't like helix at least yet, you need to learn to do everything the helix way and not the vim/nvim customised way you build all those years.
So I will say that for developers that are starting using terminal editors, helix is a very good starting point, because of the built in stuff that it seems essential at this point in time for an editor to already have and that might be what helix does better.
elromulous
> I fully expect Helix to replace Vim, Neovim, and Kakoune for most users in the long run.
I hope this doesn't come off as flippant: I thought your comment was sarcastic at first.
While I love seeing newer / better software displacing the old and crusty, this seems a little unlikely, no? It seems like somewhat of a miracle that neovim has taken as much share as it has.
P.s. I'm hoping to eat my words one day.
p-e-w
> It seems like somewhat of a miracle that neovim has taken as much share as it has.
It's not a miracle but rather a testament to how much Neovim improves upon Vim. The number of useful features, among them Tree-Sitter and LSP, that Neovim has introduced has ended what feels like decades of stagnation in Vim development.
Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model. That's essentially what Helix is. The Vim -> Neovim improvement is nothing compared to what Helix will deliver (and already is delivering in many aspects).
pg999w
> Now imagine an editor like Neovim, but instead of working through 30 years of cruft and legacy code, it's built from the start using modern software engineering techniques and incorporates such features into its core editing model.
User inertia is strong. Neovim has its success because of its improvement, but more importantly, the keymap and config language is based on Vim7. Vim7 users can painlessly switch to Neovim with all config preserved. That's the main reason why Neovim can gain a large number of users initially. Conversely, Helix has no keymap nor configuration compatibility with Vim or other mainstream editors. Given this, I see no hope that Helix will become mainstream.
bee_rider
IMO it is not that surprising that neovim has had some success, in the same way that it isn't very surprising that SwayWM has had some success. They both have the benefit of, in many cases, being completely compatible with the tool they want to replace. Being almost completely compatible with the old tool, while integrating a popular new technology (LSP or wayland) seems to be the only way to win over users who already have a strong connection to their tools of choice.
My vimrc already has a bunch of configuration in it, I'll give Helix a try when it is able to parse that (so, probably never, I guess).
isatty
> Those are by far the most important features for a text editor to have
The most important feature of a text editor is that it can edit text well. Vim is popular because it’s the best _text editor_ not because it has a bunch of plugins making it an IDE.
discreteevent
> the best _text editor_
Code is text. So it is good to have a very good text editor for manipulating it as text. But code is also very different from plain text. It is highly structured. When I think about code I think about it as some kind of syntax tree (call hierarchies etc) . I don't think about it as character buffers. So if I am programming and I can have something that supports good text editing but also good tree editing then I will take that over something that only does good text editing.
Myrmornis
I agree with this. I have never been a vim/neovim/helix user, so there's little I can contribute here. But I have always used paredit commands as much as possible, in all languages, not just lisps, and that's still true now that I've switched to vscode from emacs. I'm curious whether any vim/helix editing operations are "tree-based" in a similar way to paredit, and also whether anyone's building a paredit-like editing system based on treesitter.
bee_rider
I don't see it. If you want IDE features in a text editor, you can use VSCode, it even has vim bindings that are at least trying (with middling success) to match the originals. The addressable market for Helix seems to be (neo)vim users who aren't picky about keybindings and new users who want a terminal editor in 2022. So... on the bright side the developers can probably have one-to-one conversations with all 10 of these people.
BaculumMeumEst
I think you're overestimating the likelihood that Tree-sitter is going to gain enough traction to be reliable for general purpose text editing. It's great for popular modern languages, but not for everything, and there's no fallback in Helix. I'm not convinced that's ever going to change.
p-e-w
Reliable? I trust Tree-Sitter's grammars a hundred times more than the underspecified regex monstrosities that power highlighting in other editors.
Tree-Sitter grammars are unit tested, have usable primitives for precedence and associativity, and are generally far more predictable than previous highlighting systems.
Also, name a language for which there is no Tree-Sitter grammar yet. The only remaining ones are so obscure that the missing "fallback" is irrelevant for 99% of users.
albertoCaroM
Is there Asciidoctor tree-sitter grammar? I can't find one.
BaculumMeumEst
Python, Janet, Haskell, and Hare were the filetypes I remember either being unsupported or not working well. I need to be able to depend on basic language support from my text editor, even when I work with niche languages.
wvh
I have been trying out Helix for the last few months as part of my now 24 year quest to incorporate some form of vi into my daily routine. This time, it's looking good. What sets it apart are the (zero-conf) built-in LSP and tree-sitter highlighting, and the select-verb modal keybindings instead of vi's verb-object syntax, where you see what you're about to do before you do it. Some of the key combinations also show a reminder menu, aiding the learning process, which is a nice touch over plain old vi which has zero discoverability. General performance is also very good, the editor feels a lot snappier than a fully loaded Neovim or Doom Emacs, or a monster like Visual Code.
I think there are plans to see if a graphical editor could be built on top of it, which would be an interesting project. As a new Rust graphical tree-sitter based editor, it would probably rival the upcoming open-or-not Zed editor by the Atom folks.
fordsmith
Man, I don't know what has happened but the spur for new editors has.been delightful. I have been using Zed for a bit since I made it into the closed beta, but it has been very nice to use. VSCode does the job pretty well, but it just feels more clunky to me, and I have hitches quite often. It is not bad, but I want something more performant while giving me the style of vim and emacs. Zed definitely has some rough edges and some sorely missing features (that are being worked on), but it just feels better to use.
I know so many people probably discount these projects because of the RIIR meme, but it really has spurred more inovations that we should all be grateful for.
dilap
RIIR doesn't scare me at all -- as a user, my experience has been the rust rewrites are usually high-quality improvements over the original. Ripgrep is legendary!
It is a huge accomplishment of Rust to enable the creation of better versions of lang-standing highly-optimized-C tools.
(Which inspired me to kick the tires a bit on the language; it felt like C++ done right to me. Being able to write threaded code w/o fear of data-races is very cool.)
tambourine_man
For the uninitiated: RIIR = Rewrite it in Rust
caeril
> Man, I don't know what has happened
My guess is that 4coder kicked all this off.
rjzzleep
I actually think that the place where it could potentially really shine is when you have to do remote shell work. I don't know if you can specify the runtime folder but if you use it as a simple replacement for nano on old machines that don't have a proper editor this would be perfect.
kamaal
vscode is very good at this, and is the primary reason why I even use it.
Frankly speaking the vim/emacs lines are yet to catch up with this sort of thinking. vscode feels like you are editing on the local machine. The experience is seamless and feels magical.
sceadu
You can use tramp in emacs?
dmillar
It could be cleaner. My understanding is that you need different extension(s) to manipulate files requiring elevated access (e.g. sudo).
caeril
>> when you have to do remote shell work
> vscode is very good at this
I'm sorry, but what? VSCode over ssh? Huh?
mattrighetti
Zed is more aimed towards collaborative development at the moment, at least this is how it’s marketed on their website.
archseer
Helix author here: I think the poster chose an unfortunate headline.
1) Helix was written to replace my neovim setup but is in fact kakoune inspired. 2) It's written in Rust but I don't draw focus to it precisely because RiiR/"X in Rust" posts are getting a bit tiring to see.
Casperin
Helix is awesome. Thank you for doing this!
psuresh
Does this 'written in Rust, written in Zig, written in Go' make any difference in the user experience? See this often nowadays.
phao
Directly, I believe this has more to do with people interested in the language seeing it being used in actual projects.
Indirectly (a lot indirectly), sure. Maybe the software should perform better or maybe have fewer bugs because programming language X or Y is understood to help with those things. Maybe it showcases a more flexible architectural design, which leads to more potential features in future versions, etc.
galangalalgol
It also hints at the mindset and values of the creator. Communities around languages value things that may or may not line up with the qualities of the language they form around, but simply the fact they value those things is reflected by rhe things they produce. If people think a language is performant, then performance will be something their community values. If it is known for having a learning curve, their product might too.
acje
A bit like seeing «car built in carbon fiber”. May poke the interest in materials or imply different quality attributes and design intent.
Voklen
Yes, because if it's a language I'm comfortable in, if there's a bug I can hop into the code and try fix it myself. I find this happens most often for me with Flutter projects to be fair.
packetlost
Yeah, it's a tool targeting developers. The language matters to a certain subset of people who don't throw their arms up and move on when they encounter a bug.
the_mitsuhiko
If "contributing to the project" is part of the user experience then yes.
flohofwoe
Technically no, but quite often they are easier to install and tinker with than C/C++ projects (for instance usually you just need to clone the repo and run either 'cargo build' or 'zig build', and it mostly 'just works' no matter the platform).
Some C/C++ projects which have switched to cmake are equally easy to build (well not quite: "mkdir build && cd build && cmake .. && cmake --build ."), but it's definitely not the norm.
stonogo
Yes, it's a useful indicator of how portable the software is. I can ignore systems software written in Rust because it only works in places that LLVM targets, and extending LLVM is a nightmarish process. I can ignore software written in Zig because until this year (or arguably last year) it's been a one-man hobby project, worth checking on again in about a decade. For now there are too many weird bugs that pop up if you use platforms different from the main developer. "Written in Go" means I at least have a chance of fixing deployment problems, becausae crosscompiling is easy and the language is fully self-hosted.
gnulynnux
Yes. In my experience, Rust projects are always easy to install. Cargo is much nicer than, say, npm or conda.
slazaro
I assume, besides looking for contributors, that not being based on Atom or similar is a selling point.
allisdust
For an editor? Makes a lot of difference. The day intellij ide is rewriten in non gc/dynamic language, there will be a noticeable improvement in performance and number of times the ide has to be restarted because it ate all the memory.
nkozyra
If IntelliJ stuff were not GUIs and instead terminal apps I suspect that would be a pretty big performance boost, too.
doix
Super cool to see another competitor in this space. There's no support for tabs, I really hope it's coming and they implement them in the same way vim does. So far the buffer/window implementation matches vim (as far as I can tell), so I really hope the tab implementation matches as well.
If they could implement the client/server architecture of kakoune, then this would really best editor (for me). It's a shame each editor implements a different subset of all the features I like and I'm always choosing between them.
Edit: Looks like there's an issue for tabs: https://github.com/helix-editor/helix/issues/2295 , doesn't have too much traction. I hope someone picks it up, unfortunately my rust sucks far too much to get it done in any reasonable amount of time.
gnull
Tabs should be implemented by an external tool, like Tmux or whatever. This is how Kakoune does it.
doix
Kakoune has a client/server mode so that the client instances can talk to the same server. This way unsaved changes to a buffer are visible across instances + all the registers etc are shared.
Helix doesn't have that functionality. Kakoune also doesn't have splits at all where as Helix does, so the design philosophy is different between the editors.
Personally, I would prefer if tabs were first class citizens in the editor, but would make do with scuffed tabs if there was a server/client model implemented.
cloverr20
I have not tried the editor itself, but one thing that puts me off is how some people are claiming its going to replace vim/nevoim and others by the virtue of its great LSP and tree sitter support. I am working as a full time developer for the last 4-5 years and I never needed to use auto complete (for long words C-x n is there) and the current syntax highlighting seems fine. Vim is working great for me and I don't feel any reason to switch to others. Instead of bashing other editors, maybe just tell what makes your editor unique and why people would want to use it?
oefrha
> by the virtue of its great LSP and tree sitter support.
> maybe just tell ... why people would want to use it?
Apparently they did tell you, and you’re not interested. Fine, but what a pointless comment. Rob Pike will also tell you how he loves coding without syntax highlighting, which you apparently find useful.
mpalmer
It's not a "pointless comment". Why would someone want to use it every day over Vim or Neovim? The only benefit of Helix specific to LSP and tree-sitter is the ease of configuration, a mostly fixed cost. Then what?
oefrha
That would be a reasonable comment, and people have been discussing that in this very thread. The one I replied to is "I don't use autocomplete, so you didn't tell me what's good about this editor, except you actually did and I even acknowledged that". Pointless.
undefined
spion
When you say you never needed LSP, do you mean you've tried it and found no benefit to having it, or do you mean you're doing just fine without it? (Because its possible to do just fine without it yet still find significant benefit to having it).
What LSP does for me is instant documentation integrated into the editor and getting constant feedback if you get it wrong (at least from a typechecking perspective). I guess that in many cases, you can get something similar by having a documentation window open on the side as well as automated unit tests in a second terminal re-running on every save.
cloverr20
I have tried using it few times but I didn't see much benefit of using it, I am mostly working with python/django/javascript/react and by now most of the common functions I already know, so I didn't see much use of it and tbh it felt a bit distracting to me when a big hover definition came when I am typing something.
The times when I don't remember how something works, usually I have to go the stackoverflow answers/documentation to read on how it works, maybe try it out a few times in the shell, before writing the code. For typechecking and errors I have been using ALE and it does give a warning if there's something wrong and this setup is working fine for me.
kkkrist
I feel you. Vim has been such a staple in my dev life. So much that switching felt like betraying sweet uncle Bram ;-) And without the need to write typescript, I probably wouldn't have switched. But what made me stay even for non-typescript work were the little things, like the positions in the location and quickfix list being auto-updated while editing, being (feeling?) faster and more responsive, the saner default settings (server usage) etc.
Regarding lsp integration, it's just nice to have project-based instead of buffer-based auto-completion, auto-insertion of import statements etc. Definitely makes me more productive. Setting it up the way I wanted (non-obstrusive, on-demand) was a bit of pain though.
lancebeet
I use vim with ale. Linting, go-to- definition etc. for typescript (or really any other language I use) just works automagically. It took more effort to get it working in vscode. I haven't tried neovim or helix yet. They both seem great, but it seems to me that people here might be slightly exaggerating the difficulty of getting this working with regular old vim.
kkkrist
Well, I tried ALE and it worked ok. Compared to the neovim built-in lsp client it just doesn't display as much info and does not support multiple hints per line. There's also CoC which should also work with regular vim and which I've used for a while, but it wasn't very stable for me (the auto-insertion of import statements made it crash frequently for example). The built-in lsp client seems to be the cleanest, fastest and most stable implementation. Using nvim-lspconfig it was fairly easy to set as well. It just took me a while to find out how to disable all the distracting live-/auto- completion, underlining, inline-hints etc. (vim.diagnostic.config)
pornel
For a long time I had the same opinion (using Sublime Text with its plain same-file autocomplete). It's okay, but after using LSP for a while, I'm sold on it. It really is nicer, and I wouldn't go back to my pre-LSP times.
"Go to definition" and "Find references" is faster and more precise than grepping, especially for common function names. This lets me browse larger codebases, even if I don't remember their layout.
Being able to peek at actual types of variables is quite useful in Rust which has type inference. I can check types instead of deducing issues out of compile errors.
LSP support for like "Extract into function/module" are great for refactoring eliminating most of the busywork. Renames are also more reliable than find'n'replace, especially when I'm renaming because the name is ambiguous.
awestroke
tnfru
He very explicitly stated what about the post was off-putting to him. You made a comment about being personally attacked while repeating the tool is better without any argument whatsoever. You're exactly proving the point of the comment.
coldtea
>what about the post was off-putting to him
And the part that they listed as "off-putting" was a very tame and popular sentiment, to the point that it's off-putting itself (or at least bizarre) to be "off-put" by it.
Not to mention that the whole comment is based on a bizarro claim amounting to "who needs LSP/treesitter anyway" and how they can't see the point of those (probably the most requested features from any new editor), since he "never uses autocomplete".
Still, "I can't see the point for feature X" and "I never use X" are totally fine. But saying that people saying they appreciate them and consider them important is "off-putting"?
awestroke
No, they stated that they personally have no interest in using better tools (lsp, autocomplete etc).
cloverr20
See I am not against newer tools, I am using a lot of newer tools myself like fd/rg. What I am against is claims like "Ths new tool will replace everything else that has been made". Let people decide what works for them and choose accordingly.
scblock
I gave Helix a try last week and I think there are a lot of things to like about it, but until it supports soft text wrapping for prose documents it's effectively useless to me. I'm not going to bounce back and forth between neovim and helix depending on whether I'm editing code, documentation, or personal notes.
The comments on the open issue in Github are not particularly encouraging.
bobbyskelton41
I would say they're pretty encouraging. There's a straightforward path to implement it, and some work is being done on that front.
aussiesnack
As far as I understand from scanning the PR, there's been more than a year of discussion with no actual progress on a basic (if not in this case simple to implement) feature which is universally available in text editors. Helix looks nice in many ways (I installed it last night and have worked with it on a couple of Rust projects today) but it's clearly more of a research project with potential than current practical tool.
bobbyskelton41
I wouldn't say so. It's taken so long because it hasn't been a priority for the developers, and nobody else picked it up.
Protostome
I'm a big fan of open source software and have tons of respect for any OSS developer, regardless of the software he/she develops.
But I have to say, as a developer who has been taking part in the OSS scence for the last 20 years, it is very strange to me that some developers feel obliged to indicate they wrote a piece of code with Rust.
If I'm a user, I care much more that this is a usable software than what kind of programming language was used. For all I care, write it in binary. Rust may be a great programming language, but it is only a mean to an end.
cactus2093
I can think of several ways this is useful to know:
1. As OSS software, some users will want to edit the code and add features, and knowing what language it’s written in is a pre-requisite to doing that.
2. The developer community is an important factor in making OSS projects successful. If I’m going to take a chance on a young project, I want to know that it is set up to have a strong community and continue to be improved over time. If it was hand-written in binary or assembly as you suggest, there is no chance it would grow a popular community of developer contributions.
3. Like it or not, different programming language communities have developed around different values in how to build software. The Rust community generally promotes strong type safety that makes entire classes of bugs much less likely which is a plus to me as a user.
4. With editors in particular, the language it’s written in often leaks into the user experience. E.g. Emacs is written and configured in Lisp, Vim has a ton of legacy cruft in the C and vimscript codebase that can make it annoying to compile/install, annoying to build plugins for, and has made modern features like asynchronous tasks difficult to add, which was the whole reason for neovim existing. VSCode has plugins written in JavaScript. Knowing this project is written in Rust gives me some hints that it probably won’t share any of these similarities with these other editors.
chatterhead
Pretty sure the Rust nod is for the HN audience; not just a nebulous end user.
cercatrova
See also Lapce, an editor also written in Rust although it's trying to compete more with VSCode rather than Vim.
Also, RIP OniVim 2, it was great having been written in a similarly fast ReasonML/OCaml but the creator ran out of funding and had to get a job. A shame, it even had compatibility with VSCode extensions.
IshKebab
Lapce is looking really promising IMO. It's very fast, has single-click support for a few languages (Rust of course) and the UI is surprisingly complete.
Obviously there are still a ton of paper cuts but it's still very impressive and they are very welcoming of contributions.
The only thing that concerns me slightly is that they're using their own fork of Druid which was pretty much labelled a failed experiment by its primary author (though tbf he still seems to be working on it). On the other hand the UI mostly looks and works really well! I've only noticed a couple of niggles - misalignments, labels not linked to check boxes, ugly context menus on Windows etc. (and that last one is mostly Windows's fault).
sullyj3
Oni was presumably dead in the water as soon as they switched from Neovim to vim, as the initial backers would have been primarily composed of neovim enthusiasts
skavi
Does anyone know what happened to Zas editor [0]? I was a huge fan of the concept (a mac-assed app [1] with first class Rust support).
In fact, I was such a fan that I bought it, which has turned out to be a rather foolish move. The people behind it have gone completely silent.
[0]: https://news.ycombinator.com/item?id=30952084
[1]: https://daringfireball.net/linked/2020/03/20/mac-assed-mac-a...
mgrandl
Yeah seems like a scam. I paid for it, requested an invoice and never got a reply. Never received a single software update either.
Q-and-A
Does anyone happen to know if there is a terminal IDE that more or less operates like the very basics of popular GUI IDEs? By this I mean has a file manager pane which can be manipulated by mouse, allows multiple open tabs which are selectable and closable by mouse, is generally mouse-aware with regard to cursor activity on the text, and operates as a regular user would expect (not modal)? The closest thing I've found to this is Micro, but the full IDE experience is missing.
I know mouse-aware file manager and tab capabilities are possible in terminal IDEs, but I haven't seen anything that simply put it all together as a cohesive and easy-to-use whole that anyone who has used VSCode could quickly start using for basic editing of multiple files in a project.
bartq
Try https://github.com/AstroNvim/AstroNvim, mouse works nicely out of the box, there is also a files tree.
sanxiyn
You may want to try Warp: https://www.warp.dev/
__warlord__
You require to log in to use this. For me is a no no.
Next thing you know... you have warp stories in your terminal.
anthomtb
Can I ask why you would want such a mouse-aware terminal-based IDE? Because it sounds like an oxymoron.
davidatbu
Not OP, but I get their frustration. File browsing is not very amenable to keyboard based navigation IMO. I'm currently using fdfind through telescope.nvim as well as another neovim plugin for this, but I can easily see why someone would want to use a terminal based text editor, with a mouse based file navigation tool.
Test0129
Not to shove Emacs into a Vim thread but Emacs file browsing is actually pleasurable. You can have a tree if you want (neotree) but C-x C-f with Ivy fuzzy search makes navigating really easy. It's one of the things I wish Vim had for a long time and one of the things that eventually drew me away from Vim to Emacs.
Anyway, to add to your point there are also cases where highlighting a large chunk of code is often easier with mouse based nav.
drekipus
Emacs
rami3l
I love to see that Helix tries its best to ensure an out-of-the-box experience, as well as to add so many interactive hints for key combinations (for example when you want to paste in insert mode with C-R it’ll immediately list a set of registers that you can paste from).
However Vim is much more to me. It’s not just an editor, but a keybinding that I can use not only in nain, but also in VSCode, in fish shell, and even in GHCi REPL.
How long would it take to make them all support (some reasonable subset of) Helix?
rami3l
* nain -> nvim
Get the top HN stories in your inbox every day.
I've used Helix for all my recreational programming projects (in Rust) for about 6 months and I've written about 10kLOC of code with it. Still using vim at $WORK for a variety of reasons (giant c++ codebase that does not easily plug in to clangd/LSP), but I might be doing the switch soon.
Installation was easy and the default configuration is good. Plugging in rust-analyzer still needed a line or two of config file editing, but that should not be necessary for very long. Hint: use `hx --health` to check that all the tools are properly installed and configured (it shows a matrix of programming languages and their associated tooling, with red/green check marks).
My Helix config file is about 5 lines long, but my Vim config is in the hundreds of lines.
I had very little friction coming from Vim and a little bit of Kakoune.
I particularly like the fact that all the important features are built-in and not half baked scripts with unintended side effects (e.g. opening a Makefile in Vim triggers a ftplugin script that messes editor-global config instead of buffer-local, with the default out of the box scripts).
Lots of people are requesting a plugin extension system, which is kinda understandable since every editor seems to have one. But I haven't had a need to add any kind of plugin, and it's easy enough to fork a shell for an external process if needed.
It's still rough around the edges, but good enough for a daily driver.
Thanks to everyone working on the project.