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 - by suddenly curling into a ball and forever becoming completely unresponsive - a state from which only recovery is a hard reboot. 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.
While I agree that Linux sucks at handling this particular situation, my point was about Rust's complexity. Normally, when you're using C/++ dependencies the IDE doesn't need to inspect the internals of the libraries to figure out how to parse dependent code. And, it's also true that rust-analyze doesn't know how to stop trying. It will parse what you give it, even if it kills your machine.
>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.