[TeMPOraL]

> I had never seen a computer crash because an IDE was trying to figure out how to parse a program before I worked with Rust, for example.

C++ is complex enough that the IDE can't really parse much of the program's code in any useful fashion. You're lucky if it can get the right type hints and jump to definition. And even the latter may not be complete.

Contrast with e.g. Java, which makes it easy for the IDEs to get the full picture.

[fluoridation]

Sure, but in those cases the parser just gives up. It doesn't grow its working set trying harder and harder seemingly forever.

We're talking about C++ and Rust here, so I don't know why you bring up Java. If parsing Rust was as easy as parsing Java you would not see me complaining about it.

[TeMPOraL]

Giving up vs. crashing is a trivial difference, ultimately boiling down to an extra terminating condition connected to real-world resource use. Either way, the parsing is useless.

I brought up Java as an example of what it means for the IDE parsing to work and be useful.

[fluoridation]

Losing your work versus a minor inconvenience is a trivial difference to you? Well, okay!

[TeMPOraL]

What kind of IDE are you working in that will lose your work when it crashes?

I don't know what's going on in the Rust world, but in C++ world, even the good ol' Visual C++ (2017, 2019), when it crashes (which it does surprisingly often on my work's codebase), it doesn't lose anything other than maybe unsaved edits. It's annoying, sure, but 30 seconds later it's back to where it was before the crash.

Also, a not working parser is not a trivial inconvenience. It just means the tool doesn't work. From the POV of wanting to use advanced functionality that relies on parsing the code, it doesn't matter whether the tool aborts its execution so it doesn't crash, or has to be disabled because it doesn't abort its execution and just crashes. The end result is the same: I can't use the advanced functionality.

[fluoridation]

What I said was that the computer crashed. The IDE used so much memory that it took the system with it. When it came back up something weird had happened to the environment and it was ignoring the stuff in .bashrc.

>Also, a not working parser is not a trivial inconvenience. [...] The end result is the same: I can't use the advanced functionality.

Yeah. Now compare "the IDE is just working as a glorified text editor" to what I'm describing above.

[TeMPOraL]

I'm sorry for misunderstanding your earlier comment, and thank you for clarifying. I can see how this is a much more serious problem.

However.

That sounds to me less like an IDE problem, and more like a Linux problem. Specifically, the problem with the... unique way a typical Linux system handles OOM state, i.e. by suddenly curling into a ball and becoming completely unresponsive until you power-cycle it. I've hit that a couple times in the past, and my solutions were, in order:

- Monitoring the memory usage and killing the offending process (a graph database runtime) before it OOMs the system;

- After becoming tired of the constant vigilance, quadrupling the amount of RAM available in the OS; (yes, this is why people overprovision their machines relative to what naive economists or operations people may think..)

- Changing the job, and switching to working on Windows; WSL may not be 100% like a real Linux, but it inherits sane OOM handling from its host platform.

I'm sure there is a way in Linux to set a memory quota for the offending IDE process. This would hopefully reduce your problem to the more benign (if annoying) case I described earlier.