Show HN: Wireworld written in Nim

It was complete coincidence. I was trying to think of something fun, and slightly more complicated than hello world or the simple dice roller I whipped up.

Your GoL implementation is so pretty though. I really need to work on my design skills.

I've worked with Nim's sdl2 interface too, it is indeed pretty straightforward, and it was easy for me to tell vim to know how to jump to the nim wrapper's source. The main pain points for me were 1) sdl2 is harder than sdl1 and 2) I thought some type conversion behavior (or lack thereof) was odd, especially when working with 'cints' (which is what the wrapper api expects everywhere).

For a more flushed out example there's: https://hookrace.net/blog/writing-a-2d-platform-game-in-nim-...

It was pretty straightforward. I had never had any experience with SDL before, and I figured it out pretty quickly just from comments and the function names.

I did use a tiny bit of code from the tutorial on 2D platformers linked by someone else.

I'm surprised it was that brief actually. I didn't even try for brevity. And I'm sure if I had a better handle on some of the other features like macros and templates it could have been much more elegant in the display/SDL code.

The actual implementation of the automaton is only about 70 lines of code if I remember correctly.

Thank you! I want to write the loading logic to get the insanely complex systems like the one you linked. I'm curious to see what the performance will be like.

To me it seems just the right choice for embedded systems: fast, small, easy to understand and translates to C.

Coming from C++ (with C experience too), I too was hesitant about Nim because of GC. But I can turn it off completely or even better "--gc=stack" which makes it behave like C++ (dealloc when going out of scope). The compiler is also good at telling you what calls use GC'ed memory, so you can work around them if necessary.

But even with GC on, Nim is super fast. I use it in real time rendering and I honestly didn't see any significant performance loss. In fact, it made some routines much faster because the Nim compiler produced much better C code than I ever did.

Common sense says that non-GC languages should beat GC languages, but there are actually cases where GCs can be faster. In particular, allocating memory can be just incrementing a pointer with a GC, whereas malloc does some more bookkeeping. You pay the price later during garbage collection, but if you are lucky your process is idle at that time, or even better, it is finished, and you get cleanup for free. See also https://stackoverflow.com/a/6977194/143091 What's faster will vary a lot from case to case.

(Of course, deep down the stack is always a non-GCed language, or at least assembly, so if your GC language wins a benchmark, you can always write that same program + the GC runtime in a non-GC language... but that is a trivial observation. Nim compiles to C, so is it GC'ed or not?)