IDK about "tier 1" but I'll note I've used VS for debugging and profiling Rust binaries. I even wrote a tool to auto-generate a wrapper .sln so I can easily launch from VS: https://github.com/MaulingMonkey/cargo-vs

The main pain point IME was poor debugger visualizers for standard containers and enums. I fixed some of that for the standard containers by writing some natvis files for std: https://github.com/rust-lang/rust/issues?q=state%3Aclosed%20... . Admittedly, they broke a few times. They also weren't automatically included in the pdbs, so I wrote a crate for that: https://github.com/MaulingMonkey/natvis-pdbs . And then someone crated and stabilized #[debugger_visualizer] for rust itself, which can do the same job: https://doc.rust-lang.org/reference/attributes/debugger.html .

(...I should check on enum visualization, but I suspect it's still poor.)

Optimistic to assume that modern day programmers even know what a debugger is, or if they do, consider it as anything else than some weird ancient shibboleth only used by the greybeards ;)

The greybeards rarely used debuggers, and then only to see the stack trace of a core file. They found printf better.

I can't find my copy of https://en.wikipedia.org/wiki/The_Practice_of_Programming but that is what I recall it says. Those authors are the best known greybeards.

To be fair, even before LLMs could spot my bugs in an instant I really only regularly used debuggers in C because it can't display arbitrary types in debug print statements.

Debuggers still have their place in algorithm heavy work, or to pull apart heap dumps to try and figure out obscure bugs.

Even LLMs use debuggers. I asked Claude to reverse engineer a closed source binary the other day. It used gdb to trace its behaviour. Didn’t even use ghidra.

> even before LLMs could spot my bugs in an instant

I guess it depends on the bugs.

LLMs even INSIDE the (VS) debugger couldn't work out some of the more recent bugs I have been looking at. Never mind by statically looking at the code base.

Debugger MCP better

But of a tangent but I think cognitive skills are starting to become like physical skills. If we don’t move our bodies, we waste away physically. If we don’t do hard cognitive work sometimes - like writing and debugging code - I worry our minds will atrophy.

I don’t have a problem with cars. But walking is still good for us.

Try, but what skills are work keeping? We need something cogntive, but not everything. I know a few people who blacksmith as a hobby (often for the physical exercise as much as the work), but most people are happy not knowing how to do that job. I know how to set the air-fuel ratio on a gas engine, but I'm glad I don't need to tweak those parameters while driving (unlike a 1910s car where you did), and I won't miss oil changes on my cars as I move to electric.

> Try, but what skills are work keeping? We need something cogntive, but not everything.

Are you trying to be funny?

Work should be worth. I'm not sure if that is me or autocorrect.

It was unintentionally funny then :-)

If I'd accidentally written a comment asking whether the intellectual skills I am losing are worth keeping, and make 2x spelling errors in a single short sentence, I'd find the unintended irony hilarious.

(but that's me, maybe you don't find accidental errors that you make to sometimes be funny)

It’s all /skills now

You have it already on VSCode, which isn't quite the same, however nowadays it is an open question which one is more relevant for Microsoft's management, especially given that VS isn't cross platform (see Azure), and is stuck with WPF/.NET Framework.

println!() already works, who needs more than that?

Kidding aside, VS Code has excellent debugging support already. Unless you need to share your Rust code base with a legacy C/C++ code base, I don't think VS is the best environment for Rust programming.

There are good use cases for staying within full-fat VS's capability set (drivers, among other things), but I don't think Microsoft needs to add Rust to VS in this much of a hurry.

I'd also love to see MS sponsoring Windows support for a modern linker like mold or wild.

lld-link is already a big step up from link.exe. Although the latter has incremental linking, which none of the Unix-like linkers have.

to be fair mold or wild's full link is a few hundred times faster than a link.exe incremental relink

Works already in Visual Studio Code, even seamlessly between C++ and Rust

RustRover, my friend.

I thought rover forced you to use their horrible new UI?

I've been using it since ~23 without any issues, the ui's have all been similar to Borland's stuff since the beginning.