Charly Coste 馃嚝馃嚪
@Changaco@mastodon.cloud  路  activity timestamp 2 months ago

Today I realized #Go and #Rust both have panics instead of exceptions and both originate from the second half of the 2000s.

These facts are now mentioned in https://gato-lang.dev/

If you have experience with Go or Rust, I'm interested in your thoughts on the lack of exceptions in these languages. It looks to me like an attempt to simplify things that eventually backfired, as evidenced for example by https://www.crowdstrike.com/en-us/blog/dealing-with-out-of-memory-conditions-in-rust/

#ProgrammingLanguages
Micha艂 Fita
@michalfita@mastodon.social replied  路  activity timestamp 2 months ago
@Changaco In non-garbage collected languages like #Rust or C++ the problem with exceptions (and panic is kind of exception with limited options for handling) is that the stack unwinding is non-deterministic and code heavy. So in contexts like embedded systems, very problematic (that's why on embedded we turn off exceptions in C++). With handling errors, the cost is explicit in the code.

#C++23 introduced `std::expected<>` for that reason, but SL doesn't use it yet for anything.
Kornel
@kornel@mastodon.social replied  路  activity timestamp 2 months ago
@Changaco The OOM handling situation in Rust is not caused by panics, and the problem is limited to the standard library, not the language.

It was a conscious design decision to just give up and not even bother to recover from OOM, because Linux has overcommit which makes OOM practically impossible to observe. It makes C malloc() interface broken and checking futile, because it doesn't fail on allocation, only sometime later when you write to some bytes to RAM that happen to cause page faults.
Bobulous :rust: :codeberg:
@bobulous@fosstodon.org replied  路  activity timestamp 2 months ago
@Changaco If you're writing a library in Rust then you should never allow your code to panic, you should instead have fallible functions return the `Result<T, E>` container and allow the client (application) code to decide how to handle a Result which contains an error instead of a successful payload.

I have to say I prefer this model to that of exceptions (and that's based on years of experience in Java).
Charly Coste 馃嚝馃嚪
@Changaco@mastodon.cloud replied  路  activity timestamp 2 months ago
@bobulous Panics exist because explicitly handling all possible errors is considered impractical (i.e. unacceptably verbose).

In a language like #Rust, a simple division can cause a panic (because the language design doesn't enable the compiler to detect all possible divisions by zero), any function call can cause a panic (because the compiler doesn't prevent stack overflows), and when running inside a virtual memory space any write to a new memory page can cause a panic.