ilovecaching

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.

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 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.

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'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.

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.

I never said anything about AI development.

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.

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.

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.

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.

Complexity is where bugs hide. Do you really think Rust protects you from every class of bugs? It doesn't even protect you from all memory bugs.