Nim 1.6.2 • Hacker News Board

Re: Nim 1.6.2

#61

Post by sp33der89 » Fri, Dec 17, 2021, 10:54 AM UTC

michaelsbradley wrote: post #47

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…

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

Last time I tried nimlsp was in June-ish, using neovim. It was an okay experience, but things broke down quickly when using macros and I got red squigglies everywhere because things rely on a certain setting. Compared to the VSCode experience, it's really lacking though.

It's certainly been getting better and the focus is also on tooling, so I'm hopeful!

Re: Nim 1.6.2

#62

Post by shirleyquirk » Fri, Dec 17, 2021, 10:56 AM UTC

jimmyed wrote: post #60

> Macros cannot change Nim's syntax because there is no need for it — the syntax is flexible enough. Erm, what? How about letting the user decide that?

it does come across as arrogant. A humbler way to put it would be "Macros cannot change Nim's syntax because they transform the AST after it has already been parsed"

Re: Nim 1.6.2

#63

Post by kajiryoji » Fri, Dec 17, 2021, 10:59 AM UTC

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

Re: Nim 1.6.2

#64

Post by formerly_proven » Fri, Dec 17, 2021, 11:00 AM UTC

dom96 wrote: post #59

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…

I'm sure Rust also has a way to disable bounds/overflow checks for speed. Do benchmarks utilise it?

Rust should be able to elide more checks than most other languages without impacting safety.

Re: Nim 1.6.2

#65

Post by k__ » Fri, Dec 17, 2021, 11:06 AM UTC

girvo wrote: post #10

esimov wrote: post #6

Seeing that the team behind Nim is accepting Bitcoin is not a good sign.

Why’s that?

Just the general disdain for crypto here at HN.

Re: Nim 1.6.2

#66

Post by qalmakka » Fri, Dec 17, 2021, 11:12 AM UTC

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?

They kind of occupy two different niches, IMHO. I see Nim more as a competitor to Go, whole Zig wants to replace C mostly and somewhat competes with Rust in that regard.

Re: Nim 1.6.2

#67

Post by vegai_ » Fri, Dec 17, 2021, 11:15 AM UTC

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?

They have the same amount of letters in their name, both have "i" as the second letter.

Zig is (a much) better C. Few solid features.

Nim is a better (Pascal+python+lisp)/3. Lots of features. Some are solid.

Re: Nim 1.6.2

#68

Post by dom96 » Fri, Dec 17, 2021, 11:21 AM UTC

shirleyquirk wrote: post #62

jimmyed wrote: post #60

> Macros cannot change Nim's syntax because there is no need for it — the syntax is flexible enough. Erm, what? How about letting the user decide that?

it does come across as arrogant. A humbler way to put it would be "Macros cannot change Nim's syntax because they transform the AST after it has already been parsed"

That's not the reasoning though. Not allowing macros to change the syntax gives Nim programmers an anchor and reduces friction from needing to learn brand new syntax rules for any big DSLs.

Re: Nim 1.6.2

#69

Post by shirleyquirk » Fri, Dec 17, 2021, 11:23 AM UTC

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

Re: Nim 1.6.2

#70

Post by qalmakka » Fri, Dec 17, 2021, 11:25 AM UTC

formerly_proven wrote: post #15

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?

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 insensitivity is a Western-only concept that should die ASAP, it's immensely complicated to pull off right and it opens a massive can of worms that makes no sense (see the Turkey Test for more about this).