VS has no place anymore. The velocity and mindshare is with VS Code. VS with its visual designers had its place .. but desktop is dead and Xamarin competes with frameworks without costly IDEs.
There is a place for a featureful IDE with robustly implemented build, debug, and package management capabilities working out of the box with multiple languages and entrenched technologies.
I do very much like VSC and use it all the time for anything involving text, markdown, cross-platform C++, javascript, and even rust...but Visual Studio is as much of the Windows or .NET dev's toolkit as Xcode is a part of a dev in the Apple ecosystem.
VSCode is great. However, there is plenty of space for VS: it is also very strong, and has a long history of deep and extensive integration into very mature technologies. VS is still getting better year over year and while I see VSCode as competitive in some spaces, it is no contest in others. If VSCode is to replace VS, it has a very long tail of issues to address, the resolution of which would probably raise both boats anyways.
But, what I didn't know until this recent debacle, is how there is a theory that the reason the .Net-tooling in VSCode is so bad is the same reason we had this watch-debacle. There was some discussion on that in the other HN-thread: https://news.ycombinator.com/item?id=28968231
https://github.com/microsoft/vscode/issues/6328
For a while there wasn't really another way to run SQL projects outside of VS. Data Studio recently got support for that though.
In VS the Solution Explorer lists Project Items, not files. Eg it lists DLL References. This means the entire tree view goes through the IVsProject interfaces and you open Solutions and Projects, not folders.
VS Code works on files only and doesn't have a project system that can specify file nesting rules. The simple ask in the PR could be implemented, but it seems arbitrary and other languages will ask for their own rules. (Vue?)
What doesn't feel so nice it's writing C/C++ as intellisense does not help as much as it does for other languages.
I've only ever used VS for hobby/side projects, and even 10 years ago it was leaps and bounds better than what I have to use for my professional day to day work now (code completion, debugger are the two things that I miss basically every day).
The tools that I use now have these features, but they're such a joke in comparison. The code completion has no notion of "code", it's just looking for similar words.
For C/C++ on Windows, well, you have VS Code and also JetBrains CLion, but IMO CLion is surprisingly rougher than Rider, even though it's older. You can get stuff done though.
My only gripe is not supporting remote development but it's in the works.
Since I know it and am familiar with it, I make my employer pay for a commercial license at work. In the grand scheme of things, it is not that expensive in a commercial setting.
VS Code is great, but I do not think it is a comprehensive replacement for Visual Studio proper when doing full stack .NET development.
Though it seems MS actively disallows employees to come n tribute to them.
If you do GUI work, you pretty much have to use VS. :-/
It's usable for sure but the development it's not as fast as in Visual Studio.
I still use VS Code if I want to modify some files like XML, json, yaml, and I don't want to fire another instance of Visual Studio for that.
As others have already pointed out, OmniSharp is "good enough", but what's built into Visual Studio is still a lot better.
Even with extensions, VS Code feels like an text editor.
Attaching a price to your ability to onboard a language with your favorite workflow changes how you view that language and the motives of its maintainers when compared to the alternatives for that platform. Java has no such barrier to adoption on Linux, for example, because IntelliJ happens to have a community edition.
Are you paid for your work? Why shouldn't the developers of development tools be?
[1] https://github.com/JetBrains/intellij-community
[2] https://visualstudio.microsoft.com/license-terms/mlt031819/
CLion is getting there, it's not quite as good yet but was still much better than VSCode.
For the non-web world specifically, the part that was Windows Server and Windows Desktop is simply a dead end outside of niches. And within the niches, comparisons are not all that relevant since... they are niches. If you have a specific job for a specific tool, then trying to compare that with something that does not meet those specifics isn't all that helpful.
Most of my C/C++ work that remains doesn't even target windows anymore since there is no purpose for it. The super small subset that does is just things like device drivers, and that's more a property of the OS than of the project itself.
Speaking of which, I feel the need to rant a bit: developing for Windows using QT is much more nicer than with any MS framework. MFC is a nightmare. Windows Forms was deprecated in favor of WPF which no one cares about. From C# you can't use Direct X or Vulkan with ease.
Maybe MAUI will bring a better experience. But they need to do something for C/C++, too. Maybe buy the rights to use QT and integrate it with Visual Studio if they don't want to develop a good framework. Or buy the framework from Embarcadero (the one used by C++ buulder). But don't force people into MFC mess. I presume that even their own developers hate MFC with passion.
Winapi was ok in the 80s. MFC was ok in the 90s but we are in 2020s.
But that doesn't make the tool a great tool in absolute terms. That is also the problem with this type of comparison, some people come up with arguments that are tangential at best. If you use literally anything else (anything that is not winapi, win32, forms, mfc, wpf or some legacy xaml) then Visual Studio is just a limited experience at best, and a steaming pile of crap in most cases.
This goes for more software obviously, if you want to write C# but try to do that in Xcode, you're going to have a bad time. Same for when you need to write a Kubernetes controller in Go, that's going to suck really badly in VS or XC.
There are a few remaining systems that really benefit from unmanaged languages and strong OS-integrated tooling (the niches that were mentioned), but the mass development practises going on today are basically non-desktop and specifically non-windows-desktop. This means that a tool that was designed to be specifically for windows-desktop (or macOS-desktop for that matter) is unlikely to be optimised for anything else.
Windows Desktop as-is might not be a niche, but building local native desktop applications is. Even if you target Windows Desktop right now for a new application, it's likely that it's going to be some crappy CEF/Electron thing. And yes, that's crappy, but it also means you get to use much more of the knowledge/mindshare/community that is out there which is bigger than all desktops combined.
VS Code still has good code completion/etc but it doesn't seem able to match the instant responsiveness of VS.
It's not a replacement for VS itself in that regard, but the activities that used to be bound to that IDE moved on over the years.
Whenever I have to load some old project into VS, it feels old, slow and clunky compared to other tools. The limitations on the structuring on-desk, metadata, building, linking etc. are very annoying as well for projects that ended up having more than just generic Windows Desktop targets (or even if they are highly specific editions/versions). I suppose that might be because other tooling outside of the process of the 'write-debug-release' chain has moved to broader and more interchangeable concepts where VS has remained basically the same for the last decade.
Presumably you are not using anything built on the Eclipse, Jetbrains or NetBeans with any language they support? (PHP, Java, Kotlin, Python)
Because out of the box and without any extras all these three beat Visual Studio easily once you start doing anything advanced except GUI, and NetBeans had a reasonable story to sell even there.
On refactoring the story is if not night and day then at least dusk and broad daylight.
Similar to what is going on here with Microsoft, they refuse to support what Eclipse and Netbeans do for free, as means to sell Clion licenses, and then make you run two IDEs in parallel.
That said, for most .Net devs I know the first thing they do after installing Visual Studio is installing Resharper just to get it up to the same level that IntelliJ (including the open source community edition), NetBeans and Eclipse (both open source) provide out of the box.
I can only guess but I think Big Scott, lesser Scott and Julia will have a meeting soon. The .NET community is at a boiling point and they should really avoid a community which takes dev productivity in their own hands. Because that is the garantueed end of visual studio.
sounds like .NET is almost the kind of thing I'd use then, because in a world without Visual Studio, I might not be punished for choosing to use .NET but not VS
I was amazed they'd try something new like cloud. I thought they will stick to the desktop and and MS Office until someone will snatch it from their dead cold hands. But Ballmer went and Nadella came. I still think that the company has a lot of Ballmers hidden in a lot of places, waiting for the opportunity to pull the breaks if they sniff that something interesting might happen.
People keep saying this, but they obviously have no idea. Desktop isn’t dead and nowhere near it. Just because web and mobile app developers think so doesn’t make it true.
There are several industries in which desktop applications are a must. Any application with the needs of multiple windows automatically rules out web and mobile stacks, even if they happen to work on desktops.
Can you elaborate? The last time I looked into this (including a little now) showed that, yes, you can create multiple windows, but there are not good solutions for communicating between the windows. Electron's own documentation shows two, options between local storage and Electron's IPC mechanism. From what I've read, IPC is not good for more complex multiple window apps. So one needs to use a local network communication method.
https://www.electronjs.org/docs/latest/faq#how-to-share-data...
If this is all the case, I would hardly consider it full support.
The only reason Electron exists is to enable Javascript developers do desktop apps without learning other languages and frameworks. Electron is not a solution for desktop development, it's a solution for lazy developers.
I would say most industries. Anything that requires creating any kind of digital content (images, videos, CAD models, electronic schematics, chip design, PCB layout, etc), most of the scientific software, all rely on the computational power and the speed of the desktop applications.
While there are industries that still use local compute and local rendering, that is exactly what it's about: industries. You might have image and video and audio manipulation. There could be hardware control. Maybe there is 'appliance'-like functionality such as POS and vending systems. But those aren't really the mass-desktop scenario that it used to be. That is mainly 'work' usage.
There is this section that you can carve out that does still exist in the traditional form and that is gaming. But that essentially turns the 'desktop' into a gaming console.
Legacy configurations that require things like an actual mouse pointer and multiple windows (or that dreaded MDI document-window-in-a-window interface) are generally left in two categories:
1. bad implementations
2. niche implementations
The first one means investment to fix, which is generally not going to happen if there is no commercial incentive for a commercial piece of software. The second one is a niche and doesn't represent desktops in general.
It would be more precise to say: Desktop business apps are dead. That is almost 100% true. Some lingering ghosts still exist.
While the backed is nice, that React UI feels like crap compared to the old UI. The only reason we are using an React UI being that "it's modern". Not every app should be an web app.
VS is on a whole other level than VSCode when it comes to C#. I suspect that many people here haven't really used the IDE features and VS' debugger for more than simple breaking and inspecting a variable.
Yes, if you have a hobby project, you can use VSCode instead of VS Community Edition just fine. But if you are dealing with concurrency errors, performance analysis, dump analysis, and very, very large projects, you can't use VsCode. VS' GUI is also a lot more flexible than VSCode's. In VS I can have a lot more information present where in VSCode I need to constantly switch windows.
That's exaggeration at best.
VS with extensions like Roslynator make C# development really good.
VS Code is nice, but I always felt like VS had significantly more reliable Intellisense than VS Code (for C#).
but I wish VS (real, not 4Mac) worked on Linux.
I use the community version. VS Code, while being extremely good, is still far behind VS. I love using VS, as a solo developer. The integration it has WRT .NET projects is amazing.
But VS Code is far more just a text editor and that you can run and debug many languages in it in my opinion means it meets the criteria of an IDE.
If I was forced to switch from VS to VS Code I would be miserable and feel handicapped, but infinitely more productive than just having a text editor and the dotnet CLI.
So VS Code is absolutely a “replacement” for VS, but only for a poor man with a very limited set of required features.
All the above being said, I don’t ever see VS Code truly replacing VS, but it’s a competent IDE considering its both cross platform and free as in beer.
And when .NET MAUI will ship, I guess we will have a visual designer for that.
That are endless features on VS that VSCode will never get.
I tend to disregard leetcode interviews anyway, unless I am on a deep need for a job without alternatives.
Same for 'what was your first computer', there is a whole generation (or maybe two of them at this point) that started out with smartphones and didn't get to the 'using a desktop' level until much later when preparation for work life required it.