FWIW, I actually agree with everything you said about linux as a dev environment vs windows. But that wasn't the question... as an IDE and debugger integration, there is absolutely no comparison to VisualD, not by miles.

It would be really cool if parts from VisualD were more suitable for VSCode, but I can't see that being easy or practical.
One is the Concorde integration, which is pretty deep, and GDB is just not even remotely as good, and the vscode debug UX is embarrassing by contrast.
Then the general autocomplete engine, which is fairly dependent on the detail expressed in the project files. While vcxproj files are very shit to write, it's much easier on the tooling than trying to extract sufficient build config from make.
Nobody writes VS project files, you generate them, just the same as makefiles... nobody writes makefiles.


On Thu, Jul 9, 2020 at 6:45 PM Petar via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
On Thursday, 9 July 2020 at 00:03:02 UTC, Manu wrote:
>
> Not really. VisualD is objectively the most functional and
> competent
> IDE/Debugger solution, BY FAR.
> It's not an opinion, it's a measurable fact.
>
> Obviously, if you are into vim/emacs/whatever, then you don't
> actually
> really care much about IDE support and debugging, and in that
> case, this
> question is not relevant to you.
> I agree that Code-D + VSCode is probably the second best
> solution, but
> there's really no comparison; the debugger is a kind of
> funny/sad joke, the
> D debug experience is poorly integrated, and the
> intellisense/autocomplete
> is nowhere near the same standard. There's no competition.
>
> Code-D is great work, but it's still catching up, and it may
> never do so because VSCode just has an embarrassingly bad
> debugger :(

Professionally, I've used Visual Studio for the first 3-4 years
of my career. Back then the company I worked for was a MSFT
partner, so we all had the Professional or Ultimate edition that
had all the bells and whistles. I agree that VS has probably the
best debugger, though I'd actually say that the debugging
experience is much better with C# than C++. Debugging C++ (with
/Od and with or without /Zo) feels wanky compared C# which has
always been rock-solid.

However, I've since moved to Linux and I couldn't be happier. I
haven't had to fire up Windows for the past 1-2 years. On my work
machine, I neither have a dual boot, nor even a Windows VM, just
Linux. Windows really sucks as a dev environment. And I'm telling
this as someone who would for years be one of the first among my
colleagues and friends to install the latest Windows, VS, MSVC,
.NET FX /.NET Core preview builds, Chocolatey, vcpkg, WSL,
Windows Terminal, Cygwin, Msys, Msys2 and so on.
The only salvation I see is WSL2, but still, it's overall a
pretty bad dev UX. No matter how much effort is put in a GUI IDE,
nothing beets Unix as an IDE and especially modern distros, such
as NixOS (my daily driver). Yes, it takes much more effort for
beginners than VS, but it's all worth it.

Coming back to VS Code, for what I do on my daily job it's really
destroying the "real" VS:
* It's cross-platform, so I can take my dev environment on
whichever OS I work.
* You don't need to create a "project file" to effectively work
on a project
* On Windows, admin user is not necessary to install & update.
This makes the update process unnoticeable, where VS, before
their new modular installer was unbearably slow (1h min).
* Start time is much better. Additionally, in many cases, you
don't need to restart when you install/uninstall an extension -
this make's it much easier to test extensions for 1-2 mins and
then throw them away.
* The extensions integrate much better - in many cases it takes <
10 secs to install something, while with VS it takes at least
1min in my experience, sometimes even several minutes, depending
on the size of the extension.
* VS Code integrates much better with the system - on Windows you
just right-click to open a folder or file and it's opened in less
then 1-3secs. In the terminal you just type `code <path>` and
it's done. I know this works already with full VS and I have used
it, but its much slower startup time defeats this workflow.
* For beginners (which don't know vim), VS Code is actually not a
bad choice as the default git editor (it's just `git config
--global core.editor "code --wait"`) (e.g. for interactive
rebase, writing commit messages, git add -p edit, and so on)
* Given that I spend at least at 30-70% of my time in the
terminal, VS Code's integrated terminal is much better than
whatever VS has had when I tried it over the years. I'd like the
perf to be better with vim and git diff, but it's very workable.
* vscodevim still has much to be desired, but it's miles ahead
then the alternative extensions for the full VS
* The editor as a whole is much *easier* to customize and I feel
that in the past 1-2 years it has started to be *more*
customizable compared to VS
* Extensions like Remote development for containers and SSH are
live savers. I couldn't live without them (if I have to use a GUI
editor / IDE).
* The overall language support is much better. VS does a couple
of languages really well, but VSCode has a much richer extensions
gallery and supports many more languages.
* Of course, I'm biased, since I haven't had to use a debugger in
the past several months, but these days I'd always pick an editor
with a much better extensibility story because many of the things
I need daily I haven't found alternatives for in VS.

----

Rainer, the work you have done with VisualD is astounding! I have
always been extremely impressed by the progress you have been
making over the years!

(Of course, not a high priority by any means, but) it would be
great to have VisualD's engine for VS Code! I know that a large
part of VisualD is very tightly coupled with VS, but I think that
anything that could be made a bit more independent and reusable
would be a plus.
What I really wish is we had a single shared codebase for dlang
editor support, that could be shared among editor extension
writers, instead of having many community members working on
competing solutions.