> You can write M_ya_wse_s_omEv_ar in any language, yes?

Yes? That doesn't mean that we should add features that encourage that kind of confusion. Especially not when they, again, help nobody and bring no actual benefit.

(Not who you responed to)

Just to argue against there being no benefit, I have a cognitive impairment that occasionally puts me in an altered state, a delirium to varying degrees. camelCase is much more difficult to read at that point, so I can get confused ridiculously easily. I tend leave a bunch of comments and then step away, but sometimes I can work well through it; things like horrendous variable names/regexs will throw me. I default to snake_case but compile over when I share the code.

This is my unique situation and predilection to being able to read one form more easily than another, but it does indeed help me.

That's understandable, but doesn't that cause the same issues when reading documentation or third-party code?

I can back away from those while leaving the tabs open and be not too confused coming back, not having temporarily broken them. When I'm in the middle of refactoring especially though, getting a seizure and trying to back away without jumbling the house of cards is a lot easier with whatever pattern recognition I have around snake_case.

Edit: curious, have a preference besides consistency for cases?

If anything, it encourages a consistent style, since you don't have to use whatever style your dependency uses.

Also, if you work with people that name things like that, it's not really Nim's fault?

Somehow pretty much every other ecosystem can just pick one style and stick to it, negating the problem entirely.

I have never come across a Rust project that didn't use snake_case, or a Java project that didn't use camelCase.