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

141–150 of 162 posts

Re: Nim 1.6.2

#141

Post by silok »

DangitBobby wrote: post #140
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.

player = Player() all the time in Python. date = new Date() all the time in JS. Those are just the two languages I spend the most time in, but, but I'm sure it's trivial to find numerous examples of cases carying meaning in case-sensitive languages. Especially ones which encourage camel casing.

There is a difference between variables and types.

For instance, in C#, with capital-case convention for variables, it is common to give a variable the same name as the type.

eg `public Player Player;`

Re: Nim 1.6.2

#142

Post by jokoon »

amedvednikov wrote: post #97
jokoon wrote: post #30

Earlier quoted context omitted.

If I would pick one, I would pick Zig. The language that is missing is a simple language that can work well with C or C++, compiles fast, is easy to read, has a good lib, etc. There are not enough non-GC languages that are statically compiled. I really, really want a pythonic, statically compiled language. I don't want templates, OOP, abstract stuff, just A C-like language, more readable, with good syntactic sugar. M…

> The language that is missing is a simple language that can work well with C or C++, compiles fast, is easy to read, has a good lib, etc. https://vlang.io ?

it has a GC

Re: Nim 1.6.2

#143

Post by beagle3 »

DangitBobby wrote: post #139
BiteCode_dev wrote: post #130

Earlier quoted context omitted.

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.

The only thing worse than 3 is 2.

I don’t remember the exact options, but there’s a way to make Nim emit warnings (and perhaps errors) for inconsistent capitalization.

It isn’t the default, though.

Re: Nim 1.6.2

#144

Post by beagle3 »

shirleyquirk wrote: post #69
kajiryoji wrote: post #63

I see nim being compared with the same languages as zig. Does anyone has any opinios regarding how nim vs zig?

zig's IR is llvm, while Nim's IR is C/C++/javascript. C supports more platforms than llvm. zig: no macros plz nim: macros are amazing

FWIW, there’s nlvm which is a fork of Nim that emits LLVM IR directly.

Re: Nim 1.6.2

#145

Post by MrBuddyCasino »

shirleyquirk wrote: post #55
MrBuddyCasino wrote: post #48

Earlier quoted context omitted.

I've digged some more, and indeed in numeric tests Nim is often close to C. Its hard to find good data though, with documented compiler flags and recent versions.

There are definitely slow bits of the Nim stdlib; json parsing for example. String-heavy code is easy to make slow in Nim, too.

Yes the benchmark against Crystal was heavy on strings (json & base64) and Crystal seems to do better there. Whats the reason, Nim using refcounting?

Re: Nim 1.6.2

#146

Post by beagle3 »

qalmakka wrote: post #70
formerly_proven wrote: post #15

Earlier quoted context omitted.

I was a interested in Nim until I learned that getBlochenAngle and get__B_L_O_C_H_E_N_ANGLE are the same identifier. > https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

This is quite bad. Relying on uppercase/lowercase equivalences in a Unicode world is by definition a code smell, no matter if they force the comparison to be based on ASCII. This whole ordeal causes any sort of issue if Unicode letters are allowed, because they will pass through `toLowerAscii` untouched and it is bound to cause confusion or to force people to avoid using Unicode in identifiers altogether. Case insens…

Keywords are in English, and 99% of identifiers in all code I met are too, even when comments are in French or russian.

Pascal and old basic (among other languages) have been case insensitive for decades, and that has not been a problem.

In UI, you are by all means correct. But code is a formal language that happens to be expressed in Latin letters. APL is the only real language that doesn’t impose a western character set.

Re: Nim 1.6.2

#147

Post by 1_player »

BiteCode_dev wrote: post #81
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.

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.

Yes, you have listed the two things that have stopped me from giving Nim a chance. I especially dislike the global namespaces, it makes it very hard to understand where a function is defined.

Re: Nim 1.6.2

#148

Post by k__ »

WesolyKubeczek wrote: post #123
k__ wrote: post #121

Earlier quoted context omitted.

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.

q.e.d.

Re: Nim 1.6.2

#149

Post by cb321 »

beagle3 wrote: post #143
DangitBobby wrote: post #139

Earlier quoted context omitted.

The only thing worse than 3 is 2.

I don’t remember the exact options, but there’s a way to make Nim emit warnings (and perhaps errors) for inconsistent capitalization. It isn’t the default, though.

The options are nim c --styleCheck:hint --styleCheck:usages (you need both). Though not on by default you could put it in your config.nims or nim.cfg's to make it on by default for you or for your code.

Re: Nim 1.6.2

#150

Post by narimiran »

DangitBobby wrote: post #140
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.

player = Player() all the time in Python. date = new Date() all the time in JS. Those are just the two languages I spend the most time in, but, but I'm sure it's trivial to find numerous examples of cases carying meaning in case-sensitive languages. Especially ones which encourage camel casing.

`player` and `Player` are different in Nim. Ditto for `date` and `Date`.
Post reply on HN