| Slightly on a tangent here. But i think someone with more knowledge of either the zig implementation/language or programming language and runtime in general should take a second pass at Zig's wikipedia page.
I see a lot of assertion which doesn't seem substantiated by the provided references, some of the reference almost look unrelated and some stuff also look wrong ( i am not a zig experts) > The goals of Zig are in contrast to the many similar languages introduced in the 2020s time-frame, like Go, Rust, Carbon, Nim and many others. Generally, these languages are more complex with additional features like operator overloading, functions that masquerade as values (properties), generic types and many other features intended to aid the construction of large programs. These sorts of features have more in common with C++'s approach, and these languages are more along the lines of that language.
> reference (https://www.infoworld.com/article/3113083/new-challenger-joi...) The provided reference doesn't really mention this statement, and C++ did not originate a lot of those features. On a more abstract level, no having abstraction features doesn't always make a language simpler. > A common solution to these problems is a garbage collector (GC), which examines the program for pointers to previously malloced memory, and removing any blocks that no longer have anything pointing to them. Although this greatly reduces, or even eliminates, memory errors, GC systems are relatively slow compared to manual memory management, and have unpredictable performance that makes them unsuited to systems programming. > reference (https://docs.elementscompiler.com/Concepts/ARCvsGC/) I am not sure how authoritative the given reference is, but even assuming it is, there is no mentions on manual vs GC speed, or anything about how GC systems are inadequate for system programing (what ever that means in this context). I know the the memory management styles trade-off are still hot debates, and a lot of progress have been made with regard to modern implementation. > Another solution is automatic reference counting (ARC), which implements the same basic concept of looking for pointers to removed memory, but does so at malloc time by recording the number of pointers to that block, meaning there does not need to perform an exhaustive search, but instead adds time to every malloc and release operation. This doesn't sound like the best way to describe ARC..., again the provided references doesn't substantiate this definition. > Zig aims to provide performance similar or better than C, so GC and ARC are not suitable solutions. Instead, it uses a modern, as of 2022, concept known as optional types, or smart pointers. I don't think smart pointer and optional types are the same. Quickly glancing at zig official website , this looks like a mistake > Instead of a pointer being allowed to point to nothing, or nil, a separate type is used to indicate data that is optionally empty. This is similar to using a structure with a pointer and a boolean that indicates whether the pointer is valid, but the state of the boolean is invisibly managed by the language and does not need to be explicitly managed by the programmer. So, for instance, when the pointer is declared it is set to "unallocated", and when that pointer receives a value from a malloc, it is set to "allocated" if the malloc succeeded. Mixing optional types and they way zig uses it to represent references. |