9 ms·

Zig: A new direction for low-level programming?

27 points by hmac1282 1y ago

deleted 1y ago
[deleted]
jbritton 1y ago
Instinctually I’m bothered by passing an allocator to everything. LISP’s dynamic variables spring to mind. One could set an arena allocator at the top of a loop in a dynamic variable and then everything inside the loop would use that allocator. The bottom of the loop could free everything. Although I do really like knowing if something might call an allocator, perhaps a function specifier to indicate it allocates. Although I’m intrigued by another idea I haven’t thought through. Haskell requires all function side effects to essentially propagate a description of the side effect up to main() where Haskell executes the side effect. There is also the idea of imperative shell, functional core that I don’t fully grasp. In any case perhaps all side effects should execute at the top level or maybe in a parallel environment and here passing an allocator would not be so onerous.
- bnolsen 1y ago
  That might violate the no implied behavior rule that zig has.
com2kid 1y ago
I disagree on many points the article makes, but it is well written and lays out its arguments well. One example - I prefer the named fields of Zig over Odin's use of positional fields. Zig's syntax is the more popular one as of late, heck even C has named struct member initialization. IMHO Positional is just asking for trouble. Yes it works fine for game programming, and not having to specify x and y thousands of times in a code base is nice, but for general purpose languages where a struct can have a dozen+ fields to init, positional assignment is how bugs are made.
- lerno 1y ago
  C gives either, I think that is the true with Odin as well, it certainly is for C3. I was assuming Zig allowed both. Is this another one of Zig being strict with ”only one way”?
- Simran-B 1y ago
  You can simply offer a function to create an object using positional arguments if you want that
  - hansvm 1y ago
    You can also create a function capable of doing that for any object, or one which curries the type parameter, if you'd like to reduce the boilerplate if you have many types of objects you'd like to instantiate positionally.
- hmac1282 1y ago
  I am only giving my impressions. Coming from other languages, this was very confusing, and the error messages were not helpful.
GianFabien 1y ago
I stumbled across Zig by a reference to it as part of the Bun (JS engine) documentation. I didn't find the Zig language benefits sufficiently compelling to learn yet another opinionated language. Since much of my work is with embedded and bespoke systems, I did find the Zig cc front-end to LLVM convenient. Maybe it's because I haven't sufficiently mastered Clang for cross-compilation.
- davemp 1y ago
  I’m using zig for embedded builds currently. All of the mcu files are still in C (arm thumb isn’t first class supported in zig) but the host software is sometimes zig. Being and to easily develop on and for any host platform is such a pleasure. I can just tell junior devs to download zig and a vscode extension and they’re off to the races.
fithisux 1y ago
I like the try/catch of Zig. It is innovative. Moreover Zig is a research playground. Ideas will find their way to D/Nim. Zig CC is another innovation. The compile time is also a great experiment. It brings a lot to the table. May not be a total C replacement, but it is an improvement and lots of C code, can be written in Zig. Lots of people can be introduced to Systems Programming with Zig. For Low Level coding, have you heard of FASM? Better than C in my opinion.
- hmac1282 1y ago
  What people want today is easy cross platform coding, something poorly served by C, but served much better by both Zig and Odin.
lerno 1y ago
The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point. I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.
- chienandalou 1y ago
  It's cool that it's so easy with Odin, but I think whether it takes one minute to set up Raylib with Odin or three minutes with Zig or C3 is pretty insignificant for any real project.
cranberryturkey 1y ago
https://smashlang.com https://smashlang.com
- gliptic 1y ago
  > Dynamic Typing: Flexible type system with runtime type checking Uhm, what does this have to do with C/Zig?
  - cranberryturkey 1y ago
    its another alternative to C
    - bonzini 1y ago
      It doesn't even distinguish integer and floating point?
    - gliptic 1y ago
      It's really not. Looks like something like JS with almost identical syntax. Also, the compiler (and what else?) isn't even implemented [1]. [1] https://github.com/profullstack/smashlang/blob/master/src/compiler.rs https://github.com/profullstack/smashlang/blob/master/src/co...
trealira 1y ago
The message I got upon connecting to this site: > Website Access Prohibited > Malware Website Warning > The website you are trying to access is known to host malware and poses a security risk to your computer and network. Please contact your IT help desk to review if you are impacted. If you think you are receiving this message in error, please contact your IT help desk. I guess you should know your website is seen as a malware vector.
- patrakov 1y ago
  Some anti-malware vendors apply this classification to the whole .cc domain.
  - trealira 1y ago
    I see. That might be what's happened, then.
    - sph 1y ago
      Name and shame the anti-malware vendor you/your company is using, so that I will avoid them.
      - trealira 1y ago
        I don't know for sure, but I can tell you that this isn't a company, but a university, and based on a press release from a couple years ago, I'm pretty sure they use OnSystem Defender. This might not be their fault, though; it might be that the school itself blocked all .cc domains using their own firewall rules.
  - tmtvl 1y ago
    What did the Cocos Islands do to deserve that? They don't seem to be a den of villainy and cybercrime.
GardenLetter27 1y ago
The worst part IMO is no decent LSP like rust-analyzer.
- hansvm 1y ago
  What does the LSP lack?
  - GardenLetter27 1y ago
    When I tried it, it just didn't detect loads of stuff. It reminded me of writing Go years ago.
bonzini 1y ago
Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement. Having to know the full set of Zig sources in advance due to error types, and the strong accent on Zig as a build system, are both a non starter for integration in existing large C programs, for example.
- anonymoushn 1y ago
  You can't have monomorphization or the old async feature if you need to be able to convert individual files to C.
  - bonzini 1y ago
    You can do it in multiple passes (analysis/dumping IR followed by code generation, with dep files to connect them). It's what Rust does internally with rmeta files. Mine is not necessarily a criticism of Zig, mind. It's a criticism of what is needed from a C replacement.
- davemp 1y ago
  Replacing C != coexisting seamlessly. Exposing an idiomatic C interface by default would handcuff Zig’s own design. > Having to know the full set of Zig sources in advance due to error types You can just catch all of the errors and translate them back into errno or whatever homegrown scheme your c project is using. - - - Does the zig compiler not support generating .o’s without a build.zig? I like the zig build system so much that I’ve migrated some large projects that will likely never contain a line of zig, so I haven’t felt that pain point.
  - kristoff_it 1y ago
    > Does the zig compiler not support generating .o’s without a build.zig? Of course it does, all the build system does is orchestrate invocations to the other basic zig subcommands (`build-exe`, `build-lib`, `build-obj`, etc). You can invoke `zig build-obj` and get an object file in whatever flavor you prefer.
90s_dev 1y ago
> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const. This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn the language. I get the rationale, that it's trying to protect me from shipping poorly designed code. But helicopter mom features do not belong in a programming language. They are just as hindering to progress as a literal one would be to a grown man, and for the exact same reasons. I know Andrew has made up his mind, but minds can be changed. So please, Andrew, please take away this helicopter mom feature.
- Icathian 1y ago
  This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.
  - deleted 1y ago
    [deleted]
  - 90s_dev 1y ago
    Not using a variable is the same as flying out your car window? It's more like the cashier smacks a peanut out of your hand saying you'll get fat.
    - dmit 1y ago
      Even when compiling in Debug mode! Where the analogy is closer to a friend who's applying for a cashier job asking you to role play being a customer so they could practice, and then spitting in your face when you go "Hey, Joe! I'll take these" because "No real life customer would do that! Start over."
      - 90s_dev 1y ago
        > Even when compiling in Debug mode! closer to a friend asking you to role play being a customer so they could practice, and then spitting in your face saying "No customer would do that! Start over." Thanks for the hearty laugh :D
weiwenhao 1y ago
zig ld should be the only cross-linker out there, and I'm considering migrating to zig, for zig ld's sake . All programming languages that claim to be alternatives to C eventually become themselves, zig is good enough and different enough to not care about being an alternative to C!
SoraNoTenshi 1y ago
I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic. And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an example) Verbosity is mostly subjective. Most of Author's concerns were path lengths, which can easily be "fixed" by redefining the path into a constant. `const debug = std.debug;` I also think the Argument towards "it looks like java's println" full on is a bad argument. Especially because `std.debug.print` does something completely different. The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it. Then half of the arguments about comptime i also don't quite understand. It seems like it is building up the main point of the argument, but then you just get hit by a statement. So no explanation no nothing. Talking about lazy evaluation and a little bit of how SoA makes things worse (which i have no clue how that matters in this context) and then saying it's violation "no hidden control flow" is not really getting the point i feel like.
- deleted 1y ago
  [deleted]
- 90s_dev 1y ago
  > The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it. He just pointed out to us language skimmers that it's a potential chicken egg problem, which we may not have considered. Perfect for this kind of article. Whereas pointing out its merits would just be recreating part of ziglang.org
  - SoraNoTenshi 1y ago
    I mean reading through the article it was only considering author's present perception which is a bit too naïve in my opinion. Out of my head, the benefits of having a `build.zig` that you learn right from the get go is, that you kind of have to dig a bit into the eco-system a bit. Also how the buildsystem works, etc. which then in return makes it muuuuch easier later on if you have a bigger project, to properly utilize the power of the buildsystem. I can also only consider my perspective here, but I've done quite a bit of Rust now (and work with it for over a year now, full time as well), and i can tell you as much: I would be thrown into icy waters if i need to do anything with a build.rs.
stephc_int13 1y ago
I've been closely following and evaluating the train of C replacement languages that was (I believe) started by Jonathan Blow and Jai. Zig is one of the strong contenders, but Odin is IMO following a saner path, Carbon and D should be mentioned and I think there are a few others. My initial reaction to new programming languages is naturally skeptical, but I really liked the way the designers behind those efforts approached it, trying to solve frequent C/C++ pain points and adding a few fresh ideas. But overall, after a few years, I am sticking with C and orthodox C++, the cost/benefit ratio is simply not worth the effort, none of them are really mature and the problems they try to solve are not painful enough. My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. An other analogy that can be made is the many attempts at replacing keyboards layouts. Dvorak etc. They probably have their merits, but the adoption was limited to a few enthusiasts for the same reasons that C is unlikely to get replaced by any of those forks.
- 90s_dev 1y ago
  > My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. Didn't Rust do the same thing? We only call efforts wasteful until they become mainstream, then in retrospect we call it excitement driven prudence. Anyway, is there an "Odin for C programmers" short guide, so I can learn it more quickly?
  - stephc_int13 1y ago
    Rust is a bit different, more like a C++ replacement and heavily focused on so-called memory safety, but with IMO many bad design decisions, while I consider Zig/Jai/Odin as merely "meh" I think that Rust is bad.
    - cadu2 1y ago
      Can you comment you some of these decisions in Rust that you feel are bad? I enjoy the language and have done quite a bit of work with it so I might be blinded/biased. I feel some warts here and there (async fns, anyone?), but overall the thing works and `cargo` is really a blessing.
macintux 1y ago
Discussion yesterday of Odin, that touched on Zig and D. https://news.ycombinator.com/item?id=43939520 https://news.ycombinator.com/item?id=43939520
- dang 1y ago
  Thanks! Macroexpanded: Odin, a pragmatic C alternative with a Go flavour - https://news.ycombinator.com/item?id=43939520 https://news.ycombinator.com/item?id=43939520 - May 2025 (106 comments)
pron 1y ago
Because we rarely have objective measures by which to compare programming languages, there is no such thing as "ideal." Some objective measures can include code size, and it is undoubtedly true that switching from Assembly to Python often results in a super-linear reduction in code size, but we rarely see such differences anymore. When we do get some objective comparisons through empirical research -- always many years later -- we also find that usually differences between languages are smaller than many would expect [1]. This isn't surprising and, in fact, it was predicted by Fred Brooks in the 80s. This is because much of the difficulty in constructing algorithms is essential. This is not just due to results in computational complexity about the fundamental difficulty in constructing and analysing programs, but also part of computers' utility. As I once heard a NASA developer say, "computers were built to surprise us; if we knew their output we wouldn't need to build them." That's a long-winded way of saying that programming language preference is mostly a matter of personal taste as well as more objective but non-intrinsic, "environmental" or social factors. But that doesn't mean that preferences are evenly distributed. Even within a specific domain there may be big disagreements among programmers over which language is "better," but some languages may appeal to significantly more people than others. Programming language designers, at least those who target their language for wide audiences, effectively try to pick tradeoffs that they guess would appeal to many. This is what makes statements like "but as we all know, it’s not always the best alternative that wins" meaningless. Winning means appealing to more people, i.e. having a good "market fit", whereas "best" has no agreed-upon definition. Like in the famous story about Betamax vs VHS, one had a better picture quality at the expense of recording time, and it turned out that a longer recording time was more important to them than better picture quality. In various debates over programming languages, I often see people frustrated when confronted with the reality that other people prefer different tradeoffs to their own preferred ones. What the author find surprising or confusing in Zig are things others find desirable (for reasons such as making the language more expressive, simpler, more easily portable, or faster to compile). If you prefer Odin or Rust or Jai -- use them; that different people prefer different languages is very much to be expected. But one of the things I, subjectively, find appealing in Zig has to do with the point made in the post about "high level conveniences" and "abtractions." Over the past several decades, high-level languages have become so fast that in most software it makes little sense to use low-level languages regardless of the "high level conveniences" they may offer. But low-level languages still have a very important role to play when full control over resource usage (especially memory) is needed, such as in constrained environments. That is why I, as someone who does both high and low-level programming, prefer a separation between the two. I probably won't write a large, complex application in any low-level language, and when I do write low-level code, what's important to me is to clearly see what's going on. Anything that hides that from me isn't a convenience but an inconvenience when doing this kind of programming. To me, subjectively, it seems that making low-level languages appear more high level is a mistake -- it hinders low-level programming without offering a truly compelling alternative to a high-level language. Whether my preferences or the author's are more common is something we'll find out in another decade or so. [1]: One of the things I find annoying -- not only in programming language debates but in science and technology discourse in general -- is invalid extrapolation of valid empirical results. For example, we do have some valid empirical comparisons of TypeScript vs JavaScript or Rust vs. C, but extrapolating from those to conclusions about, say, TypeScript vs. Clojure or Rust vs. Zig requires making unfounded (as yet) assumptions (such as that all untyped languages are alike or that all languages that don't soundly prevent all undefined behaviour are alike).
dustbunny 1y ago
Some fair criticisms of differing importance, but the tone of the article feels pretty off putting. Almost like the author has some personal gripe against someone affiliated with Zig something.
behnamoh 1y ago
C is not going anywhere. Neither are C++, Java, and JS (less sure about TS). One reason is that we've built most of the foundations of modern software already in these languages. New apps pop up all the time but they all rely on ffmpeg, etc. The only way for a new language like Zig to cement itself is to build foundational software that other programs depend on. I don't think even Rust is moving in that direction (lots of Rust apps, but not so many libs I've had to use in my programs that were written in Rust).
- josephg 1y ago
  A language doesn't need to be used in foundational software to be relevant or useful. Go isn't built in the OS either, but its still used by lots of developers to write useful software. This might be controversial, but I think its fine for small languages to exist, with small followings. Nobody will ever make a browser in Haskell, but its still a work of art. Nobody uses Elm, but React wouldn't exist without it. And so on. Rust is useful on its own. But its also already inspired the C++ language committee to start talking about memory safety a lot more seriously. Thats a big deal! I'm delighted that languages like Zig exist. If for no other reason than to show that if you're dedicated enough, a lone hobbyist can still invent a language and make it good. (I wish that were still true for web browsers.)
- dumah 1y ago
  From my perspective, the adoption for Linux kernel modules, prevalence in the ecosystem of data science my industry relies on, and the explosion of great rust CLI tools satisfies this foundation. Native rust extensions to provide canonical high quality interfaces for other languages, like Valkey Glide are another example. Adding on the fact that rust is the fastest or nearly the fastest growing language in terms of users, and I can’t agree with the view that it is not moving in that direction.
- jeberle 1y ago
  Ubuntu's move to uutils suggests Rust is not going anywhere.
pjmlp 1y ago
That would have been Modula-2 already in 1978, but sadly Acorn, yes the one from ARM, was the only OS vendor adopting it.
dvh 1y ago
Does it run on Arduino?
jmull 1y ago
The author hand waves away ReleaseSafe, but does not really seem to understand its usage. I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Since zig allows turning off/on safety checks on a per-block basis, you only need to pay as much of a performance cost as you want for this. Actually, this doesn't really come across as a sincere critique of zig. It's more like how a sport fan talks about a rival team (I guess the author must be team Odin). The "first impressions" section is silly.. of course you don't understand how it all works before you've learned anything about it. It might be a bit confusing and have some new patterns. And yes, all the options of the advanced build system is complex, but... you can use the simple build mechanism, or just go with the template for that matter. Myself, I think there are certainly valid criticisms of zig to make and I don't know if it's ultimately going to amount to something, but you've got to have some knowledge of the subject and not come at it with a predetermined conclusion.
- dmit 1y ago
  > I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Which profile is the default for the Zig compiler itself? What about Bun? TigerBeetle was the only one of the three to use ReleaseSafe by default last I checked? (Edit: in fact, they outright ban ReleaseFast and ReleaseSmall because they care about correctness.) ZLS suggests ReleaseSafe in its README too, if you count it among the prominent Zig projects.
  - kristoff_it 1y ago
    Zig ships release fast but there's an accepted proposal (not implemented yet) to change unstable builds to be release safe.
    - dmit 1y ago
      You mean the official nightlies? I like that plan! Should boost coverage by a lot in irl projects.
charlie-83 1y ago
Its always interesting to me that other people have such an issue with languages being verbose. I have never really understood why people feel this way. It's just a bit of extra typing. I also think it generally increases code readability. Anyone who dislikes verbose languages care to explain their perspective to me?
EPWN3D 1y ago
I think the author's criticism of the named initializer requirement is emblematic of a big problem I have with most new languages. The author says that it makes things like vectors more verbose and awkward, which is true. My counter to this is: who gives a shit? I'm not writing a vector library or a game engine; I'm writing systems code, and unnamed initializers are harder to read and expose code to subtle bugs. And for what? So that vectors look prettier? A lot of programming language design seems to prioritize making its own standard library math functions more elegant to implement, which I find to be very irritating, and Zig is a breath of fresh air in this regard.
ur-whale 1y ago
> the language motto is “No hidden control flow”. Oh man, I wish the Haskell crowd gave at the very least lip service to that type of idea.
- tome 1y ago
  If you like that idea you might like my library Bluefin, where even throwing exceptions requires an explicit value telling you where control will return to. https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin
pepa65 1y ago
For the Bitshifters author: could you do a review of the V language as well?
- hmac1282 1y ago
  Yes.
- hmac1282 1y ago
  It is here: https://bitshifters.cc/2025/05/17/vlang.html https://bitshifters.cc/2025/05/17/vlang.html
hmac1282 1y ago
The full list of articles: Jai: https://bitshifters.cc/2025/04/28/jai.html https://bitshifters.cc/2025/04/28/jai.html Odin: https://bitshifters.cc/2025/05/04/odin.html https://bitshifters.cc/2025/05/04/odin.html Zig: https://bitshifters.cc/2025/05/04/zig.html https://bitshifters.cc/2025/05/04/zig.html V: https://bitshifters.cc/2025/05/17/vlang.html https://bitshifters.cc/2025/05/17/vlang.html C3: https://bitshifters.cc/2025/05/22/c3-c-tradition.html https://bitshifters.cc/2025/05/22/c3-c-tradition.html

27 points by hmac1282 1y ago

deleted 1y ago

[deleted]

Instinctually I’m bothered by passing an allocator to everything. LISP’s dynamic variables spring to mind. One could set an arena allocator at the top of a loop in a dynamic variable and then everything inside the loop would use that allocator. The bottom of the loop could free everything. Although I do really like knowing if something might call an allocator, perhaps a function specifier to indicate it allocates. Although I’m intrigued by another idea I haven’t thought through. Haskell requires all function side effects to essentially propagate a description of the side effect up to main() where Haskell executes the side effect. There is also the idea of imperative shell, functional core that I don’t fully grasp. In any case perhaps all side effects should execute at the top level or maybe in a parallel environment and here passing an allocator would not be so onerous.

bnolsen 1y ago
That might violate the no implied behavior rule that zig has.

com2kid 1y ago

I disagree on many points the article makes, but it is well written and lays out its arguments well. One example - I prefer the named fields of Zig over Odin's use of positional fields. Zig's syntax is the more popular one as of late, heck even C has named struct member initialization. IMHO Positional is just asking for trouble. Yes it works fine for game programming, and not having to specify x and y thousands of times in a code base is nice, but for general purpose languages where a struct can have a dozen+ fields to init, positional assignment is how bugs are made.

lerno 1y ago
C gives either, I think that is the true with Odin as well, it certainly is for C3. I was assuming Zig allowed both. Is this another one of Zig being strict with ”only one way”?
Simran-B 1y ago
You can simply offer a function to create an object using positional arguments if you want that
- hansvm 1y ago
  You can also create a function capable of doing that for any object, or one which curries the type parameter, if you'd like to reduce the boilerplate if you have many types of objects you'd like to instantiate positionally.
hmac1282 1y ago
I am only giving my impressions. Coming from other languages, this was very confusing, and the error messages were not helpful.

GianFabien 1y ago

I stumbled across Zig by a reference to it as part of the Bun (JS engine) documentation. I didn't find the Zig language benefits sufficiently compelling to learn yet another opinionated language. Since much of my work is with embedded and bespoke systems, I did find the Zig cc front-end to LLVM convenient. Maybe it's because I haven't sufficiently mastered Clang for cross-compilation.

davemp 1y ago
I’m using zig for embedded builds currently. All of the mcu files are still in C (arm thumb isn’t first class supported in zig) but the host software is sometimes zig. Being and to easily develop on and for any host platform is such a pleasure. I can just tell junior devs to download zig and a vscode extension and they’re off to the races.

fithisux 1y ago

I like the try/catch of Zig. It is innovative. Moreover Zig is a research playground. Ideas will find their way to D/Nim. Zig CC is another innovation. The compile time is also a great experiment. It brings a lot to the table. May not be a total C replacement, but it is an improvement and lots of C code, can be written in Zig. Lots of people can be introduced to Systems Programming with Zig. For Low Level coding, have you heard of FASM? Better than C in my opinion.

hmac1282 1y ago
What people want today is easy cross platform coding, something poorly served by C, but served much better by both Zig and Odin.

lerno 1y ago

The ease of using Odin over Zig for Raylib was an interesting contrast that I hadn’t reflected on myself. I tried to do things well with C3, but it might be hard to beat Odin on that particular point. I just wonder how well it will work long term with update cycles and such. Zig and C3’s decentralized model seems easier for handling frequently updating libraries.

chienandalou 1y ago
It's cool that it's so easy with Odin, but I think whether it takes one minute to set up Raylib with Odin or three minutes with Zig or C3 is pretty insignificant for any real project.

cranberryturkey 1y ago

https://smashlang.com https://smashlang.com

gliptic 1y ago
> Dynamic Typing: Flexible type system with runtime type checking Uhm, what does this have to do with C/Zig?
- cranberryturkey 1y ago
  its another alternative to C
  - bonzini 1y ago
    It doesn't even distinguish integer and floating point?
  - gliptic 1y ago
    It's really not. Looks like something like JS with almost identical syntax. Also, the compiler (and what else?) isn't even implemented [1]. [1] https://github.com/profullstack/smashlang/blob/master/src/compiler.rs https://github.com/profullstack/smashlang/blob/master/src/co...

trealira 1y ago

The message I got upon connecting to this site: > Website Access Prohibited > Malware Website Warning > The website you are trying to access is known to host malware and poses a security risk to your computer and network. Please contact your IT help desk to review if you are impacted. If you think you are receiving this message in error, please contact your IT help desk. I guess you should know your website is seen as a malware vector.

patrakov 1y ago
Some anti-malware vendors apply this classification to the whole .cc domain.
- trealira 1y ago
  I see. That might be what's happened, then.
  - sph 1y ago
    Name and shame the anti-malware vendor you/your company is using, so that I will avoid them.
    - trealira 1y ago
      I don't know for sure, but I can tell you that this isn't a company, but a university, and based on a press release from a couple years ago, I'm pretty sure they use OnSystem Defender. This might not be their fault, though; it might be that the school itself blocked all .cc domains using their own firewall rules.
- tmtvl 1y ago
  What did the Cocos Islands do to deserve that? They don't seem to be a den of villainy and cybercrime.

GardenLetter27 1y ago

The worst part IMO is no decent LSP like rust-analyzer.

hansvm 1y ago
What does the LSP lack?
- GardenLetter27 1y ago
  When I tried it, it just didn't detect loads of stuff. It reminded me of writing Go years ago.

bonzini 1y ago

Back when it still had async support, I looked at using Zig in QEMU. My main qualm with it is that it doesn't try to integrate with existing C programs. The ideal C replacement for me would be a two-way per-file C transpiler, in the same way as the Vala language was. Cython also works the same way even though it's not a C replacement. Having to know the full set of Zig sources in advance due to error types, and the strong accent on Zig as a build system, are both a non starter for integration in existing large C programs, for example.

anonymoushn 1y ago
You can't have monomorphization or the old async feature if you need to be able to convert individual files to C.
- bonzini 1y ago
  You can do it in multiple passes (analysis/dumping IR followed by code generation, with dep files to connect them). It's what Rust does internally with rmeta files. Mine is not necessarily a criticism of Zig, mind. It's a criticism of what is needed from a C replacement.
davemp 1y ago
Replacing C != coexisting seamlessly. Exposing an idiomatic C interface by default would handcuff Zig’s own design. > Having to know the full set of Zig sources in advance due to error types You can just catch all of the errors and translate them back into errno or whatever homegrown scheme your c project is using. - - - Does the zig compiler not support generating .o’s without a build.zig? I like the zig build system so much that I’ve migrated some large projects that will likely never contain a line of zig, so I haven’t felt that pain point.
- kristoff_it 1y ago
  > Does the zig compiler not support generating .o’s without a build.zig? Of course it does, all the build system does is orchestrate invocations to the other basic zig subcommands (`build-exe`, `build-lib`, `build-obj`, etc). You can invoke `zig build-obj` and get an object file in whatever flavor you prefer.

90s_dev 1y ago

> Of course, if you don’t use pos, the compiler will say that this is an error and refuse to compile as well. And if you discard that error (typically using _ = pos;), the compiler will complain that it should be a const. This was one of the main things that bothered me about Zig when I last tried it. This actively works against me when writing prototypes, exploratory code, and especially when writing code to learn the language. I get the rationale, that it's trying to protect me from shipping poorly designed code. But helicopter mom features do not belong in a programming language. They are just as hindering to progress as a literal one would be to a grown man, and for the exact same reasons. I know Andrew has made up his mind, but minds can be changed. So please, Andrew, please take away this helicopter mom feature.

Icathian 1y ago
This is the exact same attitude as people who threw tantrums about seatbelt laws in the 90s. It was wrong then, and it's wrong now. For mostly the same reasons.
- deleted 1y ago
  [deleted]
- 90s_dev 1y ago
  Not using a variable is the same as flying out your car window? It's more like the cashier smacks a peanut out of your hand saying you'll get fat.
  - dmit 1y ago
    Even when compiling in Debug mode! Where the analogy is closer to a friend who's applying for a cashier job asking you to role play being a customer so they could practice, and then spitting in your face when you go "Hey, Joe! I'll take these" because "No real life customer would do that! Start over."
    - 90s_dev 1y ago
      > Even when compiling in Debug mode! closer to a friend asking you to role play being a customer so they could practice, and then spitting in your face saying "No customer would do that! Start over." Thanks for the hearty laugh :D

weiwenhao 1y ago

zig ld should be the only cross-linker out there, and I'm considering migrating to zig, for zig ld's sake . All programming languages that claim to be alternatives to C eventually become themselves, zig is good enough and different enough to not care about being an alternative to C!

SoraNoTenshi 1y ago

I am not entirely sure what the Author is criticizing? It looks like a comparison to Odin rather than any critic. And also: I don't quite understand most of the Arguments. UB is often a way to ensure that certain optimizations can be made (if i remember correctly.) Also there just are certain facts that when you have full control over memory, some things can just not be predictable. (Accessing invalid pointers as an example) Verbosity is mostly subjective. Most of Author's concerns were path lengths, which can easily be "fixed" by redefining the path into a constant. `const debug = std.debug;` I also think the Argument towards "it looks like java's println" full on is a bad argument. Especially because `std.debug.print` does something completely different. The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it. Then half of the arguments about comptime i also don't quite understand. It seems like it is building up the main point of the argument, but then you just get hit by a statement. So no explanation no nothing. Talking about lazy evaluation and a little bit of how SoA makes things worse (which i have no clue how that matters in this context) and then saying it's violation "no hidden control flow" is not really getting the point i feel like.

deleted 1y ago
[deleted]
90s_dev 1y ago
> The whole "critic" towards `build.zig` also seems like it's done with without good faith. Yes it's daunting at first. Yes it requires to learn about the build system in the beginning. Sure those are all very real Arguments, author just doesn't want to mention the benefits of it. He just pointed out to us language skimmers that it's a potential chicken egg problem, which we may not have considered. Perfect for this kind of article. Whereas pointing out its merits would just be recreating part of ziglang.org
- SoraNoTenshi 1y ago
  I mean reading through the article it was only considering author's present perception which is a bit too naïve in my opinion. Out of my head, the benefits of having a `build.zig` that you learn right from the get go is, that you kind of have to dig a bit into the eco-system a bit. Also how the buildsystem works, etc. which then in return makes it muuuuch easier later on if you have a bigger project, to properly utilize the power of the buildsystem. I can also only consider my perspective here, but I've done quite a bit of Rust now (and work with it for over a year now, full time as well), and i can tell you as much: I would be thrown into icy waters if i need to do anything with a build.rs.

stephc_int13 1y ago

I've been closely following and evaluating the train of C replacement languages that was (I believe) started by Jonathan Blow and Jai. Zig is one of the strong contenders, but Odin is IMO following a saner path, Carbon and D should be mentioned and I think there are a few others. My initial reaction to new programming languages is naturally skeptical, but I really liked the way the designers behind those efforts approached it, trying to solve frequent C/C++ pain points and adding a few fresh ideas. But overall, after a few years, I am sticking with C and orthodox C++, the cost/benefit ratio is simply not worth the effort, none of them are really mature and the problems they try to solve are not painful enough. My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. An other analogy that can be made is the many attempts at replacing keyboards layouts. Dvorak etc. They probably have their merits, but the adoption was limited to a few enthusiasts for the same reasons that C is unlikely to get replaced by any of those forks.

90s_dev 1y ago
> My current take on this is to view Jai/Zig/Odin/etc. as attempted C forks, quite often motivated by hubris and coming with the usual inconvenience of forks, a lot of wasteful/redundant efforts put into small islands, each ruled by their own "benevolent" kings. Didn't Rust do the same thing? We only call efforts wasteful until they become mainstream, then in retrospect we call it excitement driven prudence. Anyway, is there an "Odin for C programmers" short guide, so I can learn it more quickly?
- stephc_int13 1y ago
  Rust is a bit different, more like a C++ replacement and heavily focused on so-called memory safety, but with IMO many bad design decisions, while I consider Zig/Jai/Odin as merely "meh" I think that Rust is bad.
  - cadu2 1y ago
    Can you comment you some of these decisions in Rust that you feel are bad? I enjoy the language and have done quite a bit of work with it so I might be blinded/biased. I feel some warts here and there (async fns, anyone?), but overall the thing works and `cargo` is really a blessing.

macintux 1y ago

Discussion yesterday of Odin, that touched on Zig and D. https://news.ycombinator.com/item?id=43939520 https://news.ycombinator.com/item?id=43939520

dang 1y ago
Thanks! Macroexpanded: Odin, a pragmatic C alternative with a Go flavour - https://news.ycombinator.com/item?id=43939520 https://news.ycombinator.com/item?id=43939520 - May 2025 (106 comments)

pron 1y ago

Because we rarely have objective measures by which to compare programming languages, there is no such thing as "ideal." Some objective measures can include code size, and it is undoubtedly true that switching from Assembly to Python often results in a super-linear reduction in code size, but we rarely see such differences anymore. When we do get some objective comparisons through empirical research -- always many years later -- we also find that usually differences between languages are smaller than many would expect [1]. This isn't surprising and, in fact, it was predicted by Fred Brooks in the 80s. This is because much of the difficulty in constructing algorithms is essential. This is not just due to results in computational complexity about the fundamental difficulty in constructing and analysing programs, but also part of computers' utility. As I once heard a NASA developer say, "computers were built to surprise us; if we knew their output we wouldn't need to build them." That's a long-winded way of saying that programming language preference is mostly a matter of personal taste as well as more objective but non-intrinsic, "environmental" or social factors. But that doesn't mean that preferences are evenly distributed. Even within a specific domain there may be big disagreements among programmers over which language is "better," but some languages may appeal to significantly more people than others. Programming language designers, at least those who target their language for wide audiences, effectively try to pick tradeoffs that they guess would appeal to many. This is what makes statements like "but as we all know, it’s not always the best alternative that wins" meaningless. Winning means appealing to more people, i.e. having a good "market fit", whereas "best" has no agreed-upon definition. Like in the famous story about Betamax vs VHS, one had a better picture quality at the expense of recording time, and it turned out that a longer recording time was more important to them than better picture quality. In various debates over programming languages, I often see people frustrated when confronted with the reality that other people prefer different tradeoffs to their own preferred ones. What the author find surprising or confusing in Zig are things others find desirable (for reasons such as making the language more expressive, simpler, more easily portable, or faster to compile). If you prefer Odin or Rust or Jai -- use them; that different people prefer different languages is very much to be expected. But one of the things I, subjectively, find appealing in Zig has to do with the point made in the post about "high level conveniences" and "abtractions." Over the past several decades, high-level languages have become so fast that in most software it makes little sense to use low-level languages regardless of the "high level conveniences" they may offer. But low-level languages still have a very important role to play when full control over resource usage (especially memory) is needed, such as in constrained environments. That is why I, as someone who does both high and low-level programming, prefer a separation between the two. I probably won't write a large, complex application in any low-level language, and when I do write low-level code, what's important to me is to clearly see what's going on. Anything that hides that from me isn't a convenience but an inconvenience when doing this kind of programming. To me, subjectively, it seems that making low-level languages appear more high level is a mistake -- it hinders low-level programming without offering a truly compelling alternative to a high-level language. Whether my preferences or the author's are more common is something we'll find out in another decade or so. [1]: One of the things I find annoying -- not only in programming language debates but in science and technology discourse in general -- is invalid extrapolation of valid empirical results. For example, we do have some valid empirical comparisons of TypeScript vs JavaScript or Rust vs. C, but extrapolating from those to conclusions about, say, TypeScript vs. Clojure or Rust vs. Zig requires making unfounded (as yet) assumptions (such as that all untyped languages are alike or that all languages that don't soundly prevent all undefined behaviour are alike).

dustbunny 1y ago

Some fair criticisms of differing importance, but the tone of the article feels pretty off putting. Almost like the author has some personal gripe against someone affiliated with Zig something.

behnamoh 1y ago

C is not going anywhere. Neither are C++, Java, and JS (less sure about TS). One reason is that we've built most of the foundations of modern software already in these languages. New apps pop up all the time but they all rely on ffmpeg, etc. The only way for a new language like Zig to cement itself is to build foundational software that other programs depend on. I don't think even Rust is moving in that direction (lots of Rust apps, but not so many libs I've had to use in my programs that were written in Rust).

josephg 1y ago
A language doesn't need to be used in foundational software to be relevant or useful. Go isn't built in the OS either, but its still used by lots of developers to write useful software. This might be controversial, but I think its fine for small languages to exist, with small followings. Nobody will ever make a browser in Haskell, but its still a work of art. Nobody uses Elm, but React wouldn't exist without it. And so on. Rust is useful on its own. But its also already inspired the C++ language committee to start talking about memory safety a lot more seriously. Thats a big deal! I'm delighted that languages like Zig exist. If for no other reason than to show that if you're dedicated enough, a lone hobbyist can still invent a language and make it good. (I wish that were still true for web browsers.)
dumah 1y ago
From my perspective, the adoption for Linux kernel modules, prevalence in the ecosystem of data science my industry relies on, and the explosion of great rust CLI tools satisfies this foundation. Native rust extensions to provide canonical high quality interfaces for other languages, like Valkey Glide are another example. Adding on the fact that rust is the fastest or nearly the fastest growing language in terms of users, and I can’t agree with the view that it is not moving in that direction.
jeberle 1y ago
Ubuntu's move to uutils suggests Rust is not going anywhere.

pjmlp 1y ago

That would have been Modula-2 already in 1978, but sadly Acorn, yes the one from ARM, was the only OS vendor adopting it.

dvh 1y ago

Does it run on Arduino?

jmull 1y ago

The author hand waves away ReleaseSafe, but does not really seem to understand its usage. I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Since zig allows turning off/on safety checks on a per-block basis, you only need to pay as much of a performance cost as you want for this. Actually, this doesn't really come across as a sincere critique of zig. It's more like how a sport fan talks about a rival team (I guess the author must be team Odin). The "first impressions" section is silly.. of course you don't understand how it all works before you've learned anything about it. It might be a bit confusing and have some new patterns. And yes, all the options of the advanced build system is complex, but... you can use the simple build mechanism, or just go with the template for that matter. Myself, I think there are certainly valid criticisms of zig to make and I don't know if it's ultimately going to amount to something, but you've got to have some knowledge of the subject and not come at it with a predetermined conclusion.

dmit 1y ago
> I don't think zig best-practices are written in stone yet, but I would expect ReleaseSafe to be the default in production. Which profile is the default for the Zig compiler itself? What about Bun? TigerBeetle was the only one of the three to use ReleaseSafe by default last I checked? (Edit: in fact, they outright ban ReleaseFast and ReleaseSmall because they care about correctness.) ZLS suggests ReleaseSafe in its README too, if you count it among the prominent Zig projects.
- kristoff_it 1y ago
  Zig ships release fast but there's an accepted proposal (not implemented yet) to change unstable builds to be release safe.
  - dmit 1y ago
    You mean the official nightlies? I like that plan! Should boost coverage by a lot in irl projects.

charlie-83 1y ago

Its always interesting to me that other people have such an issue with languages being verbose. I have never really understood why people feel this way. It's just a bit of extra typing. I also think it generally increases code readability. Anyone who dislikes verbose languages care to explain their perspective to me?

EPWN3D 1y ago

I think the author's criticism of the named initializer requirement is emblematic of a big problem I have with most new languages. The author says that it makes things like vectors more verbose and awkward, which is true. My counter to this is: who gives a shit? I'm not writing a vector library or a game engine; I'm writing systems code, and unnamed initializers are harder to read and expose code to subtle bugs. And for what? So that vectors look prettier? A lot of programming language design seems to prioritize making its own standard library math functions more elegant to implement, which I find to be very irritating, and Zig is a breath of fresh air in this regard.

ur-whale 1y ago

> the language motto is “No hidden control flow”. Oh man, I wish the Haskell crowd gave at the very least lip service to that type of idea.

tome 1y ago
If you like that idea you might like my library Bluefin, where even throwing exceptions requires an explicit value telling you where control will return to. https://hackage.haskell.org/package/bluefin https://hackage.haskell.org/package/bluefin

pepa65 1y ago

For the Bitshifters author: could you do a review of the V language as well?

hmac1282 1y ago
Yes.
hmac1282 1y ago
It is here: https://bitshifters.cc/2025/05/17/vlang.html https://bitshifters.cc/2025/05/17/vlang.html

hmac1282 1y ago

The full list of articles: Jai: https://bitshifters.cc/2025/04/28/jai.html https://bitshifters.cc/2025/04/28/jai.html Odin: https://bitshifters.cc/2025/05/04/odin.html https://bitshifters.cc/2025/05/04/odin.html Zig: https://bitshifters.cc/2025/05/04/zig.html https://bitshifters.cc/2025/05/04/zig.html V: https://bitshifters.cc/2025/05/17/vlang.html https://bitshifters.cc/2025/05/17/vlang.html C3: https://bitshifters.cc/2025/05/22/c3-c-tradition.html https://bitshifters.cc/2025/05/22/c3-c-tradition.html