3 ms·
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 compile
by epolanski 5mo ago
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 "the LLM has seen lots of this language so will write better in this language" scenario existed. Will make you an example: I have worked in a very esoteric typescript fork called TS plus (providing among others fluent style apis for pipe-able functions) and even Opus 4.1 did well. Recently I have forked the Elm language and the LLM had no problem dealing with it, despite significant differences to the original Elm.
4. Zig's community uses Zig because it likes Zig and its tooling and doesn't like the constraints of other languages. Simple as that.
- flooow 5mo agoBelieve what you want, I guess. https://xcancel.com/jarredsumner/status/2055796104302858694#m https://xcancel.com/jarredsumner/status/2055796104302858694#... > I’m just tired of dealing with crashes and memory leaks & want language features to help prevent things (Edit: this reply seemed less flippant before the parent edited their reply)
- kristoff_it 5mo agoThe truth is a bit of everything, bun being a messy codebase written primarily with "move fast and break things" in mind, cultural divergence between Bun and the Zig community, and also hiring issues. People maybe forgot but Jarred at some point caused a bunch of drama when he tweeted that working at Bun is not for people that value life/work balance, which went viral and caused an uproar. Must not have been super easy to hire from the Zig community after that, and in fact once Bun got acquired by Anthropic, it was pretty much Jarred and Claude doing all the work on the codebase. Pivoting to Rust is probably at least in part a way to reset the clock on those hiring interactions.
- BariumBlue 5mo agoYeah my take is they wanted a language more resilient to slop-cannon code. Last I looked they had 900kLOC of Rust just after the Rust PR - I have no doubt there's a lot of garbage in those LOC, and Rust gives more safety guardrails for that.
- dapperdrake 5mo agoWriting memory safe code in C with (most) compilers slapping UB in your face without so much as a warning is about the same as vibecoding.
- jeremyjh 5mo ago> You can write memory safe code in C (Redis, SQLite, OpenBSD, Git, etc), 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-qfc9-5f9q 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-9v9q-c838 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 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 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-8v3m-8wwr 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 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-july-2022-library-api/ https://blog.trailofbits.com/2022/10/25/sqlite-vulnerability... CVE-2023-7104: heap overflow in session extension https://sqlite.org/forum/forumpost/5bcbf4571c https://sqlite.org/forum/forumpost/5bcbf4571c CVE-2020-9327: NULL pointer dereference in isAuxiliaryVtabOperator https://nvd.nist.gov/vuln/detail/CVE-2020-9327 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 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 https://seclists.org/oss-sec/2023/q1/92 CVE-2022-27882: heap overflow in slaacd https://blog.quarkslab.com/heap-overflow-in-openbsds-slaacd-via-router-advertisement.html https://blog.quarkslab.com/heap-overflow-in-openbsds-slaacd-... errata 70/003: kernel memory leak closing unix sockets https://www.openbsd.org/errata70.html https://www.openbsd.org/errata70.html errata 74/018: buffer over-read in sndiod https://www.openbsd.org/errata74.html https://www.openbsd.org/errata74.html errata 78/013: use-after-free in httpd chunked encoding https://www.openbsd.org/errata78.html 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-2q3q-hvwq 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 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-wcq6-83p6 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 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 https://nvd.nist.gov/vuln/detail/CVE-2016-2324