[vlovich123]

I'm not sure I'm following the scenario described, but I don't see how the debugging complexity is more difficult than at the crate level. Can you help me understand why this might be the case? I'm not sure what you're calling as division boundaries / pseudo-crates here (are you suggesting that the dependency tracking won't be fine-grained & trivial changes can cause false sharing or something else?).

Doing all this tracking correctly though across layers of compilers is tricky if you want to shoot for absolute optimal performance. At the limit for truly optimal behavior, you'd track all the input information the compiler used when generating code and map it back to the source level (i.e. did I inline function A into function B - then I need to regenerate function A if B changes, but if no inline then don't regenerate A), which can be hard as most compiler optimization passes are information destroying. So yeah, I don't doubt that whatever "practical" middle ground is found as a realistic implementation can be tricky to reason about, but I suspect it almost doesn't matter if done well because it'll always outperform what you would have done by hand as outlined in this post / do it for you for free in 90% of cases.

[IshKebab]

He's saying that if you explicitly separate your crates out, and then you accidentally introduce a circular dependency you will get a compile time error. But if you have one big crate and rely on the compiler to detect internal dependencies for performance, then when you accidentally introduce a dependency that you didn't mean to it will happily compile but it will be slower so you probably won't notice and it will be really hard to debug.