3 ms·

I recently worked in a fairly large Rust project that I could simply not load into VS Code. rust-analyze would allocate more and more memory until it eventually

I recently worked in a fairly large Rust project that I could simply not load into VS Code. rust-analyze would allocate more and more memory until it eventually crashed. I have never seen that with C++ code, besides that time I was investigating how someone was using CImg and found out that the CImg developers thought it was cute to make a single 3 MB header, and that brought the debugger to its knees. It still didn't crash, though! So yeah, difficult-to-parse codebases are not an exclusive feature of C++.

shadowgovt 3y ago
Interesting. This is the first I've heard of a Rust codebase too big to parse, but I'm not deeply surprised; Rust tooling hasn't been hammered on for as many decades as the C++ tooling. I'm medium-level confident there's meat on the bones of optimizing it to a point better than the C++ tools because they made choices in the language that do some amount of compartmentalization, so you don't get that "one #define up in this header you've never seen changes the meaning of symbols in every other file in this compilation unit." Unless that is possible and I simply haven't gotten deep enough into Rust to realize it yet.
- fluoridation 3y ago
  Funny you should mention that. I'm pretty sure the reason this project was so difficult to process was the (IMO) abusive use of macros. I'm talking foo!( in one line, and several hundred lines below was the closing parenthesis.
  - shadowgovt 3y ago
    Macros (and in C++, their neighbor templates, since both are ways to make conditional decisions about what code to generate evaluated at compile time) are definitely the way to test out the limits of the compiler's performance. I haven't done enough Rust yet to hit this, but I don't doubt it happens. I did once make vscode scream on a very intricate family of conditional TypeScript types... Code compiled fine, but the editor started to take dozens of seconds to determine on-the-fly if types were sound. Back in the day, I once worked with a C++ game engine where the developer was obsessed with interfaces vs. implementation. Every class, even if there was one implementation, had an abstract interface wrapper. It was the first codebase I ever encountered where the compiler (on my Mac laptop) choked on it because it ran out of RAM trying to compile it.
    - fluoridation 3y ago
      That's very odd. Polymorphism and inheritance in general is quite easy to deal with both for the compiler and for the IDE.

shadowgovt 3y ago

Interesting. This is the first I've heard of a Rust codebase too big to parse, but I'm not deeply surprised; Rust tooling hasn't been hammered on for as many decades as the C++ tooling. I'm medium-level confident there's meat on the bones of optimizing it to a point better than the C++ tools because they made choices in the language that do some amount of compartmentalization, so you don't get that "one #define up in this header you've never seen changes the meaning of symbols in every other file in this compilation unit." Unless that is possible and I simply haven't gotten deep enough into Rust to realize it yet.

fluoridation 3y ago
Funny you should mention that. I'm pretty sure the reason this project was so difficult to process was the (IMO) abusive use of macros. I'm talking foo!( in one line, and several hundred lines below was the closing parenthesis.
- shadowgovt 3y ago
  Macros (and in C++, their neighbor templates, since both are ways to make conditional decisions about what code to generate evaluated at compile time) are definitely the way to test out the limits of the compiler's performance. I haven't done enough Rust yet to hit this, but I don't doubt it happens. I did once make vscode scream on a very intricate family of conditional TypeScript types... Code compiled fine, but the editor started to take dozens of seconds to determine on-the-fly if types were sound. Back in the day, I once worked with a C++ game engine where the developer was obsessed with interfaces vs. implementation. Every class, even if there was one implementation, had an abstract interface wrapper. It was the first codebase I ever encountered where the compiler (on my Mac laptop) choked on it because it ran out of RAM trying to compile it.
  - fluoridation 3y ago
    That's very odd. Polymorphism and inheritance in general is quite easy to deal with both for the compiler and for the IDE.