One of the fundamental truths I've learned over my decades of designing software for consumption by other developers is if you enable them to do the stupid thing, they will do the stupid thing. Expectations aren't really anything meaningful without enforcement.
Yes, that's generally true, but I think irrelevant to this specific question.
Most languages do not enforce a naming convention. Yet, Java projects almost always follow the same (horrible IMHO) standard, Python program almost always follow one of two standards (underscore_lowercase for everything, or the same with CamelCase for classes), C programs follows one of 20.
Even though Java & Go programmers can do the stupid thing in this specific instance, they generally don't, even without enforcement.
A C/C++ project usually has a salad of coding conventions, because each of the different libraries (e.g. Qt, GSL, libc/libm) has a different one - regardless of how conformant developers are to their official style guide.
Nim actually has an advantage in this respect: It allows you to maintain a uniform style in your codebase, even though it is expected to call out to different styled ones; though I agree a "nim --verify_style=blah_blah" would have been a useful option.
Personally, I think that's misguided - if you're using a library, it is better to use the original style (whatever it is) so you don't have to translate back-and-forth from examples, forum discussions, etc. But to each his own.
Treating different conventions as equivalent, though, is an excellent of ending with code that looks visually different (library A can still use Capitalized_with_underscore identifiers everywhere while library B relies on lowercase everywhere, same with Bob and Alice working in the same codebase) but is the source of surprising behaviours.
If you want to enforce style conventions, either make them mandatory at the language level or write gofmt. The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.
It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name). Nim just feels like taking this a little farther - making '_' the lower case version of no character. Not at all a big jump from Pascal, and pascal is not confusing.
In fact, experiments teaching Python to non-programmers indicated that the two biggest confusing issues were case sensitivity and integer division[0].
> The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.
That sentiment is very often expressed by people coming from C/C++/Java about Python's indentation (What? Whitespace is significant to semantics? That's awful!). And you know what? I know not of one person who actually tried Python and actually had a problem.
[0] http://www.alice.org/ - can't find the rational description now; but I was following its development, and IIRC those were the two biggest stumbling blocks in Python (which were therefore changed in Alice)
