[HN Gopher] The Rust calling convention we deserve (2024)
       ___________________________________________________________________
        
       The Rust calling convention we deserve (2024)
        
       Author : cratermoon
       Score  : 44 points
       Date   : 2026-03-01 17:25 UTC (3 days ago)
        
 (HTM) web link (mcyoung.xyz)
 (TXT) w3m dump (mcyoung.xyz)
        
       | tomhow wrote:
       | Previously:
       | 
       |  _The Rust calling convention we deserve_ -
       | https://news.ycombinator.com/item?id=40081314 - April 2024 (137
       | comments)
        
       | jauntywundrkind wrote:
       | What was the interval of time for Rust having green threads, out
       | of curiosity? How if at all had that affected layout and calling?
        
         | JoshTriplett wrote:
         | Pre-1.0. Rust removed the green-threads runtime prior to
         | stabilization.
         | 
         | I personally think this was one of the most important changes
         | Rust made; without it, Rust would have been _interesting_ but
         | would not have been able to compete directly with C and C++ for
         | systems programming.
        
       | wahern wrote:
       | This reads like word games. The article basically argues for
       | optimizing the calling discipline on a per-function basis, using
       | the function body to guide the optimization. That's not a calling
       | convention and definitely not a standard ABI. What they're
       | arguing for is a kind of static optimization mid-way between
       | targeting a calling convention and inlining. That's not a bad
       | idea on its face, but has nothing at all to do with the C ABI. As
       | to whether it would actually improve anything, frankly, I'm half-
       | surprised compilers don't already do this, i.e. for functions
       | where it's deemed too costly to inline, but which aren't
       | externally visible, and the fact that they don't suggests that
       | maybe there's not much to gain here.
       | 
       | I've yet to read an article criticizing the so-called C ABI that
       | doesn't end up effectively changing the problem statement (in
       | this case, into something utterly incomparable), as opposed to
       | providing a better solution to the same problem. Changing the
       | problem statement is often how you arrive at better solutions
       | overall, but don't try to sell it as something it isn't,
       | insinuating that the pre-existing solution is stupid.
        
         | dmitrygr wrote:
         | > for functions where it's deemed too costly to inline, but
         | which aren't externally visible
         | 
         | in LTO mode, gcc does
        
       ___________________________________________________________________
       (page generated 2026-03-04 23:00 UTC)