Hacker News Reader

Comment by kristoff_it | Hacker News Reader

>What are the improvements i should expect in zig compared to C ?

>And how does zig stdlib compare to something like the go stdlib

the stdlib is still work in progress and not the current focus of development. right now things get added to it organically (ie things needed by the compiler itself, the toolchain, or as a proof of concept for other important functionality, like an event loop). as we move forward we will have a phase where we make a final decision on what should stay in, what should be improved, and and what should be cut.

In the meantime you can quickly get a feel for what's in the stdlib by browsing the online docs:

https://ziglang.org/documentation/master/std/

View on HN

i just read the doc and saw a page saying stdlib only targets x86 arch at the moment ? so no arm ?

According to https://ziglang.org/documentation/master/#Targets the only fully supported targets are x86-64. This does not mean that the entire stdlib will only work on x86-64 but that specific functions that require information about the inner workings of an architecture is only guaranteed to work on x86-84.

If you'd be interested in a hash function like CRC32 you can see in the source code that there is no dependency on arch specific functionality, which makes it likely that it will work fine on other (LE?) architectures. This is on a case-by-case basis at the moment though. The advice from the Zig community is to check the source code in case of doubt. I have always found the source to be accessible, so this hasn't been an issue for me.

nah that's absolutely not the case, we support a bunch of architectures (with varying degrees of support level). can you link to the page that said that?

this is the most up to date support table for Zig:

https://ziglang.org/download/0.10.0/release-notes.html#Suppo...

sorry, i can't find the link back. Maybe it wasn't on the official site but from an old website.

Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ?

I'm honestly halfway to try and prototype some cross-platform lib for my mobile app using zig, but this part is really the one that bugs me. I'm fine with having no GC or no ARC like go or swift, (and i'm ok with no ownership mechanim like rust), but seeing absolutely nothing new since C on that side is both a surprise (since zig has improved other aspects like slices and fat pointers), and a worry.

The GeneralPurposeAllocator will tell you about memory leaks and double frees in debug mode. Take a look at the example on the front page of ziglang.org.

That said, the main feature that Zig offers for avoiding those mistakes are defer and errdefer, those really go a long way in avoiding mistakes, while also keeping things simple and explicit, which also helps avoid bugs.

ArenaAllocator is another thing that helps with memory safety, depending on what you're doing.

Finally, having to pass an allocator explicitly to all the things that need to allocate also helps with that: if you have an allocator to a struct when initing it, then you know you will most probably have to call its deinit method once you don't need it anymore.

> Another question i have : are there any kind of mechanism to ensure at least some kind of memory safety with regards to memory deallocation ?

In general you probably need to learn about custom allocators and how different kinds can help you manage your memory. This applies to pretty much any lower-level language, but Odin, Zig, C++ and a few others have explicit support for this in their standard libraries.

Reply on news.ycombinator.com