From a developer soon to retire

Brainstorming
1

(English is not my native language, this message is translated by Google, I apologize in advance if some of the translation doesn’t reflect what I mean.)

I hesitated for a long time before writing this message.

I’m 59 years old, I’ve been coding since I was 14, Basic on the ZX81 and Commodore 64, assembly and C on the Amiga during a stint at a game publisher, then Pascal on PC and Macintosh, C++ with Microsoft MFC, then Java, then Go, then Rust out of curiosity. My tools were Lattice C, Turbo Pascal, Delphi, MPW, Metrowerks CodeWarrior, QT, Visual C++, etc.

Today, when I work on network tools for my employer, I always ask Claude for a C, Go, Rust and Zig version.

The Zig version, even AI-generated and unoptimized, is the most pleasant one to read.

The software development world is going through an irreversible shift.

For example, my son works at a large international bank, and in his team almost no one writes code anymore.

In the past, custom development was too expensive and always rejected by managers; today it’s off-the-shelf software that’s too expensive.

At my company we built an excellent monitoring platform with three.js for a twentieth of the price of the ready-made solution pushed by a software vendor.

In the end we got something that perfectly matches our needs and is easy to maintain over time — that would have been impossible just 24 months ago.

And this trend, if you look at the latest studies from the major consulting firms (Gartner and McKinsey), is advancing everywhere.

Zig should be part of this and take the place of the language that lets a developer do everything quickly and cleanly, with or without AI help.

Realistically, Zig will probably never match what Rust has achieved — it’s too late for that. The investment in Rust is too massive, the commitment from every player in the language too significant. Bun’s rewrite finished convincing average developers like me that Rust could make it into enterprises.

But like many people, I love Zig, and I don’t want to see it become a niche language for a handful of very good developers.

For this reason, would it be possible to have a roadmap, even an imperfect one, toward version 1, similar to what was announced for Odin.

I know this goes against the general opinion of no rushing, no AI — but this game-changer is moving so fast in enterprises that I’m afraid Zig will arrive too late and miss this huge opportunity to be here to stay.

Thank you all for your work.

21 Likes
2

there is a roadmap, i thought.

by the way, i know this is a shifting topic, but i’ll say that i would much prefer handwritten english or a message not in english to machine translation. machine translation results in a subset of English common to AI agent-speak and punchy ad copy that I personally find grating to read, especially when it doesn’t match what I perceive to be the content of the post.

6 Likes
3

Voici la version originale.
J’ai longtemps hésité avant d’adresser ce message.

J’ai 59 ans, je code depuis l’âge de 14 ans, Basic sur ZX81 et Commodore 64, assembleur et C sur Amiga au cours d’un passage chez un éditeur de jeu, ensuite Pascal sur PC et Macintosh, Cpp avec Microsoft MFC, ensuite Java, ensuite Go, ensuite Rust par curiosité. Mes outils ont été Lattice C, Turbo Pascal, Delphi, MPW, Metrowerks CodeWarrior, QT, Visual C++, etc…

Aujourd’hui quand je travaille sur des outils réseaux pour mon employeur, je demande toujours une version C, Go, Rust et Zig à Claude.

La version Zig, même générée par une IA et non optimisée, est la plus agréable à relire.

Le monde du développement logiciel est en train d’opérer un renversement irréversible.

Par exemple, mon fils travaille dans une grande banque internationale et dans son équipe plus personne ne code.

Auparavant les développements spécifiques coutaient trop cher, toujours refusés par les managers, aujourd’hui c’est le logiciel standard qui coûte trop cher.

Dans mon entreprise on a fait une superbe plateforme de supervision avec three.js pour le 20 ième du prix de la solution déjà prête poussée par un éditeur logiciel.

Au final on a quelque chose qui correspond parfaitement à notre besoin et maintenable facilement dans le temps, cela aurait été impossible il y a encore 24 mois.

Et cette tendance, si on regarde les dernières études des grands cabinets de conseil (Gartner et McKinsey), elle est en train d’avancer partout.

Zig doit participer à cela et prendre la place du langage qui permettra à un développeur de tout faire rapidement et proprement avec l’aide d’une IA ou sans.

A la régulière Zig ne pourra jamais égaler ce qu’a réussi Rust, c’est trop tard. Les investissements dans Rust sont trop massifs, les engagements de tous les acteurs dans le langage trop important. La réécriture de Bun a terminé de convaincre les développeurs moyens comme moi que Rust pouvait entrer dans les entreprises.

Mais comme beaucoup de personnes j’aime Zig et je ne souhaite pas le voir devenir un langage de niche pour une poignée de très bons développeurs.

Pour cette raison, est-il possible d’avoir une roadmap, même imparfaite, vers la version 1 à l’image de ce qui a été annoncé pour Odin.

Je sais que cela vient contre l’opinion générale qui est, pas de précipitations, pas d’IA mais ce game changer est tellement rapide dans les entreprises, j’ai peur que Zig arrive trop tard et rate cette immense opportunité d’être là pour rester.

Merci à vous tous pour votre travail.

14 Likes
4

What is it too late for? What’s the rush? And don’t get me wrong I’d love a Zig 1.0, but I appreciate how methodical Zig, as I am writing it and as it is being developed.

There is a 2026 roadmap in the News category

In games it’s said that adding more people/money to a project makes it bigger before it makes it faster. A bigger programming language might have a better/fleshed-out std library, maybe it has superfluous and confusing language features. There’s another popular thread debating what to remove from the language1, so I think it’s generally agreed among this community we want small strong features over many weak and confusing additions.

If you are already satisfied- and even prefer Zig with LLM-generated code, why do you need Zig to be 1.0? Do you need a 1.0 badge to convince your team to accept the language? Wouldn’t this new LLM stuff be more in-dev and unstable than Zig, especially if we’re talking about price hikes? What is it exactly you would want changed from the language?

15 Likes
5

Thank you for your reply.
You may not work in a large company, but today it is no longer accurate to call LLM tools unstable; in fact, the exact opposite is true. In less than a year, they have forever changed the way the vast majority of developers worldwide work.
What I would like to see is for Zig to stabilize a version 1 release that enables LLMs to generate increasingly high-quality Zig code.
Zig is highly performant, and this performance translates into energy savings—and thus more environmentally sustainable operations.
I want as many people as possible to benefit from Zig’s inherent qualities; since the majority of developers use LLMs, I want all LLMs to be capable of producing excellent Zig code.

6 Likes
6

By “unstable” I meant that the LLM tools are changing rapidly, which you agree LLMs have been changing rapidly within the last year. This is at odds with wanting Zig to stop changing with a 1.0 version. So do you prefer stable software or not?

I don’t think that anything Zig related needs to be done for this? LLMs will spit out code from any language, no integration is needed, it’s just text to the machine. If anything Zig shouldn’t worry about LLMs and instead focus on creating readable code as usual, a feature you mentioned enjoying.

It sounds like you are worried about something but don’t know what, or are just trying to sell us on LLMs. I agree with you that I love Zig for it’s legibility, but I do not agree catering to LLMs in any way would advance the language in a good direction. Any focus of the language development itself is unrelated to, nor impacts LLM usage, so it would be frivolous any ways.

8 Likes
7

Timing has always been crucial during the major shifts in our industry. It happened at the right moment for C, at the right moment for Java, and now it is Rust’s moment. Without rushing things—assuming Zig’s release pace remains as it is (and I am certainly not asking for the work to be botched)—Zig will likely remain a niche language, though that may well be what the community desires.
Perhaps the real question is: what is needed to move faster? More donations?

1 Like
8

Maybe we do desire it- I’m certainly not worried about using a niche language. I would argue a niche language is only a bad thing in scenarios where an old project using such a language needs revival, and the language is hard to use. COBOL comes to mind but it certainly wasn’t a niche language, PHP and Javascript are similarly widely used but terribly difficult to produce good code with.

And what does being on top get Zig? What does it get us as users? It’s already free! Let’s suppose Zig is #1 worldwide, best language hands down, used for every project- as a Zig programmer I’d be a little happier, in some (or most) projects. Even then why wouldn’t I use the right tool for the job, I’d certainly prefer writing bash scripts for bash-like problems.

Speaking as just a Zig user, I have no experience chatting with/about the inner workings or with project management. What follows is speculation!

Stable donations might help, I’ve mentioned before but more money often does not make projects quicker, but I would trust the Zig Foundation after that one interview with Jetbrains.

I think good tooling would help. For example Github’s stability declining and policy changes made for a bad host. Migrating probably helped in the long run, but it surely did slow things down with huge project-management changes, just a lot of extra work because of one company’s mistakes. Another example of good tooling would be incremental compiling, faster compiling pretty directly means faster iteration and less flow-state breaks.

8 Likes
9

In his interview with JetBrains, Andrew envisioned Zig achieving a level of popularity comparable to Go or Rust. Reaching that level requires widespread adoption—potentially driven by LLMs—as remaining a niche language won’t suffice. However, you might be right: Zig’s rise will ultimately depend on what the community chooses to do with the language.

1 Like
10

More donations would help having more core team members working full-time on Zig, so yes that would help. But you would still need to manage your expectations, as some things just require time (9 women can’t make a baby in 1 month, as they say).

I would caution against paying too close attention to the news stream of current shifts in our industry. Sure, by predicting the future you can potentially position yourself in a way that makes you rich one way or another but, unless you’re explicitly trying to do that, and especially if your interest is in producing high-quality software, you risk just getting depressed, in good part also because of the deliberate doomerism/hype-ism of those who did invest in one specific outcome.

With Zig we are aiming to grow the language and ecosystem but we’re not optimizing for that, meaning that we’re not interested in what Gartner has to say, but at the same time we are being proactive in helping the community grow vibrant.

Last week I attended Zigtoberfest, where I asked to a room full of people (around 100) if they felt confident that the Zig community is helping them make progress towards becoming better software engineers and pretty much the entire room raised their hand to say ‘yes’. At that same event we also held the founding meeting for EuroZig, which will help the Zig community grow further within the European Union. Also next week there’s Software You Can Love Vancouver.

That’s good stuff that is happening already today, make sure to not sleep on it and to enjoy the perks it brings.

On top of that, observing the growth trajectory of the community in the real world is a good way to get a feeling for where Zig is going. A significantly better way than whatever Gartner or the youtube influencers think the state of Zig is.

My bet is that Zig is going to become a mainstream language precisely because we’re not min-maxing growth. Here’s a challenge for everybody reading: make a mental note to revisit your feelings about Zig’s popularity after we fully announce publicly incremental compilation (ie once it works on the major platforms).

In the meantime, don’t stress, and attend a Zig Day near you.

45 Likes
11

I think think opposite is more attractive, especially with LLMs, LLMs seem to have made it really easy to translate between languages (Bun) and the same is true for updating code (for compiler versions).

I would find it more favorable to work on a changing but highly polished language than compromise on what exists today as v1.0 only so that LLMs can be fine-tuned on semantics.

I would rather Zig code be as excellent as it can be.

7 Likes
12

From my own experience AI does very well with Zig for several reasons:

  • it’s a simple language
  • the standard library is always available for browsing
  • compiling/testing is reasonably fast in debug mode so it can fix its own bugs in little time

Consider that this is being achieved with zero efforts from the Zig development team (they don’t care about AI) and also from the community, it just stems from the qualities of the language. And these aren’t the result of rushing, but of careful design.

So Zig doesn’t need rushing imho, it’s doing perfectly well with AI, and it’s doing well for the same reasons that make many people distrust AI. In reality, AIs like simple code (which isn’t their own usually) just as much as developers and Zig is a great fit for them (already).

11 Likes
13

From what I’ve seen, language or API stability isn’t all that important anymore with recent LLMs, they’ll adapt automatically though a trial-and-error loop.

Also, IME while the more recent LLMs definitely work good enough to build entire applications, they don’t replace the thought process that goes into a maintainable code base. E.g. when building an application entirely via Claude Code at work, it doesn’t feel much different than the traditional workflow.

The bulk of the work was always communicating with designers and artists, clarify gaps in design documents or “art handovers”, and thinking about architecture and systems. With that in place, the code “almost wrote itself” before too.

E.g. all the “bureaucracy” that comes with working in multi-disciplinary teams is still there, only a very small aspect is replaced.

For my ‘precious spare time’ work I prefer to get deeply involved with the code though (which means writing the code by hand, the main purpose of writing code isn’t to get that code into the machine, but into your own head - and for that, writing is better than reading). I also don’t write a separate specification, since the code is the spec. And I can willy nilly change the design in my head as soon as anything “feels” off. You don’t get that deep relationship with a codebase by letting the code be written by an LLM (or somebody else for that matter).

I basically invert the regular LLM workflow: write the (important) code by hand, but LLMs review it. That is even slower than before, but also results in higher quality code than before. Thankfully for open source, implementation speed doesn’t matter (but quality does).

What I also see at work: LLMs seem to amplify the quality of the programmer. When steered by an experienced programmer, the “structural quality” of LLM generated codebases is typically pretty good. But better don’t look under the hood of that vibe-coded webpage a non-technical person wrote on the side (OTH, as long as the thing does what it’s supposed to do and doesn’t need to be longterm maintained - e.g. it’s essentially throwaway code, that’s usually ok).

13 Likes
14

I don’t think zig needs to show us a roadmap or announce 1.0 is soon. I also work in a big corporation in France (Thales). And I can tell you that yes AI has an impact, and it is profoundly changing how code is written, but AI won’t do the engineering for you, at least not yet, even frontier models are quite lazy, and don’t necessarily produce high quality output, they can and are useful, as a better google, for quick example, one off tools, basically intern jobs, the “nice to have but not critical”.

But when you want to do something properly, imo it still needs to be made by a human, and probably for the foreseeable future, and even those who use AI to code (myself included) should be careful, and read the code carefully and testing it accordingly.

Software engineering is still a valuable skill, and even if at some point the AI become insanely good, you would still need a human to check it’s output, and give it directions. For example at work I was debugging why suddenly i was loosing 15fps in my library for handling cameras, and at some point asked Sol to look if it found anything wrong ? and after working for 1h while i went eating, it was confidently saying that “It was probably because the hardware was reaching it’s limit” and it was confidently making napkin maths, to prove it too me. Which I knew was wrong, because the same morning it was working correctly, and it turned out to be a cond variable not waking up one of my threads. So the point is if i didn’t know better, I would have trust it, and made subpar software, with a huge performance gap with what the hardware is capable off.

The truth is code has become cheap, but the engineering is still expansive and needed. Zig already focuses on that, they are on a good trajectory, and have all my trusts, they will release the language when they dim it ready, and even past 1.0 I’d expect breaking changes (probably less magnitude, and less frequent but still).

In my opinion we should just enjoy the ride, and nobody knows of what tomorrow is made, we all share a common passion for making software, we all enjoy computers, and love to play with glorified sand, in the form of silicon die. Zig doesn’t need to care about AI, nor does it need to take it into consideration in it’s development.

19 Likes
15

Basically… my worst-case “AI apocalypse scenario” is when language and library authors don’t care anymore about ergonomics in their languages and libraries, because the Clankers don’t mind shitting out thousands of lines of pointless boilerplate (yes I rate that problem higher than the end of civilization lol).

On the other hand I don’t really care if 99% of the industry produces shitty code, industrial software development was always crap (see the OOP and Component Model hype of the 1990s), after that it got better, but now is the time where the pendulum swings back :wink:

22 Likes
16

Yeah I agree, and in big corporations usually even the human made software is cursed, because Daniel 15y ago though it would be cool to make a build system in perl (I kid you not). And know it’s a thing. But yeah I hope we don’t loose the art of making good interface, things that are clear, and easy to use/understand like zig std. Otherwise we won’t even have a choice.

9 Likes
17

One neat thing happened recently at work. When going to compile a C extension for a go program, the AI immediately reached to ask for a zig install as the compiler setup without being told to. I think it was because zig has a great story wrt cross compiles and just plain ease of use for compiling c code anywhere.

As far as LLMs writing zig, if you’re using frontier models or anything close, it’s just a non-issue now. And hey, if it isn’t up to your standards, then tell the AI your standards and what the success condition is.

What I would like to see from zig is a freeze on semantics of just a few AIR instructions so that formal analysis can be done to prove properties of code. The AIR is not high churn for a lot of it so I think this could be done.

3 Likes
18

What?

As long as your compilers work, computers don’t need popularity or fame to understand and to use a programming language, right?

Even if you are the only few people in the world still using Zig, it still works, right?

ViaWeb was written in C and Common Lisp. The guy who did that said the exact same thing. Few people understand Latin because few people use it, but computer can always use your programming language…

FlightGear uses a script language named Nasal, which has been long abondoned by its original author, and FlightGear is the only organization still uses it… The language carries all the fancy add-ons and moves on…

A lot of guys in China still using Pascal to write or help people to fix their decades old STC 8051…

Airbus A350’s computer programs are written on a graphical programming suite to emit C codes. And the suite is written in Java and Ocaml. Everybody thinks Rust or whatever will take over this industry, but actually people in this industry just picked whatever they think it fits best and move on…

And most importantly, when you are suggesting people to surf the tidal bore, you are essentially in the endless dependencies culture created in the last decade and hoping others to do the free work for you.

9 Likes
19

I’ve noticed much AI is trying to gaslight you into believing there are limits to something’s potential when there are not. It is a very defeatist and overconfident software. Only when they spin up 10 000 agents with some hidden internal model do they have the confidence to reach for some sort of frontier. Hopefully this won’t last long.

4 Likes
20

Sorry, what has rust achieved? Having to ask the US government to tell everyone “to prefer using memory safe languages” in a desperate attempt to draw any remaining gullible devs to using it? The fact it still relies on LLVM is enough to show even its core language development team never believed in the language to begin with.

3 Likes