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

41–50 of 162 posts

Re: Nim 1.6.2

#41

Post by lifthrasiir »

goodpoint wrote: post #32
trymas wrote: post #20

Earlier quoted context omitted.

Agreed. First world problem, though I've tried couple of times to get into nimlang, but this feature is such an anti-pattern (anti-feature) that it drove me crazy. I could not easily and reliably grep/search anything. Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing. Why this was implemented into the l…

This complain comes from people who haven't used the language. > Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing. On the contrary, the language prevents confusion due to mixing getAttr and get_attr in the same codebase and bugs from using the wrong one. Unsurprisingly, many safety-critical environment…

There are two kinds of case-insensitivity in identifiers. In either cases identifier cases (and in this case, also underscores) are normalized, but case-agnostic languages would allow any mix of them while case-pedantic languages would disallow any pair of identifiers normalizing into the same name (they may still give helpful errors based on that normalized name though). I don't think case-agnostic languages provide a new value not provided by case-pedantic languages.

Re: Nim 1.6.2

#42

Post by shirleyquirk »

MrBuddyCasino wrote: post #26
sp33der89 wrote: post #5

Earlier quoted context omitted.

For me it's the intersection of performance like Rust, the readability like Python, the ability to generate native executables without dependencies like Go and a very cool type system. All while delivering fast compile speeds! The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials. Some downsides: not a big e…

> performance like Rust I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang. Fast enough for sure, but "half the speed of C" would be more honest it seems?

which benchmarks? I play the language benchmark game sometimes and I can always get within 10% of the fastest contender. Beating the fastest contender,though, is rarely possible without using the unsafe subset of Nim, hence `-d:danger`

Re: Nim 1.6.2

#43

Post by shirleyquirk »

carlmr wrote: post #36
michaelsbradley wrote: post #29

Earlier quoted context omitted.

Maybe so, but sometimes benchmarkers forget to employ compiler options like: nim c -d:danger -d:lto --opt:speed ymmv https://nim-lang.org/faq.html https://nim-lang.org/docs/nimc.html Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).

Do these activate -funsafe-math on the underlying C compiler? Because if so that's not a fair comparison, since this breaks a lot of code.

no, -d:danger turns off runtime bounds/overflow checks, assertions, and debug info, and passes '-O3 -fno-ident' to the C compiler

Re: Nim 1.6.2

#44

Post by rakoo »

benjamin-lee wrote: post #27
rakoo wrote: post #18

Earlier quoted context omitted.

My personal blocker is that identifiers are all imported globally by convention, so when you see that there is a call to a method called "get", you have to get to the top of the file or mouse over the call to see what lib it is from. A "get" from the http lib is not the same as a "get" from the kv store lib.

There is some logic as to why that is. Here [1] is an explanation for why it makes sense but the tldr is that you don't want to be manually importing functions such as `$` and `+`. In languages like Python, those are defined as methods on the object being imported (e.g. `.__str__()`) so they come along for free. Not so in Nim. If there's a conflict (same name, same signature), the compiler will warn you but it's extr…

Thank you for the link but it doesn't address the issue I have. It's not about types, or about the compiler being "unsure". It's about me, as a developer, reading code someone else wrote, not knowing directly what package a call is from. I need to leave my current context to have the answer.

I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention

Re: Nim 1.6.2

#45

Post by shirleyquirk »

trymas wrote: post #20
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...

Agreed. First world problem, though I've tried couple of times to get into nimlang, but this feature is such an anti-pattern (anti-feature) that it drove me crazy. I could not easily and reliably grep/search anything. Not to mention that reading code requires extra mental overhead (especially being new to the language), that `getAttr`, `get_attr`, etc., are actually the same thing. Why this was implemented into the l…

> everything is imported globally `from package import *`

yes, that is the default, but it is also possible to

`from package import nil`

which gives you python's `import package` behaviour or

`from package import symbol`

which is just like python

Re: Nim 1.6.2

#46

Post by benjamin-lee »

rakoo wrote: post #44
benjamin-lee wrote: post #27

Earlier quoted context omitted.

There is some logic as to why that is. Here [1] is an explanation for why it makes sense but the tldr is that you don't want to be manually importing functions such as `$` and `+`. In languages like Python, those are defined as methods on the object being imported (e.g. `.__str__()`) so they come along for free. Not so in Nim. If there's a conflict (same name, same signature), the compiler will warn you but it's extr…

Thank you for the link but it doesn't address the issue I have. It's not about types, or about the compiler being "unsure". It's about me, as a developer, reading code someone else wrote, not knowing directly what package a call is from. I need to leave my current context to have the answer. I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention

Ah that makes sense. I agree with you; I’m not a huge fan of trying to infer where the types came from myself either when reading code on GitHub since it doesn’t have the inference that my IDE does.

Re: Nim 1.6.2

#47

Post by michaelsbradley »

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

For me it's the intersection of performance like Rust, the readability like Python, the ability to generate native executables without dependencies like Go and a very cool type system. All while delivering fast compile speeds! The adoption isn't like Rust and Go, but Nim is growing: https://github.com/nim-lang/Nim/wiki/Organizations-using-Nim and the community is active across all socials. Some downsides: not a big e…

Tooling has been a weak point, but it's getting better. I've been having a pretty good time of late with nimlsp[1] plus Emacs and lsp-mode[2].

[1] https://github.com/PMunch/nimlsp#readme

[2] https://github.com/emacs-lsp/lsp-mode#readme

Re: Nim 1.6.2

#48

Post by MrBuddyCasino »

shirleyquirk wrote: post #42
MrBuddyCasino wrote: post #26

Earlier quoted context omitted.

> performance like Rust I've just looked at some benchmarks, and even though Nim claims C-like performance, that never seems to be confirmed by independent tests. It is usually a bit behind C / C++ / Rust / Crystal, and roughly on-par with Golang. Fast enough for sure, but "half the speed of C" would be more honest it seems?

which benchmarks? I play the language benchmark game sometimes and I can always get within 10% of the fastest contender. Beating the fastest contender,though, is rarely possible without using the unsafe subset of Nim, hence `-d:danger`

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.

Re: Nim 1.6.2

#49

Post by dom96 »

rakoo wrote: post #44
benjamin-lee wrote: post #27

Earlier quoted context omitted.

There is some logic as to why that is. Here [1] is an explanation for why it makes sense but the tldr is that you don't want to be manually importing functions such as `$` and `+`. In languages like Python, those are defined as methods on the object being imported (e.g. `.__str__()`) so they come along for free. Not so in Nim. If there's a conflict (same name, same signature), the compiler will warn you but it's extr…

Thank you for the link but it doesn't address the issue I have. It's not about types, or about the compiler being "unsure". It's about me, as a developer, reading code someone else wrote, not knowing directly what package a call is from. I need to leave my current context to have the answer. I can do `mypackage.mymethod` but it will only be in my own code, because it's not the convention

There are plenty of cases in Python and similar languages where it's not clear where a method is defined, consider `myClassInstance.myMethod`, how do you find its definition? You do not immediately know which class it belongs to, nor where that class is defined. This is especially the case when you've got classes inheriting from multiple levels of other classes.

Re: Nim 1.6.2

#50

Post by shirleyquirk »

MrBuddyCasino wrote: post #34
michaelsbradley wrote: post #29

Earlier quoted context omitted.

Maybe so, but sometimes benchmarkers forget to employ compiler options like: nim c -d:danger -d:lto --opt:speed ymmv https://nim-lang.org/faq.html https://nim-lang.org/docs/nimc.html Also, --gc:arc and --gc:orc are going to bring a stronger game to the table as they continue to mature (already pretty far along).

Nothing says "realistic benchmark" quite like the "-d:danger" flag.

leaving (e.g.)runtime overflow checks turned on in the Nim code would not be a realistic comparison against C
Post reply on HN