Skip to main content

I can't stop wondering if, to truly meet my goals for the #AccessKit project (https://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/?

GitHub - AccessKit/accesskit: UI accessibility infrastructure across platforms and programming languages

UI accessibility infrastructure across platforms and programming languages - GitHub - AccessKit/accesskit: UI accessibility infrastructure across platforms and programming languages
GitHub
#accesskit
in reply to Matt Campbell

Matt Campbell
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

Matt Campbell
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. https://fosstodon.org/@drewdevault/111608733376671155 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/?
@Drew DeVault
in reply to Matt Campbell

Matt Campbell
Matt Campbell
• •
So, I don't have time to do this right now, but maybe someone should start a parallel project to translate AccessKit into C. I wouldn't propose discontinuing the Rust project, because people are using it, and those users probably wouldn't want to bring in a dependenty on a C library. Damned if you do, damned if you don't. 4/?
in reply to Matt Campbell

Leonard de Ruijter
Leonard de Ruijter
• •
I wonder if you don't see it a bit too negatively now. I guess the problem of having the Rust compiler as a dependency as well as having the ability to bundle accesskit with something like Dear ImGui kan be solved just fine. Just provide precompiled binaries for every platform and provide the C header with it.
in reply to Leonard de Ruijter

Matt Campbell
Matt Campbell
• •
@leonardder Yeah, our CI already produces pre-compiled static and shared libraries for the C API, for Windows (x86, x64, and ARM64), macOS (x64 and ARM64), and Linux (x64 only so far). I doubt that Dear ImGui would want to bundle those though, especially as a mandatory dependency.
@Leonard de Ruijter
in reply to Matt Campbell

Leonard de Ruijter
Leonard de Ruijter
• •
Unlikely, but I don't see how that would be different with a C++ version of accesskit, relying pretty heavily on platform adapters. Not to mention the headaches and amount of boiler plate stuff that's necessary to have proper COM interop in C++ to support UIA for example.
in reply to Leonard de Ruijter

Matt Campbell
Matt Campbell
• •
@leonardder A C++ version of AccessKit, or a C version for that matter, could in principle be a header-file-only library.
@Leonard de Ruijter
in reply to Leonard de Ruijter

Leonard de Ruijter
Leonard de Ruijter
• •
Of course I'm exaggerating a bit, but choosing C++ will saddle you with other frustrations in due course.
in reply to Matt Campbell

Jason J.G. White
Jason J.G. White
• •
This raises the unrelated but similar question of the GNOME project's dependency policy and the choice of implementation language for that work. Also, for the IPC effort, there might be something to learn from PipeWire. If I remember correctly, PipeWire plans to transfer the audio/video data across the network as well as between local processes.
in reply to Matt Campbell

Nelson Chu Pavlosky
Nelson Chu Pavlosky
• •

One area where Rust may have an advantage is in selling to governments, if they mandate or seem likely to mandate memory safe languages: https://steveklabnik.com/writing/memory-safety-is-a-red-herring

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.

Memory Safety is a Red Herring

steveklabnik.com
in reply to Matt Campbell

Drew DeVault
Drew DeVault
• •

I don't think that my shitpost ought to be the sole inspiration for your desire to rewrite-it-not-in-rust

Micro-optimizing which languages we choose for software projects on the basis of climate change is not productive, unless the language you choose is some Ethereum shit or whatever. There are better ways to address environmental goals.

Matt Campbell reshared this.

in reply to Drew DeVault

Drew DeVault
Drew DeVault
• •
if rust is saving you time and making the software better, keep using it imho.
in reply to Drew DeVault

Matt Campbell
Matt Campbell
• •
@drewdevault It's definitely saving me time, in that it attracted a collaborator who directly told me that he wouldn't have attempted to work on such a project in C or C++.
@Drew DeVault
in reply to Drew DeVault

Drew DeVault
Drew DeVault
• •
in terms of how the Rust community should take this into account, it's more important not to make megaprojects which burn millions of CI minutes on rebuilding the toolchain with rustup and running some giant test matrix on some fossil-fuel powered cloud
in reply to Drew DeVault

Matt Campbell
Matt Campbell
• •
@drewdevault Yeah. I've already taken some steps to reduce AccessKit's compile time, and I'm thinking of moving the CI from GitHub Actions to something self-hosted (not Sourcehut CI, or at least not solely that, because we have to do CI for Windows and Mac).
@Drew DeVault
in reply to Matt Campbell

Drew 🐘
Drew 🐘
• •

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.

in reply to Matt Campbell

janet
janet
• •
My personal take is that I don't believe that Rust is the end-all language, and that the way it injects itself will cause a "Rewrite in X" of the next big language. But personally I think Rust has set in stone a lot of key points that _must_ be addressed before a modern *systems* language is used by most and has momentum moved over from Rust. Memory safety is one, ergonomics, compiler friendliness, and type safety are others.
⇧