Hacker News Reader

Comment by pjbk | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com