31–40 of 60 posts
It should be better noted on this website, but this is not the official Zig guide - which can be found here: https://ziglang.org/learn/
(And while yes, Zig does make reference to zig.guide because it's very helpful and people appreciate the effort put into it - but it's still under the other online learning resource section, not official documentation section)
I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…
Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practi... . More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I a…
Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true.
And if it's not the latter, then it's not a failure of memory safety as most people mean it.
Earlier quoted context omitted.
Since c abi powers the world, with zig’s ability to easily wrap c libs, not only does zig have access to all libs; it also makes it easy to integrate zig with any existing project as most programming languages have integration with c. This is why everybody says just use some existing c lib
Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second. I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairl…
Earlier quoted context omitted.
Hmm. I could substitute lots of languages for zig in that first sentence. But that doesn't invariably lead the communities that maintain those languages to utter the second. I also doubt I have space to enumerate the languages that claim to "easily wrap c libs." None of them easily do that. That statement imagines that there's some basic consistency between APIs (and that those APIs are asking for and returning fairl…
I would argue zig had the best c integration. This is why it’s different.
I know it is not a popular view, but I really hope Zig becomes as stable in language design as C. I am tried of language design as an endless project of 'change because we can'. I switched from objective-c to swift thinking job done, and felt like I was learning a new language with each new version. I ended up switching back to objective-c. I think Java had a good start by defining a solid language spec (JLS) up fron…
What? Go is one of the most stable languages I can think of. What churn are you referring to?
I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…
I love Zig and I love that it’s getting attention, but can someone convince me of its memory safety? One thing that surprised me is that returning pointers to stack-allocated memory doesn’t cause a compiler error — it just segfaults at runtime. This has been an open issue since 2019 [#1]. That, along with the number of memory-related issues in one of Zig’s most popular project, Bun.js [#2], gives me pause. [#1]: http…
Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practi... . More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I a…
Earlier quoted context omitted.
Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Sanitation is very much possible, so it is no design problem, see https://matu3ba.github.io/articles/optimal_debugging/#practi... . More interesting would be threading and process/shared memory synchronization problems and limitations. At least on Linux in theory the latter should be fuzzable with scheduler API, but I a…
> Neither Rust is memory safe due to stackoverflow on recursion or in the call chain being possible. Does a stack overflow trigger a crash, or does it cause undefined behavior and/or remote code execution? You'd have a point if it's the latter, but I also assumed that I would have heard about it before if that were true. And if it's not the latter, then it's not a failure of memory safety as most people mean it.