I recommend VHS generally for these (we use them for all the ratatui screenshots generally). I'm also playing around with doing a rust version of this (https://www.joshka.net/betamax/)
I haven't used homebridge, but have used HA in the past when I had lights and things hooked up. The UX and configuration surface always felt janky to me. So many little paper cut annoyances across every control / window / menu that you touch. The screenshots of homebridge seem much better at a cursory glance - if so, that's a net gain.
> The real problem is that pretty much the whole stack has a terrible AX story.
> First, most GPU-rendered terminal emulators don't engage in system-provided accessibility APIs AT ALL. Because text is GPU-rendered, AX tooling can't "read" it, it just shows up as an image. This applies to Kitty, Alacritty, WezTerm. My own terminal Ghostty is AX-readable (on macOS), and so are others like iTerm2 and Terminal.app (which admittedly do it better than me, we have gaps to fill).
> Second, there are no terminal sequences or initiatives at all for TUIs to communicate AX information to the emulator, so the emulator itself can't do much more than display a blob of text to AX tooling. We need the equivalent of ARIA-style annotations but for terminal cells, runs, and regions. No such initiative exists. Even if TUIs do great things with the cursor, this is going to bite a lot of use cases.
> As an example of combining the above, I've been working on something with Ghostty where we integrate semantic prompt (OSC133) and AX APIs so that we can present each shell prompt, input, and command as structurally significant to AX tooling (rather than simply a text box where the cursor is somewhere else). This shows the importance of the relationship between terminal specs (OSC133), TUIs (which must emit OSC133), and terminal emulators (which must both understand OSC133 AND communicate it to AX APIs).
> The whole stack is rotten. And no one is earnestly trying to fix it (including me, I have limited time and I do my best but this is a WHOLE TOPIC that requires a huge amount of time and politicking the ecosystem and I don't have it, sorry).
Bonus: a simultaneously awesome and horrible reality is that AI is really helping to improve AX here. A lot of AI tooling uses/abuses AX APIs to make things happen. How is OpenAI reading your list of windows, typing into them, etc? Accessibility frameworks! So a lot more apps are taking AX integration a lot more seriously since its table stacks for AI using it... Sad it requires that but the glass half full is more software is doing that.
>> AX originated in reference to UX (User Experience) and stands for Accessibility Experience. AX is also sometimes used as a synonym for accessibility.
A much more charitable reading of the article is "here's some observations I found interesting / different". I met the author at the conf and watched their talk. Their perspective was very much in the camp of exploration, learning, wonder, etc. and not in the camp of criticism of either rust or vibe coding practices.
Interesting that the talk was quite different, because this clearly AI generated article was condescending and infuriating. Quite a difference apparently.
The weird-looking Rust isn’t really Rust being weird, it’s the type telling the truth.
Result<Option<Result<Message, WsError>>, Elapsed>
That’s three independent “not the happy path” channels: timeout, stream closed,
and websocket error.
The nicer version is not a cleverer match. It’s choosing a domain error shape
and converting into it one layer at a time:
let timed = tokio::time::timeout(duration, receiver.next()).await;
let next = timed.map_err(|_| ReceiveError::Timeout)?;
let item = next.ok_or(ReceiveError::Closed)?;
let msg = item.map_err(ReceiveError::WebSocket)?;
The ugly line is what happens when you have not decided where to normalize the
shape yet.
It's basically doing the same thing that, say, `return true` might do to indicate a function succeeded, but with more explicit types. However, because it uses `Result`, it can be used with the `try`/question mark operator which can be convenient in some situations.
That said, a couple of the examples here feel a bit strange - they're clever things you can do, but they're not necessarily things you often have to do, particularly for a relatively simple task like this. I think the problem with the author's approach is that they can't distinguish between "weird because Rust is weird" and "weird because the LLM generated bad code", because they (understandably) don't have enough experience in what good Rust code looks like.
it is indeed pretty weird. clippy has a lint against this iirc. it's recommended to just create a custom error type, even if its just an empty struct or a single-variant enum
this lets you implement `std::error::Error`, which you really should to make it less painful when you want to erase the type (`std::error::Error` is `dyn`-compatible)
It's not like people regularly decide this is a good return type. Just because Claude isn't good at designing code or what have you doesn't mean rust is bad/weird.
Sure this is something someone can do but it's suggesting the caller doesn't care about why it failed and doesn't need anything from it's success. It's a choice but it's not a typical one. Maybe the fact that it looks weird and there is no comment is a clue that this isn't high quality code.
People really should be more skeptical of LLM coding. Claude is not as amazing as marketing makes it sound. It is amazing in that it can write code and follow specs sometimes, but a lot of quality gets lost along the way without close supervision by someone who knows better
Sometimes you just want a fancy boolean. The advantage is that Result has all the Result APIs and you can compose it with other Results, but otherwise this is just a success bool.
Probably on topic here - I talk like an LLM sometimes, and parse my points through them sometimes. I’d reasonably use that terminology and think nothing of it as it’s precise and correct. That said, this was partially LLM and my thinking here.
yeah, you can have github actions setup on arbitrary pushes to your branches, but there's not a good interface for linking actions to bare commits, and then having conversations etc. The place where that happens is usually a PR.
>it is mostly your build-systems' job to be hermetic, run anywhere, handle cross-builds etc.
yes, and... the idea here is that it would be neat to extend the hermetic builds idea such that this can be run locally / anywhere where there's compute easily. The root problem that's being called out here is that idea of running something until the CI says it's green when there's a change, commit, network call, in the cycle is a pain in the ass. (The best way to avoid this churncycle is to just never write bugs! TFIC ;P)
reply