[HN Gopher] Systems Programming with Zig
___________________________________________________________________
Systems Programming with Zig
Author : signa11
Score : 152 points
Date : 2025-10-01 10:51 UTC (3 days ago)
(HTM) web link (www.manning.com)
(TXT) w3m dump (www.manning.com)
| gabrielgio wrote:
| As a developer interested in zig it is nice to see books being
| release, but I'd be a bit resitant to buy anything before zig
| reaches 1.0 or at least when they settle on a stable api. Both
| the builder and the std keep changing. Just 0.15 is a huge
| breakage. Does anyone knows how those changes would affect this
| book?
| turtleyacht wrote:
| Author links to 0.15.1 Zig docs in several places, at least for
| now.
|
| Outstanding issue on Zig side for 1.0 release:
| https://github.com/ziglang/zig/issues/16270
| zwnow wrote:
| With how its going I feel Zig 1.0 wont be a thing until my
| retirement in 37 years
| testdelacc1 wrote:
| I'm willing to bet $5 it happens in 4 years or fewer.
| ebri wrote:
| That's a pretty low confidence if we measure confidence in
| dollars willing to risk
| testdelacc1 wrote:
| It's 100% of my annual betting budget though!
| tialaramex wrote:
| Do you have a history we can look at to see how good you
| are at predicting this for programming languages? Like say,
| some 2020 predictions you had for languages which would or
| would not ship 1.0 by 2025 ?
| testdelacc1 wrote:
| I made a set of predictions for Rust in 2022, nearly all
| of which turned out to be correct. And I was publicly
| confident Go and Rust would be massive when they reached
| 1.0. I was right on both counts.
|
| But I will also admit I don't follow developments in zig
| as closely as Rust. I've never written any Zig. And in
| any case, past performance isn't indicative of future
| performance.
|
| I could be wrong about this prediction, but I don't think
| I will be. From what I've seen Andy Kelley is a
| perfectionist who could work on point releases forever.
| But his biggest users (tigerbeetle and bun especially)
| will only be taken seriously once Zig is 1.0. They'll
| nudge him towards 1.0. They can wait a few years, but not
| forever. That's why I guessed 4 years.
| jorangreef wrote:
| > But his biggest users (tigerbeetle and bun especially)
| will only be taken seriously once Zig is 1.0.
|
| TB is only 5 years old but already migrating some of the
| largest brokerages, exchanges and wealth managements in
| their respective jurisdictions.
|
| Zig's quality for us here holds up under some pretty
| extreme fuzzing (a fleet of 1000 dedicated CPU cores),
| Deterministic Simulation Testing and Jepsen auditing (TB
| did 4x the typical audit engagement duration), and is
| orthogonal to 1.0 backwards compatibility.
|
| Zig version upgrades for our team are no big deal,
| compared to the difficulty of the consensus and local
| storage engine challenges we work on, and we vendor most
| of our std lib usage in stdx.
|
| > They'll nudge him towards 1.0.
|
| On the contrary, we want Andrew to take his time and get
| it right on the big decisions, because the half life of
| these projects can be decades.
|
| We're in no rush. For example, TigerBeetle is designed to
| power the next 30 years of transaction processing and
| Zig's trajectory here is what's important.
|
| That said, Zig and Zig's toolchain today, is already
| better, at least for our purposes, than anything else we
| considered using.
| noshitsherlock wrote:
| Wouldn't you think AI advances in 4 years would make this a
| safe bet?
| therein wrote:
| No, unless you're riding the hype train so hard that you
| are excited to go to colonize Mars thanks to AI advances.
| Rochus wrote:
| Is this really the first Zig book since the development startet
| in 2016? Maybe the language and library is just too volatile
| for a book.
| wslh wrote:
| Or it evolves smoothly at another pace.
| osigurdson wrote:
| People are doing real companies with Zig (e.g. Tiger Beetle)
| and important projects (e.g. Ghostty) without the 1.0 backward
| compatibility guarantee. Zig must be doing something right.
| Maybe this also keeps opinionated 9-5er, enterprise type devs
| out of it as well which might be a good thing :).
| Rochus wrote:
| Are there other notable commercial companies/projects than
| Tiger Beetle relying on Zig? According to public information,
| Tiger Beetle are about eight employees with a single
| customer, isn't it?
| jakogut wrote:
| Bun.sh uses zig for large portions of native code.
| Rochus wrote:
| Thanks for the hint. According to public sources, Bun's
| runtime infrastructure and bindings are written in Zig,
| but it uses Apple's JavaScriptCore engine written in C++
| (i.e. Zig is essentially used in a thin wrapper layer
| around a large C++ engine). Bun itself apparently
| struggles with stability and production readiness. Oven
| (Bun's company) has around 2-10 employees according to
| LinkedIn.
| epolanski wrote:
| Been using bun from years, it's as stable as alternatives
| from a long time.
| throwawaymaths wrote:
| lightpanda and bun
| Rochus wrote:
| Lightpanda looks interesting, thanks for the hint.
| According to public sources, behind the development is a
| company of 2-10 employees (like Bun). The engine uses
| parts of the Netsurf browser (written in C) and the V8
| engine (written in C++), and - as far a I can tell - is
| in an early development stage.
| katiehallett wrote:
| https://news.ycombinator.com/item?id=42817439
| Rochus wrote:
| > _The main idea is to avoid any graphical rendering and
| just work with data manipulation_
|
| Which makes the engine much smaller and less complex than
| a "normal" browser.
| hawk_ wrote:
| Who is that single customer? I'd have thought by now there
| would be more.
| wolvesechoes wrote:
| I guess almost every single language out there have at least
| one "real" company using it, so yeah, Zig is still mostly
| hype and blog post praising its awesomeness.
| hu3 wrote:
| I disagree, since there's Bun also to exemplify real,
| popular, tools are being created.
|
| https://bun.com
| justinhj wrote:
| As a Zig adopter I was rooting for this because even though
| there is the official documentation and some great community
| content, it's nice to just kick back and read a well written
| book. I'm also very happy with other Manning titles; they have
| built a high level of trust with me.
|
| To answer your question is it too early. My expectation is that
| the core language, being quite small by design, will not change
| that much before 1.0. Some things will, especially async
| support.
|
| What I think we will see is something like a comprehensive book
| on C++14 . The language is not much changed between now and
| then, but there will be new sections to add and some sections
| to rework with changes to the interface. The book would still
| be useful today.
|
| Not a perfect analogy because C++ maintains backwards
| compatibility but I think it is close.
| Ygg2 wrote:
| What is the point of this book this early? Zig is in too much
| flux. Language is 0.x for a reason.
|
| Just to gauge interest?
| adamors wrote:
| Well the MEAP just started, 3 chapters are complete and the
| rest will follow probably next year.
|
| IMO it's a bet: Zig stays stable enough and this will be _the_
| Zig book for a while. Should the bet not pay off it still
| cements the author as an authority on the language and gets
| them a foot in the door.
| mi_lk wrote:
| Looks like a win-win for the author? Why would the publisher
| take the bet
| bombcar wrote:
| Manning does this all the time, I presume the cost-to-print
| is so low it doesn't hurt.
| dom96 wrote:
| When I wrote Nim in Action[1] for Manning, it was prior
| to 1.0 as well. It was definitely a bit akward, but
| breaking changes to the stuff covered in the book was
| relatively minor.
|
| 1 - https://book.picheta.me/
| mtlynch wrote:
| Manning doesn't pay that much to first time authors, and it
| looks like it's the first book for the author, Garrison
| Hinson-Hasty.
|
| My guess is it's about $2k upfront and the author owes it
| back if they don't deliver.
|
| Teiva Harsanyi did a good writeup recently about working
| with Manning as a first-time author. He got $2k upfront and
| $2k after delivering the first 1/3rd.[0]
|
| [0] https://www.thecoder.cafe/p/100-go-mistakes
| rtfeldman wrote:
| When I wrote Elm in Action for Manning, I talked with
| them explicitly about the language being pre-1.0 and what
| would happen if there were breaking changes. The short
| answer was that it was something they dealt with all the
| time; if there were small changes, we could issue errata
| online, and if there were sufficiently large changes, we
| could do a second edition.
|
| I did get an advance but I don't remember a clause about
| having to return any of it if I didn't earn it out. (I
| did earn it out, but I don't remember any expectation
| that I'd have to give them money back if I hadn't.) Also
| my memory was that it was more than $2k but it was about
| 10 years ago so I might be misremembering!
| cultofmetatron wrote:
| I bought a copy through my subscription.
|
| having read through a few of their books, Manning has a
| pretty good record of producing a lot of good content.
| nostarch an pragprog are arguably better in terms of
| writing quality (slightly) but they dont' publish nearly as
| many books.
|
| Pakt certainly has more books but the quality is absolute
| garbage.
|
| whenever a new language comes out, I usually take a weekend
| to at least dabble in it to see if its worth getting into.
| Most of the languages end up in my "cool story" bucket but
| its also how I found elixir and I've been working in it
| fulltime for the last 7 years every since.
|
| In the case of manning, they presell the pdf. that costs
| them nothing while expanding their catalog in a way that
| doesnt feel like a ripoff for the subscribers. I'm not
| expecting a MEAP title to have the same level of polish as
| a completed book. Rather, I appreciate having close to
| bleeding age info thats been somewhat curated for my
| consumption.
| ozgrakkurt wrote:
| Language doesn't really change that much, it is mainly stdlib
| and build apis changing
| sparky4pro wrote:
| Garrison Hinson-Hasty is writing a book about a programming
| language that is still in flux seems a little bit... hasty.
| Sorry, couldn't resist...
| epolanski wrote:
| Selling a system programming book to the thousands of people
| interested in system programming with zig.
| bjackman wrote:
| Not a comment on the book but I hope a slightly off topic thread
| is OK...
|
| As a systems programmer, what is the selling point of Zig? For
| me, memory safety is the number 1, 2, 3, 4 and 5 problem with C.
| A new language that doesn't solve those problems seems very
| strange to me. And as a counterpoint, I will tolerate massive
| number of issues with Rust because it gives us memory safety.
|
| I work in security so that may give me a bias. But maybe instead
| of "bias" it's more like awareness. If you don't deal with it day
| in, day out, it seems impossible to really internalise how
| completely fucking broken something like the Linux kernel is.
| Continuing to write e.g. driver code in an unsafe language is
| just not acceptable for our civilisation.
|
| But, also maybe you don't need full complete memory safety, if a
| language has well designed abstractions maybe it can just be
| "safe enough in practice". I've worked on C++ code that feels
| that way. Is this the deal with Zig?
| pron wrote:
| 1. Lack of memory safety is a big problem particularly because
| it's a common cause of dangerous vulnerabilities, but spatial
| safety is more important than temporal safety for that reason,
| and Zig does offer spatial safety.
|
| 2. Other important issues of concern when it comes to
| security/correctness are language complexity and compilation
| speed. A complicated language with lots of implicitness can
| obscure bugs and make reviews slower. Slow compilation reduces
| the iteration speed and harms testing. Zig focuses on these
| two. The language is simple, with no implicitness - overloading
| of any kind is not allowed and neither are any kind of hidden
| calls. Even if security were the only concern, it's not clear
| at all how much complexity and compilation speed should be
| sacrificed for temporal safety. Remember that it's easy to
| classify bugs by technical causes, but more diffuse aspects,
| like testing and review, are also very important, and Zig tries
| to find a good balance.
|
| 3. Nevertheless, the language is still very expressive [1]. In
| any language, you want the algorithm to be clear and with
| neither extraneous nor important hidden details for that
| domain. I think Zig gets that about right for low-level
| programming (and C++ doesn't).
|
| For me, the #1 problem with C is lack of safety and the #2
| problem is lack of expressivity. With C++, the main problem for
| me is language complexity and implicitness, with slow
| compilation and lack of safety tied for number 2. So Zig is as
| expressive as C++. but not only safer, but also much simpler,
| and compiles faster (and improving compilation speed further is
| an important goal).
|
| [1]: I say that two languages are equally expressive if, over
| all algorithms, idiomatic implementations in both languages
| (that are roughly equally clear) differ in length by no more
| than a linear relation with a small constant.
| mi_lk wrote:
| Can you say more about spatial security v.s. temporal
| security and how Zig does them?
| pron wrote:
| Spatial memory safety means that a language (at least in
| its subset that's designated "safe") doesn't allow you to
| manufacture pointers into memory that may contain data of a
| different type than what's expected by the pointer (we'll
| call such pointers "invalid"). The classic examples of
| spatial memory safety is guaranteeing that arrays are never
| accessed out of bounds (hence "spatial", as in pointers are
| safely constrained in the address space). Zig guarantees
| (except when using delineated "unsafe" code) such spatial
| safety.
|
| Temporal memory safety is the guarantee that you never
| access pointers that have been valid at some point in time
| after they've become invalid due to reallocation of memory;
| we call such pointers "dangling" (hence "temporal", as in
| pointers are safely constrained in time). The classic
| example of this is use-after-free. Zig does not guarantee
| temporal safety, and you can accidentally have a dangling
| pointer (i.e. access a one-time valid pointer after it's
| become invalid).
|
| Invalid pointers are especially dangerous because, in
| languages where they can occur, they've been a very common
| source of exploitable security vulnerabilities. However,
| violating spatial memory bounds is more dangerous, as the
| result is more easily exploited by attackers in the case of
| a vulnerability, as it's more predictable.
| pRusya wrote:
| > So Zig is as expressive as C++. but not only safer, but
| also much simpler, and compiles faster
|
| Tbh syntax-wise Zig feels more cryptic[1] at first than C++.
|
| [1] e.g. `extern "user32" fn MessageBoxA(?win.HWND,
| [*:0]const u8, [*:0]const u8, u32) callconv(win.WINAPI) i32;`
| from https://ziglang.org/learn/samples/
| pron wrote:
| I think that's just a matter of syntax habits, presumably
| because you're already familiar with C++ syntax. The syntax
| in your example is especially "cryptic" simply because it's
| an FFI signature (of a function that's not written in Zig
| and doesn't use the normal Zig data representations).
| tredre3 wrote:
| To be clear the equivalent C++ code is:
| #include <windows.h> extern "C"
| __declspec(dllimport) int __stdcall MessageBoxA(HWND,
| LPCSTR, LPCSTR, UINT); // or extern "C"
| __declspec(dllimport) int __stdcall MessageBoxA(void *,
| const char[], const char[], unsigned int);
|
| It's not exactly a stellar improvement.
| npalli wrote:
| Lol, no this is the equivalent #include
| <windows.h> int main() {
| MessageBoxA(NULL, "world!", "Hello", 0); return
| 0; }
| hansvm wrote:
| You touched on the idea in your last paragraph. Comparing Zig
| to C using memory safety as a binary threshold instead of a
| continuous scale is apples to oranges.
|
| For one, Rust isn't even at the far right of the memory safety
| scale, so any argument against Zig due to some epsilon of
| safety has to reckon with the epsilon Rust is missing as well.
| That scale exists, and in choosing a language we're choosing
| (among other things) where on that scale we want to be. Maybe
| Rust is "good enough", and maybe not.
|
| For two, there's a lot more to software design than memory
| safety _even when your goals revolve around the safety and
| stability of the end product_.
|
| So long as you get the basics right (like how Zig uses slices
| by default and has defer/errdefer statements), you won't have
| an RCE from a memory safety bug, or at least not one that you
| wouldn't likely see in Rust anyway (e.g., suppose you're
| writing a new data structure in both languages; suppose that it
| involves back-references or something else where the common
| pattern in Rust would involve creating backing memory and
| passing indices around, combined with an unsafe block on the
| actual cell access to satisfy the borrow checker; the fact that
| you had to do something in an unsafe block opens you up to
| safety issues like index wraparound causing OOB reads).
|
| If memory safety is "good enough" from an RCE perspective, what
| are we buying with the rest of Rust's memory safety? Why is it
| so important? For everything else, you're just preventing
| normal application bugs -- leaking user data, incorrect
| computations, random crashes, etc. The importance of normal
| application bugs varies from project to project, but in the
| context of systems programming of any kind I'll argue that
| these are absolutely as critical as RCEs and the other "big"
| things you're trying to prevent via memory safety. The whole
| reason you try to prevent an RCE is to ensure that you have
| access to your files/data/tools and that an attacker doesn't,
| but if logic bugs corrupt data, crash your tools, and leak PII
| then you're still fucked. Memory safety didn't save you.
|
| That shift in perspective is important. If our goal is
| preventing ordinary application bugs on top of memory-safety
| bugs it becomes blatantly obvious that you'd be willing to
| trade a little safety for some bug prevention.
|
| Does Zig actually help reduce bugs though? IME, yes. The big
| thing it has going for it is that it's a small, cohesive
| language that gives you the power you need to do the things
| you're trying to do. Being small makes it possible to create
| features that compose well and are correct by default, and
| having the power to do what you're trying to do means you don't
| have to create convoluted (expensive, bug-prone) workarounds.
| Some examples:
|
| 1. `let` rebindings in Rust are a great feature, and I like
| them a lot. Better than 90% of the time I use them correctly.
| The other 10% I'm instead trying to create a new variable and
| accidentally shadowing an existing one. That's often not the
| end of the world, but if there exists any code after my `let`
| rebinding expecting the old value then it's totally incorrect
| (assuming compatible types so that you don't have a compilation
| failure). Zig yells loudly about the error.
|
| 2. The error-handling system in Zig is easy to get right
| because of largely compatible return types. By contrast, I see
| an awful lot of `unwrap` in Rust code in places that really
| shouldn't have it, and in codebases that try to use `?` or
| other more-likely-to-be-correct strategies the largely
| incompatible return types force most people into slapping
| `anyhow` around everything and calling it a day.
|
| 3. Going back to error-handling, Rust allows intentional
| discards of return values, but if you start by discarding the
| return value of a non-error function and the signature is later
| updated to potentially return errors Rust still lets you
| discard the value. Zig forces you to do something explicitly
| acknowledging that there was an error. 100% of the time the
| compiler has yelled at me for a potential logic bug it was
| correct to do so.
|
| It really is just a bunch of little things, but those little
| things add up and make for a pleasant language with shockingly
| few bugs. Maybe my team is just even more exceptional than I
| already think or something and I'm over-indexing on the
| language, but in the last couple years I haven't seen a single
| memory safety issue, or much in the way of other bugs in the
| Zig part of the company.
| throwawaymaths wrote:
| the far right of the security scale is C (+ isabelle?) again
| (seL4)
| tialaramex wrote:
| 1. I guess by "let rebinding" you mean shadowing. Clippy has
| lints for shadowing which are default off, you might find
| that some patterns of shadowing which are legal in Rust are
| too often problematic in your software and so you should tell
| Clippy to warn you about them or even deny them by default.
|
| For example you might decide to warn for
| clippy::shadow_unrelated which says if I have a variable
| named "goose" and then later in the function I just make
| another variable that's not obviously derived from the first
| variable but it is called "goose" anyway, warn me I did that.
|
| 2. I don't see any advantage of "largely compatible" error
| handling over anyhow, maybe you could be more explicit about
| what you want here or give an example.
|
| 3. What you're claiming for Zig here is a semantic check.
| This could exist but be fallible (it can't be infallible
| because Rice's Theorem), but I suspect the reality is that
| it's not a semantic check and you've misattributed your
| experience since I don't see any such check in Zig. Maybe an
| example would clarify.
| hansvm wrote:
| I really didn't mean to make this about Zig vs Rust. That
| was a mistake. My real point is that Zig is also a great
| language, even when you care about safety.
|
| That said, the things you asked about:
|
| 1. I suppose you might get away with linting all of
| shadow_reuse, shadow_same, and shadow_unrelated. Would that
| sufficiently disable the feature?
|
| 2. The biggest problems with overusing `anyhow` to
| circumvent the language's error system are performance and
| type safety. Perf is probably fine enough for most
| applications (though, we _are_ talking about systems
| programming, and this is yet another way in which
| allocation-free Rust is hard to actually do), but not being
| able to match on the returned error makes appropriately
| handling errors clunkier than it should be, leading to devs
| instead bubbling things up the call stack even more than
| normal or "handling" the error by ignoring any context and
| using some cudgel like killing connections regardless of
| what the underlying error was.
|
| 3. Rice's Theorem is only tangentially related. Your goal,
| and one that Rust also strives for, is to make it so that
| changes to the type signature of a function require
| compatible changes at call sites, which you can often
| handle syntactically. Rust allows `let _ = foo()` to also
| silence errors, and where Zig normally allows `_ = foo()`
| to silence unhandled return values it additionally requires
| `try`, `catch`, or `return` (or similar control flow). You
| have options like `_ = foo() catch {}` or `_ = foo() catch
| @panic("WTF")` if you really do want to silence the error,
| but you'll never be caught off-guard by an error being
| added to a function's return type.
| ptrwis wrote:
| Maybe in the future, if the language has very good AI support,
| security guarantees of the language won't be as important, as
| it (ai) will find potential bugs well enough. This may be the
| case with Zig, as the language is simple and consistent, and
| the lack of macros will make it easier for LLMs to understand
| the code.
| bigstrat2003 wrote:
| AI is not remotely capable enough to be trusted with that.
| Perhaps in the future it will be, but I'm not betting on it
| with the lack of improvement we have seen thus far.
| throwawaymaths wrote:
| 1. you get spatial memory safety which iirc is more common for
| security problems than temporal.
|
| 2. honestly for high performance applications you might reach
| for an ECS type system anyways (i think dom engines do this) at
| which point you would be getting around the borrow checker
| anyways.
| picafrost wrote:
| Excellent way to stay busy producing revised editions over the
| next few years.
|
| I really enjoy writing Zig and I think it's going to be an
| important language in the future. I do not enjoy porting my code
| between versions of the language. But early adopters are
| important for exploring the problem space, and I would have loved
| to find a canonical source (aside from the docs, which are mostly
| nice) for learning the language when I did. A text that evolves
| with the language has a better chance of becoming that canonical
| onboarding source.
| techjuice wrote:
| I think this is great, gives those wanting a good formal
| foundation a guide to getting organized and making something
| happen.
|
| With time this is also going to be great for the author with new
| iterations of the book, but getting in early like this can set
| the author and the language up for success long term.
| materiallie wrote:
| Zig certainly has a lot of interesting features and good ideas,
| but I honestly don't see the point of starting a major project
| with it. With alternatives like Rust and Swift, memory safety is
| simply table stakes these days.
|
| Yes, I know Zig does a lot of things to help the programmer avoid
| mistakes. But the last time I looked, it was still _possible_ to
| make mistakes.
|
| The only time I would pick something like C, C++, or Rust is if I
| am planning to build a multi-million line, performance sensitive
| project. In which case, I want total memory safety. For most
| "good enough" use cases, garbage collectors work fine and I
| wouldn't bother with a system's programming language at all.
|
| That leaves me a little bit confused about the value proposition
| of Zig. I suppose it's a "better C". But like I said, for serious
| industry projects starting in 2025, memory safety is just
| tablestakes these days.
|
| This isn't meant to be a criticism of Zig or all of the hard work
| put into the language. I'm all for interesting projects. And
| certainly there are a lot of interesting ideas in Zig. I'm just
| not going to use them until they're present in a memory safe
| language.
|
| I am actually a bit surprised by the popularity of Zig on this
| website, given the strong dislike towards Go. From my
| perspective, both languages are very similar, from the
| perspective that they decided to "unsolve already solved
| problems". Meaning, we _know_ how to guarantee memory safety.
| Multiple programming languages have implemented this in a variety
| of ways. Why would I use a new language that takes a problem a
| language like Rust, Java, or Swift already solved for me, and
| takes away features (memory safety) that I already have?
| winrid wrote:
| Zig has a pretty great type system, and sometimes languages
| like Rust and C++ are not great with preventing accidental heap
| allocations. Zig and C make this very explicit, and it's great
| to be able to handle allocation failures in robust software.
| pjmlp wrote:
| That is the usual fallacy, because it assumes everyone has
| full access to whole source code and is tracking down all the
| places where heap is being used.
|
| It also assumes that the OS doesn't lie to the application
| when allocations fail.
| simjnd wrote:
| Zig make allocations extremely explicit (even more than C)
| by having you pass around the allocator to every function
| that allocates to the heap. Even third-party libraries will
| only use the allocator you provide them. It's not a
| fallacy, you're in total control.
| pjmlp wrote:
| Why, are you going to abort if too many calls to the
| allocator take place?
| simjnd wrote:
| You can if you want. You can write your own allocator
| that never actually touches the heap and just distributes
| memory from a big chunk on the stack if you want to. The
| point is you have fine grained (per function) control
| over the allocation strategy not only in your codebase
| but also your dependencies.
| pjmlp wrote:
| Allocation strategy isn't the same as knowing exactly
| exactly when allocations take place.
|
| You missed the point that libraries can have their own
| allocators and don't expose customisation points.
| dmytrish wrote:
| > pass around the allocator to every function that
| allocates to the heap.
|
| what prevents a library from taking an allocator, saving
| it hidden somewhere and using it silently?
| renehsz wrote:
| > It also assumes that the OS doesn't lie to the
| application when allocations fail.
|
| Gotta do the good ol' echo 2
| >/proc/sys/vm/overcommit_memory
|
| and maybe adjust overcommit_ratio as well to make sure the
| memory you allocated is actually available.
| pjmlp wrote:
| OS specific hack and unrelated to C.
| tredre3 wrote:
| Your comment was also OS-specific because Windows doesn't
| lie to applications about failed allocations.
| dmytrish wrote:
| What's great about its type system? I find it severely
| limited and not actually useful for conveying and checking
| invariants.
| SvenL wrote:
| Since most system level api provide a C interface and the c
| interoperability of zig is top notch you don't require a
| marshaling/interop layer.
| bigstrat2003 wrote:
| That's true of Rust as well, so it's not really an advantage
| unique to Zig.
| SvenL wrote:
| Is it? Most of the time I read you have to create a
| wrapper, like here: https://docs.rust-
| embedded.org/book/interoperability/c-with-...
|
| Please provide some documentation of how to use c libraries
| without such interop layer in rust. And while bindgen does
| most of the work it can be pretty tedious to get running.
| apwell23 wrote:
| rust has really high learning curve
| osigurdson wrote:
| Perhaps worse is the fatigue curve that some people claim
| sets in after a few years of using it.
| hitekker wrote:
| Do you have links on people's experience with the fatigue
| curve?
|
| I've heard of "hard to learn, easy to forget" but I haven't
| seen people document it for career reasons.
| hu3 wrote:
| I guess lack of job positions could be one kind of
| fatigue curve.
| osigurdson wrote:
| I have no hard data. I have seen comments to this effect
| in HN. Somewhat famously Primagen threw in the towel on
| it. I would love to hear from others with 4+ years of
| Rust experience though.
| dustbunny wrote:
| > memory safety is simply table stakes
|
| Why?
|
| And also, this is black and white thinking, implying that
| "swift and rust" are completely memory "safe" and zig is
| completely "unsafe". It's a spectrum.
|
| The real underlying comparison statement here is far more
| subjective. It's along the lines of: "I find it easier to write
| solid code in rust than in zig". This is a more accurate and
| fair way to state the semantics of what you are saying.
|
| Saying things like "rust is memory safe. Zig is not memory
| safe" is reductionist and too absolutist.
| Barrin92 wrote:
| >Why?
|
| Memory bugs are hard to debug, potentially catastrophic
| (particularly concerning security) and in large systems
| software tend to constitute the majority of issues.[1]
|
| It is true that Rust is not absolutely memory safe and Zig
| provides some more features than C but directionally it is
| correct that Rust (or languages with a similar design
| philosophy) eliminate billion dollar mistakes. And you can
| take that literally rather than metaphorically. We live in a
| world where vulnerable software can take a country's
| infrastructure out.
|
| [1] https://www.zdnet.com/article/microsoft-70-percent-of-
| all-se...
| DarkNova6 wrote:
| If decades of experience shows us anything it is that
| discipline and skill is not enough to achieve memory safety.
|
| Developers simply aren't as good at dealing with these
| problems as they think they are. And even if a few infallible
| individuals would be truly flawless, their co-workers just
| aren't.
| scuff3d wrote:
| I'm not convinced that on average Zig is any less safe, or
| produces software that is any less stable, then Rust.
|
| Zig embraces reality in its design. Allocation exist,
| hardware exists, our entire modern infrastructure is built
| on C. When you start to work directly with those things,
| there is going to be safety issues. That's just how it is.
| Zig tries to give you as many tools as possible to make
| good decisions at every turn, and help you catch mistakes.
| Like it's testing allocator detecting memory leaks.
|
| Rust puts you in a box, where the outside world doesn't
| exist. As long as you play by its rules everything will be
| fine. But it eventually has to deal with this stuff, so it
| has unsafe. I suspect if Rust programmers went digging
| through all their dependencies, especially when they are
| working on low level stuff, they would be surprised by how
| much of it actually exists.
|
| Zig tried to be more safe on average and make developers
| aware if pitfalls. Rust tried to be 100% safe where it can,
| and then not safe at all where it can't. Obviously Rusts
| approach has worked for it, but I don't think that
| invalidates Zigs. Especially when you start to get into
| projects where a lot of unsafe operations are needed.
|
| Zig also has an advantage in that it simplifies memory
| management through its use of allocators. If you read
| Richard Feldman's write up on the Roc compilers rewtire in
| Zig, he talks about how he realized their memory allocation
| patterns were simple enough in Zig that they just didn't
| need the complexity of Rust.
| xwowsersx wrote:
| Genuinely curious because I don't know: when you group Swift
| with Rust here, do you mean in terms of memory safety
| guarantees or in the sense of being used for systems-level
| projects? I've always thought of Swift as having runtime safety
| (via ARC), not the same compile-time model as Rust, and mostly
| confined to Apple platforms.
|
| I'm surprised to see them mentioned alongside each other, but I
| may very well be missing something basic.
| jolux wrote:
| Swift is mostly runtime-enforced now but there are a lot of
| cultural affinities (for lack of a better term) between Swift
| and Rust and there's a proposal to add ownership https://gith
| ub.com/swiftlang/swift/blob/main/docs/OwnershipM...
| pron wrote:
| Yes, we know how to offer memory safety; we just don't know how
| to offer it without exacting a price that, in some situations,
| may not be worth it. Memory safety always has cost.
|
| Rust exists because the cost of safety, offered in other
| languages, is sometimes too high to pay, and likewise, the cost
| Rust exacts for its memory safety is sometimes too high to pay
| (and may even adversely affect correctness).
|
| I completely agree with you that we reach for low-level
| languages like C, C++, Rust, or Zig, in "special" circumstances
| - those that, for various reasons, require precise control over
| hardware resource, and or focuses more on the worst case rather
| than average case - and most software has increasingly been
| written in high-level languages (and there's no reversal in
| this trend). But just as different factors may affect your
| decisions on whether to use a low-level language, different
| factors may affect your decision on which low-level language to
| choose (many of those factors may be subjective, and some are
| extrinsic to the language's design). Of course, if, like the
| vast majority of programmers, you don't do low-level
| programming, then none of these languages are for you.
|
| As a long-time low-level programmer, I can tell you that _all_
| of these low-level languages suffer from very serious problems,
| but they suffer from _different_ problems and require making
| different tradeoffs. Different projects and different people
| may reasonably want different tradeoffs, and just as we don 't
| have one high-level language that all programmers like, we also
| don't have one low-level language that all programmers like.
| However, preferences are not necessarily evenly distributed,
| and so some languages, or language-design approaches, end up
| more popular than others. Which languages or approaches end up
| more popular in the low-level space remains to be seen.
|
| Memory safety is clearly not "table stakes" for new software
| _written in a low level language_ for the simple reason that
| most new software written in low level languages uses languages
| with significantly less memory safety than Zig offers (Zig
| offers spatial memory safety, but not temporal memory safety; C
| and C++ offer neither, and most new low level software written
| in 2025 is written in C or C++).
|
| I can't see a strong similarity between Go, a high-level
| language, and Zig, a low-level language, other than that both -
| each in its own separate domain - values language simplicity.
| Also, I don't see Zig as being "a better C", because Zig is as
| different (or as similar) from C as it is from C++ or Rust,
| albeit on different axes. I find Zig _so_ different from any
| existing language that it 's hard to compare it to anything. As
| far as I know, it is the first "industry language" that's
| designed almost entirely around the concept of partial
| evaluation.
| hawk_ wrote:
| Would you say writing something like a database (storage and
| query engine) from scratch is better done in Rust or Zig?
| pron wrote:
| First, I would avoid using any low-level language if at all
| possible, because no matter what you pick, the maintenance
| and evolution costs are going to be significantly higher
| than for a high-level language. It's a very costly
| commitment, so I'd want to be sure it's worth it. But let's
| suppose I decided that I must use a low-level language
| (perhaps because worst-case behaviour is really important
| or I may want to run in a low-memory device or the DB was a
| "pure overhead" software that aims to minimise memory
| consumption that's needed for a co-located resource heavy
| application).
|
| Then, if this were an actual product that people would
| depend on for a long time, the obvious choice would be C++,
| because of its maturity and good prospects. But say this is
| hypothetical or something more adventurous that allows for
| more risk, then I would say it entirely depends on the
| aesthetic preferences of the team, as neither language has
| some clear intrinsic advantage over the other. Personally,
| I would prefer Zig, because it more closely aligns with my
| subjective aesthetic preferences, but others may like
| different things and prefer Rust. It's just a matter of
| taste.
| osigurdson wrote:
| >> Why would I use a new language...
|
| If you are asking that question you should not use a new
| language. Stick with what works for you. You need to feel that
| something is unsatisfactory with what you are using now in
| order to consider changing.
| jmull wrote:
| To me the argument is that memory errors are just one type of
| logic error that can lead to serious bugs. You want a language
| that reduces logic errors generally, not just memory safety
| ones, and zig's focus on simplicity and being explicit might be
| the way to accomplish that.
|
| For large performant systems, what makes sense to me is memory
| safety by default, with robust, fine-grained levers available
| to opt in to performance over safety (or to achieve both at
| once, where that's possible).
|
| Zig isn't that, but it's at least an open question to me. It
| has some strong safe-by-default constructs yet also has wide
| open safety holes. It does have those fine-grained levers, plus
| simplicity and explicitness, so not that far away. Perhaps
| they'll get there by 1.0?
| DarkNova6 wrote:
| Logical errors and Memory errors aren't even close to being
| in the same ballpark.
|
| Memories errors are deterministic errors with non-
| deterministic consequences. Logical errors are mostly non-
| deterministic (subjective and domain dependent) but with
| deterministic consequences.
| tliltocatl wrote:
| None of all those memory-safe languages allows you to work
| without a heap. And I don't mean "avoid allocations in that
| little critical loop". I mean "no dynamic allocation, never
| ever". A lot of tasks doesn't actually require dynamic
| allocation, for some it's highly undesirable (e. g. embedded
| with limited memory and long uptimes), for some it's not even
| an option (like when you are writing an allocator). Rust has
| some support for zero-runtime, but a lot of it's features is
| either useless of outright in the way when you are not using a
| heap. Swift and others don't even bother.
|
| Unpopular opinion: safety is a red herring. A language
| shouldn't prevent the programmer from doing the unsafe thing,
| rather it should provide an ergonomic way to do things in a
| safe way. If there is no such way - that's on language
| designer, not the programmer. Rust being the worst offender:
| there is still no way to do parent links, other than ECS/"data
| oriented" which, while it has it's advantages, is both quite
| unergonomic and provides memory safety by flaying it, stuffing
| the skin with cow dung and throwing the rest out of the window.
|
| >strong dislike towards Go.
|
| Go unsolves problem without unlocking any new possibilities.
| Zig unsolves problem before it aims towards niches where the
| "solution" doesn't work.
| needlesslygrim wrote:
| > Rust has some support for zero-runtime, but a lot of it's
| features is either useless of outright in the way when you
| are not using a heap.
|
| Could you give some examples?
| sparky4pro wrote:
| Tried to use Swift outside Xcode and it's a pain. Especially
| when writing CLI apps the Swift compiler chocked and says there
| is an error, mentioning no line number. Good luck with that.
| Also the Swift tooling outside Xcode is miserable. Even Rust
| tooling is better than that, and Swift has a multi billion
| dollar company behind it. What a shame...
| scuff3d wrote:
| > ...memory safety is simply table stakes these days.
|
| Is there like a mailing list Rust folks are on where they send
| out talking points every few months? I have never seen a
| community so in sync on how to talk about a language or
| project. Every few months there's some new phrase or talking
| point I see all over the place, often repeated verbatim. This
| is just the most recent one.
___________________________________________________________________
(page generated 2025-10-04 23:00 UTC)