4 ms·

IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the pa

by awesan 7mo ago

IMO rust started at this from the wrong direction. Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic, cannot allocate unless the developer wrote the allocation, etc. Rust instead has all these implicit things that just happen, and now needs ways to specify that in particular cases, it doesn't.

tialaramex 7mo ago
Huh? It seems to me that in these respects the two languages are almost identical. If I tell the program to panic, it panics, and if I divide an integer by zero it... panics and either those are both "the developer wrote the thing" or neither is.
- awesan 7mo ago
  In Zig, dividing by 0 does not panic unless you decide that it should or go out of your way to use unsafe primitives [1]. Same for trying to allocate more memory than is available. The general difference is as follows (IMO): Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such as Odin, Jai, etc.) allow anything by default, but surface the fact that issues can occur in its API design. In practice the result is the same, but Rust needs to be much more complex both to do the proving and to allow the developers to ignore its rules. [1]: https://ziglang.org/documentation/0.15.2/std/#std.math.divExact https://ziglang.org/documentation/0.15.2/std/#std.math.divEx...
  - ivanbakel 7mo ago
    Could you clarify what's going on in the Zig docs[0], then? My reading of them is that Zig definitely allows you to try to divide by 0 in a way the compiler doesn't catch, and this results in a panic at runtime. I'd be interested if this weren't true, since the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0. It doesn't look like Zig does either of these. [0]: https://ziglang.org/documentation/master/#Division-by-Zero https://ziglang.org/documentation/master/#Division-by-Zero
    - Turskarama 7mo ago
      More specifically, Zig will return an error type from the division and if this isn't handled THEN it will panic, kind of like an exception except it can be handled with proper pattern matching.
      - ben-schaaf 7mo ago
        I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.
        Turskarama 7mo ago
        Actually you're right, I was going by the source code which was in the link of the comment you replied to, but I missed that that was specifically for divExact and not just primitive division.
        MaulingMonkey 7mo ago
        (Rust has a similar fn: https://doc.rust-lang.org/std/primitive.isize.html#method.checked_div https://doc.rust-lang.org/std/primitive.isize.html#method.ch... )
    - thomasmg 7mo ago
      > the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0. I don't think it's very cumbersome if the compiler checks if the divisor could be zero. Some programming languages (Kotlin, Swift, Rust, Typescript...) already do something similar for possible null pointer access: they require that you add a check "if s == null" before the access. The same can be done for division (and remainder / modulo). In my own programming language, this is what I do: you can not have a division by zero at runtime, because the compiler does not allow it [1]. In my experience, integer division by a variable is not all that common in reality. (And floating point division does not panic, and integer division by a non-zero constant doesn't panic either). If needed, one could use a static function that returns 0 or panics or whatever is best. [1] https://github.com/thomasmueller/bau-lang/blob/main/README.md#division-by-zero https://github.com/thomasmueller/bau-lang/blob/main/README.m...
IshKebab 7mo ago
The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.
- OptionOfT 7mo ago
  What about doing something that Java does with the throws keyword? Would that make the checking easier?
  - bigfishrunning 7mo ago
    I think that's exactly what's being asked for here (via the "panic effect" that the article refers to) although, I think i'd prefer a "doesn't panic" effect just to keep backwards compatibility (allowing functions to panic by default)
    - 3836293648 7mo ago
      Or effect aliases. But given that it's strictly a syntactic transformation it seems like make the wrong default today, fix it in the next edition. (Editions come with tools to update syntax changes)
  - mananaysiempre 7mo ago
    Something like that, except you probably also want to be able to express things like “whatever the callback I’m passed can throw, I can throw all of that and also FooException”. And correctly handle the cases when the callback can throw FooException itself, and when one of the potential exceptions is dependent on a type parameter, and you see how this becomes a whole thing when done properly. But it’s doable.
- throwaw3y 7mo ago
  "Panic-free" labels are so difficult to ascribe without being misleading because temporal memory effects can cause panics. Pusher too much onto your stack because the function happened to be preceded by a ton of other stack allocations? Crash. Heap too full and malloc failed? Crash. These things can happen from user input, so labelling a function no_panic just because it doesn't do any unchecked indexing can dangerously mislead readers into thinking code can't crash when it can.
School-Cotton 7mo ago
> Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic The zig compiler can’t possibly guarantee this without knowing which parts of the code were written by you and which by other people (which is impossible). So really it’s not “the developer” wrote the thing that does the panic, it’s “some developer” wrote it. And how is that different from rust?

by awesan 7mo ago

tialaramex 7mo ago

Huh? It seems to me that in these respects the two languages are almost identical. If I tell the program to panic, it panics, and if I divide an integer by zero it... panics and either those are both "the developer wrote the thing" or neither is.

awesan 7mo ago
In Zig, dividing by 0 does not panic unless you decide that it should or go out of your way to use unsafe primitives [1]. Same for trying to allocate more memory than is available. The general difference is as follows (IMO): Rust tries to prevent developers from doing bad things, then has to include ways to avoid these checks for cases where it cannot prove that bad things are actually OK. Zig (and many others such as Odin, Jai, etc.) allow anything by default, but surface the fact that issues can occur in its API design. In practice the result is the same, but Rust needs to be much more complex both to do the proving and to allow the developers to ignore its rules. [1]: https://ziglang.org/documentation/0.15.2/std/#std.math.divExact https://ziglang.org/documentation/0.15.2/std/#std.math.divEx...
- ivanbakel 7mo ago
  Could you clarify what's going on in the Zig docs[0], then? My reading of them is that Zig definitely allows you to try to divide by 0 in a way the compiler doesn't catch, and this results in a panic at runtime. I'd be interested if this weren't true, since the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0. It doesn't look like Zig does either of these. [0]: https://ziglang.org/documentation/master/#Division-by-Zero https://ziglang.org/documentation/master/#Division-by-Zero
  - Turskarama 7mo ago
    More specifically, Zig will return an error type from the division and if this isn't handled THEN it will panic, kind of like an exception except it can be handled with proper pattern matching.
    - ben-schaaf 7mo ago
      I can't find anything related to division returning an error type. Looking at std.math.divExact, rem, mod, add, sub, etc. it looks to me like you're expected to use these if you don't want to panic.
      - Turskarama 7mo ago
        Actually you're right, I was going by the source code which was in the link of the comment you replied to, but I missed that that was specifically for divExact and not just primitive division.
        MaulingMonkey 7mo ago
        (Rust has a similar fn: https://doc.rust-lang.org/std/primitive.isize.html#method.checked_div https://doc.rust-lang.org/std/primitive.isize.html#method.ch... )
  - thomasmg 7mo ago
    > the only feasible compiler solutions to preventing division-by-0 errors are either: defining the behaviour, which always ends up surprising people later on, or; incredibly cumbersome or underperformant type systems/analyses which ensure that denominators are never 0. I don't think it's very cumbersome if the compiler checks if the divisor could be zero. Some programming languages (Kotlin, Swift, Rust, Typescript...) already do something similar for possible null pointer access: they require that you add a check "if s == null" before the access. The same can be done for division (and remainder / modulo). In my own programming language, this is what I do: you can not have a division by zero at runtime, because the compiler does not allow it [1]. In my experience, integer division by a variable is not all that common in reality. (And floating point division does not panic, and integer division by a non-zero constant doesn't panic either). If needed, one could use a static function that returns 0 or panics or whatever is best. [1] https://github.com/thomasmueller/bau-lang/blob/main/README.md#division-by-zero https://github.com/thomasmueller/bau-lang/blob/main/README.m...

IshKebab 7mo ago

The problem isn't implicit things happening. He's talking about this problem. Can this code panic? foo(); You can't easily answer that in Rust or Zig. In both cases you have to walk the entire call graph of the function (which could be arbitrarily large) and check for panics. It's not feasible to do by hand. The compiler could do it though.

OptionOfT 7mo ago
What about doing something that Java does with the throws keyword? Would that make the checking easier?
- bigfishrunning 7mo ago
  I think that's exactly what's being asked for here (via the "panic effect" that the article refers to) although, I think i'd prefer a "doesn't panic" effect just to keep backwards compatibility (allowing functions to panic by default)
  - 3836293648 7mo ago
    Or effect aliases. But given that it's strictly a syntactic transformation it seems like make the wrong default today, fix it in the next edition. (Editions come with tools to update syntax changes)
- mananaysiempre 7mo ago
  Something like that, except you probably also want to be able to express things like “whatever the callback I’m passed can throw, I can throw all of that and also FooException”. And correctly handle the cases when the callback can throw FooException itself, and when one of the potential exceptions is dependent on a type parameter, and you see how this becomes a whole thing when done properly. But it’s doable.
throwaw3y 7mo ago
"Panic-free" labels are so difficult to ascribe without being misleading because temporal memory effects can cause panics. Pusher too much onto your stack because the function happened to be preceded by a ton of other stack allocations? Crash. Heap too full and malloc failed? Crash. These things can happen from user input, so labelling a function no_panic just because it doesn't do any unchecked indexing can dangerously mislead readers into thinking code can't crash when it can.

School-Cotton 7mo ago

> Comparing to something like zig which just cannot panic unless the developer wrote the thing that does the panic The zig compiler can’t possibly guarantee this without knowing which parts of the code were written by you and which by other people (which is impossible). So really it’s not “the developer” wrote the thing that does the panic, it’s “some developer” wrote it. And how is that different from rust?