In a perfect world, yes. But having worked with Python I must say not all Python libraries are PEP 8, and I've more than once ended up with a strange mix of styles.

Nim on the other hand takes a different approach, don't trust anyone else to keep things the way you like it, but rather allow you to use it however you want. This means that if some inexperienced Nim programmer who didn't care to look at the NEP 1 style guide (yes Nim also has a style guide, which says Nim prefers camelCase), but nonetheless wrote an interesting library could still see his library used by others.

Something else to keep in mind is that Nim also has it's own version of gofmt in development, it's called nimpretty.

If everyone is using this tool anyway then style insensitivity will not be a problem, and for those cases where some library uses snake_case instead the code formatter will still be able to format your code completely consistently even if you're using that library. There is no way that gofmt or any other language's code formatter can do that.

Even if somebody deviates from a style guide, the library is still usable. The consumer might just need to use a casing convention they're not using elsewhere.

This is such an incredibly small inconvenience, I have no idea why the Nim language would choose to make identifiers case/_ insensitive. Basic refactoring tools become unnecessarily more complicated.

Just searching for an identifier is a complex regex instead of what should just be ctrl+f.

Nim's roots are firmly in Pascal and Ada, which are both case insensitive; Every editor supports case insensitive search so I don't understand what your problem is with case insensitive identifiers.

"Basic refactoring tools" would just need to replace the case sensitive search with insensitive. Every editor knows how to do that.

If you're talking about the underscore and first letter rules - yes, they're different, and that's why nim includes nimgrep, and support was added for just about every editor under the sun already (Emacs, VSCode, Vim, Sublime, TextMate at the very least). It's still Ctrl+F

I find it a big nuisance to use different casings in my code, but obviously people are different. Most of the type you won't be using the style insensitivity though, so for the most part a simple case-sensitive search will give you exactly what you are expecting. For more complicated things though you have nimgrep, and also nimsuggest (and soon nimlsp) which gives you editor support for finding and renaming identifiers. It really is a much smaller issue than people think it is.

Prior to Py3, not even the entire _standard library_ was PEP8:

https://docs.python.org/2/library/queue.html

Before 2.6, the situation was even worse, with camel-case methods in the threading module:

https://docs.python.org/2/library/threading.html

> The goal was to make it so library authors could write Nim in their own "style" - some prefer snake_case, others prefer camelCase, maybe PascalCase.

That's something that would have appealed to me years ago, but now not so much.

In 2018, I want all the libraries, and all the code I ever look at in a language to follow the same style and naming conventions. If you adapt yourself to that, my belief is that will aid comprehension in the long term.

So I appreciate the language communities which have strong conventions which are followed by the majority, and are encouraged / enforced by the tooling. All hail gofmt and rustfmt!