71–80 of 181 posts
A 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.
Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.
Really seems like something that should be a lint rule..
Earlier quoted context omitted.
Unsure what "massive concurrency means". As far as I'm aware zig offers no special primitives for threading (other than tools in a standard library to start/stop threads and such). Async/await/suspend/resume are features used for concurrency (yielding on a single thread). You then use those primitives to implement parallelism however you want. Just like you'd do in C. Or, ykno, someone makes a library that does green…
So Go has a two things that enable massive concurrency. 1. Coroutines have dynamic stacks, meaning that you can start a lot of threads without exhausting your memory: https://medium.com/a-journey-with-go/go-how-does-the-gorouti... 2. Go has a lightweight threading model that doesn't map one thread to one OS/kernel level thread. Enabling you to have thousands of threads operating at once. limited by GOMAXPROCS. I was…
There is one event loop in the stdlib, but it has some limitations and there is some discussion to change it or remove it https://github.com/ziglang/zig/issues/8224
Some Zig libraries implementing an event loop:
- libxev by Mitchell Hashimoto https://github.com/mitchellh/libxev
- one from the Tigerbeetle DB https://github.com/tigerbeetledb/tigerbeetle/tree/main/src/i...
They both use kernel concurrency features (io_uring/epool on Linux, kqueue on MacOS). They are quite low level and do not implement a lightweight threading model comparable to Go concurrency.
Is it a good alternative to Go? How is interoperability?
Of course you have more to handle by yourself in Zig. For example a simple string concatenation will need more work as there is no implicit heap allocation.
For interoperability with Go it's quite the same than CGo through Cgo: doable but not ideal.
However the Zig toolchain can be used to improve the build system of Go projects with Cgo dependancies. That's what Uber is doing https://jakstys.lt/2022/how-uber-uses-zig/
Earlier quoted context omitted.
> No objects, just structs C doesn't have 'objects' either, just structs. In Zig you can add functions to structs though, and you have UFCS syntax sugar, both together is pretty close to class methods ;) Those sentinel terminated arrays are a killer feature for C API interop, since you don't need to allocate separate C strings on the stack or heap just for passing string literals into the C API (Zig string literals a…
I think one of the author's problems is that he conflates C and C++ and it seems they do not have a knowledge around either. This quote also supports this: > There is no malloc keyword like in C/C++.
https://en.cppreference.com/w/c/memory/malloc
and a standard library function in C++
https://en.cppreference.com/w/cpp/memory/c/malloc
?
I don’t know why these new languages have to have their own special takes on loops without giving us the classic C99 version of the three-clause-for-loop. Even JavaScript has it. If they want to improve on it, then allow us to declare variables of different types in the first clause. Yes, using the C-style loop to iterate over a container sucks, but that is an argument for also having a for-each loop. There are lots…
C-style for loops can almost always be replaced with iterators in a more concise manner. No need for the explicit termination check or the explicit advancement expression, that's already handled by the iterator.
Does Zig still have that insane compiler enforced no unused variables policy? Honestly, that is such a stupid thing that it literally kept me away from the language, which I otherwise find interesting for its niche.
Product of the creator's will. Andrew is confident that always rejecting programs with unused variables catches bugs, and he believes that if you don't like this you should have software to adapt the Zig you write so that it compiles, by adding or removing _ = unused_variable; style statements to consume the otherwise unused variables. There can be a benefit to a singular coherent vision behind something - committees…
I honestly can't think of one.
Earlier quoted context omitted.
I think one of the author's problems is that he conflates C and C++ and it seems they do not have a knowledge around either. This quote also supports this: > There is no malloc keyword like in C/C++.
Are you nitpicking about it being a keyword in C, https://en.cppreference.com/w/c/memory/malloc and a standard library function in C++ https://en.cppreference.com/w/cpp/memory/c/malloc ?
(It is conjuring things from "nowhere" in the higher level language, obviously normal functions aren't supposed to just make objects, only transform them - but this can, so that's magic)
Earlier quoted context omitted.
Are you nitpicking about it being a keyword in C, https://en.cppreference.com/w/c/memory/malloc and a standard library function in C++ https://en.cppreference.com/w/cpp/memory/c/malloc ?
That's not a keyword. It's just a free function, maybe you could argue it is an intrinsic since it's magic and needs to some extent to be blessed by the implementation (It is conjuring things from "nowhere" in the higher level language, obviously normal functions aren't supposed to just make objects, only transform them - but this can, so that's magic)
Earlier quoted context omitted.
> I really wish Rust would use the same idea, it would simplify creating C API wrappers a lot. Zero terminated strings suck , you need to do allocation everywhere to work with them, or else you must in-place mutate the strings in hard to reason about ways and they can't fully represent arbitrary text. So I definitely wouldn't want Rust's &str string references to have either behaviour. If what you do is interact clos…
Well yeah, zero terminated strings suck, but that doesn't change the fact that pretty much all operating systems and fundamental C libraries expect strings to be zero terminated, it's not just a C quirk anymore, but burned forever into operating system ABIs too. A programming language which is supposed to interact with those APIs directly really shouldn't make this harder than it needs to be, and Zig's sentinel-termi…