Nim: Curated Packages | Hacker News Reader

Nim: Curated Packages

github.com

BTW in case anybody is looking for help learning Nim, the Nim Discord was pretty helpful. I wrote a simple text file parser and ran into an annoying issue with the compiler reporting indentation errors which were really issues unrelated to indentation, so I asked there.

Turns out they have a community pastebin-type compiler for sharing code, and within a few minutes a couple others shared back fixes to my source. Really convenient compared to pulling one's hair out for a couple hours...

Genuinely curious, why Discord is better than StackOverflow?

The compiler developers hangout there (or IRC) and you likely get help within minutes.

Just under their table of contents, they say that "This list is fairly outdated." and point you to https://github.com/xflywind/awesome-nim - and that repo seems to have recent updates.

Both lists are unnecessary. You are better off search Nimble and evaluate the libraries yourself.

Nim is fast and highly productive to code in.

I'm nearly ready to release my Nim Dev Framework (for web apps, web-services and console apps). It has an ORM and the web/view part is getting there. Should be released in the next month or so. https://nexusdev.tools

I keep waiting for something like this for Rust. Call it the BatteriesIncluded2022 crate and do an annual release cycle. If it could get a nod from the official Rust maintainers, all the better. Something that is roughly analogous to the Python/Go standard libraries allowing to stand up quite a bit more software without pulling in a hundred different crates.

The Rust Cookbook [0] was meant to be one way of maintaining a curated list of crates though I don't know how much attention it has received since the 2018 edition documentation blitz.

As for a central batteries-included crate, its been tried a couple of times (e.g. stdx, ergo). Some things that I think would help drive it forward

- RFC 3243 [1] to allow for a central "front" for these crates without having to actually compile what you don't need or feature flags

- A compelling reason for people to adopt it. For a lot of existing projects, there isn't much motivation. I see the biggest benefit mostly being for prototyping and new users, so they need to cater to these users. Don't just re-export existing crates but lay things out in a natural, discoverable way. Also consider making things easier by keeping the Rust language knowledge to a minimum for end-users (even avoiding lifetimes where possible), don't overwhelm users with choices that won't matter in these contexts, etc. If the user needs more performance or flexibility, they can scale up to the crates being wrapped

I'm interested in working in this space but need to wrap up some other projects first. If anyone wants to work on this and is looking for a mentor, feel free to reach out to me.

[0] https://rust-lang-nursery.github.io/rust-cookbook/intro.html

[1] https://github.com/rust-lang/rfcs/pull/3243

>A compelling reason for people to adopt it.

I could imagine that security conscious products (medical, automotive, network applications) would feel more comfortable if there was a definitive release that could be cited as the basis for the work. Hardly absolves the requirements that would go into a regulated product, but it could be a minor step in the right direction.

>Don't just re-export existing crates but lay things out in a natural, discoverable way.

Complete agreement there. If there were ever to be a sanctioned "batteries crate" it needs to be more than slapping together a meta directory and calling it a day. I think the Lua Penlight project stands as an example of this.

What things would you like to see included that aren’t currently in the standard library?

Fair question. Noting that I am a Python person who has only tooled around with Rust a bit, a few packages I think warrant inclusion because the base options are too anemic:

  - Command line parsing (more feature rich the manually iterating over args)
  - (De)Compression: tar, zip, gzip, bzip2
  - CSV parser
  - Date time 
  - Hashing: md5, sha1, sha256
  - HTTP requests
  - Logging
  - Random generation: ints, floats, sampling, uuids
  - Regex
  - SQLite bindings
  - (De)serialization: json, ini, toml, yaml
  - System niceties: where is user home?, # of cpus?

Appreciating some of these are quite complex, and probably best left to a crate that has more leeway in experimentation/breaking APIs.

Edit: tried to make the formatting less bad

Maybe some of these can be chalked up to language philosophy or APIs as you said, but many of these would be welcome additions in my eyes.

I think regex, time, and crates like num_cpus would especially be nice to have. There's plenty of those types of crates where it feels like you can't compile a single project without seeing it float by as you build the dependencies.

> and crates like num_cpus

https://doc.rust-lang.org/std/thread/fn.available_parallelis... — Rust 1.59

Nim has sort of been in my peripheral vision for awhile but I’ve never really checked it out.

Any Nim fans have a good link to a good sell for it? No cynicism at all: I’m genuinely curious?

I'd say just try it out for yourself with these simple examples: https://nim-by-example.github.io/

Here's a nice link comparing memory safety of C, Zig, Rust and Nim – https://uploads.peterme.net/nimsafe.html – which was inspired by this post: https://www.scattered-thoughts.net/writing/how-safe-is-zig/

Thank you! Will check it out!

You may like to take a look at the NimConf presentations - https://conf.nim-lang.org/2020/ and https://conf.nim-lang.org/2021/ - for some nice inspiration as well as discussions of pros and cons done by actual practitioners.

As for me, in short words, what I found especially amazing in Nim was its resemblance to pseudocode (I literally found that it's a great notation to use when thinking in a notebook), fast compile times while at the same time low-bloat, macros, and the crazy impressive cross-platform story - including a JS target (I used it to write a functioning WebExt plugin for a browser; though I quickly got tired of the HTML+CSS part that remained necessary). At the other end of the x-platform spectrum, if you take a look at the videos, people are also successfully playing with Nim on microcontrollers (and I mean the real, small ones, not the Linux-hosting kinds). As for a few less amazing aspects, I struggled with the parallelism story; it is there, which makes it a complete modern runtime - but I found it nonstandard enough (and possibly somewhat unpolished?) that I failed to complete a hobby project where it was required. Thus (and also for a number of completely of unrelated reasons) I personally switched to learning Rust after Nim. Nim's package management is also missing lockfiles for reproducibility; I believe this might have recently gotten back into spotlight and hopefully is being worked on, but I don't know for sure, I'm not tracking the community now.

PS. Ah, and Araq (the BDFL) is constantly experimenting with some really cool stuff (e.g. the Orc garbage collector). Which gives the language and ecosystem some of its most interesting, exciting, and exceptional traits; OTOH then I'd say the financial support story of the language is regrettably not enough for some of the class-leading prototypes to make it past teaser stage (see e.g. DrNim: https://nim-lang.org/docs/drnim.html).

I don’t have any convincing links, but my sell would be that a yokel like me was able to learn and build things with Nim really quickly. It was something like 4 hours to start getting familiar and seeing results. I was able to make a wordle clone in a few days of very limited spare time.

The reference I used the most was this:

https://github.com/nim-lang/Nim/wiki/Nim-for-TypeScript-Prog...

Less of a global sales pitch for Nim (I'm a shoo-in from Pascal), but I found this today and thought it was neat:

"Enu lets you build and explore worlds using a familiar block-building interface and a Logo inspired API."

https://www.youtube.com/watch?v=ECJsq7BeZ8w

https://github.com/dsrw/enu

I am working on OpenStreetMap renderer in Nim - see https://github.com/severak/lunarender3/ (but work somewhat stalled)

I needed some language which is:

- compiled to binaries

- and really fast

- has needed libraries (HTTP server, protocol buffers, sqlite and image generation)

- it's easy to set up

It was nice experience and Nim simply worked for my needs. People on Nim forum were nice and helped me when I ran into problems. It has nice and usable built-in library and I was really impressed by graphic library pixie - https://github.com/treeform/pixie

I would use Nim again when I when I will see this application is suited for it (e.g. some command line apps).

This is definitely a well organized list with helpful packages. For those interested in Nim, I'd recommend giving a go to https://www.libhunt.com/l/nim as well. (disclosure - I work on LibHunt)

Does nim have virtual packages or meta-packages (dependency-only packages)? Then you could just pull nim-parse-json and have it pull in the curated package for JSON parsing.

Yes it does. Just make a package without Nim source code

I might be wrong, but is Nim comparable to Go? And if so, how does it fare against it?

I've been doing Nim professionally for about 3 years now. But I only shipped a small project in Go.

I feel like Go specifically “dumbs down” the language so that it can be used in large teams with varying programmer skills and high turnover. Perfect for large companies. Go routine stuff is really cool. But If you're not writing a super concurrent http server in a large team, Nim is just better at compiling to JS, Game Dev, Mobile and Embedded applications. It allows you to do cool meta programming and express things with templates and macros. You can go really low level with SIMD and manual memory or really high level with database, html, ui, and api DSLs.

Go feels like it was made to do one thing, while Nim is more of a swiss army knife of things.

Comparable in the sense that it's a compiled language with a GC and an easy to read syntax. They have their drawbacks and advantages over each other, but go is the only one with a strong institutional backing and a lot more dev.

Nim ARC/ORC is much closer to Rust than Go.

Reply on news.ycombinator.com