[anonymars]

> Sometimes I think it would be nice to have limits on resources in order to more automatically find mistakes like this

I was actually fairly disappointed when Visual Studio (not code) went to 64-bit. Because I knew its memory usage was now going to be unconstrained. Still way better than the unapologetic gluttony of Rider but experiences showed it to be a bit leaky over time (tip: Ctrl-Alt-Shift-F12 twice does a full garbage collection https://learn.microsoft.com/en-us/visualstudio/ide/visual-st...)

Also remember that all your references (pointers) are going to double in size so right off the bat it will use more, potentially a lot more depending on how reference-heavy your data is

[pjmlp]

Even if it stayed 32 bit that wouldn't have helped with memory resources, because experience has proven that if we care about host stability extensions should be running on their own processes with OS IPC.

Which is something that VSCode does, and VS has been increasingly adopting, and I bet VS 2026 will most likely double down on it.

Which in the end means lots of processes going around to support IDE related tasks.

[anonymars]

Right, isn't that all the more reason not to make the IDE itself 64-bit?

[pjmlp]

Maybe, although there are other issues keeping 32 bit processes around on a 64 bit OS.

[anonymars]

Do you have some examples?

[DanielHB]

> I was actually fairly disappointed when Visual Studio (not code) went to 64-bit.

Keep stuff on 32bit to ensure memory leaks and feature bloat are caught early, genius.

Seriously though, that might be a quick and dirty way to get an application with a hard-limit on memory for testing.