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

31–40 of 162 posts

Re: Nim 1.6.2

#31

Post by Mikeb85 »

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?

Why do people bother with questions like this?

Araq created Nim because he wanted to. Others use it because they want to. Why does it need a raison d'être ?

What it has: garbage collection with option to turn off, small binaries, compiles to C (and other languages) as intermediate step so it's easy to integrate into existing codebases, it's very fast without needing much trickery, it has all the features everyone always asks for with more being added all the time, etc...

Is it better than Rust, C++, Go, Java, whatever? Probably not in a strict sense. But it's pleasant to write plus above features. It's like Pascal meets Python meets Go but compiles to C and JS.

Re: Nim 1.6.2

#32

Post by goodpoint »

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…

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 environments have policies to enforce consistent naming styles.

The linter will convert both to "getAttr" and the compiler will complain if the user tries to define the same proc twice.

Re: Nim 1.6.2

#33

Post by formerly_proven »

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…

Argument-dependent lookup would solve that in a far less global way.

Re: Nim 1.6.2

#34

Post by MrBuddyCasino »

michaelsbradley wrote: post #29
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?

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.

Re: Nim 1.6.2

#35

Post by knuthsat »

jokoon wrote: post #30
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?

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…

I always thought of Python as being a massive language. If it was simple, it should be easy to compile and optimize.

I mean, I would feel like an idiot when someone would point out a feature that makes Python code faster. Python classes are quite massive and complicated (with a bunch of tweaks one can do through attributes).

Re: Nim 1.6.2

#36

Post by carlmr »

michaelsbradley wrote: post #29
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?

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.

Re: Nim 1.6.2

#37

Post by michaelsbradley »

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.

If you're going into production with Nim code and execution speed is a top concern, you're probably going to remove all the safety belts after thoroughly testing, valgrind'ing, etc., i.e. you're probably going to opt for -d:danger instead of -d:release. But maybe not, depends on the project I guess.

Re: Nim 1.6.2

#39

Post by pietroppeter »

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?

> why should I care about Nim?

it depends a lot on where you are coming from. If you are a Python developer/user (without any other information it is possibly the most likely case nowadays), you might find it solves a lot of current Python pain points (speed, portability, lack of typing, package system) and it has some added bonuses (great macro system, compiles to JS, works great for embedded).

If you are not a Python developer/user but you are somehow interested in new languages like Rust, Julia or Zig (you might be both), you might want to hear a different take on how Nim is also able to solve some of the problems they solve (a better C++, a better Python/R/Matlab for scientific computing, a better C - not that those languages reduce to those aspects...).

I think that what is happening now with Rust, Julia and Zig is great and I am happy that many people are looking at those languages and growing their ecosystem and their communities. Part of the drive of people there is to be able to make a significant improvement in the evolution of those languages (harder to do that in C, C++, Java, Python, C#, Swift, ...). I just happen to particularly like Nim and love being involved in it so far.

A recent article that explains the philosophy of Nim is the Zen of Nim by Araq (Nim's BDFL) [0]. Nim has some universal vision in the sense that it can be really used for everything (from kernel programming to web development, from scientific computing to game development, from embedded to devoping compilers and interpreters, from short throwaway scripts to critical infrastructure). Not necessarily it is for _everyone_. Taste of people varies a lot and that is a good thing.

[0]: https://nim-lang.org/blog/2021/11/15/zen-of-nim.html

Re: Nim 1.6.2

#40

Post by goodpoint »

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.

It's the normal compilation flag for performant code.

The word "danger" is scary, but it's simply disabling debugging code: debug assertions, full stacktraces, extra safety checks.

Post reply on HN