[flooow]

I 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 for your sloppy-but-functional AI-written code - why open yourself up to memory unsafety on top of everything else? Further, the Zig community appears to value a hand-crafted, 'artisanal' approach to software development, which is the very antithesis of vibecoding.

I have no particular interest in Zig as a language but definitely feel some empathy here. The industry is changing in ways that many of us are struggling to process.

[kristoff_it]

> I imagine it's a difficult time to be a Zig developer.

In some ways it always has been, the community was 'born' in the middle of the pandemic, then for a long time there was a constant influx of Rust zealots coming into threads about Zig to remark how immoral it is to use Zig, and now LLM shovel sellers are telling everybody that the only way forward is to become efficient at consuming tokens.

But it's actually not that bad.

The Zig community is growing pretty well, useful software is being written in Zig, and the advantages that Zig brings are still valid whether you hand-code or use LLMs (e.g. cross-compilation of C/C++ code).

[bsza]

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 your tools, the dumber you get. People often claim to acquire "higher level thinking" skills from it (as do meth users), but even if that's true, they are also currently teaching those skills to the very tools that try to replace them.

The question is why would you fare any better if you don't use it. I don't know how it will play out, but this much I know: I will never pay for AI music, because I can replicate it for free. I'm still buying music from real musicians (in fact tons more than ever before), because I can't. Similarly, I have contributed to many FOSS projects (both financially and in PRs), but will not (knowingly) do the same for the ones that are vibecoded. Whether that will amount to anything or is just a fart in the wind, we'll see.

[pyth0]

I take amphetamines prescribed by a doctor for ADHD, and without them I am considerably less effective. And the same way your amphetamine analogy doesn't work, I think it similarly doesn't work for LLMs either. At the end of the day if you are more effective with something than without it, it would be silly to avoid it out of some sense of "purity".

[bsza]

I definitely did not mean using it as a prescription drug for a known condition. I meant using it without any medical indication, like many of us do. We know that amphetamines can lead to cognitive impairment [1] [2]. We know much less about reliance (over-reliance?) on AI, but what we know doesn't look good either [3] [4]. Of course, if you already live with a condition that makes it hard to concentrate, the benefits can outweigh the risks. But for most people they don't.

(Aside wrt being more effective with something than without: this is anecdotal, but my paragliding instructor once said that modern wings are often designed to correct for various pilot errors. He advised against buying those because he had seen people make worse mistakes after getting accustomed to them. In his own words: "you become dumber under a smart wing". Sharing because I think this applies to many things in life.)

[1] https://pmc.ncbi.nlm.nih.gov/articles/PMC3639428/

[2] https://pmc.ncbi.nlm.nih.gov/articles/PMC2670101/

[3] https://www.sciencedirect.com/science/article/pii/S074756322...

[4] https://www.dailycal.org/news/campus/academics/failing-grade...

[ian_holt]

<In his own words: "you become dumber under a smart wing". Sharing because I think this applies to many things in life.>

Applies a lot in life, eh. The old expression re muscles "if you don't use it, you lose it" applies a lot to coding or even in just normal day to day systems maintenance. Asking an AI agent, do to simple task just because "an agent is quicker or more effective" will quite often end up costing more in the long run do to one not remembering "how" to do something

[remexre]

I take (prescribed) amphetamines and use LLMs, and I think "I wrote this while on amphetamines" will leave you with way better understanding of the code than "I vibecoded this?" Like, to an absurd degree?

Vibecoding $x gives you pretty much the understanding of "someone else did $x," which seems unsurprising to me. There's a lot of usecases for code where "someone else did $x" is a perfectly fine way to accomplish $x! There are also many cases where "someone else did $x" is not a substitute for "I did $x."

"I want a tmux theme that fits with my existing zsh and neovim themes." Is it useful to me to learn how tmux themes work? Eh, marginally maybe? I'm personally kinda hoping I'm not using tmux in 10 years, so probably not.

"I'm writing code for work, where a bad correctness bug would be very expensive." If I'm pulling in someone else's code, I /better/ be auditing that code.

Like, this seems like the obvious framing and a useful heuristic? Maybe the problem is the subject of "vibecoded" is usually "I vibecoded this with Claude," not "Claude vibecoded this with me?" IDK

[dnautics]

> before Zig gets properly established.

zig is reasonably established. the llms write pretty good zig. see project linked below which is almost entirely llm-written

> And it is going to be very hard to justify choosing Zig for your sloppy-but-functional AI-written code

why? because one project that was shipping fast made a dog's breakfast of it?

> why open yourself up to memory unsafety on top of everything else?

this can be addressed by third parties in the reasonable near-term. for example:

https://github.com/ityonemo/clr

the zig team says that in the future stabilizing the IR and providing an API will happen.

fwiw in the process of building this project the llms have never once written a memory safety error in the "lib" section (in the src section there was a lot of tripping over segfaults since memory mapping datatypes accessed by a dylib can get hairy)

[rirze]

> the llms write pretty good zig

I doubt this from my personal experience. Every week after a release, I see tweets complaining how AI wrote some depreciated code because Zig is making breaking changes every release. (They are valid in doing so, it's just not AI friendly yet)

[dnautics]

claude and codex are pretty quick to figure out "oh that's not a thing anymore" and figure out what they need to do?

i did a 0.15 -> 0.16 port of this library and most of it the LLM did

https://github.com/E-xyza/zigler

[rirze]

I agree, when agents realize they're using old Zig semantics, they will adapt.

Doesn't help the training sets that Zig changes frequently though.

[dnautics]

nah. zig doesn't have weird macros/dsls and most zig authors are reasonably good about sticking to conventions. easiest thing to do is to put a "reminder here is changelog" in the agents file

[Zakis1]

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 have made in the past few years, and extrapolate that to the next 10 or 20 years. I don't see how Zig makes sense if this is the trajectory the industry is going.

[raincole]

> Just look at the progress LLM'S have made in the past few years, and extrapolate that to the next 10 or 20 years.

First of all, past trend doesn't predict the future.

And if it did, then the answer would be nothing will matter in 20 years. Not just "no programming language," but nothing.

[zaphirplane]

What does nothing matter mean thou ? The extrapolation is very plausible outcome thou

[Ygg2]

https://xkcd.com/605/

No one can predict the future least of all humble extrapolation line.

[zaphirplane]

Everything we do is about anticipation, from cooking to walking to driving. You maybe thinking 100% or nothing

[Ygg2]

Yeah, but those (cooking, walking) rely on prior experiences.

We don't have prior experiences that can tell us with certainty that LLMs will or will not replace humans entirely.

Projecting that LLMs will become a singularity is the same as saying processor's clock speed will double every year. They do double, they don't.

Sun will always rise in the east until it engulfs us.

[epolanski]

Why's everybody obsessed with the popularity contest?

Rust is a great language with some great killer features.

It does not need consistent propaganda preaching how it's a better choice than "insert other language".

Every system programmer is aware of Rust and it's pros. Doesn't mean it's a language that fits the use case, project, constraints and even preferences. It's not just about generating code, it's also about reading it and maintaining it.

Thus some people just prefer alternatives, be it C, C3, Odin, Zig, Jai or whatever else there is.

You said it yourself, it's selling point is "nicer C", so it's for people that don't want to write Rust or C++ but a nicer C.

[bwfan123]

> It does not need consistent propaganda preaching how it's a better choice than "insert other language".

Indeed. There is an irrational urge in some folks to become language-missionaries. Usually such folks have gained expertise in that specific language and want to protect and expand their turf. There is a wide-range of software usecases requiring a variety of tools and no one language fits all.

Amusing side-note. xai was all-in on rust for their ai-stack back in 2023. But now, spacex controlled xai is apparently coding ai in C - perhaps with the attitude that if a language is good enough to control rockets it is good for ai.

[AnimalMuppet]

I think it's like this. People think differently. Someone finds a language that really fits the way they think, and it feels wonderful, and they feel like they've been let out of prison into this wonderful new freedom. And they, being empathetic humans, want other people to have the same experience, and they think that others will have the same experience if they just try this wonderful language. So they become language missionaries.

But what they miss is that other people think differently than them. Other people will feel let out of prison by a different language.

[pdimitar]

Beautifully put and I agree, with one nuance:

There are multiple ways to think about how to write software, and that number really is not as high as various language proponents want us to believe. They aim at 50-100 but I'd say we got maximum 20, if not 6-7.

Point being: stuff is starting to converge IMO. It's not endless exciting diversity. "How to write software" (and adjacently: what PL to use) is just a boring multi-dimensional math problem at its root.

[flohofwoe]

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, while 'convenient highlevel abstractions' become less important).

[zozbot234]

Writing memory safe code in unsafe languages requires global reasoning, which LLMs are terrible at. The whole point of a type system or a borrow checker like Rust's is to thread the requirements for safety throughout the program syntax in a way that makes it possible to spot problems locally. That's why LLMs tend to be rather good at writing Rust.

[kristoff_it]

> Writing memory safe code in unsafe languages requires global reasoning

If you learn how to use arena allocators and in general use modern techniques, you don't need global reasoning to write correct memory management code pretty much never.

If your code is a RAII and abstraction maze, then yes, you will probably need global reasoning, but that's not the case with Zig.

[kibwen]

Arena allocators are great for certain use cases, but they don't provide any solutions to memory unsafety; they don't do anything for use-after-free, they don't do anything for buffer overruns, they don't address any sources of undefined behavior, and they don't do anything for thread-safety, which is a requirement for memory safety.

[J_Shelby_J]

The billion dollar “if”

[saagarjha]

Not all code can be expressed well by an arena allocator.

[trumpdong]

Writing anything safe code in any language that doesn't have that safety built in requires global reasoning. That's why LLMs aren't better at writing rm-rf/-safe code in Rust.

[tasuki]

> when the LLMs get good enough to just write memory safe code in unsafe languages

There is, and always will be, a huge difference between "because a LLM said so" and "here is a proof this is memory safe".

[KronisLV]

> 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 just got a lot of visibility because of the speed and scope of the migration, which both shook things up and I guess was good PR cause that made a lot of headlines.

[flooow]

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".

[flohofwoe]

You can replace the product and author name with Bun and the Bun author and the sentence also works, in the end all technical decisions are based on "opinions".

[KronisLV]

I mean, personally I just hope that at the end of the day everyone is as happy as the technologies in question will permit them to be. Either way I wouldn't say that Zig is done even after such prominent/loud news as the Bun rewrite.

[tasuki]

I find the Elm-adjacent people generally have above average taste, so that's a signal for me.

[codethief]

> 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

Thanks for the link! Unfortunately, contrary to what the title suggests, that video seems to be more about AI than about the migration? (Sigh…) I did, however, find the following document where they explain why they migrated to Zig. It makes for a nice read: https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...

[epolanski]

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]

Believe what you want, I guess.

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]

The 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]

Yeah 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]

Writing 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]

> 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...

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

[oytis]

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.

[zozbot234]

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 are assumed throughout and the whole point of unsafe code is to break those. (You can selectively relax those requirements, e.g. take &Cell<T> not &mut T, to allow for benign aliasing - but most stdlib code doesn't bother to!)

[kibwen]

Rust's library facilities are excellent for writing unsafe code with. Rust is very precise about which safety invariants must be upheld by which APIs, and does an excellent job documenting these, an excellent job at linting against improper usage of these APIs, and an excellent job leveraging the type system to reduce the need for unsafety in the first place. Writing unsafe Rust does indeed require its own degree of expertise compared to writing safe Rust, but fortunately it's trivial to just not write unsafe Rust; most Rust programmers only rarely have any cause to write unsafe code.

[zozbot234]

> but fortunately it's trivial to just not write unsafe Rust

The point of unsafe Rust is to "leave no room for a lower-level language". When writing lower-level facilities it's not uncommon at all to have to resort to unsafe. In practice, relying on the idiomatic standard library support within an unsafe block that might be breaking Safe Rust invariants is almost a sure way of shooting oneself in the foot as soon as the library function is doing anything more complicated than taking a pure value as input and returning a value as output.

[oytis]

"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

[applfanboysbgon]

It's weird to talk about "basically every" language, when you have exactly three mature systems languages: C, C++, Rust. C is from the 70s, C++ is an incoherent kludge on top of it, and Rust has a miserable DX (especially when actually used as a systems language instead of relying on pulling in 500 cargo dependencies that handle the unsafe code for you). Nothing else is used for serious systems programming. You don't need to do anything innovative, simply developing C-but-with-some-lessons-learned-since-1972 to a mature enough point would be more than sufficient to add value to the pitiful array of language options available. It is the language projects that try too hard to be novel and innovative and do brand new things that don't fill a real niche; they are academic experiments that will be use at most recreationally, never for real projects. If Zig doesn't seem interesting or unique enough to you, that's a good sign for it, because a new systems language doesn't need to be interesting or revolutionary.

[oytis]

C, C++ and Rust are the only ones that stuck, but programming languages graveyard is full of C++ killers. Rust is around because it offered something new.

[applfanboysbgon]

> but programming languages graveyard is full of C++ killers.

Literally just D? I'm not really aware of other serious efforts to modernise C/C++. Other than Rust, the world became completely fixated on GC languages that were inherently meant for higher-level purposes. Full-fledged attempts at memory unsafe languages in this century have been few and far between.

[sunshowers]

I look at people saying things like "Rust has a miserable DX" and I wonder whether I live on a different planet from them.

[mfru]

For me personally I found Zigs AI stance and the artisanal mindset very attractive.

So much so that I am at the moment doing the ziglings exercises and learning it over Rust (which I gave up on some time in the past, because it didn't spark "joy" for me; so far Zig does).

Sure, for now it is just a hobby programming lang to me, but it might become more than that.

[marcosdumay]

Why do people even try to vibe-code stuff in low level languages?

You either care about non-functional aspects of your code, or you don't. Running your code through the shredder that destroys everything you don't test while insisting on writing it on a language that specifies non-functional properties... I don't have any other word, it's stupid.

[data-ottawa]

Control and performance, the same reasons why people write in low level languages today/yesterday instead of everything in Python or JS.

Not all vibe coding is top down "Claude build X", it can be very specific implementation guidelines and criteria.

[liampulles]

There are performance reasons to handle memory allocation manually and tactically. This is why languages which deal with memory manually are not going anywhere.

Whether Zig will become dominant in that space remains to be seen.

[nsvd2]

While true, that doesn't distinguish between Zig and Rust, as both allow you to manually allocate memory and create custom data structures.

[liampulles]

Ok, but doing manual memory management in Rust is a bit like digging a ditch with a spoon. I get that its technically possible, that does not mean it should be done outside the most exceptional of circumstances.

[BobbyTables2]

I just assumed Bun users also suffer from psychological damage…

[tempodox]

I am not optimistic. When I look back in history, “worse is better” won every time. And vibecoding is the current epitome of “worse is better”. There are many places where code is a necessary evil, just a means to an end. And when the resulting software has never been particularly good anyway, then vibe-coded slop might just be good enough. Eventually, the economics will decide. There is a small chance that rising costs of LLM usage might save a segment or two from being devoured altogether.