Reminder that neovim is completely free, you can modify the editor using Lua, it has a renaissance of new awesome plugins, LSP support for the official Rust LSP server, and as a system developer you can run it on a target device or quickly switch between a serial console and your editor using tmux. Plus, you can easily add new LLM integrations or wrap tools in about a half an hour of hacking. My neovim setup is easily 10x more productive than RustRover.
My NeoVim broke so often I came to realize a product that has 50 random people working on the core and various plugins is not going to make a stable product that would work for years.
After all, there is no consistent testing as a whole product but it's a combination of "works for me" and after some months of originally setting the editor up, things start to break apart saying something is deprecated, something is incompatible with something else and it will start asking for newer NeoVim version which the distro obviously can't keep up with. It's like you're using a nightly build of a product or worse if things can't be fixed.
Maybe someone could snapshot a stable state of NeoVim + some popular plugins and release as some sort of LTS and things might change but currently you'll need to spend time fixing frequently than use it for what you need it for.
Are you using a neovim distro? I think the broken things only applies for automated setups. I use Vim instead of neovim, but my plugins set is pretty minimal. Most of my config is Vim-related, then a couple of options for the plugins. I instead use the terminal for most stuff.
> Maybe someone could snapshot a stable state of NeoVim + some popular plugins and release as some sort of LTS
Vim Plug (and maybe other plugins managers) can handle tags, branches, and commits references for versioning.
It’s all fucked ime even with nixos from the pov of “just working.” Yes, it’s fun and cool and impressive if you get things all setup and dialed in. But if you care about just dropping in and not spending tons of time configuring your tools, imo JetBrains is just the way to go.
As a pragmatic programmer, one of the rules is Know thy tools. You don't really drop in. You learn the tools, and adapt them. The first commit of my dotfiles is more than 3 years ago. And I think the actual files are older. And that was me starting from scratch after years of Linux.
Even with JetBrains IDEs, I usually spend an hour configuring stuff (never bothered to save the config, as I seldom use them). I tune my setup as I go. If I'm spending hours everyday with a software, I want it suited to my workflows.
> As a pragmatic programmer, one of the rules is Know thy tools.
Dunno what you’re trying to say with respect to the broader conversation (though I don’t take issue with any of your points, really).
When I say IntelliJ “just works” I hope it’s obvious I’m not just using it as a text editor ;). On the contrary, it is an incredibly powerful tool (I just remembered I forgot to mention shelving — yet another wonderful feature).
Because I’ve spent countless hours with it, I mean it “just works” for doing incredibly sophisticated things that VSCode and nvim hardly approach (let alone with consistency between languages supported by Jetbrains) without an insane amount of time configuring ime.
Yea, you can get good at the configuring, say, with nvim; and it can be fascinating. I am a tools guy. But again, if I want to create X today, futzing with getting the perfect bespoke nvim environment is simply not to my taste.
My point isn’t that my taste is “better”, but more an attempt to say “just use nvim” is not preferable for many folks in many situations.
I agree with you. I’m not a purist pushing “Unix as a IDE”. I reach to Intellij, Android Studio, and Xcode when the needs arise. I’m saying that a lot of people got confused and try to replicate vs code in neovim, lending to a fragile setup. The correct approach is ground up, maybe taking inspiration from others configs. But everything in your config should be understood.
The same applies to all the tools you use, may it be Intellij, or your shell.
People can spend hours to initially set their environment up but the original post was about having it broken after a period of usage which involves spending unnecessary amount of time fixing than do what they want to do.
And that's a solved problem. First by not having a fragile setup, then doing backups to have some kind of rollback solutions. An IDE strong point is their cohesion and product support. But it's not magic and things can go haywire. It's like people coding with C or using Arch Linux vs using Java or Debian. The latter are stabler, but they're not silver bullets.
The bottleneck in programming is often how fast you can think, not how fast you can type or use auto completion, and definitely not some shortcuts. They cut down time but are not magic. Not to mention that different IDEs often have the same features, you just need to find them.
Folks shilling for the nvim cult completely baffle me. YES it’s cool and impressive, but it also means essentially spending hours and hours of time managing your configuration if you want anything remotely close ime to RustRover or any other JetBrains product.
Spending that time can be interesting, but personally, frankly, I’d rather be writing code than fucking around with lua wrappers for vimscript.
Let’s be honest about this stuff and stop putting down an incredible firm that makes incredible tools.
I think it's analogous to zsh/fish, either you think that customizing is fun and you want to spend time doing it, or you want a nice set of features enabled by default and a minimal config footprint. Can't have both.
You can have both, it's called "good defaults", then you don't need to customize anything if you don't like customizing. But you can.
Also, helix doesn't have minimal config, it has dozens of various options even before potentially hundreds of keybindings, so you can get buried there "for fun" just like in vim
Anyone claiming bullshit like 10x difference has absolutely no basis in reality. Hell, there wouldn’t be an order of magnitude difference between your best setup vs literally touch typing on a foreign keyboard layout.
Also, neovim is just a text/code editor, not an IDE even with plugins.
Long term I think bootc containers will win the war. It has better backing and the weight of Podman behind it. Sysext will likely play a role, but I think flatcar is a losing horse.
The grass is always greener. Rust also has rough edges and there's maybe a fraction of a fraction of a percent of Rust code out there to work on in the corpus of systems software, and a lot of it has to interface with C anyway. Even crates in Rust are overly complicated and they've set up a system that allows people to squat on well known names.
I think if you want to work on systems software you should enjoy working with legacy cruft, otherwise you're just going to be miserable. I mean it's everywhere from the language, to the POSIX APIs, to device drivers, to hardware quirks... C++ is only a quarter of the problem.
I primary write Rust/C for a living, but I would pick Go in any situation if I could. I understand Rust's appeal as a shiny spaceship, but it adds a lot of complication for not enough benefit if you can use a garbage collector. Why deal with boxing, lifetime annotations, and async when you could just write plain Go.
Go is easier for onboarding, it's fixed the major issues people have had with it - it has modules, it has generics. It's easy to package a binary versus deal with having a Python venv.
Go is just the best common denominator and that's what the majority of people need. I really feel that people want to use Rust because it's interesting and fun, not because it's really the better tool for the job. The vast majority of applications can use GC and are not resource constrained by Go's runtime or binary size.
I've successfully used ChatGPT and Gemini to 1:1 translate a pretty much all of my Python programs from the last 20 years (scripts really) to Go and couldn't be happier.
Instead of figuring out what's the package manager/virtual env wrangler du jour when installing my stuff to a new server after 2+ years of not touching it (Poetry is the current leader I think?) I can just compile the Go program with the correct arch on my local computer and scp it to the server.
And forks diverge... in the case of neovim by tens of thousands of LoC. In what way is forking a stable product a guarantee that the fork will remain stable?
I use default vim, I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim. I have also not found any neovim functionality that sells neovim over vim. Vim is fast enough that I have never even thought about it's speed. With term, termdebug, fzf, ripgrep, and ALE with LSPs and Vim's excellent built in support for auto-completion, tag browsing, and cscope, there's really nothing I can't do in another editor I can't do faster in vim and as a bonus I find that I know more about regular expressions than most IDE programmers.
>I believe it was a mistake to fracture the ecosystem with plugins that can only be used with neovim.
I hate to break this to you, but Vim itself is in the process of converting its runtime files into Vim9script (which is Vim specific), and many new Vim plugins are also being written in Vim9script.
Neovim has always supported "traditional" Vimscript, and has ported all runtime file changes from Vim (think filetype plugins, syntax highlighting, etc.). In fact, we explicitly request that any runtime file changes first go through Vim precisely because we want to keep the two projects aligned. But the more that Vim transitions to Vim9script, the less can be shared between the two projects. So unfortunately the "fracturing of the ecosystem" is not specific to Neovim.
I don't think the onus is on the original project to maintain compatibility with a fork. Neovim made it pretty clear from the beginning that they were going to fracture the ecosystem and now we have colorschemes in Lua that can't be used in vim... say what you will about Emacs, but at least all of their distros can run the same code.
From my perspective as a vim user, neovim has only made my life worse by splitting plugin authors into two camps without any real benefit over what we had in vim. The only good thing about neovim is it caused some nice features to be added to vim, which the neovim authors could have just contributed themselves without trying to fight for control of the ecosystem with Bram. Neovim has really just made things worse for everyone.
Probably me but I definitely sense biases in your replies.
Vim ecosystem is 'controlled' by the community not Bram. If Neovim/Lua is not good enough there wouldn't be a fracture in the first place.
The fact that Bram saw the success of Lua with Neovim but insisted on inventing Vim9Script speaks for itself. Yet you somehow manage to blame everything on Neovim.
I never looked at neovim until Vim9Script. Such a strange choice to invent and maintain a language when that energy can be put to fixing bugs or adding features. He's done amazing work maintaining vim for so long but I don't enjoy the not-invented-here mentality. It adds unnecessary complexity and potential security issues to the codebase with no real benefit.
It's his project he can do whatever he wants, but I'm planning on using this tool for the rest of my career so I went with the fork. Moving my config to XDG_CONFIG_HOME was a welcome side-effect.
I've had one vanilla vim breakage in over a decade of use. A common pattern I see that inhibits vim usage is:
- Using too many plugins without understanding all that vim has to offer.
- Cargo culting configs instead of building up little by little.
- Trying too hard to rice vim in appearance without adding meaningful utility.
The same applies for Emacs. Vim and emacs are powerful editors not controlled by corporations, have succeeded for decades when other editors have floundered, can run in any basic computing environment/terminal, and are logically present in many Unix tools. Like all of software engineering, a deeper understanding of the system you're using pays huge dividends in the long run.
In short, take the time to learn one of these editors in it's basic form and then nurture a small config that can go a long way, and you will find success.
Just want to say that I'm not going to touch any AI tools until the legalities are ironed out, and I absolutely won't be using it at work without very clear approval. AI poses a huge risk to businesses as programmers start feeding code into other companies backends without thinking and pulling out random snippets from projects with varying licenses.
Being cautious in order to keep one's IP and job safe during an economic downturn isn't shortsighted, it's playing the long game. AI isn't going anywhere, and waiting and seeing how the legalities shake out and how companies will want to consume this internally is the smart play.
Jumping onto a new technology with unknown risks and getting burned is shortsighted.
Then I get home and think: how come we're collectively killing the biome that sustains us and degrading its ability to nurture human civilization? Then I remember I need to race to the bottom with everyone else to get that cash son!
I'm not sure what company you're working for where generating code that may or may not be correct and needs careful analysis is somehow increasing your coding velocity to the point where it's trumping higher level thinking or protecting your IP or not getting into expensive lawsuits. I would like to hear more.
It's not about generating code which may or may not be correct. It's about being free to use a new wave of tools which allows engineers to try many approaches and analyse results at warp speed. The engineers (and organisations) which can capture this velocity will have a huge advantage over those who do not.
I understand that it would be nice for the industry to behave within the law when it comes to IP and copyright. But historically, that isn't the case. Google v Oracle re: Java. Zenimax V Occulus. Samsung v Apple. Microsoft v Motorola. Companies will happily look the other way when it comes to IP if it means capturing more of the market.
He's just saying he won't share the codebase owned by the company he works for on a 3rd party platform without explicit approval from whomever owns it, and he won't just willy-nilly copy-paste snippets from the AI onto said codebase without properly vetting them.
He didn't say anything about ignoring AI. Pretty reasonable if you ask me.
Wise decision as far as I'm concerned. Unfettered AI experiments on production systems are an IP and (depending on your field) regulatory nightmare waiting to happen. Unless you have lawyer-vetted guidelines and oversight, use OpenAI products exclusively for experiments and personal projects.
This is why I stick to a terminal based editor. You can use it practically anywhere with minimal resource usage. You can use it remotely so any machine is your workstation. You can use it on a machine without a GUI at all.
With the new AI plugins I doubt even Jet Brains will be able to offer much over what Vim and Emacs can provide with fugitive, magit, fzf, etc. providing best in class features while still running on actual terminals.
As regards both AI plugins as you mention, and “Emacs anywhere”, I compiled a list of Emacs ChatGPT plugins[0] along with each having an easy issue/tasks for others to help linked below, and on the next installment of this newsletter I’m planning to feature among more AI plugins things like controlling Firefox from within Emacs (if I can reach that plug-in’s author to get permission to feature.)
I have state-of-the-art gear and I mostly do everything in the terminal. Why? Because I run months long sessions in tmux that I attach to from all sorts of places and machines, including whatever notebook my youngest left around or from my phone (via Terminus) to quickly check on something.
Being able to resume exactly where I left off is more important to me than fancy colors and fonts (and the mouse to too slow and imprecise anyway).
I think there is no problem using an editor like VisualCode or Notepad++. But you should have an editor like Emacs or in my case VI at hand. It is a lethal weapon to solve any problem in inhospitable environments where speed and power are required. I want to believe that VI or Emacs is like that gun that James Bond or Jim West has up his sleeve, and at the push of a button it deploys to your hand in case of emergency. Subtle, fast, and effective in emergencies.
yes, so true. as an avid Emacs user, still, I love vi for being available everywhere and impressing people on production machines to adjust config files. somehow the muscle memory of my teenage years is still there. a weapon for a more noble age.
The Makefile one is important. Make is still the best tool for managing a dependency graph, adding project commands, building artifacts of any kind, whether it be building docker images, binary objects, or spinning up integration environments. You can use make anywhere and everywhere, it's powerful but it's also simple on the surface and battle tested.
For DevOps in general I have learned to KISS, always know how your tools work, and focus on observability and low hanging automation. If you can't observe or understand how your systems works, you're screwed. You need metrics, logs, statistics, in one place that you can easily build queries with. You should be able to see everything at the fleet level down to the innards of each machine with no troubles.
