Earlier quoted context omitted.
Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code…
"Like unsafe Rust, but more convenient to use" is basically every imperative language around there, I still don't understand the specific niche that Zig intended to fill
My Software North Star
121–130 of 166 posts
Re: My Software North Star
#122I imagine it's a difficult time to be a Zig developer. In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage. But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig…
1. Fixing memory errors wasn't the reason the project migrated to Zig, but a beef between the Bun maintainer not getting his own changes in the upstream compiler and the Bun's new employer focus on Rust. 2. You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), let alone in Zig which provides more tools to write memory safe code. 3. AI can write very good Zig already. This isn't 2024 anymore where "t…
Do you think that this is a list of software that have never had memory bugs? It really is not practically possible to completely avoid a large class of memory bugs in C in just about any kind of very large commercial or open source codebase.
Redis
CVE-2025-49844 ("RediShell"): use-after-free in bundled Lua parser https://github.com/redis/redis/security/advisories/GHSA-4789...
CVE-2022-24834: heap overflow in Lua cjson/cmsgpack https://github.com/redis/redis/security/advisories/GHSA-p8x2...
CVE-2021-32761: OOB read / integer overflow in BIT commands https://security-tracker.debian.org/tracker/CVE-2021-32761
CVE-2023-41056: heap overflow on buffer resizing https://github.com/redis/redis/releases/tag/7.0.15
CVE-2021-32765: integer overflow to heap overflow in hiredis https://github.com/redis/redis/security/advisories/GHSA-833w...
Sqlite
CVE-2020-11656: use-after-free in ALTER TABLE https://bugzilla.redhat.com/show_bug.cgi?id=1824185
CVE-2022-35737: array-bounds overflow in printf engine https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability...
CVE-2023-7104: heap overflow in session extension https://sqlite.org/forum/forumpost/5bcbf4571c
CVE-2020-9327: NULL pointer dereference in isAuxiliaryVtabOperator https://nvd.nist.gov/vuln/detail/CVE-2020-9327
CVE-2019-9936: heap over-read in FTS5 https://nvd.nist.gov/vuln/detail/CVE-2019-9936
OpenBSD
CVE-2023-25136: pre-auth double-free in OpenSSH sshd https://seclists.org/oss-sec/2023/q1/92
CVE-2022-27882: heap overflow in slaacd https://blog.quarkslab.com/heap-overflow-in-openbsds-slaacd-...
errata 70/003: kernel memory leak closing unix sockets https://www.openbsd.org/errata70.html
errata 74/018: buffer over-read in sndiod https://www.openbsd.org/errata74.html
errata 78/013: use-after-free in httpd chunked encoding https://www.openbsd.org/errata78.html
Git
CVE-2022-41903: OOB write in pretty.c format_and_pad_commit() https://github.com/git/git/security/advisories/GHSA-475x-2q3...
CVE-2022-23521: OOB write/read in .gitattributes parsing https://nvd.nist.gov/vuln/detail/cve-2022-23521
CVE-2022-39260: heap overflow in git shell split_cmdline() https://github.com/git/git/security/advisories/GHSA-rjr6-wcq...
CVE-2016-2315: heap overflow in path_name() https://bugs.launchpad.net/bugs/cve/2016-2315
CVE-2016-2324: integer overflow to heap overflow (nested trees) https://nvd.nist.gov/vuln/detail/CVE-2016-2324
Re: My Software North Star
#123Earlier quoted context omitted.
Agreed unfortunately, if Zigs whole selling point is meant to be a "nicer C" (and a much nicer DX than Rust because no fighting the borrow checker etc) - does that really matter in a world where an LLM is writing the code? I am not going to be fighting the borrow checker, the LLM is. And as always, the response you'll hear is: but AI sucks/hallucinates/could never replace me etc... Just look at the progress LLM'S hav…
Why would *any* programming language matter when LLMs can just directly output binaries from a sufficiently detailed spec ;) And specifically, why would Rust be a better choice than C or Zig when the LLMs get good enough to just write memory safe code in unsafe languages (they are already pretty good at finding memory safety bugs). IMHO for code generation, different things start to matter (like fast build times, whi…
There is, and always will be, a huge difference between "because a LLM said so" and "here is a proof this is memory safe".
Re: My Software North Star
#124Earlier quoted context omitted.
> In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage. Meanwhile, some projects are doing the opposite, like going from Rust to Zig, here's an example from a podcast I recently listened to: https://www.youtube.com/watch?v=XSXGf3oN2yU Here's the project in question: https://github.com/roc-lang/roc I think Bun…
I wish Roclang well but (as a regular listener to Feldman's podcast) I don't think we can draw many conclusions from this switch other than "Feldman has lots of opinions on lots of things".
Re: My Software North Star
#125Earlier quoted context omitted.
> Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature i…
Grandparent is onto something. You can't define correctness without a spec. And since most business-oriented software, which most of us work with, isn't made against a comprehensive spec, you can argue that anything falling outside it is either a bug or a feature. 'If your disk backup software corrupts backups' has behind it a clean definition that's (pretty) unambiguous and you don't care about, since it's already o…
Sure you can. Correctness doesn't mean "follows a spec", it means "It does what the developer intended it to do without problems".
I mean that casually and within reason, it's not supposed to be a formal statement checkable by proof checker. z
I don't need a spec to know that e.g. my email client has a bug if it crashes when I try to make something bold. The presense of the "Bold" formatting button means it should support it, spec or no spec.
Re: My Software North Star
#126Earlier quoted context omitted.
> Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature i…
My read was they were not saying they’re actually, literally, the same, but for the purposes of prioritization there’s no point in differentiating feature from bug when you use the same “how does this impact my products value to users” as the deciding factor for what gets scoped. It’s an interesting insight but I’m also not sure it’s valuable in practice. Sort of like “we’re just bags of chemicals that tricked rocks…
Then they could just say that, not that in general "a feature is the same as a bug" without qualification.
Re: My Software North Star
#127Earlier quoted context omitted.
> Once you realize that the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features", then you also accept that you will never be done. This doesn't make sense at all. Your email software mangles my email. Or your media player randomly skips. That's a bug. No big philosophy needs to be hidden behind it. That your media player doesn't have the shuffle feature i…
When you're trying to prioritize work , bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that. You want to say that they're not the same kind of work? True. And yet, when you're allocating work , that doesn't particularly matter.
Well, they did claim something more though though: "the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features".
Well, no. Take TeX as an example. It does what it does. Bug are bugs, and they can fix them. Lack of features are not bugs. They can absolutely close to fixing all bugs. And some small programs can be 100% bug free (or close), without considering any rando's future request (which can expand to the thousands unrelated asks you never planned it do) as "a bug".
Re: My Software North Star
#128I imagine it's a difficult time to be a Zig developer. In the near term, Bun choosing to switch from Zig to Rust specifically to fix all the memory errors seems to have done the Zig community some psychological damage. But more significantly, in the medium term it looks likely that AI coding is going to overtake the industry before Zig gets properly established. And it is going to be very hard to justify choosing Zig…
This might be a very naive take on my part, but I don't think of vibecoding as a competitor to actual coding the same way I don't think of doing amphetamines (even if they make you more productive in the short term) as a competitor to being clean. I think it's a self-destructive behavior that is ultimately going to degrade your critical thinking skills, especially if you're a beginner. As with everything, the smarter…
Re: My Software North Star
#129Earlier quoted context omitted.
I don't understand the idea behind Zig. What I have read sounded like "let's make a language like Rust, but not memory-safe", which doesn't make a lot of sense to me.
Even Rust has an unsafe subset. There's a meaningful question about how to make such an unsafe language as easy and comfortable to use as possible, and Zig is a decent answer to that particular question. The libraries Zig ships with are especially relevant here, rather than the core language per se: Rust's library facilities are outright terrible to write unsafe code with, because the usual requirements of safe code…
Re: My Software North Star
#130Earlier quoted context omitted.
When you're trying to prioritize work , bugs and features are the same - they're both demands for developer time. I don't think they were saying anything more than that. You want to say that they're not the same kind of work? True. And yet, when you're allocating work , that doesn't particularly matter.
> I don't think they were saying anything more than that. Well, they did claim something more though though: "the lack of a feature is the same as the presence of a bug then "fixing all bugs" also means "adding all the features". Well, no. Take TeX as an example. It does what it does. Bug are bugs, and they can fix them. Lack of features are not bugs. They can absolutely close to fixing all bugs. And some small progr…