Nim 1.4

A small perspective insight from a game developer:<p>We (Beamdog) are using nim in production for Neverwinter Nights: Enhanced Edition, for the serverside parts of running the multiplayer infra.<p>nim is uniquely good in providing an immense amount of value for very little effort. It gets _out of my way_ and makes it very easy to write a lot of code that mostly works really well, without having given me any serious traps and pits to fall into. No memleaks, no spurious crashes, no side-effect oopses, anything like that. It&#x27;s C&#x2F;++ interop has been a huge enabler for feature growth as well, as we can partly link in game code and it works fine. For example, our platform integrates seamlessly with native&#x2F;openssl&#x2F;dtls for game console connectivity. And it all works, and does so with good performance. It is all now a set of quite a few moving components (a message bus, various network terminators, TURN relays, state management, logging and metrics, a simple json api consumed both by game clients and web (<a href="https:&#x2F;&#x2F;nwn.beamdog.net" rel="nofollow">https:&#x2F;&#x2F;nwn.beamdog.net</a>), ...).<p>We&#x27;re still lagging behind and are on 1.0.8, but that is totally fine. It&#x27;s tested and works, and there&#x27;s no real incentive to move to 1.2 or 1.4 - yet!<p>Usage for our game has expanded to provide a few open source supporting utilities (<a href="https:&#x2F;&#x2F;github.com&#x2F;Beamdog&#x2F;nwsync" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Beamdog&#x2F;nwsync</a>) and libraries (<a href="https:&#x2F;&#x2F;github.com&#x2F;niv&#x2F;neverwinter.nim&#x2F;" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;niv&#x2F;neverwinter.nim&#x2F;</a>) too. The good part about those is that they are cross-platform as well, and we can provide one-click binaries for users.<p>OTOH, There&#x27;s been a few rough edges and some issues along the way. Some platform snafus come to mind, but those have been early days - 0.17, etc. Some strange async bugs had been found and fixed quickly though.<p>Good and bad, at least for me, nim has been a real joy to work with. If I had the chance to message my 3-years-younger, I&#x27;d just say &quot;yea, keep going with that plan&quot;, as it turned out to save us a lot of development time. I suspect the features we&#x27;ve put in wouldn&#x27;t have been possible in the timeframe we had, if it would have been all written in, say, C++.

Since Nim has hit the front page twice in the past day, let me just say: if you&#x27;re at all curious about the language, try it out over the weekend. Nim isnt quite as simple as Zig (to compare to another compiled language with a smaller ecosystem), but the more advanced features stay out of the way until you need them. If you&#x27;ve worked with any static language, you probably know 80%-90% of what you need to write productive Nim code. The dev team has worked hard over the past year to improve documentation, and the website links to some great tutorials.

I&#x27;m going to do a little bit of a shameless plug as a way to show off just what Nim is capable of. If you&#x27;ve ever played one of the many IO games, it might seem familiar to you. Basically I have used Nim to create a multiplayer game that can be played in the browser[1].<p>I&#x27;m planning to write up a more detailed post outlining the architecture of this. But suffice it to say, Stardust is written 100% in Nim. Both the servers and the client running in your browser is written in Nim. The client uses Nim&#x27;s JS backend and the server Nim&#x27;s C backend. The two share code to ensure the game simulation is the same across both. Communication happens over websockets.<p>It&#x27;s been a lot of fun working on this and I cannot imagine another language being as flexible as Nim to make something like this possible. I already have an Android client up and running too, it also is built from the same code and I plan to release it soon.<p>1 - <a href="https:&#x2F;&#x2F;stardust.dev&#x2F;play" rel="nofollow">https:&#x2F;&#x2F;stardust.dev&#x2F;play</a>

An economic argument for GC instead of ARC&#x2F;ORC.<p>Commercial web application in Java. Java GC is concurrent, on other cpu cores than the cores processing customer requests. Modern GCs such as Red Hat&#x27;s Shenandoah or Oracle&#x27;s ZGC have 1 ms or lower pause times on heap sizes of terabytes (TB). Java 15 increased max heap size from 4 TB to 16 TB of memory.<p>Now the argument. A thread running on a cpu core which processes an incoming request has to earn enough to pay the economic dollar cost of the other threads that do GC on other cpu cores. But that thread processing the client request spends ZERO cpu cycles on memory management. No reference counting. Malloc is extremely fast as long as memory is available. (GC on other cores ensures this.) During or even after that thread has serviced a client request, GC will (later) &quot;dispose&quot; of the garbage that was allocated when servicing the client request.<p>Obviously, just from Java continuously occupying the top 2 or 3 spots for popularity over the last 15 years -- Java&#x27;s approach must be doing something right.<p>That said, I find Nim very interesting, and this is not a rant about Nim. I am skeptical of an alternative to real GC until it is proven to work, in a heavily multi threaded environment. And there is that economic argument of servicing client requests with no cpu cycles spent on memory management -- until AFTER the client request was fully serviced.

There are a lot of gotchas with the new GC that make me nervous about this release:<p>&gt; As far as we know, ARC works with the complete standard library except for the current implementation of async...<p>That&#x27;s not a great endorsement...<p>&gt; If your code uses cyclic data structures, or if you’re not sure if your code produces cycles, you need to use --gc:orc and not --gc:arc.<p>Seems like this is a big onus to put on the user -- it&#x27;s tough to prove a negative like this.

Awesome to see 1.4 finally released, and to have a version that should hopefully build cleanly out of the box on OpenBSD and FreeBSD and mostly &quot;just work&quot;[1]. Next target is NetBSD[2] then DragonFly!<p>1. <a href="https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;Nim&#x2F;issues&#x2F;14035" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;nim-lang&#x2F;Nim&#x2F;issues&#x2F;14035</a> 2. <a href="https:&#x2F;&#x2F;forum.nim-lang.org&#x2F;t&#x2F;6610" rel="nofollow">https:&#x2F;&#x2F;forum.nim-lang.org&#x2F;t&#x2F;6610</a>

I was skeptical towards Nim. Then I wrote a small program that uses SDL2, and compared it to the same program written in over 10 other programming languages. Nim has an excellent combination of ease of use and performance.

Great to see that Nim grows ever faster and more stable. Been a fan of the language for quite a while now and while I miss the old days of new and exiting changes with every release it&#x27;s much easier to target Nim now that it has become this stable. Great work all around!

I played around with Nim a little and was amazed at how small the executables were: 10s of KB for something simple. Even Rust spits out 100s of KB, or even &gt;1MB by default.<p>In the end I still went with Rust, simply because it&#x27;s more popular, but my initial impression was that Nim is a really fun language to work in, and much <i>much</i> easier to pick up than Rust.

Great stuff! GC ORC is an amazing improvement over existing memory management models :) I hope to see more Nim projects adopt it!

So one of the biggest improvements to my day-to-day life as a programmer was having compiler-checked nullability in Kotlin. It is the most significant feature that makes programs more reliable and code more readable compared to Java. I never want to miss it again.<p>Why did Nim decide to allow null pointers? They must have had a very good reason, given its young age?

Congratulations! And thanks for all the progress on ARC&#x2F;ORC. But I must say, even though I&#x27;m excited about ARC&#x2F;ORC, I&#x27;m even more happy to see the nice list of bugfixes and quality standard library additions!!

Nim is a lot of fun to write, and the language is small enough that you could build something fun &#x2F; useful in a weekend. The community is also very responsive. Definitely worth checking out!

Web development.<p>I’ve said it before and I’ll say it again ... I wish more folks would use NIM for web development.

Maybe my lack of lower level language knowledge will show here, but how does that compare to Rust? I keep seeing and hearing about these new-ish languages Rust, Nim, Zig, etc. that all claim to be C&#x2F;C++ perf lvl but better developper experience. Any of these is preferred for API&#x2F;Web development? Does it yield much advantage over something like Elixir that already provides significant perf increase over a Python(Django-Flask)&#x2F;RoR stack?

I am using nim this week on a data file scraping project. If you can Google and write python you can just start with nim and learn as you go, very easy.<p>I am super bummed that there is (effectively) no debugging. I am too lazy to mess with VS code to get gdb working, it should just work already. Someday, I guess. Maybe jetbrains will save us. With real IDE support nim would sweep the nations.

I am intrigued by Nim. Anyone know of the motivation for Nim? I was not able to find that out in their website.

Great! Where&#x27;s the announcement on <a href="https:&#x2F;&#x2F;twitter.com&#x2F;nim_lang" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;nim_lang</a> so I can retweet it?

&gt; The reason is that only after the new(result, finalizer) call the compiler knows that it needs to generate a custom destructor for the CustomObject type, but when it compiled tricky the default destructor was used.<p>I&#x27;m wondering why people underestimate graphs that much. It&#x27;s lot easier to explicitly represent dependencies between your definitions as a graph and not just avoid such issues but also get rid of unnecessary passes. I did that in my compiler and it works great.

NIM and Red (also on HN today) seem both seem to have an interesting and intersecting feature set. Anybody here used or heavily evaluated both that can comment?

Nim or Julia?

It is nice with a lot of innovation now in the ahead-of-time compiled languages camp.<p>What worries me is the fragmentation, and the fact that no one language seems to check all of the (subjective set of) boxes for a general purpose high-speed, ahead-of-time compiled language [0].<p>E.g, Crystal seems to be the only one supporting a modern concurrency story (similar to Go), but has a huge problem with compile times.<p>Nim looks nice in many respects, but last I checked, they don&#x27;t have anything like Go-like concurrency. Maybe not on everyone&#x27;s wishlist, but as the world move toward flow everything&#x2F;everywhere[1], I personally find this to be a problem.<p>[0] <a href="https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1BAiJR026ih1U8HoRw__nzbCSFnnHicWrjxpW5l6-O3w&#x2F;edit#gid=0" rel="nofollow">https:&#x2F;&#x2F;docs.google.com&#x2F;spreadsheets&#x2F;d&#x2F;1BAiJR026ih1U8HoRw__n...</a><p>[1] <a href="https:&#x2F;&#x2F;www.amazon.com&#x2F;Flow-Architectures-Streaming-Event-Driven-Integration&#x2F;dp&#x2F;1492075892&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.amazon.com&#x2F;Flow-Architectures-Streaming-Event-Dr...</a>