Or with most language specific extensions disabled by default.
I almost disable all extensions except the ones I use all the time. Then I enable specific ones at workspace level.
Yes, it's annoying. But as an extension author, I know how some badly written extension can significantly slow down the experience, both during startup and editing. I even profiled other people's extensions and submitted feedback.
Load time is in seconds, even with the program cached. I can still load vim with a ton of plugins[0] and still load a project in a few hundred milliseconds.
Maybe VS Code is faster with fewer plugins but it's still "dog slow" to load and run. Only thing I'm "missing" in vim is the bloat
[0] personal I only use a handful but I've played around because why not
With LazyVim (requires NeoVim) and its load-on-demand architecture, startup time usually stays below 50 milliseconds even with a ton of plugins. Below 50ms is fast enough that it feels instant. Aliasing `nvim` to `n` in my ~/.bash_aliases just makes it even faster. cd to a project directory, run `n .` and I'm looking at the NeoVim file explorer plugin for that project directory. No break in thought flow, no standing up to get coffee while the IDE loads, just keep going.
Your focus on startup speed feels really alien to me. When working on a project I just keep vscode open. I reboot maybe once a week and starting vscode again takes about a second, and then maybe 10s of seconds of background processing, depending on the project size, for the language server to become fully operational. That's more than good enough for me.
I've done a lot of shell-driven development in the 00s though, and I remember it did involve frequently firing up vim instances for editing just a single file. I no longer understand the appeal of that approach. Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
> starting vscode again takes about a second, and then maybe 10s of seconds of background processing
Yet I'm doing the same thing instantly or near instantly.
I don't reboot often and I'm still lazy and will leave projects open often, but honestly, have you considered that your workflow is an adaptation to the wait time?
> Navigating between files (using fuzzy search or go-to-definition) is just a lot faster and more convenient.
I agree? But why do you think people don't fuzzy search in vim? Or the terminal? There's been tools to do this for a very long time. Fzf is over a decade old and wasn't the first
If you're using vim as an IDE (which is if course perfectly doable), then why does it matter if startup time is 50 or 1000 ms. You typically leave them running.
> Yet I'm doing the same thing instantly or near instantly.
Does vim somehow allow LSP servers to index faster? Or are you not actually doing the same thing?
Why are you leaving them running? Because they are slow to load?
Yes, Neovim supports LSP and it is very very fast.
I'm not sure why any of this is surprising. We're talking about the same company who is speeding up their file browser by loading it at boot time rather than actually trying to fix the actual fucking problems. Why is it surprising that everything else they make is slow and bloated as shit (even more as they've shoving AI into everything)
The point of LSP is that neovim is using the same servers for this as vscode. So I guess you work on smaller projects or with languages that have faster (usually meaning less fully featured) LSP servers.
LazyVim includes a bunch of pre-configured plugins that turn NeoVim into an IDE. Fuzzy search by filename, search by text, file explorer, go to definition, go to reference... Even debugging and unit test runners, it's all there. Yet when I'm at the command line and I need to make a quick edit to one file, e.g. `nvim ~/.bashrc`, I don't pay the startup cost of waiting for 50 plugins I'm not going to use. So it's the best of both worlds.
>>Load time is in seconds, even with the program cached.
Are you like, for real? How often do you load it up for it to matter in the slightest? Do you not just open the project once at the start of the day and then continue working?
Sorry but for someone used to working in VS proper and projects which take minimum 40 minutes to build, saying that a startup time of a few seconds is a problem is.....just hard to understand.
I live in the terminal and opening files with vim is the primary way I interact with them.
> Do you not just open the project once at the start of the day and then continue working?
I mean I do this too
> projects which take minimum 40 minutes to build
This sounds problematic and a whole different category of problems.
Don't you have partial compiles? Parallel compiling? Upgrade your machine?
But it's not just startup time. I use less RAM, less CPU resources, jumping through tags is instant, working through the debugger is instant, opening new files is instant, fuzzy searching my system is instant. It sounds like the program you're working on and your editor are fighting for resources and I've never faced that problem with vim
>>Don't you have partial compiles? Parallel compiling?
We do. Without it it it takes over 3 hours for a full project build. Normally if I change one line of code and hit "run" it takes ~10-15 minutes for the app to start, depending on which file I changed.
>>Upgrade your machine?
It's a 64 core/128 thread core Threadripper workstation with 256GB of ram, so not many upgrade options from that.
It's a huge C++ project, heavily templated, that's kinda normal. My previous 2 projects were also like this.
Lol this isn't unique nor out of the norm - most big C++ projects are like this, and certainly every one in my industry(video games), unless you're trying to make an argument that C++ is somehow not commonly used. I even worked on a small indie game in C++ and it took 5 minutes minimum to compile.
C++ is common, but game programming definitely isn't the norm.
And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I've also worked on systems which are entirely written with template metaprogramming. This is definitely not the norm. Though that code was highly focused on optimization, as we were writing for HPC environments (extremely heterogeneous hardware). Sure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane. A partial compile of a few minutes usually meant my time was better spent mucking about with the cmake and build files because incremental testing sped up development and your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
>>C++ is common, but game programming definitely isn't the norm.
I mean, last time I checked there are hundreds of thousands of programmers working in this industry, and video games are a bigger industry than movies. What's not the norm about it, exactly? I imagine there's more programmers out there making video games than making accounting software, for example.
>>And 5 min is very different from 40 mins. Don't pretend a factor of 8 isn't insignificant
I'm sorry, I'm confused. Did I ever imply otherwise? Maybe let me say it again, clearer - so far I worked at 2 big AAA studios, on 5 big AAA franchises, in 4 different engines. All 5 of those had those multi-hour compilation times unless you used something like Incredibuild or Fastbuild, and every single one of them had a startup of around 10+ minutes if you made any change to the code at all, just for VS to finish compilation and linking. I also worked at a small indie studio, with its own C++ engine, we had maybe...200 files max? That project took 5 minutes to build. Don't know where you got the idea that I'm saying factor of 8 is insignificant.
>> your PRs aren't going to be merged quickly if they take an hour to verify if they even compile.
Hmm at the current project the time from me submitting a change to it actually being accepted is ~6 hours. On my previous projects I think the fastest I've seen has been around an hour for a very very quick preflight. But then all the tests also have to pass which takes a lot of time.
>>ure, a full compile could take quite some time but doing a full compile, or even compiling a decent portion, when developing would be insane.
Right, but you have to do this at least once when you get latest, normally in the morning I grab latest and have to build around ~9000 files. If I make a change in the gameplay code it might have to recompile ~200-300 files because of the dependencies on all the associated systems.
> I don't use it because it's so dog slow.
You might find it runs better with fewer plugins.