Hacker News Reader

what are you making in NIM? Finance stuff? Websites? Database tools? Science/Space?

Kinda curious what you've done "using Nim pretty intensively for several years"

I’m not the OP but have implemented a bioinformatics algorithm library with with Nim.

I had an implementation in Python and just ported it to Nim. I have been incredibly impressed with Nim to say the least. I managed to make the Nim version orders of magnitude faster with fewer lines of code while having more features. With the excellent Nimporter library, I can easily make a Python API and have it be pip installable.

I genuinely think Nim (or similar) may be the future of my field. Combined with its JS compile target and WASM support, it lets me target my three main “platforms“: web, Python API, and high-performance CLI.

This sounds very interesting! What are your thoughts on nim vs julia? In the scientific community, julia is popular for similar reasons as nim like easy syntax and compiled code. If you think nim will take over in bioinformatics, how is the support of numerical algorithms like BLAS and LAPACK?

https://forum.nim-lang.org/t/5242

There is https://github.com/mratsim/Arraymancer n-dimensional tensor (ndarray) library

Native plotting library: https://github.com/Vindaar/ggplotnim

as well as many other packages.

This is a good write up imo: http://lh3.github.io/2020/05/17/fast-high-level-programming-...

I have never written anything “production” grade with Julia, so do take my opinion with a grain of salt. However, I did once try to translate a simple algorithm library from Python into both Nim and Julia.

Julia was no faster than Python with my initial naive implementation. After consulting the forum and getting help, I did manage to get it running fast. My impression of Julia is that it can be incredibly fast but it takes work to get to that stage.

In contrast, with Nim, my code looked nearly identical to my Python code (i.e. quite simple) and ran fast from the start. This has been my general impression of Nim after doing a few projects in it: you write clean, readable code and get fast code out. There is no step 2.

With respect to numerical algorithms, Nim has good support for BLAS and LAPACK. I personally haven’t used them, so I can’t comment.

Nim’s metaprogramming allows for things like this [1], which is a macro library that translates between idiomatic Python and Nim. While I don’t use it myself (I find Nim’s idioms to make sense for Nim) it does make the transition a lot easier.

[1] https://github.com/Yardanico/nimpylib

Network protocol stuff, database tools, web clients & servers, games, graphics, AI, cryptography, and various random projects over the past 5-6 years. Some professionally, some for fun.

It's an incredibly adaptable tool. I mean, just take the example of writing type safe Nim code and compiling it to JS for a web client (already handy), then writing a high performance server in the same language, sharing the same types/code, but compiled to C. We can bring together front-end and backend! :)

Another generalist ability is with libraries you can get a high cooperation with Python - you can run Nim from Python and Python from Nim - so you can merge with that ecosystem too and use existing infrastructure as required. And of course an even better situation exists with C and C++.

Personally it's been a great way to diversify my ability to reach different domains with a unified tool.

> Metaprogramming in particular is just great in Nim and give you a lot of scope for doing things that would otherwise require new language features.

Metaprogramming is v alluring to me, but I’ve been wondering, people that write code super heavy on the metaprogramming, doesn’t revisiting code and debugging become much more taxing?

I have written a lot of metaprogramming myself, like 5/10 of my repos are macro libraries. And I share your concern. Even the manual advices people to use the least "powerful" tool for the job. These are proc/func<template<macro.

Macros are prefered for creating dsl like https://github.com/treeform/fidget or https://github.com/pragmagic/karax

Otherwise the advice is to use them when they "pull their weight". The reason is they're a lot harder to write and even "design" them right (how they function, what code they write, etc) takes a lot of effort. And in most cases the simpler "tools" will fit your needs.

You have multiple ways to print the macros either as AST tree or even Nim code that can be copy-pasted to replace the macro:

- dumpTree

- lisprRepr

- treeRepr

- toStrLit

This means that for debugging you can generate your code. Replace the macro by regular code temporarily and understand what's wrong and then fix the macros.

I don't think I have a single library without macro but I try to keep them as reasonable as you can. But sometimes you need to give a Python feel (for example to provide a Numpy interface for a multidimensional array library) or you have to do code transformation (implementing async or multithreading as a library or autovectorizing high-performance computing code or implementing a GPU or Audio DSL) and there is no way around macros.

You generally want to use the simplest tool for the job first. Most of the time generics and templates really are as much as you need since Nim's generics are structurally typed and templates allow a lot of metaprogramming without getting into AST trees.

My experience debugging complex compile time transformations is pretty positive thanks to the tools available to manipulate and debug the syntax trees. For example you can `echo node.repr` to display the code it represents at any point, and going the other way you can pass code to `dumpAstGen` to display the code that will generate the AST tree and so on.

This also has the benefit of letting you quickly understand how the trees are structured by trying different bits of code, or for passing DSL syntax fragments to see the parsed tree structure for your macro to consume.

The main important thing is that stack traces at compile time get you to the place where the error is happening. How hard that is to debug depends on how complex your tree manipulation is, and how you are doing that manipulation.

For example if you're just got a load of `quote` statements that interpolate variables and you're chucking these together, the trace will usually lead to the start of the `quote` block, so if you've got a long `quote` block then you have to kind of find the error in that, but it's not too bad since the error messages are pretty precise and the language is strongly typed.

For direct AST manipulation, the error will point to the place where the error is triggered, so for example if you add a bunch of statements in a node, the error may be the place that node is added to it's parent to be 'connected' to the program as a whole. Or, if it's an attempt at a duplicate variable declaration it will point directly to the place where you're creating the `ident` that represents the variable in your macro, so that's pretty nice.

In short, yes it is more work, but it generally makes sense, is type safe, and we have tools that mean fixing stuff is often some `echo` statements to look at generated code.

Why does Nim have "nil"?

To represent a null pointer. Nim is a systems language (or at least can be used as one), and you need null/nil when working at that level.

Even Haskell has null pointers, if you know where to look:

https://hackage.haskell.org/package/base-4.14.0.0/docs/Forei...

Likewise unsafe Rust has null pointers, but I've never needed it or seen it used. (Same with Haskell).

You just mentioned using "nil" in a simple example which doesn't appear to be related to systems programming.

I didn't mention "nil" in a simple example. I wasn't the poster of that comment.

Oh, thought you were same poster. Well, that other person mentioned it in a context which doesn't appear to be related to systems programming.

Just checked Github for some of the top Nim projects.

Forum software: https://github.com/nim-lang/nimforum/search?q=nil&unscoped_q...

Web framework: https://github.com/planety/prologue/search?q=nil&unscoped_q=...

Twitter front-end: https://github.com/zedeus/nitter/search?q=nil&type=Code

These uses of "nil" don't appear to have anything to do with systems programming.

Fair point. I should mention that I'm not a Nim expert, and am not defending its design. It's true that 'nil' appears in Nim under both of its pointer types (GC traced "references" and untraced "pointers") -- which is unlike, say, Rust's safe references vs. unsafe (nullable) pointers. So 'nil' is not simply a systems level construct; otherwise you might expect Nim to have nillable pointers, but not nillable references.

You need nil/null when doing systems work -- and Nim is capable of that -- but I don't know the rationale for allowing 'nil' in higher level language features.

Thanks for the honest reply.

Nim interests me but this nil business seems questionable to me.

Just found this comment from the language creator,

https://github.com/nim-lang/Nim/issues/6638#issuecomment-487...

"We need the nil state to disarm pointers but that only means these can be nil and so would require a nil check before deref. Doesn't seem to be too hard nor too cumbersome."

Seems a bit dismissive to me

I agree that it's a sharp edge in the language. Or at least it seems to be -- I've written a little bit of Nim, and never encountered a case where I was actually bitten by 'nil'. The language does have a 'non nil' annotation that can be used when defining structs (and maybe in other parts of the language, I don't recall), so there must have been some thinking about the dangers of nil pointers.

I would still recommend playing with the language for a while. It's quite practical, and the performance is very good. I've used it to write some utilities where I might otherwise use Python, but either needed more speed or needed to use it in a restricted environment where the Python interpreter wasn't available. The experience was mostly positive, and I would use it again.

Thanks, I intend to give it a fair try

P.S., you can annotate procedure to help ensure you can’t raise certain conditions in code. Imho it’s nice for writing sections of “safe” code.

`non-nil` was deemed too breaking to introduce for 1.0 or even as a default because if you tagged your input as `T not nil` the compiler was not powerful enough to prove that T was indeed not nil except in the most obvious cases.

The new battleplan is to integrate the Z3 theorem prover into Nim as DrNim:

- https://nim-lang.org/docs/drnim.html

The first use-case will be proving array bounds at compile-time and elide them. Future use-cases include not nil tracking.

This sounds pretty cool, but, two thoughts

1) Echoing the other comments in this thread about uneasiness with feature creep

2) Wouldn't have been a breaking change if the language didn't have nil from the beginning

1: DrNim is basically additional annotations that are ignored, and you can choose to opt-in via a flag.

It's something you similar to MyPy for python and type annotations. The danger is if it becomes non-optional.

That said contrary too many languages, the core language doesn't need:

- threading

- async

which are huge parts to maintain, but thanks to metaprogramming you can implement them as libraries with very nice syntax as well. It also allows compiler devs to focus on what they know well, compilers and leave those 2 highly specialized areas to people who are experts (or become experts) in those.

2: There are 2 dimensions there: nil is used for C FFI, for higher-level primitives you can use Option. And C FFI was needed to bootstrap Nim with a useful set of functionality and has an escape hatch so that people could start building early on and not wait for the language. So both from a functionality and a time-to-market point of view it was necessary.

That's an old comment by the way. At that time the newruntime idea was tested (and now replaced by --gc:arc). One needs to be more careful when using others words, especially taken out of context.