News for hackers. Stuff that matters.
Re:Nim Apocrypha, Vol. I by jstimpfle on Wednesday December 23, 2020 @11:18AM (#25519142)
There is also "Rust is fine once you know how to not get burnt by the type system, and if you carefully choose your dependencies it will maybe still be able to start a build of your project a month from now, and if you're lucky it will build in less than a lifetime".

Or "Java is fine if your fingers aren't sore yet and if you don't mind the latency spikes for your interactive application or if you're basically programming like C with training wheels and less performance".

;-)

Re:Nim Apocrypha, Vol. I by earwaxauditor on Wednesday December 23, 2020 @12:03PM (#25519607)
At least “this code doesn’t compile” isn’t a potential security vulnerability.
Re:Nim Apocrypha, Vol. I by wffurr on Wednesday December 23, 2020 @03:38PM (#25521922)
That's exactly the point I was trying to make.
Re:Nim Apocrypha, Vol. I by jstimpfle on Wednesday December 23, 2020 @02:56PM (#25521476)
Sure, and projects that never ship aren't either.
Re:Nim Apocrypha, Vol. I by earwaxauditor on Wednesday December 23, 2020 @03:31PM (#25521837)
I think you should lighten up ;)
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.