I can't stop wondering if, to truly meet my goals for the #AccessKit project (github.com/AccessKit/accesskit), it will be necessary to rewrite it as a C library. Not a Rust library with a C API, but actually in C. I've had doubts before; you'd think the question would be settled by now. But two things prompted me to think about this again. 1/?
in reply to Matt Campbell

First, there was a Hacker News thread yesterday (one of several over the years) about the most popular C++ immediate-mode GUI library, Dear ImGui. I'm happy to say that others brought up accessibility; I didn't have to. But it occurred to me that, while some applications using Dear ImGui may be willing to use AccessKit via the C API, Dear ImGui itself probably wouldn't, because that would make it impossible to just drop a handful of C++ source files into any build system. 2/?
in reply to Matt Campbell

And the other thing making me second-guess my choice of Rust is @drewdevault's recent hot take about Rust being bad for the environment compared to simpler languages, specifically Hare and C. fosstodon.org/@drewdevault/111… Sure, he presented it as an extra spicy hot take, but as far as I can tell, he's not wrong. So if AccessKit in its current form does achieve my goals, it would be introducing the energy-hungry Rust compiler as a dependency into many GUI projects. 3/?
in reply to Matt Campbell

One area where Rust may have an advantage is in selling to governments, if they mandate or seem likely to mandate memory safe languages: steveklabnik.com/writing/memor…

If you want to improve the accessibility of government software (which ought to be accessible by law, but will it be?), it may be the case that writing in Rust is the best future-proofing strategy.

in reply to Matt Campbell

You can produce C ABI dynamic libraries with rust. It takes additional work and there are quirks but the rust toolchain shouldn't haven't to be a direct dependency of AccessKit projects.

On the fundamental trade-off, you might want to consider some projections for (a) the full set of tools required to support the development effort and (b) how often they would need to run. Valgrind, ASAN, fuzzers, et al consume energy as well and they will be run much more often for a C project.

⇧