Compile time evaluation in Nim, Zig, Rust and C++

Re:Compile time evaluation in Nim, Zig, Rust and C++ by elcritch on Tuesday April 26, 2022 @05:37AM (#31165531)

I think the biggest issue is that Nim took a long time to “find its feet”. There was a lot of experimentation before the current sweet spot. Due to its new GC system ‘ARC’ it’s now broadly useable as a systems language, which wasn’t true before with a regular GC. ARC is non-atomic/non-locking reference count based, meaning it can be used to as a systems language (no GC pauses) or for system libraries (C programs can use it).

There’s a few awkward-ish parts of the syntax, but in practice those items aren’t big issues (compared to say Rust async syntax issue). For example multi-line lambdas can be done with ‘do’ blocks or just wrapping parens. Identifier equality has actually saved me from a few bugs by accidentally creating a new similarly named variable, say an ‘isDone’ when I already had an ‘is_done’ following the style from C FFI. Though the compiler warns by default when mix naming styles, and can be set as an error if desired.

Iterators usage can be a bit annoying though. I also really enjoy UFCS: https://en.m.wikipedia.org/wiki/Uniform_Function_Call_Syntax

Python comparison example: https://narimiran.github.io//2018/05/10/python-numpy-nim.htm...

[ Parent | on HN ]

Re:Compile time evaluation in Nim, Zig, Rust and C++ by coliveira on Tuesday April 26, 2022 @03:40PM (#31172197)

ARC is not new, it was used by Apple in their languages for at least 10 years now.

[ Parent | on HN ]

Re:Compile time evaluation in Nim, Zig, Rust and C++ by ______-_-______ on Tuesday April 26, 2022 @03:52PM (#31172329)

Obviously parent is not claiming that Nim invented the concept of reference counting. They're saying that it's a recent addition to Nim, and Nim's other memory management strategies have been part of the compiler for longer.

[ Parent | on HN ]

Re:Compile time evaluation in Nim, Zig, Rust and C++ by elcritch on Tuesday April 26, 2022 @11:22PM (#31175951)

That and that Nim's ARC system extends the concept a bit further to include move semantics and limited ownership rules. Nim had a traditional RC garbage collector before, but ARC is case where "the whole is greater than the sum of parts".

Swift and Obj-C's ARC system relies on atomics and their associated issues (explained well here: https://news.ycombinator.com/item?id=15046481).

Nim's ARC system relies on ownership rules that require a single thread to "own" any ARC-managed memory which removes the need for locks or atomics in the reference counts. That eliminates the non-determinism of locks & atomics when doing the RC accounting, overall improving latency and performance. Move semantics increase performance and enables "giving" ownership of ARC-managed memory to another thread.

[ Parent | on HN ]