> modules in Nim provide no intrinsic guarantees about that splitting There are not many languages that provide such guarantees. C guarantees nothing. C++ guarantees a member to be defined in the class definition or its superclasses, which in turn are not guaranteed to reside in any specifically named file. C# has class extensions, so no guarantees again. Ruby has implicitly object static functions, so no luck. Even if you take Java which provides a whole ton of guarantees, still a symbol could either belong to a class or any of its superclasses. Still all of these languages proved to have extremely large codebases. Usually they manage to do so by following common sense and good engineering practices. I personally love such approach. With powers comes responsibility.
>From my own statistics, the project I work on (splitted to libs) counts more >than 90KLOC of pure Nim code, not counting numerous dependencies in nimble >packages, and still there was no pain at all with name conflicts, lack of >namespaces, or symbol-origin-determination. However, there was some pain with >cyclic imports a few times, but that doesn't mean Nim is not the best language >out there
