That being said, I find the error handling via multiple return values + or_return pretty nifty, and the vendored libraries give it a very “batteries-included” feel.

For example, you can render hardware accelerated graphics and de/serialize JSON without downloading any packages.

However, my point with linking this library was just to demonstrate that accessibility and IMGUI are not inherently incompatible.

My point with the example I created above was that you don't have to trade away battery life in order to take advantage of the IMGUI paradigm. My secondary point was also to implement the "interactive rectangles" optimization I mentioned above (which only took a few lines of code).

While I agree with you that there are definitely tradeoffs, I don't think the aforementioned ones are necessary.

https://github.com/goodpaul6/imgui-power-saving-example

Of course this is a greatly simplified example, but I can see this extending to any GUI widget that can be represented with a (hierarchy) of rectangles.

  while (running) {
    event := get_next_event()
    process_event(event)
    repaint()
  }

IMGUI is just a different API design IMO.

I suspect that even BeReal will do this at some point unless they pivot to e.g. Cohost’s [1] model of paying a monthly fee.

Unfortunately achieving the network effects required for a successful social media app is at odds with the friction involved in paying for a subscription service. As such, “cool” apps like BeReal don’t stay cool for very long IMO.

[1] cohost.org

Not sure if this supports your point. Lots of compilers emit runtime type information, e.g. Golang, Java.

As such, the "array" type is just an opaque type exposed via the C binding API. Given that there are no generics at the moment, this array API works with "any" values (similar to "any" in e.g. TypeScript).

[0] https://github.com/goodpaul6/Tiny