That is a valid point of view. For me, however, I have found a huge productivity boost being able to stay in Neovim for extended periods of time. That's not to say that my way is the only right way, but the more I'm able to accomplish in Neovim, the less friction I personally experience.
On k8s/devops tooling: I'm building tuis.nvim [1] — Docker and Kubernetes management as Neovim buffer TUIs, built on morph.nvim [2], a react-like UI framework for Neovim. Stay in the editor (if you already use Neovim, of course) instead of switching to k9s, works over SSH, same Vim keybindings you already use. Also has plugins for Bitwarden, process management, and file exploration.
I've been working on exactly this with morph.nvim [1] — a React-like component model (h(), component lifecycle, reconciliation, extmark-based styling) for building declarative TUIs. It uses Neovim as a base, which might seem like an odd choice, but Neovim gives a lot out of the box that most TUI frameworks don't: syntax highlighting, extmark tracking (i.e., editable regions that feed back into the component state — type in a filter and the UI re-renders around it), and navigation that Vim users already know without learning yet another keybinding layer. Built on top, tuis.nvim [2] ships real plugins — Docker, K8s, Bitwarden, process manager — all as native Neovim buffer TUIs. No Electron, no separate app window, runs over SSH.
So far, it's just a flash-banner on their `/code` page. I don't see any announcement other than folks mentioning that they are getting email announcements about its release.
Tommy Emmanuel apparently learned by transrcibing, famously thinking that both the bass line and guitar lines he was hearing were a singular "guitar part". Just by having his expectations (incorrectly) raised, he rose to the occasion and played both parts.
I forget where I heard this story -- it's probably either rather famous, or buried in an interview somewhere.
As others have said, the fact that they're letting the ecosystem settle before including something out-of-the box is beneficial in some sense. It's allowed time for experiments (including my own "how would I do UI in Neovim: morph.nvim [1]").
For some, this stage of a project attracts tinkerers and builders, and lets the community shape how things are done in the future. It's not always practical, but it does have a certain appeal.
Right? That's the only reason that "coding with LLMs" works at all (believe me, all at the same time, I am wowed by LLMs, and carry a healthy level of skepticism with respect to their ability as well). You can prompt all you want, let an Agent spin in a Ralph loop, or whatever, but at the end of the day, what you're checking into Git is not the prompts, but the formalized, codified artifact that is the bi-product of all of that process.
We have been rewatching Clone Wars as a family, and I, for one, find this terminology hilarious given the use of it in the series towards the separatist droids.
I don't buy this. I've long wondered if the larger models, while exhibiting more useful knowledge, are not more wasteful as we greedily explore the frontier of "bigger is getting us better results, make it bigger". Qwen3-Coder-Next seems to be a point for that thought: we need to spend some time exploring what smaller models are capable of.
Perhaps I'm grossly wrong -- I guess time will tell.
Between GLM-4.7-Flash and this announcement, THIS is what I'm excited to see in this space: pushing the capabilities of _small_ models further and further. It really feels like we're breaking into a space where models that can run on hardware that I actually own is getting better and better, and that has me excited.
Just going to jump in here and say that there's another reason I might want Rust with a Garbage Collector: The language/type-system/LSP is really nice to work with. There have indeed been times that I really miss having enums + traits, but DON'T miss the borrow checker.
To be clear, I don't try to Nix-everything. I just use it to 1) install a bunch of CLI tools to my nix-env, and 2) dev-shells. That's pretty much it, though. Even that is a huge boon. Even so, I'm keeping an eye on mise, for sure.
I'm actually trying to work on a video-series to do just this. I've made my own rudimentary plugins reproducing several popular ones, and would like to walk through how I made: a) file-tree b) picker/fzf replacment c) hop/leap replacement d) surround plugin e) code-formatter f) hydra (sub-modes) g) many "UI" (interactive) buffers, etc.
None of these are published because the popular ones are better and provide more functionality, but I want to share what I believe is more valuable: what I learned while writing them.