4 ms·

> Rust’s type system ended up being Turing-complete anyway. It seems like it fell into the same trap as C++ templates: it’s an accidental programming language i

> Rust’s type system ended up being Turing-complete anyway. It seems like it fell into the same trap as C++ templates: it’s an accidental programming language in a programming language, but with way worse syntax. Most anything in software can easily end up Turing-complete though. It isn't that high of a bar unfortunately. I think most mature type and template systems end up as Turing-complete. To single out Rust for this is to ignore that this is just standard fare for mature typing systems. TypeScript's types are Turing complete: https://github.com/microsoft/TypeScript/issues/14833 https://github.com/microsoft/TypeScript/issues/14833 Python's type hints are Turing complete: https://arxiv.org/abs/2208.14755 https://arxiv.org/abs/2208.14755 Java generics are Turing complete: https://arxiv.org/abs/1605.05274 https://arxiv.org/abs/1605.05274

dgb23 3y ago
The point is that Zig basically circumvents issues surrounding that, by introducing "comptime", where you can just write regular Zig to achieve the same things. The article showcases a nice example of having this very direct power. But it really comes up more often than you think as soon as you actually have it. It's easy in Zig to allocate precisely based on computed values and then have the sizes as part of your types etc. It all falls out of some simple ideas and it's all just regular Zig code. "Types in Zig are values of the type type" from: https://ziglearn.org/chapter-1/ https://ziglearn.org/chapter-1/ So instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs.
- bhouston 3y ago
  Here is a really good link that shows the power of Zig's comptime: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/
- littlestymaar 3y ago
  The problem is that it ends up being dynamically-typed, like C++ templates. See: https://nitter.net/pcwalton/status/1369114008045772804 https://nitter.net/pcwalton/status/1369114008045772804 > So instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs. Well maybe in theory, but the current state of Zig is that it makes it hard to write programs no matter how correct because the compiler keeps crashing ¯\_(ツ)_/¯
  - wredue 3y ago
    What are you talking about? The tagged versions are usually quite stable and also plan bug fix follow ups. If you follow master, you’ll occasionally run in to crashes, which is true of any developing language. If you don’t want that, follow tagged versions.
- chrismorgan 3y ago
  I am certainly sometimes envious of comptime and what it makes practical, but it’s worth noting that it results in dynamically-typed generics, whereas Rust goes for statically-typed generics, which is in keeping with its goals. There are some significant general maintainability improvements in statically-typed generics; when you use dynamic generics, subtle changes in one place can cause obscure compile errors in a completely different and seemingly unrelated place (commonly called post-monomorphisation errors); this doesn’t happen with static generics. So… I’m not sold on your wording that it’s circumventing issues, as it’s choosing a different set of trade-offs. In shedding types-are-a-language-of-their-own, you also shed confidence about what’s a breaking change, and make call sites more fragile. Decide for yourself whether it’s worth it.
  - convolvatron 3y ago
    is there anything fundamental about using the same language at compile time to generate fully static typing that is boiled away? I don't know, but it doesn't seem so?
  - dgb23 3y ago
    I'm still in the honeymoon phase with this language and learning, but I agree it's a trade off. For example your LSP isn't going to help you as much while you edit code. However being able to express arbitrary compile time constraints and pre-compute stuff without having to go through a code generation tool is really powerful. You can actually use all the knowledge you have ahead of time as long as you can express it in Zig. So far it seems like Zig is carving out a very strong niche for itself.
  - anonymoushn 3y ago
    What do you mean by dynamically-typed generics and statically typed generics here? I've looked up "post-monomorphization errors" and found some things about assertions about generic types failing because of the choices made by the user who passed in types or constants that do not work with the generic code. It seems like Zig libraries have the option of generating the errors at the right place if they place their assertions in the function that returns the type to the user, but they also have the option of generating the errors in the wrong place if they place their assertions in methods of the type. > So… I’m not sold on your wording that it’s circumventing issues, as it’s choosing a different set of trade-offs. In shedding types-are-a-language-of-their-own, you also shed confidence about what’s a breaking change, and make call sites more fragile. Decide for yourself whether it’s worth it. Client code can just look at all the members of all the structs so there's not really much hope for enforcing that changes cannot break any client code using compiler-adjacent tooling.
- ksec 3y ago
  >instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs. Or May be rephrasing it ( To avoid the word "instead" which may anger Rust supporters ); Rust Makes it hard to write incorrect programs, Zig makes it easy to write correct programs. I think this single sentence captures the philosophical difference between Rust and Zig. And of course there is no right or wrong in philosophy.
  - dgb23 3y ago
    I fully agree. It’s an interesting trade off that is worth thinking about.
38 3y ago
> Most anything in software can easily end up Turing-complete though. not really, if you actually pay attention when youre designing the type system: https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf
- insanitybit 3y ago
  "if you actually pay attention" or, in other words, if you produce novel research into the area that's worthy of publishing, and noting that this is only just the start and has its own limitations: > The cost is that of requiring a whole program analysis and disallowing programs that would result in infinite instantiations (Section 5.3). Clearly, this is the beginning of the story, not the end.
  - deleted 3y ago
    [deleted]
- bhouston 3y ago
  My experience with Turing-completeness in any custom DSL or similar is that you will generally get Turing-complete systems unless you work really really hard to avoid them. And it only takes one wrong move by anything anywhere in the system, and you'll end up with Turing-completeness. Instead of trying to avoid Turing-completeness, just expect it, embrace it and instead deal with its consequences to contain the fallout.
  - 38 3y ago
    > Instead of trying to avoid Turing-completeness, just expect it, embrace it and instead deal with its consequences to contain the fallout. this seems like such a cop out. its like saying "oh failure is a given, so don't even try to succeed". at least currently, Go generics are NOT Turing complete. the generics were designed in part specifically to avoid that. so just because Rust (and others) failed, doesn't mean its impossible.
    - bhouston 3y ago
egl2021 3y ago
"It isn't that high of a bar unfortunately." --> "It isn't that high of a bar."

dgb23 3y ago

The point is that Zig basically circumvents issues surrounding that, by introducing "comptime", where you can just write regular Zig to achieve the same things. The article showcases a nice example of having this very direct power. But it really comes up more often than you think as soon as you actually have it. It's easy in Zig to allocate precisely based on computed values and then have the sizes as part of your types etc. It all falls out of some simple ideas and it's all just regular Zig code. "Types in Zig are values of the type type" from: https://ziglearn.org/chapter-1/ https://ziglearn.org/chapter-1/ So instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs.

bhouston 3y ago
Here is a really good link that shows the power of Zig's comptime: https://kristoff.it/blog/what-is-zig-comptime/ https://kristoff.it/blog/what-is-zig-comptime/
littlestymaar 3y ago
The problem is that it ends up being dynamically-typed, like C++ templates. See: https://nitter.net/pcwalton/status/1369114008045772804 https://nitter.net/pcwalton/status/1369114008045772804 > So instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs. Well maybe in theory, but the current state of Zig is that it makes it hard to write programs no matter how correct because the compiler keeps crashing ¯\_(ツ)_/¯
- wredue 3y ago
  What are you talking about? The tagged versions are usually quite stable and also plan bug fix follow ups. If you follow master, you’ll occasionally run in to crashes, which is true of any developing language. If you don’t want that, follow tagged versions.
chrismorgan 3y ago
I am certainly sometimes envious of comptime and what it makes practical, but it’s worth noting that it results in dynamically-typed generics, whereas Rust goes for statically-typed generics, which is in keeping with its goals. There are some significant general maintainability improvements in statically-typed generics; when you use dynamic generics, subtle changes in one place can cause obscure compile errors in a completely different and seemingly unrelated place (commonly called post-monomorphisation errors); this doesn’t happen with static generics. So… I’m not sold on your wording that it’s circumventing issues, as it’s choosing a different set of trade-offs. In shedding types-are-a-language-of-their-own, you also shed confidence about what’s a breaking change, and make call sites more fragile. Decide for yourself whether it’s worth it.
- convolvatron 3y ago
  is there anything fundamental about using the same language at compile time to generate fully static typing that is boiled away? I don't know, but it doesn't seem so?
- dgb23 3y ago
  I'm still in the honeymoon phase with this language and learning, but I agree it's a trade off. For example your LSP isn't going to help you as much while you edit code. However being able to express arbitrary compile time constraints and pre-compute stuff without having to go through a code generation tool is really powerful. You can actually use all the knowledge you have ahead of time as long as you can express it in Zig. So far it seems like Zig is carving out a very strong niche for itself.
- anonymoushn 3y ago
  What do you mean by dynamically-typed generics and statically typed generics here? I've looked up "post-monomorphization errors" and found some things about assertions about generic types failing because of the choices made by the user who passed in types or constants that do not work with the generic code. It seems like Zig libraries have the option of generating the errors at the right place if they place their assertions in the function that returns the type to the user, but they also have the option of generating the errors in the wrong place if they place their assertions in methods of the type. > So… I’m not sold on your wording that it’s circumventing issues, as it’s choosing a different set of trade-offs. In shedding types-are-a-language-of-their-own, you also shed confidence about what’s a breaking change, and make call sites more fragile. Decide for yourself whether it’s worth it. Client code can just look at all the members of all the structs so there's not really much hope for enforcing that changes cannot break any client code using compiler-adjacent tooling.
ksec 3y ago
>instead of making it hard to write incorrect programs, Zig makes it easy to write correct programs. Or May be rephrasing it ( To avoid the word "instead" which may anger Rust supporters ); Rust Makes it hard to write incorrect programs, Zig makes it easy to write correct programs. I think this single sentence captures the philosophical difference between Rust and Zig. And of course there is no right or wrong in philosophy.
- dgb23 3y ago
  I fully agree. It’s an interesting trade off that is worth thinking about.

38 3y ago

> Most anything in software can easily end up Turing-complete though. not really, if you actually pay attention when youre designing the type system: https://arxiv.org/pdf/2005.11710.pdf https://arxiv.org/pdf/2005.11710.pdf

insanitybit 3y ago
"if you actually pay attention" or, in other words, if you produce novel research into the area that's worthy of publishing, and noting that this is only just the start and has its own limitations: > The cost is that of requiring a whole program analysis and disallowing programs that would result in infinite instantiations (Section 5.3). Clearly, this is the beginning of the story, not the end.
- deleted 3y ago
  [deleted]
bhouston 3y ago
My experience with Turing-completeness in any custom DSL or similar is that you will generally get Turing-complete systems unless you work really really hard to avoid them. And it only takes one wrong move by anything anywhere in the system, and you'll end up with Turing-completeness. Instead of trying to avoid Turing-completeness, just expect it, embrace it and instead deal with its consequences to contain the fallout.
- 38 3y ago
  > Instead of trying to avoid Turing-completeness, just expect it, embrace it and instead deal with its consequences to contain the fallout. this seems like such a cop out. its like saying "oh failure is a given, so don't even try to succeed". at least currently, Go generics are NOT Turing complete. the generics were designed in part specifically to avoid that. so just because Rust (and others) failed, doesn't mean its impossible.
  - bhouston 3y ago

egl2021 3y ago

"It isn't that high of a bar unfortunately." --> "It isn't that high of a bar."