Long-time Vim/NeoVim user here...about 20 or so years with it being my daily driver for the last 8. As soon as I found Helix, I was unsure whether it would become my new editor, but I've been using it every day for a few months and haven't really looked back. The only thing I still use Vim for is `vimdiff` with Git, but I don't think I need to, just been lazy about configuring Helix to do the same thing.
Helix does everything I need, nothing I don't, and I don't have to learn a bunch of esoteric syntax. It's a great editor for people new to the world of shell editing, and I highly suggest trying it out.
I am contributor to helix that is working on bringing diff functionality to helix.
You can check the current progress on the first related PR on github (https://github.com/helix-editor/helix/pull/3890). The PR is pretty far along. A new gitoxide release is happening today and once that is out we will only be waiting for an upstream library to merge my fixes.
The machinery developed in that PR contains most of the heavy lifting for implementing a vimdiff tool. The only thing that is missing is support in the rendering system to display them. I will be collaborating with one of the maintainers to make that happen as well so we will get a diff mode in helix sooner rather then later.
I used vim as my daily driver probably for the same amount of time as you and couldn't make the switch . The lack of tabs and folding destroyed my workflow.
I like to set my splits up a certain way when I'm working on something specific and then make a new tab when I change context. Then I just change tabs to context-switch quickly.
I also immediately fold all when I open a file to get an "overview" and then slowly dig in deeper.
Both currently impossible in helix (at least last time I checked).
A lot of my muscle memory also doesn't work, specifically with shift+v and selecting/moving sections around quickly.
I got used to the different order of things fairly quickly, but I'm not convinced it's actually more efficient.
I also found the random pop-ups with hints really annoying and distracting. I'm guessing there's probably a config to disable them but I haven't looked into it.
I used it for a few days, but the not-quite-vim keybindings also destroyed my workflow - I'm a slow learner, took me a while to figure out the few vim commands I know and I hate to relearn everything a bit differently.
One thing I really liked about it was the UI experience where as soon as you typed the first character of some sequence it started showing you all the other option starting with the same character. (Try pressing space or Ctr-w in Normal mode)
It made the whole thing far more explorable and I really thought it was a good experience although clearly not yet on par with something as fully mature as vim (but also with far less technical baggage).
The first thing I did on my vim setup was installing an extension which gave me very similar command completions.
>Were you also able to replicate the small popups that open when you press `m`, `g`, etc.?
Yes, although 'm' has a totally different meaning in vim (placing a mark), so there is no popup for that. But it works where there are actually sensible choices, even for marks it works and shows you every available one, which is pretty cool
I'm a huge fan of Helix, use it everyday. LSP works out of the box(if you install it with a package manager, otherwise you need to do a bit of config) .My configuration file has 5 lines or so, great defaults. No need for overly complicated configuration, or installing dozens of plugins, etc.. Did I mentioned is crazy fast? Opens in ms, and everything feels very snappy. The only thing I noticed, when I use it with tmux, the colorscheme get reverted, dunno if that is a tmux issue or not. But in general, great editor, thanks to the authors.
I recently got into neovim (from vscode) and it took me 1.5 weeks to get it to have similar functionality. I really like the vim commands though. What’s your opinion on that compared to helix?
I've switched to helix, from neovim and I can say that I like the commands much more. It feels like they took vim commands and made them much more consistent. Plus the UX is so good, lsp out of the box and all. In neovim I always feelt like my config was missing something but helix feels good without even touching the config. Much recommended.
Helix just has better out of the box experience. Will take you like 5 minutes to setup instead of 1.5 weeks. It is just so much easier to start a model editor if you havent used one before.
I'm a long-time user of Emacs, and although I don't see myself switching to Helix, one thing that I really liked when I looked at Helix was how good the out-of-the-box experience was. As I get older, I am annoyed at the amount of customization that I have for different programs, and I wish I had fewer dotfiles that to maintain and carry around. I recently started trying some of my daily drivers (alacritty, fish, tmux, git) without my configurations and though they're a bit less comfortable, they're pretty good nonetheless. I would probably put Helix in that category: I would probably be fine just using the thing without any customization, because the defaults are so well chosen and polished.
Tree-sitter and LSP (language server protocol) are both global standards. If you support them then you automatically support any language that has a tree-sitter grammar or implements an LSP.
My assumption has been JetBrains' implementations are better for languages that they support deeply since they have so many more man-hours of polish, but e.g. Rust is going to be better with LSP than JetBrains' plugin implementation.
I have not used the LSP directly, but Python's LSP uses Jedi under the hood, the same code as VS Code's official Python extension - it is very good.
JetBrains put in lots of effort but they are just one company - the power of LSP is that the whole community (including companies like Microsoft) are building a single tool that all IDEs and editors can use. Granted I hit a couple of bugs as it is under heavy development but I think they'll win out in the long term.
Not quite, it gets you about 90% there. Even with a grammar to use off the shelf, you still need to write queries to make use of it for highlighting, text object selection, auto indenting, etc. These have so far been particular to the editor.
It's a delight to use it, opens in a few milliseconds, has everything I need, you can't and don't need to configure it much. It just works. No distractions.
I gave this a couple of tries but my vim muscle memory is actively hurting me the longer I try... I would love if this had a - at least somewhat closer to - vim-mode, because all the rest, LSP, startup speed, etc, is excellent.
Because it's not the same as vim, they've made some fundamentally different choices and their default binds reflect that. I genuinely think helix stands to be better, it lacks the community and thus the extensions of vim/neovim as well as decades of experience, so it's hard to replace it, but for me it's managed to nevertheless.
Helix primarily follows the Kakoune model instead of Vim's. It can be confusing to switch from Vim, but Helix's model tends to be more intuitive if one does not already have Vim muscle memory.
Am I the only one that doesn't have any strong preference for some editor?
I am always super impressed by all the comments stating how much of a night/day difference editors make to them.
I have to say that I have tried many (VSC, neovim, Emacs and Spacemacs mostly) in the last five years but at the end of the day I feel like none makes such a difference to me so I just default to whatever my colleagues use to make collaboration (fixing ide issuesm, exchanging configs and tips) easier.
Do you have strong opinions about what operating system you use? Makes me wonder what the most common area of the stack people's choices are for where their choice is strongly preferred in their computing experience.
Also, I imagine that team size and existing diversity of choice plays a role as well.
You're stuck using things like that. For work, you're stuck choosing from what's available, because the work is to be done now, not later.
If choosing I'd go with Mac for work. They have hardware that is reliable, and software that is approachable. Unless it's 3-4 levels deep into MS tech, I'd be confident the Mac can handle it.
If I was starting a new project for myself, like a game or a SaaS thing, then I'd go with some Debian or Arch peppered with a RoFi search/command thing, and a window manager akin to i3. A development machine, entirely geared towards looking at and making of code.
But if time wasn't an issue I would not jump on any of the things available to me. They are all largely misguided with relation to my goals. None of them are particularly enabling. All of them are better than center-aligned Comic Sans in a Word.app document, but none of them integrate my prior knowledge, or even the projects I previously did. Every new project is entirely new anyways.
Computers kinda went the sellout route circa 2012, the PC makers do what they understand will sell well, and there aren't any projects that are different enough to warrant an interest. The commercial offering is geared towards the common journeyman programmer, in it's entirety. There are no niche computing devices, I'd expect to see thousands of those, but still there are a handful at best.
There is like one model of a 3-year old Thinkpad that I'd buy, but it doesn't get me excited enough to actually do that. I'd put some Linux on it, with flare.
I have strong opinions. I have the 20+ years of experience to have formed them.
If I were to take a job or a gig in coding ever again, I'd ask the employer for a machine and figure it out from there. I don't care what it is. As my employer, you make these decisions and suffer their consequences.
I'm just here to figure it out, clock out and go home, where you will never, ever call or message me. You got your 8 hours, and they are as you made them come out. Get screwed.
This is surely just the bias of those willing to make a comment one way or the other. If you are so-so about it, you probably don't make the effort to make a comment.
I think the real power is in learning keybindings, either emacs or vim. You'll be able to use those shortcuts everywhere -- your IDE, shell, web browser.
I just wrote an in-depth comment about why I don't think Helix needs an extension system (despite the historical precedence from other text editors) that I think folks interested in Helix might find interesting:
https://github.com/helix-editor/helix/discussions/3806#discu...
I see a lot of vim-to-helix comments, but I have been a helix user for a little while and decided to try neovim seriously for the first time. I've used it, but I never got into it.
I like the extensibility and customizability of neovim. I do not like the action-subject (verb-noun as some put it) model flow, but that could be just muscle memory and bias. I'm going to keep at it and see if I like it better, it might turn out to be more powerful. I don't like a lot of the default binds, helix's binds just seem to be more sensible, again could be bias since I used helix first, and I can always change them.
Even in neovim you can select a region first (via 'v') and act on it later. E.g. to change till the end of the word: 'vec' (where idiomatic vi would be 'ce'), to delete the content of a block: 'vibd' (idiomatic: 'dib'), etc.
Every text editor should support multiple cursors. In fact, every text field should support it. I often copy paste things into vs code just so I can use multiple cursors to edit something.
Also block indents. If you're going to require four spaces for a quote or a code block, don't make me copy paste between an editor just so I don't have to indent each line individually.
For anyone who's used to fd/jk/kj/jj/jf or the like in Vim as an alias to ESC to exit insert mode, it looks like Helix is not too usable as of today: https://github.com/helix-editor/helix/issues/2612
I would've considered exploring Helix myself if it wasn't for this.
Looks interesting. I've always remapped capslock to CTRL myself, of course, but haven't thought of remapping tap-capslock to ESC. It looks like you need external software to do this though (like Karabiner Elements on mac, or xcape on linux, etc).
(That being said, if you're used to jk/kj/fd/jj/jf, many years of muscle memory would still take a while to erase...)
You can only map CapsLock to a single modifier in keyboard settings? Which is how I've always had it myself (caps->ctrl) but that's not what's being discussed here.
The classic mapping is Alt/Meta to send escape when tapped, because terminals send Alt-q as `ESC q`.
I have no strong opinions about how people lay out their keyboards, other than that people should try a split key if they haven't. My layout sends ESC when Alt is tapped, capslock is for backspace.
I was just making a joke about how deep we can all get into configuring every little thing on a PC - no offense or point intended, I spend as much time configuring my boxes as using them if I'm being honest.
Lite XL (lite-xl.com) is also extremely fast. Also, because a lot of it is written in Lua, you can very easily extend it yourself; you can just monkey-patch many functions and do what you want!
It's kind of immature in some ways, for example, the current release version has some limitations in the native plugin interface (which you need for loading C libraries for Lua, as Lite may use a statically linked version), and there is a conflict between the linewrapping and projectsearch plugins where opening a file from it is bugged if you have linewrapping enabled by default.
Lapce does seem more advanced in some ways, but IMO the enormous hackability of Lite is also a nice advantage.
It works quite decently, although again limitations regarding linewrapping apply; the inline lints from lint+ break linewrapping :/
Also, for Lapce I cannot find server integrations other than a few, namely Rust, JS/TS, YAML, C/C++, Go and Dart. No Python, for example. Adding Python support in Lite's LSP is as simple as adding lspconfig.pylsp.setup() to your config (and installing the server), if you already have the plugin set up correctly.
Oh, this is good to know! May I suggest putting that in the FAQ? I looked for this information but didn't see it browsing the docs (perhaps I missed it though).
I really like helix. So much that I've switched from jetbrains to neovim.
I think hx is way more "discoverable" than vim with it's "whichkey" by default functionality and it's motion-first structure is way more attractive to me.
As someone used to an IDE, I just really want git integration and other things. As soon as they land on a plugin system, maybe it will be viable.
Not a fan to be honest. I stick with vanilla so when it breaks I can read the manual. Although I know Doom works great and makes a lot of people happy, it doesn’t do anything you can’t do yourself by downloading packages and configuring them to your needs.
That is true. But it’s pretty overwhelming for a lot of folks. I was a spacemacs user. I tried to rebuild what I liked about it. It was a lot, and I didn’t quite get it there.
A modern Emacs would look like VSCode with an API that was lower level, with less built-in UI, a focus on pure text buffers, and incubated for a few years to build out more of a framework so every extension doesn’t feel completely unrelated. It’s unlikely VSCode will become that, but it’s even more unlikely to be a text editor pitched to Vim users.
Helix is really great. If only it had a VIM (or VIM-like) mode available. I find the Kanoune shortcuts really limiting, as they fail to use the relative line numbers for anything except moving the cursor. Bidirectional selection, deletion, commenting, etc. is super useful when coding.
Say I am at the last line of a part of a function, that I would like to delete - maybe some debug output. In VIM, I will look at the relative line numbers and immediately see that I would like to delete up to the number 8. Then I simply write d8<up> or d8h, and I am done.
As far as I can tell - I may be wrong - in Helix, I would have to first do 8<up> and then 9xd. Note the number 9 in there. This is due to the fact that in Helix, I have to count the number of lines I want to delete, rather than just being able to look at the relative line numbers.
In Helix you'd have to x downward or use v to enter visual mode. But you initially said that you "found kakoune bindings limiting". In kakoune you can 8Kxd, or 8K<a-x>d on less recent versions. The vim approach is usually superior for simple commands like "delete N lines", the kakoune approach is superior when you want to compose commands, e.g. `%sif<ret>f(<a-i>(sand<ret>cor` is "select all `if`, find `(`, select inside `(`, select all `and`, change to `or`"
Legit. You can do nicer than that in Helix’s defaults, but you're right that it won't match d-8-up’s concision: instead of 8-up-9-x-d ("8-move up-9-select whole lines below-delete"), you can do v-9-up-x-d, ("select-9-this line and above-the whole lines-delete").
If you're asking about what helix can do in general, though, as opposed to just the defaults, you can configure it to:
- use relative line numbering
- map a key (say, capital X) to the opposite of x’s behavior — or even better, to `[“extend_line_up”, “extend_to_line_bounds”]` ; the latter won't "eat" the first press by using it to select the current line.
- make the same tweak to lowercase x
Combined, that will get you back to 8-X-d (“8-select whole lines up from here-delete”) to delete up through where you can see 8 in the gutter (and 8-x-d in the other direction).
Agreed, but more often, I find myself in a situation, where I just want to delete, comment, or yank a few lines of a function, so I find that going by relative line numbers is a lot more flexible and useful for me.
I'm a long time user of vim/nvim and have learnt so many great techniques from "practical vim". Helix looks good, and the speed is impressive.
It does seem very code-centric though, movements seem based with this in mind. I also find it inconsistent that some movements cannot be combined with actions but others can.
Having said that, there are certainly some ways that vim could be reimagined. I find beginning and end of line movements awkwardly placed by default, as is moving up and down by half and whole pages.
I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
In my experience, as another longtime user of vim and now using helix as my daily driver, it does take a bit of getting used to. But once you grok the whole idea of "selection first, then action", it becomes a bit easier to deal with. Honestly I think Helix is a better editor for those who are looking for the features of Vim but don't want to learn its esoteric syntax. I had to learn Vi/Vim in order to work with FreeBSD machines back in the day, and I had a whole book to reference its commands, so for me it's kinda second-nature. But for new users, I can imagine Vim not being the easiest thing to figure out.
I chose to take the plunge and start using Helix most of the time because:
1. It's like Vim/NeoVim enough that I didn't constantly get stuck. Most of the modal commands are similar to Vim, and you can always fall back to mouse-based selection and using normal commands like Ctrl/Cmd+V and Ctrl/Cmd+C if you don't want to get into the registers just yet.
2. Built-in support for the stuff I actually care about. LSP, fuzzy file picking, inline docs, IDE-like features like "go to definition", it's all included. And unlike NeoVim, it doesn't crash half the time when I'm working on TypeScript files (thanks Rust!). Haven't needed CTags at all since I started using Helix.
3. It's fast. Like, way faster than NeoVim or Vim unless you don't use any plugins. And without plugins, it looks great. Tons of themes to choose from, easy to switch them in the config, etc.
> I have a feeling that movement-action paradigm as opposed to action-movement paradigm of vim will have some tradeoffs with visualisation being a plus, and more advanced repetitions bring a negative, but I haven't totally thought this through.
I think the "advanced repetition" side of this is just going to look different, more like Emacs or Sublime Text in its functionality IMO. For example, the "Migrating from Vim" guide mentions global replace (https://github.com/helix-editor/helix/wiki/Migrating-from-Vi...). This doesn't really go into how it looks, but what happens looks a lot more like NeoVim than Vim. It's still just as fast as Vim to write these commands, albeit a different syntax that you have to get used to, but the benefit is being able to see what is happening to your file while it's happening, rather than after the fact or having to jump through every instance and "confirm" it (which is problematic on large files). In other words, I think this will be/is possible to do in Helix, but it will just look a little different than in Vim.
That's really interesting, thank you for the perspective. I'm amazed so many long in the tooth vim/nvim have moved over!
I do think the movement could be better arranged in nvim/vim - but that's really just an issue of remapping keys I guess. hjkl are in a great place, the equivalent of home/end/pageup/down are odd and not ergonomic.
I compiled helix on a 1Ghz single core processor, and it runs incredibly fast on that. Very impressive.
I'm using alacritty all the time, and I'm thinking of switching to starship from powerline because powerline has noticeable startup time (I think it is python-based). Unfortunately neovim+plugins does too, probably as a result of plugins more than neovim.
I tried this and it is much nippier than my current neovim+plugins setup. I'll have to plug in a bunch more language servers to fully compare.
In a way I'm almost hoping they don't add a plugin system. There's something to be said for this all-rust future my terminal suddenly seems to have found itself in: it is quick!
I love helix. It’s my daily driver at work (python) with occasional hops over to VS Code for a graphical debugger. Would love if anyone has tips for getting the python DAP working in Helix, though.
I quite like it. I use my own fork of it that introduces a few things that make it more familiar for vim users. It’s definitely different but a lot of it is better.
It’s the first editor I’m seriously giving a try as a hardcore, many years vim user.
Having to switch between "normal" and "insert" modes all the time is one of the things that turns me off from vi and its family tree, and is consequently something that turns me off of Helix, too. There are a lot of neat ideas here, though, and I wonder how many could be hacked into other editors like Emacs.
I’m the same way- my MacBook trackpad is closer to my fingers than the escape key! Not to mention, in VSCode I can do anything with the command palette with cmd+P without the need for separate modes and without the need to memorize a million shortcuts.
If I know the first letter or two of the command, then it’s only 3 keystrokes away. For example, “Evaluate Math Expression” is “cmd+shift+p”+”ev”+”enter”. The command palette also provides great additional explorability with the fuzzy searchable menu + descriptions.
This is a far superior workflow because I have access to every possible command in the editor / installed extensions (very easily mapped to my own shortcuts of I want) without the need to memorize anything. I can even reverse-search commands by typing the shortcut and it will tell me the commands bound to that shortcut.
I could be missing something, but Vim and family feels like a huge step backwards in workflow for me.
It is really great that your workflow works for you, and you enjoy working that way! It seems like you've spent time getting used to this workflow, and now get to reap the benefits.
Be careful though, just because you are used to doing something in a specific way, doesn't mean that your way of doing it is superior!
> They are saying that their workflow is superior to the Vim workflow
Yes, for our specific tastes. We're well aware that people have different tastes and might prefer Vim's or Helix's workflow; you can spare us the lecture.
> If I know the first letter or two of the command, then it’s only 3 keystrokes away. For example, “Evaluate Math Expression” is “cmd+shift+p”+”ev”+”enter”. The command palette also provides great additional explorability with the fuzzy searchable menu + descriptions.
Similar deal for me in Emacs, especially with things like ivy or helm. Pretty much anything more complex than an existing keystroke is a simple M(eta)-x and a couple letters (and spaces for wildcards). My setup even extends that to search results, opening files, you name it.
Something like Vim or Helix could probably get most of the way there by defaulting to "insert" mode and having some keystroke like Esc or M-x to temporarily switch into a "command" mode.
Huge thank you to the helix team and contributors.
Running `hx` for the first time is one of those experiences where you go simply go, "woah". I've since never looked back and it's slowly defeating how often I open up even larger things in VS Code.
The thing that always held me back from learning `[n]vim` was the huge amount of configuration variability between all the variants and the lack of instruction on just doing something out of default. Neovim is basically the best experience out of the box but even sometimes there you want to have extra functionality. It's really hard to beat the amazing defaults in `hx` and even better `hx -g fetch||build`.
The one thing I'm still missing is ease of running singular test cases or test groups in larger codebases. This still feels hard on Helix.
It's interesting to me, reading comments in this thread, that this editor mostly seems to appeal to current vim/emacs users. It's like the first choice everyone makes when selecting an editor is deciding whether they want something that runs in the terminal, something that calls itself as an "IDE", or something in between.
Am I the only one who cares a lot more about functionality than branding or user interface?
The 80/20 rule means 20% of an editor's features are going to provide 80% of the value. Instead of focusing on an editor's presentation, why not try to identify an editor which has an unusual feature you consider valuable?
I use Emacs. I love seeing people working on new editors, too. NeoVim looks awesome, Helix is cool, I wish Kakoune was still active. BUT I don't understand why we're still writing new full-featured editors like this that only run inside terminal emulators.* We've had GUIs for 40 years! They're good, actually! It's okay to have an interface based on pixels instead of grids of characters!
Yes, of course sometimes doing a bit of in-terminal editing is the best way to get something done, but that should be quick, basic, and exceptional, not something where you need an LSP client and project management.
I want to love helix, but the transition from vim is too great with very few resources that explain how something that would be done in vim could be done in helix.
I use vim a lot. Here are my first impressions about Helix:
- It loads noticeably slower than vim on my old laptop. (Vim being immediate, Helix taking about 3 seconds).
- The default theme is purple, which I'm not a fan of.
- It's more "put together" than vim out of the box. I wish vim had a bunch of plugins installed out of the box.
- I get some vim shortcuts but not all, which I immediately miss. I guess I'll have to read the docs.
I write mostly in typescript, and being able to run eslint and tsserver is pretty important for my workflow. (I could just use this branch and build it from source though…)
This project looks awesome and as someone who’s used vim/neovim my whole career, I’m very excited for a modern modal editor. If it had an easy motion/sneak/leap/hop sort of thing (there’s an open PR), I’d switch right away. I keep checking on it every few weeks. Can’t wait for that and the plug-in functionality.
Helix supporters often cite the object-action paradigm as preferable to vi's action-object. I find this argument moot: you can work in object-action fashion in vi as well if you remember to begin your sequence with 'v' (possibly at the small cost of an additional keypress in some cases).
If Helix added some kind of compatibility layer for Vim/Neovim plugins (much like Neovim's support for VimScript or the existence of things like Torch.jl in Julia), I'd switch in a heartbeat. As it stands, I simply rely on too much of the Vim/Neovim ecosystem to make the jump.
I found this quote from the page linked by that repo's README about what "structural regexps" are:
“The current UNIX® text processing tools are weakened by the built-in concept of a line. There is a simple notation that can describe the `shape' of files when the typical array-of-lines picture is inadequate. That notation is regular expressions. Using regular expressions to describe the structure in addition to the contents of files has interesting applications, and yields elegant methods for dealing with some problems the current tools handle clumsily. When operations using these expressions are composed, the result is reminiscent of shell pipelines.”
Seems like a rather insightful understanding and ___domain-widening effort when it comes to manipulating programs. I've always wanted something like paredit, but for everything else besides lisps.
It's just notably bad for beginners, and getting worse all the time. I've been in software for over three decades and I haven't seen the obsession this bad since Java, which has apparently come a long way towards UX, and also didn't ever put out new BS every six weeks that I can recall. Rust on the other hand, is an absolute nightmare for beginners. I've spent a lot of time throughout my career working with non-programming-inclined math and *-int people, and I've already seen one outfit crash and burn from trying to deal with it's complexity rather than just using Python/R/Matlab, because "safety" or because "performance" or whatever else somebody lied and told them.
This shouldn't become a Rust-bashing thread, I'm just genuinely curious if there's lesser-known "post-modern" text editors. It's crazy to think how many thousands of days I've accumulated in gedit... For how much we spend our time in editors, it still feels so primitive just typing things in a few bytes at a time and compiling, etc etc. Back in the early 2000s, I thought we were getting close to just Star-Trekking it, but alas. I have to read about whatever the shit a devcontainer is... to edit text...
I’m curious though how as a user of the editor the programming language even matters (beyond how complex it is to compile).
And if you do want to contribute I’m reasonably certain that helix by virtue of how it’s programmed is the easiest to contribute to I have come across.
I see what you mean, I suppose I should have clarified.
I want to dig into one of these editors for a stronger understanding of how they work, and using something as obtuse as Rust is a total nonstarter for me.
I read through the source of micro over a few weekends during the 2020 lockdowns and really enjoyed the experience, though I was woefully underprepared with spending that much time looking at Go, which I wasn't familiar with at the time. Even still, I felt relatively confident within a few hours.
Conversely, I've seen things like: https://fasterthanli.me/articles/a-half-hour-to-learn-rust from Rusties that just made me sick to my stomach. It's just ridiculous how many syntactical elements there are, and how little is done for the end-user by way of ergonomics. To top it off, people who've spend dozens (!!!) of hours with Rust still struggle with it. With Go, Python, maybe C, and others, I can typically bring students or grads up to speed enough to at least have a decent conversation about crucial code within a single workday.
I do think that the Rust ecosystem is a brittle one, despite the grandiose claims of safety and security, in that few people whose time is valuable and whose experience is vast would be spending their time wisely coming up to speed with the language in any scenario, even outside of text editors. The
Again, I'm not starting a Rust-bashing thread, esp not with someone invested in Rust, but that's where I'm coming from.
> I want to dig into one of these editors for a stronger understanding of how they work, and using something as obtuse as Rust is a total nonstarter for me.
I would be absolutely amazed if the language is what makes an editor easy/hard to understand unless that thing is written in whitespace/brainfuck. In this particular case the helix codebase is incredible easy to understand and contribute to, definitely easier than vim, neovim and others _despite_ the fact that it's written in Rust.
My project advances the state of the art, your project publishes updates, his project puts out new BS.[0]
Also, I'd like to know whoever's recommending Rust for _beginners_? Nobody should be doing that. Not even the most hardcore fan I know would push that.
I don't think rust is particularly bad for beginners. It makes subtle bugs harder to write, so the bugs you get tend to be pretty straightforward and easy to diagnose.
There is obviously a bit of upfront investment, but it's comparable to most other languages (less than C++, for example). I have a much easier time writing rust than C, for example, and I'm a very mediocre programmer.
You don't mean to argue that because there are potentially an infinite number of possible editor configurations, that they must all be equally valid, and that there is no objectivity in editor design?
That is just "past discussion", not a dupe. A dupe suggests there's a competing conversation happening right now that may be splintering the discussion.
It's very much a dupe by HN's rules of dupery. It's just that saying 'dupe' went a somewhat out of style since it can come off a little aggro. 'Past discussion' is often just the polite way to point out a dupe.
Helix does everything I need, nothing I don't, and I don't have to learn a bunch of esoteric syntax. It's a great editor for people new to the world of shell editing, and I highly suggest trying it out.