5 ms·

I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the g

by achn 5y ago

I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the greatest IDEs ever produced. If you are having to fight with VS, then you may not be using it for one of its main use cases. I certainly don’t think it is perfect (git support being quite annoying at times) but to say that it isn’t an incredible achievement is ridiculous.

amelius 5y ago
> If you are producing code for which VS was designed That's literally what GP is trying to say: "either you do it the VS way or screw you."
n8cpdx 5y ago
Try programming for Xamarin, UWP, or anything involving multitargeting. The list of actions for which closing visual studio, deleting a bunch of random folders, and restarting is long. Unfortunately it includes any changes to project files, because the project system is super broken with anything multitargeting related. That basically means I have to completely restart my IDE and run a script to clean everything maybe 15 times a day. And fuck me if I’m trying to find where a regression happened (which means changing dependencies, which live in the csproj). I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.
- lazulicurio 5y ago
  > Try programming for Xamarin, UWP, or anything involving multitargeting. The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS. With that said, if you're coloring within the lines[1], VS is very powerful and productive. [1] To an extent. There definitely are use cases that are "supported" only in name.
  - ripley12 5y ago
    > More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS. This is part of why the .NET hot reload fiasco was such a big deal to me; it felt like doubling down on one of .NET's biggest weaknesses.
- garren 5y ago
  I used VS for years across a couple of C/C++/C# projects, and it was second to none with one exception. The exception was Xamarin/Xamarin.Forms. Seriously, congrats to the Xamarin people for getting that project going, but it was (at least into Xamarin.Forms 1-3) more than a little hacky and extremely frustrating. Granted, it kind of had to be though given that it was intended for a broader audience targeting completely different platforms, and at least initially didn't have a lot of MS support iirc. I think the issues surrounding cross-platform targeting were/are less a problem with the IDE itself than what it was/is forced to work with. The whole iOS "code in VS on Windows, but build on a Mac" was a nightmare, I don't know if things have gotten any better.
  - n8cpdx 5y ago
    They’ve actively gotten worse. I should have clarified that my “I remember when” comment applied to 5 years ago, not 15. Reverse progress on that timescale just isn’t acceptable IMO. MAUI is supposed to fix it, but I’m not sure they’ll have a developer community left to use it by then.
- phillipcarter 5y ago
  >I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment. This is because the software you're building today is far more complicated than before (from the IDE's perspective), and it doesn't do a good job of keeping up. There's a reason why so many people jump to VSCode these days - it gives you less bells and whistles, but it won't blow up on you when you try to do something moderately complex.
blibble 5y ago
> I don’t see how anyone can have this opinion. it's pretty common amongst those who used Delphi 15 years ago (or those that use JetBrains products today)
- deleted 5y ago
  [deleted]
strictfp 5y ago
I'm one! I work with VS daily and I think it's pretty bad. Some examples; I cannot get a plain folder view. Intellisense is very inept compared to Jetbrains products. Bad refactor support, can't find things you're looking for etc. File tabs are hard to keep organized. The source control support has been worst of the worst up util recently (blame view taking minutes to show up etc), and now it's only mediocre. Best way to find stuff is through "find all", which is an order of magnitude slower than grep. "Track changes" resets on file close, not when you save or commit, making it rather useless. VS also crashes quite frequently if you aren't gentle with keypresses. Single-threaded plugin model causing keyboard input lag. Etc etc. I could go on. The good parts of VS is hot-reload (when it works), the debugger, and the profiler. Otherwise I'm not a fan.
- unbanned 5y ago
  >I cannot get a plain folder view Yes you can. Change from solution view to folder view. >The good parts of VS is hot-reload (when it works), the debugger, and the profiler So everything you want from an IDE? What are you actually angry at?
  - strictfp 5y ago
    I can't use file view, since it has some side-effect that messes up our solution completely. And before you blame me, it's a cmake import. I'm not angry, I just don't think it's fair to claim that VS is a good IDE. If that's all you expect from an IDE, I understand why you're happy with VS :D
    - jevgeni 5y ago
      Yes, but what do YOU expect from an ideal IDE? That was the question. If you're targeting .NET or C++ development for Windows, there's not a lot of competition to be able to claim that there's something substantially better. Rider, IMO, is on par, with better refactoring. However, VS debugger is still better.
      - 5y ago
cma 5y ago
> to say that it isn’t an incredible achievement is ridiculous It takes like 20s to search source filenames of large projects, with fast SSD and 64 cores.
leetcrew 5y ago
I would think visual c++ must be one of the intended use cases. it's far from the worst c++ ide, but it can be pretty frustrating. you basically can't trust "find all references" in large projects.
phillipcarter 5y ago
> If you are having to fight with VS, then you may not be using it for one of its main use cases. So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases. VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.
- SantiagoElf 5y ago
  You should be very proud. I remember the early .NET 2.0/3.0 days where you had to have ReSharper installed and it made VS almost unusable. Nowadays (the last 5-6 years) I use Visual Studio without any third party extensions - it's a blast! I believe Visual Studio to be one of the crown jewels of Microsoft.
- temac 5y ago
  > 64-bit solves so many perf and user-perceived reliability issues I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. I suspect the cold reality was that the code base was not ready and the migration just took some time :)
  - phillipcarter 5y ago
    >but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end. Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019. But the problem with this article is that it was entirely speculation. It did not account for several things: * A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less * Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time * You really don't know what the impact of something is going to be until you actually do it * If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.
joenathanone 5y ago
Lately VS has been breaking my code with its autocomplete, for example lets say I'm working on a web project and want to wrap an element in a div, I may have some existing code I want to reuse so I will copy and paste the opening tag for example, <div style="some styling" class="class1 class2 class3">, then I will hand code the closing tag like so, </div> but VS will 'correct' it to this </div>> for some reason and my code wont work, I start debugging only to find that the autocomplete has again broken my code.
ejb999 5y ago
Couldn't agree more - love visual studio (on windows), and vs code even more (lighter weight, but less features) when I am on a mac or ubuntu. Also use Visual Studio on the Mac - that one I could agree is terrible - but hope it will improve over time. Probably helps that I have used every version of VS since it was released - so like anything else, if you are used to it and use it every day for 20+ years you become biased - but for C# programming, imo, nothing even comes close.
- wsc981 5y ago
  On the Mac I use Rider which is in many ways a huge improvement over Visual Studio. No visual editing of XAML files though, so I am slowly migrating the codebase to use views fully written in C#.
hermitdev 5y ago
I've been a long time VS user. Started with Visual C++ 6... In my experience, it's never been a straight forward conclusion of version X is better than the one before. With each release, it does somethings better, or new, but others worse, sometimes cripplingly so. And one of the most frustrating things for the longest time was that if you needed a specific C++ compiler major version, you were stuck using the specific VS version that shipped with the compiler (unless you were willing to ditch projects and go with makefiles). Only in 2019 did that finally change. And speed of the IDE itself has been dodgy at times, even for brand new projects. I've tried the 2022 preview (I have not yet tried RTM), and there are excruciating pauses in the UI for seconds to create a new file in an empty project! But, there are great new features in there, too... Like Pretzold, I have a love hate relationship with IntelliSense. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. It is an active hindrance for writing/designing APIs. It is great for telling you about what exists, but falls on its face when you're trying to write something new. If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.
blitzd 5y ago
Not all portions of VS are maintained to the same degree - their BI tools were horrible for years, and there was not much in the way of alternatives. I'd often spend more time fixing/triaging the IDE issues than I would my own code/projects. And when you then start to add multiple versions of VS into the mix (this was required for the BI projects + newest SQL Server database projects) it gets even worse.
fivea 5y ago
> I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the greatest IDEs ever produced. Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus. Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy. > If you are having to fight with VS, then you may not be using it for one of its main use cases. I guess that writing software and building projects are not Visual Studio's main use cases, then.

by achn 5y ago

amelius 5y ago

> If you are producing code for which VS was designed That's literally what GP is trying to say: "either you do it the VS way or screw you."

n8cpdx 5y ago

Try programming for Xamarin, UWP, or anything involving multitargeting. The list of actions for which closing visual studio, deleting a bunch of random folders, and restarting is long. Unfortunately it includes any changes to project files, because the project system is super broken with anything multitargeting related. That basically means I have to completely restart my IDE and run a script to clean everything maybe 15 times a day. And fuck me if I’m trying to find where a regression happened (which means changing dependencies, which live in the csproj). I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment.

lazulicurio 5y ago
> Try programming for Xamarin, UWP, or anything involving multitargeting. The complaints in the original article fell rather flat to me, but this is one area where it's absolutely fair to criticize VS. More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS. With that said, if you're coloring within the lines[1], VS is very powerful and productive. [1] To an extent. There definitely are use cases that are "supported" only in name.
- ripley12 5y ago
  > More generally, the reason that build tooling in the .net sphere is such a mess is because of historical baggage from VS. This is part of why the .NET hot reload fiasco was such a big deal to me; it felt like doubling down on one of .NET's biggest weaknesses.
garren 5y ago
I used VS for years across a couple of C/C++/C# projects, and it was second to none with one exception. The exception was Xamarin/Xamarin.Forms. Seriously, congrats to the Xamarin people for getting that project going, but it was (at least into Xamarin.Forms 1-3) more than a little hacky and extremely frustrating. Granted, it kind of had to be though given that it was intended for a broader audience targeting completely different platforms, and at least initially didn't have a lot of MS support iirc. I think the issues surrounding cross-platform targeting were/are less a problem with the IDE itself than what it was/is forced to work with. The whole iOS "code in VS on Windows, but build on a Mac" was a nightmare, I don't know if things have gotten any better.
- n8cpdx 5y ago
  They’ve actively gotten worse. I should have clarified that my “I remember when” comment applied to 5 years ago, not 15. Reverse progress on that timescale just isn’t acceptable IMO. MAUI is supposed to fix it, but I’m not sure they’ll have a developer community left to use it by then.
phillipcarter 5y ago
>I remember when I didn’t have to restart VS 30 times a day, and memorize which build errors actually aren’t errors, and do random sequences of events to work around bugs, and memorize which unsuppressable warnings are legitimate and which are not. Before those days, Visual Studio was indeed an incredible accomplishment. This is because the software you're building today is far more complicated than before (from the IDE's perspective), and it doesn't do a good job of keeping up. There's a reason why so many people jump to VSCode these days - it gives you less bells and whistles, but it won't blow up on you when you try to do something moderately complex.

blibble 5y ago

> I don’t see how anyone can have this opinion. it's pretty common amongst those who used Delphi 15 years ago (or those that use JetBrains products today)

deleted 5y ago
[deleted]

strictfp 5y ago

I'm one! I work with VS daily and I think it's pretty bad. Some examples; I cannot get a plain folder view. Intellisense is very inept compared to Jetbrains products. Bad refactor support, can't find things you're looking for etc. File tabs are hard to keep organized. The source control support has been worst of the worst up util recently (blame view taking minutes to show up etc), and now it's only mediocre. Best way to find stuff is through "find all", which is an order of magnitude slower than grep. "Track changes" resets on file close, not when you save or commit, making it rather useless. VS also crashes quite frequently if you aren't gentle with keypresses. Single-threaded plugin model causing keyboard input lag. Etc etc. I could go on. The good parts of VS is hot-reload (when it works), the debugger, and the profiler. Otherwise I'm not a fan.

unbanned 5y ago
>I cannot get a plain folder view Yes you can. Change from solution view to folder view. >The good parts of VS is hot-reload (when it works), the debugger, and the profiler So everything you want from an IDE? What are you actually angry at?
- strictfp 5y ago
  I can't use file view, since it has some side-effect that messes up our solution completely. And before you blame me, it's a cmake import. I'm not angry, I just don't think it's fair to claim that VS is a good IDE. If that's all you expect from an IDE, I understand why you're happy with VS :D
  - jevgeni 5y ago
    Yes, but what do YOU expect from an ideal IDE? That was the question. If you're targeting .NET or C++ development for Windows, there's not a lot of competition to be able to claim that there's something substantially better. Rider, IMO, is on par, with better refactoring. However, VS debugger is still better.
    - 5y ago

cma 5y ago

> to say that it isn’t an incredible achievement is ridiculous It takes like 20s to search source filenames of large projects, with fast SSD and 64 cores.

leetcrew 5y ago

I would think visual c++ must be one of the intended use cases. it's far from the worst c++ ide, but it can be pretty frustrating. you basically can't trust "find all references" in large projects.

phillipcarter 5y ago

> If you are having to fight with VS, then you may not be using it for one of its main use cases. So I worked on VS tooling for a few years and I'm proud of what me and my peers achieved, but I don't think this is the right perspective. People should not be surprised by the behavior of their tools, and they should not be frustrated by random freezes or crashes all of the time. What the person you're replying to has experienced is very real - I saw it come up again and again and again in reports - and I hope that things improve for them with subsequent releases. VS 2022 is a fantastic new release (64-bit solves so many perf and user-perceived reliability issues), but there is so much more to go. VS still relies on a very very old COM-based UI model with one of the most convoluted and complex threading models to manage it that I've ever seen. It's so easy for any little component to mess things up, hang the UI, and make someone have a terrible experience. I know folks on the inside are working to improve this dramatically (they know roughly how to do it), but it's a long road ahead.

SantiagoElf 5y ago
You should be very proud. I remember the early .NET 2.0/3.0 days where you had to have ReSharper installed and it made VS almost unusable. Nowadays (the last 5-6 years) I use Visual Studio without any third party extensions - it's a blast! I believe Visual Studio to be one of the crown jewels of Microsoft.
temac 5y ago
> 64-bit solves so many perf and user-perceived reliability issues I love how in tech everything is always evil one day and the next one nearly the panacea. Now I understand the timing component is actually not to get rid of entirely, in the sense that maybe a 64-bit VS would have been a bad idea the year AMD released x64, but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. I suspect the cold reality was that the code base was not ready and the migration just took some time :)
- phillipcarter 5y ago
  >but among the stated reasons to stick to 32-bits not so long ago, and even one of the main, there was: performance. Yeah, this was from a series of articles that were a great example of managing to be right about all kinds of things but still be wrong in the end. Specifically, the articles laid the blame for things like memory usage (which when high enough, causes a foreground GC in the devenv.exe process that freezes your UI), on language services that get all too happy to allocate tons of memory. If you make this 64-bit, pointers double in size and you could observe even more memory usage. 64-bit is also objectively slower than 32-bit in terms of CPU time to execute stuff. The solution it suggested was for memory-intensive components to move out of process, which is actually what many of them did in VS 2017 and VS 2019. But the problem with this article is that it was entirely speculation. It did not account for several things: * A 64-bit devenv.exe process gives the GC more "room to work with" and do more background GCs rather than foreground GCs, which will pause the UI far less * Marshaling data between processes still requires use of the UI thread in VS in various scenarios, due to a wildly complicated threading model that people mess up all the time * You really don't know what the impact of something is going to be until you actually do it * If you commit to something ambitious like going 64-bit only, engineers can meet the challenge and produce something very good My personal belief is that 64-bit could have been reasonably accomplished many years ago, and it would have been the right call to do it then. But I won't be looking a gift horse in the mouth. The codebase I contribute to is so much more pleasant to work in with VS 2022.

joenathanone 5y ago

Lately VS has been breaking my code with its autocomplete, for example lets say I'm working on a web project and want to wrap an element in a div, I may have some existing code I want to reuse so I will copy and paste the opening tag for example, <div style="some styling" class="class1 class2 class3">, then I will hand code the closing tag like so, </div> but VS will 'correct' it to this </div>> for some reason and my code wont work, I start debugging only to find that the autocomplete has again broken my code.

ejb999 5y ago

Couldn't agree more - love visual studio (on windows), and vs code even more (lighter weight, but less features) when I am on a mac or ubuntu. Also use Visual Studio on the Mac - that one I could agree is terrible - but hope it will improve over time. Probably helps that I have used every version of VS since it was released - so like anything else, if you are used to it and use it every day for 20+ years you become biased - but for C# programming, imo, nothing even comes close.

wsc981 5y ago
On the Mac I use Rider which is in many ways a huge improvement over Visual Studio. No visual editing of XAML files though, so I am slowly migrating the codebase to use views fully written in C#.

hermitdev 5y ago

I've been a long time VS user. Started with Visual C++ 6... In my experience, it's never been a straight forward conclusion of version X is better than the one before. With each release, it does somethings better, or new, but others worse, sometimes cripplingly so. And one of the most frustrating things for the longest time was that if you needed a specific C++ compiler major version, you were stuck using the specific VS version that shipped with the compiler (unless you were willing to ditch projects and go with makefiles). Only in 2019 did that finally change. And speed of the IDE itself has been dodgy at times, even for brand new projects. I've tried the 2022 preview (I have not yet tried RTM), and there are excruciating pauses in the UI for seconds to create a new file in an empty project! But, there are great new features in there, too... Like Pretzold, I have a love hate relationship with IntelliSense. I think I can boil down my gripes with this: IntelliSense is wonderful for consuming APIs. It is an active hindrance for writing/designing APIs. It is great for telling you about what exists, but falls on its face when you're trying to write something new. If I am undoing the suggestions I didn't want, yet it insisted on placing, it is counterproductive. Personally, I get rather tired of slapping the escape key to cancel IntelliSense multiple times just so I can write out a dotted expression.

blitzd 5y ago

Not all portions of VS are maintained to the same degree - their BI tools were horrible for years, and there was not much in the way of alternatives. I'd often spend more time fixing/triaging the IDE issues than I would my own code/projects. And when you then start to add multiple versions of VS into the mix (this was required for the BI projects + newest SQL Server database projects) it gets even worse.

fivea 5y ago

> I don’t see how anyone can have this opinion. If you are producing code for which VS was designed (.net for example) it is obviously and definitely one of the greatest IDEs ever produced. Hard disagree. VS makes code harder to navigate than any other popular IDE out there to the point where even vscode is more intuitive and capable, it's extremely slow at that too, and makes even the tiniest change to a build config something that requires jumping through a myriad arcane menus. Having used other IDEs to develop Java, C# and C++ code, the only explanation I can find to explain Visual Studio's adoption, besides privileged access to Microsoft's emergent technologies and frameworks, is the boiling frogs analogy. > If you are having to fight with VS, then you may not be using it for one of its main use cases. I guess that writing software and building projects are not Visual Studio's main use cases, then.