Hacker News Reader

Comment by bicubic | Hacker News Reader

Considering the 64 bit support problem has been going on for over five years now and the magical 3GB limit is increasingly absurd on modern hardware, I wonder if they've considered just giving up on VS and doubling down on VS Code. It also sorts out their desperate need for a UI overhaul.

View on HN

Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.

It's not slower than VS. It's just not an IDE.

I really hope it is. I don't really find VS Code to be any slower than VS. Of course, this depends on what you're using each for. I find I prefer VS Code because it has so few default features. The default install does not contain GB of bloat that I will never need. I'm able to build the experience I want, rather than fight one thrust upon me.

I don't know precisely what the default install size is for Visual Studio 2017, but with the new installer, a Visual Studio install can be svelte relative to previous releases.

It's still large relative to VS Code and other editors of course. But the "gigabytes of bloat" problem with Visual Studio isn't so much the case now.

"I don't really find VS Code to be any slower than VS."

Given VS Code has a fraction of the features VS has, it should be noticeably faster. It will eventually be GB of bloat and slower than VS.

What I'd like to see instead is features being broken out into separate components that can be used by any other editor/tool. Of course, if every component is going to required it's own dot file in my home directory to (maybe) turn off telemetry, I won't touch it, so I'd rather see those things developed by someone other than MS.

VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".

The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.

You have a very different experience with VS than I have... right now, I'm waiting half an hour, so I can check out a branch from vsts, so I can wait another 6-8 minutes to build my solution, etc... it's painfully slow... VS Code, edit, next...

I've only seen VS Code run slow if you're running on 2gb of ram, or have hundreds of competing plugins installed, and even then. VS Code is way better than VS proper from my own subjective experience.

Visual Studio Code is a wonderful text editor. But it's far from being a full-featured IDE.

Really? I find that really surprising. Because VS itself isn't anywhere close to a wonderful text editor.

Like most IDE's, it is a mediocre text editor with a bunch of compelling (for certain workflows) tooling for project and build management, debugger, etc. Plus usable introspection. As a text editor though, a solid C+ at best.

Is VS Code someone doing something radically different?

VS Code started with atom shell (now electron), and a JS based editor that was being worked on for VisualStudio online... combined they were pretty compelling, and at the time so much faster than say Atom or Brackets... It's been my editor of choice since first trying it and only better with each regular release. The entire thing is opensource.

Completely open source, rich plugin/extension community. Pretty much has become the editor of choice if you're working on node or go... more than decent with other platforms, and as a general editor. There are extensions to improve workflows, but all optional extensions.

I have git history, git lense, eslint, docker, c# (works for .net core), go, jest, npm, npm intellisense, yandex-translate (makes vscode worthwhile by itself), and a couple others.

I don't think I can go back... having the treeview, git integration, integrated console, it's all just way awesome to say the least.

The plan that they seem to be following is to convert VS into a completely managed memory product and then move to 64 bit. It's easier and doesn't introduce a feature-freeze period for a project the size of Visual Studio.

You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse.

Personally, attaching a managed code port to the 64-bit migration sounds misguided. The managed code port sounds much more involved and disruptive than migrating the existing native code would be. It's probably some manager's pet project and it makes no technical sense.

There are already large chunks of managed code in VS. It might be that they are pushing to fully convert to managed code for other reasons, and as a side benefit they get 64-bit support for "free".

Probably the parts that are still in native code include stuff that is performance-sensitive, like the guts of the compilers. It's probably intricate and finely-tuned.

Only C++ ones, the main goal of Roslyn was to bootstrap C# and VB.NET compilers and get rid of their former C++ implementation.

Now with Roslyn and .NET Native, they are planning to increasingly move more runtime stuff into C#.

.NET Native backend is of course shared with Visual C++, aka C2, a kind of Microsoft's own LLVM-like approach.

.NET Native is new to me. It looks like it helps CIL languages to perform better. I'm not sure what it does to C/C++. I can't tell what the grand strategy is, but I guess they are catching up to Apple in some ways. It's amazing what Microsoft's resources allows them to do. Apple uses LLVM, and, of course, they would not be Microsoft if they adopted LLVM. Microsoft writes their own LLVM from scratch.

I think it's good to have additional implementations, even if they are rather insular about it.

Actually Microsoft had their own LLVM first. :)

It was called Project Phoenix, developed at MSR.

https://en.wikipedia.org/wiki/Phoenix_(compiler_framework)

Microsoft Research is the genuine article. It's a world class research institution.

I guess Phoenixey/LLVM type stuff is probably the way the winds were blowing in the compiler community at large. It's interesting how a lot of things that used to seem impossible are now in multiple software packages.

You figure that once MS is rolling out a compiler technology in a big way, it can't get much more mainstream than that.

I still don't totally understand why it was important for MS to push into JIT-compiled bytecode on Windows. From the end-user's standpoint, it just makes software slower.

Security, safety. Also GC is easier to make.

It doesn’t always makes software slower.

Not all software is CPU bound, a lot is IO bound, and .NET framework implements event-based asynchronous I/O since version 1.0.

> You can sort of imagine that there is a faction that hates the idea of moving to managed code, and that is causing an impasse.

Probably the same one that caused the issues with Longhorn.

Now we have UWP with .NET Native, which is creating an OO ABI similar to Longhorn ideas.

Reply on news.ycombinator.com