Some of us work in regulated industries where coding standards are not strong suggestions but unconditional requirements. Unambiguous names and identifiers precludes the use of Nim as a tool in any of those fields just by an improper design decision. Sounds very bad and completely avoidable to me.

There is a reason old languages were many times case insensitive but not anymore.

I'm confused how unconditional requirements would preclude Nim? If anything, this allows you to use your "house style" internally and still interact with libraries who don't. I haven't used Nim, but I imagine that was the intention because that's when I've had to mix styles in other languages. To keep your own code consistent you just need your own linter/formatter, which if you have a strict style you're probably already doing.

Do they preclude using e.g. NTFS (case preserving but insensitive) in your project for that reason? NTFS vs. ext4 has exactly the same kind of issues (and it has in fact caused security issues in cross-platform software.

Regardless, this does not preclude the use of Nim any more than a regulation saying "do not use preprocessor macros" preclude C because you might accidentally use #define. It just means you have to verify that you adhere to those regulations. Here's one tool[0] you can use to make sure your unconditional requirements are satisfied.

Nim would probably be precluded anyway based on age and popularity, and rightly so for tightly regulated industries -- but given some time, assuming it does grow in popularity, there is no inherent reason Nim would be precluded from any project that allows e.g. C++, Java, JavaScript or Go.

[0] https://github.com/FedericoCeratto/nimfmt

Please provide some examples of how Nim is not compatible with some coding standards.

> In Nim the compiler tells you that you are redefining the same variable in 3 different places and you can go and give them more meaningful names.

If this is the goal, there are many alternative ways to solve this problem, making the language case insensitive is a pretty big hammer.

See gtrs' comment above[0]. Why do you assume case sensitivity is "the right thing"?

[0] https://news.ycombinator.com/item?id=21403387

I’m confused so you are saying the language where using StartDate one place and start_date another without issues is better than the ones that error out because you used different names? Seems like a recipe for disaster like the early days of IE that would try to render broken markup, which led to the web being littered with broken webpages that relied on IE specific quirky attempts to save them in order to be consistent.