Zig: The Modern Alternative to C
infoworld.com
Zig: The Modern Alternative to C
1–10 of 181 posts
Re: Zig: The Modern Alternative to C
#2A short and clear introductory overview.
Re: Zig: The Modern Alternative to C
#3What is Zig's async story? Is there something like Go's coroutines?
Re: Zig: The Modern Alternative to C
#4You know what you doing. Move Zig. For great justice
Re: Zig: The Modern Alternative to C
#5Is it a good alternative to Go? How is interoperability?
Re: Zig: The Modern Alternative to C
#6A quote from the article:
> A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library.
I guess it is all you need to know about the article quality.
Re: Zig: The Modern Alternative to C
#7After using zig for a few projects, it's amazing how it feels similar to C when coding.
Re: Zig: The Modern Alternative to C
#8A quote from the article: > A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library. I guess it is all you need to know about the article quality.
The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.
Re: Zig: The Modern Alternative to C
#9What is Zig's async story? Is there something like Go's coroutines?
No, it's 'code transform' async-await as is fashionable these days, but with the advantage that it's 'color blind' (the compiler will do the async transform or not based on the caller's expectation).
Re: Zig: The Modern Alternative to C
#10A quote from the article: > A distinctive feature of Zig is that it does not deal with memory allocation directly in the language. There is no malloc keyword like in C/C++. Instead, access to the heap is handled explicitly in the standard library. I guess it is all you need to know about the article quality.
The point that paragraph is trying to make but articulates imperfectly is that you explicitly pass an Allocator to the stdlib routines that allocate -- rather than having them allocate on the heap implicitly.
Yes, but it still is a part of the standard library and how the standard library does things - a convention. Same as in C, as malloc is just a function. You could create a replacement library for C stdlib and it could also expect an allocator in the parameters if a given function could allocate.