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.
Readit Newsilovecaching commented on JetBrains releases RustRover IDE for Rust development infoworld.com/article/371... · Posted by u/thunderbong
ilovecaching commented on Flatcar: OS Innovation with Systemd-Sysext flatcar.org/blog/2024/04/... · Posted by u/goombacloud
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.
As a longtime C++ user, I'd sooner just upgrade to a better system programming language. C++ is a weird mess.
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.
ilovecaching commented on Go or Rust? Just Listen to the Bots cybernetist.com/2024/04/2... · Posted by u/todsacerdoti
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 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.
That's odd, because neovim is a fork of vim, not a reimplementation. What broke for you?
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 just realised that I'm using Neovim despite there are no nvim-specific plugins in my config (CoC covers most of my needs), and I don't use lua.
Still is feels like Neovim is more stable and faster than the regular Vim somehow. Plus it has much better defaults.
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.
Agreed. Neither VS Code nor VS Codium (my preferred variant, telemetry-free) have ever broken my setup with an update, something I can’t say about NeoVim or Emacs.
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.
The "long game" becomes short if your organisation is out-executed by a competitor who isn't as conservative in approach.
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.
So AI products can only be developed in AI friendly legal areas? Similar to cloning and stem cell research?
I never said anything about AI development.