Nim 1.6.2 • Hacker News Board

Re: Nim 1.6.2

#11

Post by kitd » Fri, Dec 17, 2021, 9:01 AM UTC

echelon wrote: post #4

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?

Nim seems to be targeting the space between Python and Go, which is wide open for disruption. (Also touches at the edges of managed memory systems-y light languages like Java/C#.) Python is a dynamically typed cowboy land and is painfully slow for many applications. People want types, speed, and fixes for decades of baggage, but they like Python ergonomics. Go until recently lacked generics (it still doesn't have ful…

Go ... has bad error handling, and other weird features.

That's just, like, your opinion man ;)

Re: Nim 1.6.2

#12

Post by bronze » Fri, Dec 17, 2021, 9:09 AM UTC

esimov wrote: post #6

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

Seeing as one of the main users of nim is developing an ethereum client (https://nimbus.team/) I don't see why it's a bad thing to accept BTC too.

Re: Nim 1.6.2

#13

Post by winrid » Fri, Dec 17, 2021, 9:09 AM UTC

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 think others have covered this question well, but for my $0.02 - I've found it easy to write code in Nim that's half the size of and easily out performs (and has increased predictability, which is the big + for me) than Java/Node/etc.

The default runtime also doesn't have stop the world pauses and uses a similar message passing mechanism to Go.

Re: Nim 1.6.2

#14

Post by goodpoint » Fri, Dec 17, 2021, 9:10 AM UTC

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?

It's expressive and friendly like Python, but fast, statically typed and with powerful templating and macros.

It makes me productive and it's really fun to use.

Re: Nim 1.6.2

#15

Post by formerly_proven » Fri, Dec 17, 2021, 9:13 AM UTC

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...

Re: Nim 1.6.2

#16

Post by michaelsbradley » Fri, Dec 17, 2021, 9:14 AM UTC

Something I'm excited about: v1.6.2 integrates support for (not yet released) Nimble[1] v0.14, which will introduce project lockfiles. I've had terrible experiences with lockfiles in JS land, but they are sorely needed for Nim projects as (fingers crossed) they'll allow for reproducible builds without having to resort to the nimbus-build-system[2]. The latter isn't completely horrible — a lot of much appreciated hard work has gone into it, and it's been a real workhorse — but some days it feels like a big ball and chain.

I'll be much happier when I can cruise along with choosenim[3] and lockfiles and not have to worry about Makefile + submodules shenanigans.

[1] https://github.com/nim-lang/nimble#readme

[2] https://github.com/status-im/nimbus-build-system#readme

[3] https://github.com/dom96/choosenim#readme

Re: Nim 1.6.2

#17

Post by jb1991 » Fri, Dec 17, 2021, 9:15 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...

Indeed I too find this off-putting. I understand the rationale behind it, but developers are used to extreme attention to detail, and this discards an important aspect of detail in the important area of naming.

Re: Nim 1.6.2

#18

Post by rakoo » Fri, Dec 17, 2021, 9:19 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...

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.

Re: Nim 1.6.2

#19

Post by gyulai » Fri, Dec 17, 2021, 9:21 AM UTC

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?

Several years back, I wanted to know what the hype was about with regard to Rust and started looking into Rust a bit. In the process I also stumbled across Nim and decided that Nim suited those needs that I might have had for Rust even better than Rust did.

The killer feature for me is that it transpiles both to C and to JavaScript and I like the clean Python-like syntax.

I now use Nim whenever I write a decent chunk of "pure logic". By that, I mean something that does something complex and useful without leaving the confines of its own codebase all too much. In those cases it's nice to have the option of portability between the C ecosystem and JavaScript ecosystem.

When I write "glue code" (and, unfortunately, most code that most people write falls into that category) where I basically just put bits of language ecosystem together in a trivial way to achieve something useful, then I use Python because for such tasks the sheer size of the language ecosystem is king.

Re: Nim 1.6.2

#20

Post by trymas » Fri, Dec 17, 2021, 9:22 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...

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 language itself, instead of left as a suggestion or a standard is beyond me.

quick edit: also, everything is imported globally (if that's the right term? like in python `from package import *`). So when you see function call, you need to look it up all the time where it comes from.

edit2: apparently I am not alone :)