[HN Gopher] Error ABI
       ___________________________________________________________________
        
       Error ABI
        
       Author : todsacerdoti
       Score  : 51 points
       Date   : 2025-11-10 02:31 UTC (20 hours ago)
        
 (HTM) web link (matklad.github.io)
 (TXT) w3m dump (matklad.github.io)
        
       | stmw wrote:
       | I'm simultaneously amused and concerned by the recurring
       | proposals for Rust to add
       | 
       | 1. exceptions 2. garbage collection
       | 
       | Sometimes in slightly modified forms or names, and often with
       | very well-articulated, technically competent justifications (as
       | is the case here).
       | 
       | Just say no!
        
         | necubi wrote:
         | This doesn't have anything to do with exceptions, and the
         | context appears to be Zig, not Rust.
         | 
         | The article is about how we represent errors not their control
         | flow (i.e., exceptions).
        
           | stmw wrote:
           | Fair point re: Zig vs Rust, but my larger point was about
           | exceptions by any other name, in the linked article:
           | 
           | "Instead, when returning an error, rather than jumping to the
           | return address, we look it up in the side table to find a
           | corresponding error recovery address, and jump to that. Stack
           | unwinding!
           | 
           | The bold claim is that unwinding is the optimal thing to do!
           | .."
        
             | necubi wrote:
             | If by "exceptions" you're talking about stack unwinding (as
             | opposed to the language-level control flow constructs like
             | throw/catch) then Rust has always had that with panics and
             | panic=unwind.
        
               | stmw wrote:
               | I am talking about the wider category that includes stack
               | unwinding as an error handling pattern for errors outside
               | of catastrophic. T
               | 
               | My opinion (which one need not approve of) is that it
               | asymptotically approaches the language-level control flow
               | constructs.
        
         | MaulingMonkey wrote:
         | Rust already has exceptions (when panic=unwind)
        
           | stmw wrote:
           | But it's not really encouraged as it is in C++ or Java.
           | Quoting Rustonomicon: "There is an API called catch_unwind
           | that enables catching a panic without spawning a thread.
           | Still, we would encourage you to only do this sparingly. In
           | particular, Rust's current unwinding implementation is
           | heavily optimized for the "doesn't unwind" case. If a program
           | doesn't unwind, there should be no runtime cost for the
           | program being ready to unwind. As a consequence, actually
           | unwinding will be more expensive than in e.g. Java. Don't
           | build your programs to unwind under normal circumstances.
           | Ideally, you should only panic for programming errors or
           | extreme problems."
        
         | kbolino wrote:
         | But the argument is _not_ about adding exceptions to the
         | language.
         | 
         | It's about borrowing a technique from languages that do have
         | exceptions (and Rust's own panic unwinding) to implement Rust's
         | existing error handling without making any changes to the
         | language.
        
       | fleventynine wrote:
       | Rigid ABIs aren't necessary for statically linked programs.
       | Ideally, the compiler would look at the usage of the function in
       | context and figure out an ABI specifically for that function that
       | minimizes unnecessary copies and register churn.
       | 
       | IMHO this is the next logical step in LTO; today we leave a lot
       | of code size and performance on the floor in order to meet some
       | arbitrary ABI.
        
         | layer8 wrote:
         | I would argue that most of today's performance problems in
         | software are unrelated to ABI.
        
           | stmw wrote:
           | I would argue that is largely true because we got the ABIs
           | and the hardware to support them to be highly optimized.
           | Thing slow down very quickly if one gets off that hard-won
           | autobahn of ABI efficiency.
        
       ___________________________________________________________________
       (page generated 2025-11-10 23:00 UTC)