News for hackers. Stuff that matters.
Re:Nim Apocrypha, Vol. I by kaba0 on Wednesday December 23, 2020 @01:54PM (#25520767)
As for the latter: Or you know, most applications don’t need manual memory management because more often than not, programmers WILL get it wrong. Unless you really need that level of control over the hardware, you ARE better off with a good runtime env
Re:Nim Apocrypha, Vol. I by jstimpfle on Wednesday December 23, 2020 @02:55PM (#25521466)
That may be, but personally I am interested in those applications - GUI work, signal processing, low-latency networking.
Re:Nim Apocrypha, Vol. I by elcritch on Wednesday December 23, 2020 @04:33PM (#25522472)
Nim, with the new ARC garbage collector works well for those situations now (well within a few percent usually). Especially with the `move` and `sink` semantics.

I'm using it in embedded devices and needed a few tight loops a week or two back. With a bit of work and a few odd contortions, I got it to compile to almost the exact type of C code I'd write by hand to run a fast inner loop using preallocated arrays, etc. It turns out that code wasn't noticeably faster than more idiomatic Nim code with a few tweaks to ensure move's were able to be used. So I ended up going back to the more readable/idiomatic version while still roughly doubling the overall speed.

The new `move` semantics with Nim's ARC system really do help make it easier to write fast code. Now I understand why the C++ ecosystem is so bullish on `move` in the C++ stdlib now. It really can take code which looks like straightforward C code but performs closer to painstakingly optimized C code. Mainly since it result in less copying of objects/structs and reducing the number of malloc's. Overall it means less effort to design a fast system.