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

61–70 of 121 posts

Re: Nim in 2020: A Short Recap

#61

Post by cb321 »

m45t3r wrote: post #57
runald wrote: post #12

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

I also have many thing I don't like in every language I use, but I still use them because they're still useful. If we're talking about syntax for example, for me it is Clojure > Python > Elixir >> Ruby, but I know lots of people that thing Ruby is the most beautiful language on earth. BTW, if we are talking about things that really goes on nerve for me it is the fact that Golang doesn't compile when there is unused i…

In Nim, a warning is exactly what happens for unused imports. I also think that is the right level of pestering.

Re: Nim in 2020: A Short Recap

#62

Post by inbx0 »

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.

Re: Nim in 2020: A Short Recap

#64

Post by k__ »

pjmlp wrote: post #47
Rompect wrote: post #41

Earlier quoted context omitted.

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?

High level Rust libraries like Yew are pretty straight forward to use.

Re: Nim in 2020: A Short Recap

#65

Post by beagle3 »

dom96 wrote: post #50
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 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 a…

The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python.

And many random question start with “Python let’s you..” or “shouldn’t we make this more like Python” to which Araq rather consistently (and rightly) replies “no, because this is not Python”

Re: Nim in 2020: A Short Recap

#66

Post by dom96 »

beagle3 wrote: post #65
dom96 wrote: post #50

Earlier quoted context omitted.

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 a…

The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python. And many random question start with “Python let’s you..” or “shouldn’t we make this more like Python” to which Araq rather consistently (and rightly) replies “no, because this is not Python”

> The Nim forum has recurring questions about deserializing JSON that only make sense if you assume Nim is runtime dynamic like Python.

Nim is a statically typed Python, and actually the way you can deserialise JSON is very Python-like, so I'm not sure where you got this from. Here is an example:

Python:

    >>> import json
    >>> j = json.loads('{"foo": 42}')
    >>> j["foo"]
    42
Nim:

    import json
    let j = parseJson("{\"foo\": 42}")
    echo(j["foo"]) # 42
https://play.nim-lang.org/#ix=2KpU

Re: Nim in 2020: A Short Recap

#68

Post by Symmetry »

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"

It really depends on what you're doing. If you've developing an OS or web browser or game engine you're going to be having to think about memory management very carefully in any event and dealing with Rust's lifetimes is just formalizing the work you'd be doing anyways. But most applications aren't optimized that heavily and as long as you don't have a memory leak or an algorithmic pessimization you don't have to worry about performance in most cases and having a garbage collector is saving you a lot of work.

Re: Nim in 2020: A Short Recap

#70

Post by planetis »

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…

Ah debugging is very simple, just call `writeStacktrace()` (I assume you can guess what it does) It's great!
Post reply on HN