I am a lurker with general interest in programming languages. I would sincerely appreciate if any veterans here or @Araq could provide links (forum or outside) that discusses the reasoning behind the design decisions on the nim language grammer or code conventions.
Taking import for example (but not limited to it only)
I was looking at the unix socket example at https://github.com/nim-lang/Nim/blob/devel/examples/unix_socket/server.nim
Coming from python and java background, i found implicit imports (like c's include) of module exports troubling (newSocket and constants in above example). If there are texts that discusses
import net vs import net.AF_UNIXThanks
Elaborating on ambiguity.
import libfoo
import libbar
open() # open is coming from foo.
Later down the road libbar decided to add proc open(). Second developer (Not the original author of above code) needed to use the latest version of libbar , in some other part of the code. Compiler might report the ambuigity and be done. But the burden of namespace resolution falls on second developer's head to figure out open() was added to by libbar's new version and the open() was meant to be from flibfoo.
From libbar's point of view, addition of new optional elements in api becomes a breaking change requiring major version change.
But i don't think that's the fault of the language if you define a proc with a name as generic as "open", or maybe it should foresee how people behave, which is something to think. Araq used to say that he can't fix people's habit, maybe he is more on the side of providing freedom in spite of problems like the one you described.
On the other hand, nim does sopply of certain tools to avoid these problems, for example:
from libfoo import nil
from libbar import nil
libfoo.open() # Now you are forced to use the full name.
Maybe there could be a compiler switch to make it the default.
There are ambiguities from time to time. But as soon as they appear, the compiler is so nice to tell me about them. There is a compile error that is usually very easy to fix. Unlike for example C++, the c++ linker is used to throw stuff away that have been defined several times. That has to do with the fact that in header files types have to be defined a lot, and the linker is forced to throw a lot of stuff away, sometimes c++ silently throws stuff away that should have better been reported. And then you have a very very horrible job in finding the result. So just because name collisions are something very horrible in c++, it doesn't mean that they cause the same kind of problem in Nim.
Not knowing where a method comes from could be a problem when your only tool to read and write the sourcecode is notepad. But generally development tools can tell you where a function comes from in case you don't know it. If this is constantly a problem, then there might be a problem in the naming conventions in the used libraries.