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

31–40 of 116 posts

Re: Nim Version 1.6.6 Released

#31

Post by nimmer »

Symmetry wrote: post #23
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.

This is exactly what Nim does. If you try to define both my_var and myVar it will error out.

The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.

Re: Nim Version 1.6.6 Released

#32

Post by nimmer »

RafaGC wrote: post #25
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.

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.

You can use --styleCheck:usages or a linter to ensure that the style is uniform.

Re: Nim Version 1.6.6 Released

#33

Post by tyingq »

GordonS wrote: post #27
tyingq wrote: post #16

Earlier quoted context omitted.

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?

Hard to say, since we have no idea how the antivirus vendors are identifying nim. Maybe there's something about the fact that nim compiles to C which is then usually compiled by mingw? (You can use compilers other than mingw, but it's the default).

Mingw might have a higher weight for "this is malware". Then you combine that with nim generating code that's common across most nim binaries (the GC, boilerplate symbols, etc).

Then there's perhaps not enough positive signals to offset that, since there's not yet a wildly popular windows app written in nim.

Re: Nim Version 1.6.6 Released

#34

Post by derbOac »

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.

I love Nim and wish it would take off and become as common as python. Case sensitivity isn't affecting that for me. But it still really irks me.

There are times when you might want to use the same variables in different cases (math), and the assumption that you wouldn't seems like nannying to me.

Also, fundamentally, it's a very english-centric view and encourages that by default. I'd prefer case assumptions weren't implicitly baked into the language at a basic level.

I guess for me I just feel like a character is a character and I don't want the language telling me I should view it differently.

Re: Nim Version 1.6.6 Released

#35

Post by [deleted] »

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

[deleted]

Re: Nim Version 1.6.6 Released

#36

Post by snowcorn »

GordonS wrote: post #27
tyingq wrote: post #16

Earlier quoted context omitted.

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?

Yes, but it's not like this only happens with small/new languages. Even today, Go-lang binaries will often get detected by various Windows anti-malware software. They even have a section in their FAQ about it [0].

Also, in Hare's specific case, it doesn't _really_ matter as they will never support Windows or MacOS [1], and there isn't a significant presence of anti-malware software on linux distros.

[0]: https://go.dev/doc/faq#virus

[1]: https://harelang.org/platforms/

Re: Nim Version 1.6.6 Released

#37

Post by nimmer »

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.

This is the opposite of a footgun. Imagine if DNS was case sensitive and GMAIL.COM belonged to a domain squatter.

Nim prevents that. It's that simple.

Re: Nim Version 1.6.6 Released

#38

Post by rosetremiere »

A bit off-topic, but I'd like to see a language à la rust+gc, with pattern matching, traits, and the functional stuff rust got right, but without all the worries of lifetimes, and maybe some easier trait management (function signatures become very ugly imo).

I've heard the claim that lean is going in this direction.

Re: Nim Version 1.6.6 Released

#39

Post by the_duke »

ZoomZoomZoom wrote: post #8

For all those who are really interested in the language and have at least a small amount of experience with it already: Nim is ripe for contributing! While the main team works on bigger things drawing v2 closer, there's still lots of issues of various magnitude and lots of housekeeping bits that can be done while getting yourself acquainted with the project's structure. Here's a few links for your consideration: * ht…

What's on the roadmap for v2?

Re: Nim Version 1.6.6 Released

#40

Post by Symmetry »

nimmer wrote: post #31
Symmetry wrote: post #23

Earlier quoted context omitted.

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.

This is exactly what Nim does. If you try to define both my_var and myVar it will error out. The benefit is to avoid confusing variables or procs named my_var, myVar and myvar.

If you define them both yes, but you're still free to use them both.

  var my_var = 1
  myVar += 1
  echo(my_var)
Will happily compile and give you 2. I'd prefer an error in that case because while I'm not liable to make that mistake but I could easily mistype long_variable_name as long_variablename without noticing and then cause myself problems when I try to grep.
Post reply on HN