Reflecting on a Year of Gamedev in Zig(bgthompson.codeberg.page)
bgthompson.codeberg.page
Reflecting on a Year of Gamedev in Zig
https://bgthompson.codeberg.page/blog/one-year-zig-gamedev-reflections/
123 comments
> Am I the only one who feels this is a step back from platforms such as Stack Overflow?
I have a long-held belief that the single best community information database format is Stack Overflow. (As opposed to wiki, chats, user groups/mailing lists, flat/threaded forums.) An editable top-level question, answered by several editable top level answers with different weighting on different things. (And then chat or small comments, there should be a place for some busywork that should carry no relevant information ideally.) Not necessary the website, but the format.
The second is blogosphere, allow users to write articles and engage in comments. For some reason basically no communities have these. They tend to have discord, and maybe a wiki.
I have a long-held belief that the single best community information database format is Stack Overflow. (As opposed to wiki, chats, user groups/mailing lists, flat/threaded forums.) An editable top-level question, answered by several editable top level answers with different weighting on different things. (And then chat or small comments, there should be a place for some busywork that should carry no relevant information ideally.) Not necessary the website, but the format.
The second is blogosphere, allow users to write articles and engage in comments. For some reason basically no communities have these. They tend to have discord, and maybe a wiki.
I previously worked at a fintech and they, understandably so given the domain, blocked Discord. Think for a second what wonders that does for participating in open source (which the same employer had no problem with).
Discord is not a suitable platform for developers. I think Matrix is pretty good but, fuck it, I'll take IRC over Discord - it's still perfectly functional.
Discord is not a suitable platform for developers. I think Matrix is pretty good but, fuck it, I'll take IRC over Discord - it's still perfectly functional.
I agree, Discord is a terrible user experience for me. The UI is confusing and any piece of information older than a few hours disappears forever into the void.
SO is a very beginner-unfriendly platform. Every time I used it, I either did not get any replies or had my question altered, deleted, removed, closed etc. I have no clue why anyone still uses it.
My 10 year old question was closed as a duplicate of a 7 year old question. I'm still both bitter and amused by this. (This was a few years ago, but it's still closed.)
https://stackoverflow.com/questions/10181706/working-with-a-...
https://stackoverflow.com/questions/10181706/working-with-a-...
Yes, this is an unfortunate direction that SO took in the last 5 or so years. In the first 5-10 years of its life it was much more welcoming and a great resource. Now it feels like a static database of (potentially slightly out of date) FAQs.
SO has always been this way, which is why I prefer to ask on reddit, and resort to SO when the question is unanswered or quite technical.
The two options are: 1) no one has had their questions answered on stack overflow, or 2) your questions were duplicates or needed a lot of rewording to make them useful to people in the future.
Asking a question on stackoverflow that is long term useful to the community isn’t a beginner-difficulty task.
Yeah, I guess if you have a very specific problem that you need help with, it's better to ask about it on Discord. But for the general questions that many noobs are likely to face that the blog post mentions ("How do you make for loop in reverse?" or "What allocator to use in WASM?"), I still think SO would be the better platform, if only to avoid trying the patience of the helpful people on Discord too much...
And even for specific questions like the one he mentions after that you really want to have them somewhere in public, because someone will eventually run into a similar problem
It’s beginner adverse site today. It’s got a lot of great existing questions and answers though
It is.
It's very hostile. Sometimes I just want to ask a broader, conceptual question. I don't need someone to produce working code. Just discuss.
Sometimes I can't make a working minimal example because I work with info that can't be placed online and writing something ground up that is similar enough and decoupled from the hundreds of files and hundreds of thousands of lines would take me a week or two and may not end up even working out.
Sometimes I can't make a working minimal example because I work with info that can't be placed online and writing something ground up that is similar enough and decoupled from the hundreds of files and hundreds of thousands of lines would take me a week or two and may not end up even working out.
They decided to not support those kinds of questions—their prerogative I suppose. They do have meta and software design, architecture sites.
[deleted]
Not that it matters as much any more since SO is slowly dying, they should replace human moderates with AI and involve humans only when AI says it needs help with something
You can still ask your Zig question on Stack Overflow, or they have a semi-official Discourse forum Ziggit (which I find preferable to Discord) where I got answers quickly...
Zig Discord is also just semi-official... there is also Slack, there is also mailing list, libera IRC, Telegram, QQ, Zulip...
https://github.com/ziglang/zig/wiki/Community
Zig Discord is also just semi-official... there is also Slack, there is also mailing list, libera IRC, Telegram, QQ, Zulip...
https://github.com/ziglang/zig/wiki/Community
> Zig Discord is also just semi-official
Is the Zig creator not there? I'm pretty sure he is.
Is the Zig creator not there? I'm pretty sure he is.
No, Andrew deleted his Discord account a while ago. Regardless, having the creator present does not make a space official, it's a matter of who owns the space and what the general policy is.
The general policy of the Zig Software Foundation is to not have blessed community spaces outside of spaces used strictly for coordinating the development of Zig (those currently are the Ziglang GitHub Organization and the ZSF Zulip), so all communities are equally non-official.
The main Zig Discord server is owned by community members and is actually not even the only Zig server on Discord.
The general policy of the Zig Software Foundation is to not have blessed community spaces outside of spaces used strictly for coordinating the development of Zig (those currently are the Ziglang GitHub Organization and the ZSF Zulip), so all communities are equally non-official.
The main Zig Discord server is owned by community members and is actually not even the only Zig server on Discord.
I thought the Zig creator abandoned Discord due to invasive ads sometime last year.
That wouldn't necessarily make it official though
I always found SO really slow. Often I would get stuck on something, ask a question and then have to wait an hour for a response (which would often become a back and forth of comments with large periods of time between them). Even on discords for less popular languages/libraries you generally get an answer in minutes.
I think this is likely due to the incentives SO creates. I have never actually answered a SO question because it feels like you need to answer perfectly or get torn apart. I will often contribute to a discord question even if I don't full know the answer just because I think I can add something useful.
I think this is likely due to the incentives SO creates. I have never actually answered a SO question because it feels like you need to answer perfectly or get torn apart. I will often contribute to a discord question even if I don't full know the answer just because I think I can add something useful.
> Even on discords for less popular languages/libraries you generally get an answer in minutes.
On SO, at its peak, you got an answer even faster because it was public (i.e. the answer was already there, you just searched for your question).
So you're comparing minutes to instant.
On SO, at its peak, you got an answer even faster because it was public (i.e. the answer was already there, you just searched for your question).
So you're comparing minutes to instant.
But zig's discord is also public ;o
> I have never actually answered a SO question because it feels like you need to answer perfectly or get torn apart.
I agree i rather see all this discussion etc take place on dedicated forums or other text based options so search engines can index the stuff..
Ziggit is a Zig Discourse that is pretty good:
https://ziggit.dev/
It's almost as fast as the Discord and much friendlier to searching and context.
I make a point of avoiding the Discord simply because I want my questions and answers to be searchable by people who come afterward.
It's almost as fast as the Discord and much friendlier to searching and context.
I make a point of avoiding the Discord simply because I want my questions and answers to be searchable by people who come afterward.
Except discourse is just a forum and thus less useful than the SO format where good answers bubble up
Discourse has the feature where the comment marked as answer will be placed up top right after the question.
I'll be honest, for me, SO feels sclerotic.
Any question that is more than a couple of years old and applies to something under active development risks having the "bubbled up" answer being actively incorrect.
Maybe this is just because I'm not developing in Javascript.
Any question that is more than a couple of years old and applies to something under active development risks having the "bubbled up" answer being actively incorrect.
Maybe this is just because I'm not developing in Javascript.
Ziggit is indeed another active community and it's perfectly legitimate to want to stick to a platform vs another for personal preference, the people who downvoted this comment should really re-evaluate the way the approach this subject.
Agreed - humans like participating in chats better (when you have a problem, you want live humans ready to answer you now), but the SO style archive is better for long term archiving & retrievability.
A LLM product that turns Discord transcripts into a browsable Q&A archive would be neat.
A LLM product that turns Discord transcripts into a browsable Q&A archive would be neat.
There are already several projects that have tried the “expose Discord data for indexing” model. Problem is no chat servers ever actually use them, perhaps because they’re at odds with expectations of people in the servers themselves.
In the context of Zig, Ziggit has been pretty nice also. I use that instead.
Discord is just one of many places where you can get help from other Zig community members.
Over time I've seen plenty of comments like this one about platform A vs platform B and I find them all absolutely uninteresting. Having an active Discord server doesn't stop you from having active communities elsewhere.
Some people prefer Discord and they made a comfortable home for themselves. If you prefer a different platform (which could be a matter of personal preference or an objective advantage, it really doesn't matter which it is), then go make yourself a comfortable home there and start offering help to others on it.
If you're a newcomer and can't really offer much help, then you're asking for people who do have that knowledge to help you on a platform of your choice. That's certainly something you can wish for, but you can't demand it, regardless of how much objectively better your platform might be.
Over time I've seen plenty of comments like this one about platform A vs platform B and I find them all absolutely uninteresting. Having an active Discord server doesn't stop you from having active communities elsewhere.
Some people prefer Discord and they made a comfortable home for themselves. If you prefer a different platform (which could be a matter of personal preference or an objective advantage, it really doesn't matter which it is), then go make yourself a comfortable home there and start offering help to others on it.
If you're a newcomer and can't really offer much help, then you're asking for people who do have that knowledge to help you on a platform of your choice. That's certainly something you can wish for, but you can't demand it, regardless of how much objectively better your platform might be.
> Having an active Discord server doesn't stop you from having active communities elsewhere.
It actually does when users are pointed to discord to ask the same questions over and over.
Look at the two example questions in OP's quote. Sending users to discord for those means nearly nobody else will benefit from the answers.
And I think it's fair to point this out.
It actually does when users are pointed to discord to ask the same questions over and over.
Look at the two example questions in OP's quote. Sending users to discord for those means nearly nobody else will benefit from the answers.
And I think it's fair to point this out.
1. Questions and answers on Discord are searchable, there's a channel format that makes every conversation a thread and the UI even automatically searches for matches as you type the title of a new thread, which is what the Zig Discord server uses. It's correct to say that Discord answers will not be searchable outside of Discord, but it's factually wrong to say that you won't be able to very easily find out if your question has been asked already.
2. OP is not sending anybody anywhere, they're just talking about their experience. Zig has multiple communities and you can get help also elsewhere. A blog post that recounts one's experience doesn't need to list all other ways of getting help and it's wrong for you to assume otherwise.
2. OP is not sending anybody anywhere, they're just talking about their experience. Zig has multiple communities and you can get help also elsewhere. A blog post that recounts one's experience doesn't need to list all other ways of getting help and it's wrong for you to assume otherwise.
> it's factually wrong to say that you won't be able to very easily find out if your question has been asked already
IME discord's search is terrible. When I try to find previous questions it seems like it uses a naive exact word search, so if I change my keywords slightly it finds different results. I haven't tried Zig's channel so maybe they do it better. But in general, I stand by my comment.
> OP is not sending anybody anywhere, they're just talking about their experience
The quote was clearly recommending the Zig Discord channel as a place for anyone learning Zig to go and ask questions. This is "sending people there".
IME discord's search is terrible. When I try to find previous questions it seems like it uses a naive exact word search, so if I change my keywords slightly it finds different results. I haven't tried Zig's channel so maybe they do it better. But in general, I stand by my comment.
> OP is not sending anybody anywhere, they're just talking about their experience
The quote was clearly recommending the Zig Discord channel as a place for anyone learning Zig to go and ask questions. This is "sending people there".
Discord will arbitrarily ban users for using a VPN making it next impossible to access prior conversations on given topics where support takes anywhere from a week to two months to review tickets related to it (they then go "whoops" and lift the ban only to apply it again days later).
Not being searchable outside of Discord is the problem (matrix / telegram also suffer from this) as it places useful Q&A and discussion behind a wall.
Not being searchable outside of Discord is the problem (matrix / telegram also suffer from this) as it places useful Q&A and discussion behind a wall.
> 1. Questions and answers on Discord are searchable, there's a channel format that makes every conversation a thread and the UI even automatically searches for matches as you type the title of a new thread, which is what the Zig Discord server uses. It's correct to say that Discord answers will not be searchable outside of Discord, but it's factually wrong to say that you won't be able to very easily find out if your question has been asked already.
The built-in search software for a lot of forums is for lack of a better term, abysmal.
Consider this search on SO - user:172406 javascript userscript
consider the same search on google - vfclists javascript userscript.
It is the first answer on the list and note that I didn't add "stackoverflow" to the query.
The built-in search software for a lot of forums is for lack of a better term, abysmal.
Consider this search on SO - user:172406 javascript userscript
consider the same search on google - vfclists javascript userscript.
It is the first answer on the list and note that I didn't add "stackoverflow" to the query.
I don’t really think chat is a step back (discord may be a step back vs irc or I am just graying). Learning newish tech in chat has always been way more engaging for me than wiki or forum style communication.
IME chat attracts people who devote a lot of energy to the topic, including top contributors and power users. If you have questions about the latest features or obscure use cases there isn’t a better place to go.
Forum and wiki are great formats too, with different strengths. But if you are frustrated because you can’t seem to find help in those formats, head for the chat.
Some communities archive their chat. This seems like a great source of data to bootstrap a wiki or faq.
IME chat attracts people who devote a lot of energy to the topic, including top contributors and power users. If you have questions about the latest features or obscure use cases there isn’t a better place to go.
Forum and wiki are great formats too, with different strengths. But if you are frustrated because you can’t seem to find help in those formats, head for the chat.
Some communities archive their chat. This seems like a great source of data to bootstrap a wiki or faq.
> forum is awash with questions from beginners like “How do you make for loop in reverse? or “What allocator to use in WASM?” Most get answered within minutes.
You wouldn't get a chat awash with these questions if they could be easily searched for.
You wouldn't get a chat awash with these questions if they could be easily searched for.
Yes you would.
1. Not as much because people can actually find the answers to their questions before locking to the chat
2. On top of that you can make info on and solutions to other issues/problems actually available and accessible. Like the one the author describes later in the same text
Instead all this info is locked behind a proprietary chat platform
2. On top of that you can make info on and solutions to other issues/problems actually available and accessible. Like the one the author describes later in the same text
Instead all this info is locked behind a proprietary chat platform
Totally agree
But once we opened a Discord for our product we had so many more questions and users coming in. I do not like that it is locked up on a proprietary platform organised as a chat interface, but damn is it popular and often-used. Having users communicate with us more regularly is very motivating, and we've had so much more quality feedback by having it available
It is, unfortunately, where a lot of the people are and it makes your user base feel very "alive"
But once we opened a Discord for our product we had so many more questions and users coming in. I do not like that it is locked up on a proprietary platform organised as a chat interface, but damn is it popular and often-used. Having users communicate with us more regularly is very motivating, and we've had so much more quality feedback by having it available
It is, unfortunately, where a lot of the people are and it makes your user base feel very "alive"
Why not use AnswerOverflow to make the chats indexed and searchable? It's definitely a lot better than nothing, multiple times it has already helped me find answers to questions I had.
Thanks for the suggestion! I had no idea this existed
I don't think SO's "canonical answer" concept really jives with a pre-1.0 language like Zig that is still in constant flux, regularly making breaking changes. One of the questions the blog brings up as an example, "What allocator to use in WASM?" would have a different answer last year than it would this year, and may well have a different answer next year.
I agree, but I think that you could get a useful middle ground by continuously publishing the contents of your Q&A Discord channel to the internet (in a way where it gets indexed by search engines).
Yes, Stack Overflow collated these questions and answers better but then at least you could google for something and get the answer, rather than asking again.
Yes, Stack Overflow collated these questions and answers better but then at least you could google for something and get the answer, rather than asking again.
Discord is really bad if you want more than 1-on-1 real-time communication with other humans. This is also its primary advantage.
In a world where every surface of the web is infested with bots, trolls, spammers and AI slop, persistent static and public information is a hazard. Moving knowledge to ephemeral communities is an immune response to what the web has become. I'm usually not a fan of gatekeeping but doing so to filter for human beings seems like a necessary evil.
Discord sucks. Slack is so much better, IMO.
I tried Zig a bit and found it quite nice, but it is very low level. Like in Rust you concatenate strings like this:
let result = format!("{a}{b}{c}");
const allocator = std.heap.page_allocator;
const parts = [_][]const u8{"a", "b"};
const result = std.mem.concat(allocator, &parts[0], 2) catch @panic("allocation failure");
defer allocator.free(result);
There's also `std.fmt.allocPrint()` which functions similarly to `format!()`. Although I'd argue its rather poorly named, like many of the functions in the stdlib...
For wanting to avoid fiddling with multiple repeated alloc/defer-free, it's often convenient to use the arena allocators that allow you to release everything with a single `defer arena.deinit()`
For wanting to avoid fiddling with multiple repeated alloc/defer-free, it's often convenient to use the arena allocators that allow you to release everything with a single `defer arena.deinit()`
I would (coming from a C background) guess that `allocPrint()` owes its name from the C standard library function(s) `as(n)printf()`[1]. At least that would make sense, the naming is modernized by being made longer, to gain clarity.
[1]: https://man7.org/linux/man-pages/man3/asprintf.3.html
[1]: https://man7.org/linux/man-pages/man3/asprintf.3.html
My game has a bunch of strings, and my string code currently looks very different to this! For example, copying two lines from source:
The reason is, most of the strings in my game are bounded, and actually, known ahead of time. None of the levels have names that approach anything as long as 64 bytes, so I can actually do a fair bit of string manipulation on the stack before needing to use / save it to an allocator. (At least for now before localization XD)
So it depends on the use case. Sure, string manipulation in general can be tiresome in Zig, but in many cases it's also simple.
var buffer : [64] u8 = undefined;
const level_name_cstring : stringnt = std.fmt.bufPrintZ(&buffer, "{}. {s}", .{icon_index + 1, level_name}) catch unreachable;
The reason is, most of the strings in my game are bounded, and actually, known ahead of time. None of the levels have names that approach anything as long as 64 bytes, so I can actually do a fair bit of string manipulation on the stack before needing to use / save it to an allocator. (At least for now before localization XD)
So it depends on the use case. Sure, string manipulation in general can be tiresome in Zig, but in many cases it's also simple.
Isn't `unreachable` in Zig like in C? So very bad things can happen if you overflow.
This sort of code makes me nervous about Zig.
This sort of code makes me nervous about Zig.
Discord (Chat in general) is really nice if you are the first to have a problem.
If anyone else has the same problem, they can't find it by just googling tho. So they need to ask the same question again which gets annoying pretty fast unfortunately
If anyone else has the same problem, they can't find it by just googling tho. So they need to ask the same question again which gets annoying pretty fast unfortunately
Not sure why this was flagged. It was an interesting read, thanks for sharing. My biggest concern with using Zig has been the breaking changes that you mentioned, but I have been pushing forward with it for personal projects because it just seems like people are able to work around them easily, like you mentioned.
You're welcome! My experience with the breaking changes in Zig has not been bad at all. For brevity in the blog I didn't get into what I had to do to get things working again, but the process itself was straightforwards. Sometimes the names of some standard library functions had changed, sometimes it was some extra fields in the build system. Whatever the case, the changes were almost always documented in the release notes anyway, so after reading the release notes I basically knew the (small) amount of work I had ahead of me.
All posts not fellating Rust are eventually flagged here. It’s not really a neutral venue for more academic conversations about PLT.
First class SIMD vector support is awesome. The complaint about that not being first class matrix support kind of misses the mark: it's all vectors all the way down.
This is one glaring omission from Rust. Their SIMD integration is library specific and patchwork but improving.
This is one glaring omission from Rust. Their SIMD integration is library specific and patchwork but improving.
Out of C3, Odin and Zig, Zig is actually the language with the worst SIMD support. Odin has SIMD vectors, array programming and built in matrix types while C3 has built in SIMD vector types and operator overloading for userland numerical types such as matrix and complex types.
Odin and C3 has things like swizzling, assigning a scalar to all elements etc out of the box, whereas Zig is similar to C and just provides compiler builtins. Compare `vec * @splat(foo())` (Zig) to `vec * foo()` (Odin/C3).
Odin and C3 has things like swizzling, assigning a scalar to all elements etc out of the box, whereas Zig is similar to C and just provides compiler builtins. Compare `vec * @splat(foo())` (Zig) to `vec * foo()` (Odin/C3).
Yeah I dislike Zig for all those "@()" stuff.
Snap! I've been developing a roguelike in zig for nearly exactly a year and my experience is very similar. I especially appreciate your mentioning the positives that come with breaking changes.
Seems like you're also a C/C++ developer so I'm curious: how have you found zig's comptime compares to templates? (Personally I've found it a refreshingly simple experience, if occasionally annoying due to pre-1.0 bugs)
Seems like you're also a C/C++ developer so I'm curious: how have you found zig's comptime compares to templates? (Personally I've found it a refreshingly simple experience, if occasionally annoying due to pre-1.0 bugs)
For my (relatively simple) use cases, I've had a significantly better time using comptime than templates; the syntax and the quality of the error messages are a lot simpler in Zig. While I've never attempted to do anything super fancy with templates in C/C++, my gut feeling is that comptime can provide most, if not all, of functionality that templates provide. (But C/C++ template experts please chime in if this is not the case.)
Former Cpp dev here. If I never have to debug a template barf it'll be too soon. By the end of my time in C/Cpp land I'd written more C than anything, with occasional "structs with con/de-structors". Happily the next gen of systems languages fit about in that niche already!
Zig is really HN's new love story, isn't it. Or quickly becoming...
Rust is still popular but it turns out the developer joy is pretty low.
Rust is still popular but it turns out the developer joy is pretty low.
I’ve been dabbling in OS development. I started with rust and it was… ok. Lots of what you’d expect: unsafe all over the place, weird borrow checker work arounds. It felt like I was bending the languages arm.
I recently started to re implement the (admittedly very basic) kernel in Zig and it’s been a breath of fresh air. The language seems much better suited for the level of abstraction that Osdev lives at. Major bonus is that all the existing C code is directly useable in a zig project without any wrapper nonsense or it can be easily translated.
I think I’ll stick with dig for a bit.
I recently started to re implement the (admittedly very basic) kernel in Zig and it’s been a breath of fresh air. The language seems much better suited for the level of abstraction that Osdev lives at. Major bonus is that all the existing C code is directly useable in a zig project without any wrapper nonsense or it can be easily translated.
I think I’ll stick with dig for a bit.
I think base Rust is a great language, but the ecosystem tends towards very complex and overengineered solutions; with advanced uses/abuses of macros and the type system, trait hell ends up being not too dissimilar to template hell from C++. And the async/await story is plagued with layers and layers of complexity due to the many obtuse interactions with its lifetime system.
Rust honestly probably should've gone with its original idea of green threads/channels, like GC-less Go, but that idea was dropped a long time ago.
"Joy" is always highest for new languages, because there are only green fields and enthusiasts. "Joy" is also increased by languages that let you just do what you want, like dynamic typing, or other language features that delay seeing that first error.
This is a good point. Zig is practically optimized for this: comptime is extremely dynamically typed compared to actual generics, and the lack of memory safety is often "a breath of fresh air"--until you have to actually fix bugs (including security bugs) resulting from it.
It's like the "joy" of a good vacation paid for with a credit card.
I appreciate Zig and hope it succeeds. I don't dismiss the benefits of Rust like some comments though; the borrow checker or unsafe syntax may be a pain now, but so is saving money before a vacation.
I appreciate Zig and hope it succeeds. I don't dismiss the benefits of Rust like some comments though; the borrow checker or unsafe syntax may be a pain now, but so is saving money before a vacation.
> Rust is still popular but it turns out the developer joy is pretty low.
Rust is one of the language I enjoy to use. The problem is you need to overcome its steep learning curve in order to enjoy it, which people tend to give up because it is too hard.
Rust is one of the language I enjoy to use. The problem is you need to overcome its steep learning curve in order to enjoy it, which people tend to give up because it is too hard.
For me, it wasn’t the learning curve that was the problem with Rust. It’s the compilation time. It’s just so slow. I’m used to OCaml, Go, and Typescript (via Bun or esbuild) with iteration times in the tens-to-low-hundreds of milliseconds. Zig still feels a wee bit slow, but it’s acceptable. Rust? It makes me want to toss my laptop into the fire.
To be honest, I haven’t touched Rust in years, so it may have improved.
To be honest, I haven’t touched Rust in years, so it may have improved.
Coming from those, I can see how it'd be a downgrade. Coming from C++ it's like greased lightning.
It has improved continually over the years, but on the order of 3x-5x, and by the way you talk about it, you’re looking for 10x-100x, so I doubt it’s not still an issue for you.
Which to me is fine. It's not a great hobby language but it is a fantastic professional language, precisely because of the ease of refactors and speed of development that comes with the type system and borrow checker.
> It's not a great hobby language but it is a fantastic professional language,
I never thought I'd live to see the day when someone would say this. The first 5 years of Rust were all "this is interesting for hobby projects but nobody will ever adopt this in industry".
I never thought I'd live to see the day when someone would say this. The first 5 years of Rust were all "this is interesting for hobby projects but nobody will ever adopt this in industry".
If you’re only looking at HN, sure.
The programming world is much larger than this small slice of the internet, though. HN has had several eras of “this is the hot new fad language and you should use it!”, going as far back as Lisp in the mid-2000s.
It will likely continue to experience this cycle until the heat death of the universe.
The programming world is much larger than this small slice of the internet, though. HN has had several eras of “this is the hot new fad language and you should use it!”, going as far back as Lisp in the mid-2000s.
It will likely continue to experience this cycle until the heat death of the universe.
> Rust is still popular but it turns out the developer joy is pretty low.
I mean, Rust keeps winning the "most loved" language contest on GitHub, so it seems someone likes it.
I mean, Rust keeps winning the "most loved" language contest on GitHub, so it seems someone likes it.
I think you're talking about stackoverflow not github
Yeah, sorry, my mistake. GitHub did report on the SO survey [1], which probably led to my mixup.
Anyway, Rust was still the "most admired" language in 2024 [2].
[1]: https://github.blog/developer-skills/programming-languages-a...
[2]: https://survey.stackoverflow.co/2024/technology#admired-and-...
Anyway, Rust was still the "most admired" language in 2024 [2].
[1]: https://github.blog/developer-skills/programming-languages-a...
[2]: https://survey.stackoverflow.co/2024/technology#admired-and-...
https://github.blog/news-insights/octoverse/octoverse-2024/#...
What are you talking about?
What are you talking about?
Your link is from 2023 and references 2022. (It is also much more of an advertisement for Rust than anything else.)
The one I shared before that is from late 2024. What are you trying to say other than Rust has peaked?
The one I shared before that is from late 2024. What are you trying to say other than Rust has peaked?
I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won" if you want to nitpick my choice of verb tenses. It refutes the idea that the "developer joy is pretty low" either way.
> It refutes the idea that the "developer joy is pretty low" either way.
https://deadmoney.gg/news/articles/migrating-away-from-rust
https://loglog.games/blog/leaving-rust-gamedev
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...
https://medium.com/@rusty-vibes/part-4-abandoning-rust-for-c...
A pile of evidence refutes your statement. There is more if you need.
> I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won"
"Rust has peaked"
https://deadmoney.gg/news/articles/migrating-away-from-rust
https://loglog.games/blog/leaving-rust-gamedev
https://www.boringcactus.com/2025/04/13/2025-survey-of-rust-...
https://gist.github.com/rtfeldman/77fb430ee57b42f5f2ca973a39...
https://medium.com/@rusty-vibes/part-4-abandoning-rust-for-c...
A pile of evidence refutes your statement. There is more if you need.
> I'm happy to revise what I said from "Rust keeps winning" to "Rust continually won"
"Rust has peaked"
Yes, you have correctly pointed out that there are some developers who are unhappy with Rust.
I don't really care to have an argument as to whether "Rust has peaked" or not. Rust is the same language now as it was in 2023, and 2022, and 2021, etc., and developers liked it then. That's all.
I don't really care to have an argument as to whether "Rust has peaked" or not. Rust is the same language now as it was in 2023, and 2022, and 2021, etc., and developers liked it then. That's all.
> A pile of evidence refutes your statement. There is more if you need.
There are only two kinds of languages: the ones people complain about and the ones nobody uses
Of course some people are going to complain about Rust (for many various reasons, and had you read the links you posted, you'd have noticed that they all moved to a different one: C++, Zig or C#), the question is which share of it do, and the answer is a smaller one than in other mainstream languages.
> "Rust has peaked"
You wish.
There are only two kinds of languages: the ones people complain about and the ones nobody uses
Of course some people are going to complain about Rust (for many various reasons, and had you read the links you posted, you'd have noticed that they all moved to a different one: C++, Zig or C#), the question is which share of it do, and the answer is a smaller one than in other mainstream languages.
> "Rust has peaked"
You wish.
> After compiling the game with the flag -Dcpu=baseline, the binary contained only x86-64-v1 instructions, allowing my friend to play the game.
Feels like the startup code should actually verify that it's running on a suitable CPU rather than just crashing.
I don't think C/C++ or Rust do this either but they should!
Feels like the startup code should actually verify that it's running on a suitable CPU rather than just crashing.
I don't think C/C++ or Rust do this either but they should!
pretty much no language do this by default. however, most languages target the -v1 instruction set in 'release' or optimized mode. (e.g. Rust does this, and AFAIK GCC and clang both do this for C/C++)
Not gonna lie, most of those things look like negatives.
- Zig main source of QnA is a black box (Discord)? One that might be soon enshittified to hell because we have to satisfy the IPO.
- Zig uses Gradle style approach to Maven. Having used Gradle, I honestly can't recommend it. Too much freedom in build pipeline leads to too many footguns.
- Zig changes in big exciting ways, sounds like euphemism for breaking changes. Having those on framework level is tiring, having those on language level is hell.
- Zig main source of QnA is a black box (Discord)? One that might be soon enshittified to hell because we have to satisfy the IPO.
- Zig uses Gradle style approach to Maven. Having used Gradle, I honestly can't recommend it. Too much freedom in build pipeline leads to too many footguns.
- Zig changes in big exciting ways, sounds like euphemism for breaking changes. Having those on framework level is tiring, having those on language level is hell.
1. I agree
2. I guess this is a matter of perspective. I don't have strong opinions on build systems but as someone who only occasionally dabbles in systems programming, I know that Zig's build system is infinitely more approachable and coherent than the monstrosities of CMake and any other build system I've ever come across in various C and C++ projects.
3. That's true, but Zig isn't 1.0 yet so that's to be expected.
2. I guess this is a matter of perspective. I don't have strong opinions on build systems but as someone who only occasionally dabbles in systems programming, I know that Zig's build system is infinitely more approachable and coherent than the monstrosities of CMake and any other build system I've ever come across in various C and C++ projects.
3. That's true, but Zig isn't 1.0 yet so that's to be expected.
> I don't have strong opinions on build systems but as someone who only occasionally dabbles in systems programming, I know that Zig's build system is infinitely more approachable and coherent than the monstrosities of CMake and any other build system I've ever come across in various C and C++ projects.
Whenever a language builds their own build system in a programming language or a DSL, the issue of composability rears its ugly head. Yeah, it's a bit better to write Zig build in Zig than Bash, or some Groovy DSL.
What it doesn't change that it's hard to compose them. Do you want to add code coverage? Well, you now need to figure out where to add code coverage in your custom build script. Rather than a linear set of steps, you have a tangle of unique "solutions" rather than a standard way to extend the process.
Whenever a language builds their own build system in a programming language or a DSL, the issue of composability rears its ugly head. Yeah, it's a bit better to write Zig build in Zig than Bash, or some Groovy DSL.
What it doesn't change that it's hard to compose them. Do you want to add code coverage? Well, you now need to figure out where to add code coverage in your custom build script. Rather than a linear set of steps, you have a tangle of unique "solutions" rather than a standard way to extend the process.
> Zig main source of QnA is a black box (Discord)?
The Discord is quite okay-ish for getting a quick answer for things you're blocked on. For proper discussions and deeper questions, Ziggit is a better choice (which is also a 'proper' forum):
https://ziggit.dev/latest
> Zig uses Gradle style approach to Maven.
Zig's build system is conceptionally further away from both Gradle and Maven than Gradle is different from Maven (having to wrestle with both from time to time, my personal opinion is: both are a huge pile of excrement, unfit for real-world usage - even cmake is better than what the Java world accepts as build systems, and that's some achievement ;)
At least the Zig build system looks promising in the way that simple things are simple and complex things are possible, even though the API still sometimes doesn't quite know if it wants to be imperative or declarative. But the basic idea is that the Zig build system and package manager are "just" part of the regular stdlib and that your build process is a regular Zig program that gets compiled and then executed to perform the build.
> Zig changes in big exciting ways, sounds like euphemism for breaking changes
...which is completely expected of a pre-1.0 status. OTH, the last couple of versions were not worse than fixing new warnings after a minor C/C++ compiler update.
The Discord is quite okay-ish for getting a quick answer for things you're blocked on. For proper discussions and deeper questions, Ziggit is a better choice (which is also a 'proper' forum):
https://ziggit.dev/latest
> Zig uses Gradle style approach to Maven.
Zig's build system is conceptionally further away from both Gradle and Maven than Gradle is different from Maven (having to wrestle with both from time to time, my personal opinion is: both are a huge pile of excrement, unfit for real-world usage - even cmake is better than what the Java world accepts as build systems, and that's some achievement ;)
At least the Zig build system looks promising in the way that simple things are simple and complex things are possible, even though the API still sometimes doesn't quite know if it wants to be imperative or declarative. But the basic idea is that the Zig build system and package manager are "just" part of the regular stdlib and that your build process is a regular Zig program that gets compiled and then executed to perform the build.
> Zig changes in big exciting ways, sounds like euphemism for breaking changes
...which is completely expected of a pre-1.0 status. OTH, the last couple of versions were not worse than fixing new warnings after a minor C/C++ compiler update.
> ...which is completely expected of a pre-1.0 status.
I fully agree, but I assume you want to ship your game (i.e. its a game not a toy). At least to Windows. Building your game on pre 1.0 language is like building a house on sand that's being transported by a truck.
I fully agree, but I assume you want to ship your game (i.e. its a game not a toy). At least to Windows. Building your game on pre 1.0 language is like building a house on sand that's being transported by a truck.
2. Zig has good builtin support for vectors, but not for matrices.
Oh boy do I have the language for you.
https://odin-lang.org/docs/overview/#matrix-type
Oh boy do I have the language for you.
https://odin-lang.org/docs/overview/#matrix-type
If you poke around you will find the author is already familiar with Odin. Might be interesting to hear why they moved to Zig.
I think point 3 is completely off. That's not cherry-picking, that's comparing apples to oranges, those generated Makefiles are not meant to be readable, if you want to compare, look at configure.ac and Makefile.am. I also dislike CMake, but just saying it sucks is poor argumentation. Finally, in the title Ninja and Meson are mentioned, just to be completely ignored. I'm having a great experience with Meson, I would like to learn how the Zig build system is better than it, this piece unfortunately does not provide that.
I would go even further: showing the generated cmake file is like showing the disassembly from the zig snippet shown.
I still think the point stands though: zig's build system is nicer. Still bad IMHO as I despise build systems where you describe the build in the same language. Most of the time, it's much better to have a declarative rather than imperative build system. All in all, Ninja/Meson/Cargo/etc are much better in this regard.
(and yes, I think build.rs was a mistake, a necessary evil. Definitely not a feature)
I still think the point stands though: zig's build system is nicer. Still bad IMHO as I despise build systems where you describe the build in the same language. Most of the time, it's much better to have a declarative rather than imperative build system. All in all, Ninja/Meson/Cargo/etc are much better in this regard.
(and yes, I think build.rs was a mistake, a necessary evil. Definitely not a feature)
I have never once had to make a build.rs file, except to make python bindings for some of my own rust libraries. Are people out here using build.rs for everyday driving?
Bindings, and generally any form of code generation, is the most common form of build.rs I see in the wild.
One such example of "daily driving" is for gRPC, where the canonical way to generate the protobuf and gRPC bindings using Tonic+Prost is through build.rs. Another is C-to-Rust bindings, for all of those -sys crates.
Though I've also seen it used to circumvent limitations of Cargo, e.g. for invocations of dependent cargo build steps, etc. Overall, it's less common (or more robust?) than it used to be 5-ish years ago.
One such example of "daily driving" is for gRPC, where the canonical way to generate the protobuf and gRPC bindings using Tonic+Prost is through build.rs. Another is C-to-Rust bindings, for all of those -sys crates.
Though I've also seen it used to circumvent limitations of Cargo, e.g. for invocations of dependent cargo build steps, etc. Overall, it's less common (or more robust?) than it used to be 5-ish years ago.
I would love it if we introduced specialized means of addressing each of these use cases, to make them declarative.
I would assume, that when developing a game alone, you would depend a lot on libraries other have written. Is the Zig ecosystem rich enough in this respect, at this point?
The Zig compiler can compile C, C++ and ObjC, directly import C headers, directly call into C APIs and the Zig type system is very "C ABI friendly". So if something isn't available in pure Zig it's quite trivial to directly integrate dependencies that are written in C, C++ or ObjC (much easier than any other language I used so far).
There's also a centralized effort to wrap C/C++ libraries into Zig packages so that they can be easily consumed in the Zig build system:
https://github.com/allyourcodebase
There's also a centralized effort to wrap C/C++ libraries into Zig packages so that they can be easily consumed in the Zig build system:
https://github.com/allyourcodebase
> I would assume, that when developing a game alone, you would depend a lot on libraries other have written.
The guts of a game engine don't require any libraries at all. Using licensed offerings like havok for physics, etc., I don't think the language-specific part you might write (bindings, etc.) is a meaningful part of integrating the offering, and since they're licensed it's not as if you could just add them willy nilly in C++. You could argue that you'd want a language-specific library for some Steam SDK stuff, but AFAIK both Odin and Zig do have bindings for at least some important parts of these, and even if they didn't I don't think FFI is really that big of a problem in either language.
If you use Odin everything you need in order to create a game engine is shipped with it via the standard library (`math:linalg`, etc.) and vendor libraries (`vendor:{OpenGL,directx/direct3d11,directx/direct3d12,wgpu}`, etc.). If you really do want to use libraries `raylib` is also included, as well as SDL.
The guts of a game engine don't require any libraries at all. Using licensed offerings like havok for physics, etc., I don't think the language-specific part you might write (bindings, etc.) is a meaningful part of integrating the offering, and since they're licensed it's not as if you could just add them willy nilly in C++. You could argue that you'd want a language-specific library for some Steam SDK stuff, but AFAIK both Odin and Zig do have bindings for at least some important parts of these, and even if they didn't I don't think FFI is really that big of a problem in either language.
If you use Odin everything you need in order to create a game engine is shipped with it via the standard library (`math:linalg`, etc.) and vendor libraries (`vendor:{OpenGL,directx/direct3d11,directx/direct3d12,wgpu}`, etc.). If you really do want to use libraries `raylib` is also included, as well as SDL.
Ultimately, this will be determined by the scope of the project, and depends on whether you count using an existing C library as part of the Zig ecosystem.
If you want Zig libraries that don't call any C/C++ code whatsoever, then you're going to have a hard time (as of 2025). There's not, e.g, something as mature and tested as glfw in pure Zig. There is work being done to make pure Zig libraries for gamedev however, see for example Mach: https://machengine.org/
If you're happy to use C libraries though (as I am), then things are generally fine. Many of the most popular gamedev C/C++ libraries have already had their build systems converted into Zig (e.g. Raylib) and so can easily be added to a project without having to do any work in the build system.
For C libraries that aren't already packaged, or if you want to maintain full control of the build yourself, packaging libraries with the Zig build system isn't too bad, but it's still a lot of work. (E.g. Ghostty maintains its own build files for its packages; as a result there is a lot of Ghostty build system code: https://github.com/ghostty-org/ghostty/tree/main/pkg )
If you want Zig libraries that don't call any C/C++ code whatsoever, then you're going to have a hard time (as of 2025). There's not, e.g, something as mature and tested as glfw in pure Zig. There is work being done to make pure Zig libraries for gamedev however, see for example Mach: https://machengine.org/
If you're happy to use C libraries though (as I am), then things are generally fine. Many of the most popular gamedev C/C++ libraries have already had their build systems converted into Zig (e.g. Raylib) and so can easily be added to a project without having to do any work in the build system.
For C libraries that aren't already packaged, or if you want to maintain full control of the build yourself, packaging libraries with the Zig build system isn't too bad, but it's still a lot of work. (E.g. Ghostty maintains its own build files for its packages; as a result there is a lot of Ghostty build system code: https://github.com/ghostty-org/ghostty/tree/main/pkg )
You can easily integrate any C library, so pretty much all the important stuff is available. You also have Zig-gamedev repo where you have community written zig wrappers for those c libraries.
C interoperability is the name of the game with Zig, however there is a chance of reading article like "Moving away from Zig" in the future like we're seeing with Rust. At one point in time you have to decide whether you want to write a game or tinker with tech and engines. Both is absolutely fine, of course and most of us "get it", but it also depends on personal skills and pain and time threshold.
On point 4, I don't use zig but a two second google leads to http://ratfactor.com/zig/stdlib-browseable2/math/atan.zig.ht...
I wonder about the accuracy of the rest of the article.
I wonder about the accuracy of the rest of the article.
If you don't use zig, you might have missed why that error indicates a stdlib bug. The error in the article is down to a quirk of the type system where literals (like the literal float) have their own unique type (comptime_float) that can coerce to related types (f32, f64) but in this particular case, when atan switches on the type, it doesn't explicitly include comptime_float and fails. Seems like an oversight in the stdlib to me.
Missed all of that, thanks for the explanation. Why doesn't zig try and apply the coercion before the type switch - is this deliberate for safety?
Because "else" technically includes "comptime_float", so that case is handled, just not in the way that's expected.
One of the downsides of comptime over generics is that, because it's low-level and procedural instead of high-level and declarative, things like automatically inserting coercions become harder.
One of the downsides of comptime over generics is that, because it's low-level and procedural instead of high-level and declarative, things like automatically inserting coercions become harder.
I'm not sure but I would guess it's in the spirit of Zig's "explicit over implicit" philosophy. They are technically different types.
The issue is that atan wasn't implemented for a comptime float.
A "comptime f32" is different from an "f32"
A "comptime f32" is different from an "f32"
Am I the only one who feels this is a step back from platforms such as Stack Overflow? Discord is basically just a chat platform, and while it's nice that there are always people there who are willing to answer the same questions over and over again, you can't rely on that staying the same in the future. Whereas SO crowdsourced a "canonical" answer to a question, and if someone came up with the same question later (and didn't find the existing answer via the search function or Google), they could be pointed to that answer.