Sadly, as a developer there is no beating Visual Studio. Microsoft still makes the best developer IDE that unfortunately only runs on their worst OS. But as a C++ developer there is just no substitute(imho). Not to mention some development toolchains only work on windows(for playstation/xbox/switch) so if you work in games there is very little choice.
I left Visual Studio for Rider long before I gave up Windows, IMO it's far superior to VS for everything other than GUI Apps or Blazor hot reloading (which is basically broken in both).
JetBrains seem to have the best IDE for every language I've tried: Rider / IntelliJ / Android Studio / PyCharm / PhpStorm / RubyMine. Never tried CLion though, but given they all share the same base I'd thought it would be of a equally high standard?
My bad. I naively assumed the successful developer-focued tools company with 25 years experience in parsing programming languages and building IDEs with advanced AST/refactoring tooling, that I've been happily using for 8 years had a great C/C++ story based on my experience of having used 7 of their other IDEs (built from the same platform base), were all best-in-class.
Maybe that's why I ended my thought with a question mark? i.e. So C/C++ developers with experience in both can clarify what makes VS so much better than CLion. Or if they haven't tried CLion that it would be a good alternative on Linux to try given all JetBrains other IDEs are of high quality.
Visual Studio is nice for C++ if you target Windows and CLR languages but for the rest it’s pretty abysmal. I personally generally prefer IntelliJ and used to find CLion nicer for C++ but that was a long time ago.
Anyway, Windows has become a pain for normal user but remains fine if you are a company user. The management tools will strip away most if not all the annoyance people are complaining about here. I think Microsoft knows where the money comes from.
You know, I think that's the key - I'm on Windows Enterprise and it just works. I start my PC, I code for 8 hours a day, I switch it off - it just works.
If your target platform is MS Windows only or only supported by MS Windows like with your examples, by all means, use Visual Studio. If Visual Studio is dictating your choice of platform, I'd consider the tradeoffs.
I use Emacs. It does need some fine tuning, tree-sitter installation, etc. but after that, I cannot understand colleges using VS. I have seen no feature in VS not available in Emacs.
Some colleges have switched from years VS to Emacs and after a week won’t look back.
Can you share what the experience is like debugging with gdb directly?
I'm new enough that my first debugger experience was Visual Studio, and I currently use IntelliJ IDEs which provide a similar experience. That experience consisting of: setting breakpoints in the gutter of the text editor, visually stepping through my source files line by line when a breakpoint is hit, with a special-purpose pane in the IDE visible, showing the call stack and the state of all local variables (and able to poke at that state any point higher up in the stack by clicking around the debug pane), able to execute small snippets of code manually to make evaluations/calculations based on the current program state.
I'm not so naive to believe that effective debugging tools didn't exist before GUIs became commonplace, but I have a hard time seeing how anything TUI-based can be anywhere near as information-dense and let you poke around at the running program like I do with my GUI-based IDEs.
(Pasting this comment under a few others because I genuinely want to hear how this works in the real world!)
Some emacs-fans really like emacs and will invent any justification for its shortcomings. You are 100% right it has a subpar debugging experience. There were better debuggers 20 years ago than emacs has now.
Stallman himself wrote it so it lies at the intersection of that camp and the lisp cultists (though Ig they are mostly extinct post-LLM), but they used to have a really strong belief that lisp was the path to AI because of it's homoiconicity.
What should be said in it's favor is that due to its architecture it is crazy extensible and hackable. And the fact that the line between configuration and code is very blurry really encourages you to dive into that.
The choice of lisp also helps ensure user freedom as it's a quite simple language - ensuring that compilers and interpreters are a commodity. You don't like one, pick another. Contrast that with say Rust where if you don't like the official Rust you are shit out of luck. It's also a rolling release deal so you can't even easily stay on an old version.
Maybe is personal preference? I like better gdb directly to VC.
I’ve tried to debug with VC, but I felt slow working with it. After several tries, I gave up.
Most of my colleagues never use a debugger even though they use vscode. I (the weird emacs user) actually had to show them how to use one, but they still don't.
Are they actually programmers? Or just people who pretend to know how to code? How can you be a professional programmer and not use a debugger? Also not sure what VS Code has to do with it, it's not Visual Studio proper.
I know plenty of professional programmers (job title states so) that not even they do not use a debugger, many don’t even know how to install/use one or even the very concept of “execute step by step”. Plenty of python users don’t know what pdb is (as matter of fact, have never met one that does know it!). Also plenty of embedded developers writing C or C++ or Java
They go all the time adding hundreds of print(f) of log_* function calls. Often they don’t care to remove them after the fact, as I ask them to, often comes “can/will be useful to detect future bugs”
I’m in the automotive industry, where is known to be a disaster in topic SW. but I think it is also common in other industries. I have seen it in telco already.
While I agree that knowing a debugger is important, and as a leader won’t hire somebody who do not use it, is a fact that many people don’t use it, and are doing ok.
Last but not least, it must be said sometimes you have to go to prints: in fact yesterday I had to, as I was debugging a library with sockets, which would timeout pretty quickly. I used dprintf in gdb, but the advantage to simple prints was not huge.
>>Last but not least, it must be said sometimes you have to go to prints
Well yes, obviously - it's an indespensible tool in any arsenal, I just cannot fathom(as a C++ low level engineer) how someone can be a professional programmer where they are paid for their job and they don't know to use a debugger even to just do a basic pause and step through flow. But then again I don't work with any python programmers, so maybe that's why.
They managed to grow a career out of a minimum set of skills, printf was enough I guess. Also they leverage stupid IT shops where squeaky wheel gets the grease.. being efficient at debugging would almost prove harmful in their world.
Just wait for it, from what I know Sony uses clang for it toolchain, don't know about the others so if enough studios start to switch they will start to offer the tools.
Side note: I have been using msvc in wine for almost 5 years now, so if that works I don't know why the Sony/Nintendo/Xbox toolchain wouldn't.
Have you tried the intellij IDEs? I thought that they were pretty similar in terms of experience, although I have used them for java/dotnet primarily.
I guess downvotes come from people that believe vim + grep + printf debugging is peak development environment. Quite amazing that they even go for something such advanced as vim, instead of sticking with ed, for I believe there exists some Linux user claiming that ed doesn't lack anything that VS has.
No you’re just completely ignorant. You can trivially set breakpoints, use conditional breakpoints, watch variables, step over, through, and into in exactly the same way.
Hell, even raw-dogging lldb directly on the CLI is incredibly user friendly, fast, and has a ton features you wish were more exposed by common IDEs. Don’t feel like debugging right now? Take a heap snapshot and do it later! Don’t even need to launch the process.
Visual Studio is ridiculously overrated, and this is coming from someone that works at Microsoft and forced to use it every day. What really kills me are the insanely complicated and unmodifiable shortcut keys for common tasks. Killing the process is like some finger breaking ctrl+alt+function key nonsense? Seriously wtf? Oh to debug multiple binaries simultaneously in the same solution requires launching multiple instances of the entire IDE? Why??
Can you share what the experience is like debugging with gdb directly?
I'm new enough that my first debugger experience was Visual Studio, and I currently use IntelliJ IDEs which provide a similar experience. That experience consisting of: setting breakpoints in the gutter of the text editor, visually stepping through my source files line by line when a breakpoint is hit, with a special-purpose pane in the IDE visible, showing the call stack and the state of all local variables (and able to poke at that state any point higher up in the stack by clicking around the debug pane), able to execute small snippets of code manually to make evaluations/calculations based on the current program state.
I'm not so naive to believe that effective debugging tools didn't exist before GUIs became commonplace, but I have a hard time seeing how anything TUI-based can be anywhere near as information-dense and let you poke around at the running program like I do with my GUI-based IDEs.
(Pasting this comment under a few others because I genuinely want to hear how this works in the real world!)
I much prefer lldb over gdb, but why don’t you just try it and see for yourself?
Of course setting a gutter breakpoint is easier in an IDE, and that’s irrelevant to my point. OP made this aabout vim/emacs versus VisualStudio as if the former doesn’t have gutter-clicking capabilities. Which is ridiculous
The keyboard layout change is not on my version (dogfood) for some reason, maybe because I have to use Remote Desktop and it doesn’t detect a physical keyboard. But fine, I’ll take that back. I even asked AssPilot for help and it was predictably useless.
And cmon modify the registry to debug multiple processes? People work together in teams and share a common tooling that ideally tries to minimize the friction required to get work done. Think about that while contrasting the steps required in that article with the alternative of“launch the app a couple more times, then…”
* "Sometimes, you might need to debug the startup code for an app that is launched by another process. Examples include services and custom setup actions"
Starting multiple copies of the IDE wouldn't handle these scenarios either
