4 ms·

The rust philosophy is very correctness oriented and safety focused. This, combined with a general frustration with how broken software engineering is as a whol

by j-pb 4y ago

The rust philosophy is very correctness oriented and safety focused. This, combined with a general frustration with how broken software engineering is as a whole, has led to the mindset in part of the rust community that using anything less than very rigorous type checking is unprofessional and dangerous (think Therac-25, https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25). 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 https://web.cs.ucdavis.edu/~filkov/papers/lang_github.pdf

zozbot234 4y ago
Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. The Rust devs are still working on giving a full semantics for the 'unsafe' superset of the language, and this currently involves quite a few pitfalls that just don't exist elsewhere in the same way. (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.)
- j-pb 4y ago
  Yes I wholeheartedly agree, rust is definitely overpromising in that department. The language has grown too large too quickly imho, and having the compiler as a formally verifying aide when the foundations/axioms aren't defined yet certainly leaves a bad aftertaste for me. 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 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.
- puffoflogic 4y ago
  > Zig can easily be more correct than unsafe code in Rust. 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.)
  - josephcsible 4y ago
    When exactly would that call X? Can you post or link to a whole program where it does?
    - puffoflogic 4y ago
      It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. 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 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/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097
      - anonymoushn 4y ago
        > https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 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.
- Ygg2 4y ago
  > Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. 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).

by j-pb 4y ago

zozbot234 4y ago

Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. The Rust devs are still working on giving a full semantics for the 'unsafe' superset of the language, and this currently involves quite a few pitfalls that just don't exist elsewhere in the same way. (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.)

j-pb 4y ago
Yes I wholeheartedly agree, rust is definitely overpromising in that department. The language has grown too large too quickly imho, and having the compiler as a formally verifying aide when the foundations/axioms aren't defined yet certainly leaves a bad aftertaste for me. 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 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.
puffoflogic 4y ago
> Zig can easily be more correct than unsafe code in Rust. 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.)
- josephcsible 4y ago
  When exactly would that call X? Can you post or link to a whole program where it does?
  - puffoflogic 4y ago
    It's a known issue, idk, look it up in the github issues. https://github.com/ziglang/zig/issues/3882 https://github.com/ziglang/zig/issues/3882 is related but not quite the same thing. 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 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/10349 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/8952 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/4491 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/5230 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/6444 https://github.com/ziglang/zig/issues/7097 https://github.com/ziglang/zig/issues/7097
    - anonymoushn 4y ago
      > https://github.com/ziglang/zig/issues/12040 https://github.com/ziglang/zig/issues/12040 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.
Ygg2 4y ago
> Somewhat ironically, idiomatic code in Zig can easily be more correct than unsafe code in Rust. 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).