Hacker News Reader

Nim is like writing C at the speed of Python, and running Python at the speed of C.

If you took Python but made it perform blazingly fast, and made it suitable for the most demanding of embedded and systems programming applications, in addition to game dev, you'd get Nim.

If on the other hand you're satisfied with Python, then keep using it. It was trivial for me to port a Python elliptic curve implementation to Nim. I'd certainly recommend it over Cython, because Nim is simply designed as one complete system built for writing high performance applications with a sane syntax.

Statistics (on an x86_64 Intel Core2Quad Q9300):

    Lang    Time [ms]  Memory [KB]  Compile Time [ms]  Compressed Code [B]
    Nim          1400         1460                893                  486
    C++          1478         2717                774                  728
    D            1518         2388               1614                  669
    Rust         1623         2632               6735                  934
    Java         1874        24428                812                  778
    OCaml        2384         4496                125                  782
    Go           3116         1664                596                  618
    Haskell      3329         5268               3002                 1091
    LuaJit       3857         2368                  -                  519
    Lisp         8219        15876               1043                 1007
    Racket       8503       130284              24793                  741

https://github.com/def-/LPATHBench/blob/master/nim.nim

https://github.com/Araq/Nim/wiki/Nim-for-C-programmers

Thank's for the explanation! Then I know Nim isn't for me because "winning the benchmark game" isn't important to me -- even Python is fast enough for almost everything I write. But I understand why it is appealing to others.

Are there any other up-to-date benchmarks of Nim? In larger programs, performance is often dominated by allocating and garbage collecting memory. It would be interesting to know if Nim performs as well in that discipline as in raw number crunching.

The reason I use Nim is because it is a compiled Python with static types, generics and very powerful macros.

When I say "powerful macros" I really do mean it. I wrote what is essentially the equivalent of C# async await using only Nim's powerful metaprogramming.

For me the big selling point is being able to do so many things at compile time. Stuff like

  const lookupTable = veryComplicatedFunctionCall()

or letting you declare types differently depending on compile time specifications. And then there's the macro system which I haven't really used but seems pretty nice.

So maybe "C with a macro system that's safe and does everything you always wanted it to do"?

As someone who does a lot of work on microcontrollers where there's no filesystem to read in configurations from and where small binary sizes count this is all very exciting for me.

I am excited about Nim because it compiles to C that can run on an ARM microcontroller. I believe this was a possibility at some point, but I don't know if this is a priority for Araq. So (personally) I see it as a (potential) "C replacement for embedded systems".

Won't Rust and Go likely get there equally easy?

Nim compiles down to C and can produce code to run directly on bare metal. My understanding is that Go and Rust (to a lesser degree) require a runtime. Perhaps someone with better knowledge of all three languages could chime in.

Rust's runtime has been reduced to bounds-checking of array access, IIRC. So to a much lesser degree, and I believe Nim also provides this behavior by default.

Go is garbage collected and has an opinionated ABI and runtime. Completely different beasts.

Yes, agreed, though I really wish Rust could compile to C: http://www.reddit.com/r/rust/comments/2e8t9k/my_1_wish_list_...

Someone has revived the LLVM C Backend. Hopefully this could be a path to Rust->C compilation: https://github.com/draperlaboratory/llvm-cbe

Compiling to C is so important to me that I may check out Nim as an alternative to Rust, despite liking Rust very much.

Rust has been used to write code that runs on bare metal too. Typically, this is done by using #![no_std], since the standard library depends on things like jemalloc and libc stuff. Everything that doesn't depend on these is in libcore.

I like this use case. I've had the misfortune of trying to cross compile Python for ARM. It's very difficult, because the build process runs the freshly compiled python executable. This obviously doesn't work when you are compiling an ARM executable on an x86 machine. The answer for us was to use Scratchbox [0]. This let us run the compilation on an emulated ARM machine.

In case anyone is wondering: The actual platform was Chumby [1], and Python ran great on it. We had a little twisted [2] application that displayed images and played sound. To display the images we just wrote an image file (after using PIL to manipulate it) to /dev/fb. It was really fun! I just double checked the hardware the chumby: A 350 MHZ ARM9 processor with 64 megabytes of SDRAM. It sounds a little crazy to me now to think of transforming images using PIL in 64 megabytes of ram, but it actually worked quite well.

[0] http://www.scratchbox.org/

[1] http://en.wikipedia.org/wiki/Chumby

[2] https://twistedmatrix.com/trac/

I'm just trying Nim for the first time. How do you compile to totally self-contained C?

I tried pulling the files out of nimcache/*.c, but it is wanting to include nimbase.h.

Is there a way to compile an entire Nim program to a single self-contained .c file (ie. an amalgamation, aka SQLite?)

You copy the nimbase.h file along with the nimcache/*.c files. That's it. The compiler doesn't do it because it's a waste of time/space copying a file which you most likely can include from somewhere else, and it's not a generated file.

Good to know. It would be nice if there was an option for the compiler to build a single .c file that was totally self-contained, for distribution purposes.

I don't know anybody who redistributes source code as a single C file, but you could try concatenating the files into one. Usually people redistributing source code don't mind having several files bound together by some make|build script. The nim compiler has the --genScript switch to make one. Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.

> I don't know anybody who redistributes source code as a single C file

SQLite pioneered this approach, called an Amalgamation. It offers some noticeable advantages:

https://www.sqlite.org/amalgamation.html

It is gaining some followers:

https://github.com/vinniefalco/Amalgamate

http://stackoverflow.com/questions/2719311/tool-to-create-an...

http://lua-users.org/lists/lua-l/2008-08/msg00594.html

> Usually people redistributing source code don't mind having several files bound together by some make|build script.

A single .c file is easier to integrate into various build systems. For example a Visual Studio project, or another Makefile without needing a separate script. It's just cleaner.

> Most people willing to get something redistributable prefer a binary static|dynamic library or final executable.

These aren't portable like a C source file is.

That's truly exciting. I wonder how well it'd run on Altera Nios 2 with, say, 16 kB of RAM. If Nim works well for that case, I'll start to use it yesterday!

>Clojure: "Scheme on the JVM"

That would be Kawa (http://www.gnu.org/software/kawa/).

Nim: What Python3 should've been.

Put that up, and allow integrate CPython 2.7 into Nim's output binaries for use of interfacing with Python2 libraries through Nim code... and you have yourself a serious contender for picking off many Python refugees and some serious traction within industry too.

> Nim: "no idea what to write here"

That's a good point. One could try "faster, safer Python" here, but I agree that it should be discussed and made official, so that anyone seeing Nim's homepage would immediately know what it's about.

Main problems people have with Python are:

-very slow

-GIL

-not enough type checking

Nim fixes those while keeping things which attract people to Python in the first place. It should be enough of a selling point.

I write most of my code in C + Python (and sometimes in Python + C). For me Nim ticks all the boxes, even the minor ones (how syntax looks etc.). I can't wait to give it a try once I am done with my current project.

Exactly. This is why I mostly agree with the comment which said that Nim should be advertised directly to Python programmers. Pythonistas have a hard time finding a language which would be faster, lower-level but still elegant, simple and expressive - and Nim is a solid candidate here. It's not 100% aligned with Python design, but it's much more similar to Python than Go is.

http://hookrace.net/blog/what-is-special-about-nim/