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

Nim 1.6.2

nim-lang.org

Post reply on HN
Print view View original

121–130 of 162 posts

Re: Nim 1.6.2

#121

Post by k__ »

WesolyKubeczek wrote: post #108
k__ wrote: post #65

Earlier quoted context omitted.

Just the general disdain for crypto here at HN.

I still see more crypto/blockchain adoration here than disdain, although the tables might be turning slowly now. HN users are much like magpies: once an idea shoots up, you can't swing a cat without hitting a zealot. If you are ambivalent or skeptic, you'll be furiously explained into the corner. Then, when the fad fizzes out and its inevitable drawbacks are publicized by more and more sources, the "told you so" camp…

In the web3/blockchain space, HN is known as a prime example of a place you should go to ground yourself, because HN hates it with passion.

Re: Nim 1.6.2

#122

Post by ASalazarMX »

Symmetry wrote: post #118
BiteCode_dev wrote: post #81

Earlier quoted context omitted.

I like Nim, and probably will learn it at some point. But no, Nim is not everything "python should/want to be". The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.

If you have 'myvar' and 'myVar' in some code there are three things you could do. 1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that. 2) These end up referring to the same variable with no error. Nim's solution. 3) These are actually different variables with no error. The common solution. Again, I would prefer (1) but I think that (2) is a safer…

As much as I hate it for correctness, 2 is better than 3 indeed. No sane developer encodes meaning in the case of the name of the variables, in the overwhelming majority of cases it's a typo.

Re: Nim 1.6.2

#123

Post by WesolyKubeczek »

k__ wrote: post #121
WesolyKubeczek wrote: post #108

Earlier quoted context omitted.

I still see more crypto/blockchain adoration here than disdain, although the tables might be turning slowly now. HN users are much like magpies: once an idea shoots up, you can't swing a cat without hitting a zealot. If you are ambivalent or skeptic, you'll be furiously explained into the corner. Then, when the fad fizzes out and its inevitable drawbacks are publicized by more and more sources, the "told you so" camp…

In the web3/blockchain space, HN is known as a prime example of a place you should go to ground yourself, because HN hates it with passion.

You say "web3/blockchain", I hear "homeopathy", "astrology", and "bioenergetic therapy". The HN crowd might be fad-gullible, but stupid-gullible? I don't think so.

Re: Nim 1.6.2

#124

Post by cb321 »

ASalazarMX wrote: post #122
Symmetry wrote: post #118

Earlier quoted context omitted.

If you have 'myvar' and 'myVar' in some code there are three things you could do. 1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that. 2) These end up referring to the same variable with no error. Nim's solution. 3) These are actually different variables with no error. The common solution. Again, I would prefer (1) but I think that (2) is a safer…

As much as I hate it for correctness, 2 is better than 3 indeed. No sane developer encodes meaning in the case of the name of the variables, in the overwhelming majority of cases it's a typo.

In the C world ALL_CAPS very often signify preprocessor macro identifiers (or some other "class" of identifier), but, yeah..they may all be "insane". ;-)

Re: Nim 1.6.2

#125

Post by adamrt »

klibertp wrote: post #111
adamrt wrote: post #106

Earlier quoted context omitted.

Cool thanks for the info. Nim having selective imports solves any annoyances I would have. But you mentioned all the reasons it was ok in Nim. But the answer is always that the compiler knows. That isn’t why I personally dislike this type of import. I dislike it as a user. I find it super annoying not knowing where an identifier is coming from. I love having ‘fmt.Printf()’ instead of ‘Printf()’. Trivial example I kno…

There's a reason why wildcard/selective[1] imports are favored in Nim. It's because of the uniform function call syntax[2]. In short, this: split("a string", " ") is exactly the same thing as this: "a string".split(" ") `split` here is a normal function, not any kind of method. This means that you can chain normal functions as if they were methods on objects: "a string".split(" ").join("\n") now, if you imported modu…

Great explanation, that makes total sense.

Thanks for giving the insight.

Re: Nim 1.6.2

#126

Post by auxym »

spaniard89277 wrote: post #74
FridgeSeal wrote: post #72

Nim is everything Python and Go should be/want to be, as far as language features and semantics go (haha). It has their easy-to-learn properties, but has a better type system, the generics system and macros are arguably more useful, and more usable than what is offered in either language. It deserves far more attention than it currently gets.

As someone learning programming, should I try nim for my first compiled language, instead of C++? I know it's likely harder to find answers in the Internet, but at the same time it looks easier, coming from Python and JS. If nim picks up pace in a few years and I already have a sense of it, it may be a good for prospects too.

I'd recommend it. The syntax should make you feel at home if know python, though the type system (and std lib) does make it feel like a very different language once you use actually use it.

One advantage over C++ is that you don't need to learn make, IDEs or a complex build system. The nim compiler and the nimble package manager just takes care of building for you. "nim c main.nim" and off you go, ending up with a single executable, no matter how many imports, modules, etc you have.

I do recommend this as a gentle introduction: https://nim-by-example.github.io/ and recommend you use VS Code with the Nim extension by saem.

Re: Nim 1.6.2

#127

Post by posharma »

posharma wrote: post #3

Genuinely curious - why should I care about Nim? There are already a plethora of general purpose languages (both compiled and interpreted). Also, is anyone using Nim today? What's the adoption?

Not sure why I'm getting downvoted for asking a genuine question. The objective is not to deride Nim in any way.

Re: Nim 1.6.2

#128

Post by CodesInChaos »

goodpoint wrote: post #114
MrBuddyCasino wrote: post #53

Earlier quoted context omitted.

I suppose the makers of Nim named that flag for a reason - giving up memory safety by disabling bounds/overflow checks should be never be the default for networked software in a production setting, so benchmarking in that mode would paint an unrealistic picture. What you want are comparable compiler flags across languages, say "optimized for performance, yet retaining safety" and "go as fast as possible and disable a…

"disable all brakes" is misleading. All the basic memory safety stays, static typing is still there, non-debug assertions are still checked. Removing debugging features is reasonable for such benchmarks, especially if comparing with languages that don't have them.

Another poster claimed it disables bounds checks, you claim it still offers basic memory safety. That sounds like a contradiction to me.

Re: Nim 1.6.2

#129

Post by ASalazarMX »

cb321 wrote: post #124
ASalazarMX wrote: post #122

Earlier quoted context omitted.

As much as I hate it for correctness, 2 is better than 3 indeed. No sane developer encodes meaning in the case of the name of the variables, in the overwhelming majority of cases it's a typo.

In the C world ALL_CAPS very often signify preprocessor macro identifiers (or some other "class" of identifier), but, yeah..they may all be "insane". ;-)

OMG, what if C did significant case because of that? I mean, it's fine to write "#import", why didn't K&R use a special syntax for macros, like $MACRO or something and left the uppercase as a convention?

Re: Nim 1.6.2

#130

Post by BiteCode_dev »

Symmetry wrote: post #118
BiteCode_dev wrote: post #81

Earlier quoted context omitted.

I like Nim, and probably will learn it at some point. But no, Nim is not everything "python should/want to be". The name case insensitivity and the implicit imports on the global namespaces are perfect examples of stuff that are better in Python.

If you have 'myvar' and 'myVar' in some code there are three things you could do. 1) The compiler gives you an error, this would be my preferred solution though I'm not aware of any language that does that. 2) These end up referring to the same variable with no error. Nim's solution. 3) These are actually different variables with no error. The common solution. Again, I would prefer (1) but I think that (2) is a safer…

The 3rd solution is terrible, because:

    ForMid = 4 # padding for middle box in px
And:

    FormId = 3 # ID of the form in the user process
Should definitely not be resolved as the same variable.
Post reply on HN