Hacker News Reader

Comment by hetman | Hacker News Reader

The language has a lot going for it, however, its chosen scheme for identifier resolution undermines a lot of existing tooling people are used to using with other languages, which has kept a lot of people (including my self) away from seriously considering it.

View on HN

In practice its identifier resolution[1] has little impact on enjoyable and successful software development with Nim, even if it takes a little getting used to. nimgrep[2] is bundled with the compiler, but you may or may not make much use of it depending on your editor and development setup.

[1] https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

[2] https://nim-lang.org/docs/nimgrep.html

I really like Nim but this identifier resolution seems to be the only topic that comes up against Nim, and I really doubt this "feature" is worth the consternation when pitching the language to someone new. I wish the Nim developers would just admit that it is not worth the effort and make it opt-in instead of opt-out.

Personally, I agree, but the Nim lead dev looked into it and declared it "unreasonably hard to implement with unknown effects for template instantiation"

    https://github.com/nim-lang/RFCs/issues/547#issuecomment-1879179448

I wish he had detailed the problems more as I think opt-in to insensitivity at import time with some kind of compile-time error for ambiguity is The Better Answer. { For then Nim would not be taking away ident choice from (many) creators in order to support the ident-pickiness of (many) consumers. It's hard to measure/know/forecast, of course, but I suspect the 2nd "(many)" (the number of such very picky consumers) is low in absolute terms in spite of usually high name-consumer/name-producer ratios. A huge fraction of people just go along with whatever the name-producer did, a small fraction complain loudly, and an even smaller fraction would care enough to opt-in to insensitivity if such were available and, say, sometimes caused trouble. There is also a "broader system" aspect of the producer-consumer ratio changing as a prog.lang goes from dark horse/obscure/niche to popular (with a lot more consumers). }

All this said, I would reinforce what others here have said - the property is not actually as onerous in practice as you might imagine. So, it is really worth suppressing knee-jerk reactions to this one feature and giving the language a try, just with `nim c/cpp/js --styleCheck:usages` or whatnot.

When I first started using Nim I was a snake_case person, and I was also put off by camelCase as the preferred style. Fast-forward a few years and I got used to the camelCase and moved on, focusing on what I want to build instead of personal style preference.

The identifier case style issue almost never comes up in practice. My advice: if you really want to give Nim a chance, don't get hung up on this issue, just adopt the community convention and enjoy the language.

Conventions really don't bother me, I'm happy to adapt. Even case insensitivity, while not so common on Unix, can generally be dealt with. Underscore insensitivity though is kind of wild and breaks a lot of things (and a case insensitivity exception for the first character only, while tacitly admitting there really is a problem here, is just adding even more inconsistency).

I have never heard any serious criticism about this feature for anyone actually trying the language.

When there was a proposal to remove it just for the sake of this kind of arguments I actually took time to think about it and I actually ended it liking it.

Can you elaborate more here? I don’t know anything about Nim.

I assume the grandparent is referring to Nim’s insensitivity to underscores and capitalization in naming [1]. I’ve found this a tad annoying as well and I imagine I’d find it more troublesome in production use—I use ripgrep often to search codebases.

[1] https://narimiran.github.io/nim-basics/#_variable_declaratio...

Reply on news.ycombinator.com