Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nim in 2020: A Short Recap

nim-lang.org

Post reply on HN
Print view View original

41–50 of 121 posts

Re: Nim in 2020: A Short Recap

#41

Post by Rompect »

suncore wrote: post #7
leandot wrote: post #4

In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

Re: Nim in 2020: A Short Recap

#42

Post by matthiaswh »

macleginn wrote: post #38
beagle3 wrote: post #27

Earlier quoted context omitted.

Nim looks Pytonish (and has some Python-inspired syntax), but it is very much NOT Python. People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.

When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is.

Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently.

IMO going into Nim thinking it will be like Python but compiled! and faster! with types! is not a good way to approach it. It is an entirely different language altogether.

Re: Nim in 2020: A Short Recap

#44

Post by jononor »

leandot wrote: post #4

In what cases is Nim a better option than Rust? Would be great if anyone with more experience can share more information.

The relative simplicity of the language is a feature. I can imagine introducing Nim to embedded/microcontroller firmware developers that only know/use C99 now. I cannot imagine introducing Rust - while a great language, it is C++ level complexity - and that is not always warranted.

Re: Nim in 2020: A Short Recap

#45

Post by rattray »

matthiaswh wrote: post #42
macleginn wrote: post #38

Earlier quoted context omitted.

When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going…

I'm curious - how would you describe the qualitative differences in code structure that results?

Are there ways in which Nim nudges you to structure your code in better ways than you would in Python? Are there footguns?

Re: Nim in 2020: A Short Recap

#46

Post by JNRowe »

runald wrote: post #12

Too bad nim uses a whitespace-sensitive syntax like python, something I personally dislike.

One of my favourite things about working with Vala¹ was being able to use Genie² with the off-side rule syntax where it felt appropriate. Some chunks of code feel better to me when structured in certain ways.

I often find myself wondering why other languages haven't implemented support for an alternative syntax. I suspect the answer is that simply no one cares enough to put the work in, but perhaps there is a better reason.

¹ https://en.m.wikipedia.org/wiki/Vala_programming_language

² https://en.m.wikipedia.org/wiki/Genie_(programming_language)

Re: Nim in 2020: A Short Recap

#47

Post by pjmlp »

Rompect wrote: post #41
suncore wrote: post #7

Earlier quoted context omitted.

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

Not writing GUIs in Rust are we?

Re: Nim in 2020: A Short Recap

#48

Post by pjmlp »

matthiaswh wrote: post #42
macleginn wrote: post #38

Earlier quoted context omitted.

When I started learning Nim, I did not really expect anything, but time and again I caught myself thinking, ‘This is so much like Python!’ Eventually I lost interest because I do not need a faster Python that is not Python, and I didn’t find much else to be enthusiastic about.

I've written a large-ish amount of Nim code on personal projects while using Python day to day at work, and almost every time I'm working with Nim my brain is screaming at me at how unlike Python it is. Nim took some inspiration from Python's syntax, but the similarity is only skin deep. The construct of the language is very, very different resulting in code that usually looks and is structured differently. IMO going…

Actually it feels more like a Python flavoured Object Pascal.

Re: Nim in 2020: A Short Recap

#49

Post by dom96 »

Rompect wrote: post #41
suncore wrote: post #7

Earlier quoted context omitted.

I think the main difference (benefit?) is that Nim has the convenience of a garbage collected language while retaining good and predictable performance (e.g. via ARC/ORC and thread-local GC). Rust has no GC so requires more from the programmer. Personally, I'd rather use a GC language to have less complexity in the code even though I have to spend some more time learning to use the GC correctly.

For normal purposes, dealing with Rust's lifetimes will be easier than spending some time "learning to use the GC correctly"

What do you consider "normal" and "non-normal"?

Re: Nim in 2020: A Short Recap

#50

Post by dom96 »

beagle3 wrote: post #27
johnisgood wrote: post #9

Earlier quoted context omitted.

I consider Nim to be a compiled, faster Python. Nim is very easy to read and understand, and prototype in, vs. Rust.

Nim looks Pytonish (and has some Python-inspired syntax), but it is very much NOT Python. People coming from Python that expect a "compiled, faster" Python often find a compiled, faster language but have very weird concepts expecting that language to behave like Python though it isn't.

When I first found Nim I was looking for a faster compiled Python. I've found something that is much better: static types, less of an emphasis on OOP, static dependency-free fast binaries and macros all work together well to make Nim awesome to work with but what makes Python great is retained: speed of development, ergonomic syntax, and a small learning curve.

> very weird concepts

I'm curious, what weird concepts are you referring to?

Post reply on HN