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

91–100 of 121 posts

Re: Nim in 2020: A Short Recap

#91

Post by cb321 »

GordonS wrote: post #88
the__alchemist wrote: post #59

Earlier quoted context omitted.

This is subjective, but I prefer Nim's python-like scoping syntax; ie no semilonons nor curlybraces. Someone else in this thread posted a comment to the opposite effect! That said, I don't see a compelling class of projects to use it on instead of Rust. I'll consider Nim next time I'm looking at making a python project. However - most of the times this happens is if I'm making a web backend or doing something numeric…

Funny how personal preference with regard to some syntax is so polarising - I'm coming from a primarily C# background and while Nim looks interesting, I find the lack of semicolon line endings and the whitespace-based scopes, to be really off-putting!

Syntactic indentation has been very polarizing since at least Python 0.9 (and maybe others) in the late 80s. Like ()s in Nim, Haskell also has a "both brackets or whitespace" kind of vibe.

But, yeah, choice lets different parts of code bases differ. No two ways around that. A ton of people had knee-jerk resistance to Python's lexical style but "got over it" eventually.

There really is a lot more to Nim than just this (its generic/template/macro metaprogramming, user-defined operators, GC options, speed, etc.). Many, many things can be done as libraries that would require direct compiler support in other languages. I would encourage you to give it a try.

Re: Nim in 2020: A Short Recap

#92

Post by dxdm »

magicalhippo wrote: post #20
runald wrote: post #12

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

I agree that the lack of explicit start/end markers for code blocks is a very unfortunate choice. It was a bold choice by Python, but in my experience it turned out to be a poor choice, and not one to be copied. That being said, it looks like a very exciting language and like Python I think I'd manage to enjoy it overall despite of that choice.

> the lack of explicit start/end markers for code blocks is a very unfortunate choice.

> It was a bold choice by Python, but in my experience it turned out to be a poor choice

Could you explain why? I've heavily used languages with explicit block delimiters as well as Python, in collaborative environments, and the significant whitespace in Python does not really cause me any trouble. There is some slight overhead of making sure of the indentation when copy-pasting, but a decent text editor will make fixing things simple.

As for the theoretical mixing of or trade-offs between tabs and spaces - that's just not a practical concern that exists in my experience.

Of course that's a matter of taste, but the whole thing just seems like a minor detail to me - especially when we have the option of code autoformatting now.

Am I missing something here that makes other people's experiences much worse?

Re: Nim in 2020: A Short Recap

#93

Post by longstation »

inbx0 wrote: post #62
zubspace wrote: post #53

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1]. It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use. The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in…

I'm wondering if the JS compile target could be used for debugging, at least in cases where it's the general logic of the app you want to debug and not some native code -specific bug. JS already has pretty good debugger story for VSCode & other editors, that has been tried and tested with other languages that compile to JavaScript. If Nim can output good source maps, the JS debuggers should pretty much just work.

I think this is a very good idea but it may depend on what you are doing. For example, if you are using Nim to talk to some C library, I believe you won't be able to compile the C part into JS for debugging (even if you are not debugging the C part of course).

Re: Nim in 2020: A Short Recap

#94

Post by GordonS »

cb321 wrote: post #91
GordonS wrote: post #88

Earlier quoted context omitted.

Funny how personal preference with regard to some syntax is so polarising - I'm coming from a primarily C# background and while Nim looks interesting, I find the lack of semicolon line endings and the whitespace-based scopes, to be really off-putting!

Syntactic indentation has been very polarizing since at least Python 0.9 (and maybe others) in the late 80s. Like ()s in Nim, Haskell also has a "both brackets or whitespace" kind of vibe. But, yeah, choice lets different parts of code bases differ. No two ways around that. A ton of people had knee-jerk resistance to Python's lexical style but "got over it" eventually. There really is a lot more to Nim than just this…

> There really is a lot more to Nim than just this

I've actually just been skimming some tutorials and docs, and wow, you're not wrong! I'm impressed - Nim seems to be rammed with features, but also easy to get started with (as long as you ignore some of the more advanced stuff).

I've recently been trying to find time and motivation to start learning Rust, but I have to say that (even with horrible indentation syntax :p ) Nim looks really compelling too...

Re: Nim in 2020: A Short Recap

#95

Post by cb321 »

GordonS wrote: post #94
cb321 wrote: post #91

Earlier quoted context omitted.

Syntactic indentation has been very polarizing since at least Python 0.9 (and maybe others) in the late 80s. Like ()s in Nim, Haskell also has a "both brackets or whitespace" kind of vibe. But, yeah, choice lets different parts of code bases differ. No two ways around that. A ton of people had knee-jerk resistance to Python's lexical style but "got over it" eventually. There really is a lot more to Nim than just this…

> There really is a lot more to Nim than just this I've actually just been skimming some tutorials and docs, and wow, you're not wrong! I'm impressed - Nim seems to be rammed with features, but also easy to get started with (as long as you ignore some of the more advanced stuff). I've recently been trying to find time and motivation to start learning Rust, but I have to say that (even with horrible indentation syntax…

If a little CLI app to do something useful (instead of say, some shell script/batch file or something) is your entry point then you might try cligen [1]. Everyone is different, but from many and varied reports (e.g. in this very thread [2]), it is hugely more probable that you get up & running with some basic skills in like 30 minutes to 4 hours or so with Nim than you would with Rust. Nim really seems to "scale up gracefully" for most.

[1] https://github.com/c-blake/cligen [2] https://news.ycombinator.com/item?id=25596285

Re: Nim in 2020: A Short Recap

#96

Post by dom96 »

planetis wrote: post #82
doteka wrote: post #80

Earlier quoted context omitted.

That would be a great argument, except I didn't start out with the intention of assassinating anyone's character. The above thread is literally the 3rd search result for "Karax state management". You know, a very reasonable search query when someone's trying to determine whether a frontend framework is ready for production use. This does not bode well. > Well, offer up your language of choice, and I'm sure we could w…

Fair point, although yourself gave me the wrong impression initially. karax doesn't support stateful components indeed.

You can certainly get stateful components with Karax. Perhaps I am missing something but Karax itself doesn't need any special support for them.

In the code for NimForum I've laid out each component as a stateful component, one example is the `threadlist` module: https://github.com/nim-lang/nimforum/blob/master/src/fronten.... You can see the `State` type defined there and all components follow this convention.

Re: Nim in 2020: A Short Recap

#97

Post by moldavi »

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's involved in learning to use the GC correctly? I'm very experienced in Rust, and so skeptical when anyone says Rust is easier than something.

Re: Nim in 2020: A Short Recap

#98

Post by auxym »

zubspace wrote: post #53

I've used Nin for this years advent-of-code challenge. Never used Nim before but there are some great tutorials [1]. It's a nice language with a great standard library. Implicit static typing is great after a bit of getting used to. Some things like tuples or "Object Variants" are fun to use. The only thing I'm missing is strong debugging support. You can use GDB and there is even some basic support for debugging in…

There's definitely some talk in the community on improving dev tooling as a logical next step to improve adoption, eg: https://github.com/nim-lang/RFCs/issues/300

Re: Nim in 2020: A Short Recap

#99

Post by lostdog »

girvo wrote: post #33
runald wrote: post #12

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

So I used to totally agree with you... then I used Nim in anger. Honestly the whole white space thing barely even registered in the end for me!

I worked in Python for a while, and once you have a production bug because the indentation shifted around on one line when you moved some code around, you start to get really cautious and nervous every time you cut-and-paste. I much prefer C++ and Java now, where I can just paste and reformat without fear.

(I still use Python, and I'm still going to try Nim some day. Syntactic whitespace is a pain, and, in my opinion, a bad design decision, but it isn't everything.)

Re: Nim in 2020: A Short Recap

#100

Post by tokai »

doteka wrote: post #73

I’d love to give Nim a shot, but comments like these from the author make sure I’ll never be able to take the language seriously: (Context: gitter thread about frontend state management/immutable data structures, https://gitter.im/nim-lang/Nim?at=59722654bc46472974112028 ) Araq: meh, I cannot watch these hipsters talk Araq: as soon as I hear “business logic” I stop listening He felt compelled to make these comments a…

Oh man you're gonna have a heart attack if you ever look up some of Linus' comments.
Post reply on HN