Of course we should use whatever best fits our needs as developers, but I do find the resistance to configuration slightly odd in something like an editor. In all likelihood, it’s where you spend a huge amount of your day - tuning it to your needs seems like a wise investment of time (so long as you know when to stop - on Emacs it was never quite right, with Neovim I have a setup I now rarely touch).
With neovim (at least from the last time I used it) I feel the amount of configuration required is higher than it should be. Like you need plugins for the completion UI, then nvim-lspconfig to get the LSP configurations and so on. Having to think about for example whether I should use nvim-cmp or the new blink plugin for completion popups seems too much work.
In Helix for example you can get a decent base by just having gopls in PATH and then opening a file in a go project.
It is a bit hypocritical for me to say this because I use emacs most of the time but I can understand where people are coming from when they say this.
I’m honestly a bit struck by how many of the current wave of text editors are basically just “vim, but with these plugins/config options by default” when you get right down to it.
As someone who’s been using Emacs for nearly a quarter-century I don’t know whether to feel smug or to ask the vim folks if they’re OK over there.
Sure, I can definitely see the argument for where to set the bar on what is pre-configured. With Neovim specifically I suppose using a preconfigured distro is a potential solution to that, giving that experience to people who desire it while leaving the core there for the tinkerers.
I’ve had the same experience with neovim (I’m an Emacs user, but like having something in the terminal, I used micro for this earlier)
I just gave up on configuring the built-in lsp and used lazy.nvim which gave me everything I wanted.
EDIT: as for Emacs, I don’t think it’s hypocritical, because everything is built-in: treesitter for syntax highlighting, eglot for LSP, and use-package for package management
With lazyvim my neovim config is roughly 90% there. The only things I have to add are selecting which languages I want from the list it gives you and picking my colorscheme. It even “upgraded” (I don’t know what the differences are, but I trust the lazyvim maintainers) to blink over cmp.
I feel like there’s been some pushback against this in recent times, in the Ruby community at least. I’ve upgraded a number of old Rails applications and almost without exception the pain point is the gems. How many are abandoned or have umpteen breaking changes.
Introducing a dependency into your project is introducing (often a large amount of) code you are unlikely to have vetted properly, often adding a larger attack surface among other issues.
I’m lucky enough that the teams I’ve worked on mostly understand this, and I’ve encouraged before the addition of a dependency to require a full-team discussion.
Literally this week upgrading an old Ruby project that had ONE dependency and the source of all of the trouble is the single dependency. Which, honestly, could be factored out!
I think like with anything there are trade-offs with adding/not adding dependencies, and almost always are situational.
I’ve encouraged before the addition of a dependency to require a full-team discussion.
For us, this is a thing that usually gets caught in reviews and the reviewee has to justify “do we really need this? if so, why?”
Of course we should use whatever best fits our needs as developers, but I do find the resistance to configuration slightly odd in something like an editor. In all likelihood, it’s where you spend a huge amount of your day - tuning it to your needs seems like a wise investment of time (so long as you know when to stop - on Emacs it was never quite right, with Neovim I have a setup I now rarely touch).
With neovim (at least from the last time I used it) I feel the amount of configuration required is higher than it should be. Like you need plugins for the completion UI, then nvim-lspconfig to get the LSP configurations and so on. Having to think about for example whether I should use nvim-cmp or the new blink plugin for completion popups seems too much work.
In Helix for example you can get a decent base by just having gopls in PATH and then opening a file in a go project.
It is a bit hypocritical for me to say this because I use emacs most of the time but I can understand where people are coming from when they say this.
I’m honestly a bit struck by how many of the current wave of text editors are basically just “vim, but with these plugins/config options by default” when you get right down to it.
As someone who’s been using Emacs for nearly a quarter-century I don’t know whether to feel smug or to ask the vim folks if they’re OK over there.
Sure, I can definitely see the argument for where to set the bar on what is pre-configured. With Neovim specifically I suppose using a preconfigured distro is a potential solution to that, giving that experience to people who desire it while leaving the core there for the tinkerers.
I’ve had the same experience with neovim (I’m an Emacs user, but like having something in the terminal, I used micro for this earlier)
I just gave up on configuring the built-in lsp and used lazy.nvim which gave me everything I wanted.
EDIT: as for Emacs, I don’t think it’s hypocritical, because everything is built-in: treesitter for syntax highlighting, eglot for LSP, and use-package for package management
With lazyvim my neovim config is roughly 90% there. The only things I have to add are selecting which languages I want from the list it gives you and picking my colorscheme. It even “upgraded” (I don’t know what the differences are, but I trust the lazyvim maintainers) to blink over cmp.
I feel like there’s been some pushback against this in recent times, in the Ruby community at least. I’ve upgraded a number of old Rails applications and almost without exception the pain point is the gems. How many are abandoned or have umpteen breaking changes.
Introducing a dependency into your project is introducing (often a large amount of) code you are unlikely to have vetted properly, often adding a larger attack surface among other issues.
I’m lucky enough that the teams I’ve worked on mostly understand this, and I’ve encouraged before the addition of a dependency to require a full-team discussion.
Literally this week upgrading an old Ruby project that had ONE dependency and the source of all of the trouble is the single dependency. Which, honestly, could be factored out!
I think like with anything there are trade-offs with adding/not adding dependencies, and almost always are situational.
For us, this is a thing that usually gets caught in reviews and the reviewee has to justify “do we really need this? if so, why?”