Reading this comment in a post:Namespacing is very sloppy. Importing a module dumps the entirety of its contents into your namespace. Method calls are just syntactic sugar: a.b() is exactly the same as b(a), so methods are also in the globalish namespace. Seems to rely extremely heavily on overloading.I applaud his commitment, the post was very long and addressed a number of topics. One thing that caught my eye was your criticism of nim namespacing or lack thereof. I’m not sure I have a strong enough opinion either way but one thing I have been noodling on is the notion of a monolithic codebase with a global namespace. Silly me, this is exactly how C does it so it’s only natural that Nim does too. Java and C# privacy modifiers are nonsensical since “we” typically have access to the source. The Go implementation uses case for privacy but implements package namespaces which are easy to overlap meaning having to use aliases.In a related post. Namespaces are supposed to provide some sort of orthogonal barrier between packages. One perfect example is the C compiler. Most C compilers prefix all user attributes, variables and functions with a ‘_’ (underscore). This way there is no possible way for the user code to overlap with the compiler-provided code and libraries.If the compiler defined a variable SYS and the user defined a similar variable; the user variable would be renamed to _SYS so the two would not reference the same data or cause linker issues. ‘C’ does not address the issue between libraries. If you have two libraries that perform different functions but have the same name then you have a serious challenge ahead of you.While I’m not invested in the subject one way or the other I can see the merit and making namespaces optional might create it’s own challenges. I think the answer is going to be some sort of meta approach that will satisfy both sides. Golang’s generate subcommand seems to have some potential in this area although current examples have been fairly trivial string replaces or Stringer code generators.