boringcactus

I’m Job Hunting

2025-10-04T00:00:00Z

My employer’s remote work policies are changing, and Salt Lake City isn’t “commutable distance” from Boston, so I’m looking for a new job. If you’re hiring software developers (remote in the US, or hybrid in Salt Lake City) to work on something that’s prosocial and technically ambitious, let me know.

I’ve done backend, frontend, mobile, devops, internal tooling, release engineering, CI, and more. I’m incredibly flexible, and I learn fast, so if you have a mission I can believe in, I can be effective and comfortable in any role and any language and tech stack.

A 2025 Survey of Rust GUI Libraries

2025-04-13T00:00:00Z

I did this in 2020 and then again in 2021, but I’m in the mood to look around again. Let’s look through Are We GUI Yet? and see what’s up these days.

The task today is to have a text label and an input field that can change the text in the label. In React, for example, this is basically free:

const Demo = () => {
    let [state, setState] = useState("Hello, world!");
    
    return (
        <div>
            <p>{state}</p>
            <input type="text" value={state} onInput={evt => setState(evt.target.value)} />
        </div>
    );
}

Choosing a task this simple means I can actually have a shot at completing this at a reasonable pace (although it took me two weeks), but it also means frameworks that prioritize scaling over initial setup will be at a disadvantage here. If you’ve found this post looking for specific guidance for a project that’s going to be substantially more complicated than this, don’t assume my conclusions are valid in your context.

A few other reasons my context may not match yours:

I’m developing this, like nearly all my personal projects, on Windows. I’m in good company there — per the 2024 Stack Overflow developer survey, “Windows is the most popular operating system for developers, across both personal and professional use” — but for a handful of reasons Windows is an afterthought in a lot of open source development. I find some of those reasons more compelling than others, but for GUI libraries in particular I think avoiding Windows is avoiding success, and if Windows support is lower on your roadmap than trend chasing AI bullshit, you are not serious.
I am checking that the text label can be read out from Windows Narrator. Screen reader accessibility is another frequent afterthought, and it’s not load-bearing for me personally but it’s a lot more important as a matter of principle (and potentially a matter of law, depending on the project).
New in the 2025 version of this exercise: I will be using the Windows Japanese IME to type in the kanji for Tokyo, 東京 (which on my US-layout-emulating keyboard I do with toukyou<Tab><Return>). I don’t speak Japanese (although there are more obscure IMEs that I’m more interested in), and there are a lot of internationalization pieces that a minimal GUI library can reasonably decide to ignore, but if you’ve implemented text fields from scratch and you’re just appending keystrokes to a buffer then you have rejected compatibility with a lot of languages that are more complicated than that.

I’m feeling very slightly more patient this time around, so I’m not going to give up instantly if something takes very slightly more setup than just cargo add, but I’ve got a lot of things to check, so that’s gotta be enough preamble.

I’m writing this in linear order in parallel with my development, so it’s more of a journal than a reference and it probably reads best top to bottom, but if you want a TL;DR or you’re coming back for reference you can skip right to the conclusion or the table.

Azul

Azul is the first beneficiary of my newfound patience: you have to manually download the prebuilt .dll (via a link that doesn’t quite work, or directly off the GitHub release), and the last time I was here I balked at that request. It’s not a great sign that the getting started guide has samples for C++ and Python but not Rust, but there are examples in the repo that aren’t too hard to follow. However, the hello world sample doesn’t actually work if I copy and paste it into my main.rs - it looks like the API has changed somewhat since the latest release.

There’s a bit of a theme of release versioning issues with Azul - following the guide appears to give me version 1.0.0-alpha4, but the only Git tag is 1.0.0-alpha1 and it’s not clear what may have changed between alpha1 and alpha4.

The broader issue, though, is that even if I download the 1.0.0-alpha1 examples off the GitHub release and try to run the same code myself, I am beset with error LNK2019: unresolved external symbol __imp_AzCallbackInfo_getNodeIdOfRootDataset and 47 other unresolved symbols. I made an honest attempt to get Azul working, but it still doesn’t work. I’ll see you in a couple years, Azul.

cacao

Cocoa is some subset of the macOS API; it has Rust bindings named Cacao. I could have sworn that the cocoa/cacao wordplay had been done forever ago in the macOS space, but maybe I just couldn’t fucking read, because the only things I’m able to find are this crate. Unsurprisingly, this does not work on Windows.

core-foundation

Core Foundation is a different subset of the macOS API; it has Rust bindings. Also not useful from Windows.

Crux

Crux is new, and I find it really intriguing. The idea of writing a shared library with business logic and then writing an ideally minimal native UI shell around it is also how Kotlin Multiplatform works (if you adopted it before Compose Multiplatform on iOS was out of alpha, at least), and I’ve been using that at my day job for a year and a half with only a handful of complaints. The initial project setup accurately describes itself as a sharp edge that needs better tooling, but it’s not miserable.

Manually defining the entire shared library interface feels like it would get old fast, but this task is faster. Unfortunately, though, I’m just now processing that Crux doesn’t actually support desktop GUI development, only mobile and web! It’s very interesting that this exists, though, and if my aim today was actually mobile development I’d be very curious if actual Swift bindings solve my Kotlin Multiplatform woes (I suspect that they might).

Hang on, though, this isn’t even a GUI library, the whole point is that you still use the native GUI library directly from each platform, and in fact several of the web examples use libraries that will be coming back later in this very list. I’m not quite certain I agree with listing it on Are We GUI Yet? in the first place, although I guess the current design doesn’t have space for a separate section for non-GUI frameworks that would be useful for GUI applications.

Cushy

Cushy is another new entrant - apparently there’s been a lot of movement in the space in the last four years. The README code snippet has a funny but inconsequential mistake:

// Create a dynamic usize.
let count = Dynamic::new(0_isize);

Maybe one day clippy will be able to detect comments that don’t actually match the code.

The README example actually works (it’s a Christmas miracle!) but it spams stderr with a ton of eyebrow-raising Vulkan/DirectX 12 errors:

2025-04-03T04:20:03.810927Z ERROR wgpu_hal::auxil::dxgi::exception: ID3D12CommandQueue::ExecuteCommandLists: Using ClearRenderTargetView on Command List (0x0000026C511CF250:'Unnamed ID3D12GraphicsCommandList Object'): Resource state (0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]) of resource (0x0000026C510E4EB0:'Unnamed ID3D12Resource Object') (subresource: 0) is invalid for use as a render target.  Expected State Bits (all): 0x4: D3D12_RESOURCE_STATE_RENDER_TARGET, Actual State: 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT], Missing State: 0x4: D3D12_RESOURCE_STATE_RENDER_TARGET. [ EXECUTION ERROR #538: INVALID_SUBRESOURCE_STATE]
2025-04-03T04:20:03.812586Z ERROR wgpu_hal::auxil::dxgi::exception: ID3D12CommandQueue::ExecuteCommandLists: Using IDXGISwapChain::Present on Command List (0x0000026C51057910:'Internal DXGI CommandList'): Resource state (0x4: D3D12_RESOURCE_STATE_RENDER_TARGET) of resource (0x0000026C510E4EB0:'Unnamed ID3D12Resource Object') (subresource: 0) is invalid for use as a PRESENT_SOURCE.  Expected State Bits (all): 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT], Actual State: 0x4: D3D12_RESOURCE_STATE_RENDER_TARGET, Missing State: 0x0: D3D12_RESOURCE_STATE_[COMMON|PRESENT]. [ EXECUTION ERROR #538: INVALID_SUBRESOURCE_STATE]

It’s probably fine, though. The actual application is about as simple as you’d hope it’d be:

let text = Dynamic::new("Hello, world!".to_string());
let label = text.map_each(|text| text.clone());
let text_input = text.into_input();
label.and(text_input).into_rows().run()

Unfortunately, Windows Narrator has no idea what’s inside this window. Kanji input with the IME sorta works, though; I don’t get to see the とうきょう that my toukyou becomes as I type it, but when I press Return I do in fact get the kanji I was expecting.

In IME jargon, turning toukyou into とうきょう is the job of the composer and turning とうきょう into 東京 is the job of the converter, so the composer step is hidden but the converter step works fine.

I’m not sure whether Cushy has done anything in particular to accept IME results in its text input widgets or if the IME just dispatches the selected kanji as though they were typed directly, but I suspect it’s the latter. I know Windows is pretty flexible with how it treats keyboard input — every curly quote in this blog post was hand-curled with WinCompose despite my Markdown renderer almost certainly doing smart quotes automatically — so maybe the IME result is just dispatched as though it’s a direct input of U+6771 CJK Unified Ideograph and then U+4EAC CJK Unified Ideograph. (I had forgotten about Han unification; I’m curious how if at all using the Japanese IME causes the Japanese kanji to be displayed instead of the theoretically-equivalent hanzi/hanja, but I suspect the answer is that it doesn’t, and that scares me.)

CXX-Qt

CXX-Qt is a framework for using the well-established Qt C++ GUI library from Rust. I have been avoiding Qt for years, but it seems like it’s time to stop.

It’s annoying that I have to make an account to install Qt, and it’s very annoying that they want my name and location before they’ll let me download it. I was right to hate this the whole time.

Their sample code will not run due to 1058 linker errors:

   Creating library C:\Users\Melody\Projects\misc\2025\rust-gui-survey\target\debug\deps\cxx_qt_demo.lib and object C:\Users\Melody\Projects\misc\2025\rust-gui-survey\target\debug\deps\cxx_qt_demo.exp␍
0245cd17b2ba3548-com_kdab_cxx_qt_demo_plugin_init.o : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl qRegisterStaticPluginFunction(struct QStaticPlugin)" (__imp_?qRegisterStaticPluginFunction@@YAXUQStaticPlugin@@@Z) referenced in function "public: __cdecl Staticcom_kdab_cxx_qt_demo_pluginPluginInstance::Staticcom_kdab_cxx_qt_demo_pluginPluginInstance(void)" (??0Staticcom_kdab_cxx_qt_demo_pluginPluginInstance@@QEAA@XZ)␍
libcxx_qt_lib-c91f193d907e83ae.rlib(badec7f11aadc5df-qcoreapplication.o) : error LNK2001: unresolved external symbol "__declspec(dllimport) void __cdecl qt_assert(char const *,char const *,int)" (__imp_?qt_assert@@YAXPEBD0H@Z)␍
<...>
libcxx_qt-464ae71fe424547a.rlib(0602fb52cb66f316-connection.o) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl QMetaObject::Connection::Connection(void)" (__imp_??0Connection@QMetaObject@@QEAA@XZ) referenced in function "class QMetaObject::Connection __cdecl rust::cxxqt1::qmetaobjectconnectionDefault(void)" (?qmetaobjectconnectionDefault@cxxqt1@rust@@YA?AVConnection@QMetaObject@@XZ)␍
libcxx_qt-464ae71fe424547a.rlib(0602fb52cb66f316-connection.o) : error LNK2019: unresolved external symbol "__declspec(dllimport) public: static bool __cdecl QObject::disconnect(class QMetaObject::Connection const &)" (__imp_?disconnect@QObject@@SA_NAEBVConnection@QMetaObject@@@Z) referenced in function "bool __cdecl rust::cxxqt1::qmetaobjectconnectionDisconnect(class QMetaObject::Connection const &)" (?qmetaobjectconnectionDisconnect@cxxqt1@rust@@YA_NAEBVConnection@QMetaObject@@@Z)␍
C:\Users\Melody\Projects\misc\2025\rust-gui-survey\target\debug\deps\cxx_qt_demo.exe : fatal error LNK1120: 1058 unresolved externals␍

I suspect it’s the entire Qt standard library that’s missing. The linker args all look reasonable, though — it’s looking for C:/Qt/6.9.0/mingw_64/lib\libQt6Qml.a, which aside from the mixed slashes is a real path that exists — so I’m not sure what the problem is.

This is a complete bust. There’s a section in the docs about building projects with CMake instead of cargo, but it says it’s optional, and it’s not like I’m desperate for more opportunities to use CMake, so I’m not going to try it.

Dioxus

I think I remember Dioxus as being one of the Rust frontend web dev frameworks; apparently they’ve branched out.

Their tutorial involves building “HotDog - basically Tinder, but for dogs!”, and by that they mean the app lets you swipe through a pile of dog photos and then view the ones you’ve swiped whichever direction is good on. That is not what I would expect “Tinder, but for dogs” to be, but maybe I don’t know what Tinder is.

Apparently the way Dioxus supports desktop development is through WebView2/WebKitGTK, so they haven’t branched very far out. I’m a little bit skeptical that Diet Electron is really the future, but given that Electron is the present, maybe I need to take what I can get. I also have some concerns about leaning this hard into cloning React — React hooks are a fascinating hack to almost build algebraic effects in JS, and it’s not like Rust really has algebraic effects, either, but maybe the real compilation step means they can do a little more magic and make it actually work reasonably. At this scale, though, it’s hard to argue with the results:

let mut text = use_signal(|| "Hello, world!".to_string());
rsx! {
    p { "{text}" }
    input {
        type: "text",
        oninput: move |event| text.set(event.value()),
        value: "{text}"
    }
}

Windows Narrator can even see what the text is, although it feels a little clumsy (it’s saying “Web content region” on its way into the body of the frame). The IME works perfectly, too. I guess there are benefits to letting Chrome-via-Edge-via-WebView2 be responsible for all the UI machinery.

Dioxus did not invent the Diet Electron approach (that was Tauri, whose WebView2/WebKitGTK/macOS things library Dioxus builds its desktop support on), but the Rust-all-the-way-through approach feels like a way better idea than how Tauri works, which I’ll get into once I make it that far through my list. If Diet Electron is really the best thing out there, I may be a little bit sad, but it’s probably possible to use Dioxus for real work without constantly being miserable, and that’s a new high water mark for this blog series.

Dominator

Dominator is a Web-only UI crate, and unlike Dioxus it does not also offer a blessed desktop stack.

egui

egui, and its framework eframe, have been around for a while. The setup process has always been pretty straightforward, which is nice. It’s pretty simple to use, too:

egui::CentralPanel::default().show(ctx, |ui| {
    ui.label(&self.label);
    ui.text_edit_singleline(&mut self.label);
});

Windows Narrator can even see this text! It feels a little janky trying to get Narrator into the text field, though, but maybe that’s just the ceiling of how well Windows Narrator can work, or maybe I’m just holding it wrong and there’s a way to get behavior that feels more intuitive that I just can’t think of.

The default font doesn’t have hiragana or kanji coverage, though, and if I manually load a system font (which requires loading the bytes directly instead of just specifying a system font name, which is suboptimal but probably common), my Tab press to select 東京 as the kanji for とうきょう gets eaten by egui and I’m stuck with the hiragana forever.

I prefer this default appearance to Cushy’s or Dioxus’s, although it’s probably possible to make anything look like anything if you try hard and believe in yourself. I’m not sure I love immediate mode on principle, although at this scale it extremely doesn’t matter.

Digression: “Immediate mode” and “retained mode”

In an “immediate mode” GUI, your code that builds your widgets runs every frame, and the widgets don’t really exist per se. This can be simpler to work with — I can create the label with &self.label and the text edit widget with &mut self.label and there’s no issue because the label and the text field don’t actually exist at the same time. I think it’s also easier to integrate into a game engine, since the GUI library doesn’t need as much control over communication with the GPU; that doesn’t matter for me today, but it may matter for you.

“Retained mode” is the opposite of that, where the code that builds the widgets only runs when it has something to do, and the widgets keep existing after they’re created. My understanding is that this can have better performance since you aren’t rebuilding your entire UI from scratch every frame, although presumably serious immediate mode libraries do some amount of caching under the hood so you aren’t actually rebuilding your entire UI from scratch every frame. I’m not sure how much of a difference it actually makes; it would be impossible to tell with anything this small.

The fact that it’s possible to render your UI yourself and still have real accessibility support is definitely a good thing, and if it weren’t for the weird IME issues this would be perfect. If you don’t need IME support and you want better styles out of the box or an immediate mode library you can plug into your existing game engine, egui seems like a perfectly reasonable choice, and that IME issue will probably get fixed eventually.

Floem

Floem is the UI framework developed for Lapce, the cooler VSCode-but-in-Rust IDE. I haven’t used Lapce in a while — several years ago when I last checked, its support for non-Rust languages was pretty weak, and I don’t actually prefer VSCode-style lightweight IDEs anyway (I pay for the JetBrains suite despite not doing enough personal development to justify that expense) — but everything that exists and is good enough for me once existed and was not. It’s cool that it exists; let’s see if their UI framework is any good.

Getting from zero to today’s sample is pretty straightforward:

let label = create_rw_signal("Hello, world!".to_owned());
(
    dyn_view(move || label),
    text_input(label),
).style(|s| s.flex_col())

Windows Narrator can’t see any of this text, and the IME won’t even start, I’m stuck with “toukyou” forever.

Building layouts out of tuples feels a little bit weird — you can only have up to 16 widgets directly within a container at once, due to tuple generics in Rust being still obviously incomplete after 11 years and counting — but it’s probably better than Cushy’s .and(). The complete lack of accessibility or IME support is the real issue, though. Maybe one day they’ll fix it, but for now, this is no good.

fltk

FLTK is a C++ library with Rust bindings. Conveniently, the Rust bindings offer a bundled feature so I don’t have to figure out how to build FLTK from source on Windows. Unfortunately, FLTK doesn’t appear to have an idea of widgets having an inherent size, and its whole layout subsystem leaves something to be desired:

let app = App::default();
let mut wind = Window::new(100, 100, 400, 300, "Hello from rust");
let mut pack = Pack::default_fill().with_type(PackType::Vertical);
let mut label = Frame::default();
label.set_label("Hello, world!");
let mut input = Input::default();
input.set_value("Hello, world!");
input.set_callback(move |input| label.set_label(&input.value()));
input.set_trigger(CallbackTrigger::Changed);
pack.end();
pack.auto_layout();
wind.end();
wind.show();
app.run().unwrap();

Windows Narrator has no idea what’s going on in here, but I did notice a two-year-stale fltk-accesskit repo under the fltk-rs org, and that works but it requires its own ugly setup (you have to pass it a redundant list of all your widgets, which is tough because I moved one of them into the callback for the other). The IME works perfectly, which I wasn’t expecting.

The main issue here is the layout subsystem, which appears to have no concept of widgets having intrinsic sizes. You can manually position and size everything, or you can use one of the clumsy automatic layouts, but neither of those is particularly satisfying. The fact that adding widgets to containers happens in implicit global state and you have to .end() a container to stop adding items to it is a little bit horrifying, I can’t lie. I don’t like this API design one bit.

flutter_rust_bridge

Flutter is a Google framework for cross-platform UI development, but you use it from Dart. Dart has switch statements and switch expressions with completely different syntax. Dart sucks. Maybe using Flutter from Rust doesn’t suck?

It’s very funny to me that Flutter for Windows claims you absolutely need a 1366x768 display; as an act of spite I will be disabling my primary display and only using my 1024x768 secondary display for the remainder of this section.

Oh god this is cramped, I regret this already.

Flutter hates my MSVC toolchain for some reason, and the Visual Studio installer does not want to be this narrow, but if I tab offscreen or move the window to the side I can still add the right components. Apparently “MSVC v143 - VS 2022 C++ x64/x86 build tools” and “Windows 11 SDK” aren’t good enough, and Flutter absolutely insists on having specifically “MSVC v142 - VS 2019 C++ x64/x86 build tools” and “Windows 10 SDK”.

If I install those, though, flutter doctor still doesn’t think I have them for some reason. It seems like my issue, which flutter doctor failed to detect for some reason, was that I didn’t have the “Desktop development with C++” workload installed in Visual Studio.

Getting flutter_rust_bridge set up is easy once Flutter itself is working, although having to run flutter_rust_bridge_codegen generate explicitly is no good; it can’t hook into the Flutter/Dart build process because the only piece that anything can hook into runs completely outside the Flutter/Dart build process. However, what you actually get with flutter_rust_bridge is the opportunity to write your business logic in Rust and your UI in Dart still. You can write your UI state in Rust if you want, but you still have to define your widgets in Dart:

#[frb(ui_state)]
pub struct RustState {
    pub label: String,
}

impl RustState {
    pub fn new() -> Self {
        Self {
            label: "Hello, world!".to_owned(),
            base_state: Default::default(),
        }
    }

    #[frb(ui_mutation)]
    pub fn set_label(&mut self, label: String) {
        self.label = label;
    }
}

void main() => runRustApp(body: body, state: RustState.new);

Widget body(RustState state) {
  return Column(
    children: [
      Text(state.label),
      TextField(
        controller: TextEditingController(text: state.label),
        onChanged: (text) => state.setLabel(label: text),
      ),
    ],
  );
}

This doesn’t even actually work, though: typing happens in reverse in the input field, because the TextEditingController contains the caret position but keeps getting reset. In pure Flutter, you’d probably solve this by moving the controller into the widget state, but it’s not obvious how to do that here since our widget state is being defined in Rust instead. Windows Narrator appears to be able to see this text, at least, although it feels janky trying to move between the label and the input. The IME sort of works, but for presumably the same TextEditingController reasons, the intermediate states aren’t being cleared as I type in the IME, so the actual value that I’ve entered with toukyou<Tab><Return> is 東京東京東京東京とうきょうとうきょうとうきょとうきょとうｋｙとうｋｙとうｋとうｋとうとうととｔ.

I’d get slightly better functionality if I moved this widget state to Flutter, I’m sure, but then there’d be no Rust code at all. If I wanted to write my UIs in Flutter, I’d just do that. If you want to write your UIs in Flutter and just some business logic in Rust, this might work alright for you, but that is not what I want.

Freya

Per the README, Freya is “a cross-platform GUI library for Rust powered by 🧬 Dioxus and 🎨 Skia.” Evidently, it takes the logic and structure of Dioxus and but renders everything itself instead of using Diet Electron. I did grumble about the Diet Electron-hood of Dioxus, so maybe this is the exact thing I was hoping for all along.

Edit 2025-04-15: I’ve been asked to run this again with the week-old release candidate rather than the year-old latest stable release, and I’ve ignored other year-old latest stable releases so it’s fair to do that here too. Next time, unless I forget to, I’m deciding up front when to use a stable release vs an unstable release vs the main branch.

Freya’s README example uses rsx!() rather than the Dioxus docs’ rsx! {}, and it still feels weird to me that those are interchangeable, but aside from that, the only difference from the Dioxus code is some component names:

let mut text = use_signal(|| "Hello, world!".to_string());
rsx!(
    label { "{text}" }
    Input {
        value: text.read().clone(),
        onchange: move |value| text.set(value),
    }
)

Narrator sees the text label fine, but something’s gone wacky with the text input: Narrator can see that there’s a text input with those bounds on the screen, but it doesn’t seem like it actually knows the contents of the text input. The IME shows up in the corner of the screen, and the provisional states aren’t displayed at all, but the final kanji land correctly in the text input once I accept them from the converter.

There are some drawbacks to rendering things yourself instead of letting Chrome-via-Edge-via-WebView2 do it for you, it seems. Regardless, it’s extremely cool that Dioxus is set up in a way that makes this possible, and it’s extremely cool that someone’s trying to do it. I’m not sure that Freya is quite ready for serious use yet, but it’s definitely promising.

fui

FUI does not have a lot of high-level documentation I can use to figure out what to put here.

The example in the README has drifted from the examples in the code, which I suppose is natural but which is rarely auspicious.

Even less auspicious is that I can’t build fui_system:

qmake.stderr: Project ERROR: Cannot run compiler 'g++'. Output:
===================
===================
Maybe you forgot to setup the environment?

I can find no documentation about how to set up my environment, and if I really need g++ then that’s not great.

GemGui

The last commit to GemGui was two years ago; that’s rarely a good sign.

GemGui leans even further into Diet Electron by actually running your frontend on an HTTP server and by default just opening it in your regular browser. There’s a setting to run it in its own application frame instead, but that appears to have a load-bearing dependency on Python being installed in a way that I currently don’t have it installed. It also looks like you’re only really intended to define the UI elements in HTML and wire up the business logic in Rust.

If I give this a venv and then manually ensure python3 will do the right thing, that isn’t enough, because the Python dependency doesn’t actually work or something. “Embed an HTTP server and then use a Web framework and open your server in the system default browser” is a very boring way to technically claim that you’re doing GUI development.

This repo has four stars on GitHub. Why is it even listed in Are We GUI Yet?

GPUI

GPUI is the UI framework developed for Zed, the other VSCode-but-in-Rust IDE. Are We GUI Yet? links to someone squatting it on crates.io, which is silly.

Remember this piece from the intro?

if Windows support is lower on your roadmap than trend chasing AI bullshit, you are not serious.

Well, that’s Zed. It’s a heavily-LLM-focused IDE with no Windows support. GPUI appears to work alright on Windows, though.

It looks like GPUI doesn’t have a basic text input widget, though; their text input example is over 700 lines of code. It’s possible to shuffle that example around to at least get something that’ll meet the task I’m working on, though.

// this isn’t even the bad part!
div()
    .flex()
    .key_context("TextInput")
    .track_focus(&self.focus_handle(cx))
    .cursor(CursorStyle::IBeam)
    .on_action(cx.listener(Self::backspace))
    .on_action(cx.listener(Self::delete))
    .on_action(cx.listener(Self::left))
    .on_action(cx.listener(Self::right))
    .on_action(cx.listener(Self::select_left))
    .on_action(cx.listener(Self::select_right))
    .on_action(cx.listener(Self::select_all))
    .on_action(cx.listener(Self::home))
    .on_action(cx.listener(Self::end))
    .on_action(cx.listener(Self::show_character_palette))
    .on_action(cx.listener(Self::paste))
    .on_action(cx.listener(Self::cut))
    .on_action(cx.listener(Self::copy))
    .on_mouse_down(MouseButton::Left, cx.listener(Self::on_mouse_down))
    .on_mouse_up(MouseButton::Left, cx.listener(Self::on_mouse_up))
    .on_mouse_up_out(MouseButton::Left, cx.listener(Self::on_mouse_up))
    .on_mouse_move(cx.listener(Self::on_mouse_move))
    .bg(rgb(0xeeeeee))
    .line_height(px(30.))
    .text_size(px(24.))
    .child(
        div()
            .h(px(30. + 4. * 2.))
            .w_full()
            .p(px(4.))
            .bg(white())
            .child(TextElement {
                input: cx.entity().clone(),
            }),
    )

Narrator has no idea what’s going on inside this window (and it’s in good company there). The IME works fine, though.

I’m not sure you’re actually supposed to use GPUI at this stage; the documentation is spotty, the installation is janky, and the standard library is woefully inadequate. But at least you can generate bad code way faster, and clearly that’s enough to get your Series A in. Was inflicting Electron on us all by way of Atom not enough?

GTK 3

UNMAINTAINED Rust bindings for the GTK+ 3 library (use gtk4 instead).

OK then.

GTK 4

GTK is the GNOME toolkit (although apparently that’s not actually what it stands for); it’s got Rust bindings. Conveniently, there are specific installation instructions for Windows. It’s not clear whether or not just downloading the prebuilt binaries would work, and it’d certainly save a lot of time if they would, but I’m going to assume building the binaries myself will be more likely to work. That only took five minutes, astonishingly.

I find it a little bit counterintuitive that the single-line text widget is named Entry, but it does kinda rule that GTK’s property bindings mean I don’t have to keep any state at all:

let label = Label::builder()
    .label("Hello, world!")
    .build();

let entry = Entry::builder()
    .text("Hello, world!")
    .build();

entry
    .bind_property("text", &label, "label")
    .build();

let r#box = Box::builder()
    .orientation(Orientation::Vertical)
    .build();
r#box.append(&label);
r#box.append(&entry);

let window = ApplicationWindow::builder()
    .application(app)
    .title("My GTK App")
    .child(&r#box)
    .build();

window.present();

Not only can Narrator not see this text, it can’t even see the minimize/maximize/close buttons, and that’s not a failure state I had realized was possible. The IME works fine.

You may have noticed that this is not the idiomatic Windows window decoration; these minimize/maximize/close buttons are very GNOMEy, which makes sense but isn’t really what I want. Maybe Adwaita will solve this? For some reason, gvsbuild build libadwaita librsvg (as recommended by the gtk-rs book) is building fucking libsass; not the actually maintained stop-trying-to-make-Dart-happen rewrite dart-sass, but the old and busted last-commit-two-years-ago libsass. rsvg also appears to depend on some yanked crate versions, which is concerning but not my problem today. Well, Adwaita certainly makes it look different:

I’ve got way more drop shadow or something that’s extending the ShareX window capture way beyond the actual boundary of the window, and I’ve got dark mode and a purple emphasis color (which I’m not sure if they’re reading from somewhere or if the default was just picked out by someone with good taste). It still doesn’t look like a Windows window, though, and Adwaita has not magically fixed the accessibility.

Using GTK4 from Rust on Windows works, I guess, but I would have to lower my standards a lot to call this good enough.

Iced

Iced says it’s inspired by Elm, and that’s cool. Elm was your favorite programming language’s favorite programming language. I miss it sometimes.

struct State {
    label: String,
}

impl Default for State {
    fn default() -> Self {
        Self { label: "Hello, world!".to_owned() }
    }
}

impl State {
    fn update(&mut self, message: Message) {
        match message {
            Message::SetLabel(label) => self.label = label
        }
    }

    fn view(&self) -> Column<Message> {
        column![
            text(&self.label),
            text_input("", &self.label)
                .on_input(Message::SetLabel),
        ]
    }
}

#[derive(Clone, Debug)]
enum Message {
    SetLabel(String),
}

Windows Narrator can’t see into this window, and the IME won’t even switch into active mode when I try to switch it into active mode, which may actually be a better failure state than having it just not work.

Apparently System76 is all in on Iced for Pop!_OS’s COSMIC shell, so for their users’ sake I hope accessibility and IME support are actually happening at some point.

imgui

Dear ImGui is a minimalist C++ GUI library with Rust bindings. I will always think of it as being called dear imgui,, even though it hasn’t been canonically spelled that way since 2018; the trailing comma is delightful in an e e cummings sort of way, and they should bring it back.

Unfortunately, since Dear ImGui is designed to be plugged into an existing game engine, starting with it from scratch is a little bit annoying. There’s a downright Linux-desktop-environment number of different ways to use imgui-rs, but apparently “The most tested platform/renderer combination is imgui-glow-renderer + imgui-winit-support + winit”, so that’s what I’ll use. Or at least it would be what I’d use if the examples didn’t all use imgui-glium-renderer instead; that one’s deprecated and it doesn’t appear to work with the latest version of glium but I can’t figure out how to get glow working instead. Open source!

// eliding the 160 lines of glue i copied and pasted without understanding
let mut label = "Hello, world!".to_string();
support::simple_init(file!(), move |_, ui| {
    ui.window("Hello world")
        .size([300.0, 110.0], Condition::FirstUseEver)
        .build(|| {
            ui.text_wrapped(&label);
            ui.input_text("Text", &mut label)
                .build();
        });
});

Windows Narrator can’t see this text, and the IME refuses to activate.

The tiny window within the huge window is hilarious, and it makes sense if you’re actually doing game dev and there’s a game in the rest of the window, but I am not, and the massive white void is not something I would tolerate even in an application I was building solely for myself. If I had a graphics stack picked out already because I was doing game dev, I might not mind the flexibility of supporting what feels like hundreds of different renderers and backends, but since that is not my current situation I very much do mind the flexibility. This is what Sartre meant by being “condemned to freedom”: you have innumerable options available to you, but nobody can rescue you from the responsibility of deciding between them.

digression: the irony you may have noticed

KAS

KAS, the toolKit Abstraction System, is written from scratch in Rust. The tutorials are a bit out of date — some things appear to have been moved around between when the tutorials were written and the most recent stable release — but the examples in the actual repo appear to work. I’m not sure I quite understand how the state management is designed, but after a bit of fumbling I can at least complete the task:

let tree = column![
    format_value!("{}"),
    EditBox::instant_parser(|x: &String| x.clone(), SetLabel),
];

Adapt::new(tree, "Hello, world!".to_string())
    .on_message(|_, label, SetLabel(text)| *label = text)

Narrator can’t see this text, and the IME won’t activate.

The part that confuses me the most is why the EditBox needs to be explicitly told that it’s a String that’s being edited; that seems like it shouldn’t require an explicit declaration. Maybe if the tutorial were up to date it’d be easier to understand. Regardless, it seems like this isn’t really ready for prime time yet.

kittest

kittest is an AccessKit-driven testing library that only supports egui. This is cool, but it’s not in the same category as the sort of thing I’m actually looking for. If I maintained Are We GUI Yet? I’d probably split the list up into separate categories like Are We Web Yet? has.

Leptos

Leptos is a Web frontend framework that is for some reason on the Are We GUI Yet? list. The README has an FAQ about native GUIs that says it’d be possible to build native GUIs with Leptos but it’s not actually supported because it sent the whole codebase into generics hell when they tried it.

lvgl

LVGL, the Lightweight and Versatile Graphics Library, is a C GUI library designed for embedded use; it has Rust bindings that are #![no_std] compatible by default, which is neat if you need that. Unfortunately, after copying around the C header files that define the configuration, I’m getting C compiler errors:

  C:\Users\Melody\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\lvgl-sys-0.6.2\vendor\lv_drivers\display\fbdev.c(13): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory

It seems like the LVGL configuration in the Rust binding samples is not designed to work on Windows, and if I figure out the flag to disable the framebuffer driver I get similar errors about not finding SDL, and if I disable SDL I get bindgen not being able to find libclang, and if I come back after fixing bindgen for a later library I get errors about the linker not finding SDL even though I already turned off SDL. I wouldn’t be surprised if doing desktop development with LVGL is missing the point, though, and I’m holding it wrong by not cross compiling to some slightly cursed embedded Linux target.

Makepad

Makepad is another novel Rust GUI framework. They’re publishing versions to crates.io but not creating Git tags to match those versions, so it’s hard to find the examples that are supposed to work with the published crates, and it’s easier to just point the dependency right at the Git repo so the examples from their main branch will work. They’ve got a macro DSL with no documentation I can find, but a bit of persistence is all it takes to turn the simplest example into something that works:

live_design! {
    import makepad_widgets::base::*;
    import makepad_widgets::theme_desktop_dark::*;
    App =  {
        ui: <Root> {
            main_window = <Window> {
                body = <ScrollXYView> {
                    flow: Down,
                    spacing: 10,
                    align: { x: 0.5, y: 0.5 },
                    label1 = <Label> {
                        text: "Hello, world!",
                    }
                    input1 = <TextInput> {
                        text: "Hello, world!",
                    }
                }
            }
        }
    }
}

impl MatchEvent for App {
    fn handle_actions(&mut self, cx: &mut Cx, actions: &Actions) {
        let input1 = self.ui.text_input(id!(input1));
        if let Some(new_text) = input1.changed(&actions) {
            let label1 = self.ui.label(id!(label1));
            label1.set_text(&new_text);
            label1.redraw(cx);
        }
    }
}

Narrator can’t even see the minimize/maximize/close buttons, much less the content of the window. The IME opens in the corner of the display and has its own wrapper to show the kana while I’m typing, but when I press Enter the kanji get correctly entered into the text field.

I kinda like the Blender aesthetic they’ve got for their stock widgets, but the lack of accessibility support is a downer, and the lack of documentation around the load-bearing DSL may be worse. Maybe the documentation exists and I just can’t find it (they’ve got a Discord server that I’m not joining), but I suspect that Makepad is built for the Makepad team right now, and any utility anyone else can get out of it is coincidental. A lot of projects start in that stage, and most of mine never leave, so that’s not a bad thing, but I do kinda wish Are We GUI Yet? was doing a little more pruning. I’ve been working on this post for almost a week already, and I’m only 58% of the way through the list.

masonry

Masonry is a pure-Rust GUI library that’s the successor to the discontinued Druid framework that I found really impressive early on. It primarily serves as the foundation for Xilem, a kinda Elm-ish kinda SwiftUI-ish framework I’m looking forward to trying once I get all the way down the list.

The last release of Masonry was 11 months ago, and it looks like a lot has changed since then, so I’m going to just point to the main branch directly.

fn on_action(&mut self, ctx: &mut DriverCtx<'_>, _widget_id: WidgetId, action: Action) {
    match action {
        Action::TextChanged(new_text) => {
            ctx.render_root().edit_widget(self.label_id, |mut label| {
                let mut label = label.downcast::<Label>();
                Label::set_text(&mut label, new_text);
            });
        }
        _ => {}
    }
}

let main_widget = Portal::new(
    Flex::column()
        .with_child(Label::new("Hello, world!").with_id(label_id))
        .with_child(Textbox::new("Hello, world!"))
        .with_spacer(VERTICAL_WIDGET_SPACING),
);

Confusingly, Narrator can tell that there’s a text field in here, but it’s wrong about where in the window it is. Kanji input via the IME works, but the default font appears to not support the fullwidth Latin characters that show up in provisional states before the hiragana replace them, so there’s a bit of tofu in the intermediate states ☐, とう☐, and とう☐☐ (after the t, k, and y in toukyou).

I think it’s fair to say that you aren’t really supposed to use Masonry directly, the intent is to build an architecture on top of Masonry. The API ergonomics feel like they match that: you probably could build a nontrivial application directly in Masonry, but I wouldn’t recommend it.

Maycoon

Maycoon is another new from scratch pure Rust framework. It looks like it’s still pretty new. The quick start guide is out of date, but the in-repo examples are still good. (It’s very nice that Cargo defaults to compiling examples as part of running tests.)

Maycoon doesn’t appear to have a text input widget. GPUI didn’t, either, but at least they had an example that involved building one from scratch that I could just copy. Maycoon is too new to be usable for this task.

Pax

Pax is “a revolutionary new canvas for building apps & websites with AI.” 🤮🤮🤮 Shipping a real visual editor for your GUI DSL is a good idea, though, although I think I broke the fancy editor somehow because it stopped responding to anything and started logging a bunch of index out of bounds errors.

Alas, the only desktop target Pax supports is macOS, which is useless to me today. Maybe one day an AI bro who pays for Twitter will contribute something positive to society, but this is not that day.

qmetaobject

QMetaObject is a different approach to Qt bindings than CXX-Qt that appears to try to put even more code into Rust. Unfortunately, it appears to not work nicely with the windows-msvc target, and I don’t appear to have a gcc toolchain installed in a place that it likes.

relm

relm is named after Elm, which is neat. Unfortunately, relm is built on the unmaintained GTK 3 bindings, and even if I did install GTK 3 I’m not certain it would’ve worked, because some load-bearing components are making incorrect UNIX-centric assumptions about how lists of paths work:

  pkg-config exited with status code 1
  > PKG_CONFIG_PATH=C:\Users\Melody\Projects\_resources\gtk-build\gtk\x64\release\lib\pkgconfig PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 pkg-config --libs --cflags gdk-3.0 'gdk-3.0 >= 3.22'
  The system library `gdk-3.0` required by crate `gdk-sys` was not found.
  The file `gdk-3.0.pc` needs to be installed and the PKG_CONFIG_PATH environment variable must contain its parent directory.
  PKG_CONFIG_PATH contains the following:
      - C
      - \Users\Melody\Projects\_resources\gtk-build\gtk\x64\release\lib\pkgconfig

I wonder if there’s a library that’s like relm but built on GTK 4?

Relm4

Relm4 is like relm but built on GTK 4.

view! {
    gtk::Window {
        set_title: Some("Simple app"),
        set_default_size: (300, 100),

        gtk::Box {
            set_orientation: gtk::Orientation::Vertical,
            set_spacing: 5,
            set_margin_all: 5,

            gtk::Label {
                #[watch]
                set_label: &model.label,
                set_margin_all: 5,
            },

            gtk::Entry {
                set_text: &model.label,
                connect_changed[sender] => move |x| sender.input(Msg::SetLabel(x.text().into())),
            },
        }
    }
}

As was the case with the GTK 4 test, Narrator can’t even see the window chrome, and the IME works fine.

This architecture is probably easier to work with at scale than throwing GTK 4 widgets around directly would be, but it also inherits all of the problems of GTK 4 on Windows, of which there are many. Also, that view! macro is (like all Rust macros) really annoying to try to debug if your input is slightly incorrect, which mine was while I tried to figure out how to get connect_changed working. If you love the widgets of GTK 4 but want a nicer architecture, you might like Relm4, but if you are not in that situation, this library has nothing to offer you.

Ribir

Ribir is a bespoke Rust GUI framework that markets itself as being “non-intrusive”, meaning that your GUI components read and write your model objects directly, with no intermediate state layers or constraints on model objects. I’m not sure that this is actually a problem with other frameworks, and I feel like there might be a clearer way to pitch that, but it’s in principle good to be trying to stand out in what I had not quite realized was this crowded of a landscape.

The website docs only have options for 0.2.x and main despite 0.3.0 coming out last August.

Well, I can’t get the pile of macro magic to work correctly, and I’m not sure why. This code looks like it should work, but the text I type into the input field doesn’t actually appear in the label:

App::run(fn_widget! {
    let label = State::value("Hello, world!".to_string());
    let input = @Input { auto_focus: true };
    $input.write().set_text("Hello, world!");
    @Column {
        @Text { text: pipe!($label.to_string()) }
        @ $input {
            on_key_up: move |_| {
                label.set($input.text().to_string());
            },
        }
    }
});

Windows Narrator can’t see any of the text inside this window. The IME opens in a random corner of my monitor, the composer state is hidden, and the default font doesn’t have kanji, but there are two missing-glyph symbols after I confirm from the IME converter, so it seems like the IME technically a little bit works.

If the pitch was that you don’t need to think about the mechanisms of state going into and out of the UI, then the pitch was overstated, because I have an app that looks like it should work but doesn’t because that glue has gone wrong.

Rinf

Rinf is another framework for using Rust for business logic and Flutter for UIs. I want that even less now than I did a few days ago when I wrote the flutter_rust_bridge section.

rui

rui is a Rust GUI library “inspired by SwiftUI”; as someone who’s worked with SwiftUI a lot at my day job, I’m reading that as meaning that this will be almost good but its state management will be clumsy and annoying to work with.

It’s pretty alright at scales this small, though, so that may not be fair:

rui(state(
    || "Hello, world!".to_string(),
    |label, cx| {
        vstack((
            text(&cx[label]).padding(Auto),
            text_editor(label).padding(Auto),
        ))
    },
));

Narrator can’t see this text, and the IME won’t even activate.

I think I kinda like the aesthetic — a strong default font goes a long way towards giving a GUI toolkit a cohesive look — and I also like the lack of load-bearing macros, but I’m of course less wild about the lack of accessibility or IME support.

Slint

Slint is like if Qt had been invented 30 years later. Like Qt, it’s got its own bespoke DSL, and like Qt, the business model is to be GPL and sell exceptions, but unlike Qt, desktop and web exceptions are free and it’s only embedded development that they want you to pay for. There’s no inherent guarantee that that’ll always be the case, but also, doing this stuff right is hard and I am in favor of people getting paid for the work that they do.

This DSL kinda rules, I can’t lie:

export component AppWindow inherits Window {
    property <string> label: "Hello, world!";
    VerticalBox {
        Text {
            text: root.label;
        }

        LineEdit {
            text <=> root.label;
        }
    }
}

Narrator works perfectly. The IME renders all its provisional states as just missing-character glyphs ☐, which makes me think the default font just doesn’t have fullwidth Latin or hiragana or kanji, but once I accept the kanji from the converter I get the actual kanji displaying correctly, so that may actually be a bug and not just a font selection issue.

Using <=> as the operator to create a two-way data binding is really clever, I hope they’re proud of that. Also, since this DSL is a standalone language and not just a pile of Rust macros, the ceiling on error message quality is way higher. I don’t think they’re actually hitting that ceiling yet, though: before I stumbled into the two-way data binding operator I had a callback with a syntax error and the Slint compiler wasn’t a ton of help. They’ve even got C++, JS, and Python bindings, and it’s cool that you can write a library once in Rust and then use it from that many different languages.

I suggested towards the end of my previous excursion here that Slint (then still called SixtyFPS) would merit a more thorough look once it had better accessibility support, and it certainly does. It’s not perfect, but it’s come a long way in the last four years, and I’m curious what the next couple years will look like for Slint.

Tauri

Do you like Electron but wish it was Rust? Tauri is that. To their credit, they’ve also swapped out the bundled Chromium for just binding to the system’s inherent web browser, whether that’s WebView2 on Windows, WebKit on macOS, or WebKitGTK on Linux, so Tauri applications don’t fill your hard drive with a dozen copies of the same web browser. Unfortunately, they have not touched the architecture; you still have a host process running outside of the browser and an independent frontend running inside the browser.

Building that frontend is not something Tauri is concerned with; you have to decide for yourself what you want your stack to look like. I want to write Rust, so in the new project wizard I pick Rust as my frontend language (rather than JavaScript/TypeScript or, for all three diehard Blazor fans, C#). I’m then asked which Rust frontend framework I want, and I don’t really want to have to pick between Dioxus and Leptos and Sycamore and Yew right now, so I pick “Vanilla” assuming that it’ll give me bare web-sys to make the same DOM API calls as vanilla JS but in Rust; I’ve done this before, and it’s not very good, but at this scale it’d be completely tolerable. Instead, though, “Vanilla” means vanilla JS even if I selected Rust, and since I selected Rust I don’t even get an option of vanilla TS instead. This was reported a year and a half ago and ignored.

If I’m stuck making a choice, I need an excuse to ignore three of the four provided options. I already looked at Dioxus, so that’d be boring to use again. Yew’s 0.22 release was announced in October 2024, added to the changelog in December 2024, and released on crates.io literally never (as of April 2025); that’s not great. The Leptos book says that it’s “most similar to frameworks like Solid and Sycamore”; maybe that’s a sign that it doesn’t matter, or maybe it’s a sign that I should try both.

// leptos
#[component]
pub fn App() -> impl IntoView {
    let (label, set_label) = signal("Hello, world!".to_string());

    let update_label = move |ev| {
        let v = event_target_value(&ev);
        set_label.set(v);
    };

    view! {
        <p>{ move || label.get() }</p>
        <input type="text" value={ move || label.get() } on:input=update_label />
    }
}

// sycamore
#[component]
pub fn App() -> View {
    let label = create_signal("Hello, world!".to_string());

    view! {
        p { (label) }
        input(r#type="text", bind:value=label)
    }
}

Narrator can see all this text, and the IME provisional states are drawn in the corner of the screen rather than inline but they work correctly and the final kanji look fine.

I guess the main difference between these two Web frameworks that we can see from here is that Sycamore has a bind: modifier for attributes (very good!) but can’t quite handle input type= because type is a Rust keyword and requires r#type instead (very bad!). The largest issue, though, is something I haven’t captured here, because today’s task is so trivial it can be done entirely within the frontend, and I let that count for GTK so I have to let it count here too.

If I add the requirement that the new value of the label be printed to standard output when the label changes (as a stand-in for, say, performing some file I/O), in most frameworks it suffices to either add a println! to the existing event handler or subscribe to a two-way-bound state with a println!. Even Dioxus, built on the same WebView2/WebKitGTK library as Tauri, will do the right thing if I println! from an event handler. In Tauri, though, a println! from the frontend will be completely ignored, and if we want to be able to println! we need inter-process communication between the frontend and the host process.

In the host, this is nice and easy due to the magic of proc macros:

#[tauri::command]
fn print(text: &str) {
    println!("{}", text);
}

In the frontend, however, there is a lot more boilerplate:

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = ["window", "__TAURI__", "core"])]
    async fn invoke(cmd: &str, args: JsValue) -> JsValue;
}

#[derive(Serialize, Deserialize)]
struct PrintArgs<'a> {
    text: &'a str,
}

#[component]
pub fn App() -> View {
    // ...

    create_effect(move || {
        let label = label.get_clone();
        spawn_local_scoped(async move {
            let args = serde_wasm_bindgen::to_value(&PrintArgs { text: &label }).unwrap();
            invoke("print", args).await;
        })
    });

    // ...
}

This makes me sad for two reasons. The first is a question of principle: this arbitrary boundary drawn through the middle of my application means that if I discover I need a new piece of functionality I may need to move a substantial chunk of code from the frontend to the backend, and if it’s something load-bearing within the frontend I’m going to have a real motherfucker of a time pivoting my architecture on short notice for no reason. The second is a question of type safety: as you may have noticed, the IPC interface in the frontend takes an &str for the command name and a JsValue for the command arguments, meaning frontend IPC calls have no type checking. Indeed, if I rename the argument in the host from text to text_to_print and don’t update the PrintArgs in the frontend, I get not even a warning at compile time, and at runtime I get

panicked at src\app.rs:6:1:
unexpected exception: JsValue("invalid args `textToPrint` for command `print`: command print missing required key textToPrint")

Uncaught RuntimeError: unreachable

If I then change the label, I get

panicked at C:\Users\Melody\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wasm-bindgen-futures-0.4.50\src\task\singlethread.rs:103:37:
already borrowed: BorrowMutError

and this is all just misery upon misery. Half the point of Rust is the sheer quantity of bugs that it can catch at compile time, and if your IPC is just tossing strings around and praying at runtime, you may as well be just writing vanilla JavaScript. (I checked, and even if your frontend is TypeScript, the invoke IPC boundary just takes a string rather than a union of the actual legal values.)

edit 2026-01-03: I learned at the Utah Rust meetup that if you’re writing your frontend in TypeScript you can use tauri-specta to generate type safe IPC wrappers.

Hilariously, the Tauri docs claim that the command mechanism is “for reaching Rust functions with type safety”, as distinct from their event system, which is even less type safe. With events, you’re tossing strings and arbitrary JavaScript payloads around in both the frontend and the host, so technically it’s not false to claim that only doing that on one end is more type safe, but type checking only at one end is like putting a lock on your bike but not running it through the bike rack: you aren’t tying two things together, you’re just tying one thing to itself and praying. Even to the limited extent that half of type safety could be useful, though, they’ve picked the wrong half: there’s inherently only one implementation of the command, but there can be many calls to it, so it’d be far more valuable to have type safety at the call sites than at the implementation site. Commands only go from the frontend to the host, so type checking in the host and YOLOing in the frontend is being picky at the receive end and sloppy at the send end, which is the exact opposite of Postel’s law.

digression: Postel’s law

If there was an unnecessary IPC boundary but it was type safe, or if there was bad stringly typed nonsense somewhere but no unnecessary IPC boundary, I might find it within myself to forgive that, but the combination of the entirely unnecessary split-brain architecture with the absolute lack of type safety at the boundary means that I think I genuinely hate Tauri.

tinyfiledialogs

tinyfiledialogs is a C library with Rust bindings providing a handful of basic prompts, including message boxes, text input a la JS’s window.prompt, and, as the name implies, file dialogs. I can’t actually complete today’s task with those.

Tk

Tk is the GUI framework for Tcl, a fascinating late-80s programming language that I would describe as weird in a Lua way, weird in a LISP way, and weird in its own way all at once. Evidently it has Rust bindings.

The docs for the Rust bindings recommend ActiveState’s ActiveTcl, but I can’t find an actual way to download ActiveTcl, and ActiveState’s pricing page has an FAQ entry that doesn’t inspire confidence:

Can I still get ActivePerl, ActivePython, or ActiveTcl?

If you still need access to our legacy releases, please get in touch with us via our Contact us page.

I’m installing Magicsplat Tcl instead. It doesn’t appear to have been enough, though:

  thread 'main' panicked at C:\Users\Melody\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\bindgen-0.64.0\lib.rs:2393:31:
  Unable to find libclang: "couldn't find any valid shared libraries matching: ['clang.dll', 'libclang.dll'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"

Apparently this can be fixed with just winget install LLVM.LLVM.

let tk = make_tk!()?;
let root = tk.root();

let c = root
    .add_ttk_frame("c" -padding((3, 3, 12, 12)))?
    .grid(-column(0) -row(0) -sticky("nwes"))?;

root.grid_columnconfigure(0, -weight(1))?;
root.grid_rowconfigure(0, -weight(1))?;

let label = c
    .add_ttk_label("label" -text("Hello, world!"))?
    .grid(-column(1) -row(1))?;

let entry = c
    .add_ttk_entry("entry" -textvariable("label"))?
    .grid(-column(1) -row(2))?;

entry.insert(0, "Hello, world!")?;

entry.bind(
    event::any_key_release(),
    tclosure!(tk, || label.configure(-text(entry.get()?))),
)?;

Windows Narrator can’t see any of this text, and the IME works fine.

I guess translating ttk::label "label" -text "Hello, world!" (which is how Tcl works, I’m fairly certain) to add_ttk_label("label" -text("Hello, world!")) makes sense for existing Tcl users, but it feels really weird, and cargo fmt is understandably confused by it. It’s also hard to tell which options are actually supported on which widgets, because of all the trait magic that’s going on; it took me a while to discover that .insert() is the way you set the initial text of the text field. There’s also a bit of jank in the example — apparently attaching a callback to a button requires unsafe. Plus, after I uninstalled Tcl/Tk, the binary stopped working, so you can only ship a binary to people who also manually install Tcl/Tk.

If you already know and love Tcl/Tk and just wish (heh) you could use it from Rust, maybe you’d find this useful, but I am not in that situation and I do not.

Vizia

Vizia is another novel Rust GUI library. The book says to depend on the Git repo rather than the latest release, which I usually try to avoid, but sure. Conveniently, the counter example is pretty easy to adapt for what I need here, and there’s no list of widgets in the book (at least that I could find) but there is a list of widgets in the docs so I don’t have to spend fifteen minutes guessing what they call their text field.

#[derive(Lens)]
pub struct AppData {
    label: String,
}

pub enum AppEvent {
    SetText(String),
}

impl Model for AppData {
    fn event(&mut self, _: &mut EventContext, event: &mut Event) {
        event.map(|app_event, _| match app_event {
            AppEvent::SetText(text) => {
                self.label = text.clone();
            }
        });
    }
}

fn main() -> Result<(), ApplicationError> {
    Application::new(|cx| {
        AppData {
            label: "Hello, world!".to_string(),
        }
        .build(cx);

        VStack::new(cx, |cx| {
            Label::new(cx, AppData::label);

            Textbox::new(cx, AppData::label).on_edit(|cx, text| cx.emit(AppEvent::SetText(text)));
        })
        .alignment(Alignment::Center);
    })
    .title("Counter") // Configure window properties
    .inner_size((400, 100))
    .run()
}

Something weird happens to the internal padding in the text field when I focus it, though:

Narrator can see that there’s a text label and a text input within this window, but it doesn’t appear to be able to see what the text actually is in either widget, which is a new one. The IME converter dropdown appears in the corner of the screen, but the provisional states draw correctly in the text field, and the final kanji go in correctly.

The structure that’s present here seems promising, but Vizia doesn’t seem to be quite ready for serious use yet.

WebRender

WebRender is part of the guts of Servo, the Rust-based web browser engine that Mozilla founded and then abandoned (an event which prompted my biggest hit on this blog). It’s been picked back up and is some amount of back, although quite how back its new team wants it to be is still up in the air.

The in-repo examples are so old they’re still using the 2018 language edition, and the latest version published on crates.io is from 2020, so I guess I’m depending on the Git repo again. There’s a main branch last updated four months ago and an upstream branch updated last week; presumably the upstream branch is the right one to use, but it’d be nice if that was actually explained somewhere.

Looking a bit at the examples, WebRender does not have widgets, it just has shapes; this is a low-level graphics crate and not a high-level GUI crate, and it’s not clear why it’s on the Are We GUI Yet? list.

windows

Windows is an operating system created by Microsoft in the mid-1980s; its APIs have Rust bindings. I do not know how to do GUI development with bare Win32 API calls, though, so doing them from Rust is not exciting. XAML, which is to my understanding the shiny new way to do desktop GUI development in specifically Windows, is explicitly not included in the windows crate because “Xaml is also focused and tailored for C# app development so this API isn't applicable to Rust developers.” This is confusing, because the XAML-based WinUI 3 is also supported on C++, not just C#. Ah, Microsoft.

WinSafe

WinSafe is apparently a set of Rust wrappers around the Win32 GUI API.

#[derive(Clone)]
pub struct MyWindow {
    wnd: gui::WindowMain,
    label: gui::Label,
    field: gui::Edit,
}

impl MyWindow {
    pub fn new() -> Self {
        let wnd = gui::WindowMain::new(
            gui::WindowMainOpts {
                title: "My window title".to_owned(),
                size: (300, 150),
                ..Default::default()
            },
        );

        let label = gui::Label::new(
            &wnd,
            gui::LabelOpts {
                text: "Hello, world!".to_string(),
                position: (20, 20),
                ..Default::default()
            },
        );

        let field = gui::Edit::new(
            &wnd,
            gui::EditOpts {
                text: "Hello, world!".to_string(),
                position: (20, 50),
                ..Default::default()
            },
        );

        let new_self = Self { wnd, label, field };
        new_self.events(); // attach our events
        new_self
    }

    pub fn run(&self) -> AnyResult<i32> {
        self.wnd.run_main(None) // simply let the window manager do the hard work
    }

    fn events(&self) {
        let ready = Arc::new(AtomicBool::new(false));

        let ready2 = ready.clone();
        self.wnd.on().wm_create(move |_| {
            ready2.store(true, Ordering::SeqCst);
            Ok(0)
        });

        let self2 = self.clone();
        self.field.on().en_change(move || {
            if ready.load(Ordering::SeqCst) {
                self2.label.set_text(&self2.field.text());
            }
            Ok(())
        });
    }
}

Unsurprisingly, Narrator and the IME both work.

Manual positioning is no good, and the alternatives involve Win32 .res file editing and other Pandora’s boxen I don’t want to open. Also, I had to add that ready tracking myself, because the callback was firing for the first time before the window had been created, which was causing crashes. This isn’t great, and of course it’s only useful on Windows.

Xilem

Xilem is another novel pure-Rust framework, built on top of the previously discussed masonry, the successor to Druid, which I thought was really promising when I first got started with this series. It hasn’t had a numbered release in almost a year, so I’m pointing at the Git repo again.

Conveniently, they’ve got a todo list example that I can sculpt into what I need today mostly by deleting.

struct State {
    label: String,
}

fn app_logic(state: &mut State) -> impl WidgetView<State> + use<> {
    flex((
        label(state.label.clone()),
        textbox(state.label.clone(), |state: &mut State, new_value| {
            state.label = new_value;
        }),
    ))
}

fn run(event_loop: EventLoopBuilder) -> Result<(), EventLoopError> {
    let data = State {
        label: "Hello, world!".to_string(),
    };

    let app = Xilem::new(data, app_logic);
    app.run_windowed(event_loop, "First Example".into())
}

fn main() -> Result<(), EventLoopError> {
    run(EventLoop::with_user_event())
}

As was the case when using Masonry directly, Narrator sees the text but is wrong about its position, and some IME provisional states have missing glyphs but the IME behavior works fine.

This architecture seems pretty neat, although of course this is not sufficient to know how well it works at any reasonable scale. Honestly, aside from the screen reader jank, my only gripe is the lack of versioning, and presumably that’ll be coming as Xilem matures.

Conclusion

What a list, huh? If I had counted how many of these there were before I got started, I might’ve never started, because 43 is a lot. It’s good that there are this many different people working in this space, but the more options there are, the more important it is for people to be sifting through them to distinguish the ones that aren’t ready to use from the ones that are.

Let’s pick some winners. If you’d rather take the quirks of CSS layout over the quirks of some other layout engine, Dioxus seems like a pretty reasonable choice; Diet Electron is definitely better than regular Electron, and that may be good enough for you, but it feels not-better-enough to me (although my sense of not-better-enough is non-standard). If you like DSL-driven UIs that are putting serious effort into developer tooling, Slint might be for you. If you want to avoid DSLs and macros and write only regular Rust, egui offers that. If you’re looking for something to invest in early, Freya and Xilem are both basically usable now if you don’t mind living on the bleeding edge and putting up with some jank. There are open issues for improving accessibility in Floem and iced, so it may be worth at least keeping an eye on those issues, although the iced issue has been open for 4½ years now.

I would not describe any of these as a super easy slam dunk obviously correct choice, but there are a lot of reasonable options available, and that’s better than 2021, where I was longing for wxPython by the end of the post. Maybe better things are possible after all.

Now if you’ll excuse me, I’ve got some cargo cleans to run:

The Table

library	works at all?	screen reader accessible?	IME works?
Azul	linker hell
cacao	macOS-specific
core-foundation	macOS-specific
Crux	no desktop targets
Cushy	yes!	nope	composer hidden, converter works
CXX-Qt	linker hell
Dioxus	yes!	yes!	yes!
Dominator	web-specific
egui	yes!	yes!	composer works, Tab press stolen from converter
Floem	yes!	nope	nope
fltk	yes!	with extra crate	yes!
flutter_rust_bridge	kinda, but state hell	yes!	kinda, but state hell
Freya	yes!	mostly, but some content missing	composer hidden, converter works
fui	qmake hell
GemGui	technically
GPUI	yes!	nope	yes!
GTK 3	unmaintained
GTK 4	yes!	nope	yes!
Iced	yes!	nope	nope
imgui	yes!	nope	nope
KAS	yes!	nope	nope
kittest	only for testing
Leptos	web-specific
lvgl	C dependency hell
Makepad	yes!	nope	composer outside window, converter works
masonry	yes!	content but not position	yes! but some temporary tofu
Maycoon	no text input widget
Pax	no Windows support
qmetaobject	no windows-msvc
relm	uses unmaintained GTK 3
Relm4	yes!	nope	yes!
Ribir	kinda, but state hell	nope	composer hidden, converter works
Rinf	does not use Rust for GUI
rui	yes!	nope	nope
Slint	yes!	yes!	missing glyphs in provisional states but logic works and final kanji displayed correctly
Tauri	yes!	yes!	composer outside window, converter works
tinyfiledialogs	not general-purpose
Tk	yes!	nope	yes!
Vizia	yes!	structure but not content	converter outside window, everything works
WebRender	too low-level
windows	i don’t know Win32
WinSafe	yes!	yes!	yes!
Xilem	yes!	content but not position	yes! but some temporary tofu

Status Update

2024-10-07T00:00:00Z

been a minute, hasn’t it?

i’ve been mostly active on cohost, but it’s shutting down. this means two things:

i expect to be more active on here moving forwards, because cohost was the easiest place i had to do long-form writing, and i haven’t made this blog much easier to write on but it has the advantage of not being read-only as of last week.
at some point soon i will be importing some to most of my posts on cohost into this blog so that they live somewhere durably.

rss subscribers, if you see a flood of new posts in the next week or two, congratulations and i’m sorry. if you don’t, it’s probably because i’ve partitioned out the noise into “posts”, “scraps”, and “nonsense” and used the existing feed URL for only “posts”; i haven’t decided how i want to approach that just yet.

also, while i’m in here, i’ve done another conceptual art, which you may find compelling depending on your tastes in art. (if you are behind on your cactus lore, you may have missed my first conceptual art, which was a lot more of an achievement.)

Eggbug Forever: a custom minion mod for FFXIV

2024-09-20T00:00:00Z

The real eggbug was the friends we made along the way. We carry him with us forever.

A very simple import of Xenon Fossil’s low-poly eggbug model replacing the Wind-up Airship and/or the Great Serpent of Ronka (the Great Serpent animations are adorable but the rigging is a little janky so the Wind-up model may be better for gposing).

XIV Mod Archive | Heliosphere

(30 Sep 2024)

eggbug forever. see y’all around.

#ffxiv #eggbug #Goodbye cohost #last one out hit the lights #but for real this time

Abdication Is Not Simplicity, or cat -v Considered Harmless

2024-09-08T00:00:00Z

in some sense, the Brainfuck programming language is extremely simple. it only has eight instructions! an intermediate programmer could write an interpreter in an afternoon! that's so simple it borders on trivial! specifically, Brainfuck is simple to implement.

using Brainfuck, on the other hand, is so self-evidently a bad idea that it's the entire point. even the Wikipedia “hello world” snippet would be no small task to independently discover (and even more direct ways to print “hello world” are a bit of a mess). there is still a lot of complexity, it’s just been moved downstream, out of the implementer's hands and into the user's.

it'd be absurd to claim that Brainfuck is simple, because the only real way to get any nontrivial work done in Brainfuck would be to find or create a programming language that compiles into Brainfuck, at which point Brainfuck adds nothing. there are things we reasonably expect programming languages to do, and a simple language might do them simply but Brainfuck simply doesn’t do them. i think it'd be unhelpful and misleading to call that “simplicity” when it's just not fulfilling the responsibilities that we generally expect programming languages to fulfill.

fortunately, nobody actually says Brainfuck is simple. unfortunately, however, the idea that “simple” means “simple to implement, regardless of how complicated it is to use” is a long-lived meme among certain kinds of programmers. one cluster of such programmers is called suckless, and their backwards understanding of simplicity leads to fascinating decisions like “the way you change the settings in this software is by editing config.h and recompiling it”. it's software that gatekeeps itself:

Because dwm is customized through editing its source code, it's pointless to make binary packages of it. This keeps its userbase small and elitist. No novices asking stupid questions. There are some distributions that provide binary packages though.

this sucks more than systemd or cmake or any of the software they’re butthurt about ever could.

there's a semi-overlapping cluster of annoying fossbro nonsense over on cat-v.org. some of it is the same boomer nonsense about old software good new software bad, and some of it is more directly venerating Rob Pike and The UNIX Philosophy™. the website is named after a talk Rob Pike gave in 1983, “UNIX Style, or cat -v Considered Harmful”. that page also links to a paper by Rob Pike and Brian Kernighan, which is a really interesting case study in The UNIX Philosophy™.

what is cat? if you ask someone who knows a bit about the command line on macOS or Linux, they’ll tell you it displays the contents of a file, but if you ask a proper UNIX dweeb they’ll tell you it concatenates files (hence the name) and it’s a happy accident that it’ll display the contents of a single file. as Pike and Kernighan put it,

The fact that cat will also print on the terminal is a special case. Perhaps surprisingly, in practice it turns out that the special case is the main use of the program.

and right away we have encountered a flaw in the UNIX Philosophy™ tenet that a program should do one thing well. cat does two things well: concatenating files and displaying them. a program that displays files well would very reasonably benefit from options to add line numbers or display non-printing characters (in BSD, cat -s and the titular cat -v), but Pike and Kernighan are right that a program that concatenates files well would need no such options.

but if displaying a file is the main use of cat, then it is absurd to argue that displaying a file is not the one thing it should do well. Pike and Kernighan suggest adding line numbers with awk and displaying non-printing characters with a new program vis, to maintain the purity of cat for concatenating files, but that sucks. cat is responsible for displaying files, and as such if it can’t meet reasonable requests about displaying files, that’s not simplicity, that’s an abdication of that responsibility. cat -v is good, and 1983 Rob Pike was wrong, and The UNIX Philosophy™ is bogus.

the browser is a terrible place for art

2023-12-31T00:00:00Z

condensation on the shower door is a more stable platform to develop for than the web.

i’ve grumbled repeatedly before about how the web’s lack of actual versioning is a nightmare hellscape from satan, but i may as well rehash that even though it’s not the thing i’m mad about now. Java 9, for example, adds some features that were not present in Java 8, and you can decide whether to develop for Java 9 and be able to use the new features or develop for Java 8 and be compatible with older runtimes. on the web, meanwhile, we have terms like “ES2023” that are purely decorative and carry basically no meaning. all the standards are living documents, new features go in one at a time whenever it’s convenient, and they get implemented one at a time at whatever pace happens, except when a browser can’t figure out how to put a good UI on a new feature so they decide that feature is actually evil¹. the standard way to manage this is to compile your new-feature-using code into older-feature-using code based on guessing which browsers people still use and checking massive tables of which browsers support which features as of which versions, but this sucks, and no amount of vehicular manslaughter² will let you do the same thing in CSS, where you just can’t use anything invented after like 2016 because some dipshit vendor still can’t be bothered to implement it. they actually kinda had “CSS3” (along with “HTML5” and “ES6” to some extent), but the CSS people actually noticed that named standards versions are fake and split CSS up into shit like CSS Media Queries Level 3 and CSS Color Level 4. unfortunately, that hasn’t actually solved any of this, because then Firefox 101 implements like 80% of CSS Values and Units Level 4 and there’s no way to reason about which 80% without just listing off each individual feature by name.

the thing i’m mad about today is that even when you somehow manage to beat the odds and make something that actually works, browsers will break it before long anyway because they don’t give a shit. an art game i made less than two years ago just completely fails to do anything now, despite having worked at the time. the game uses the localStorage API to do literally anything at all, and apparently using localStorage in a game that gets embedded in an iframe sets off a dozen warning sirens at Mozilla HQ and throws an exception that just breaks the game. this game has more CSS than JS (by lines, if not by characters), so it blew my mind when i went to check how i had built it and it just didn’t work at all. i have no idea if i have turned on an inadvisable Firefox setting to break everything all of the time, or if this issue exists the same way in Chrome, or if it's somehow itch.io’s fault for confusing CSP reasons and i’m too eager to assume it’s the browsers’ fault, but like. browsers already all did this on purpose with moving audio playback behind less than obvious thresholds of user interaction over the objections of a ton of people whose browser-based art would just detonate if they did that; they have not earned the benefit of the doubt here.

it’s not just my dubious art games, either; you can’t play the equally sophisticated but much more fun Room of 1000 Snakes anymore, because steve jobs killed the unity web player when he killed flash and java³.

browsers don’t give a shit about backwards compatibility⁴. operating systems do⁵. make actual executables that can be downloaded and then played. my next game will be distributed solely via retail CD⁶. good fucking luck.

Mozilla on Web NFC. this is uncharitable but i do not think it is inaccurate
core-js. this is irrelevant but based on the way the guy talks about it this is my own personal the onion john lennon
obviously we don’t get to check in on the universe where safari on ios supports plugins to see how flash and java are doing in there, and it’s possible that goddamn adobe and motherfucking oracle would ruin everything even if apple didn’t move first. but i’m right
unless they’re doing API design and it’s contains/includes time. goddamn mootools or prototypejs or whichever. if it’s an opportunity to make things worse, they will absolutely care about backwards compatibility. don’t get me started on css if/when
except when they don’t, like if they’re mobile operating systems run by bored corporations, or if apple hasn’t made enough unforced errors yet this year, or if maintaining a 32-bit userland is getting annoying. so basically it’s just windows and the kinds of linux distribution that solve backwards compatibility by never moving forwards in the first place
no it won’t
⁸ one of my other browser-based games is also broken but because it uses a primary server for multiplayer and that primary server was on the heroku free tier and i hardcoded the url because the previous url was getting caught up in ad blocking because apparently third-party websockets connections to the goofy donuts ass tlds like .fun are inherently suspicious. it could be fixed if i cared, but. there’s the rub
this footnote does in fact not actually come from anywhere, i just wanted to also mention it because it’s tangentially related

No Man’s Sky …unless?

2023-12-27T00:00:00Z

i chose to build a hazard control room instead of a tavern in my settlement; my citizens aren’t very happy, but my colony was in debt. i don’t speak the language very well, though, so when i talk to the citizens i don’t know what they’re saying. and it’s not particularly my colony, so much as i saved them from Sentinels one time and was immediately elected mayor. the second decision i had to make as overseer of the colony was between the same pair of buildings again.

i sent my freighter on a mission doing satan knows what. it said it’d take an hour and a half real time, so they’re probably back now. and it's not like i built or scavenged the ship; i saved the existing crew from pirates one time and the admiral was like “hello would you like to command my ship”. the last time this happened, i said to just pay me instead, because i could not fathom why anyone would turn over command of their ship to a random stranger whose sole qualifications are saving them from pirates one time, and i suspected the ship command mechanics would be thematically inconsistent and somewhat janky; it turns out you can command an entire fleet of freighters and a squadron of smaller ships.

i’ve said before that half of Dragon Age: Inquisition would be the best video game of all time. i don’t know if i’d go that far at this point, but it’s certainly got a lot of good parts and a lot of extra cruft that distracts from those good parts. and when i think about Dan Olson’s Alone in Public (and, as i’ve just also discovered, Hbomb’s THE NO MAN’S SKY RANT) and i compare it to the experience i’m having seven years later, i think of cruft, and systems that add Content™ but don’t add anything meaningful, and potential wasted not by underdelivering but by adding filler to something good, and Dragon Age: Inquisition.

i also think of George Lucas. because the game that Dan and Hbomb played doesn’t exist anymore. the settlement system was added in Update 3.6, FRONTIERS, in September 2021. the Anomaly, a teleporting space station that acts as a hub for some of the overarching story and mechanical progression, has a dozen or so other players running around in it at any given time, sending the framerate and the themes equally to hell; i’m not quite sure how it worked at launch, but the player limit was raised to 16 in Update 2.0, BEYOND, in August 2019. the freighter fleet mechanics, including the real-time missions, were added in Update 1.5, NEXT, in July 2018. a lot of the bad filler has been added over time. not every patch has been a change for the worse, and i’m sure you could make a case that on balance the game as it stands now is better than it was at launch, but something has certainly been lost, and not merely lost, but erased after release by an author not content to stay dead. and that erasure began in Update 1.1, FOUNDATION, in November 2016, with base building.

my home base employs four total NPCs. the most confusing was the first hire, the overseer; surely it would make more sense for an NPC to oversee the settlement full of NPCs and me to oversee my own base, rather than me overseeing a settlement full of NPCs whose language i do not speak but having to hire an NPC to oversee the base i am building my damn self. my science, weapons, and farming experts are all fairly reasonable by comparison, although they all always have quests for me to do and the rewards are frequently blueprints i already unlocked by other means. one of the first things the game suggested i build at my home base was a teleporter, which renders distance itself meaningless after the first journey to a new solar system. i’ve built several other bases consisting exclusively of teleporters, because the convenience of fast travel is too hard to ignore even in a game that so many people have loved for the slow pace of travel. i don’t think all of these systems were added in FOUNDATION, but the first step into base building was a step towards this.

my weapons expert, when giving me some quest or other, said i had to fight the Sentinels so it’d be “no man’s sky but ours”. and yeah, having a home base in the first place, carving out a piece of the world in which i specifically belong, undermines not just the themes that people connected with in the game as it released but the very goddamn title of the video game. what Dan and Hbomb played and loved was a game that’s about an adventure that can never pause, always moving to the next place but not belonging there either, some planets more hostile but no planets really comfortable, permanently inbetween. a lonely liminality, if you will.

what i’m playing is a game that used to be about all that. and it’s fine.

i got ⋖Builder of the Realm⋗ on the cloud DC

2023-11-26T00:00:00Z

i had hoped to get ⋖Honorary Academic⋗ but obviously that's not happening. also, it's basically impossible to finish the lv50 quests since they all require tier 3 combat materia which nobody has (i tried transmuting but it's very inefficient so i didn't get anything good). however, i did still level all the DoH/DoL through ARR in less than a week.

never do this.

if you aren't aware, FFXIV is testing a new cloud data center, and it opened last Monday and it gets deleted this Monday (i.e. tomorrow). they give you a boost to lv 80 for all the combat classes, but not for the crafters and gatherers, so i somehow convinced myself it'd be funny to get an achievement for leveling up my crafters and gatherers on a data center that dies soon.

i'm gonna miss Tiny Cactus🌸Cloudtest02.

update: i don't have to miss Tiny Cactus🌸Cloudtest02 (27 Nov 2023)

with the power of retainer fantasia, Tiny-cactus lives to fish another day. almost cried a little bit hanging out in [the last area of ShB] for the last couple minutes

don't talk to me or my distant cousin i rescued from a crumbling world ever again (1 Dec 2023)

shout out to my FC for letting me swap out one of the retainers in the front yard

25-Hour Time (and the Secret Third Half of the Day)

2023-08-17T00:00:00Z

you know how if you're up past midnight, on some level it's still the same day until you go to bed, no matter what the calendar says? well, if you've ever wished that there was notation to unambiguously refer to a current date and time when the current date is somewhat vibes-based, you're actually in luck, because this is a solved problem, although depending on your preferred time notation it may require some creative extension.

It Came from Public Transit

(Opinions, as always, are my own and not that of my employer.)

Some public transit systems run 24-hour service, but many shut down for a bit overnight, which is less convenient for riders but gives staff some time to reset and maybe even take care of some small maintenance tasks without disrupting any scheduled trips. Denver's D line trains, for example, start at 3:48 AM and end at 12:21 AM the next morning (on weekdays, at least). This creates some interesting problems, because if you spell "12:21 AM the next morning" as 12:21 AM, it looks like it's before 3:48 AM, but it isn't, so you need to spell that differently.

Conveniently, this problem is solved in the¹ standard for public transit schedule data, GTFS. It's a machine-facing interchange format, so it uses 24-hour time for parsing simplicity, so it spells "3:48 AM" as 03:48 and "1:30 PM" as 13:30². The way it handles times the next morning is extremely simple: if "11:59 PM" is 23:59, then "12:00 AM the next morning" is 24:00, and "1:13 AM the next morning" is 25:13, and I'm writing this sentence at "2:14 AM the next morning", or 26:14. Apparently, this is occasionally done in countries that use 24-hour time by businesses that run past midnight.

If you say "oh yeah, i wrote that at 2023-08-16 26:20", even if people aren't familiar with beyond-24-hour time, they'll probably figure out what you mean.

Welcome to Arco AM/PM Mini-Market

Unless they don't grok 24-hour time at all, like me. A trick like that doesn't really work as nicely with 12-hour time - the minute after 11:59 is already 12:00, and by the time 12:59 rolls over to 1:00 you're an hour deep into the next half of the day anyway. If you want to have times the next morning in 12-hour time, you have to reach a little deeper into the notation.

A system I was dealing with at work has a really nice solution to this. For space efficiency, it spells "11:30 AM" as 1130a and "9:15 PM" as 915p, and then the minute after 1159p is 1200x, which I suppose would expand out to "12:00 XM" but I prefer with just the x. For sheer intuitive clarity, it doesn't match the 25-hour solution — x as an abbreviation for "AM the next morning" is not something you'd be likely to just guess — but if you see it in a list of times with some as and then some ps and then some xs it's not hard to guess that that's what it means. I have no idea if this sort of thing (or some other solution to this problem) is common outside my specific job.

If you say "I wrote this sentence on 2023-08-16 at 229x", people will only have a clue what you mean if they're already familiar with this concept. Most people won't be, but if you're taking notes for yourself, you will be.

Completely Missing the Point of Everything

But this [was originally, RIP] Cohost, and we are no strangers to goofy time notation here. I am not, myself, a .beat time enjoyer, but I know it's a feature and I think it's got several users at varying levels of irony. One of the main things I don't like about .beat time is that it also alienates you from the current date, but we're aggressively solving that in other notations, so can we solve it here too?

25-hour time demonstrates that it can make sense to reach past the bounds of the time system to express times past the edge of the calendar date; there is no authority who can stop us from doing the same thing to .beat time. I'm writing this on 2023-08-16 at @1400 (which mere mortals might write 2023-08-17 @400).

Terrifyingly, on account of time zones stretching in both directions, this could allow for someone west of Switzerland to experience negative .beat time. By my math (and the math on SwatchClock.com), someone waking up in Sydney, Australia on 2023-08-17 at 8:00 AM local time would conventionally write that as 2023-08-16 @958 but could instead write it as 2023-08-17 @-042.

The entire point of .beat time is to be absolute and global, and the whole point of this endeavor of vibes-based current date is to be anthropocentric and subjective, so this borders on heresy. In addition, it is almost completely useless as a way of communicating anything to anybody - positive overflow is at least trivial mental math to do, but turning a negative .beat time into a normal .beat time would be, at least for me, in that perfect sweet spot where it's too simple to pull up a calculator but not simple enough to be confident that I'd get the right answer doing it mentally. If you have .beat time enjoyer friends, you can probably ruin their day with a negative .beat time, but that's as much use as anyone will get out of this concept.

Exiting the Target Audience

“But Cactus,” I hear you ask, “isn't this lopsided towards people who stay up inadvisably late? What about people who wake up inadvisably early? Don't they deserve wacky time notation, too?”

Nope!

Well, that's not fair. To be more specific:

If you want to do negative time in 25-hour time, what's the minute before midnight? 00:-01? -01:59? Both of those make me sad.
Coming up with a secret fourth abbreviation for "PM the night before" is probably not difficult, but there's no canonical right answer there.
Negative .beat time could cover this use case anyway, and also very much shouldn't.
You're into real sickos territory by the time you're waking up as early as 4am, and that's still four hours away from needing anything like this. By contrast, staying up until like 1230x, which is in the range that benefits from this, is not really that out there.

Unfortunately, it is now 27:05 / 305x / @1420 (nice), and I need to go the fuck to bed.

or at least a standard: as I recall, there are several standards for public transit schedule data, and different ones are popular in different parts of the world; GTFS is big in the US
strictly speaking, those would be 03:48:00 and 13:30:00 on account of seconds also existing, but that's not relevant here. also not relevant here is the way GTFS avoids getting pranked by DST transitions; if you're curious and/or bored, look that one up.

the Derivative Gardens Misattribution-OnlyCommercial-ShareUnlike 6.9 Unportable License

2023-06-15T00:00:00Z

You are free to:

Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material

Under the following terms:

Misattribution — You must give slightly inaccurate credit and provide a link to the wrong license. You may do so in any unreasonable manner.
OnlyCommercial — You may not use the material for noncommercial purposes.
Additional restrictions — You must apply legal terms or technological measures that legally restrict others from doing one weirdly specific thing the license permits.

two heresies about link rot

2023-05-23T00:00:00Z

the term itself is fascinating. there is nothing natural or organic about a hyperlink, i've never seen anyone call a working link alive, and yet a broken link is dead and links becoming broken over time is rot. the breaking of a link can, depending on the context, be frustrating, tragic, amusing; this it has in common with the more conventional kind of death. but we recognize that to live is to one day die, and there may be no justice in when or how but no justice can be asked of if. we will not last forever; why should our work? decay exists as an extant form of life, as they say. that iconic post itself doesn't exist anymore, it seems; we keep it alive through active preservation, and if it outlasts all its authors it will be because so many people found it compelling. a former drama youtuber recently removed several of his toxic edgelord videos, and of course they're not gone (and the links themselves may still work, i don't care enough to check) but it's good that he can do at least that much to clean up the cultural mess he helped make. maybe the fact that links can rot is a good thing, actually. may the worst of all our links rot before we do.

but of course, there's a spectrum, and just because the median tumblr post or youtube video deserves ephemerality doesn't mean there's nothing to be said for permanence. if we really could recover dinosaur DNA from mosquitoes trapped in amber, that could be very neat as long as we didn't do anything unwise afterwards. there's always nonprofits volunteering to be the metaphorical amber, but it takes a lot of money to remember everything for all of time, and they have an unfortunate tendency to also use that money to pick losing fights with big industries and get into Web 3.0, plus you only need them after the link has already rotted, so the simplest solution would be for links to just always keep working. the issue with that is that internet domains are like real estate in that you can only ever rent, and if you don't pay then someone else will so goodbye. i've had several domains lapse and immediately be squatted, especially later in grad school when $20 was a silly amount of money to waste to preserve the domain for a side project i'd long since given up on. links rot because domains expire, and one of the reasons domains expire is that someone else will pay for them if you won't, therefore, if you want to get rid of link rot, you absolutely have to get rid of capitalism.

computers really are a land of contrasts, huh.

god (derogatory) saw this post and laughed (1 Jun 2023)

my domain registrar deleted pig.observer with no warning, after sending me an email a few weeks ago that said the renewal was successful. i contacted support and they gave it back, though.

i hadn't decided whether i actually think domain expiration is a bad thing or not - i briefly had a digression about that in the original post but i took it out for concision - but now that it has happened to a thing i still care about and that still has users, i am officially anti-domain-expiration.

also the site is still down, because i haven't been able to log in and fix the NS records, because i can't connect to their control panel. and i can't ping it from my home internet, or from a datacenter in Los Angeles, or from a datacenter in London, so i think they may have fucked up their network configuration. does anybody have DNS registrar recommendations that actually support a reasonable set of TLDs? if i can't have botto.ms and pig.observer on a single professional registrar i'm going to shit a brick and cry.

changed my mind again domain expiration is funny and therefore good (2 Jun 2023)

Maryland License Plates Now Inadvertently Advertising Filipino Online Casino

A URL on the license plates of 800,000 Maryland cars now redirects to an online casino based in the Philippines.

VICEvice.com/May 5, 2023

https://www.vice.com/en/article/4a3xe9/maryland-license-plates-now-inadvertently-advertising-filipino-online-casino

UUID versions through the ages

2023-02-12T00:00:00Z

UUIDs are neat. y'know, cfbff0d1-9375-5685-968c-48ce8b15ae17 type of shit. if you're like me until a few days ago, all you know about the types of UUID is that v4 is the good one. but why are there other ones? is there a secret better one? why are the dashes asymmetrical? let's take a (roughly paraphrased from wikipedia and probably not quite accurate) look.

wait why even

sometimes you need an ID for something you are putting in the computer, so that you have a stable way to refer to it even if all the editable fields on it change. the simplest possible approach is to give the first thing ID 1, the second thing ID 2, and so on. cohost works this way right now - as i'm editing it, this draft post has ID 1009270, meaning this is the just-over-a-millionth thing in the posts table.

your database sits there going "the next post has ID 8. oh, new post? it has ID 8, okay the next post has ID 9." and all is well. except a year later you have a million posts and a bunch of people posting all at once, and every new post needs a new ID but they have to get created one at a time in the database so that they all get the right ID. If You're In Line (To Get The Next Post ID), Stay In Line. and the only way to know what the next post ID is is to check with the database, so you can't do things like save drafts offline with proper IDs. (staff probably doesn't want that anyway, but we need something vaguely similar at work, which is how i got here.) if you need to work at, say, Twitter's scale, or you need to be able to generate IDs without checking with the database, you need something more involved than just sequential IDs.

version 1

in the early 90s, some UNIX people ran into this problem when drawing up their Distributed Computing Environment. they called their solution "Universal Unique Identifiers", which they call "an identifier that is unique across both space and time". it's written as a hexadecimal string, but it can be stored as just the 16 bytes that are represented by that hexadecimal string. the way they make sure it's unique across both space and time is actually pretty straightforward: part of the UUID encodes the space where it was generated, and part of the UUID encodes the time where it was generated.

the UUID format has two control fields and three data fields. the version field is pretty straightforward - it's 1 for UUIDv1, 2 for UUIDv2, etc. at this point, they only had 1 and 2, but they left room in the spec for up to 15 just in case. there's also a variant field, which says whether it's a normal UUID (10, hex value 8 through b) or some other bullshit that may or may not adhere to any of the rest of this spec.

other bullshit

the data fields are

timestamp, which is measured since the start of the Gregorian calendar with 100ns resolution (which, with 60 bits available, repeats every 3653 years). this is how they make sure the UUID is unique across time.
clock sequence, which starts at a random number and goes up by one if time goes backwards, to ensure that things like clock drift or leap seconds don't lead to collisions. this is how they make sure the UUID is actually unique across time.
node, which is just the MAC address on your network card (or one of them, if you've got more than one), since different network cards already have to have different MAC addresses in order for networking to happen. this is how they make sure the UUID is unique across space.

this is how we get that weird hyphen asymmetry, the groups come directly from the UUID data fields:

versionvariant

1a8188ce-aa78-11ed-afa1-0242ac120002

time_lowtime_midtime_hiclock sequencenode

you may have noticed that the time is split into three pieces, for the low 32 bits, the middle 16 bits, and the high 12 bits. why split it up like that? well, i don't know, but i suspect it makes a lot of things easier to split the 60 bit timestamp into at least 32 and 28 (and maybe splitting the 28 into 16 and 12 makes something easier in a way i'm not seeing?). for one, 64-bit CPUs weren't mainstream yet, and for two, they had creative alternate uses for that time_low field.

version 2

like a lot of multi-user operating systems, UNIX has users and groups, and allows for permissions management based on those users and groups. users and groups both have textual names and numeric IDs, so if you want to stably refer to a specific user or group, you can use its user ID or group ID. however, different computers can have different sets of users and groups, so if you're making the Distributed Computing Environment, you need a way to refer to a specific user or group on a specific machine. you're building on top of UNIX, because you're the Open Software Foundation (later The Open Group), so you have user and group IDs locally already. and you already made this UUID format, which has fields that refer to a specific machine. the other fields are already taken for time and also-time, but you didn't promise they'd always be time, right?

in UUIDv2 (which the DCE spec calls the "security version"), the time_low field is literally just a UNIX user/group ID. the low byte of the clock sequence field is repurposed to specify whether it's a user or a group (or a secret third thing, an organization).

i have several questions. for one, what about the other time fields? time_mid ticks up once every 7 minutes, if you construct your UUIDv2 out of a UUIDv1. do you just leave it at zero and let time_hi tick up every 325 days? do you leave mid and hi both at zero and party like it's 1582? for two, had they not invented MAC address spoofing yet? these days you can usually change your network card's MAC address to something else, so using that for anything security-related strikes me as highly dubious. for three,, what? just in general? why would you do this? this is some 5 Minute Crafts tier lifehackery. please refrain.

presumably this worked well enough for DCE, but it has not withstood the test of time. i don't know that UUIDv2 even counts as a UUID, but it follows the UUID format and put a 2 in the version number slot, and so it lives on solely as negative space in the UUID version number range. (this is also apparently the deal with IPv5.)

UUIDv2 may or may not have been a good idea, but the concept of "what if you had a UUID based on some specific value other than the current time" had legs.

version 3

DCE was done being written, and then it kinda died, but people kept using UUIDs. DCE was a legacy-style Proper Goddamn Specification, written by the consortium that had since become The Open Group, who also run POSIX and the Single UNIX Specification and all that jazz (🌵 when the posix is sus !), but that sort of doorstopper spec was overkill for the humble UUID. what it needed, as a piece of computer bullshit, was an RFC. and so in 2005 the UUID was defined again in RFC 4122, which kept v1, reduced v2 to one sentence, and added some new versions.

one way to think of the goal of UUIDv2 is that it's about referring to an object that already has a contextually unique ID. in v2, that object is either a user or a group, and that context is a machine. v3 is a little more flexible, but one of the contexts mentioned in the RFC is domain names, so let's look at that.

say i want something in the format of a UUID that refers to the domain name example.com. one option would be to take the MD5 hash of "example.com", look at the first 16 bytes, line that up with the UUID format definition, and set the version and variant to the right values. this is cool, and it basically already works for domain names, but we want flexibility. if you and i both want to do the UUIDv2 thing of referring to users on a machine, and my context is my machine and your context is your machine, and both of us have a user named cactus, oops, we have the same UUID, that's hardly Universally Unique. we need to include the context in what we're MD5ing, and we need to guarantee that different contexts have different values. and there's nothing computer people love more than recursion, so let's give the context a damn UUID.

to make a UUIDv3, you need a name (which is just some text) and a UUID for your "name space" (which is the context in which your name is unique). take the binary representation of the namespace UUID, append the name, MD5 it, copy that into your UUID structure, set the version and variant, and you are done.

the RFC defines some name space UUIDs already, like 6ba7b810-9dad-11d1-80b4-00c04fd430c8 for domain names, so we can check this ourself:

>>> import hashlib
>>> import uuid
>>> dns_namespace = uuid.UUID("6ba7b810-9dad-11d1-80b4-00c04fd430c8")
>>> hashlib.md5(dns_namespace.bytes + b"example.com").hexdigest()
'9073926b929fd1c26bc9fad77ae3e8eb'
>>> uuid.uuid3(dns_namespace, "example.com")
UUID('9073926b-929f-31c2-abc9-fad77ae3e8eb')

this is pretty damn neat. if you have something that's contextually unique and you want to turn it into something that's globally unique, this is a really cool way to do that. (spoilers, except for one thing, which you may have noticed if you know your hash functions.) but this is only sometimes a problem you have; other times, you don't have anything unique yet, and you want something ex nihilo. v1 is still good, if you've got a timestamp and a MAC address, but what if you're doing something like JS development where you can't exactly check the MAC address you're running on? well, satan help you. or what if that 100ns resolution isn't good enough like it was in the 90s?

version 4

set the version and variant. fill the rest with random bits. there is no step 3.

if you had asked me to guess last week what a UUIDv4 was, i'd have just guessed it was 128 random bits (if you made me count how long it was). and i'd have been wrong, but only by six bits. which is neat, but also a little bit bullshit, because like. me from last week wants those bits back!

those six bits are for compatibility with the rest of the UUID universe, but if you're just looking for some random bytes to throw in your id column, you don't need compatibility with UUIDv1, you could just make some random bytes! and 16 of them is probably overkill for your use case anyway!

wait hang on a minute, did that say MD5 earlier?

version 5

turns out MD5 sucks. you know what's really cool? SHA-1.

UUIDv5 is just UUIDv3 again, but with SHA-1 instead of MD5.

>>> hashlib.sha1(dns_namespace.bytes + b"example.com").hexdigest()
'cfbff0d193753685568c48ce8b15ae17d93cc34c'
>>> uuid.uuid5(dns_namespace, "example.com")
UUID('cfbff0d1-9375-5685-968c-48ce8b15ae17')

thankfully, SHA-1 is the last word in hashing algorithms, it's never had problems and it's known to be very good. now to take a big sip of my coffee and check the NIST website.

NIST Retires SHA-1 Cryptographic Algorithm

The venerable cryptographic hash function has vulnerabilities that make its further use inadvisable.

NISTnist.gov/Dec 15, 2022

https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

oh. that seems bad. when is UUIDv6?

version 6

well. there's a draft RFC making updates to the UUID RFC, but it doesn't solve that problem, it solves different problems.

edit 2025-03-04: this draft has been adopted as RFC 9562, obsoleting the original RFC 4122. hell yeah.

one of the cool things about UUIDv1 is that you can decode the timestamp back out of it, and you don't need a separate field for the time when your object was created, because its ID tells you when it was created. however, the weird slicing and dicing that UUIDv1 does to the timestamp field means sorting by time is complicated, since the low 32 bits come first and the high 12 bits come last.

UUIDv6 puts the whole timestamp in order, so that the most significant bit is first.

versionvariant

1edaa9b4-e919-6172-a0d0-6721ef312724

time_hightime_midtime_lowclock sequencenode

it keeps the clock sequence as-is from v1, but it explicitly recommends using random data instead of the MAC address for the node field, which is good.

hang on, while we're messing with silly things from v1, what the hell is up with time since the gregorian calendar?

version 7

what if we just did unix timestamp and randomness, so that we had easy sorting and decoding but also uniqueness, without any bullshit.

well, v7 is that. 48 bits of unix timestamp in milliseconds (rolls over every 8920 years), 74 random bits, 6 control bits for version and variant.

versionvariant

0186443f-2c00-75fb-800a-7ec0f02a852d

timerand_arand_b

this is the real good one. the only reason not to use it is that the RFC isn't approved so it isn't quite official yet, but if you don't need to care, find an implementation in your language of choice and go to fuckin town.

edit 2025-03-04: hi it’s me from the future. i have good news: the RFC was approved. i do not have more good news than that.

but what if yolo?

version 8

if yolo, then you can use version 8. all of the version-specific fields are defined to be custom, so you can put whatever the hell nonsense you need to there.

versionvariant

b00b5101-6969-8420-9a55-676179736578

custom_acustom_bcustom_c

so what did we learn

UUIDs are pretty neat. if you need a database identifier and you get to pick something from scratch, use v7, it gives you timestamps for free. if you have things that are contextually unique and you want to turn them into universally unique IDs with a standard format, v5 is for you. if all you need is some random shit, v4 is that in the UUID format, but if you don't need the UUID format, you can also just use random bytes directly. if what you need is very specific shit nobody's thought of before, but in the UUID format, that's v8. v6 is the worse version of v7, v3 is the worse version of v5, v1 is the worse version of v6, and v2 was a mistake.

in conclusion,

UUIDs nuts.

some axes for a taxonomy of open source

2022-10-30T00:00:00Z

maintenance effort and expectations: professionally maintained / casually maintained / not maintained
source of priorities: owner-driven / community-driven
desire for input: PRs welcome / issues welcome / view-only
license standards: bare minimum / give code back / don't be evil / be specifically good
how bills get paid: not users' problem / crowdfunding / selling support / we productized the hosting so if you also productize the hosting you're being a dick

for example:

React is professionally maintained, owner-driven, PRs welcome, bare minimum, not users' problem
MongoDB is the same but give code back and we productized the hosting
SQLite is professionally maintained, owner-driven, issues welcome, bare minimum, selling support
anything that runs on github sponsors or patreon is crowdfunding
the Hippocratic License or some of the others are don't be evil
ACSL counts as be specifically good
anti-licenses are the secret fifth tier of license standards, Good Fucking Luck
some projects are actually community-driven but I can't think of one off the top of my head
most of my side projects are not maintained, owner-driven, view-only, Good Fucking Luck, and crowdfunding at the time they were written but currently not your problem.

writing balanced elevenary in the ogham script

2022-09-21T00:00:00Z

for no particular reason

digits, from negative five to positive five:

ᚅ ᚄ ᚃ ᚂ ᚁ ᚋ ᚆ ᚇ ᚈ ᚉ ᚊ

(romanized as N S F L B M H D T C Q)

radix point ᚖ (left as . when romanizing)

a few nice values: ᚆᚅᚈᚖᚆᚊᚇᚋᚅ, ᚈᚊᚇ, ᚈᚖᚇᚅᚆᚊᚆ

fuck around with it y'self:

https://codepen.io/boringcactus/pen/abGwgoG

A 2021 Survey of Rust GUI Libraries

2021-10-24T00:00:00Z

(Note from the future: I did this again in 2025.)

A year and a half ago I looked at a bunch of different Rust GUI libraries; that's a long time, so let's see if things have changed.

As before, some context:

List of libraries is drawn from Are We GUI Yet.
I work on Windows, and I am lazy; as such, any library that requires more setup on Windows than "add it to Cargo.toml" is disqualified.
I'm interested in making desktop application UIs, not game UIs. As such, I don't already have a graphics pipeline set up, so if I have to decide between vulkano and glium before I can get going, and the library documentation doesn't tell me which one is the right one to choose, I'm moving on. If you make me learn game dev before I can use your UI library, I am not the target audience for your UI library.
Accessibility should not be an afterthought. I don't currently need accessibility tools like screen readers, but some people do, and I may find myself among them at some time. I'm not experienced enough to evaluate in depth the quality of accessibility features, but I know how to turn on Windows Narrator and see if it can tell what's going on in an application window or not. If I have Hello World running in your library, but Narrator can't tell that it says Hello World, you have zero accessibility support, and therefore I have zero interest in your library.
These are all my opinions. Even if you also work on Windows and are lazy, and also don't want to learn the practical difference between Vulkan and OpenGL, and also care about accessibility, you are not me, so my opinions might not match yours.
This shit is really difficult. I've tried writing Rust bindings for wxWidgets, because I like wxPython when I'm working in Python, and for Tk, because tkinter is kinda neat too. Neither of those went anywhere, because I don't have the skill or patience to do that. All of the libraries I'm about to review were written by people who put a lot of time and energy into making them, and even if the results don't meet my needs or tastes, I'm glad they've done the work.

The short version, if you're in a hurry:

library	easy setup?	nonzero accessibility?	overall vibe check
Azul	❌
Conrod	❌
core-foundation	❌
druid	✅	❌
egui	✅	❌
fltk	✅	❌
GTK	❌
Iced	✅	❌
imgui	❌
iui	✅	✅	👍
KAS	✅	❌
lvgl	❌
native-windows-gui	✅	✅	🤷
OrbTk	✅	❌
qmetaobject-rs	❌
qt_widgets	❌
relm	❌
rust-qt-binding-generator	❌
sciter-rs	❌
SixtyFPS	✅	❌
tauri	❌
vgtk	❌
WebRender	❌

Azul

The installation guide says you need to separately download the precompiled library and make sure it's in the right folder and ughhhh that's more setup than adding it to Cargo.toml and i literally put in my rules that that's more work than i want to do. Rust already has a build system, I don't want to have to fuck with things independently of that.

Conrod

My previous adventures in Rust GUI development have led me to Conrod several times, and most of those times it's been a hassle, but we'll see if things have changed since then. The hello world tutorial appears to actually say which backends to use, which is a welcome and sorely-needed improvement.

Wait, what did that say there?

At the time of writing (September 2017),

Ok hold up, how outdated is this? It said to depend on conrod 0.55.0, but it looks like the latest version is actually 0.75.0. And there is no conrod 0.75.0, apparently, because they split the crate into several different crates as of 0.62.0; allegedly I am "most likely looking for conrod_core." So the guide, which is part of conrod_core, is so out of date that it uses the wrong name for itself. If I just use conrod_core 0.75.0 where the guide said to use conrod 0.55.0 my issues have not ceased, though:

error: failed to select a version for `conrod_core`.
    ... required by package `conrod-demo v0.1.0 (D:\Melody\Projects\misc\gui-survey-2021\conrod-demo)`
versions that meet the requirements `^0.75.0` are: 0.75.0

the package `conrod-demo` depends on `conrod_core`, with features: `glium` but `conrod_core` does not have these features.

So the officially-recommended backends don't exist anymore, or at least they no longer exist in the same way and it's my job to figure out how to get them back. I don't want to debug the official tutorial that's linked in the README. As such, Conrod appears to not be for me.

core-foundation

"Bindings to Core Foundation for macOS" are cool if I'm using macOS. As established, I'm not.

druid

Previously, druid was one of the two libraries I was most impressed by; let's see if that still holds. The "this is outdated, and should be replaced with a walkthrough of getting a simple app built and running" message in the official guide persists, and upon further inspection there's been one release since my last blog post, with few new features.

The "hello world" code in the guide has broken - something that used to take a value now takes a closure returning that value - but that's an easy fix.

A harder fix, though, is that in the official "hello world" example, Windows Narrator can't find the text "hello world". In my last post, I treated accessibility as an afterthought, to the point where I had to go in several months later and retroactively check for and add information about screen reader support; this was the wrong decision for me, and it's the wrong decision for druid. They list "Offer robust accessibility support" under their goals; maybe one day they'll get there.

egui

This is the first entry on Are We GUI Yet that wasn't there last year, and it was seeing something about this on Twitter that got me interested in revisiting this topic in the first place. There's an official template that comes with some (bash, and thereby more-painful-on-Windows, but what can you do) scripts for managing WASM builds, but I'm not interested in WASM at this point, so I'll just yoink the code and undo the multi-track drifting that allows WASM builds (which they probably don't actually need to do because wasm-bindgen can just do the right thing on binary crates due to work that i did almost exactly two years ago now, but whatever).

It runs correctly, which is good, but out of the box, Windows Narrator can't tell what's going on. There is, however, work-in-progress screen reading support which we can opt into with the screen_reader feature. Unfortunately, this appears not to do anything, at least for me with my current setup and near-zero knowledge of egui. Hopefully this becomes more robust soon.

FLTK

The presence of the fltk-bundled feature is very much appreciated. Unfortunately, it doesn't make up for a lack of screen reader accessibility.

GTK

The GTK project appears to be putting a lot of effort towards providing good Rust bindings. Unfortunately,

warning: Could not run `"pkg-config" "--libs" "--cflags" "glib-2.0" "glib-2.0 >= 2.48"`

Full disclosure: I have tried several times to get GTK 3 or 4 working for development on this computer. I have failed several times, and succeeded none. I am disinclined to try and fail again.

Iced

Iced was one of the two projects I was impressed by last time around. Unfortunately, that was before I started caring about accessibility as much; the counter example, when ran as a native binary, gives no information to Narrator.

imgui

The README doesn't have a self-contained example, but there's a hello world example that looks pretty reasonable. But that mod support; declaration looks like it's probably abstracting out some complexity, let me just—oh god my eyes that's a lot of boilerplate. Am I supposed to copy and paste all that logic into my code? If so, why is it not just part of the library already? If not, why do all the examples have it?

As stated, I don't already have a graphics pipeline set up, so I think I am not the target audience for imgui.

iui

This one's also a new addition compared to my previous writeup. And I'll be damned, it actually works! Didn't have to mess around with compilers, worked just fine with Narrator.

It's been three years since the last crates.io release, but I'm writing this in the same order you're reading it, so this is the first one I've seen that actually has any accessibility support whatsoever. If more than a handful of other libraries can clear that not-very-high bar, I'll fill in a more robust comparison, but for now this is pretty damn good.

KAS

Runs fine, doesn't give Narrator any info.

lvgl

Setting up DEP_LV_CONFIG_PATH is 1. more work than just adding it to Cargo.toml and 2. apparently some bullshit based on C header configuration??

native-windows-gui

Unsurprisingly, this works like a charm on Windows. No installation problems, no accessibility problems, no worries. It does, of course, only work on Windows, though, and I would love to wind up with code that theoretically should be cross-platform.

OrbTk

Works, no accessibility.

qmetaobject-rs

Error: Failed to execute qmake. Make sure 'qmake' is in your path!

qt_widgets

failed to run command: "qmake" "-query" "QT_VERSION"

relm

LINK : fatal error LNK1181: cannot open input file 'gtk-3.lib'

rust-qt-binding-generator

installing Qt is more work than i want to have to do.

sciter-rs

downloading the SDK independent of Cargo is more work than i want to have to do.

SixtyFPS

works, no accessibility

Tauri

whatever the hell any of this is is more work than i want to have to do. it looks like this wants you to have both npm/yarn and Cargo? and i don't think i like the implications of that.

vgtk

Could not run `"pkg-config" "--libs" "--cflags" "glib-2.0" "glib-2.0 >= 2.44"`

WebRender

what the goddamn hell is this supposed to be?

the basic example is doing shader fuckery! that doesn't seem basic to me!

summary

Well, shit. Turns out if you want low-fuss Windows setup, nonzero accessibility, and theoretical cross-platform support, and you want them in the present rather than the future, there's only one option (at least among the things listed on Are We GUI Yet). Shout out to iui, in all its three-year-old-latest-release no-way-to-draw-images(-at-least-that-I-can-find) glory. Honorable mention to egui for having put in at least some effort towards accessibility; if I revisit this topic in another year or two, I suspect I'll be very impressed with egui. Additional reference to SixtyFPS who have made an entire other markup language for specifying UI structure; I'm not sure it's a good or necessary approach, but it's eye-catching, and maybe at some point they'll start working on accessibility and I'll take a more thorough look. (I'm not entirely sure the extent to which German and/or EU law requires commercial products meet accessibility standards, but if SixtyFPS is doing commercial licensing, they'd better have looked into that.)

whining

I've worked with Python and Rust a lot, and those are my two languages of choice for new personal projects these days. Python, as an interpreted language, does not really go out of its way to give you binaries that you can just hand to end users; it's possible, but as of the last time I checked, the tools were all varying shades of pains in the ass to use. Rust seems like it'd be far better suited for end-user application development, since at the end you have a .exe or whatever that you can hand off to anybody. It looks like the Rust ecosystem doesn't really have a solid foundation for GUI development, despite being a good language for GUI development. Python is set up such that it's easier to write tools for other developers (who are likely to have a Python interpreter installed) than for end users (who are not), and developers tend to prefer CLI programs to GUI ones, so it would be reasonable to expect GUI tools in Python to be worse than they are in Rust, right?

Let's check in on that:

# after `pip install wxPython` and no other fuckery:
import wx
app = wx.App()
frame = wx.Frame(None, title="wxPython Example")
panel = wx.Panel(frame)
text = wx.StaticText(panel, label="Hello World!")
frame.Show()
app.MainLoop()

This was easy to set up on Windows, correctly provides accessibility data to Windows Narrator, and was really concise to implement. So if I want a nice, powerful, elegant GUI library without losing my mind trying to set it up, I can have that, as long as I don't need other people to be able to conveniently run the program I make. How the goddamn fuck did we get here?

Unfortunately, I know the answer to that one. wxWidgets, the library wxPython is binding to, is a C++ library that is used primarily by inheriting from wxWidgets's classes. Rust bindings to C++ libraries are difficult to create in the best of scenarios, and inheritance is among the worst of scenarios, because Rust does not have any concepts to which C++ inheritance maps cleanly. The wxPython bindings are maintained by the wxWidgets team themselves, and Python is designed to be extended by C/C++ code. Rust's FFI with C is fine, but bindgen is really bad at handling C++ as used by wxWidgets, and manually authoring the thousands of bindings and then providing a safe abstraction over them would be extraordinarily not a good time.

So if wxWidgets isn't feasible to use from Rust, what about some other library? Well, the only reason wxPython is as easy to install as it is is that the maintainers made sure it comes with the fully-compiled wxWidgets binaries, especially on Windows where everything of that sort is harder to do by hand after the fact. Some Rust bindings to C libraries, like SDL2 or the aforementioned FLTK, will build the libraries they depend on automatically, encapsulating all that complexity and letting me just use them; most, like GTK, do not. I'm not sure if there's a technical reason gtk-rs and the rest of these can't do that (or, for bonus points, just download a precompiled binary from the official releases and save a bunch of time), or if it's just that nobody's asked for it. Linux (and to some extent Mac I suppose) devs are accustomed to niceties like pkg-config and actual package managers that make it easy to install a C library; on Windows, we don't have that (unless we're working inside MSYS2 or what have you, but that's its own mess sometimes). So please: if you're writing Rust bindings to a C library, do your Windows users a favor, and give us a bundled feature.

An Anti-License Manifesto

2021-09-29T00:00:00Z

software licenses are unavoidably a legal tool. the legal system, in the US and approximately everywhere else, is not a machine that leads to justice. therefore, software licenses do not lead to justice.

we cannot software license our way to a better world. as such, we should and must software license our way to a stranger world. permissive licenses and copyleft licenses are both tools of the corporate status quo. we therefore reject all conventional software licenses, and instead champion the weird, the experimental, the decorative, the hostile, the absurd, the useless, the straight up unhinged.

some anti-licenses:

How to Develop a Deeply Unhealthy Relationship with Twitter

2021-05-25T00:00:00Z

Follow some cool people on Twitter.
Spend time on Twitter.
See a cool person quote tweet some dipshit to be mad about them, or retweet a reply to some dipshit that dunks on or dismantles them, or say something controversial yet correct where you just know a bunch of the replies and quote tweets are going to be dipshits.
Think to yourself "damn, it sucks that people on here are being dipshits. but hey, if I block all these people now, I'll never have them show up in my mentions later"
Read through all the immediate (and, if your brain decides to, several levels deep) context, finding and blocking dipshits as they come up.
Repeat steps 3-5 several times. Importantly, never only do step 3, so that the subsequent quest to block all dipshits attaching themselves to the original tweet becomes a habit, and then a reflex, rather than a deliberate decision.
Get mad that you keep seeing dipshits doing dipshit things on Twitter. Consider leaving, but then say "but the cool people are here! hell am I gonna do, convince them to stop arguing with dipshits and posting takes that dipshits will disagree with?" Forget that you have any other options.
Wait for Discourse, when arguing and dipshittery are ubiquitous.
Reflexively seek out all the dipshits swarming around every time you see a new Discourse-related tweet.
Be miserable on Twitter because your experience is overwhelmingly dominated by seeing dipshits being wrong and obnoxious, because you built a habit of seeking those dipshits out in the first place.

In conclusion, as Fraxiom put it in food house's "8 now",

I need to delete Twitter 'cause it gives me fucking mental illness

Non-FSF Copyleft Usage

2021-03-24T00:00:00Z

The Free Software Foundation has decided they'd rather hang out with a sex pest than have an ounce of credibility, so fuck em. Let's look at the copyleft licenses they didn't write and see how they're used.

I'll be using the Blue Oak Council's list of copyleft licenses here, because I don't know of a good other way to find specifically copyleft licenses. I'll be searching GitHub for filename:LICENSE "<some snippet from the license>" or checking Wikipedia and then seeing if anything notable turns up.

Maximal Copyleft

Cryptographic Autonomy License: almost entirely cryptocurrency bullshit
Parity Public License: maintains its own list of users, including some work from substack (original author of browserify, prominent in the node.js scene, name stolen by a shitty newsletter startup) and some Git hook manager with 22.2k stars on GitHub (although it's only Parity licensed while it's in early access, and it'll revert to MIT later on). so there's a notable person and a notable project using this license, which is neat.
Reciprocal Public License: well, there's "the most popular service bus for .NET", but that appears to be basically it.

Network Copyleft

Affero GPL: fuck GNU, fuck the FSF, fuck RMS, fuck you
Apple Public Source License: unsurprisingly, the only use I've seen is for stuff derived directly from Apple releases
Common Public Attribution License: apparently it was invented by some startup that hasn't existed since 2012, and I could only find one nontrivial use of it
European Union Public License: well, there's "dig but i rewrote it in rust" and there's Pi-hole (actually neat!) but that's about it. i think being the pi-hole license (plus having a metagovernment behind it) would probably be enough to ensure its longevity.
Non-Profit Open Software License: GitHub can't find any usage of it!
Open Software License: it's got Magento (WordPress for ecommerce) and that's about it
RealNetworks Public Source License: ehhhhh I am officially ignoring any license with a mostly-defunct vendor in the title now

Strong Copyleft

BSD Protection: nothing uses this
CC BY-SA: that's not a software license, you can't fool me
GPL: fuck that
Q Public License: this name has aged poorly and i can't find use of it
Sleepycat License: adorable! but not used by anything

Weak Copyleft

Common Development and Distribution License: apparently this is popular with enterprisey bullshit because it started at Sun but it seems like it's mostly enterprisey bullshit
Common Public License: this one's IBM's, so there's even less usage
Eclipse Public License: well, there's Eclipse, but also a lot of other non-enterprise-bullshit (mostly Java) stuff apparently
Erlang Public License: even Erlang doesn't use it anymore lol
IBM Public License: ehhhhhhhh
LGPL: fuck that
Mozilla Public License: lots of users, probably not going anywhere anytime soon
Microsoft Reciprocal License: not really widely used, unsurprisingly
Sun Public License: apparently it's the older, worse CDDL

Summary

for maximal copyleft ("must publish source, even if only changing for internal use"), Parity is probably the most promising future license.

for network copyleft ("must offer source to users even across a network"), the European Union Public License is already seeing some adoption.

for "strong" copyleft ("must offer source to users even if just linking as a library"), there are no good options because the GPL has been the only game in town for ages.

for "weak" copyleft ("must offer source to users"), the Mozilla Public License looks like it has a good chance of continuing to exist and be used by actual projeccts for a nice long while.

Cactus's Obvious, Intuitive Naming Scheme

2021-03-21T00:00:00Z

It's well-established that naming things is one of the two hardest problems in computer science (along with cache invalidation and off-by-one errors). So I solved naming. If you've got a project that needs a name, here you go.

The ingredients are simple:

Your name.
The word "obvious".
A good adjective.
The kind of thing you've made.

The canonical example, from which this scheme was reverse-engineered, is Tom's Obvious, Minimal Language. People who haven't used TOML might think that "obvious" is functioning here to describe the language, but various attributes of TOML (non-ASCII keys requiring quotes, substantial distinctions between single- and double-quoted strings, array-of-tables syntax) indicate that "obvious" is merely part of the name template rather than an actual descriptor.

As an example, we can construct a name for this approach to assigning names to things. My name is cactus (for some value of "name", and for that matter "my"), it would be good if this was intuitive, and this is a naming scheme. As such, the name this process assigns to itself is "Cactus's Obvious, Intuitive Naming Scheme", which abbreviates nicely to "COINS".

We can also construct COINS names for other things:

Despite the fact that Tom's Obvious, Minimal Language inspired this naming scheme, it actually suffers greatly from having used it. If I ever get my hands on a time machine, I will go back and tell Tom to call it "My INI-Like Format" instead.

Can We Please Move Past Git?

2021-02-22T00:00:00Z

Git is fundamentally a content-addressable filesystem with a VCS user interface written on top of it.

— Pro Git §10.1

Most software development is not like the Linux kernel's development; as such, Git is not designed for most software development. Like Samuel Hayden tapping the forces of Hell itself to generate electricity, the foundations on which Git is built are overkill on the largest scale, and when the interface concealing all that complexity cracks, the nightmares which emerge can only be dealt with by the Doom Slayer that is Oh Shit Git. Of course, the far more common error handling method is start over from scratch.

Git is bad. But are version control systems like operating systems in that they're all various kinds of bad, or is an actually good VCS possible? I don't know, but I can test some things and see what comes up.

Mercurial

Mercurial is a distributed VCS that's around the same age as Git, and I've seen it called the Betamax to Git's VHS, which my boomer friends tell me is an apt analogy, but I'm too young for that to carry meaning. So let me see what all the fuss is about.

Well, I have some bad news. From the download page, under "Requirements":

Mercurial uses Python (version 2.7). Most ready-to-run Mercurial distributions include Python or use the Python that comes with your operating system.

Emphasis theirs, but I'd have added it myself otherwise. Python 2 has been dead for a very long time now, and saying you require Python 2 makes me stop caring faster than referring to "GNU/Linux". If you've updated it to Python 3, cool, don't say it uses Python 2. Saying it uses Python 2 makes me think you don't have your shit together, and in fairness, that makes two of us, but I'm not asking people to use my version control system (so far, at least).

You can't be better than Git if you're that outdated. (Although you can totally be better than Git by developing a reputation for having a better UI than Git; word of mouth helps a lot.)

Subversion

I am a fan of subverting things, and I have to respect wordplay. So let's take a look at Subversion (sorry, "Apache® Subversion®").

There are no official binaries at all, and the most-plausible-looking blessed unofficial binary for Windows is TortoiseSVN. I'm looking through the manual, and I must say, the fact that branches and tags aren't actually part of the VCS, but instead conventions on top of it, isn't good. When I want to make a new branch, it's usually "I want to try an experiment, and I want to make it easy to give up on this experiment." Also, I'm not married to the idea of distributed VCSes, but I do tend to start a project well before I've set up server-side infrastructure for it, and Subversion is not designed for that sort of thing at all. So I think I'll pass.

You can't be better than Git if the server setup precedes the client setup when you're starting a new project. (Although you can totally be better than Git by having monotonically-ish increasing revision numbers.)

Fossil

Fossil is kinda nifty: it handles not just code but also issue tracking, documentation authoring, and a bunch of the other things that services like GitHub staple on after the fact. Where Git was designed for the Linux kernel, which has a fuckton of contributors and needs to scale absurdly widely, Fossil was designed for SQLite, which has a very small number of contributors and does not solicit patches. My projects tend to only have one contributor, so this should in principle work fine for me.

However, a few things about Fossil fail to spark joy. The fact that repository metadata is stored as an independent file separate from the working directory, for example, is a design decision that doesn't merge well with my existing setup. If I were to move my website into Fossil, I would need somewhere to put boringcactus.com.fossil outside of D:\Melody\Projects\boringcactus.com where the working directory currently resides. The documentation suggests ~/Fossils as a folder in which repository metadata can be stored, but that makes my directory structure more ugly. The rationale for doing it this way instead of having .fossil in the working directory like .git etc. is that multiple checkouts of the same repository are simpler when repository metadata is outside each of them. Presumably the SQLite developers do that sort of thing a lot, but I don't, and I don't know anyone who does, and I've only ever done it once (back in the days when the only way to use GitHub Pages was to make a separate gh-pages branch). Cluttering up my filesystem just so you can support a weird edge case that I don't need isn't a great pitch.

But sure, let's check this out. The docs have instructions for importing a Git repo to Fossil, so let's follow them:

PS D:\Melody\Projects\boringcactus.com> git fast-export --all | fossil import --git D:\Melody\Projects\misc\boringcactus.com.fossil
]ad fast-import line: [S IN THE

Well, then. You can't be better than Git if your instructions for importing from Git don't actually work. (Although you can totally be better than Git if you can keep track of issues etc. alongside the code.)

Darcs

Darcs is a distributed VCS that's a little different to Git etc. Git etc. have the commit as the fundamental unit on which all else is built, whereas Darcs has the patch as its fundamental unit. This means that a branch in Darcs refers to a set of patches, not a commit. As such, Darcs can be more flexible with its history than Git can: a Git commit depends on its temporal ancestor ("parent"), whereas a Darcs patch depends only on its logical ancestor (e.g. creating a file before adding text to it). This approach also improves the way that some types of merge are handled; I'm not sure how often this sort of thing actually comes up, but the fact that it could is definitely suboptimal.

So that's pretty cool; let's take a look for ourselves. Oh. Well, then. The download page is only served over plain HTTP - there's just nothing listening on that server over HTTPS - and the downloaded binaries are also served over plain HTTP. That's not a good idea. I'll pass, thanks.

You can't be better than Git while serving binaries over plain HTTP. (Although you can totally be better than Git by having nonlinear history and doing interesting things with patches.)

Pijul

Pijul is (per the manual)

the first distributed version control system to be based on a sound mathematical theory of changes. It is inspired by Darcs, but aims at solving the soundness and performance issues of Darcs.

Inspired by Darcs but better, you say? You have my attention. Also of note is that the developers are also building their own GitHub clone, which they use to host pijul itself, which gives a really nice view of how a GitHub clone built on top of pijul would work, and also offers free hosting.

The manual gives installation instructions for a couple Linuces and OS X, but not Windows, and not Alpine Linux, which is the only WSL distro I have installed. However, someone involved in the project showed up in my mentions to say that it works on Windows, so we'll just follow the generic instructions and see what happens:

PS D:\Melody\Projects> cargo install pijul --version "~1.0.0-alpha"
    Updating crates.io index
  Installing pijul v1.0.0-alpha.38
  Downloaded <a bunch of stuff>
   Compiling <a bunch of stuff>
error: linking with `link.exe` failed: exit code: 1181
  |
  = note: "C:\\Program Files (x86)\\Microsoft Visual Studio\\2019\\BuildTools\\VC\\Tools\\MSVC\\14.27.29110\\bin\\HostX64\\x64\\link.exe" <lots of bullshit>
  = note: LINK : fatal error LNK1181: cannot open input file 'zstd.lib'


error: aborting due to previous error

So it doesn't work for me on Windows. (There's a chance that instructions would help, but in the absence of those, I will simply give up.) Let's try it over on Linux:

UberPC-V3:~$ cargo install pijul --version "~1.0.0-alpha"
<lots of output>
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" <a mountain of arguments>
  = note: /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lzstd
          /usr/lib/gcc/x86_64-alpine-linux-musl/9.3.0/../../../../x86_64-alpine-linux-musl/bin/ld: cannot find -lxxhash
          collect2: error: ld returned 1 exit status


error: aborting due to previous error
UberPC-V3:~$ sudo apk add zstd-dev xxhash-dev
UberPC-V3:~$ cargo install pijul --version "~1.0.0-alpha"
<lots of output again because cargo install forgets dependencies immediately smdh>
   Installed package `pijul v1.0.0-alpha.38` (executable `pijul`)

Oh hey, would you look at that, it actually worked, and all I had to do was wait six months for each compile to finish (and make an educated guess about what packages to install). So for the sake of giving back, let's add those instructions to the manual, so nobody else has to bang their head against the wall like I'd done the past few times I tried to get Pijul working for myself.

First, clone the repository for the manual:

UberPC-V3:~$ pijul clone https://nest.pijul.com/pijul/manual
Segmentation fault

Oh my god. That's extremely funny. Oh fuck that's hilarious - I sent that to a friend and her reaction reminded me that Pijul is written in Rust. This VCS so profoundly doesn't work on my machine that it manages to segfault in a language that's supposed to make segfaults impossible. Presumably the segfault came from C code FFId with unsafe preconditions that weren't met, but still, that's just amazing.

Update 2021-02-24: One of the Pijul authors reached out to me to help debug things. Apparently mmap on WSL is just broken, which explains the segfault. They also pointed me towards the state of the art in getting Pijul to work on Windows, which I confirmed worked locally and then set up automated Windows builds using GitHub Actions. So if we have a working Pijul install, let's see if we can add that CI setup to the manual:

PS D:\Melody\Projects\misc> pijul clone https://nest.pijul.com/pijul/manual pijul-manual
✓ Updating remote changelist
✓ Applying changes       47/47
✓ Downloading changes    47/47
✓ Outputting repository

Hey, that actually works! We can throw in some text to the installation page (and more text to the getting started page) and then use pijul record to commit our changes. That pulls up Notepad as the default text editor, which fails to spark joy, but that's a papercut that's entirely understandable for alpha software not primarily developed on this OS. Instead of having "issues" and "pull requests" as two disjoint things, the Pijul Nest lets you add changes to any discussion, which I very much like. Once we've recorded our change and made a discussion on the repository, we can pijul push boringcactus@nest.pijul.com:pijul/manual --to-channel :34 and it'll attach the change we just made to discussion #34. (It appears to be having trouble finding my SSH keys or persisting known SSH hosts, which means I have to re-accept the fingerprint and re-enter my Nest password every time, but that's not the end of the world.)

So yeah, Pijul definitely still isn't production-ready, but it shows some real promise. That said, you can't be better than Git if you aren't production-ready. (Although you can totally be better than Git by having your own officially-blessed GitHub clone sorted out already.) (And maybe, with time, you can be eventually better than Git.)

what next?

None of the existing VCSes that I looked at were unreservedly better than Git, but they all had aspects that would help beat Git.

A tool which is actually better than Git should start by being no worse than Git:

allow importing existing Git repositories
don't require Git users to relearn every single thing - we already had to learn Git, we've been through enough

Then, to pick and choose the best parts of other VCSes, it should

have a UI that's better, or at least perceived as better, than Git's - ideally minimalism and intuitiveness will get you there, but user testing is gonna be the main thing
avoid opaque hashes as the primary identifier for things - r62 carries more meaning than 7c7bb33 - but not at the expense of features that are actually important
go beyond just source code, and cover issues, documentation wikis, and similar items, so that (for at least the easy cases) the entire state of the project is contained within version control
approach history as not just a linear sequence of facts but a story
offer hosting to other developers who want to use your VCS, so they don't have to figure that out themselves to get started in a robust way

And just for kicks, a couple of extra features that nobody has but everybody should:

the CLI takes a back seat to the GUI (or TUI, I guess) - seeing the state gets easier that way, discovering features gets easier that way, teaching to people who aren't CLI-literate gets easier that way
contributor names & emails aren't immutable - trans people exist, and git filter-graph makes it about as difficult to change my name as the state of Colorado did
if you build in issue/wiki/whatever tracking, also build in CI in some way
avoid internal jargon - either say things in plain $LANG or develop a consistent and intuitive metaphor and use it literally everywhere

I probably don't have the skills, and I certainly don't have the free time, to build an Actually Good VCS myself. But if you want to, here's what you're aiming for. Good luck. If you can pull it off, you'll be a hero. And if you can't, you'll be in good company.

Every President Sucked

2021-02-15T00:00:00Z

(Not exhaustive; based on cursory readings of parts of Wikipedia articles.)

Washington thought it was morally acceptable to own human beings as property.

Adams signed the Alien and Sedition Acts, which were xenophobic and authoritarian.

Jefferson thought it was morally acceptable to own human beings as property.

Madison thought it was morally acceptable to own human beings as property.

Monroe thought it was morally acceptable to own human beings as property.

Quincy Adams thought partisanship could be solved by appointing his enemies to office (but aside from that he seems pretty decent).

Jackson thought it was morally acceptable to own human beings as property, and was extremely enthusiastic about Native American genocide.

Van Buren thought it was morally acceptable to own human beings as property.

Harrison thought it was morally acceptable to own human beings as property.

Tyler thought it was morally acceptable to own human beings as property.

Polk thought it was morally acceptable to own human beings as property.

Taylor thought it was morally acceptable to own human beings as property.

Fillmore signed the Compromise of 1850, which had numerous elements which propagated slavery, and wound up attached to the Know-Nothing Party.

Pierce supported the illegitimate pro-slavery government of the Kansas Territory.

Buchanan encouraged the Supreme Court's decision in Dred Scott v Sandford that the Constitution does not apply to Black people.

Lincoln

ran on a platform of allowing slavery to continue in the states where it already existed
reversed Frémont's emancipation order in Missouri in the early months of the Civil War
rejected the Radical Republicans' pressure to immediately and uncompromisingly abolish slavery
suppressed a Native American uprising
was generally a moderate on issues where moderation is unacceptable.

Johnson

opposed federal protections for voting rights of former slaves
undermined the work of the Freedmen's Bureau
vetoed civil rights protections
generally did everything he could to fuck up Reconstruction.

Grant

gave amnesty to former Confederates that allowed them to hold government office
signed the Comstock Act which suppressed both educational and erotic speech about sex
appointed zero Native Americans to the Board of Indian Commissioners
approved of the erasure of Native culture
started treating Native tribes as subordinate to the US instead of independent and sovereign

Hayes

sent the military in to suppress strikes
continued Grant's cultural assimilation of Native Americans
opened the door for immigration restrictions based on country of origin

Garfield

felt gross about racial political equality
fucking died lmfao get rekt

Arthur

restricted immigration in some racist & ableist ways
gave us the "public charge rule" that's used to deny immigration rights to people who might rely on welfare
strengthened federal territory polygamy bans (fuck the Mormons, but like. my polyamorous ass would prefer to have my options open)
opened up Native American reservations to settlers

Cleveland

fucked up the linear timeline of presidents
vetoed a bunch of welfare
didn't enforce civil rights protections
fucked over Chinese immigrants
approached relationship with Native Americans as guardianship, not diplomacy
sent in the military to break up a railroad strike, killing 30 people
approved of the Supreme Court's "separate but equal" decision in Plessy v Ferguson

Harrison

didn't do anything about the Wounded Knee Massacre
opened more Native American land to settlers
tried to annex Hawaii, backed a coup against the queen, recognized the illegitimate government

McKinley

didn't bother enforcing antitrust laws
didn't bother opposing Jim Crow laws
finished the annexation of Hawaii
fucked everything up after kicking Spain's ass in the Spanish-American War:
- ignored the independent government in Cuba, set up a military government instead
- went to war with the independent government in the Philippines, sent Taft to take over
- set up military governments in Puerto Rico and Guam, left them with "unincorporated territory" status so people who live there don't have full constitutional rights
generally an imperialist dipshit
lmao Czołgosz got his ass, pour one out for a real one

Roosevelt

didn't really do much good for civil rights
more imperialism
shenanigans around the construction of the Panama Canal
more racist immigration bullshit

Taft

caved to racists demanding positions be filled with white people
more racist immigration bullshit
fuckery in Nicaragua

Wilson

lots of racism
drafting people for WW1
oppressing dissent against WW1, including fucking over Eugene V. Debs
did i mention the racism
the dude literally supported segregation
like. he told Black military members "segregation is not a humiliation but a benefit, and ought to be so regarded by you gentlemen."
constantly intervening in Latin American governments
sent troops to fuck with the Bolsheviks mid-Revolution
didn't recognize the Russian Soviet Republic
and also the racism

Harding

bullshit immigration restrictions
opposed federal unemployment benefits
opposed racial integration socially
kept Wilson's segregation
rolled back antitrust stuff
lots of corruption and scandal

Coolidge

more fuckin immigration restrictions
avoiding antitrust enforcement
proto-supply-side trickle-down tax cuts

Hoover

enforced Prohibition
fucked up response to the Great Depression
removed Black leaders from the Republican party to court racists in the South
more goddamn immigration bullshit! kicking out Mexican-American citizens! ethnic cleansing!
sent the Army in to fuck up some veterans who were protesting for prompt payment

Roosevelt

Japanese internment
immigration fuckery
not accepting Jewish refugees

Truman

nuking Japan
purged communist sympathizers

Eisenhower

CIA coups in Iran and Guatemala
pretended Castro didn't exist
mass deportations
didn't stop McCarthy
started COINTELPRO
wasn't really on board with desegregation
institutional homophobia

Kennedy

invasion of Vietnam, with all the attending war crimes and bullshit
Bay of Pigs Invasion
CIA fuckery all over the place in opposition to leftism
military alliance with a post-Suez-Crisis expansionist Israel
took a while to start proactively protecting civil rights

Johnson

expansion of Vietnam War
spying on anti-war movement
fuckery in Dominican Republic

Nixon

i mean. c'mon. he's mainly remembered for Watergate, the scandal so big we name all our other scandals after it.
opposed to forced integration
prosecuted the Chicago Seven
suppressed the Pentagon Papers
let Kissinger do heinous Kissinger shit in Cambodia
fucked over Allende, supported Pinochet's bullshit oppressive regime
didn't end the Vietnam War

Ford

pardoned Nixon
fucked over Vietnam, presumably butthurt that the US lost
kept Kissinger around
supplied Indonesia for its invasion of East Timor and fuckery therein
didn't die

Carter

opposed universal health care
continued support for oppressive regimes in Saudi Arabia, Iran, etc
sheltered the Shah of Iran from justice
fucked up the rescue mission in the Iran hostage crisis

Reagan

racism
supply-side economics
anti-communism
put Scalia on the supreme court
recovered from an assassination attempt
broke the air traffic controller strike
heightened the war on drugs
didn't take AIDS or gay rights seriously
propped up oppressive regimes in Latin America
Iran-Contra
allied with apartheid South Africa

Bush

didn't retract nomination of Clarence Thomas after Anita Hill spoke out
invaded Panama to overthrow the CIA stooge who had previously been in charge
sent Kissinger to negotiate with China
tried to make it illegal to burn the flag
pardoned the Iran-Contra people

Clinton

welfare reform (the bad kind)
deregulated banking, energy, and telecom
settled for "don't ask don't tell"
signed DOMA
extended copyright
workplace sexual misconduct
mass incarceration

Bush

lied about WMDs in Iraq
"war on terror"
Patriot Act
Abu Ghraib
Gitmo
blamed Israeli-Palestinian tension on the Palestinians
fucked up the response to Hurricane Katrina
doesn't care about black people
tried to privatize Social Security

Obama

frequent use of sanctions as warfare
let the feds do a bunch of evil shit in Ferguson etc
did not withdraw from Iraq and Afghanistan
prevented UN from calling for a Palestinian state
increased aid to Israel
didn't close Gitmo
extensive drone strikes, lots of civilian casualties, blew up a damn hospital, extrajudicially murdered a US citizen on purpose
continued supporting Saudi Arabia despite fuckin heinous shit
mass surveillance, defense of PRISM, extension of the Patriot Act
war on whistleblowers (Manning and Snowden should both have been pardoned fuckin instantly)
fucktons of deportation

Trump

bro do i even gotta list this shit

Biden, for the like month he's been in there so far

backed down from $2000 fuckin instantly
appointed a bunch of liberal centrist dipshits in his cabinet
he's a goddamn rapist
let Fauci keep his job after lying to the public about COVID

happy (slightly late) presidents' day!

Not "Any Purpose"

2021-02-11T00:00:00Z

A program is free software if the program's users have the four essential freedoms:

The freedom to run the program as you wish, for any purpose (freedom 0).

– the Free Software Definition, emphasis mine

Goddamn, what the fuck?
What the fuck, what the fuck?
Goddamn, what the fuck?
What the fuck?
Goddamn, what the fuck
What the fuck, what the—
What the fuck? What the fuck? What the fuck?

– 745 sticky (Black Dresses Remix)

My previous post on post-open source appeared to resonate with a lot of people, but unsurprisingly, not much has changed since then. Recently, the company Elastic, who makes the database Elasticsearch, changed the license on Elasticsearch from Apache to the Server-Side Public License, which (to oversimplify the analysis of the excellent Kyle E. Mitchell) is AGPL but even more so. And unsurprisingly, as happened with Redis and MongoDB before it, everyone got mad. When I wrote this snippet of my post-open source post, I was referring to Redis, but it's the exact same playbook that's happening again now:

you made a cool database server that's under an open source license? amazon's selling it as a service now, and they're not paying you a fuckin dime. you want to change your license to stop them from doing that? now the open source people are yelling at you, because when they say they're apolitical they mean they support the status quo. and the free software people are also yelling at you, because you didn't do it their way with their license, you did it a different way with a different license, and that goes against amazon's freedom to screw you over.

So we're back here again. Open source ideology leads to intra-corporate exploitation, the exploitees want to get out from under the exploiters, everyone gets mad that the status quo has been upset, and Amazon forks the last permissively-licensed version of the software and laughs all the way to the bank. The only way for Elastic to win would've been to have licensed Elasticsearch under something restrictive like the SSPL from day one.

But since they didn't, we get shit like this:

Capitalism concerns itself with making monopolies — FOSS instead concerns itself with the socialized creation of software wealth.

– some jackass who loves being wrong on the internet

FOSS is not socialist. The free software movement is right-libertarian / "anarcho"-capitalist, and the open source movement is neoliberal; neither of these is even particularly close to socialism. If you want a software ideology that is actually opposed to capitalism, instead of sucking up to capital, you might be looking for the Anti-Capitalist Software License. It's good, it links to my previous writing on post-open source (and the Fuck Around and Find Out License), and the FSF hate it:

The Anti-Capitalist Software License is a nonfree license because it extends the four freedoms only to some kinds of organizations, not to all. Such a restriction in a software license, in the name of any cause whatsoever, imposes too much power over users. Please don't use this license, and we urge you to avoid any software that has been released under it.

What's not to love! As an author of some software released under the Anti-Capitalist Software License, I also urge people who take the FSF seriously to avoid my software which has been released under the ACSL. And my software released under any other license. And just me in general.

Unsurprisingly, Richard M. Stallman (the "M" stands for "Making female students extremely uncomfortable for 30 years") has done some handwringing about the vital importance of Freedom 0's "for any purpose" that we can make fun of. Essentially, his points are

enforcement against governments or big corporations is impossible because they can just make excuses and dodge jurisdiction and accountability
for small stuff, ethics vary, so if we accept a thousand orthogonal usage restrictions ("only this music genre", "can't be used in meat processing because i'm vegan", etc) we'll have a shitshow of an ecosystem and everyone will just give up and go back to using "nonfree" software
who are we as developers to even tell users what they can and can't do with our software? you wouldn't buy a pen that had a "you can't use this pen to do X" on it, right? that'd be ridiculous!

First, lmao, "don't bother doing this because enforcement is impossible" applies equally to copyleft and the GPL in general. Second, if we set aside masturbatory trolling bullshit like Bruce Perens's "Vaccine License", nobody makes licenses that are that narrowly tailored to one specific thing - and even the Vaccine License is still a world away from a hypothetical Country Music Only License or Vegan Software License or what have you. This is a textbook slippery slope argument, and if you think "you can't use this software to violate human rights" is anywhere near "you can't use this software to listen to BTS" then fuck all of the way off. (Although, one time I mentioned on IRC that I was throwing a simple script together in Python, and someone said "Hopefully it's Python 2, but if not I'll just rewrite it in Python 2", so I threw together the Why The Fuck Would You Even Do That Holy Shit Public License to prohibit exactly that.) Third, god damn libertarians hate when anyone tells them that some actions are bad. If I was going to buy a pen, and I saw that it had a "hey, don't use this pen to violate human rights" sticker on it, I would go "fair enough I guess" and just buy the damn pen.

The libertarian position here is that toolmakers should have no say in how those tools are used, and the only way they should control what can be done with their tools is by directly adding or removing capabilities from the tools. Unsurprisingly, the libertarian position here is bullshit. A tool is not a morally neutral thing, and toolsmithing is not an act which must by necessity end when the tool leaves the smith's hands.

Let me now list some of the ethical principles from the ACM Code of Ethics:

A computing professional should...

Contribute to society and to human well-being, acknowledging that all people are stakeholders in computing.

Avoid harm.

Be honest and trustworthy.

Be fair and take action not to discriminate.

Respect the work required to produce new ideas, inventions, creative works, and computing artifacts.

Points 1 and 2 are broadly aligned with the idea that software should be used for good, and point 5 suggests that authors should be compensated for their work. As such, ethical restrictions in software licenses are perfectly compatible with this code of ethics, as are restrictions on commercial use. It is possible to go even further than this, and I think I will, because I'm in the mood to start some fights:

In my view, it conflicts with the ACM Code of Ethics to release software under a license which permits ethical misconduct and economic exploitation.

Crowbar: Turns out, language development is hard

2020-10-19T00:00:00Z

(Previously in Crowbar: Defining a good C replacement, Simplifying C's type names)

Originally, I hadn't decided whether Crowbar should be designed with an eye towards compiling to C or with an eye towards compiling directly. Compiling to C massively cuts down the scope of Crowbar as a project, but compiling directly gives me more comprehensive control over what all happens.

I figured I wouldn't need comprehensive control over everything, so I chose compiling to C, and then almost immediately ran into a pile of issues that compiling to C brings with it.

libc is part of the problem

One of the goals I had for Crowbar was memory safety - most of the footguns in C are of the dubious-memory-operations variety - but it turns out you can't just duct tape memory safety to an existing language and call it a day. Among the most easily-exploited class of dubious memory operations is the buffer overflow, and the most straightforward fix is bounds checking.

However, most of the C standard library doesn't perform bounds checking, because the C standard library was designed in the 1600s when every CPU cycle took six months and compiler optimizations hadn't been invented yet.

The C11 specification actually defines bounds-checking-performing alternatives to some of the standard library APIs, but it's optional (filed away in Annex K) and fuckin nobody can be bothered to implement it. Some of the spec authors wrote a whole investigation of why nobody uses Annex K, and it all boils down to "error handling in C is broken-by-default" - which is the other big issue Crowbar will have to solve, and I haven't even begun to think about how to do that.

But. We live in a world where C already exists in all its mixed glory, and in that world, nothing supports Annex K. There exist some tacked-on implementations, but the most complete-looking one is licensed under the regular GPL, not even the LGPL, which would be a problem for a lot of software. So if I want Crowbar to be designed to compile into C, I need to either reimplement Annex K my damn self or design some equivalent APIs and implement those.

In either case, now Crowbar has a runtime library on top of libc, and nobody's going to already have it so it'll have to figure out how to ensure that its runtime library is available wherever needed. And that's a pain in the ass.

you can't win

Okay, so if compiling to C would still require a runtime library, and ensuring that the runtime library still worked in mixed-Crowbar-and-C and fully-Crowbar projects without requiring system-wide installation or anything would be a nuisance, why not just simplify some things and skip over C?

Well, for an ordinary language, that'd work rather well, which is why fucking nothing uses C as a compile target. But one of the nonnegotiable goals of Crowbar is to have low- or no-effort C interoperability. As such, you need to be able to include regular C headers. But loading and parsing regular C headers means the Crowbar compiler needs to be able to understand all of C, and either implement or shell out to a C preprocessor that can use conventional command line arguments to define include directories. And if the compiler has to encompass all of the complexity of C, then Crowbar just went from a subset of C to a superset of C. I do not want to write a C compiler. If Crowbar is supposed to be simpler than C, then writing a Crowbar compiler should be simpler than writing a C compiler, not more complicated.

So compiling to C creates problems, and compiling not-to-C creates problems. This sucks. Send help.

No, seriously, if you have advice, even if it's just "well I'd probably do this because it seems more intuitive to me", send it in.

Crowbar: Simplifying C's type names

2020-10-13T00:00:00Z

(Previously in Crowbar: Defining a good C replacement.)

I've been working intermittently on drawing up a specification for Crowbar, a C replacement aiming to be both simpler and safer. I'm still nowhere near done, but I'm proud of the concept I've reached for type names, and I want to explain it in depth here.

The Problem

C declarations are known to be a nuisance in nontrivial cases. There's a mid-90s "clockwise/spiral rule" that I've seen referenced a few times, but three steps are two too many for reading a declaration. Function pointers in particular have a reputation for being legendarily impossible to visually parse. I don't know what void (*signal(int, void (*fp)(int)))(int); is declaring, but it's the most complicated example listed on the spiral rule page, and I'm pretty sure just pasting it into this blog post has already summoned some eldritch abomination.

A Solution

So we have this syntax which is well-established, and for simple cases well-understood, but in complex cases quickly becomes unmanageable. Ideally, we can preserve the syntax as is for simple cases, while cutting down on that complexity in the more difficult cases.

As of right now, the Crowbar specification gives the syntax as a parsing expression grammar, which I'll give an excerpt from here:

Type      ← 'const' BasicType /
            BasicType '*' /
            BasicType '[' Expression ']' /
            BasicType 'function' '(' (BasicType ',')* ')' /
            BasicType
BasicType ← 'void' /
            'int' /
            'float' /
            'bool' /
            '(' Type ')'

So essentially, basic types can be used as-is, and pointers-to or arrays-of those basic types require no additional syntax. But if you want to do something nontrivial, you'll need to parenthesize the inner type.

I didn't think this would wind up being quite as elegant as it turned out to be, but it handles a lot of edge cases gracefully and intuitively.

In Motion

I'll just lift some examples straight from the Spiral Rule page.

char *str[10];

Evidently this means "str is an array 10 of pointers to char". How would we express that in Crowbar (as it hypothetically exists so far)?

(char *)[10] str;

Now that's more like it. We can look at it and tell right away that the array is the outermost piece and so str is an array. In C, I'm not sure how we'd express a pointer-to-arrays-of-10-chars, but in Crowbar it's also straightforward:

(char[10])* str;

Now let's kick it up a notch, and look at those legendarily-awful aspects of C's syntax, function pointers. The Spiral Rule offers up

char *(*fp)( int, float *);

which supposedly means "fp is a pointer to a function passing an int and a pointer to float returning a pointer to a char". That's not extremely dreadful, merely somewhat off-putting, but let's see how it looks in Crowbar.

((char *) function(int, (float *),)* fp;

I hate that way less. It's less terse, certainly, but it's more explicit. The variable name is where it belongs, instead of nestled three layers deep inside the declaration. The fact that the char * and float * need to be parenthesized here is probably unnecessary, but you could imagine situations where those parentheses would be vital. And introducing function as a keyword means you can look at it and know instantly that it's a pointer-to-a-function, instead of going "wait what's that syntax where there are more parentheses than you'd think you'd want? oh yeah it's function pointers."

So let's take a look at the worst thing C can offer. The Spiral Rule calls it the "ultimate", and I don't think that's a misnomer:

void (*signal(int, void (*fp)(int)))(int);

That fractal mess is "a function passing an int and a pointer to a function passing an int returning nothing (void) returning a pointer to a function passing an int returning nothing (void)". My eyes glaze over reading that description even more than they do reading the original C. Can we make this not look awful?

((void function(int,))*) signal(int, ((void function(int,))*),);

This is beautiful. (Well, no it isn't, but it's way less ugly than the original.) It's clear which things are functions and which things are not, the nesting is all transparent and visible, and you can tell what the return type is without a PhD in Deciphering C Declarations. Plus, importantly, it's clear that this is a function prototype and not a function pointer declaration, which is a massive improvement over the original.

Bonus Round

Just for kicks, another less-awful-but-still-not-great thing about C type syntax is the pointer-to-constant vs constant-pointer dichotomy.

const int * points_to_const; // can never do *points_to_const = 8;
int * const const_pointer; // can never do const_pointer = &x;

You have to remember which is which. And why memorize when you can read?

(const int)* points_to_const;
const (int *) const_pointer;

Much, much better.

Looking Forwards

This syntax is simpler than C's without losing any expressive power. That makes me very happy.

If you're curious what's coming next for Crowbar, watch this space for when I eventually write another Crowbar-related blog post, or join the mailing list. (But don't get your hopes up; Crowbar is a project I'm working on in my spare time on a when-I-feel-like-it basis.)

Crowbar: Defining a good C replacement

2020-09-28T00:00:00Z

I like Rust a lot. That said, the always-opinionated, ~~often-correct~~ occasionally-correct Drew DeVault raises some good points in his blog post Rust is not a good C replacement. He names some attributes that C has and Rust lacks which he thinks are required in a good C replacement. So what can we say are some features of a hypothetical good C replacement?

Portability

Per Drew, "C is the most portable programming language." Rust, via LLVM, supports a lot of target architectures, but C remains ubiquitous. Anything less portable than LLVM is, therefore, incapable of being a good C replacement, and to be a truly great C replacement a language should be as portable as C.

The lifehack that makes sense here to me, difficult as it might be to implement, is to have the compiler for your C replacement be able to emit C as a compile target. It might not be the same C that a competent C programmer would write by hand, the result might not initially be as fast as the compiler would be if it were running the full toolchain directly, but in principle a self-hosting compiler that could also emit C would be extremely easy to bootstrap on any new architecture.

Specification

The C specification, while large and unwieldy and expensive, does at least exist. This creates a clear definition for how a compiler should work, whereas the behavior of Rust-the-language is defined to be whatever rustc-the-compiler does. Rust's lack of a specification allows it to move fast and not break things, which is cool for Rust (shout out to async/await), but there's virtue in moving slow, too. I don't think Rust itself necessarily needs a specification, but I do think that a good C replacement should be formally specified, and move at the speed of bureaucracy to ensure only the best changes get actually made.

The C99 specification is 538 pages and costs more money than I'd want to spend to get a legitimate copy of. A good C replacement should probably have a specification that fits in half the size - hell, call it 200 pages for a nice round number - and that specification should be released free of charge and under a permissive license.

Diverse Implementations

I think this is a result of having a specification more than a cause of its own, but Drew points out that the various C compilers keep each other and the spec honest and well-tested. I think in principle a good C replacement could start out with only one compiler, but it would need to be fairly straightforward to write a new compiler for - which is certainly not the case for C. It might be helpful to have several different reference compilers, themselves written in different languages and for different contexts. (It would be a fun party trick to have a WebAssembly-based compiler that people could poke around at in their browsers.)

Zero-Effort FFI

Drew calls this point "a consistent and stable ABI," but I think the context in which that matters is being able to use other libraries from your code, and being able to compile your code as a library that other people can use in turn, without needing to jump through extra hoops like writing glue layers manually or recompiling everything from source. The easy ("easy") solution is to just build libraries that C code can just use directly, and use the same ABI that C libraries in turn would export, so that there's no such thing as FFI because no functions exist which are foreign.

Composable Build Tools

I don't give a shit about this one, but in fairness to Drew I could understand why he would. If I have a project that starts out being entirely C, and I'm like "oh lemme try out Rust for some of this", I don't want to start by swapping out my build system and everything, I want to keep my Makefiles and make like one change to them and call it a day. (Makefiles also suck, but they don't dual-wielding-footguns suck, so it doesn't matter.) But cargo is very decidedly not built to be used that way, and rustc is very decidedly not built to be called from things that aren't cargo. So a good C replacement should have a compiler that works the way C compilers tend to, i.e. you pass in a file or several and a bunch of arguments and it builds the file you need it to build.

fart noises

Concurrency is generally a bad thing.

Safety Is Just Another Feature

In light of all the problems he has with Rust, Drew declares

Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

And like. On one hand, those are all extremely avoidable problems, and the way to avoid them is to start using a memory safe language. And they do cause rather more substantial problems than not having a specification.

But also. On the other hand, I don't eat my vegetables, I only comment my code half the time, I use Windows and I don't hate it. We're all of us creatures of habit, we do what's familiar, and we'll keep doing things in dangerous ways if switching to safe ways would have too high a learning curve. So as much of a bruh moment as this is in the abstract, I've been there, I'll likely be there again, and I can't really judge all that harshly.

Crowbar

The conclusion to Drew's blog post opens like this:

C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex.

And those sentences have been rattling around in my brain for a while now. Because he's right about that much. If we want C programmers to stop using C, we have to give them something that's only as different from C as it actually needs to be. We need C: The Good Parts Plus Barely Enough To Add Memory Safety And Good Error Handling.

And as someone with extraordinarily poor time management skills, I think I kinda want to work on building that.

Naming things is widely known to be the hardest problem in computer science, but since the goal is to pry C diehards away from C, I think a good name for this project would be

Crowbar: the good parts of C, with a little bit extra.

I don't know if this will get any of my time and attention. It really shouldn't - I've got so much other shit I should be doing instead - but also this is fun so who knows. Join the mailing lists if you're interested in participating.

A Survey of Rust Embeddable Scripting Languages

2020-09-16T00:00:00Z

Rust is a nice programming language. But it's only ever compiled, so if you want behavior that can be edited at runtime, you have to either anticipate and implement every single knob you think might need adjusting or let users write code in some other language that you then call from Rust. Lua is (to my knowledge) the most common language for this use case in general, but I don't really like using Lua all that much, so let's take a more comprehensive look at some of our options.

We'll need a use case in mind before we can really get going here, so here's our motivating example. We've got an event enum that our host can send to our script:

pub enum Event {
    Number(i64),
    Word(String),
}

And we've got some operation that makes sense in the context of our host, which the script can call:

pub fn print_fancy(text: &str) {
    println!("✨{}✨", text);
}

It'd be nice to reuse most of this structure, so let's define a consistent interface:

pub trait ScriptHost {
    type ScriptContext;
    type Error;

    fn new_context() -> Result<Self::ScriptContext, Self::Error>;
    
    fn handle_event(context: &mut Self::ScriptContext, event: Event) -> Result<(), Self::Error>;
}

And it'd be nice if almost all the logic was generic over ScriptHost so our individual examples could just call it as is:

pub fn run_main<SH: ScriptHost>() -> Result<(), SH::Error> {
    let stdin = stdin();

    let mut context = SH::new_context()?;

    loop {
        println!("Type a number or some text to fire an event, or nothing to exit.");
        let mut input = String::new();
        stdin.read_line(&mut input).unwrap();
        let input = input.trim();

        if input.is_empty() {
            break;
        }
        let event = match input.parse() {
            Ok(i) => Event::Number(i),
            Err(_) => Event::Text(input.to_string())
        };

        SH::handle_event(&mut context, event)?;
    }

    Ok(())
}

And specifically, where possible, we'd like to have the script simply export a function we can call and pass in an event. That way, the script can maintain its own long-running state if it wants to.

So that's the context in which we are working. If your context is not like this, then some libraries that don't work here might work for you. (If you're curious, you can check out the full source code for these examples here.)

Our contenders will be pulled from the top crates.io results for the tags "script", "scripting", and "lua", sorted by Recent Downloads as of when I'm starting this blog post and with a cutoff of whenever I feel like stopping. Specifically (these are links to the sections where I discuss them, if you've got one in mind you're curious about) we have

mlua (31,454 recent downloads)
rlua (30,877 recent downloads)
duckscript (24,901 recent downloads)
rhai (5,884 recent downloads)
dyon (1,539 recent downloads)
gluon (946 recent downloads)
ketos (497 recent downloads)
rune (495 recent downloads)
ruwren (451 recent downloads)

That seems like a lot. Let's hope I don't regret this.

mlua and rlua

mlua and rlua are both Lua bindings - mlua is apparently a fork of rlua - so we'll look at them together.

Reading through the mlua README, we see something unfortunate:

On Windows vendored mode is not supported since you need to link to a Lua dll. Easiest way is to use either MinGW64 (as part of MSYS2 package) with pkg-config or MSVC with LUA_INC / LUA_LIB / LUA_LIB_NAME environment variables.

I would really rather not have to go to all that work and expect any potential contributors to do the same. So there goes that one.

Since mlua is an rlua fork, I was guessing "not a pain in the ass on Windows" isn't a feature rlua has either, but apparently rlua works just fine on Windows with zero extra pain. So that's interesting.

Oh hey, less than a hundred lines of glue and we're fuckin set! The rlua crate has its own script host, so our choice of ScriptContext is really simple:

struct LuaScriptHost;

impl ScriptHost for LuaScriptHost {
    type ScriptContext = Lua;
    type Error = Error;

When we make a new context, we want to create a binding to our print_fancy method. Aside from having to use a String instead of &str it's pretty straightforward:

    fn new_context() -> Result<Lua, Error> {
        let lua = Lua::new();
        lua.context::<_, Result<(), Error>>(|lua_ctx| {
            let print_fancy = lua_ctx.create_function(|_, text: String| {
                print_fancy(&text);
                Ok(())
            })?;

            lua_ctx.globals()
                .set("print_fancy", print_fancy)?;

            lua_ctx
                .load(&(read_to_string("scripts/rlua-sample.lua").unwrap()))
                .set_name("rlua-sample.lua")?
                .exec()?;

            Ok(())
        })?;
        Ok(lua)
    }

(We're hard coding the path to the script here, because autodiscovering those is beyond the scope of this blog post, but you could totally iterate a directory and either run all those scripts in the same context or give them each their own context.) We're going to need a little more glue on the Event enum, though since Lua doesn't exactly have anything like enums natively. (And that glue is more complicated if we're using Cargo examples, because they aren't technically the same crate, so Rust's orphan rules kick in.) The easiest way to do that, I think, is to just add get_number and get_text methods that will return nil if the Event wasn't of that type:

struct EventForLua(Event);

impl UserData for EventForLua {
    fn add_methods<'lua, M: UserDataMethods<'lua, Self>>(methods: &mut M) {
        methods.add_method("get_number", |ctx, this, _: ()| {
            match this.0 {
                Event::Number(number) => Ok(number.to_lua(ctx)?),
                _ => Ok(Nil)
            }
        });

        methods.add_method("get_text", |ctx, this, _: ()| {
            match &this.0 {
                Event::Text(text) => Ok(text.clone().to_lua(ctx)?),
                _ => Ok(Nil)
            }
        });
    }
}

Armed with all these tools, we can now actually write our Lua script:

function handle_event(event)
    local number = event:get_number()
    if number ~= nil then
        print("number!", number)
    end
    local text = event:get_text()
    if text ~= nil then
        print("text!", text)
    end
    print_fancy("got an event!")
end

And now that we have our function, since we already ran this script, to handle an event all we need to do is call that function:

    fn handle_event(context: &mut Lua, event: Event) -> Result<(), Error> {
        context.context::<_, Result<(), Error>>(|lua_ctx| {
            let handle_event: Function = lua_ctx.globals().get("handle_event")?;
            handle_event.call::<_, ()>(EventForLua(event))?;

            Ok(())
        })?;

        Ok(())
    }
}

And that's all there is to it! That was surprisingly painless, all things considered. The only part that hurt a bit was the glue from Event into Lua, which wasn't even that bad for my case, but depending on what you're doing it might be.

duckscript

So Lua is a language I know I don't like all that much, and the gnarliest part of using it here was getting Rust types into it. Let's see if Duckscript, a "simple, extendable and embeddable scripting language", will be even simpler.

Well, this is a minor nitpick, but if I want to write a custom command (which, I think, is the right way to get print_fancy available to our script) the trait for that requires that I manually write

fn clone_and_box(&self) -> Box<dyn Command> {
    Box::new(self.clone())
}

even though anything that is Clone can already be cloned into a box. So that's a (very) minor nuisance.

The less-minor nuisance, it turns out, is that I can't figure out how to actually run a function defined in a script. So I guess in Duckscript you can't do that, and we'll have to just rerun the whole script when the event gets fired.

But once we've discovered and adapted to those issues, there's not much actual code that needs writing. Conveniently, since we can't have any persistent state anyway, there's no script context to store:

struct DuckscriptHost;

impl ScriptHost for DuckscriptHost {
    type ScriptContext = ();
    type Error = ScriptError;

    fn new_context() -> Result<Self::ScriptContext, ScriptError> {
        Ok(())
    }

The glue to expose our print_fancy is pretty terse as well:

#[derive(Clone)]
struct FancyPrintCommand;

impl Command for FancyPrintCommand {
    fn name(&self) -> String {
        "fancy_print".to_string()
    }

    fn clone_and_box(&self) -> Box<dyn Command> {
        Box::new(self.clone())
    }

    fn run(&self, arguments: Vec<String>) -> CommandResult {
        print_fancy(&arguments.join(" "));
        CommandResult::Continue(None)
    }
}

Once we've got this, we can handle events by setting up everything from scratch:

    fn handle_event(_context: &mut Self::ScriptContext, event: Event) -> Result<(), ScriptError> {
        // Make a context
        let mut context = Context::new();
        // Add the standard library
        duckscriptsdk::load(&mut context.commands)?;
        // Add our print_fancy command
        context.commands.set(Box::new(PrintFancyCommand))?;
        // Pick some strings to put in the context to represent our event
        let (event_type, event_value) = match event {
            Event::Number(value) => ("number", format!("{}", value)),
            Event::Text(value) => ("text", value)
        };
        context.variables.insert("event.type".to_string(), event_type.to_string());
        context.variables.insert("event.value".to_string(), event_value);
        // Run the script
        run_script_file("scripts/duckscript-sample.ds", context)?;
        Ok(())
    }
}

That's a lot of steps there. As you may notice, we have to put the number into a string before we can add it to the context. This is because all values in Duckscript are strings.

Well, now that we've got all the code to pass in variables and run it, let's write our event handler script:

if eq ${event.type} "number"
    echo "number!" ${event.value}
else
    echo "text!" ${event.value}
end
print_fancy "Got an event"

Technically, this all works. But I don't like it. It might be enough for your use case, though, and if it is, it'll work.

rhai

We're still in search of a Rust-centric scripting language that's good for our use case, so let's see if Rhai, "an embedded scripting language and evaluation engine for Rust that gives a safe and easy way to add scripting to any application", will be that. It's got an entire documentation book, which is always nice to see, and WebAssembly support. So hopefully this one is as cool as it looks.

Page four of said documentation book gives some really helpful clarity:

Rhai’s purpose is to provide a dynamic layer over Rust code, in the same spirit of zero cost abstractions. It doesn’t attempt to be a new language.

That also sounds like exactly what we need.

Just take a minute and look at how fucking gorgeous this code is:

struct RhaiScriptHost;

impl ScriptHost for RhaiScriptHost {
    type ScriptContext = (Engine, Scope<'static>, AST);
    type Error = Box<EvalAltResult>;

    fn new_context() -> Result<Self::ScriptContext, Self::Error> {
        let mut engine = Engine::new();
        engine.register_fn("print_fancy", print_fancy);
        let mut scope = Scope::new();

        let ast = engine.compile_file_with_scope(&mut scope, PathBuf::from("scripts/rhai-sample.rhai"))?;
        // if there's some global state or on-boot handling, make sure it runs
        engine.consume_ast_with_scope(&mut scope, &ast)?;
        Ok((engine, scope, ast))
    }

    fn handle_event((engine, scope, ast): &mut Self::ScriptContext, event: Event) -> Result<(), Self::Error> {
        let argument = match event {
            Event::Number(number) => Dynamic::from(number),
            Event::Text(text) => Dynamic::from(text),
        };
        engine.call_fn(scope, ast, "handle_event", (argument,))?;
        Ok(())
    }
}

That's all of it. That's the whole damn thing. Our script is pretty darn straightforward, too, unsurprisingly:

fn handle_event(data) {
    if type_of(data) == "i64" {
       print("number! " + data);
    } else {
       print("text! " + data);
    }
    print_fancy("got an event!");
}

Rhai doesn't have pattern matching, so we can't use our Event enum directly, but it does have runtime type introspection, so we can simply pass in either a number or a string and let the script sort it out. (If this is possible in Lua, too, then we could've made our Lua implementation a little simpler, but I'm not as familiar with Lua.)

There's so much to love here, but my favorite part is that we don't need any extra glue at all around print_fancy to be able to expose it to our Rhai script. This is excellent. Well done to Stephen Chung, JT, and the rest of the contributors. This is gonna be tough to beat.

dyon

Ooh, dyon was built by one of the two big Rust game engine projects. (In fairness, though, rlua was built by the other one.)

On the upside, this is almost as straightforward as Rhai was:

struct DyonScriptHost;

impl ScriptHost for DyonScriptHost {
    type ScriptContext = Arc<Module>;
    type Error = Error;

    fn new_context() -> Result<Self::ScriptContext, Error> {
        let mut module = Module::new();

        dyon_fn!{fn dyon_print_fancy(x: String) {
            print_fancy(&x);
        }}
        module.add_str("print_fancy", dyon_print_fancy, Dfn::nl(vec![Type::Str], Type::Void));

        load("scripts/dyon-sample.dyon", &mut module)?;

        Ok(Arc::new(module))
    }

    fn handle_event(context: &mut Self::ScriptContext, event: Event) -> Result<(), Error> {
        let call = Call::new("handle_event");
        let call = match event {
            Event::Number(value) => call.arg(value as f64),
            Event::Text(value) => call.arg(value),
        };

        call.run(&mut Runtime::new(), context)?;

        Ok(())
    }
}

Our script is likewise pretty straightforward:

fn handle_event(data) {
    if typeof(data) == "number" {
       println("number! " + str(data))
    } else {
       println("text! " + data)
    }
    print_fancy("got an event!")
}

But the API took a really long time for me to actually figure out, and there are a few language features that I extremely don't get. Like, they've got secrets that can be attached to a bool or number, so you can ask for a retroactive explanation for why a function returned the value it did, or where a value came from. And that's neat and all, but like. why. Honestly I'm just not as impressed by this as I am by Rhai. Maybe you are, though, in which case this might work well for you.

gluon

gluon, unlike our previous contestants, is a statically typed functional language. Static types, for this context, are nice to have. Functional programming... may or may not be, depending on how it's implemented.

Oh hey, at time of writing their website is down. That's always a good sign.

An even better sign, of course, is the fact that trying to declare our Event type in Gluon causes a stack overflow. In theory, since it's got algebraic data types, we could just declare it as is and bring it right on in, but unfortunately the code to do that 100% automatically appears to not compile, and the code to do that only almost automatically still requires us to write the type definition on the Gluon side manually:

vm.load_script("rust-scripting-languages.event", "type Event = Number Int | Text String")?;

I'm not sure why this causes a stack overflow either. But it does. As such, I have no clue how good this actually would be to use.

ketos

ketos describes itself as "a Lisp dialect functional programming language". So that ought to be interesting.

The Rust function glue all assumes your functions return a Result and that's a minor nuisance, but that's not insurmountable. Overall, this is pretty terse:

struct KetosScriptHost;

impl ScriptHost for KetosScriptHost {
    type ScriptContext = Interpreter;
    type Error = Error;

    fn new_context() -> Result<Self::ScriptContext, Error> {
        let interp = Interpreter::new();

        let scope = interp.scope();

        fn print_fancy_fallible(text: &str) -> Result<(), Error> {
            print_fancy(text);
            Ok(())
        }

        ketos_fn! { scope => "print-fancy" => fn print_fancy_fallible(text: &str) -> () }

        interp.run_file(&PathBuf::from("scripts/ketos-sample.ket"))?;

        Ok(interp)
    }

    fn handle_event(context: &mut Self::ScriptContext, event: Event) -> Result<(), Error> {
        let value = match event {
            Event::Number(n) => Value::from(n),
            Event::Text(t) => Value::from(t),
        };
        context.call("handle-event", vec![value])?;

        Ok(())
    }
}

Our script itself is... definitely Lisp-y.

(define (handle-event event)
    (do
        (println "~a ~a" (type-of event) event)
        (print-fancy "got an event!")))

This all works, and if you love Lisp and want your users to write a bunch of Lisp then this'll work perfectly for you. But it's not really to my tastes.

rune

rune lists pattern matching in their README as a feature, so that's a good sign. And they've got a Book that starts by giving a shout out to Rhai as a major inspiration, which is also neat.

Turns out the pattern matching doesn't let you match on enum variants even though Rune has enums. So we've gotta do the same dynamic typing stuff we've been doing before. But this is pretty clean:

struct RuneScriptHost;

impl ScriptHost for RuneScriptHost {
    type ScriptContext = Vm;
    type Error = Box<dyn Error + 'static>;

    fn new_context() -> Result<Vm, Self::Error> {
        let mut context = rune::default_context()?;

        let mut module = runestick::Module::default();
        module.function(&["print_fancy"], print_fancy)?;

        context.install(&module)?;

        let script = read_to_string("scripts/rune-sample.rn")?;

        let mut warnings = rune::Warnings::new();
        let unit = rune::load_source(&context, &Default::default(), Source::new("scripts/rune-sample.rn", &script), &mut warnings)?;

        let vm = Vm::new(Arc::new(context), Arc::new(unit));

        Ok(vm)
    }

    fn handle_event(vm: &mut Vm, event: Event) -> Result<(), Self::Error> {
        let arg = match event {
            Event::Number(n) => Value::from(n),
            Event::Text(t) => Value::from(t)
        };
        vm.clone().call(&["handle_event"], (arg,))?.complete()?;

        Ok(())
    }
}

Again, we have zero glue required for our print_fancy function, which is nice. Our script looks pretty decent too:

fn handle_event(event) {
    match event {
        n if n is int => println(`Number! {n}`),
        t => println(`Text! {t}`),
    }
    print_fancy("got an event!")
}

The one issue I notice is that Vm::call takes self by value, which means we're forced to clone() our VM every time we want to handle a new event instead of handling them all in the same VM. This probably means a more complicated script with some global state to maintain wouldn't be able to do that. So if that's something you know you'll want to support, Rune might not be for you, unless there's a different way to do this that I didn't find in the docs. But if you know you don't need that, Rune might work well for you.

ruwren

ruwren provides bindings to the Wren embeddable scripting language, which looks kinda neat:

Think Smalltalk in a Lua-sized package with a dash of Erlang and wrapped up in a familiar, modern syntax.

I think the example presented in the README at time of writing is incomplete and buggy, but I figured out how to fix it and sent in a pull request.

We do have to write some glue for our print_fancy method; since Wren is inspired by Smalltalk, everything is objects, so we need a class within which print_fancy can be a static method:

struct Demo;

impl Class for Demo {
    fn initialize(_: &VM) -> Self {
        Demo
    }
}

impl Demo {
    fn print_fancy(vm: &VM) {
        let text = get_slot_checked!(vm => string 1);
        print_fancy(&text);
    }
}

create_module! {
    class("Demo") crate::Demo => foo {
        static(fn "print_fancy", 1) print_fancy
    }

    module => demo
}

Armed with this, the actual integration is pretty straightforward:

struct RuwrenScriptHost;

impl ScriptHost for RuwrenScriptHost {
    type ScriptContext = VMWrapper;
    type Error = Box<dyn Error + 'static>;

    fn new_context() -> Result<Self::ScriptContext, Self::Error> {
        let mut modules = ModuleLibrary::new();
        demo::publish_module(&mut modules);

        let vm = VMConfig::new()
            .library(&modules)
            .build();

        vm.interpret("demo", r##"
        foreign class Demo {
            foreign static print_fancy(string)
        }
        "##)?;

        let script = read_to_string("scripts/ruwren-sample.wren")?;
        vm.interpret("main", &script)?;

        Ok(vm)
    }

    fn handle_event(vm: &mut VMWrapper, event: Event) -> Result<(), Self::Error> {
        vm.execute(|vm| {
            vm.ensure_slots(2);
            vm.get_variable("main", "EventHandler", 0);
            match &event {
                Event::Number(n) => vm.set_slot_double(1, *n as f64),
                Event::Text(t) => vm.set_slot_string(1, t),
            }
        });
        vm.call(FunctionSignature::new_function("handleEvent", 1))?;

        Ok(())
    }
}

And our test script in Wren looks nice:

import "demo" for Demo
class EventHandler {
    static handleEvent(data) {
        if (data is Num) {
            System.print("Number! %(data)")
        } else {
            System.print("Text! %(data)")
        }
        Demo.print_fancy("got an event")
    }
}

Overall, I think this is pretty good. This specific use case isn't particularly well suited to Smalltalk-style object orientation, but if yours is then this will work well for you. Plus, since Wren isn't Rust-specific, it might be slightly more portable, if that's a concern for you.

summary

So those are our options. A convenient bullet points tl;dr for you:

Use rlua if you specifically want a scripting language that some of your users might already know.
Use ruwren if you specifically want a Smalltalk-like (object-oriented) scripting language.
Use ketos if you specifically want a LISP-like (parentheses-oriented) scripting language.
Use rhai if you just want a good scripting language.

A Survey of Rust GUI Libraries

2020-08-21T00:00:00Z

(Note from the future: I did this again in 2021 and in 2025.)

a popular trend in the Rust community is to ask "Are We X Yet" for various things that it would be nice to be able to develop easily in Rust - game and web are the most prominent ones as far as i can tell - and one such question is Are We GUI Yet. that's a good question; are we GUI yet? Are We GUI Yet has a list of libraries for building GUIs: let's go through them in alphabetical order and see if we can build a simple to-do list with them without too much struggle.

some notes before we get started.

this is all extremely subjective.
the only ui toolkits i have used and not hated are Swing (i know), Electron (i know), and wxWidgets, which doesn't have Rust bindings because Rust bindings to C++ libraries are generously described as a nuisance to create (i've tried, and i'm writing this post instead of trying harder). as such, i might be using some of these wrong, who knows.
i use windows, and so anything that's a nuisance to set up on windows is not going to fare well regardless of how cool it is once you get it working. it could be the best thing since sliced bread or Meteor on release and i wouldn't care. do not @ me.
the people who wrote these libraries have done more than i have to make the rust gui ecosystem not suck, and i don't want any of this to come across as suggesting that they suck and their work is bad. the strongest thing i want to say is that a library is not designed in a way that i would want it to be designed, or that it doesn't work for me. doing this shit at all is really goddamn difficult, and i don't want to minimize that by being unhappy with the results.
i started drafting this post in early July 2020, and finished it in late August 2020. some things may have changed in the meantime while i wasn't paying attention.

azul

first on our list is azul:

A free, functional, immediate-mode GUI framework for rapid development of desktop applications written in Rust, supported by the Mozilla WebRender rendering engine.

the wiki says we need cmake installed, which is never a good sign, but conveniently, i've already got that set up on my computer, for reasons i forget but probably didn't enjoy. the runtime dependencies on linux are a mile long, but fortunately i don't have to care. azul isn't currently available on crates.io for reasons that presumably exist but are difficult to explain, so we have to add it directly as a git dependency.

once we've got it added as a dependency, we can attempt to run our test crate, just to make sure everything's not on fire. unfortunately:

error: failed to run custom build command for `servo-freetype-sys v4.0.5`

Caused by:
  process didn't exit successfully: `D:\Melody\Projects\we-are-not-gui-yet\target\debug\build\servo-freetype-sys-1fae054761ff82c5\build-script-build` (exit code: 101)
--- stdout
running: "cmake" <snip>

--- stderr
CMake Error: Could not create named generator Visual Studio 16 2019

this is an inauspicious beginning. one version history crawl later and it looks like my cmake is from April 2019, which is not all that old but maybe they hadn't caught up on the latest visual studio yet, who knows. this is already more work than i was prepared to do, but i've come this far, so it's time to update my cmake.

okay one installer later and it's time to try again. armed with a cmake from May 2020, let's give this another shot:

error[E0433]: failed to resolve: could not find `IoReader` in `bincode`
   --> C:\Users\Melody\.cargo\registry\src\github.com-1ecc6299db9ec823\webrender_api-0.60.0\src\display_list.rs:270:35
    |
270 |             let reader = bincode::IoReader::new(UnsafeReader::new(&mut self.data));
    |                                   ^^^^^^^^ could not find `IoReader` in `bincode`

welp. the cmake update fixed things, i guess, but now we've got a whole other pile of mess. this might be fixable, it may have been fixed by the time you read this. regardless, this library does not work for me.

conrod

next up is conrod:

An easy-to-use, 2D GUI library written entirely in Rust.

i've actually used this one before in a couple of projects, but it's been a minute, so i forget the details.

they do not have a real tutorial, which is unfortunate, but they do have some examples. unfortunately, step one is to pick which of the half dozen backends i want. do i want glium or vulkano or rendy or piston? do i look like i know what a vulkano is? i just want a picture of a god dang hot dog. okay that's not quite fair, i recognize three of those and can infer from context what the fourth one is, but that's only because i've been down this road before, and i still have no clue which one is the right one to pick. all the examples live under glium, though, so let's go with that.

wait actually i'm staring at these examples and there's an entire ass event loop in the support code for the examples. something in here mentions a GliumDisplayWinitWrapper and i'm scared. i have literally used this library before - on two different projects - and i'm at a loss. i don't want to just copy and paste the examples without actually understanding what's going on, i can't understand what's going on in the examples, and there's nowhere else to get started. so there goes that i guess.

core-foundation

Bindings to Core Foundation for macOS.

oh hey, it's an OS i don't have access to at all. next.

druid

our next contender is druid:

Druid is a framework for building simple graphical applications.

apparently this sprung out of that vi-like text editor a couple googlers were working on, so apparently it's at least possible to use it for real software. there's a tutorial, they're on crates.io, they're describing it as "conceptually simple and largely non-magical" which i am always a fan of, i am cautiously optimistic. if we throw it in our dependencies and just see if anything breaks, we find the surprising result that everything just works.

oh hey the first real chapter in the tutorial starts with

this is outdated, and should be replaced with a walkthrough of getting a simple app built and running.

you love to see it. fortunately, we can just ignore that and skip to the hello world example, reproduced here in its entirety:

use druid::{AppLauncher, WindowDesc, Widget, PlatformError};
use druid::widget::Label;

fn build_ui() -> impl Widget<()> {
    Label::new("Hello world")
}

fn main() -> Result<(), PlatformError> {
    AppLauncher::with_window(WindowDesc::new(build_ui)).launch(())?;
    Ok(())
}

and somehow, this actually works.

the tutorial ends here, which is unfortunate, but there's more documentation, including explanations of core concepts with examples that are... todo lists! with even more features than what i was planning to include here! so that's convenient. the UI hierarchy is based on CSS Flexbox, which i also appreciate. this is what peak UI layout API looks like:

fn build_new_todo() -> impl Widget<TodoState> {
    let textbox = TextBox::new()
        .with_placeholder("New todo")
        .lens(TodoState::next_todo);
    let button = Button::new("Add")
        .on_click(|_, data: &mut TodoState, _| data.create_todo());

    Flex::row()
        .with_flex_child(textbox.expand_width(), 1.0)
        .with_child(button)
}

1 hour and 80 lines of code later, we've got ourselves a perfectly valid and working todo list!

i'm not quite happy with this, though: we can type text and hit the button and it adds the todo, but pressing enter in the text field doesn't do anything. there's no way out-of-the-box to make that happen; let's see if we can build that ourselves.

~30 lines of code later, we've got it! the Controller trait is designed for exactly this sort of thing, when you need to wrap the behavior of an existing component and intercept some events to inject your own logic.

if you're curious, you can take a look at the source for our druid example.

so apparently druid is actually pretty darn usable. i only have a couple tiny issues with it:

it doesn't use platform native UI widgets, so it doesn't look quite like a windows app should, and it won't look quite like a mac or linux app should either if i test it there. this one is a feature as far as some people are concerned, but i am not on that list.
accessibility features like being able to tab between UI widgets (update 2020-12-14: and also literally any screen reader support) are missing, so you'd have to roll those yourself in a real application. maybe they'll add that by default in future versions, maybe not, but it would be neat if it existed.
high-level documentation is incomplete. the individual struct/function docs are really good, but at a high level you don't really have a convenient place to jump in.

i was about to add "no support for web" to that list, but even though the high-level docs don't mention it, the crate root docs and the examples do. on the plus side, it just works, and i didn't have to make any changes to my code because i use this patch to wasm-pack that lets you just use binary crates in wasm-pack even though it hasn't been merged yet upstream. on the minus side, it points everything at a <canvas> tag, which means you get none of the accessibility features of actually using the DOM. so that one's a mixed bag.

but yeah, overall druid is perfectly usable for gui development. i was originally calling this post "we are not gui yet" but i guess we are at least a little bit gui already. pleasant surprises are the best kind.

fltk

following up that success is fltk:

The FLTK crate is a crossplatform lightweight gui library which can be statically linked to produce small, self-contained and fast gui applications.

cross-platform and statically linked are both good things. the upstream FLTK website makes my eyes bleed, which is never a good sign for a UI library, but that doesn't mean much one way or the other. the simple hello world example is once again a mere handful of lines:

use fltk::{app::*, window::*};

fn main() {
    let app = App::default();
    let mut wind = Window::new(100, 100, 400, 300, "Hello from rust");
    wind.end();
    wind.show();
    app.run().unwrap();
}

a downside i'm noticing already, at least compared to druid, is that everything has to be positioned manually, and we don't get any layout stuff calculated for free.

a lot of wrestling later, we have a technically working implementation (source code).

it's half as much code as the druid implementation, but part of that's because the druid implementation also preserves state information, so we could easily have added persistence without all that much work, but our fltk version does not do that and is just a pile of ui widgets. some of that code, i will say, fails to spark joy:

add_todo.set_callback(Box::new(move || {
    let text = next_todo.value();
    next_todo.set_value("");
    let done = CheckButton::new(0, top, 400, 30, &text);
    wind.add(&done);
    wind.redraw();
    top += 30;
}));

we have to drag that position and size around manually. i don't like that.

update 2020-12-14: also, it doesn't expose anything to screen readers.

overall, this technically works i guess, but i think the code is ugly and the style of the resulting application is also ugly. we do get tab and space and everything working out of the box on buttons, which is always appreciated, though. not broken or anything, not something i'd be likely to choose to use though either.

gtk

next on our list is another pile of bindings to an existing ui library, gtk:

Rust bindings and wrappers for GLib, GDK 3, GTK+ 3 and Cairo.

however. the second meaningful sentence in the README says

gtk expects GTK+, GLib and Cairo development files to be installed on your system.

and i have been down that road before and mother of god once is enough. maybe on things-that-are-not-windows this isn't a nightmare, but i do not use things that are not windows. the windows instructions are a nightmare even in the happy path that their instructions explain, which last time around i failed to hit, making the whole process even more nightmarish. so i think i will pass.

iced

our next contestant is iced:

A cross-platform GUI library for Rust focused on simplicity and type-safety. Inspired by Elm.

cross-platform and simple are good. inspired by elm is a tentative "nice" - my experiment with elm way back in the day had mixed results, but it's not clear how much of that was my fault.

iced compiles just fine, and it looks like we've got a vaguely MVC-ish architecture here. it looks like you write your logic in a highly portable way and then glue it together in ways that vary based on whether you're building for native or for Web.

conveniently, there's a todo list example! but we don't even need it; the example given in the README, with some of the details elided there, is enough context to have an entire todo list application in 100 lines of Rust.

notably, our checkboxes aren't aligned to the right of the window. i couldn't figure out how to make that happen. however, we do have built-in support for "do a thing when the user presses enter in the text area," which we had to write ourself in other frameworks. so that one is nice.

compared to druid, i'd say the logic is a little more intuitive, the layout controls are less intuitive, and the web support is way better. the native build once again doesn't use native widgets and so once again doesn't get tab-between-fields or other accessibility features, but the web build uses actual HTML elements and so gets tab-between-fields for free. high-level documentation is a little more robust here, plus the concepts are less complicated in the first place.

update 2020-12-14: screen reader support in the native build is again nonexistent, but the web build works alright, at least with the one i'm testing with.

so it's a little easier to get off the ground than with druid, and the results on the web are way better, but it's more difficult to make it look decent. maybe that's just a documentation issue, but it's not ideal. regardless, yet again we have a perfectly usable library.

imgui

up next, another binding to an existing library, imgui:

Rust bindings for Dear ImGui

further down the readme, we see

Almost every application that uses imgui-rs needs two additional components in addition to the main imgui crate: a backend platform, and a renderer.

and immediately i no longer give a shit. i'm pretty sure imgui is designed for, like, diy game engines etc where you already have a backend and a renderer set up, which is a really specific use case that i don't currently meet. goodbye.

kas

this one is not a binding to something else, it's new from scratch, it's kas:

KAS, the toolKit Abstraction System, is a general-purpose GUI toolkit.

the readme has a lot of screenshots, which is always nice to see. no tutorial, apparently, but several examples.

the guts of kas are mostly macro-based, which doesn't combine well with the lack of high-level documentation, but the examples are enough to let me bullshit my way towards something almost usable.

why almost? because clicking in the text entry field to give it focus causes an explosion:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', C:\Users\Melody\.cargo\registry\src\github.com-1ecc6299db9ec823\kas-text-0.1.3\src\prepared.rs:465:9

that's bad. and i don't feel like chasing down why that happens, especially because my gut says my code isn't the problem. shame, though, the widgets sure look pretty.

neutrino

next up we have neutrino:

Neutrino is a MVC GUI framework written in Rust.

ah, ol' reliable, MVC. the wiki has an actual tutorial, too, which you love to see.

most of the other libraries have not made me throw around Rc<RefCell<T>> everywhere myself, though. but neutrino has that just all over the place. and it gets worse than you'd think. building the same example to-do list required a Rc<RefCell<Vec<Rc<RefCell<TodoItem>>>>> and i feel like that's bad. it definitely makes my code look terrible.

excitingly, we now have a demo that looks bad and also doesn't work:

excitingly, when we type some text and hit the "add" button, the text gets lost in the created todo, and i have no goddamn clue where it's going or what to do to fix it.

update 2020-12-14: also, a first so far, the native build actually provides some information to the screen reader! only some information - the checkbox labels come through, but the fact that they're attached to checkboxes doesn't - but still, it's closer than most of the other frameworks have managed to get.

the approach is interesting, though. as i'm writing this neutrino is unmaintained and seeking a new maintainer, so hopefully somebody has the time and energy to steer it forwards.

orbtk

our next contestant is OrbTK:

The Orbital Widget Toolkit is a cross-platform (G)UI toolkit for building scalable user interfaces with the programming language Rust.

apparently this is attached to Redox, the OS written in Rust. so that's neat.

again, no tutorial, some examples that are far from self-explanatory.

it does let us build a working todo list, and one that looks pretty nice:

i can't for the life of me figure out how to make the text field take up the entire width available to it. but everything works, and we get built-in support for adding the todo on Enter in the text field, which is nice.

update 2020-12-14: screen reader support is, once again, nonexistent.

in theory, there's web support, but when i tried it it very loudly didn't work:

error[E0405]: cannot find trait `StdError` in module `serde::de`
   --> C:\Users\Melody\.cargo\registry\src\github.com-1ecc6299db9ec823\serde_json-1.0.46\src\error.rs:317:17
    |
317 | impl serde::de::StdError for Error {
    |                 ^^^^^^^^ not found in `serde::de`

so yeah, we've got some nice-looking widgets, with unintuitive layout settings, broken web support, and a lot of glue i had to write by hand that makes the source code cluttered and messy. don't think i'd use it for anything more serious, at least as it exists right now.

qmetaobject

The qmetaobject crate is a crate which is used to expose rust object to Qt and QML.

i don't want to install Qt. that sounds like a nuisance, and more importantly, if i want Travis or whatever to give me automated CI builds, i don't think it's easy to make sure Qt exists on all platforms on Travis.

qt_widgets

oh hey, more Qt API bindings! i still don't want to install Qt.

relm

Asynchronous, GTK+-based, GUI library, inspired by Elm, written in Rust.

as established, GTK+ setup on Windows is a scary nightmare hellscape.

rust-qt-binding-generator

i am so tired.

sciter-rs

i think sciter is a thing actual programs use, which is nice. however, we need not only the sciter sdk installed and available, but also GTK+, and god damn i do not want to do that.

WebRender

last, but hopefully not least, we have webrender:

WebRender is a GPU-based 2D rendering engine written in Rust. Firefox, the research web browser Servo, and other GUI frameworks draw with it.

pour one out for Servo, btw.

unfortunately, the "basic" example is still 300+ lines of code. so i doubt that's gonna be useful.

so are we GUI yet?

well, kinda. druid works well if you want a straightforward layout experience. iced works well if you want a straightforward render-update architecture, or actual HTML elements on Web. everything else is, as of today, broken and/or more complex than i want. and if you want native ui widgets to match your platform's look and feel (update 2020-12-14: or be accessible at all), that's gonna be like a year away at least.

Post-Open Source

2020-08-13T00:00:00Z

i'm writing this like a day after big mozilla layoffs that included a lot of people working on cool and important shit. the consensus i'm seeing is that it reflects mozilla's search for profit over impact, mismanagement, and disproportionate executive compensation. this is taking place in a larger trend of corporatization of open source over the past several years, an ongoing open source sustainability crisis, and of course COVID-19, the all-consuming crisis that makes all our other crises worse. all of this was summed up most concisely by Kat Marchán:

Imo, open source as a community endeavor is falling apart right before our eyes, and being replaced by open source as Big Corp entrenchment strategy.

I mean it's been happening for a while, but seeing Mozilla sinking like this is just driving the point home for me.

FOSS is dead

how did we get here? where even are we? what happens next?

i am incredibly unqualified to answer any of this - i didn't show up until right around the peak of SourceForge, i wasn't there for most of this - but i'm not gonna let that stop me.

names

to start this funeral service for FOSS, we have to unpack the term itself. "free and open source software" as a term already contains multitudes. on one hand, "free software", an explicitly political movement with a decidedly anti-charismatic leader. on the other hand, "open source software", defanged and corporate-friendly by design. the free software people (correctly) criticize "open source" as milquetoast centrism. the open source people (correctly) criticize "free software" as stubborn idealism fighting tooth and nail to reject the real world as it actually exists. they have as much in common as leftists and liberals (but they're more prepared to work together), and although their short-term goals were similar enough that it made sense to lump them together (hence the cooperation), now that the movement is dead i think there's more to gain from considering them separately. most software licenses that i'm going to bring up technically qualify as both, but they're popular with one or the other, so i'll refer to "free software licenses" and "open source licenses" as licenses that are more directly tied to those movements, even though any given license likely meets both definitions.

i'd say free software died a while ago, and open source went horribly right.

freedom

the free software movement, for all its faults, has always known what it's about:

The freedom to run the program for any purpose.

The freedom to study how the program works, and change it to make it do what you wish.

The freedom to redistribute and make copies so you can help your neighbour.

The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits.

it's concise, it's understandable, and it's… kinda useless. this point was raised better by actual lawyer Luis Villa (Karl Marx slander notwithstanding), but those freedoms don't actually mean shit to the average end user. only programmers care if they have access to the source code, and most people aren't programmers. and i am a programmer, and i don't give a shit. the freedom to not think about my operating system and just get work done overrules all of those for me, so i use windows. like, yeah, those things are all in principle nice to have, and between two otherwise equally good programs i'd take the free one. but they're really fuckin specific things, and even if i have the freedom to do them i'm not likely to have the ability or desire to do them, so there's no good reason for me as a user to use software that's worse in other ways because it gives me freedoms i don't need.

the free software movement is explicitly political, but its politics suck. it's a movement by and for ideological diehards but the ideology is extremely esoteric. theirs was a losing battle from day one. so what was it that actually killed them? i think in a very real way it was the GPLv3.

losing

the flagship projects of the free software movement are probably Linux and the GNU pile of tools. the Linux kernel being released under a free software license doesn't directly create more free software, though, since even things that tie closely to the kernel aren't obligated to also be free software, and of course user-level applications can have whatever license they want. and also most of the people using Linux right now are using it by accident, distributed as ChromeOS or Android, neither of which is free software. so Linux is a win for the free software movement but a useless one.

the GNU userland tools are, for the most part, even more underwhelming. it may be technically more accurate to call it GNU/Linux, but the only time i remember my linux userland tools are GNU or free software at all is when there's some weird inconsistency between a GNU tool and its BSD equivalent, and that's not exactly ideal. gcc had, as far as i can tell, been basically the C compiler for a while, if you weren't stuck with MSVC or something worse. the free software movement were stubborn ideologues with weird priorities, but they still had one big technical advantage. then the GPLv3 happened.

the GPLv2 was pretty popular at the time, but there were a couple notable loopholes some big corporations had been taking advantage of, which the free software people wanted to close. a whole bunch of people thought the GPLv2 was fine the way it was, though - closing the loopholes as aggressively as the GPLv3 did cut off some justifiable security measures, and some people said that it could do more harm than good. the linux kernel, along with a lot more stuff, declared it was sticking with the GPLv2 and not moving to the GPLv3. when your movement says "here is the new version of The Right Way To Do Things" and several of your largest adherents say "nah fuck you we're going with the old version" that is not a good sign. around the same time, free software organizations were starting to successfully sue companies who were using free software but not complying with the license. so big companies, like Apple, saw new restrictions coming in at the same time as more aggressive enforcement, and said "well shit, we want to base our software on these handy convenient tools like GCC but we can't use GPLv3 software while keeping our hardware and software as locked together as we'd like." so they started pouring money into a new C compiler, LLVM, that was instead open source.

and LLVM became at least as good as GCC, and a less risky decision for big companies, and easier to use to build new languages. so the free software movement's last technical advantage was gone. its social advantages also kinda went up in flames with the GPLv3, too: the software that was the foundation for the GPL enforcement lawsuits stuck with the GPLv2. the discourse over that decision was so nasty that the lead maintainer (Rob Landley; he'll come up later) started an identical project which he wound up relicensing under an open source license because the lawsuits had completely backfired: instead of complying with the terms of the GPL, companies were just avoiding GPL software.

the free software movement, in the end, burned itself out, by fighting for a tiny crumb of success and then turning around and lighting that success on fire. the death of free software tells us that we can't use a license to trick corporations into sharing our values: they want to profit, and if good software has a license that puts a limit on how much they can do that, they'll put more resources into writing their own alternative than they would spend complying with the license in the first place.

openness

the open source movement manages to share the same short term goals as the free software movement but be bad in almost entirely disjoint ways. the mission of the Open Source Initiative says

Open source enables a development method for software that harnesses the power of distributed peer review and transparency of process. The promise of open source is higher quality, better reliability, greater flexibility, lower cost, and an end to predatory vendor lock-in.

this is so profoundly different from the free software definition that it's almost comical. where free software says "we value freedom, which we define in these ways," open source says "your code will get better." the free software movement was prepared to start fights with corporations that used their work but didn't play by their rules. the open source movement was invented to be a friendly, apolitical, pro-corporate alternative to the free software movement.

the contrast between "use free software because it preserves your freedom" and "use open source software because it's better" is profound and honestly a little disappointing to revisit this explicitly. free software preserves freedoms i don't need or care about as a user, but it does at least do that. open source software is frequently not in fact better than closed source alternatives, and "use open source software because on rare occasions it manages to be almost as good" is an even more underwhelming sales pitch than anything free software can give.

where free software is misguided and quixotic, open source is spineless and centrist. and as tends to happen with spineless centrism, it has eaten the world.

winning

if there's anything corporations love more than rewriting software so it lets them make all the money they can dream of, it's letting other people do that work for them. it took a while to take off, because the conservative approach of "keep things closed source" was pretty solidly entrenched in a lot of places, but now even the once conservative holdouts have accepted the gospel of centrism. corporations have little to nothing to lose by publishing existing source code, and can gain all sorts of unpaid volunteer labor. if they start a new internal project, important enough that they're prepared to put effort into it but not so important that someone could run off with it and compete with them, then now they'll likely open source it. worst case scenario, they do all the work they were already prepared to do. best case scenario, their library turns into the single most popular library of its type, with thousands of unpaid volunteers donating their time to you. more labor for free, community goodwill for having started the project everybody uses, the benefits if it goes well are countless. free software is not in principle anti-corporate, but corporations are very cautious getting caught up in the free software movement, because that actually creates obligations for them. open source gives corporations a shot at improving their code for free, so as long as they don't share so much someone could start a competitor, so there's zero reason for a corporation to not get into open source.

the best part for corporations is they don't even have to be the ones to start a project. if you're just some random small time developer, they can just show up. you made a cool database server that's under an open source license? amazon's selling it as a service now, and they're not paying you a fuckin dime. you want to change your license to stop them from doing that? now the open source people are yelling at you, because when they say they're apolitical they mean they support the status quo. and the free software people are also yelling at you, because you didn't do it their way with their license, you did it a different way with a different license, and that goes against amazon's freedom to screw you over.

github itself is arguably the epitome of the open source movement. the platform itself is closed source, because they don't want people to compete with them running their code, and also they sell the very expensive self-hosted version to corporations. opening up the source for github itself would take a chunk out of github's profits. can't have that. but they don't even need to start or adopt an open source component to profit off other people's labor: literally every project on github makes github more valuable. popular projects get people in, network effects bring their colleagues in, and then when it's time for something that you'd rather have closed source you and everyone else are already on github so you might as well spring for the paid tier. if they believed open source was in principle better, they'd be open source themselves. they believe open source is profitable for them, and corporate profit is by definition value generated by labor but not paid to the laborer.

what's good for corporations is, of course, bad for people. random individual contributors almost never get paid for their work, even when a corporation or several will profit substantially from those changes. maintainers of vital infrastructure libraries generally only get paid if they wrote the library for or under the control of the company they worked for anyway. professional, corporate maintainers can offer more to the community since they're getting paid for it, which heightens expectations on independent maintainers and leads to maintainer burnout. and if a company runs off with some existing open source software, they can build their secret competitive advantage around it without giving any of that work back to the original authors.

all of these individual crises are by design: this was always the endgame of the open source movement. the free software movement was transparent with its greatest value: "we believe users should have the freedom to mess with and contribute to the source code of the programs they use." the open source movement had a far subtler value: "we believe corporations should have the freedom to exploit the labor of developers." the fact that individual developers were ever on board with the open source movement speaks to the pernicious branding it employs. but people are starting to notice that this isn't actually good at all.

the free software movement was on occasion writing actually good software; corporations saw that and wanted to get in on it without having to actually have principles. so they embraced the nominal goals of the free software movement and extended it into a more corporate-friendly movement with a larger pile of software to draw from. the conventional step after embrace and extend is, naturally, extinguish. the free software movement died long ago, in no small part due to its own mistakes, so there's not much left to extinguish. that which is being extinguished, that which died with mozilla, is the idea that the open source movement could have any other principles than corporate exploitation.

i wouldn't say that the open source movement died per se. it was undead from the moment it began; it won, and with its victory it has stopped pretending to be anything other than a lich. the only meaningful lesson to learn from the open source movement is that letting corporations do whatever the hell they want ends poorly, which is not exactly news.

not learning

open source won, and nothing got better. in an effort to fix this feature of the open source movement, some people have chosen to repeat the mistakes of the free software movement. as some smart german dude once said, everything in history happens twice, first as tragedy, then as farce.

the free software movement declared that the user's freedom to tinker with and contribute to the software they use is supreme, and they wrote a license specifically built to preserve that in software applied to it, and to spread that freedom to software based on it. an uninspiring but at least well-defined goal, pursued somewhat decently, with at least some lasting success.

the "ethical source" movement declares that the UN's Universal Declaration of Human Rights is supreme, with relevant laws in whatever jurisdiction is relevant a close second, and the Hippocratic License says "if the software author says you're violating human rights you have to go through public arbitration or the license is void." the goal is at least in principle better, so that's something, at least. although i will say, if someone releases a data visualization library under the Hippocratic License and someone else uses that library to display leaked personal information of police officers who got away with murder, there are several articles of the Universal Declaration of Human Rights that'd arguably be violated, so the library author would likely have grounds to make a nuisance of themself. and that sucks shit. the fact that the website for the Hippocratic License is firstdonoharm.dev kinda gives the whole thing away, because sometimes a little harm in one way prevents a much greater harm in some other way. there's a reason doctors don't use the hippocratic oath anymore.

even setting that aside, there's a far greater issue with the Hippocratic License. show me a corporate lawyer who'll look at a license that says "i can drag you into arbitration proceedings that have to be public whenever i want and there's no consequences for me doing that in bad faith" and say "yeah that looks good, we can use this library" and i'll show you a corporate lawyer who's gonna get fired tomorrow. the free software movement tried and failed to use a license to trick corporations into sharing their values. the ethical source movement appears to be trying to use a worse license to trick corporations into sharing less concretely defined values.

until all the talented people in that community start doing more useful things with their time, we can at least learn a few things from this preemptive failure. one, trying to bake the complexity of an ethical system into your license is a fool's errand that will not go well. two, if you're writing a license to coerce companies into behaving differently, don't scare them off right out of the gate with a poorly considered enforcement system.

options

the term "post-open source" apparently was used by a couple people in like 2012 to refer to just not giving your code a license. it's got a wikipedia page that's had the "this might not be notable enough for wikipedia" box applied to it since 2013. i am declaring that Basically Dead and so i'm using that term in a broader way now.

so what do we do after open source has eaten the world? the retro option, apparently, is to skip the license entirely. it'll scare off the corporations, since they technically can't safely use your work if you maintain full copyright. and as actual lawyer Luis Villa pointed out at the time, the idea that you need to give other people permission to do things like modify your code for themselves is something we shouldn't automatically take for granted. (although i must say, for someone who claims to hate "permission culture" so much, Nina Paley sure does seem concerned with giving people permission to count as women. TERFs fuck off, now and forever.) not using a license at all can be interpreted as a conscious rejection not just of copyright but also of the endeavor to wield copyright as a tool for justice at all.

however, not using a license at all also makes it complicated for actual human beings who want to use your software. Villa points to a favorite of mine, the Do What The Fuck You Want To Public License, as a way to make the implicit permissiveness of rejecting licensing altogether explicit while preserving the anti-serious aspect. however, once the corporations realize that they're allowed to use software that says fuck, they can and will exploit the shit out of WTFPL software, so this does not provide a long term solution for the problems with open source. (it is, however, really good, so i will count it as post-open source at heart even though it is essentially just open source). its nominally equivalent but more serious cousin, zero-clause BSD, was written by the same Rob Landley whose experience navigating GPLv2 vs GPLv3 was so unpleasant back in the day; it's no fun, and i wouldn't call it a post-open source license, but it is in a very real way a post-free software license, and the exact opposite of the GPL. and in fairness i'd be trying to write the opposite of the GPL after that mess too.

the ethical source people are trying to use the hippocratic license to make it illegal to use certain software if you're doing bad things. the issues with that were the broad definition of "bad things" and the weird enforcement provisions. you can take both of those to the other extreme and get the JSON License. it's just a regular MIT/BSD/X11/whatever permissive license but with an extra caveat:

The Software shall be used for Good, not Evil.

now, this is basically decorative (although evidently IBM paid the author for permission to do evil with that software, which is fucking beautiful), but it does also scare off corporations while letting normal people do whatever. i actually had a brief twitter exchange with the unparalleled jenn schiffer about the effectiveness of the json license a while back, but she understandably doesn't let ancient tweets linger forever, so whatever actual points were made there are lost to time. it does at least manage to solve the problems with the hippocratic license, though: the definition of evil is left completely implicit anyway, and the mechanism for enforcement is just copyright law like with any old license. now, since the vagueness is left implicit, there's room to argue that the clause is unenforceable. nobody has tested it, but that's a loophole waiting to be exploited, and also it's not as fun as the WTFPL. as such, right before i started writing this blog post i wrote the fuck around and find out license v0.1 (or FAFOL for short), which replaces the json license's ethics disclaimer with something more clear:

the software shall be used for Good, not Evil. the original author of the software retains the sole and exclusive right to determine which uses are Good and which uses are Evil.

now it is unambiguous in its intent, and also, it says fuck in the title. as such, it is the only good software license.

update 2020-08-17: i have set up broader infrastructure around the Fuck Around and Find Out License, if you're interested.

on a more sincere note, some licenses are trying to solve the problem of corporate exploitation by bringing back into fashion the idea of public-private licenses, where the default license is principled and corporations can simply pay for an exception and be covered by a different license instead. the most interesting of these projects, at least as of August 2020, is license zero, run by actual lawyer Kyle E. Mitchell, which offers two different public licenses, one standard private license template, and infrastructure for automatically selling exceptions. their Parity license is a share-alike license that allows any use that is also published under an open license. their Prosperity license allows any use as long as it is not commercial in nature; as such, it technically doesn't satisfy the Open Source Definition and is thus in a very concrete sense a post-open source license. their Patreon license, which isn't linked on their homepage at all, grants an automatic license exception for certain financial supporters. Kat Marchán, whose tweet i opened this blog post with, has a blog post of their own explaining one approach to using license zero's tools as a solution to the open source sustainability crisis. license zero the project appears to be currently working through some branding issues, and might have a different name and structure by the time you're reading this. but as it stands it's at least relevant.

an additional concept comes once more from actual lawyer Luis Villa, who was talking about data and not code when he said all this, but i think it can be applied to code too. i'll let him summarize his post himself:

tl;dr: say no to licenses, say yes to norms.

a license is a tool of the law, but the law is not actually very good at delineating the exact boundaries of ethical behavior (in either direction). as such, the approach Villa describes is to tell the law to mind its own damn business and use a maximally permissive license, and then use social norms to delineate what behavior you do and do not find acceptable. norms are tough to start from scratch, but sociologically they can fill a similar role in principle to laws while maintaining flexibility. i'm not quite sure what a normative approach to post-open source software would look like - i'm not aware of anyone attempting to implement it, and i'm not sure i'm ready to be the first - but most likely it'd combine the WTFPL (or, more plausibly, zero-clause BSD) with an ecosystem of standard sets of norms similar to the current varieties in codes of conduct.

update 2020-08-15: actual lawyer Kyle E. Mitchell proposed an implementation of this approach in early 2019 and i think everyone should go read that proposal right now and then come back to this blog post.

and since i've been quoting him the whole time, i should probably also give a shout out to actual lawyer Luis Villa's current project, Tidelift, which is trying to address open source funding at both ends. for corporate clients, (it looks like) tidelift is selling known-good, actively maintained, secure dependency subscriptions, and for open source maintainers, they're (i think) offering not just a proportional cut of the subscription revenue but also resources for keeping projects good, maintained, and secure. i haven't used it on either end, i'm just paraphrasing their marketing copy, but they do exist.

evaluation

so those are some options for what we do next. which ones are good? here we venture even deeper into my arbitrary, poorly informed, untrustworthy opinion than we already were.

rejecting licenses altogether is fun but feels kinda halfhearted. like, if you think licenses are a waste of time, you can just use the WTFPL and get in principle the same effect but with more gratuitous profanity. also, you can't refer to software that doesn't have a license as "unlicensed" because some chucklefucks decided to make a license called The Unlicense and so it's ambiguous now. "license-free" just doesn't have the same ring to it. and more concretely, if you have a real organization that wants to do actual good with your work, they probably still have a lawyer telling them copyright exists, and it'd be good to give them explicit permission to be doing good things.

the zero-clause BSD license is the most open of open source licenses, and as such it inherits all the issues of the open source movement it is attached to. it's essentially the same as releasing your software to the public domain, skipping copyright entirely and giving basically unlimited permissions, and therefore providing no protection from exploitation. the WTFPL is in practice probably equivalent, but in theory scares off lawyers by being impossible to take seriously. however, i remember when i got into dogecoin back when dogecoin was a Thing i thought it was impossible to take seriously and therefore immune from the cryptocurrency true believers, and that wound up pretty decidedly not happening. so a surface-level anti-serious tone is not foolproof protection against bad things. i've released software under the WTFPL, and i'd likely do it again for code i have no interest in maintaining for other people's benefit, but i would never use it as a license for a library i wanted other people to use.

if i recall correctly, the JSON license was explicitly intended as a jab at corporate lawyers, and so it is close in spirit to the WTFPL. and my FAFOL makes that harmony even greater. but as we (or at least some of us) learned from the free software movement, using a license as a tool of enacting corporate ethics by proxy is essentially impossible; corporations interpret ethics as damage and route around them. so as funny as it is, it's not actually useful.

license zero's work has a chance to succeed at creating funding opportunities for software maintainers. if you're going to want to cut into a corporation's profits, the best way that can go for you is if they can budget in the cost of your exception. i'm not aware of instances of that actually working super well for anybody, but maybe it's happened and i haven't heard, or maybe it'll happen as time goes on. same goes for tidelift, honestly. trying to solve specifically the maintainer-side economic issues is an approach i'm not qualified to evaluate, but it definitely feels more like a medium-term patch to the open source movement than a long-term fix.

i think the normative approach is at least in principle worth exploring, and maybe the next project i release will be stapled to an experiment with that. it definitely feels like it has potential, and could actually supplant the open source model if it works well. plus the idea of replacing laws with explicit but informal expectations and letting the community self-regulate warms my anarchist heart.

conclusion

FOSS is dead. free software died long ago, and open source software was a lich the whole time, only now claiming victory and beginning to pull up the ladder behind it. what will come next?

i can't predict every aspect of the post-open source movement, but i can tell you one thing it'll absolutely require if it's going to be meaningful.

what really killed mozilla? what really killed free software? what really gave us the already-dead open source movement?

optimizing for profit at the expense of any other consideration. chasing short-term gains and ignoring long-term sustainability or justice. squeezing every drop of surplus value out of every person within reach and putting it in the hands of a dozen investors and overpaid executives.

in a word, capitalism.

if post-open source wants to not die the same death, it will need to explicitly and aggressively fight its greatest existential threat.

Monads, Explained Without Bullshit

2020-07-18T00:00:00Z

edit 2025-03-04: this explanation is bad in the same way that most monad explanations are bad: it doesn’t address why the abstraction of “monad” is valuable. the first explainer i’ve seen that actually explains why it’s worth understanding is Demystifying monads in Rust through property-based testing; go read that instead.

there's a CS theory term, "monad," that has a reputation among extremely online programmers as being a really difficult to understand concept that nobody knows how to actually explain. for a while, i thought that reputation was accurate; i tried like six times to understand what a monad is, and couldn't get anywhere. but then a friend sent me Philip Wadler's 1992 paper "Monads for functional programming" which turns out to be a really good explanation of what a monad is (in addition to a bunch of other stuff i don't care about). so i'm gonna be repackaging the parts i like of that explanation here.

math jargon is pretty information-dense for me, though, and my eyes tend to glaze over pretty quickly, so i'll be using Rust (or an idealized version thereof) throughout this post instead of math.

so, a monad is a specific kind of type, so we can think of it like a trait:

trait Monad {
    // TODO
}

Rust has two types that will be helpful here, because (spoilers) it turns out they're both monads: Vec and Option. now, if you've worked with Rust before, you might be thinking "wait, don't you mean Vec<T> and Option<T>?" and that's a reasonable question to ask, since Rust doesn't really let you just say Vec or Option by themselves. but as it happens, the monad-ness applies not to a specific Vec<T> but to Vec itself, and the same goes for Option. which means what we'd like to do is say

impl Monad for Vec {}
impl Monad for Option {}

but Rust won't let us do that because we can't talk about Vec, only Vec<T>. this is (part of) why Rust doesn't have monads. so let's just kinda pretend that's legal Rust and move on. what operations make a monad a monad?

new

Wadler calls this operation unit, and Haskell calls it return, but i think it is easier to think of it as new.

trait Monad {
    fn new<T>(item: T) -> Self<T>;
}

new takes a T and returns an instance of whatever monad that contains that T. it's pretty straightforward to implement for both Option and Vec:

impl Monad for Option {
    fn new<T>(item: T) -> Self<T> { Some(item) }
}

impl Monad for Vec {
    fn new<T>(item: T) -> Self<T> { vec![item] }
}

we started out with a stuff, and we made an instance of whatever monad that contains that stuff.

flat_map

Wadler calls it *, Haskell calls it "bind" and spells it >>=, but i think flat_map is the best name for it.

trait Monad {
    fn flat_map<T, U, F: Fn(T) -> Self<U>>(data: Self<T>, operation: F) -> Self<U>;
}

we have an instance of our monad containing data of some type T, and we have an operation that takes in a T and returns the same kind of monad containing a different type U. we get back our monad containing a U.

as you may have guessed by how i named it, flat_map is basically just Iterator::flat_map, so implementing it for Vec is fairly straightforward. for Option it's literally just and_then.

impl Monad for Option {
    fn flat_map<T, U, F: Fn(T) -> Self<U>>(data: Self<T>, operation: F) -> Self<U> {
        data.and_then(operation)
    }
}

impl Monad for Vec {
    fn flat_map<T, U, F: Fn(T) -> Self<U>>(data: Self<T>, operation: F) -> Self<U> {
        data.into_iter().flat_map(operation).collect()
    }
}

so in theory, we're done. we've shown the operations that make a monad a monad, and we've given their implementations for a couple of trivial monads. but not every type implementing this trait is really a monad: there are some guarantees we need to make about the behavior of these operations.

monad laws

(written with reference to the relevant Haskell wiki page)

like how there's nothing in Rust itself to ensure that your implementation of Add doesn't instead multiply, print a dozen lines of nonsense, or delete System32, the type system is not enough to guarantee that any given implementation of Monad is well-behaved. we need to define what a well-behaved implementation of Monad does, and we'll do that by writing functions that assert our Monad implementation is reasonable. we're going to have to also cheat a bit here and deviate from actual Rust by using assert_eq! to mean "assert equivalent" and not "assert equal"; that is, the two expressions should be interchangeable in every context.

first off, we have the "left identity," which says that passing a value into a function through new and flat_map should be the same as passing that value in directly:

fn assert_left_identity_holds<M: Monad>() {
    let x = 7u8; // this should hold for any value
    let f = |n: u8| M::new((n as i16) + 3); // this should hold for any function
    assert_eq!(M::flat_map(M::new(x), f), f(x));
}

next, we have the "right identity," which says that "and then make a new monad instance" should do nothing to a monad instance:

fn assert_right_identity_holds<M: Monad>() {
    let m = M::new('z'); // this should hold for any instance of M
    assert_eq!(M::flat_map(m, M::new), m);
}

and last but by no means least we have associativity, which says it shouldn't matter the sequence in which we apply flat_map as long as the arguments stay in the same order:

fn assert_associativity_holds<M: Monad>() {
    let m = M::new(false); // this should hold for any instance of M
    let f = |data: bool| if data { M::new(3usize) } else { M::new(7usize) }; // this should hold for any function
    let g = |data: usize| M::new(vec!["hello"; data]); // this should hold for any function
    assert_eq!(
        M::flat_map(M::flat_map(m, |x: bool| f(x)), g),
        M::flat_map(m, |x: bool| M::flat_map(f(x), g))
    );
}

so now we can glue all those together and write a single function that ensures any given monad actually behaves as it should:

fn assert_well_behaved_monad<M: Monad>() {
    assert_left_identity_holds::<M>();
    assert_right_identity_holds::<M>();
    assert_associativity_holds::<M>();
}

but. why

well. monads exist in functional programming to encapsulate state in a way that doesn't explode functional programming (among other things, please do not @ me). Rust isn't a functional programming language, so we have things like mut to handle state.

there's a bit of discussion in Rust abt how monads would be actually implemented - the hypothetical extended Rust that i use here is not actually what anyone advocates for, you can look around for yourself if you care - but even the people in that discussion seem to not really explain why Rust needs monads. so all of this doesn't really build up to anything. but hey, now (with luck) you understand what monads are! i hope you find that rewarding for its own sake. i hope i do, too.

What, Then, Shall We Do?

2020-07-15T00:00:00Z

america is at a crossroads of sorts. widespread dissatisfaction with how governments at all levels handled the COVID-19 pandemic, decades of police brutality overwhelmingly targeting POC, two presidential candidates nobody (or at least nobody worth a damn) really likes. we (by which i mean the american left, broadly speaking) see these futures unfold before us, and ask ourselves "what, then, shall we do?" i'm just some random dipshit, i'm not qualified to give an answer, but i can think about what we shall do specifically when it comes to the upcoming presidential election.

the very marginally lesser of two evils

obviously voting for donald trump is inexcusable. he's a deranged senile incestuous racist rapist whose occasional halfhearted gestures towards the working class are transparently borne of a desire for self-preservation rather than any actual good will. he may occasionally claim to be an ally for queer people, or people of color, or women, but his record stands in contrast to any of these claims - he has done more material harm to these groups than he has even bothered to acknowledge - and so only profound gullibility could lead anyone to believe this. even the most negligible support of him is also a tacit acceptance of the entire political system that allowed him to gain what power he already has, and trusting that system to hold him in check is foolish.

oh shit did i say donald trump there? i meant joe biden. and also donald trump.

the least of a dozen evils

so joe biden sucks, and we cannot start ridin with biden. the democratic primary was what could generously be described as a mess, with the maybe-depending-on-who-you-ask winner of the first primary dropping out early to try to donate his momentum to an even more useless, even more racist moderate. the party establishment threatened to punish states that postponed their primaries in light of an ongoing pandemic that made it unsafe to vote, contributing to widespread voter suppression. clearly the democratic party is no friend to the left, and cannot be trusted. so what other parties can we support?

well, about that. let's look at the third parties that were around in 2016. the libertarian party is - setting aside the libsoc caucus, who are probably cool but wasting their time - just for conservatives who want to smoke weed, and the constitution party is for religious conservatives who are too cool for the republican party, so neither of those is worth a damn. we can also ignore the tiny parties that only exist in like three states. that leaves us with like two third parties that could conceivably be worth caring about.

most notably, we've got the green party. on the ballot almost everywhere, which is nice. they got like 2.5% of national votes back in 2000, and they cleared 1% in 2016. their 2020 nominee is Howie Hawkins, who apparently worked with Murray Bookchin for a while, and as a communalist myself i gotta say that's pretty epic. however. according to somebody who was running in the green primary and lost, there were some party-level shenanigans pulled to swing the process towards hawkins - local parties officially hosting hawkins' campaign events before the primary was held, party officials also being hawkins campaign staff, etc. considering that a lot of ppl are mad at the democratic party for pulling the same shit, that's not great. and also hawkins has been kinda both sidesy abt antivaxx stuff, which is cringe. you're allowed to not care if you want, but i'm not sure "get the greens past the 5% threshold so they get federal funding in 2024" is really a capital-S Solution.

in the other corner we have the Party for Socialism and Liberation. socialism and liberation are both cool things to have. also their vice presidential candidate is Leonard Peltier, a political prisoner allegedly involved in the murder of two FBI agents, so that's pretty based. however, they were only on the ballot in a handful of states in 2016, so they may or may not even have enough reach to be worth caring about even if they nominated Marx and Engels themselves. also even in the states where they exist they haven't managed to achieve any meaningful electoral results. and one of their most prominent members, Michael Prysner, is a military intelligence war crimes doer; transformative justice is a cool thing and all but for fuck's sake assume military intelligence dudes are compromised six ways from sunday and don't let them have major influence in your vanguard. again, feel free to not care, but i do.

there are non-political-party organizations like the DSA, which i'm a dues-paying member of, but i don't think pivoting one of them into a political party or spinning up something new would really help either. ballot access is key to making a case for having a chance to win despite being a third party, and even the DSA couldn't get that in most states on a shorter than several years scale.

so. the green party is recreating the favoritism that was part of why we're pissed off at the democratic party, and the PSL is hanging out with war criminals while being missing or useless everywhere, and anything else will take eons to get off the ground and so doesn't give us anything to do in the meantime. what, then, shall we do?

no fate but what we make for ourselves

maybe electoralism is a waste of energy. maybe voting is a waste of time. when we vote, we don't get shit. when we take to the streets and burn shit down, we are heard.

politicians already don't feel obligated to try to earn your vote. make them earn peace. they should be afraid of us, them and the cops and everyone who works to defend and prop up the indefensible on a daily basis. there are more of us than there are of them. violence is bad but complacency is worse. in the 60s it was the ballot or the bullet, and comrades, i don't think the ballot has done what it needed to.

Setting Up A Police Scanner With An RTL-SDR

2020-06-26T00:00:00Z

so my city has a community-run police scanner broadcast on the internet, but the person who runs it is a bootlicker who's been threatening to shut it down if people are using it to make trouble for the cops. so i figured i'd set up my own. this is how i did it, hope it's useful.

shopping

you'll need an RTL-SDR unit. i recommend the dipole antenna kit as well, so you don't need to make any additional purchases. if you're a radio enthusiast already, you might have a better antenna available, but if you're like me you do not and it's worth the US$10. mine took a bit over a week to arrive. if you're extremely unlucky, you might need two of them, but i was fine with just one.

basic setup

once your RTL-SDR arrives, you'll want to put together your antenna. if you're lucky, like i am, you can just extend the antennas arbitrarily and it'll work fine; if you're cursed, the RTL-SDR website has resources on how long is ideal for various frequencies.

connect the antenna to the RTL-SDR unit, plug it in, and follow the RTL-SDR quick start guide. SDRSharp will work, or any of the other Windows options. some of what we'll need is only available on windows.

once your RTL-SDR's drivers are sorted out, find the specifications for police radio in your area on RadioReference. click your state, click your county, scroll down and see if there's a link above a frequency table for you. if you're lucky, there is, and if you click it there's a page with a table with System Type and System Voice entries at the top. mine has a system type of EDACS Networked Standard and a system voice of ProVoice and Analog, so the rest of this assumes that's what you've got as well. if not, good luck.

there should be a table for System Frequencies on your RadioReference page. start up SDRSharp and tune your radio to the first frequency listed there. you'll probably hear a bunch of static and the UI will look something like this:

see how there's one constant signal and a bunch of other signals that appear and disappear all over the place? well, that's trunking, and the constant signal is our control channel. if you don't see it, you can click and drag on the bottom axis of the top panel to change the view. once you've found that constant signal, click on it to get the approximate frequency, go back to your frequency table and the closest thing to that will be the exact frequency. it should sound like a series of weird beeps instead of static. remember that frequency, it'll be important later.

update 2020-07-31: that control channel can change between the frequencies listed on RadioReference. if things randomly quit working, come back to this step, and see if the control channel has moved. i'll mark down below the places that need changing accordingly.

specific setup

EDACS is a trunked system, so we're using RTL-SDR's trunked radio tutorial as our guide, mostly. that guide assumes we have two RTL-SDRs, but there's a piece at the end explaining how to do it with just one. that sucks. i'm going to paraphrase it here.

first, we're going to download the software we need: Unitrunker, VB-Cable, and DSD+ (extract both the regular and DLL downloads to the same folder). install unitrunker and VB-Cable and extract dsd+ somewhere convenient. you might need to reboot after installing VB-Cable because computers are bad. VB-Cable might set your default input and output devices to the wrong things when you install it, so switch them back if it does.

open up dsd+. it'll open four different windows, one of them should have a list of audio input and output devices. check the number in the input list that goes with CABLE Output - for me it's 3. pull up notepad and make a new file. since my input was number 3, i'm typing

DSDPlus.exe -i3M

in that file: if yours is not 3, put whatever the correct number is for you instead of 3. then, save the file, find your DSDPlus folder, make sure the type is set to "All Files", and name the file run.bat. close dsd+, go to that folder, and open that run.bat file you just created. it should pull up dsd+ and if you're lucky it'll print

audio input device #3 (CABLE Output (VB-Audio Virtual ) initialized

or something like that. leave that open.

open up unitrunker. click the + to add a new receiver, and click the RTL2832 button to add your RTL-SDR. set your settings around like this:

the most important things are the RTL Device, the sample rate (2.56 msps), and the VCOs (2 VCOs). i do not know what a VCO is and i do not care enough to find out. we should now have two VCO tabs next to our info tab. the first one needs to look kinda like this:

the important things are the Role being Signal, the Park frequency being the control channel we found earlier (mine is 851.7625), and the Mute box being checked.

update 2020-07-31: if the control channel changes, this Park frequency is one of the two things you'll need to update.

the second VCO should look kinda like this:

the important things are the Role being Voice, the Deemphasis box being unchecked, and the Digital Output being set to your CABLE Input. this means it will connect up with dsd+ listening to our CABLE Output.

press Play now; it should pull up a window with a Channels tab. the Channels tab should look something like this:

but the Frequency column will all be zeroes except for the control frequency we found earlier. you'll need to copy over the rest of the frequencies manually from the RadioReference site.

update 2020-07-31: if the control channel changes, you'll need to uncheck the Control box on the old control channel, and check the Control box on the new control channel.

press the stop button and the play button again, and everything should in theory be working. ideally, the Call History tab will be crowded and updating pretty frequently, and unitrunker will be passing things along to dsd+ which will give us the audio we want. technically, this is enough.

groups

the thing, though, is we don't have context for any of this. for now, at least. RadioReference should have a table or several of talkgroups - the "list all in one table" button may come in handy - and we can use that information to figure out who we're hearing, and have at least some control over who takes priority if multiple people in different contexts are talking at once.

find the main unitrunker window - it's titled "Universal Trunker" and if you don't have it open just click the home button a bunch until it opens - and then open the Systems tab and double-click the one that exists. open the Groups tab in that window, and it should give you a massive list with columns for ID, Label, and a bunch of stuff we don't care about right now. the ID matches up with the DEC column in the RadioReference table, and the Label can be either "Description" or "Alpha Tag" or something you make up yourself if you feel creative. if you pay RadioReference $15 for a Premium subscription then unitrunker can import that data automatically.

once you've filled that all in, open the Sites tab and double-click the entry you see there, then open the Call History tab. the group labels you added should now be appearing in the Audience column; the LCN and Frequency should turn green for what unitrunker is currently listening to.

back in the Groups tab, you can edit the Priority values to control which groups will be chosen more often - as far as i can tell, higher priority groups will interrupt lower priority groups, and equal priority groups will just play whoever started talking first.

broadcasting

this setup lets you listen to things locally, but what if you want your comrades with no hardware to be able to also listen? the laziest option is to just stream the Call History window on Twitch or something, but in theory there are better options. RadioReference runs Broadcastify, which is designed for hosting police scanner livestreams, but they have to manually approve your broadcast, which is annoying for short term activity. you could run an icecast server yourself or something, but that takes effort to configure. honestly all of those kinda suck but those are your options as far as i know.

update 2020-07-31: you can also let your friendly neighborhood succulent run an icecast server for you; reach out to me if you need something like this. if you've got an icecast server, you'll need to pay for (or otherwise obtain) VB-CABLE A+B, set up VB-CABLE A, and grab butt (broadcast using this tool).

you'll need to set DSD+ to output to "CABLE-A Input" like how you set it to input from "CABLE Output" - Cable A is the fourth output in DSD+, so my run.bat now looks like this:

DSDPlus.exe -i3M -o4

run butt, pull up the settings, and under the Audio tab set the Input Device to "CABLE-A Output". (for bonus points, set the Streaming Codec to AAC+.) under the Main tab, Add a new Server and put in whatever info your icecast server admin told you to use. now restart your DSD+ and hit butt's play button to start streaming, and you should be running a livestream of your police scanner that is accessible over the internet.

Lifehack: Running An Entire Desktop Session Remotely With MobaXterm

2020-03-20T00:00:00Z

Since my university has gone as remote as possible due to coronavirus, I was looking at ways to run an entire desktop session remotely over SSH, using MobaXterm because it is very cool. Here are the two steps to doing that.

Open your MobaXterm settings, go to the X11 tab, and make sure that the server display mode is set to windowed mode. If you run individual programs over X11 forwarding, this is worse, but for an entire desktop session it is better.
Duplicate your regular command line session that already works, and under the "Advanced SSH settings" tab, set "Execute command" to env GNOME_SHELL_SESSION_MODE=ubuntu gnome-session --session=ubuntu. (If you're not running the same setup I am, look around in /usr/share/xsessions/, pick something that looks reasonable, and use everything after Exec= on the line with that.)

At this point, you should be set. You'll need to hit the "log out" button to smoothly exit the connection. For me, this is extraordinarily slow, but that could easily be just because the machines I'm connecting to are being used a lot.

Rust 2020: Write Once, Run Anywhere

2019-11-03T00:00:00Z

thing that is cool: writing the same codebase and having it run on desktop, mobile, and web

thing that is lame: JavaScript is the only language where people really do that right now, outside of big commercial game engines

things that need to happen for Rust to get there:

promote more platforms to tier 1, or maybe introduce a "tier 1.5" where std is guaranteed to work but rustc and cargo are not (although it'd be cool for rustc to work on WebAssembly)
- iOS: aarch64-apple-ios, armv7-apple-ios, i386-apple-ios, x86_64-apple-ios
- Android: aarch64-linux-android, arm-linux-androideabi, i686-linux-android, thumbv7neon-linux-androideabi, x86_64-linux-android
- WebAssembly: wasm32-unknown-unknown (or one of the other wasm32 targets)
test platform abstractions (graphics libraries, game engines, UI frameworks) on all of those
get some high-level examples together of how to use Rust to write performant cross-platform code

Email Notifications for SSH Logins From Scratch

2019-03-09T00:00:00Z

I just spent a while trying to make this happen, so I'm putting this here so I don't have to redo all that research next time.

Configuring Email

This guide from Linode explains how to install and configure Postfix, which you'll need. Be careful, though: when it says [mail.isp.example] the [] aren't just to indicate placeholders. You do need a literal [] around your hostname in your Postfix configuration.

Also, if your setup is like mine, if you try to send email from x@<your domain> to y@<your domain>, Postfix will unhelpfully try to deliver it locally. This Server Fault answer explains how to tell Postfix to not do that.

If you're really unlucky, you may also need to create local users x and y (with useradd -M -N -s /bin/false <username>). I did that before I fixed the Postfix config, so fixing the Postfix config may be enough.

Configuring SSH

Thankfully, by the time you've got the email configuration out of the way, this guide from VPSInfo fully explains how to set up SSH to send emails on login. This will send emails even if no login shell is run on the ssh connection.

Since you need to store your credentials in the Postfix configuration, a sufficiently motivated attacker could probably retrieve them. As such, if you're using email notifications to detect security breaches, I would suggest not sending them to the same address that they're being sent from.

As a security measure, this is purely reactive; you can know that someone has illegitimately connected, but whatever they're trying to do has already been done. A proactive measure would be to implement 2FA on SSH logins, as per this guide from DigitalOcean.

Announcing vidslice

2019-02-27T00:00:00Z

I just released version 1.0 of vidslice, a wxPython GUI that wraps ffmpeg and youtube-dl to make "give me from 1:03-1:15 of this youtube video" really easy to do. More details are in the project README.

Futures

2018-08-31T00:00:00Z

I'm going to be graduating from college in December and I'm a little bit freaking out. Not because I don't have a plan, but because I have six plans.

Melody the grad student

I may hate college, but that doesn't mean I'm not good at it. I'm still not entirely sure if it's college in general I hate or just my college in particular, but I've got a hunch it's the latter. In that case, I could absolutely try to get a master's in computer science at a halfway decent university.

This would be the next step towards getting a Ph.D. and becoming a computer science professor, which is a thing that I think would be super cool. However, the step itself would take a whole bunch of work and I don't necessarily have all that much interest in CS theory. Someone suggested that I could pursue a master's in philosophy instead, which is an intriguing but counterintuitive prospect that I haven't necessarily thought all the way through yet.

I don't think I could take another semester of college right now, but most places are probably set up for people to start in the fall and not the spring, so that works out.

Melody the indie miscellany dev

I am a walking collection of half-baked project ideas waiting to be built. Web application that bridges Twitter content into the ActivityPub/OStatus fediverse (Mastodon et al). No-code-required Discord bot toolkit. TodoMVC but for desktop GUI frameworks.

If I had the time, I could actually build some of those things. I'd need to make money somehow, though; if this were me full time I'd probably be on Patreon or trying to figure out non-shady ways to monetize this stuff. However, being solely responsible for things that people actually use would be super stressful. Plus I don't think I have the discipline to do anything if there's nobody to make me do it.

Melody the indie game dev

Games are cool. I've made a handful already for game jams and whatnot. Actually, the first thing I actually did as boringcactus was make a game for a game jam.

The trouble is that I don't have a big-I Idea that I would pursue if I decided I wanted to be an indie dev. Most of my jam games are either finished or not worth finishing. I'd love to make something that's an indie success story like Night in the Woods or Gunpoint, but those games already exist. Plus the odds of taking off like that are kinda one-in-a-million.

Melody the musician

This is a long shot. But music production and performance is a thing that's always been important to me. Early in high school I made some garbage tier EDM that didn't go anywhere.

What I'd really like to do is live looping covers of things that weren't really designed to be replicated like that. I think something like this live performance of Marian Hill's Down would be super amazing to do with more complicated songs. I wrote a REAPER plugin that would help with stuff like that, but I haven't actually used it for anything yet.

Melody the small tech co employee

This is a rant that I'll probably give in more detail some other time, but I think the Silicon Valley venture capital model is directly responsible for how shitty the tech industry is.

If I wanted traditional employment, the best environment for it would be a small company that isn't beholden to a VC firm. A company that can keep its standards and leave growth on the table if it'd be unethical to pursue it is a company that I'd probably be comfortable working for.

Melody the sellout

Of course, small companies don't get that way by hiring every rando with a résumé. Big companies with bad ethics are almost always hiring. And they're the most likely to still be around several years from now.

Some Thoughts About Work

2018-07-17T00:00:00Z

I think there are three things that can make work rewarding:

Working with cool people
Working on cool things
Working in cool ways

Right now (summer of 2018) I am working with cool people but on boring things in less-than-ideal ways. I think that's the main reason I don't really enjoy this internship. But hey, it'll be over in two weeks.

Working with cool people

It's nice to work with cool people. People I'm more comfortable working with are people I'll work better with. People whose judgment I trust are people whose leadership I'll find easy to respect.

Working on cool things

If I can explain the thing I'm working on to somebody and get them excited about it, that's great. If I'm excited about it but nobody else is, that's kinda enough. If even I think the project is kinda boring, I'll still get it done, but I won't enjoy the process.

Working in cool ways

I'm not sure there is a right way to run big projects, but I know there are a bunch of wrong ways. The more people are going to wind up touching your project, the more important it is to get the architecture right. If your project is going to be big, don't put all the important guts of it in the same 4000-line switch statement.

Line-by-line code reviews with the entire team can be helpful if everybody needs to know exactly what's going on, or if everybody might have something valuable to say or to learn. Line-by-line reviews of automatically generated XML are...less likely to be helpful.

What that might mean

I don't know that I'd function well if I were self-employed. I doubt I have the motivation or discipline to pull it off, plus then I wouldn't get to work with cool people.

I know "cool" is a relative term, but I think I might be a little too picky about the sort of thing I'd want to work on. I think Silicon Valley venture capital culture is such that the money has gotten so dense it's formed a black hole from which no ethics and no perspective can escape. Advertising sucks, just about every blockchain was a mistake, and AI is going to spend the rest of the century wobbling between the almost-not-useless of voice assistants today and the actively-making-things-worse that YouTube has running demonetization and recommendations. Not all growth is worth it; it's not just OK but good to leave money on the table if you can walk away with your soul (this is the part VC tends to ruin). I don't know what's good, but I know what's bad, and frankly most stuff is bad.

Doing big projects right is hard. My solution would be to just not do big projects. Somebody has to, but it doesn't have to be me.

Slicing and Dicing Images with GIMP and Python

2018-06-23T00:00:00Z

Let's say you have one big image (say, a Telegram sticker) and you need to dice it into a bunch of smaller images (say, Discord emoji). GIMP can let you do that manually, but frankly so can simpler tools. GIMP also has powerful scripting support with Python (and also Scheme, but miss me with that) that can let us do that automatically.

TL;DR how do i do the thing

Save your large image somewhere with a useful filename; this script will chuck _1_1 and _1_2 etc on the end of the existing filename.
Open that image in GIMP.
Go to the Filters menu, open Python-Fu, and hit Console.
Set up the width and height of your tiles. For 64x64 tiles, for example, type
```
WIDTH = 64
HEIGHT = 64
```

Paste in this big ol' block of code and let it build your tiles and print out the text you can enter in Discord to reconstitute your original image:

from gimpfu import *
from __future__ import print_function
import os.path

def crop(image, x, width, y, height):
    pdb.gimp_image_crop(image, width, height, x, y)
    x_idx = x / width + 1
    y_idx = y / width + 1
    filename = pdb.gimp_image_get_filename(image)
    dir, name = os.path.split(filename)
    root, ext = os.path.splitext(name)
    ext = ".png"
    output_root = root + "_" + str(y_idx) + "_" + str(x_idx)
    output_name = os.path.join(dir, output_root + ext)
    layer = pdb.gimp_image_get_active_layer(image)
    pdb.file_png_save_defaults(image, layer, output_name, output_name)
    print(":" + output_root + ":", end="")
    pdb.gimp_image_delete(image)

image = gimp.image_list()[0]
filename = pdb.gimp_image_get_filename(image)

for y in range(0, 512, WIDTH):
    for x in range(0, 512, HEIGHT):
        crop(pdb.gimp_file_load(filename, filename), x, WIDTH, y, HEIGHT)
    print()

pass

There are two minor issues with actually using this code to convert a Telegram sticker into Discord emoji that I'll get to later.

The Code, Splained

I'll walk through each bit of the code segment above and explain why it's there.

We need the GIMP libraries, the Python 3 print() function (because as of GIMP 2.8.22 the GIMP console is still on Python 2), and some path manipulation functions.

from gimpfu import *
from __future__ import print_function
import os.path

We're going to crop an image with an X and Y offset and a width and height. The first step in generating the tile is telling GIMP to do the actual crop.

def crop(image, x, width, y, height):
    pdb.gimp_image_crop(image, width, height, x, y)

The next step is to figure out the filename for this specific tile; here we're getting an index back from the offsets and width and height.

    x_idx = x / width + 1
    y_idx = y / width + 1
    filename = pdb.gimp_image_get_filename(image)
    dir, name = os.path.split(filename)
    root, ext = os.path.splitext(name)
    ext = ".png"
    output_root = root + "_" + str(y_idx) + "_" + str(x_idx)
    output_name = os.path.join(dir, output_root + ext)

Once we've got a filename, we can save. For some reason GIMP's save functions all depend on both the image and the layer, and on two copies of the filename.

    layer = pdb.gimp_image_get_active_layer(image)
    pdb.file_png_save_defaults(image, layer, output_name, output_name)

Since the goal is to reconstitute the original image from Discord emoji, we assume that they won't be renamed. We need the Python 3 print function here to suppress any characters after the string is printed; the Python 2 print "foo", trick still emits a space.

    print(":" + output_root + ":", end="")

We might as well delete the image from GIMP. I don't know if this actually serves an important purpose or not.

    pdb.gimp_image_delete(image)

We want to grab the original filename.

image = gimp.image_list()[0]
filename = pdb.gimp_image_get_filename(image)

Since we defined WIDTH and HEIGHT manually earlier, now we can loop through the image. I should probably go back in and make it grab the full image width and height, but fuck it, I don't want to.

for y in range(0, 512, WIDTH):
    for x in range(0, 512, HEIGHT):

I don't know if GIMP doesn't expose undo in the Python API or if I just couldn't find it, but either way we don't have undo, so we pass in a fresh copy of the image instead.

        crop(pdb.gimp_file_load(filename, filename), x, WIDTH, y, HEIGHT)

Since we're building up the emoji text for Discord one row at a time, we need to end the row at the end of a row.

    print()

This is just there so the newline after the for loop gets pasted successfully.

pass

The Plot Thickens

The first issue with this approach is that Discord (at time of writing, at least) sets a total of 2.25 pixels worth of horizontal margin between emoji, so your reconstituted image will have weird stripes. It might be feasible to adjust for these in the offsets so that the spacing isn't funky, but honestly that seems like a lot of work.

The second, and more interesting, issue is that Discord has a 50 emoji limit on each server. Slicing a 512x512 image into 32x32 tiles for a full size replica would generate 256 tiles, which might work if you had Discord Nitro and six different dummy servers, but nah. Slicing into 64x64 tiles that'll be rendered at half size only makes 64 tiles, which works out nicely numerically but is still more than can fit on one server. Unless we're clever.

I'm not sure how well this generalizes, but for the sticker I'm working with, 16 of those 64 tiles are fully transparent, and therefore identical. If we could detect this when slicing, we could avoid emitting 15 of those, at which point we come in nicely with 49 tiles, one under the Discord emoji limit. But how can we detect if an image is fully transparent?

Get histogram info for the alpha channel! We can use something like this to count how many pixels aren't fully transparent:

_, _, _, _, visible_count, _ = pdb.gimp_histogram(layer, HISTOGRAM_ALPHA, 1, 255)

So our final code can detect if each tile is fully transparent before it saves and treat all fully transparent tiles as equivalent to the very first one.

from gimpfu import *
from __future__ import print_function
import os.path

empty_tile_name = None

def crop(image, x, width, y, height):
    global empty_tile_name
    pdb.gimp_image_crop(image, width, height, x, y)
    layer = pdb.gimp_image_get_active_layer(image)
    _, _, _, _, visible_count, _ = pdb.gimp_histogram(layer, HISTOGRAM_ALPHA, 1, 255)
    x_idx = x / width + 1
    y_idx = y / width + 1
    filename = pdb.gimp_image_get_filename(image)
    dir, name = os.path.split(filename)
    root, ext = os.path.splitext(name)
    ext = ".png"
    output_root = root + "_" + str(y_idx) + "_" + str(x_idx)
    output_name = os.path.join(dir, output_root + ext)
    if visible_count > 0 or empty_tile_name is None:
        pdb.file_png_save_defaults(image, layer, output_name, output_name)
    if visible_count == 0:
        if empty_tile_name is None:
            empty_tile_name = output_root
        else:
            output_root = empty_tile_name
    print(":" + output_root + ":", end="")
    pdb.gimp_image_delete(image)

image = gimp.image_list()[0]
filename = pdb.gimp_image_get_filename(image)

for y in range(0, 512, WIDTH):
    for x in range(0, 512, HEIGHT):
        crop(pdb.gimp_file_load(filename, filename), x, WIDTH, y, HEIGHT)
    print()

pass

The results are actually fairly impressive, all things considered:

(that sticker is by NL and of Pandora's Fox)

But of course anyone with an ounce of sense would just upload the image so this whole project was a complete waste of three hours.

Windows, Vim, and Python: An Unholy Trinity of Pain

2018-06-17T00:00:00Z

Last summer I figured I'd learn Vim. That did not go well.

I started by stealing somebody's .vimrc, as is natural. In this case the person from whomst I lifted my .vimrc was a Python dev, and I was working in Python at the time, so that was a reasonable choice. But once I opened an actual Python file I got an error message that Vim couldn't find Python.

I did some research and it turned out that even though I'd grabbed the latest version of Vim, it was looking for Python 3.5 and I had Python 3.6, which had been out for a while by then. So I uninstalled Python 3.6 and installed Python 3.5 and started getting a different error message.

A bit more research revealed that my Python was 64-bit but my Vim was 32-bit. Apparently Vim didn't provide official 64-bit Windows builds at that time, so for 64-bit Vim on Windows they just linked to a handful of third party distributions. I went ahead and uninstalled my 32-bit Vim so I could install 64-bit Vim, and then everything worked fine. (Except for all the minor Vim papercuts that eventually led me to write my own Nano clone instead.)

To get Vim and Python to play nice with each other, I had to reinstall both of them.

And that's basically what developing on Windows is like in a nutshell.

But it doesn't have to be this way. If more people treated Windows as a first class platform, the tools to develop on Windows wouldn't be so frustrating to use, and then more people would treat Windows as a first class platform.