5 comments

  • dataflow30 minutes ago
    Can someone explain the part about Diana's $89 dress?
  • wahern2 hours ago
    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&#x27;s not a calling convention and definitely not a standard ABI. What they&#x27;re arguing for is a kind of static optimization mid-way between targeting a calling convention and inlining. That&#x27;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&#x27;m half-surprised compilers don&#x27;t already do this, i.e. for functions where it&#x27;s deemed too costly to inline, but which aren&#x27;t externally visible, and the fact that they don&#x27;t suggests that maybe there&#x27;s not much to gain here.<p>I&#x27;ve yet to read an article criticizing the so-called C ABI that doesn&#x27;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&#x27;t try to sell it as something it isn&#x27;t, insinuating that the pre-existing solution is stupid.
    • dmitrygr1 hour ago
      <p><pre><code> &gt; for functions where it&#x27;s deemed too costly to inline, but which aren&#x27;t externally visible </code></pre> in LTO mode, gcc does
  • jauntywundrkind2 hours ago
    What was the interval of time for Rust having green threads, out of curiosity? How if at all had that affected layout and calling?
    • JoshTriplett2 hours ago
      Pre-1.0. Rust removed the green-threads runtime prior to stabilization.<p>I personally think this was one of the most important changes Rust made; without it, Rust would have been <i>interesting</i> but would not have been able to compete directly with C and C++ for systems programming.
      • irishcoffee4 minutes ago
        &gt; without it, Rust would have been interesting<p>Thanks for articulating what I’ve failed to do for a decade.
      • satvikpendem1 hour ago
        Yep, it would&#x27;ve just been another OCaml with C style syntax.
        • JoshTriplett1 hour ago
          Or another Go, with a mandatory runtime, which would have been a useful language but not something you&#x27;d add to a production OS kernel or firmware or similar.
          • satvikpendem1 hour ago
            I wonder if we&#x27;d have eventually saw something like Nim, which has optional green thread concurrency and a garbage collector. Rust does not have these currently right? At least I haven&#x27;t heard of them.
            • JoshTriplett34 minutes ago
              Some of Rust&#x27;s async runtimes seem pretty similar to &quot;optional green threads&quot;. There&#x27;s no garbage collection; you can get something <i>like</i> a reference-counted GC by using Arc everywhere, but it&#x27;s neither automatic nor universal.<p>Would we have gotten to &quot;optional&quot;? Maybe! But it&#x27;s hard to predict the counterfactual, especially when substantial success usually has components of <i>both</i> design and luck&#x2F;right-place-right-time. Rust hit a sweet spot, and it&#x27;s not clear how a different history of Rust would have turned out.
  • tomhow2 hours ago
    Previously:<p><i>The Rust calling convention we deserve</i> - <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40081314">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40081314</a> - April 2024 (137 comments)