4 ms·

Ignoring the entire article, after using it for 20 years now, it rots my patience and will to live on large projects. It’s like driving a 30 year old car that w

by hughrr 5y ago

Ignoring the entire article, after using it for 20 years now, it rots my patience and will to live on large projects. It’s like driving a 30 year old car that was serviced 20 years ago and veers off the road uncontrollably once an hour. I suppose the last feature is modern if you compare to a Tesla. The twisted thing is that from what I have seen, the entire .Net development community is so compartmentalised that they think this is business as usual. Literally spending all day in pain with no idea there is a better life out there.

alkonaut 5y ago
What’s better out there? I’m using VS with a solution that eaaily has VS use 10Gb ram. I have tried vscode and Rider too, but Rider really wasn’t an option with parity until this last year or so. The perf in Rider is a bit better but I wouldn’t say it’s a dramatic difference. VS on reasonably small solutions (fewer than say 50 projects or 10k source files) is more than snappy enough these days. It’s on those large solutions it runs like a dog when each GC collects 2-3gigs of garbage in 5 frozen seconds and runs every minute.
- hughrr 5y ago
  What would be better is if they actually tore down the myriad of shitty misfeatures, bloat and bugs and did some housekeeping rather than change the theme and pile on features like an Indian train at rush hour. The one that kills me is the moment I hit . After an identifier I have to wait 30 seconds for it to work out what to do. That’s just broken. As always with Microsoft they need to actually go talk to the customers rather than collect telemetry.
  - alkonaut 5y ago
    They can’t because VS is a pile of COM-mess compatibility. So when they clean up they did it in vscode because there are decades of compat to maintain in VS. Every VS has to do what every old VS did and the new things. And it has to do it the same way too.
    - hughrr 5y ago
      Fair point. VScode is pretty good. I mostly resent having to use a text editor and msbuild because the tools are made of butter.
- sokoloff 5y ago
  We had to build tooling to break out solutions into multiple working solutions for use in VS and then use the actual solution for the build system. This meant that people would often break the build by modifying their local solution but not understanding what was really going on in the central build. Our cutoffs were way smaller than 50 projects and 10K source files, though! (We had a lot of generated code, which we eventually mostly switched from generating code to generating MSIL directly to save the IDE.)
  - fsfod 5y ago
    I wonder if filtered solutions files that load only the requested projects in a solution would of made that less painful https://docs.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2022#solution-filter-files https://docs.microsoft.com/en-us/visualstudio/ide/filtered-s...
    - sokoloff 5y ago
      It definitely would have; unfortunately, that was introduced in VS2019 and we had the need a decade before that, but glad to see that a better solution is now available.

by hughrr 5y ago

alkonaut 5y ago

What’s better out there? I’m using VS with a solution that eaaily has VS use 10Gb ram. I have tried vscode and Rider too, but Rider really wasn’t an option with parity until this last year or so. The perf in Rider is a bit better but I wouldn’t say it’s a dramatic difference. VS on reasonably small solutions (fewer than say 50 projects or 10k source files) is more than snappy enough these days. It’s on those large solutions it runs like a dog when each GC collects 2-3gigs of garbage in 5 frozen seconds and runs every minute.

hughrr 5y ago
What would be better is if they actually tore down the myriad of shitty misfeatures, bloat and bugs and did some housekeeping rather than change the theme and pile on features like an Indian train at rush hour. The one that kills me is the moment I hit . After an identifier I have to wait 30 seconds for it to work out what to do. That’s just broken. As always with Microsoft they need to actually go talk to the customers rather than collect telemetry.
- alkonaut 5y ago
  They can’t because VS is a pile of COM-mess compatibility. So when they clean up they did it in vscode because there are decades of compat to maintain in VS. Every VS has to do what every old VS did and the new things. And it has to do it the same way too.
  - hughrr 5y ago
    Fair point. VScode is pretty good. I mostly resent having to use a text editor and msbuild because the tools are made of butter.
sokoloff 5y ago
We had to build tooling to break out solutions into multiple working solutions for use in VS and then use the actual solution for the build system. This meant that people would often break the build by modifying their local solution but not understanding what was really going on in the central build. Our cutoffs were way smaller than 50 projects and 10K source files, though! (We had a lot of generated code, which we eventually mostly switched from generating code to generating MSIL directly to save the IDE.)
- fsfod 5y ago
  I wonder if filtered solutions files that load only the requested projects in a solution would of made that less painful https://docs.microsoft.com/en-us/visualstudio/ide/filtered-solutions?view=vs-2022#solution-filter-files https://docs.microsoft.com/en-us/visualstudio/ide/filtered-s...
  - sokoloff 5y ago
    It definitely would have; unfortunately, that was introduced in VS2019 and we had the need a decade before that, but glad to see that a better solution is now available.