This is a reasonable concern, but after having used Nim for a couple of years I have never run into this as an actual issue. The benefit of being able to keep your entire program in one casing style outweighs these concerns. For that is the purpose of this style insensitivity, to allow you to use a library using snake_case in a project using camelCase and the other way around. And after having used Python with mixed case libraries I must say it is a good solution.

Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.

The big issue for me is it interferes with code search tools. I like being able to use ripgrep to find all uses of an identifier. That becomes hard with style insensitivity.

That is also a valid concern, with nimsuggest (and soon nimlsp) you will be able to easily find every instance in your editor (as well as rename them). For searching through files however nimgrep is probably your best bet, but that might break up your workflow. In my experience this hasn't been that much of an issue. Typically you write all your identifiers in the same style always, so most of the time you'll find what you need with just a simple grep.

well, yes, that's why nimgrep exists.

grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.

It seems crazy to me that people are so annoyed that their libraries have different style that we have to have additional tooling to make code search simple for the end-user.

You don't _need_ additional tooling. You can get by with just searching as normal, it's not as if people's code bases are filled with random conventions or random case variations...

style insensitivity WILL lead to typos that don't get caught. Someone will change the casing somewhere. Therefore you must always search with style insensitivity in mind.

Most people use completion anyways and it prevents this problem. Also, you can lint the code.

Styles are religions, including - in some organizations - the threat of excommunication if you don’t practice the one style.

I don’t know how atheistic style looks, but Nim is style agnostic - everyone can practice their religion and they all get along. C, Python, and the real world - not so much.

"Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler."

This one point is always worth considering when deciding on user-facing portions of technology.

That's bad naming, if those had the same type, that would lead to subtle hard to track bug because a dev used one pid instead of pId.

Not in any typed language. Its instantly called out as an error.

But it's so hard to read: I admit a good IDE might help, but maybe it's not bad to prevent this on lang level.

that's why I said if those had the same type ;)