I don't understand what he wanna imply. Both are programming languages, and we should just let people decide what is best for them. How is Rust lang creating a problem that Zig lang developer is saying "Let us exists".
Zig is in a sense the antithesis to that statement, in that it eschews complex tools like a sophisticated type system, in favour of simplicity and programmer enforced contracts, with the reasoning that it is easier to informally proof correctness of a simple system, than to formally proof correctness of a very complex system. The correctness of the latter often being a somewhat shallow property that is still able to miss the intended semantics (think memory vs logic bugs).
The closest analogy in programming language communities is probably clojure vs scala or haskell. In fact there is an interesting paper on code quality, where clojure compared quite favourably to statically typed languages, despite it's dynamic nature. https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf
(And btw, unsafe code cannot be ignored altogether since it comes up naturally in any interaction with outside, non-Rust code. Additionally, idiomatically "safe" APIs can sometimes introduce restrictions that leave some performance gains on the table compared to well-written unsafe interfaces.)
In a sense rust hasn't managed to reach it's de Bruijn criterion yet, see https://lawrencecpaulson.github.io/2022/01/05/LCF.html
However, the very same can be said for zig. Given that it is such a simple language, development has focused on a many interesting things including incredible performance, but one has to wonder if the priority shouldn't have been correctness and a fully working compiler that can handle e.g. packed unions.
Surely you're joking, because zig is a joke. As recently as 0.9-rc2 (and probably to this day) `{ .x = if (false) { X(); } }` sometimes calls X. It is not possible to be "more correct" in such a language.
Zig inspired me to think deeply about comptime evaluation and how it could be made into a coherent language, and in that respect it is a useful toy language, but no more. (In zig the comptime idea is incoherent: You cannot run ordinary zig code at comptime because of core differences in behavior. For example, there's no allocation allowed, except that code which appears literally in a comptime block can sometimes append arrays together; but this still means you can't run ordinary code.)
ETA: Oh this is even better: `if (false)` code can (as of 0.10) run even outside field assignment: https://github.com/ziglang/zig/issues/12040
Like I said, joke language. I define that as a toy language which is badly broken by design. Kind of like LOLCODE except I doubt LOLCODE runs `if (false)` code.
More issues with `if`: https://github.com/ziglang/zig/issues/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097
This one is quite funny. Normally you'd use `if (a) ... else |b| ...` if the type of `a` was an error union, and you'd get the `if` branch if it was not an error and the `else` branch if it was an error. So I suspect that there's a coercion from bool to some error union here. Error unions with lazily computed error sets are allowed, and (as a result of this or of other choices about the ergonomics of conditionally-compiled code that would be made of #typedefs in C) error unions with empty error sets are allowed. Wow.
The stage1 compiler is currently being phased out for the stage2 compiler (Zig implementation). As of current master branch, stage1 is disabled by default (can be re-enabled with `-fstage1`) in favor of stage2.
2) The miscompilation in question is `if (false) else |capture| {}` not just `if (false)`. The latter is misinformation.
3) Miscompilations are conditional. Saying that the entire compiler is invalid given they exist is like saying rustc is invalid / can't uphold safety invariants given long standing compiler bugs allowing safe code to trigger UB / segfault [0] [1]. Both of such conclusions aren't true in practice.
[0]: https://crates.io/crates/fake-static [1]: https://github.com/rust-lang/rust/issues/25860
I cannot provide the full program in which it failed, and the small programs I tried did not cause it to fail at the time.
I sort of expect these things to be fixed though. Like, eventually both Zig and unsafe Rust will actually have defined semantics, and eventually expressions containing `if (false) { X(); }` will not call X, and so on.
Edit: after seeing the linked issue in a sibling comment, this is even less surprising. stage1's handling of basically any complex expression in struct/tuple literals is quite bad. I've mostly had it crash the compiler, but it's not surprising that it can also just evaluate incorrectly. It seems plausible that the actual solution to all this is to use stage2 instead, but we cannot move all of our programs to stage2 today because we use async.
If you worry about unsafety in Rust, then you should know you can run miri on your unsafe code to check for undefined behavior, in addition to most C tools used like valgrind, etc.
"Can be more" correct is a bit weaselish (corrolarry it "Can be less"). Sure. You can write bad code in any language. Rust gives you tools to limit sets of memory errors, and on top of that you can use C-standard tools, -AND- even Rust specific tools.
And on top of that it offers sets of tools to eliminate possible errors in safe Rust code (see Clippy).
The sense I get from reading a few Twitter threads is that members of the Zig community feel that the Rust community disagrees so strongly with some of Zig's design decisions that the Rust folks suggest that the world would be better without Zig.
>A massive step backwards for the industry. :(
https://twitter.com/pcwalton/status/1568306598795431936?s=46...
:(
Maybe this has something to do with this line from former Rust team member:
> I don't see much room for a new language that isn't memory-safe in 2022.
> It's perfectly reasonable to take the position that it's deeply problematic for a language aiming for wide use in 2022 to not be memory safe. There's no requirement that you "focus on tradeoffs", especially since real people get hurt by memory safety problems.
And my message was already about someone else calling Zig users irresponsible. Talk about toxicity.
If you eliminate enough memory-safety bugs, then other classes start to dominate and should also be addressed. Rust is beyond this point, but to get there it diverted resources from addressing other kinds of bugs and has also made some severe usability/productivity tradeoffs. Zig might or might not be at that point, but it certainly promises to get there and to do so without the same drawbacks. Ultimately the question is which language lets you write more bug-free code per month. A reasonable argument could be made that it's Rust and a reasonable argument could be made that it's Zig. Only time will tell, but only if both continue to exist and evolve, which pcwalton and others seem unwilling to let happen. What's "deeply problematic" is their belief that Rust's goals and approaches represent The One Right Way and no others can be allowed to exist.
If you follow Zig and Rust closely on HN you may have more sympathy as to why they think that.