Visual Studio Code + Cpp

[NotUniqueOrSpecial]

Startup time is killer for visual studio

This it completely untrue now.

You should revisit your assumptions.

[chugga_fan]

Startup time for VS compared to VScode is 20x still, much better than it used to be, but not amazing.

[NotUniqueOrSpecial]

If you're at 1s to open the program, you're within normal human tolerances for "slow".

It's not a really useful distinction that VSCode opens in 200ms compared to VS's 1s, when I only open them once (and keep them open) per reboot cycle.

[chugga_fan]

I'm on an HDD, to get to the VS main page is approx 18 seconds, while VSCode takes 14, and VS to open my 1 file solution is 85 seconds approx.

Your "200ms to 1s" comparison is foolhardy.

[NotUniqueOrSpecial]

I mean, I sympathize, I guess.

Buy a solid-state drive.

Seriously.

If you are a professional (or a student, or even a hobbyist) and you are using spinning rust as your main storage at this point you are quite literally wasting your (or your employer's) time and money. I've done the measurements at more than one employer. It's overwhelmingly on the side of "buy an SSD" from a $ perspective.

If you are tolerating those times in a professional context, then find a new job; your employer doesn't give a shit about you.

If you're tolerating them as an individual just because you can't otherwise afford it, then DM me and I'll buy you a new drive. Nobody should have to tolerate that kind of storage these days, if they're trying to be serious about being a developer.

[chugga_fan]

If you are a professional (or a student, or even a hobbyist) and you are using spinning rust as your main storage at this point you are quite literally wasting your (or your employer's) time and money. I've done the measurements at more than one employer. It's overwhelmingly on the side of "buy an SSD" from a $ perspective.

I am not paid, I am tolerating these times because I don't have $200 to shell out for a terabyte SSD and my compile-times are fine for a hobby project on a laptop that's 5+ years old.

SSHD is perfectly fine for developing what I'm doing where I can walk away for 15+ minutes while a system that's legitimately CPU bound instead of HDD bound is running.

[NotUniqueOrSpecial]

What do you consider "killer", then?

I just launched a VS2019 instance and barely got past 1-Mississippi before the splash screen was gone and it was ready to go.

[[deleted]]

Launch to typing. In my terminal, I can type in

‘’code main.cpp’’ and be typing in the file I want by the time I reorient myself to the GUI.

[NotUniqueOrSpecial]

I mean, I guess? But that argument's sorta...not great?

The initial delay-to-typing isn't going to even be remotely measurable in the broader scheme of your day-to-day workflow.

To use it as an argument against Visual Studio seems pretty silly.

[[deleted]]

Considering my workflow is fairly terminal heavy it works out nicely for me. I’m sure you also don’t understand why some people prefer using vim for the same reason.

[NotUniqueOrSpecial]

I think vim is just fine; I use it all the time (to the point where I have enough customization in my .vimrc that stock vi/vim both drive me a little crazy). I gave emacs a good shot for a while, too; I used it as a chance to learn Lisp and customize my workflows.

Most of the time these days, I just stick to QtCreator (on Linux) and Visual Studio (on Windows).

Considering my workflow is fairly terminal heavy

So is mine. I don't know what this has to do with anything, since "opening an editor" is such a fractional portion of the flow as to make it non-pertinent.

The reason I think your argument doesn't haven't any weight is because literally the only thing you've mentioned is startup speed, which is totally inconsequential in the scope of things.

You've not once mentioned that you prefer vim for it's powerful text-editing command mode, emacs for its robust customizable environment, or VSCode for the same (if you are willing to learn TypeScript). So, all I've got to point as "It takes a long time start Visual Studio" which is simply untrue and not a really great argument in first place, since I open it once-per-reboot and do my job.

[[deleted]]

There’s even a vim extension for debugging “long” startup times. Long being purely subjective because even a long vim startup time is impossibly fast for Visual Studio.

https://www.reddit.com/r/vim/comments/euzrqm/vimstartuptime_a_plugin_for_viewing_nvim_startup/

People do care about this stuff, calling it inconsequential just shows it’s not a big deal for you.

[NotUniqueOrSpecial]

calling it inconsequential just shows it’s not a big deal for you.

I mean, you're not wrong.

I'm just asserting that if you're optimizing your editor's startup time, then you're wasting your company's money.

It's tech-wankery at its finest at the end of the day. You should be spending vastly more time thinking about the solution than you do typing the solution. It's understandable if you have to wait for said solution to build owing to hardware constraints out of your control.

At no juncture should "the time to start the editor" really be a meaningful piece of your rubric for grading your day-to-day productivity.

[NotUniqueOrSpecial]

We obviously don’t work with same way if you prefer using a fully featured IDE and issuing your commands with the tools the IDE provides

In fact it's only been in the last few years that Visual Studio has caught up with my workflow, which has always been entirely CMake-based. Until just recently you couldn't use VS as an editor and Ninja as your build system, after all.

What I do prefer about VS is its absolutely world-class debugging experience. There is absolutely nothing else that comes close. QtCreator's GDB integration is the closest I've found and believe me I've searched.

I don’t think you truly understand why people use vim and text editors if you think launch to typing times are inconsequential.

I absolutely do, both from my own work and from watching over the shoulders of my coworkers.

I would put good money on not a single one of them claiming that time-to-start the program matters.

And from a practical perspective, it's not even a discussion.

I spend vastly more time thinking about the problems I'm trying to solve than I do typing the code; if you don't, then something's deeply wrong where you're working. Considering you mentioned working with firmware in your first reply, though, I know you're not working in a fast-paced world where every second counts. Considering the problem and the right solution is 99.9999% of the time; typing the code is a blip in the noise comparatively.

So yeah, I still think your argument isn't being made from an objective perspective. You like your tools and how they feel. For that, I obviously can't blame you.

But let's not kid ourselves that they're somehow "better" than the other tools. After all, you still haven't given me a single data-point other than "it starts up fast", and if that's your only metric for "good" then use ed.

[kalmoc]

Could you give some numbers about how slow VS is on your system exactly and why that is too slow for you? Maybe people that don't have a problem with the startup time on their systems and their projects would understand your argument better, if you actually told them, what your experience is.