Hacker News new | ask | show | jobs
by fluoridation 967 days ago
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.

1 comments

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.

I actually run Windows mainly. This was inside a Hyper-V VM with 32 GiB of RAM. I'd like to be able to work on this project from Windows, but unfortunately I can't, and don't have the energy or inclination to figure out how to get it building on Windows. I already knew rust-analyze had this problem, which is partly why I allocated so much memory for the VM. Unfortunately I triggered a rust-analyze rebuild just as I was already building another codebase in a different directory. That's what brought it over the edge.

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.