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

11–20 of 116 posts

Re: Nim Version 1.6.6 Released

#11

Post by rich_sasha »

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.

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.

Re: Nim Version 1.6.6 Released

#12

Post by PMunch »

rich_sasha wrote: post #4
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

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.

Re: Nim Version 1.6.6 Released

#13

Post by PMunch »

rich_sasha wrote: post #11
nimmer wrote: post #6

Earlier quoted context omitted.

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.

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 care how other people call your functions?

Re: Nim Version 1.6.6 Released

#14

Post by PMunch »

christophilus wrote: post #5
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

It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.

Why though? With this feature you're able to import a library in a style you don't like and still be able to use it in whichever style you prefer.

Re: Nim Version 1.6.6 Released

#15

Post by sausage_dog »

christophilus wrote: post #5
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

It’s probably my biggest gripe with nim. I hope they drop it and provide a tool like gofmt to get everyone’s code into the same style.

Nim has a tool called nimpretty similar to gofmt

Re: Nim Version 1.6.6 Released

#16

Post by tyingq »

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

Re: Nim Version 1.6.6 Released

#17

Post by PMunch »

cumshitpiss wrote: post #10

Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus

Well it depends a bit on your usecases. Nim certainly has a stricter type system, and since it is compiled you can be fairly certain that a program you have compiled won't suddenly start to misbehave (e.g. no JavaScript leftpad issue since it won't pull in libraries on runtime). The packaging system is fine for most purposes, and it recently got better with the introduction of lock-files. Once you get comfortable with the standard library and your favorite packages it's also very fast to write, maybe even more so than Python because it has less boilerplate.

As for numpy there are libraries that allow you to work with Python from Nim, and vice-versa. Not entirely sure how well they work for numpy as I haven't tried that myself. But there are also packages which does similar things in Nim. However packages will probably be your biggest hurdle when converting stuff to Nim. The Nim ecosystem is definitely smaller than Pythons, so it's a bit hit-or-miss if it has the packages you need for your specific usecases. You are more than welcome to join the Discord/IRC/Matrix room and ask around though.

Re: Nim Version 1.6.6 Released

#18

Post by JackC »

rich_sasha wrote: post #11
nimmer wrote: post #6

Earlier quoted context omitted.

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.

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.

Not a nim user, but I wonder if the styleCheck:error or styleCheck:usages compiler flags would do what you're asking for.

Re: Nim Version 1.6.6 Released

#19

Post by PMunch »

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…

This is pretty much it, malware was written in Nim, vendors started fingerprinting those binaries but didn't include any/enough non-malware binaries. This means that the fingerprint is more "this program is written in Nim" and less "this is malware written in Nim".

Re: Nim Version 1.6.6 Released

#20

Post by cardanome »

cumshitpiss wrote: post #10

Hi, is Nim a good replacement for python? I write a lot of scripts, but I find that python can get cumbersome to maintain. I'm looking for something with stricter typing and a sane packaging/directory system, but also easy/fast to write. If Nim can work with numpy it's a plus

I think out of the bunch of new system programming languages it sure is the most friendly towards users coming from dynamic programming languages.

My nim solutions were actually more concise than my JS code when doing some Advent Of Code puzzles.

And it has nimpy which is a bridge to the Python world though I haven't used it personally.

The only downside I can think of regarding nim is that the standard library is OK-ish I guess but not great. Still needs some work but I think they are aware of it.

Post reply on HN