Headers are missing IDs for URL fragments to jump to e.g. https://strongly-typed-thoughts.net/blog/zig-2025#error-hand... doesn't work
I noticed that and fixed it on my lunch break. Sorry for the inconvenience!
Zig; what I think after months of using it
151–160 of 181 posts
Re: Zig; what I think after months of using it
#152Earlier quoted context omitted.
WTH they were talking about Rust and Zig, they did not even mention C++ and you come with "if your metrics is blah then C++ is superior, checkmate!", completely ignoring C++ is a monster of complexity while Zig is basically simple as C.
If you present an argument that you like X in a thing so you picked B, and A exist that's more X than B, it means your argument is partially (you like X and Z) or totally (you like Y) wrong. In this context of, if you are using Zig for its safety via tooling, there is a much more mature candidate C++.
That's exactly what I was criticizing: you just make the unfounded assumption that "argument that you like X" is the only thing that matters, and the debate is not only about X in the context of languages A and B. Introducing C to the debate is stupid, as then the obvious answer is just "but C has Y which is horrile" and so on.
Re: Zig; what I think after months of using it
#153Earlier quoted context omitted.
The debate seems to have mostly ended in a victory for static types. The largest languages other than Python have them (if you include the transition from JS to TS). Python is slowly moving toward having them too.
If I'm told to still use === in typescript, it's not actually a statically typed language.
It's not a statically typed language. No one is claiming it is. It's a dynamic language with static types.
Re: Zig; what I think after months of using it
#154Earlier quoted context omitted.
As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide a…
A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive. A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.
Is Zig really a simpler language? It has a ton of features!
Re: Zig; what I think after months of using it
#155Earlier quoted context omitted.
This is precisely the myth that the article talks about. Miri finds significantly more UB in unsafe Rust than Zig's checks do. Even if it weren't, this exaggeration is a complete theater. You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. The entirety of all Zig codebases is unsafe. That's fine if you are fine with unsafe cod…
> Miri finds significantly more UB in unsafe Rust than Zig's checks do. That's not a substantiated claim. Miri also runs very slowly. > You aren't supposed to use unsafe Rust unless you really have to. I have been using Rust since 2020 and I've used it once, for 3 lines of code. Cool, glad you haven't needed it. If you're ever writing interpreters or interfacing with external code, you'll need it. > The entirety of a…
> That's not a substantiated claim.
The article we are commenting on substantiates it with, several, actual examples.
> interpreters
In what world do interpreters require unsafe code? A naive interpreter that recursively descends an AST doesn't need it, and a bytecode interpreter doesn't need it either. You'll probably need it if you want to make a fast GC, but that does not mean your entire codebase has to be unsafe.
> interfacing with external code
This is one reason unsafe exists, yes. You are supposed to hide the unsafe parts behind a safe interface. For example, Rust unavoidably has to deal with external code to do I/O - yet, the exposed std::fs interface is safe. This is a well established doctrine in the Rust community, and at least one prominent project has received hot hell for ignoring it.
And, again, the portions of code that are unsafe in a Rust codebase - even when required - are supposed to be minimal, well contained, and well tested. Running a suite of tests to check a small amount of code under Miri is not prohibitive at all. If someone is going to insist on using unsafe across their codebase then, yes, they are far better served by using a language that is unsafe to begin with.
I have done embedded Rust, and even there I have largely avoided unsafe code (the 3 lines I was forced to write happened to be for embedded).
> Rust's safety overhead has real trade-offs [...]
I never claimed otherwise. Those trade-offs have a purpose: fewer degrees of freedom result in higher degrees of certainty. Even Rust has too many degrees of freedom[1], but we don't sweep that under the rug, deflect it, or outright lie about the situation.
The Rust zeitgeist largely agrees your opinion (or rather: Andrew's opinion) of unsafe Rust, in a very oblique way. It's shit, we don't like using it. It is certainly not an accurate summary of Rust as a whole.
Leveraging unsafe Rust against Rust as a whole is a dishonest line of thinking and I'm not going to engage with it further.
Re: Zig; what I think after months of using it
#156Earlier quoted context omitted.
A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive. A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.
> A big company I worked at actually deprecated the last of its Rust code last year. What replaced Rust?
A newer JVM language, which admittedly came with its own share of problems.
Re: Zig; what I think after months of using it
#157Earlier quoted context omitted.
> it appears the clr author anticipated you: you didnt fork it, try, and fail, so you have ceded the authority to credibly make your speculative complaint That's a caveat. Not an expectation. Plus that's not how proof works. Neither Zig nor Zig+Clr have really proven they are safe, ergo they are unsafe or possibly safe (respectively).
wow what are you afraid of. you're working really hard to tear down something that is an incomplete proof of concept.
The original argument is that clr proves Zig is as safe as Rust, per your wording " all the memory safety parts."
Does the incompletely POC do all the parts, or doesn't it? That is no criticism against the project itself, striving to improve memory safety in any language is an honorable goal. The cinch is that an incomplete POC doesn't prove things one way or another, the POC needs to be completed (or at least completed far enough to prove your point). It either matches or exceeds Rust memory safety, or it only vastly improves Zig memory safety. Both are great outcomes, for what it's worth.
It shouldn't have been shown as an example of how Zig is just as/more safe than Rust if it is not. Mispresenting the project tears it down, not questioning its use an an example. Just like misrepresenting Zig's safety (and Rust's unsafety) tears Zig down.
Re: Zig; what I think after months of using it
#158Earlier quoted context omitted.
I don't know zig at all, but why is the author trying to declare foo as const 3 times. Surely you would declare it as var with some default value that means uninitialized, then try and put values in it.
It's probably a Zig antipattern, but it's a very common Rust pattern. Shadowing in Rust allows immutability to be ergonomic, and lack of shadowing discourages immutability. Zig isn't Rust, so it makes sense that patterns in Rust don't translate well, but also I totally get TFA's preference for Rust in this case.
Oh, I just read the rust doc and its says "once a value is bound to a name, you can’t change that value." but I've thought of immutability the other way around, once a name has a value, it can't be changed.
I thought the value of const was once you read const x = 1024, you can be sure that x is 1024 while its in scope, that subsequent code can make assumptions about the content of variable x. Or, when you see x in the code, you can jump directly to its definition and know what its value will be. Defined once and not changed.
Apparently I don't understand the value of const at all.
Re: Zig; what I think after months of using it
#159Earlier quoted context omitted.
It's probably a Zig antipattern, but it's a very common Rust pattern. Shadowing in Rust allows immutability to be ergonomic, and lack of shadowing discourages immutability. Zig isn't Rust, so it makes sense that patterns in Rust don't translate well, but also I totally get TFA's preference for Rust in this case.
Oh, I just read the rust doc and its says "once a value is bound to a name, you can’t change that value." but I've thought of immutability the other way around, once a name has a value, it can't be changed. I thought the value of const was once you read const x = 1024, you can be sure that x is 1024 while its in scope, that subsequent code can make assumptions about the content of variable x. Or, when you see x in th…
There is a distinction between the variable itself and its name. Const (and Rust's immutability-by-default) ensures that the variable does not change after assignment. This holds true even as references to it are passed to other functions or stored for later use. You "can't" accidentally pass a reference to that variable which will then be unexpectedly mutated a dozen calls deep into a library function you didn't write.
If you have shadowing, it simply means you can have a different variable with the same name later in the same (or child) scope, this usually must be explicit. The same name now refers to a different variable, but the original variable still exists and remains valid.
It's quite a useful pattern, particularly where the old value is no longer useful (for example transforming input), especially when using the old value might be valid code but would be a mistake.
Re: Zig; what I think after months of using it
#160lol, I knew exactly who wrote this once I saw the complaint about shadowing being forbidden. The author and I were just arguing about it the other day on irc. While the author considers it an annoying language bug because it requires creating additional variable names (given refactoring was an unpalatable option). I consider it a feature. Said arguments have become a recurring and frustrating refrain; when rust impos…
The duck typing argument is absolutely not based on minimal or missing documentation. There wouldn't be countless issues about it in the Zig repository if it were that simple. See https://github.com/ziglang/zig/issues/17198 I'm simply going to quote one of the comments from the linked GitHub issue: > generic code is hard. Hard to implement correctly, hard to test, hard to use, hard to reason about. But, for better or…
I disagree with that GitHub comment.
Saying Zig has generics because it has comptime is like saying c has generics, because C has a pre-processor
It's a wild take that you have to willfully ignore the context and nuance (implemention, rules, and semantics) for it to be true. More true than misleading, at any rate.