Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim Version 1.6.6 Released

nim-lang.org

Post reply on HN
Print view View original

21–30 of 116 posts

Re: Nim Version 1.6.6 Released

#21

Post by rich_sasha »

PMunch wrote: post #12
rich_sasha wrote: post #4

Earlier quoted context omitted.

It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.

You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.

I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know.

I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot".

Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.

Re: Nim Version 1.6.6 Released

#22

Post by styeco »

tyingq wrote: post #16
styeco wrote: post #7

I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…

It's not clear to me what they could do. In the thread you linked, it's not just the binaries of the various nim executables, but also user generated binaries. And it appears that even signed binaries are getting flagged by some vendors. I'm guessing the issue is that some malware writers started using nim, and the antivirus vendors then decided to make heuristics that detect nim generated binaries and call it malwar…

I hope I didn't come off as too aggressive in my original post, I'm not trying to demand anything, or trying to act like I know anything they don't, I most certainly do not. I just love the language so much, I wish I could use it more. The linked issue doesn't show any traction, and other languages used for malware don't have this problem, so I (probably incorrectly) presumed there was a lack of interest to solve this. I apologize if I came off as demanding.

Re: Nim Version 1.6.6 Released

#23

Post by Symmetry »

WithinReason wrote: post #2

There is a question of getting rid of style sensitivity in Nim 2: https://news.ycombinator.com/item?id=31238375 This whole question generates a lot of controversy for some reason

My ideal would be to simply not allow having my_variable and myVariable in the same namespace but given that you can do that in essentially every language I sort of prefer that they have to refer to the same thing.

Re: Nim Version 1.6.6 Released

#24

Post by PMunch »

rich_sasha wrote: post #21
PMunch wrote: post #12

Earlier quoted context omitted.

You must remember that Nim is a statically typed compiled language with support for distinct types etc. This means that you wouldn't be able to call the wrong procedure if you didn't provide it the right types. Besides, not allowing similarly named but differently cased identifiers causes less ambiguity, not more.

I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know. I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot". Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.

Yeah I can see how it might seem scary. It takes you out of your comfort zone and it's easy to start thinking uncomfortable things have to be scary. I've been using Nim for a couple of years now, and I've never run into a safety issue with it.

Re: Nim Version 1.6.6 Released

#25

Post by RafaGC »

nimmer wrote: post #6
rich_sasha wrote: post #4

Earlier quoted context omitted.

It actually is something that gives me pause for thought. In my field of coding (finance) ambiguity is terrifying and eventually you get it wrong. Maybe it's not so bad in practice, but looking from the outside, I think... really? To be specific, case-insensitivity doesn't bother me, but the automatic conversion from camel-case to snake-case... very much so.

Style insensitivity is a safety feature, not a problem. It prevents bugs where a developer mistakes one variable or proc for another having similar names. For example in another language you might have variables isReady, isready, is_ready and use the wrong one, leading to a bug. Nim does not allow defining 3 different variables like that.

For me the biggest potential issue seems grepping probably. I guess that some other tool than ag, grep, etc has to be used for searching.

Re: Nim Version 1.6.6 Released

#26

Post by GordonS »

PMunch wrote: post #9
styeco wrote: post #7

I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…

We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.

Are Nim Windows binaries signed with Authenticode?

If not, it's possible to get reasonably priced code signing certificates.

Re: Nim Version 1.6.6 Released

#27

Post by GordonS »

tyingq wrote: post #16
styeco wrote: post #7

I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…

It's not clear to me what they could do. In the thread you linked, it's not just the binaries of the various nim executables, but also user generated binaries. And it appears that even signed binaries are getting flagged by some vendors. I'm guessing the issue is that some malware writers started using nim, and the antivirus vendors then decided to make heuristics that detect nim generated binaries and call it malwar…

Yikes, does that mean scumbags could effectively torpedo any new language, like Zig and Hare, for example?

Re: Nim Version 1.6.6 Released

#28

Post by rich_sasha »

PMunch wrote: post #13
rich_sasha wrote: post #11

Earlier quoted context omitted.

If it stopped at disallowing the similar names, I'd think it is quirky but fine. A little unusual but harmless, maybe even helpful as you say. But that I can, and other people's code can, refer to the same thing by different names, is a bridge too far. Like I say, it won't deter me from trying the language, probably (I've been saying it for a while), but certainly doesn't make me more keen to try it.

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 c…

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...

Re: Nim Version 1.6.6 Released

#29

Post by rich_sasha »

PMunch wrote: post #24
rich_sasha wrote: post #21

Earlier quoted context omitted.

I mean, it really might be fine. I've written maybe 20 lines of Nim in my life, what do I know. I just look at it and see a foot and a gun pointing at it. The arguments for it sound to me like "it's fine, there's a safety and a clever mechanism that prevents shooting yourself in the foot". Maybe it's all fine, but I'd for one feel more comfortable if the gun wasn't pointing at the foot in the first place.

Yeah I can see how it might seem scary. It takes you out of your comfort zone and it's easy to start thinking uncomfortable things have to be scary. I've been using Nim for a couple of years now, and I've never run into a safety issue with it.

I'm all up for new, exciting, slightly scary but promising concepts in programming. Rust's borrow checker. Python extremely-dynamic syntax. Nim's "Python syntax, native code, GC" premise.

Exploring different ways to write the same name does not excite me.

Re: Nim Version 1.6.6 Released

#30

Post by guiriduro »

PMunch wrote: post #9
styeco wrote: post #7

I wish they would take the antivirus issue on Windows more seriously https://github.com/nim-lang/Nim/issues/17820 This issue alone means I can't use it at work, and I haven't put much time and thought into Nim as a whole because I could only use it in private toy projects. I understand it's mostly the AV vendors fault and the devs shouldn't have to worry about a problem they haven't caused, but for me, this grinds re…

We take it very seriously, but there isn't a whole lot we can do unfortunately. Apart from reporting false positives the only venue we could pursue is applying obfuscation practices used by actual viruses. This of course has its own slew of issues.

Yep, I mean, if the virus defence community took the same blanket, lazy approach with C and C++ compilers because viruses can be written in those, too (shock horror!) they'd be shutdown by some big players very fast.
Post reply on HN