20 ms·

Zig and the design choices within

129 points by lerno 11mo ago

deleted 11mo ago
[deleted]
anupj 11mo ago
[dead]
torben-friis 11mo ago
This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjoy it”, and the language seems to have a couple red flags, so why focus on it? (Honest question).
- munificent 11mo ago
  > for Ruby is ergonomics… My impression is that this is the main thing for Zig too. The intersection of the set of languages that let you write very low-level code where you have full control over memory and allocation and the set of languages that are enjoyable to program in is pretty small. C is in there if you've internalized many of its warts are fine with all of the many many footguns it has. C++ is in there if you much of your enjoyment comes from the machismo of feeling like you have conquered C++'s beastly language complexity. Rust is in there if proving to the compiler that you know what you're doing is satisfying to you. Zig sort of gets out of your way like C does, even when what you're trying to do is potentially harmful. But it's more modern and expressive and doesn't have all of C's historical baggage.
  - torben-friis 11mo ago
    Ok, that makes sense. So it’s a modern take on low level languages, like rust, but for those that dislike c for being cumbersome rather than for being less secure? Is that a stated goal of the language? Other than the feature to gradually move from c++ it wasn’t super clear from the main pitch.
    - munificent 11mo ago
      > for those that dislike c for being cumbersome rather than for being less secure? I wouldn't say "cumbersome", but perhaps "full of warts and historical baggage". They have some more details here: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
- xanthor 11mo ago
  Low abstraction overhead and no ‘big ideas’. It tries to simplify the problem of low-level systems programming by learning from the lessons of the past 50 years.
- mtlynch 11mo ago
  I'm a casual fan of Zig for hobby development, so just as a data point: I find Zig to be a pleasant option for code that requires high performance. I find it strictly dominates C as an option, as Zig outperforms C on every criteria I care about in a language's developer experience. I often see people compare Zig to Rust and complain that Zig doesn't have Rust's safety guarantees. I don't know Rust, but looking at it casually, the language itself seems to have a lot of complexity that doesn't appeal to me, and I'd still prefer Zig to Rust. If I need memory safety, I'd rather write in Go or Python. When I read articles like these, the gotchas they find don't seem that compelling to me. It's always like if you write your code in a deliberately confusing way to confuse the compiler, you can get incorrect results, but I don't care because I would never write code like that.
- xlii 11mo ago
  For me, personally, it is nice because it's bare metal where I want it and not bare metal when I don't. C is very basic and (especially when you stick to something like C99), can be very tedious to write. In C, if I hope for smarter things I need to write them by hand; usually there are no ways of achieving some goals without just crunching out the code. Zig preserves C qualities but also gives some extra tools that are completely optional and makes it less tedious than C. I believe that Zig's popularity is also caused by general tendency of some people. Some prefer to fix a segfault than spend half a day refactoring something that was supposed to be easy but is causing half of the codebase to be rewritten. (Oh, and Zig is also an escape hatch to easy CGo :))
- salamanderman 11mo ago
  I think the post gives an answer to this with "due to Zig's fairly minimalistic nature; it lacks a lot of features that one would otherwise use to solve problems. Of course, this is the appeal for many, but still". I have a lot of C/C++ experience, and they're what I reach for, but I often want C to be a little more like C++, and I often want both to have slightly better memory management, and I've never liked the different syntax for the main language, templates, and pre compiler macros. I also agree with Zig's dogmatic stance on no hidden control flow; I have been bitten by "magic" too many times.
- xeonmc 11mo ago
  Zig for me is “C with namespaces”. Other selling points are just complimentary.
- kristoff_it 11mo ago
  Some people like Zig because it makes it easier to learn how to program the machine sitting in front of them. It's better at that than Rust because it's less abstracted, and it's better at that than C because you don't have to worry all the toolchain nonsense / weird conventions / weak type system of the C ecosystem. As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_handler_rust#c_yjqhxq https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha... I think I don't need to provide references for C. It's a new pathway to mastery that really works well for some people. That in itself is much more valuable than any new specific feature the language has to offer, although the ability of the toolchain to cross-compile reliably not only Zig but also C and C++ code does play into that. And, while not yet 100% there, instant incremental rebuilds also help to achieve faster feedback loops. People like Zig because it's a tool that helps them become better programmers, faster.
  - metaltyphoon 11mo ago
    > As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha... Nitpicking? Let’s show an example on creating an interface in Zig to see all complicated tricks.
  - NobodyNada 11mo ago
    > As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick A bit of a nitpick here: the trick is for creating a new vector of a different type, that reuses the allocation of an existing vector, using only safe code. "Resetting an arraylist/vector while reusing its memory" is just vec.clear() if you're not changing the type. And it's trivial to change the type of a vector with unsafe (the docs even have examples of this); the only advantage of the "trick" is to ensure you'll get a panic if you screw up the alignment of the types. And after that blog post, the Rust team accepted a proposal to introduce a vec.recycle() function to change the type of a vector without needing that trick (and with compile-time checks for alignment compatibility): https://github.com/rust-lang/rust/pull/148416 https://github.com/rust-lang/rust/pull/148416 But that example aside, I agree with your overall premise -- Zig and Rust share different design goals here, and Zig's lower level of abstraction makes it more approachable to learn than a language like Rust.
- tayo42 11mo ago
  With all the hn hype around zig I ended up going through the docs and some example code and felt the same way. I'm not totally sure where this fits into my tool box of languages.
  - pyrolistical 11mo ago
    When I first heard about zig, I sat down and read the entire doc from start to end. It was so refreshing and was an instant fan
    - tayo42 11mo ago
      It doesn't seem bad, (though with some of rewrite of the std library? It doesn't seem quite ready) Im just not sure when I'll reach for it. I guess I'm comfortable enough with rust and both seem like languages that compile with llvm. Maybe if I didn't know rust it would feel like more useful.
- pron 11mo ago
  Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age. I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Rust. If you look at MITRE's top 25 dangerous weaknesses [1] or top 10 exploited weaknesses [2], you'll see that Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 on either list, while Zig's more limited memory safety addresses the more dangerous memory-safety-related problems without paying so dearly to solve less severe issues. Now, I personally think that Zig's combination of expressivity and simplicity, while still being low-level, is an unprecedented killer feature (I wrote more about it here: https://news.ycombinator.com/item?id=45852774 https://news.ycombinator.com/item?id=45852774) which makes the language design quite revolutionary and fascinating. This could perhaps translate to correctness benefits. [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html
  - pizza234 11mo ago
    > Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 in either list Uh? Number 2 in CWE is an out-of-bounds write, and the same vulnerability is number 1 in the KEV list.
    - pron 11mo ago
      That falls into "spatial" memory safety, which Zig also provides. Rust's ownership and lifetime - the core of its design - go into eliminating use-after-free, aka "temporal" memory safety.
  - grogers 11mo ago
    Use after free is number 8 and 9 on the lists respectively... Not like it's way down the list. And most of the things the things above it (other than out of bounds writes/reads which you addressed in another comment) are not something I would consider a programming language can directly affect (e.g. SQL injection, CSRF)
- cassepipe 11mo ago
  A lot of people strive for something that is simple (not like Rust, and I am not only talking about the borrow checker) and explicit ("debug your program, not your knowledge of the language) but also doesn't bear the historical cruft and idiosyncrasies of C. The fact that it can integrate with C code means that if you are already using C you can adopt it incrementally, plus it works as a build system and cross-compiler and I believe a package manager too. So to sum up : A powerful C without the quirks that manages to keep things simple but is also a batteries-included experience with a smooth adoption path. What's not to love ?
- raincole 11mo ago
  > for Ruby is ergonomics… In other words, "I kinda enjoy it"?
- JuniperMesos 11mo ago
  It's doing something novel in the systems programming space, and makes a bunch of different trade-offs compared to Rust. That's interesting, even if you might reasonably conclude that Rust is still a better language to use in most cases. It's good to explore different corners of the programming language design space. Every single commonly-used programming language has a couple red flags, often much more than a couple. Javascript, C, C++, Go, Python - these languages all have serious flaws and are nonetheless used by extremely large numbers of people for all sorts of tasks.
kiitos 11mo ago
probably should define memory safety before using it as an evaluation criterion otherwise, not sure who the audience of this piece is supposed to be, but it's written in a pretty combative tone, which will not be persuasive to anyone who isn't already persuaded, so i guess more of a rant than anything worth sharing here
- jasperry 11mo ago
  Someone could know what memory safety is and still be persuaded (or reminded) by an argument that it's not okay to adopt a non-memory-safe language due to all the security issues. The author did cite evidence from the Chromium project, which to me elevates it above a mere rant.
  - kiitos 11mo ago
    my point with memory safety is that it is not a single well defined concept so if you wanna talk about it you at least gotta say which definition you're using
- nightpool 11mo ago
  I can see where you're coming from, but I do think there's a fair amount of meat here. I've never used Zig, but I initially thought of it as pretty similar to other modern languages like Go and Rust, and I liked their allocator approach, but the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. I used Bun for a small data-collection project, and I liked its performance, but I ran into a lot of issues with it segfaulting (even when just passing a command line argument that was added in the most recent version!). I think that does a good job of motivating OP's argument and how Zig's language semantics directly contribute to these issues.
  - bsder 11mo ago
    > the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. That's because Zig defers a bunch of checks to runtime that Rust will force you to deal with before it will let you compile at all. That is a tradeoff. Developer velocity vs memory safety. Given that Bun seems to be beating Deno on most metrics, it seems like that was the correct choice for Bun.
anp 11mo ago
I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’d be more persuaded on the reliability point if it were comparing the “crash density” of bug reports at comparable points in those project’s lifetimes. For example, it would be interesting to compare how many Rust bugs mentioned crashes back when there were only 13k bugs reported, and the same for the JS VM comparison. Don’t get me wrong, as a Rust zealot I have my biases and still expect a memory safe implementation to be less crashy, but I’d be much happier concluding that based on stronger data and analysis.
- kennykartman 11mo ago
  I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...
  - williamstein 11mo ago
    bun has 10x the issues matching "segfault" as deno - deno 44: https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/denoland/deno/issues?q=is%3Aissue%20state... - bun 464: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
  - cb22 11mo ago
    > I'd like to see the same stats for tigerbeetle Actual SIGSEGVs are pretty rare, even during development. There was a pretty interesting one that affected our fuzzing infra a little bit ago: https://ziggit.dev/t/stack-probe-puzzle/10291 https://ziggit.dev/t/stack-probe-puzzle/10291 Almost all of the time we hit either asserts or panics or other things which trigger core dumps intentionally!
pyrolistical 11mo ago
The authors section on comptime makes me believe they have not used zig anything non trivial. I don’t think comptime as just some macro system. It is closer to a reflection system. I use comptime to access types. You can create specialized paths depending on type. Also imo generics are “first class” in zig. Comptime is first class and thus generics are too.
- refulgentis 11mo ago
  > X is first class and thus Y [implemented in terms of X] is too. Is everything first class, then?
  - pyrolistical 11mo ago
    I would argue C preprocessor macros are not first class. They are optional. This anything implements with macros are not first class
  - mirekrusin 11mo ago
    In theory it can encode 0 and 1 so anything really, right?
taylorallred 11mo ago
I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probably leads to better software because nothing is "hidden". But, I also think that there's a level of abstraction/indirection that makes code clearer and less error-prone. It's a tricky balance to achieve, and past languages have succeeded and failed at it to different degrees. Either way, I echo the OP's sentiment: if Zig is your jam, great, go make some awesome stuff with it. It's just not my go-to today.
- pron 11mo ago
  Design choices that are appropriate for low-level programming may be less appropriate for high-level programming and vice versa. In low level programming, you may want to see "on the page" anything that could translate to some machine work, because in low-level programming, such details may be essential to the algorithm. In high-level programming, the same details are likely not essential to the algorithm, and so you don't want to see them.
- kstenerud 11mo ago
  It really comes down to a matter of opinion where the line between "nothing hidden" and convenience lies. Technically, a loop is an abstraction of convenience that hides the comparative jump underneath.
- ksec 11mo ago
  I think, but I may be wrong, Zig wants to be high level assembly that could replace C. If people are viewing it from Python, Ruby, JS, and then C++ and Java POV, Zig may be a little too "raw". But then I don't think Zig intends to compete with C++ or Java. May be there will be a Zig ++ or Objective-Zig someday that will do that.
ivanjermakov 11mo ago
> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawbacks, but code generation is still a thing. > Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.
- brabel 11mo ago
  > Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And those mistakes can have catastrophic consequences. Professionals should go for tools that help them prevent those mistakes, right??
  - ModernMech 11mo ago
    > But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. That's true but it's deeper than that -- no matter how much time goes by, there will always be people new to the language, and they will always make newbie mistakes if the language allows them to. So "just be an expert and don't write shoddy code" doesn't scale, no matter how hard you personally try.
    - refulgentis 11mo ago
      It's deeper to note people who know nothing will make the mistake, than "I, an expert, will make the mistake"? :)
Demiurge 11mo ago
Why have I been seeing a Zig post every day for the past week? Is there some kind of a marketing push?
- zenlot 11mo ago
  What about more people using it? More than anything this looks to be natural evolution of language.
- Zambyte 11mo ago
  Interest on various topics comes in waves on HN. This week it's Zig, next week it's Scheme, the week after is Erlang, etc. Nothing out of the ordinary.
  - Klonoar 11mo ago
    Programming languages in general go through hype waves here; back in the mid 2000s it was some combination of Lisp -> Ruby -> JS with bits of Erlang in and around those.
- 0x1ch 11mo ago
  I think there's a small trend upwards for Zig & Nim right now. I've seen a few different front page posts for them in the last couple weeks. It at least convinced me to clone ziglings and get a feel for it this last weekend.
- refulgentis 11mo ago
  There's bursts of them and every 3-6 months I see one like this, more practical, and remember I don't need to read the others. Then I forget in 3 months. Rinse, lather, repeat. (to this 16 year veteran of HN, it reminds of early 2010s Haskell)
- tapirl 11mo ago
  still less than Rust posts.
- bargainbin 11mo ago
  Advent of code is coming, maybe lots of people looking for a language to learn with it?
Joker_vD 11mo ago
> Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while loop, and you'll enjoy it. INCR[U] i FROM 0 TO len(arr) [BY 1] DO ... DECR[U] i FROM len(arr) TO 0 [BY 1] DO ... Although actual BLISS-77 had inclusive semantics for the upper bounds in both forms. Which, on one hand, allows you to write DECRU i FROM UINT_MAX TO 0 DO ... and expect it to Just Work™ (hopefully? No idea if it worked on actual implementation ― but would've been nice, writing the same in e.g. C is kinda annoying; good luck with Golang pre-1.22 and even then, getting that one last iteration is quirky) but on the other hand, inclusive upper bounds require you to write add that "-1" almost everywhere.
- brabel 11mo ago
  That looks a lot like Common Lisp LOOP macro!
  - Joker_vD 11mo ago
    Honestly, that's been the standard form of FOR loops since Fortran and Algol-60 until C decided to spice things up.
    - brabel 11mo ago
      That may be, but I was born only 40-something years ago, so I haven't had the pleasure to see that other than in Lisp.
deepriverfish 11mo ago
It's interesting to see how popular Zig is becoming, I thought it would get overshadowed by Rust and it would go nowhere.
- guywithahat 11mo ago
  It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle
  - pizza234 11mo ago
    > Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle It is correct that the hype is past its peak, however, the TIOBE trend (if one wants to use that) is actually steadily increasing. > There is still some development in linux "Some development" is a miscarachterization - the official addition to the Linux kernel itself is a very big deal, and its adoption is increasing and will continue to do so. I think that Rust has found its niche in safe low-level programming, and it will slowly have an increasingly dominant role in (although the ceiling of this area is certainly limited in the global landscape).
    - api 11mo ago
      Rust has been adopted by Microsoft, Amazon, etc. It's past the hype phase and well into the "languages people use for work and complain about" phase. I still like it -- for systems programming, that is. It's a much better C++ basically.
      - mwcampbell 11mo ago
        > I still like it -- for systems programming, that is. Just curious, what language(s) do you prefer for things that you don't classify as "systems programming"?
pron 11mo ago
This treatment of memory safety is becoming almost a cargo cult at this point. If this were a binary issue, then clearly Rust wouldn't cut it because it is quite common in Rust (much more so than in, say, Java) to rely on unsafe code. So if you think Rust is good at memory safety, that means that you must believe that some level of unsafety is acceptable. The only question is how much, and what you're willing to pay to reduce it. The reason we care about memory-safety so much, compared to other invariants we'd like our programs to have is because, as the article notes, a very high portion of vulnerabilities are due to memory-safety violations. This is why preventing or reducing such violations is important in the first place. But if we look at vulnerability rankings [1][2], we see that Zig's memory safety covers the top weaknesses just as well as Rust, and much better than C. The vast difference in the complexity of these two languages is because Rust pays a lot to also prevent less dangerous vulnerabilities, outside the top 5. So if Rust is good because it eliminates some very common dangerous vulnerabilities thanks to its memory safety, then Zig must also be good for eliminating the same ones. Calling it C-like because it doesn't eliminate some less common/dangerous vulnerabilities just because Rust does, is just a misunderstanding of why this is all important in the first place. (Plus, if it's important to reduce the security vulnerabilities due to memory safety violations, isn't it better to make avoiding the worst outcomes more approachable?) In software correctness there are few easy choices. Everything boils down to how much you can and should pay to improve your confidence that a certain level of damage won't occur. It's a complicated subject, and trying to present it as a simple one does it a great disservice. In fact, both Rust and Zig address some of the most common/dangerous vulnerabilities — more than use-after-free - just as well as C, which is to say, not, or barely, at all. I.e. there are worse vulnerabilities that neither one of them eliminates than the ones Rust eliminates and Zig doesn't. There is no doubt that Rust and Zig are meant to appeal to people with different aesthetic preferences, but the attempt to distinguish them by turning the matter of memory-safety into a binary one simply doesn't make sense. The property of memory safety is itself not binary in both languages, and the impact of memory safety is split between more and less important effects. I understand why people wish to find objective metrics to prefer one language over another, but often such metrics are hard to come by, and extrapolation based on questionable assumptions is not really objective. But if you choose to only focus on security weaknesses, and you choose to ignore the language design's impact on code reviews or the fact that allocations are much more visible in Go than in C (which is not very objective, but perhaps you consider these harder to quantify), you would still have to conclude that there's a big difference - on your chosen metric alone - between Zig and C, and a rather small difference between Rust and Zig. What I think really happens, though, is that most of the preference boils down to aesthetics, and then we desperately seek some objective measures to rationalise it. > Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. But if working harder to satisfy the compiler is something that requires less competence than other forms of thinking about a program, then why Rust? Why not ATS? After all, Rust does let you eliminate more bugs at compile time than Zig, but ATS lets you eliminate so many more. So, if this is an objective measure to reject Zig in favour of Rust, then it must also be used to reject Rust in favour of ATS. Neither Rust nor Zig are anywhere near either extreme on compile-time guarantees in general and memory-safety in particular. They're closer to each other on the spectrum than either one of them is to either C or ATS. They both compromise heavily. It's perfectly fine to prefer one compromise over the other, but to a measure that would settle which of these compromises is objectively better is just not something we have at this time. [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html
sirhcm 11mo ago
> One extra register is all you ever need, even for an arbitrary parallel move! This statement, albeit true, is highly misleading. In the example given, you ought to be concerned with parallel assignments not parallel moves. See [0] for more details on the distinction. [0] https://inria.hal.science/inria-00289709 https://inria.hal.science/inria-00289709
TinkersW 11mo ago
The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data.. I don't really think much of Zig myself for other reasons, but comptime seems like a good design.
- spacechild1 11mo ago
  Casting and type conversion are synonyms: https://en.wikipedia.org/wiki/Type_conversion https://en.wikipedia.org/wiki/Type_conversion
  - jjtheblunt 11mo ago
    The post didn't say "type conversion", just conversion, like the int with value 3 landing in memory after calling atoi("3").
    - spacechild1 11mo ago
      The post gave the example of casting a float to an int. That is a (type) conversion. The point is that certain casts/type conversions can change the underlying data. > like the int with value 3 landing in memory after calling atoi("3"). That's something else entirely. People may colloquially call this "converting a string to an integer", but what we're realling doing here is parsing a string as an integer.
- wyldfire 11mo ago
  > Casting is when you change the type, but don't change the data.. Is that the case? That's not what I think of when I think of C-style casts. float val = 12.4; int val_i = (int) val; The representation in memory of `val` should not match that of `val_i`, right? The value is encoded differently and the quantity is not preserved through this transformation. I don't think that means that the data weren't changed. Maybe you're thinking of aliasing/type-punning? Casts in C do perform conversions as they do in C++.
api 11mo ago
I find the point about memory safety to be pretty damning. People think it's a slight on their abilities. "I can write memory safe code!" Maybe you can. There are two huge problems here, and they're problems that will never go away no matter how good you are. The first is that this doesn't scale. As soon as you add more programmers to a project, you multiply the odds of bugs like this. Even if everyone's just as good, not everyone will have the whole program in their head or code in exactly the same style. The second is that code rots. Your new C (or Zig) program might be totally correct and memory safe when it's first written. Then you commit it to a repo. Then you move on to another project for a while. Then someone else fixes something and you merge a PR. Then you come back to it three months later and you're under pressure to implement something. Then you work in a new feature a year later and you've forgotten some of the really nit-picky details of how things work. It's very easy over time for bugs to creep in, and if the language doesn't catch them they'll sit in the code until they cause random crashes or, worse, a CVE. These aren't avoidable issues. They're inherent to software and its life cycle. Memory safe languages (and secure computing systems in general) are the only way to deal with them.
sevensor 11mo ago
What’s the opposite of damning with faint praise? “Removes many but not all of the C footguns. Self hosted compiler isn’t that much faster than Clang.”
- simonmic 11mo ago
  Lauding with faint blame ? :)
- bsder 11mo ago
  > The Zig compiler is not particularly fast. This really makes me question the accuracy of the rest of the article. I'm really struggling to come up with a compiler that is faster than Zig. Go, maybe? That's ... about the end of my shortlist.
  - lerno 11mo ago
    Odin, Jai, C3, C.
    - Bolwin 11mo ago
      Odin? Isn't that built on llvm?
      - lerno 11mo ago
        It uses LLVM as the backend yes.
    - bsder 11mo ago
      Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.
      - ModernMech 11mo ago

129 points by lerno 11mo ago

deleted 11mo ago

[deleted]

anupj 11mo ago

[dead]

torben-friis 11mo ago

This article works really well to illustrate a question I have: why is Zig so popular in posts here? For most languages I can usually see one or two “killer features” that push the language: For Rust is taking C space with memory safety + modern semantics, for Go is being easy to learn by most engineers + parallelization, for Ruby is ergonomics… I don’t see any similar pitch for zig other than a general “I kinda enjoy it”, and the language seems to have a couple red flags, so why focus on it? (Honest question).

munificent 11mo ago
> for Ruby is ergonomics… My impression is that this is the main thing for Zig too. The intersection of the set of languages that let you write very low-level code where you have full control over memory and allocation and the set of languages that are enjoyable to program in is pretty small. C is in there if you've internalized many of its warts are fine with all of the many many footguns it has. C++ is in there if you much of your enjoyment comes from the machismo of feeling like you have conquered C++'s beastly language complexity. Rust is in there if proving to the compiler that you know what you're doing is satisfying to you. Zig sort of gets out of your way like C does, even when what you're trying to do is potentially harmful. But it's more modern and expressive and doesn't have all of C's historical baggage.
- torben-friis 11mo ago
  Ok, that makes sense. So it’s a modern take on low level languages, like rust, but for those that dislike c for being cumbersome rather than for being less secure? Is that a stated goal of the language? Other than the feature to gradually move from c++ it wasn’t super clear from the main pitch.
  - munificent 11mo ago
    > for those that dislike c for being cumbersome rather than for being less secure? I wouldn't say "cumbersome", but perhaps "full of warts and historical baggage". They have some more details here: https://ziglang.org/learn/why_zig_rust_d_cpp/ https://ziglang.org/learn/why_zig_rust_d_cpp/
xanthor 11mo ago
Low abstraction overhead and no ‘big ideas’. It tries to simplify the problem of low-level systems programming by learning from the lessons of the past 50 years.
mtlynch 11mo ago
I'm a casual fan of Zig for hobby development, so just as a data point: I find Zig to be a pleasant option for code that requires high performance. I find it strictly dominates C as an option, as Zig outperforms C on every criteria I care about in a language's developer experience. I often see people compare Zig to Rust and complain that Zig doesn't have Rust's safety guarantees. I don't know Rust, but looking at it casually, the language itself seems to have a lot of complexity that doesn't appeal to me, and I'd still prefer Zig to Rust. If I need memory safety, I'd rather write in Go or Python. When I read articles like these, the gotchas they find don't seem that compelling to me. It's always like if you write your code in a deliberately confusing way to confuse the compiler, you can get incorrect results, but I don't care because I would never write code like that.
xlii 11mo ago
For me, personally, it is nice because it's bare metal where I want it and not bare metal when I don't. C is very basic and (especially when you stick to something like C99), can be very tedious to write. In C, if I hope for smarter things I need to write them by hand; usually there are no ways of achieving some goals without just crunching out the code. Zig preserves C qualities but also gives some extra tools that are completely optional and makes it less tedious than C. I believe that Zig's popularity is also caused by general tendency of some people. Some prefer to fix a segfault than spend half a day refactoring something that was supposed to be easy but is causing half of the codebase to be rewritten. (Oh, and Zig is also an escape hatch to easy CGo :))
salamanderman 11mo ago
I think the post gives an answer to this with "due to Zig's fairly minimalistic nature; it lacks a lot of features that one would otherwise use to solve problems. Of course, this is the appeal for many, but still". I have a lot of C/C++ experience, and they're what I reach for, but I often want C to be a little more like C++, and I often want both to have slightly better memory management, and I've never liked the different syntax for the main language, templates, and pre compiler macros. I also agree with Zig's dogmatic stance on no hidden control flow; I have been bitten by "magic" too many times.
xeonmc 11mo ago
Zig for me is “C with namespaces”. Other selling points are just complimentary.
kristoff_it 11mo ago
Some people like Zig because it makes it easier to learn how to program the machine sitting in front of them. It's better at that than Rust because it's less abstracted, and it's better at that than C because you don't have to worry all the toolchain nonsense / weird conventions / weak type system of the C ecosystem. As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_handler_rust#c_yjqhxq https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha... I think I don't need to provide references for C. It's a new pathway to mastery that really works well for some people. That in itself is much more valuable than any new specific feature the language has to offer, although the ability of the toolchain to cross-compile reliably not only Zig but also C and C++ code does play into that. And, while not yet 100% there, instant incremental rebuilds also help to achieve faster feedback loops. People like Zig because it's a tool that helps them become better programmers, faster.
- metaltyphoon 11mo ago
  > As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha https://lobste.rs/s/emvkea/why_we_didn_t_rewrite_our_feed_ha... Nitpicking? Let’s show an example on creating an interface in Zig to see all complicated tricks.
- NobodyNada 11mo ago
  > As a small example wrt Rust: resetting an arraylist/vector while reusing its memory is a weirdly complicated trick A bit of a nitpick here: the trick is for creating a new vector of a different type, that reuses the allocation of an existing vector, using only safe code. "Resetting an arraylist/vector while reusing its memory" is just vec.clear() if you're not changing the type. And it's trivial to change the type of a vector with unsafe (the docs even have examples of this); the only advantage of the "trick" is to ensure you'll get a panic if you screw up the alignment of the types. And after that blog post, the Rust team accepted a proposal to introduce a vec.recycle() function to change the type of a vector without needing that trick (and with compile-time checks for alignment compatibility): https://github.com/rust-lang/rust/pull/148416 https://github.com/rust-lang/rust/pull/148416 But that example aside, I agree with your overall premise -- Zig and Rust share different design goals here, and Zig's lower level of abstraction makes it more approachable to learn than a language like Rust.
tayo42 11mo ago
With all the hn hype around zig I ended up going through the docs and some example code and felt the same way. I'm not totally sure where this fits into my tool box of languages.
- pyrolistical 11mo ago
  When I first heard about zig, I sat down and read the entire doc from start to end. It was so refreshing and was an instant fan
  - tayo42 11mo ago
    It doesn't seem bad, (though with some of rewrite of the std library? It doesn't seem quite ready) Im just not sure when I'll reach for it. I guess I'm comfortable enough with rust and both seem like languages that compile with llvm. Maybe if I didn't know rust it would feel like more useful.
pron 11mo ago
Turns out that "killer features" are frequently not killer enough. You mentioned Rust with its memory-safety killer-feature, and yet Rust is quite old now (about as old as Java was when JDK 6 came out or JS was when jQuery came out) and its adoption rate is low for such an old age. I have no idea if Zig will be successful or not, but even if you look just at memory safety, I think it does a better job at that than Rust. If you look at MITRE's top 25 dangerous weaknesses [1] or top 10 exploited weaknesses [2], you'll see that Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 on either list, while Zig's more limited memory safety addresses the more dangerous memory-safety-related problems without paying so dearly to solve less severe issues. Now, I personally think that Zig's combination of expressivity and simplicity, while still being low-level, is an unprecedented killer feature (I wrote more about it here: https://news.ycombinator.com/item?id=45852774 https://news.ycombinator.com/item?id=45852774) which makes the language design quite revolutionary and fascinating. This could perhaps translate to correctness benefits. [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html
- pizza234 11mo ago
  > Rust spends almost all of its complexity on eliminating weaknesses that don't even make the top 5 in either list Uh? Number 2 in CWE is an out-of-bounds write, and the same vulnerability is number 1 in the KEV list.
  - pron 11mo ago
    That falls into "spatial" memory safety, which Zig also provides. Rust's ownership and lifetime - the core of its design - go into eliminating use-after-free, aka "temporal" memory safety.
- grogers 11mo ago
  Use after free is number 8 and 9 on the lists respectively... Not like it's way down the list. And most of the things the things above it (other than out of bounds writes/reads which you addressed in another comment) are not something I would consider a programming language can directly affect (e.g. SQL injection, CSRF)
cassepipe 11mo ago
A lot of people strive for something that is simple (not like Rust, and I am not only talking about the borrow checker) and explicit ("debug your program, not your knowledge of the language) but also doesn't bear the historical cruft and idiosyncrasies of C. The fact that it can integrate with C code means that if you are already using C you can adopt it incrementally, plus it works as a build system and cross-compiler and I believe a package manager too. So to sum up : A powerful C without the quirks that manages to keep things simple but is also a batteries-included experience with a smooth adoption path. What's not to love ?
raincole 11mo ago
> for Ruby is ergonomics… In other words, "I kinda enjoy it"?
JuniperMesos 11mo ago
It's doing something novel in the systems programming space, and makes a bunch of different trade-offs compared to Rust. That's interesting, even if you might reasonably conclude that Rust is still a better language to use in most cases. It's good to explore different corners of the programming language design space. Every single commonly-used programming language has a couple red flags, often much more than a couple. Javascript, C, C++, Go, Python - these languages all have serious flaws and are nonetheless used by extremely large numbers of people for all sorts of tasks.

kiitos 11mo ago

probably should define memory safety before using it as an evaluation criterion otherwise, not sure who the audience of this piece is supposed to be, but it's written in a pretty combative tone, which will not be persuasive to anyone who isn't already persuaded, so i guess more of a rant than anything worth sharing here

jasperry 11mo ago
Someone could know what memory safety is and still be persuaded (or reminded) by an argument that it's not okay to adopt a non-memory-safe language due to all the security issues. The author did cite evidence from the Chromium project, which to me elevates it above a mere rant.
- kiitos 11mo ago
  my point with memory safety is that it is not a single well defined concept so if you wanna talk about it you at least gotta say which definition you're using
nightpool 11mo ago
I can see where you're coming from, but I do think there's a fair amount of meat here. I've never used Zig, but I initially thought of it as pretty similar to other modern languages like Go and Rust, and I liked their allocator approach, but the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. I used Bun for a small data-collection project, and I liked its performance, but I ran into a lot of issues with it segfaulting (even when just passing a command line argument that was added in the most recent version!). I think that does a good job of motivating OP's argument and how Zig's language semantics directly contribute to these issues.
- bsder 11mo ago
  > the post gives compelling statistics (Bun has almost EIGHT times as many crash issues as Deno over a similar number of tickets) on Zig's memory safety approach and its issues that also line up with my experience. That's because Zig defers a bunch of checks to runtime that Rust will force you to deal with before it will let you compile at all. That is a tradeoff. Developer velocity vs memory safety. Given that Bun seems to be beating Deno on most metrics, it seems like that was the correct choice for Bun.

anp 11mo ago

I find a lot of these points persuasive (and I’m a big Rust fan so I haven’t spent much time with Zig myself because of the memory safety point), but I’m a little skeptical about the bug report analysis. I could buy the argument that Zig is more likely to lead to crashy code, but the numbers presented don’t account for the possibility that the relative proportions of bug “flavors” might shift as a project matures. I’d be more persuaded on the reliability point if it were comparing the “crash density” of bug reports at comparable points in those project’s lifetimes. For example, it would be interesting to compare how many Rust bugs mentioned crashes back when there were only 13k bugs reported, and the same for the JS VM comparison. Don’t get me wrong, as a Rust zealot I have my biases and still expect a memory safe implementation to be less crashy, but I’d be much happier concluding that based on stronger data and analysis.

kennykartman 11mo ago
I had the same thought. But one thing was actually very useful to compare "bug densities": deno vs bun. They have comparable codebase sizes as well as comparable ages (7y vs 4y). I'd like to see the same stats for tigerbeetle, which is very carefully designed: if segfaults were relatively high on that as too, well...
- williamstein 11mo ago
  bun has 10x the issues matching "segfault" as deno - deno 44: https://github.com/denoland/deno/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/denoland/deno/issues?q=is%3Aissue%20state... - bun 464: https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3Aopen%20segfault https://github.com/oven-sh/bun/issues?q=is%3Aissue%20state%3...
- cb22 11mo ago
  > I'd like to see the same stats for tigerbeetle Actual SIGSEGVs are pretty rare, even during development. There was a pretty interesting one that affected our fuzzing infra a little bit ago: https://ziggit.dev/t/stack-probe-puzzle/10291 https://ziggit.dev/t/stack-probe-puzzle/10291 Almost all of the time we hit either asserts or panics or other things which trigger core dumps intentionally!

pyrolistical 11mo ago

The authors section on comptime makes me believe they have not used zig anything non trivial. I don’t think comptime as just some macro system. It is closer to a reflection system. I use comptime to access types. You can create specialized paths depending on type. Also imo generics are “first class” in zig. Comptime is first class and thus generics are too.

refulgentis 11mo ago
> X is first class and thus Y [implemented in terms of X] is too. Is everything first class, then?
- pyrolistical 11mo ago
  I would argue C preprocessor macros are not first class. They are optional. This anything implements with macros are not first class
- mirekrusin 11mo ago
  In theory it can encode 0 and 1 so anything really, right?

taylorallred 11mo ago

I have admired many parts of Zig and its philosophy but I've never seen it as a language that I want to use. What I've noticed is that Zig users care most about explicitness, simplicity, and minimal indirection. This leads to a lot of syntax that is cumbersome to read (albeit unambiguous) like casting and a lack of "convenience" features. I can't help but think that maybe they're right and that this philosophy probably leads to better software because nothing is "hidden". But, I also think that there's a level of abstraction/indirection that makes code clearer and less error-prone. It's a tricky balance to achieve, and past languages have succeeded and failed at it to different degrees. Either way, I echo the OP's sentiment: if Zig is your jam, great, go make some awesome stuff with it. It's just not my go-to today.

pron 11mo ago
Design choices that are appropriate for low-level programming may be less appropriate for high-level programming and vice versa. In low level programming, you may want to see "on the page" anything that could translate to some machine work, because in low-level programming, such details may be essential to the algorithm. In high-level programming, the same details are likely not essential to the algorithm, and so you don't want to see them.
kstenerud 11mo ago
It really comes down to a matter of opinion where the line between "nothing hidden" and convenience lies. Technically, a loop is an abstraction of convenience that hides the comparative jump underneath.
ksec 11mo ago
I think, but I may be wrong, Zig wants to be high level assembly that could replace C. If people are viewing it from Python, Ruby, JS, and then C++ and Java POV, Zig may be a little too "raw". But then I don't think Zig intends to compete with C++ or Java. May be there will be a Zig ++ or Objective-Zig someday that will do that.

ivanjermakov 11mo ago

> Zig's comptime is a very large and all-encompassing feature that ultimately brings very little to the table that smaller features cannot. > I am personally a proponent of a good macro system. Comptime is much more constraint than any macro system: no code generation (including AST rewrite), no arbitrary tokens. Thus it's much harder to "go overboard" with Zig's comptime. This constraints of cource have their drawbacks, but code generation is still a thing. > Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids.

brabel 11mo ago
> Nice way to put it! But I oppositely believe the world needs more tech that treats professionals as experts, not kids. That’s how it was until around the turn of the century. Who needs types, we’re adults after all. Memory safety and garbage collection? Oh please go back to kindergarten. But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. And those mistakes can have catastrophic consequences. Professionals should go for tools that help them prevent those mistakes, right??
- ModernMech 11mo ago
  > But then some of us learned that no matter how smart we are, we can make mistakes that those things can actually prevent. That's true but it's deeper than that -- no matter how much time goes by, there will always be people new to the language, and they will always make newbie mistakes if the language allows them to. So "just be an expert and don't write shoddy code" doesn't scale, no matter how hard you personally try.
  - refulgentis 11mo ago
    It's deeper to note people who know nothing will make the mistake, than "I, an expert, will make the mistake"? :)

Demiurge 11mo ago

Why have I been seeing a Zig post every day for the past week? Is there some kind of a marketing push?

zenlot 11mo ago
What about more people using it? More than anything this looks to be natural evolution of language.
Zambyte 11mo ago
Interest on various topics comes in waves on HN. This week it's Zig, next week it's Scheme, the week after is Erlang, etc. Nothing out of the ordinary.
- Klonoar 11mo ago
  Programming languages in general go through hype waves here; back in the mid 2000s it was some combination of Lisp -> Ruby -> JS with bits of Erlang in and around those.
0x1ch 11mo ago
I think there's a small trend upwards for Zig & Nim right now. I've seen a few different front page posts for them in the last couple weeks. It at least convinced me to clone ziglings and get a feel for it this last weekend.
refulgentis 11mo ago
There's bursts of them and every 3-6 months I see one like this, more practical, and remember I don't need to read the others. Then I forget in 3 months. Rinse, lather, repeat. (to this 16 year veteran of HN, it reminds of early 2010s Haskell)
tapirl 11mo ago
still less than Rust posts.
bargainbin 11mo ago
Advent of code is coming, maybe lots of people looking for a language to learn with it?

Joker_vD 11mo ago

> Zig does not have a way to iterate through a slice or similar in any way except one-at-a-time forwards. Anything else? You're using a while loop, and you'll enjoy it. INCR[U] i FROM 0 TO len(arr) [BY 1] DO ... DECR[U] i FROM len(arr) TO 0 [BY 1] DO ... Although actual BLISS-77 had inclusive semantics for the upper bounds in both forms. Which, on one hand, allows you to write DECRU i FROM UINT_MAX TO 0 DO ... and expect it to Just Work™ (hopefully? No idea if it worked on actual implementation ― but would've been nice, writing the same in e.g. C is kinda annoying; good luck with Golang pre-1.22 and even then, getting that one last iteration is quirky) but on the other hand, inclusive upper bounds require you to write add that "-1" almost everywhere.

brabel 11mo ago
That looks a lot like Common Lisp LOOP macro!
- Joker_vD 11mo ago
  Honestly, that's been the standard form of FOR loops since Fortran and Algol-60 until C decided to spice things up.
  - brabel 11mo ago
    That may be, but I was born only 40-something years ago, so I haven't had the pleasure to see that other than in Lisp.

deepriverfish 11mo ago

It's interesting to see how popular Zig is becoming, I thought it would get overshadowed by Rust and it would go nowhere.

guywithahat 11mo ago
It's interesting how much Rust has slowed down. There is still some development in linux otherwise people seem to be over it. I think Rust just doesn't offer enough in terms of features, and is overshadowed by languages like Go or C++ in terms of what developers are really looking for. Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle
- pizza234 11mo ago
  > Rust's popularity seems to be dropping or holding steady in indexes like TIOBE, and a lot of big "influencers" seem to be over Rust's hype cycle It is correct that the hype is past its peak, however, the TIOBE trend (if one wants to use that) is actually steadily increasing. > There is still some development in linux "Some development" is a miscarachterization - the official addition to the Linux kernel itself is a very big deal, and its adoption is increasing and will continue to do so. I think that Rust has found its niche in safe low-level programming, and it will slowly have an increasingly dominant role in (although the ceiling of this area is certainly limited in the global landscape).
  - api 11mo ago
    Rust has been adopted by Microsoft, Amazon, etc. It's past the hype phase and well into the "languages people use for work and complain about" phase. I still like it -- for systems programming, that is. It's a much better C++ basically.
    - mwcampbell 11mo ago
      > I still like it -- for systems programming, that is. Just curious, what language(s) do you prefer for things that you don't classify as "systems programming"?

pron 11mo ago

This treatment of memory safety is becoming almost a cargo cult at this point. If this were a binary issue, then clearly Rust wouldn't cut it because it is quite common in Rust (much more so than in, say, Java) to rely on unsafe code. So if you think Rust is good at memory safety, that means that you must believe that some level of unsafety is acceptable. The only question is how much, and what you're willing to pay to reduce it. The reason we care about memory-safety so much, compared to other invariants we'd like our programs to have is because, as the article notes, a very high portion of vulnerabilities are due to memory-safety violations. This is why preventing or reducing such violations is important in the first place. But if we look at vulnerability rankings [1][2], we see that Zig's memory safety covers the top weaknesses just as well as Rust, and much better than C. The vast difference in the complexity of these two languages is because Rust pays a lot to also prevent less dangerous vulnerabilities, outside the top 5. So if Rust is good because it eliminates some very common dangerous vulnerabilities thanks to its memory safety, then Zig must also be good for eliminating the same ones. Calling it C-like because it doesn't eliminate some less common/dangerous vulnerabilities just because Rust does, is just a misunderstanding of why this is all important in the first place. (Plus, if it's important to reduce the security vulnerabilities due to memory safety violations, isn't it better to make avoiding the worst outcomes more approachable?) In software correctness there are few easy choices. Everything boils down to how much you can and should pay to improve your confidence that a certain level of damage won't occur. It's a complicated subject, and trying to present it as a simple one does it a great disservice. In fact, both Rust and Zig address some of the most common/dangerous vulnerabilities — more than use-after-free - just as well as C, which is to say, not, or barely, at all. I.e. there are worse vulnerabilities that neither one of them eliminates than the ones Rust eliminates and Zig doesn't. There is no doubt that Rust and Zig are meant to appeal to people with different aesthetic preferences, but the attempt to distinguish them by turning the matter of memory-safety into a binary one simply doesn't make sense. The property of memory safety is itself not binary in both languages, and the impact of memory safety is split between more and less important effects. I understand why people wish to find objective metrics to prefer one language over another, but often such metrics are hard to come by, and extrapolation based on questionable assumptions is not really objective. But if you choose to only focus on security weaknesses, and you choose to ignore the language design's impact on code reviews or the fact that allocations are much more visible in Go than in C (which is not very objective, but perhaps you consider these harder to quantify), you would still have to conclude that there's a big difference - on your chosen metric alone - between Zig and C, and a rather small difference between Rust and Zig. What I think really happens, though, is that most of the preference boils down to aesthetics, and then we desperately seek some objective measures to rationalise it. > Much of Zig seems to me like "wishful thinking"; if every programmer was 150% smarter and more capable, perhaps it would work. But if working harder to satisfy the compiler is something that requires less competence than other forms of thinking about a program, then why Rust? Why not ATS? After all, Rust does let you eliminate more bugs at compile time than Zig, but ATS lets you eliminate so many more. So, if this is an objective measure to reject Zig in favour of Rust, then it must also be used to reject Rust in favour of ATS. Neither Rust nor Zig are anywhere near either extreme on compile-time guarantees in general and memory-safety in particular. They're closer to each other on the spectrum than either one of them is to either C or ATS. They both compromise heavily. It's perfectly fine to prefer one compromise over the other, but to a measure that would settle which of these compromises is objectively better is just not something we have at this time. [1]: https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html https://cwe.mitre.org/top25/archive/2024/2024_cwe_top25.html [2]: https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html https://cwe.mitre.org/top25/archive/2024/2024_kev_list.html

sirhcm 11mo ago

> One extra register is all you ever need, even for an arbitrary parallel move! This statement, albeit true, is highly misleading. In the example given, you ought to be concerned with parallel assignments not parallel moves. See [0] for more details on the distinction. [0] https://inria.hal.science/inria-00289709 https://inria.hal.science/inria-00289709

TinkersW 11mo ago

The author refers to casting ints to floats but seems to actually be talking about converting. Casting is when you change the type, but don't change the data.. I don't really think much of Zig myself for other reasons, but comptime seems like a good design.

spacechild1 11mo ago
Casting and type conversion are synonyms: https://en.wikipedia.org/wiki/Type_conversion https://en.wikipedia.org/wiki/Type_conversion
- jjtheblunt 11mo ago
  The post didn't say "type conversion", just conversion, like the int with value 3 landing in memory after calling atoi("3").
  - spacechild1 11mo ago
    The post gave the example of casting a float to an int. That is a (type) conversion. The point is that certain casts/type conversions can change the underlying data. > like the int with value 3 landing in memory after calling atoi("3"). That's something else entirely. People may colloquially call this "converting a string to an integer", but what we're realling doing here is parsing a string as an integer.
wyldfire 11mo ago
> Casting is when you change the type, but don't change the data.. Is that the case? That's not what I think of when I think of C-style casts. float val = 12.4; int val_i = (int) val; The representation in memory of `val` should not match that of `val_i`, right? The value is encoded differently and the quantity is not preserved through this transformation. I don't think that means that the data weren't changed. Maybe you're thinking of aliasing/type-punning? Casts in C do perform conversions as they do in C++.

api 11mo ago

I find the point about memory safety to be pretty damning. People think it's a slight on their abilities. "I can write memory safe code!" Maybe you can. There are two huge problems here, and they're problems that will never go away no matter how good you are. The first is that this doesn't scale. As soon as you add more programmers to a project, you multiply the odds of bugs like this. Even if everyone's just as good, not everyone will have the whole program in their head or code in exactly the same style. The second is that code rots. Your new C (or Zig) program might be totally correct and memory safe when it's first written. Then you commit it to a repo. Then you move on to another project for a while. Then someone else fixes something and you merge a PR. Then you come back to it three months later and you're under pressure to implement something. Then you work in a new feature a year later and you've forgotten some of the really nit-picky details of how things work. It's very easy over time for bugs to creep in, and if the language doesn't catch them they'll sit in the code until they cause random crashes or, worse, a CVE. These aren't avoidable issues. They're inherent to software and its life cycle. Memory safe languages (and secure computing systems in general) are the only way to deal with them.

sevensor 11mo ago

What’s the opposite of damning with faint praise? “Removes many but not all of the C footguns. Self hosted compiler isn’t that much faster than Clang.”

simonmic 11mo ago
Lauding with faint blame ? :)
bsder 11mo ago
> The Zig compiler is not particularly fast. This really makes me question the accuracy of the rest of the article. I'm really struggling to come up with a compiler that is faster than Zig. Go, maybe? That's ... about the end of my shortlist.
- lerno 11mo ago
  Odin, Jai, C3, C.
  - Bolwin 11mo ago
    Odin? Isn't that built on llvm?
    - lerno 11mo ago
      It uses LLVM as the backend yes.
  - bsder 11mo ago
    Jai isn't open source so it is completely and totally irrelevant. Zig builds C faster than most C compilers. You're going to have to do better than just mention it. However, if those are the only things that are even possibly faster than Zig, then the Zig compiler qualifies as fast, not slow--which was my original point.
    - ModernMech 11mo ago