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

Nim 2.0

nim-lang.org

Post reply on HN
Print view View original

101–110 of 213 posts

Re: Nim 2.0

#101

Post by Xeamek »

pzo wrote: post #100
treeform wrote: post #92

Earlier quoted context omitted.

To be fair to Nim, only Python has the huge ML ecosystem of numpy, scipy, pandas, opencv, pytorch, tensorflow, keres... Doing ML/AI style work in anything but python is really hard! That said Nim does have the nimpy library that allows for pretty seamless interop with python. Which means you can just import PyTorch, or scipy, or opencv and use them in Nim.

for me (mobile developer) interop with python is not enough because of really poor python story on mobile devices (iOS / android) when using native modules. I think if Nim had a seamless interop with Rust or even Zig it could piggyback on those communities to get some libraries for free.

Dunno about rust, but since both Nim and Zig compile to C as interim, it should be fairly easy to get them working together, no?

Re: Nim 2.0

#102

Post by khaledh »

khaledh wrote: post #31
jadbox wrote: post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

I've used both to work on a hobby OS project (Nim[1], Zig[2]). I very much prefer Nim. Code is succinct, elegant, and lets you focus on your core logic rather than fighting the language. Zig is nice and I like its optionals support and error handling approach. But I was put off by its noisy syntax, e.g. !? [ ]u8 to represent an error union of an optional pointer to a many-pointer of uint8. Also having to prepare and…

Couldn't edit my post, but forgot to mention my main pain points with Nim have been:

- its module system, especially not being able to have mutually recursive imports (there has been a 7 year old proposal[1])

- order-sensitive declarations of procs (i.e. can't use a proc defined further down in the file unless you add a forward reference to it). For the latter there's an experimental pragma[2], but it doesn't work a lot of times once you introduce mutually recursive calls

- object variants requiring declaration of a separate enum instead of allowing inline declaration of the variant cases, and a close issue[3] with not being able to define the same field names under different variant cases.

[1] https://github.com/nim-lang/rfcs/issues/6

[2] https://nim-lang.org/docs/manual_experimental.html#code-reor...

[3] https://github.com/nim-lang/RFCs/issues/19

Re: Nim 2.0

#103

Post by pzo »

Xeamek wrote: post #101
pzo wrote: post #100

Earlier quoted context omitted.

for me (mobile developer) interop with python is not enough because of really poor python story on mobile devices (iOS / android) when using native modules. I think if Nim had a seamless interop with Rust or even Zig it could piggyback on those communities to get some libraries for free.

Dunno about rust, but since both Nim and Zig compile to C as interim, it should be fairly easy to get them working together, no?

Things might changed but last time I checked you could easily call C function but you had to kind of export each single C function, structs etc. You couldn't just import single header file and be ready to call any function in the library. There is some pending project [0] futhark but not sure how mature it is and that still only for C libraries (instead of C++ or Rust) but maybe easy adopt for Zig - would be great nonetheless.

[0] https://github.com/PMunch/futhark

Re: Nim 2.0

#104

Post by otherme123 »

aquova wrote: post #43

Nim has been my favorite language for a while now, and I'm very excited to see version 2.0 finally released. A lot of these features have been items I've been looking forward to for some time. The only downside is some of the included modules being moved to 3rd party repositories, as mentioned at the very bottom. It's not a big deal, but it was nice having SQLite support built into the library. I suppose once you sup…

Libraries stagnate in the batteries included. Python carries some dead batteries since the 90's, but they are required there.

While it's nice to have path or logging support in the batteries, some other things are better as third parties, to allow them to evolve.

Re: Nim 2.0

#105

Post by elcritch »

khaledh wrote: post #102
khaledh wrote: post #31

Earlier quoted context omitted.

I've used both to work on a hobby OS project (Nim[1], Zig[2]). I very much prefer Nim. Code is succinct, elegant, and lets you focus on your core logic rather than fighting the language. Zig is nice and I like its optionals support and error handling approach. But I was put off by its noisy syntax, e.g. !? [ ]u8 to represent an error union of an optional pointer to a many-pointer of uint8. Also having to prepare and…

Couldn't edit my post, but forgot to mention my main pain points with Nim have been: - its module system, especially not being able to have mutually recursive imports (there has been a 7 year old proposal[1]) - order-sensitive declarations of procs (i.e. can't use a proc defined further down in the file unless you add a forward reference to it). For the latter there's an experimental pragma[2], but it doesn't work a…

You might like Patty. It makes case types more ergonomic: https://github.com/andreaferretti/patty

Re: Nim 2.0

#106

Post by pointystick »

maleldil wrote: post #44
Bostonian wrote: post #30

If your Python programs heavily use Pandas and Numpy, could there still be speed benefits to translating them to Nim?

That might depend on how many raw Python loops and functions you use. Even if most of your code uses pandas and numpy, things like string processing could still benefit from a compiled language.

Here's a presentation from last year where a Python data scientist compares a Python and Nim implementation for a problem, with the Python version calling out to Numpy. There are performance comparisons at the end and his Nim version was faster so Nim should be usable for scientific programming:

https://archive.fosdem.org/2022/schedule/event/nim_hpcfrompy...

The big issue Nim faces isn't performance but rather the relative community sizes, and thus how many libraries are available (and also how much help you might find when you run into problems).

Re: Nim 2.0

#107

Post by synergy20 »

audunw wrote: post #10
jadbox wrote: post #4

Anyone have working experience with Nim and Zig? I'd love to hear how they are similar and contrast. I'd also would like to see some idiomatic web server benchmarks between the two (now with Nim v2).

I’ve written programs in both, though it’s been a while since I used Nim now. I think I enjoyed writing Nim more. Zig is more boring, but for all the right reasons. I wouldn’t personally choose to write an OS in Nim, but I think Zig would be great for that when it’s mature. I personally started using it for embedded software. I would probably use Nim for CLI tools, server applications, maybe GUI applications and game…

nim seems good for embedded too,just use cross c compiler as the backend?

Re: Nim 2.0

#108

Post by elcritch »

c-cube wrote: post #82
frou_dh wrote: post #24

Seems like it kinda has Sum Types, so Nim passes the litmus test for respectable static type-system in this day and age. https://nim-lang.org/docs/manual.html#types-object-variants

When I looked at it a few years ago, the compiler didn't prevent you from accessing fields from the wrong variant, and didn't provide exhaustivity checks. So I think it still falls short of this (excellent) litmus test :/

They've improved the compiler analysis for them significantly, including exhaustivity checks and field checks.

Re: Nim 2.0

#109

Post by pzo »

hugs wrote: post #54
brodouevencode wrote: post #13

What are some noteworthy projects or libraries written in Nim?

I don't know if my particular version is noteworthy, but I recently started making updated Nim bindings for OpenCV and it was kinda fun. I don't consider myself an advanced C++ programmer, but Nim made the process easier than I had feared it would be. https://github.com/tapsterbot/mvb-opencv

Not familiar with Nim enough to figure it out - are the bindings auto generated in similar style like opencv bindings to any other supported language (python, julia, objc, rust, etc)?

Re: Nim 2.0

#110

Post by elcritch »

himujjal wrote: post #95

I loved Nim when I used it first. But I left it because of recursive imports. I had to basically put all my types into one file and use them from various others. For a relatively medium sized project (~10LOC), its a but of a hassle. Refactoring is an issue. That being said, the language is fantastic. Can anybody with experience suggest me what HTTP library/framework do they prefer for servers?

The lack of recursive imports can be annoying, but I found I don't mind it. It keeps your module tree into a DAG.

Chronos is probably the most feature rich and uses async. Mummy is newer and uses a threading model. Both are used in production.

Post reply on HN