If you define them both yes, but you're still free to use them both.
var my_var = 1
myVar += 1
echo(my_var)
Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
Searching has never been a problem for me in years of using Nim but there is `nimgrep` bundled for style insensitive search. Also I'm no RE wiz, but seems like RE might help if it came down it.
Just to stress myself as an anecdote though, I have years in the language and it hasn't come up yet for me, and I've never needed to use `nimgrep`.
I love Nim and wish it would take off and become as common as python. Case sensitivity isn't affecting that for me. But it still really irks me.
There are times when you might want to use the same variables in different cases (math), and the assumption that you wouldn't seems like nannying to me.
Also, fundamentally, it's a very english-centric view and encourages that by default. I'd prefer case assumptions weren't implicitly baked into the language at a basic level.
I guess for me I just feel like a character is a character and I don't want the language telling me I should view it differently.
The nice thing about being able to run others people code with your style is that your entire codebase stays in one consistent style. You don't run into issues like in other languages where one library author has done some dubious style choices which then propagates into your code. This was always a pain-point for me in Python.
And I'm not certain what scenarios you envisage where this would be an issue, why do you care how other people call your functions?
Dubious decisions in third-party libraries are common, but camel vs. snake case is probably not the main...
I care about how a function is called because so much tooling around programming is effectively grep. I can grep for a function name and get a pretty good idea where it is called. There's also a million variants of grep - git grep, unholy regular expressions (recently I used one to find all instances where foo is called with exactly 2, not 3 params, in Python), IDE plugins and so on. GitHub search? Google search for exceptions?
IIRC Nim comes with some kind of "nim-grep" that is camel-vs-snake-aware, but that doesn't fix all the other tools.
The minor gripe, additionally, is that you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager". Now... are these colliding? Or not, because the first letter _is_ case-sensitive? What does "fooManager" map to then?
In my utility function, this feature gives me nothing but concerns. But then again, I'm not (yet?) a user the Nim community provides for so... <meh>
> you often have quasi-singleton classes called "FooManager", then a single instance called "foo_manager".
Like this:
type FooManager = object
var foo_manager: FooManager
> Now... are these colliding? Or not, because the first letter _is_ case-sensitive?
Well as you correctly reason, the first letter's case distinguishes them.
Convention in the language is for types to start with a capital letter and instances start with a lower case letter.
> What does "fooManager" map to then?
It maps to the `foo_manager` instance because underscores are ignored, they're just for you. By the way, underscores are exceedingly rarely used in Nim code because they're not semantically significant, why bother.
Still, if you like you can use them in your code, and others can choose not to as they want. Clashing identifiers are a compile error so no worries.
> other people's code can, refer to the same thing by different names
They can but the compiler will just tell you it's ambiguous and to qualify it. Also bear in mind Nim has very strong static typing, so for things to clash they also have to have exactly the same type, otherwise no worries.
You can even rename symbols on import or force qualification for all symbols, but I've never needed to do either in years of heavily using the language.
I think better phrasing would indeed be something like "several former core developers" - of course we can't really measure up to the size of the original community, and don't yet have any paid developers (like Araq and narimiran [1] in the mainline - although since the end of September there were not a lot of activity on their part as well - [2] ~30 commits (~23 that are marked `[backport]`) and even less [3] for narimiran)
The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.