> The problem is that anything that's _apparent_ and not _enforced_ will be messed up over time We already have the tools to enforce these things in many mains

> The problem is that anything that's _apparent_ and not _enforced_ will be messed up over time We already have the tools to enforce these things in many mainstream languages. Breaking things apart into crates/modules certainly makes sense sometimes, but other times it does not? If you have a monorepo, do you really need multiple modules? And if you don't, does that mean your architecture is difficult to understand? I don't think that tracks at all, so I don't really agree with where you're headed. > But then we all know that there are some huge repos out there that are just "one module" and you can't make anything out of their internal structure. There's always some shitty code out there, sure. But I don't like the suggestion that "one module" can't be coherent. It's orthagonal to the architecture. Not everything needs to be made generic and reusable. > And the whole point of the article is to say that import statements do actually _not_ solve this issue, because import statements are at the file level, not at the module level (whatever module means in your mind). This is not true for Go, for example. Import statements absolutely do solve this problem in Go. I rarely need to ever look at module files which are in some ways a byproduct of the import statements.