5 ms·

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 i

by bicubic 10y ago

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.

brynjolf 10y ago
Visual Studio Code is slow in comparison to VS. It has way less features. I hope this is not the path they take.
- chillee 10y ago
  It's not slower than VS. It's just not an IDE.
- lsadam0 10y ago
  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.
  - ovao 10y ago
    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.
  - jasonkostempski 10y ago
    "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.
    - lsadam0 10y ago
      VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".
    - MichaelGG 10y ago
      The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.
    - tracker1 10y ago
      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.
- deleted 10y ago
  [deleted]
hashhar 10y ago
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.
- mtdewcmu 10y ago
  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.
  - wtetzner 10y ago
    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".
    - mtdewcmu 10y ago
      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.
      - pjmlp 10y ago
        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.
        mtdewcmu 10y ago
daigoba66 10y ago
Visual Studio Code is a wonderful text editor. But it's far from being a full-featured IDE.
- ska 10y ago
  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?
  - tracker1 10y ago
    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.
  - deleted 10y ago
    [deleted]

by bicubic 10y ago

brynjolf 10y ago

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

chillee 10y ago
It's not slower than VS. It's just not an IDE.
lsadam0 10y ago
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.
- ovao 10y ago
  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.
- jasonkostempski 10y ago
  "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.
  - lsadam0 10y ago
    VS Code does break off features into separate components. This is what I'm referring to when I say "build the experience I want".
  - MichaelGG 10y ago
    The editor is noticeably laggy on my Xubuntu VM. Emacs/vim are speedy, as is VS on the host.
  - tracker1 10y ago
    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.
deleted 10y ago
[deleted]

hashhar 10y ago

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.

mtdewcmu 10y ago
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.
- wtetzner 10y ago
  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".
  - mtdewcmu 10y ago
    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.
    - pjmlp 10y ago
      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.
      - mtdewcmu 10y ago

daigoba66 10y ago

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

ska 10y ago
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?
- tracker1 10y ago
  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.
- deleted 10y ago
  [deleted]