Author here, I spent this weekend making an implementation of a lesser known (to me at least) cellular automaton, Wireworld.
It was my first non-trivial project in Nim. I had a lot of fun. It uses SDL 2 as the graphics engine. Let me know if you have any little suggestions for it, or any questions about the development.
> Everyone knows the classic example of cellular automata, Conway’s Game of Life. Instead of rehashing an implementation of that, I wanted to build something just a little bit different while learning the Nim language.
Haha, nice catch because I just did that on the other thread ;) https://news.ycombinator.com/item?id=14387684 boring implementation of the classic game of life. I don't know if it's a pure coïncidence or not but I'll have a look at your repo, nice work !
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.
Great implementation. I love the wireworld cellular automaton so much.
A while back I implemented it in typescript and ran the computer startup file through it for the web. It is such a fun piece of logic to squeeze every nanosecond of performance out of.
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.
This is the file for the computer, shoot me an email if you ever get around to implementing it. I'd love to see the result and talk about optimizing! dested at gmail
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).
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.
It's cool to see Nim getting more visibility. It's a cutting-edge language that gets overshadowed just because it doesn't have MegaTechCo's name behind it.
This is really well written, thank you for taking the time to post it to HN to give Nim a bit of visibility. Have you considered using Nim's JS back end to make it work in the browser?
Nim is probably the most easiest language I've picked up. It's a delight to program in Nim and the performance is stellar (beats hand coded C in many cases). It's a rare feat really.
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.
This is what I experienced with GC enabled systems programming languages (Oberon family of languages) back in the late 90's, just with C++ as comparison on my case.
The main problem is the culture of micro-optimizing code without profiling it, that is so prevalent in those communities.
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?)
It was my first non-trivial project in Nim. I had a lot of fun. It uses SDL 2 as the graphics engine. Let me know if you have any little suggestions for it, or any questions about the development.