5 ms·

While comptime looks extremely powerful, I'm really not a fan of how it's used for unconstrained generics. This is the same problem I have with C++ templates wh

by Siyo 7y ago

While comptime looks extremely powerful, I'm really not a fan of how it's used for unconstrained generics. This is the same problem I have with C++ templates where an incorrect use of a generic function would result in an explosion of bizarre undescriptive template errors. Sure you can write these type asserts yourself, but it's time consuming and how many developers will actually do it and get it right? I don't know, maybe it's really not that big of a deal, but I much prefer how Rust does this using traits as type constraints (although at some cost of complexity, e.g. Eq, PartialEq, Ord, PartialOrd). Not to mention that by using constraints on the type system level, you actually get useful type signature documentation on what you can or cannot pass to a function.

moomin 7y ago
The presence of general type level programming does, however, mean that you can build decent preconditions on types. Which will get you further than you could in C++. I’m more concerned by the typeid switching, but maybe it’s got a proper structured mechanism as well.
pjmlp 7y ago
That C++ problem is partially fixed via enable_if, static_assert and constexpr if. And fully fixed in future C++20 codebases with concepts.
pron 7y ago
For one, Zig's error reporting is more friendly than C++ and will continue to get better. For another, it's a tradeoff, but the fact that the language is so much simpler than C++/Rust and compilation faster gives you a lot of headroom elsewhere (when the development cycle is faster, it's easier to focus your resources where they matter most to you). Of course, language preference is personal and aesthetic, and different people have different preferences.
- gnuvince 7y ago
  Zig is a simpler language, but that simplicity comes at a cost: the memory bugs that exist in C also exist in Zig. Users bear the cost of the programmer using a simple language. Rust is a more complex language, but it eliminates a number of classes of memory error. In this case, the programmer bears the cost of users having safer programs. Although I find Zig very interesting—and I wish Andy the best of success with it—the trade-off that the Rust offers is more in line with my values and my ethics.
  - jorangreef 7y ago
    > the memory bugs that exist in C also exist in Zig. No, they don't. See Zig's release-safe mode. Also: https://news.ycombinator.com/item?id=17184929 https://news.ycombinator.com/item?id=17184929 > the trade-off that the Rust offers is more in line with my values and my ethics. By the way, it's awesome that you like Rust, but there's no need to imply there's something ethically wrong with Zig. Depending on the platform you're targeting, you may yet find a use for either language.
    - deleted 7y ago
      [deleted]
    - edflsafoiewq 7y ago
      release-safe doesn't prevent all memory bugs.
      - jorangreef 7y ago
        Sure, but then not even "safe" languages like JavaScript will prevent all memory bugs. And to be fair, Rust does introduce memory issues of its own in terms of allocation strategy. For certain projects, Rust would not be considered "safe" with respect to memory. Zig's release-safe mode is worlds away from "the memory bugs that exist in C". See also: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
        deleted 7y ago
        [deleted]
  - pron 7y ago
    This is very inaccurate, and as a formal methods practitioner, I'd like to try and explain why. It's part of what I call "the soundness problem," and it is this. Suppose you have some class of bugs that you can eliminate in the type system (in the case of Rust, this class of bugs -- various kinds of memory errors -- is, indeed, an important one, known to be the cause of many costly bugs). A type system eliminates 100% of those errors, but because a type system works based on deductive proofs, it, too, must make a tradeoff: either be relatively unrestrictive with regards to how the programs are written, but then those proofs can be very complicated[1], or work with simple proofs, but restrict the programs. Rust has chosen the latter (which is the correct choice, IMO). However, either way, this kind of proof has a significant cost, and the cost exists because of the 100% guarantee. In general, in formal methods, the cost of verifying a property can rise by 10x or more if you want to go from 99.5% certainty to 100% certainty. So Rust gives you 100%, but at a non-negligible cost. So now the question is, is it worth it? After all, while extremely important, these memory bugs aren't the only dangerous ones, and you still need to verify your program by other means. Zig does something different, and no, it doesn't work like C. Zig allows (and encourages) you to turn on runtime checks that also guarantee no memory errors, but at a cost to performance. Then, after testing, you can turn those off for your entire program or just the performance-sensitive parts. So this, combined with language simplicity, also gets rid of those bugs, except not with 100% guarantee. The fact that Zig is so simple also helps reduce other kinds of bugs perhaps better than Rust. Soundness comes at a cost that, perhaps unintuitively, can harm correctness. So to make this simplistic, you could say that Rust sacrifices other kinds of bugs (due to complexity) in order to guarantee no bugs of a certain class, while Zig gives you no 100% guarantee regarding any kind of bug (after turning off runtime checks), but it does give you the tools and the focus to reduce bugs across the board. So even if you're uncompromising on correctness to the point you employ formal methods (as I do, and I assume you do, too, as you consider it a matter of ethics), there's still no clear winner even on correctness alone between the two approaches. You could just as well argue that your ethics directs you to preferring Zig, because it may well be that its correctness story is stronger than Rust's; we just don't know. I like to choose my own "correctness focus" and I dislike complex languages so I prefer Zig, but I completely understand that Rust is a better fit for other people's tastes. [1]: This, e.g., is what you can do with ACSL and C.
Jayschwa 7y ago
There is a proposal for adding type constraints to generic functions. That doesn't mean it will necessarily be added, but it's something the community is thinking about. https://github.com/ziglang/zig/issues/1669 https://github.com/ziglang/zig/issues/1669
adrusi 7y ago
Unlike in C++, Zig makes it easy to do compile time type introspection to see what the types passed as parameters are capable of, and then emit useful error messages if it doesn't satisfy the necessary contract. It's less streamlined than Rust traits, but you also get HKT for free (in theory) by making parameterized types be functions.

by Siyo 7y ago

moomin 7y ago

The presence of general type level programming does, however, mean that you can build decent preconditions on types. Which will get you further than you could in C++. I’m more concerned by the typeid switching, but maybe it’s got a proper structured mechanism as well.

pjmlp 7y ago

That C++ problem is partially fixed via enable_if, static_assert and constexpr if. And fully fixed in future C++20 codebases with concepts.

pron 7y ago

For one, Zig's error reporting is more friendly than C++ and will continue to get better. For another, it's a tradeoff, but the fact that the language is so much simpler than C++/Rust and compilation faster gives you a lot of headroom elsewhere (when the development cycle is faster, it's easier to focus your resources where they matter most to you). Of course, language preference is personal and aesthetic, and different people have different preferences.

gnuvince 7y ago
Zig is a simpler language, but that simplicity comes at a cost: the memory bugs that exist in C also exist in Zig. Users bear the cost of the programmer using a simple language. Rust is a more complex language, but it eliminates a number of classes of memory error. In this case, the programmer bears the cost of users having safer programs. Although I find Zig very interesting—and I wish Andy the best of success with it—the trade-off that the Rust offers is more in line with my values and my ethics.
- jorangreef 7y ago
  > the memory bugs that exist in C also exist in Zig. No, they don't. See Zig's release-safe mode. Also: https://news.ycombinator.com/item?id=17184929 https://news.ycombinator.com/item?id=17184929 > the trade-off that the Rust offers is more in line with my values and my ethics. By the way, it's awesome that you like Rust, but there's no need to imply there's something ethically wrong with Zig. Depending on the platform you're targeting, you may yet find a use for either language.
  - deleted 7y ago
    [deleted]
  - edflsafoiewq 7y ago
    release-safe doesn't prevent all memory bugs.
    - jorangreef 7y ago
      Sure, but then not even "safe" languages like JavaScript will prevent all memory bugs. And to be fair, Rust does introduce memory issues of its own in terms of allocation strategy. For certain projects, Rust would not be considered "safe" with respect to memory. Zig's release-safe mode is worlds away from "the memory bugs that exist in C". See also: https://github.com/ziglang/zig/issues/2301 https://github.com/ziglang/zig/issues/2301
      - deleted 7y ago
        [deleted]
- pron 7y ago
  This is very inaccurate, and as a formal methods practitioner, I'd like to try and explain why. It's part of what I call "the soundness problem," and it is this. Suppose you have some class of bugs that you can eliminate in the type system (in the case of Rust, this class of bugs -- various kinds of memory errors -- is, indeed, an important one, known to be the cause of many costly bugs). A type system eliminates 100% of those errors, but because a type system works based on deductive proofs, it, too, must make a tradeoff: either be relatively unrestrictive with regards to how the programs are written, but then those proofs can be very complicated[1], or work with simple proofs, but restrict the programs. Rust has chosen the latter (which is the correct choice, IMO). However, either way, this kind of proof has a significant cost, and the cost exists because of the 100% guarantee. In general, in formal methods, the cost of verifying a property can rise by 10x or more if you want to go from 99.5% certainty to 100% certainty. So Rust gives you 100%, but at a non-negligible cost. So now the question is, is it worth it? After all, while extremely important, these memory bugs aren't the only dangerous ones, and you still need to verify your program by other means. Zig does something different, and no, it doesn't work like C. Zig allows (and encourages) you to turn on runtime checks that also guarantee no memory errors, but at a cost to performance. Then, after testing, you can turn those off for your entire program or just the performance-sensitive parts. So this, combined with language simplicity, also gets rid of those bugs, except not with 100% guarantee. The fact that Zig is so simple also helps reduce other kinds of bugs perhaps better than Rust. Soundness comes at a cost that, perhaps unintuitively, can harm correctness. So to make this simplistic, you could say that Rust sacrifices other kinds of bugs (due to complexity) in order to guarantee no bugs of a certain class, while Zig gives you no 100% guarantee regarding any kind of bug (after turning off runtime checks), but it does give you the tools and the focus to reduce bugs across the board. So even if you're uncompromising on correctness to the point you employ formal methods (as I do, and I assume you do, too, as you consider it a matter of ethics), there's still no clear winner even on correctness alone between the two approaches. You could just as well argue that your ethics directs you to preferring Zig, because it may well be that its correctness story is stronger than Rust's; we just don't know. I like to choose my own "correctness focus" and I dislike complex languages so I prefer Zig, but I completely understand that Rust is a better fit for other people's tastes. [1]: This, e.g., is what you can do with ACSL and C.

Jayschwa 7y ago

There is a proposal for adding type constraints to generic functions. That doesn't mean it will necessarily be added, but it's something the community is thinking about. https://github.com/ziglang/zig/issues/1669 https://github.com/ziglang/zig/issues/1669

adrusi 7y ago

Unlike in C++, Zig makes it easy to do compile time type introspection to see what the types passed as parameters are capable of, and then emit useful error messages if it doesn't satisfy the necessary contract. It's less streamlined than Rust traits, but you also get HKT for free (in theory) by making parameterized types be functions.