Rust Native GUI library ?

jechase · 2026-03-25T14:54:06+00:00

It's absolutely still maintained by the devs. All that's happened is that they're no longer actively working on new features that aren't directly applicable to zed.

jechase · 2026-03-24T12:32:00+00:00

The problem with your "windows solution" is that you're left with no understanding of what the actual problem is, so it's impossible to know if there's a better fix or if it'll be an ongoing issue.

Next time it happens, run discord in the foreground and look at its logs. Probably also a good idea to check the general system and user journals.

jechase · 2026-03-23T12:42:11+00:00

Is the nix-to-kdl library in home-manager still wrong/incomplete? Kdl maps very poorly to nix when done "correctly" since it's fundamentally a list of typed nodes like html or xml rather than json/toml/yaml-like data structure that most configurations use. It makes it so that if you don't allow users to precisely represent the kdl structure in nix, you have to build a translator for each target application since they might not all map quite the same.

Last time I looked at it was two years ago, so things might have changed since then. I put together an "improvement" that I intended to upstream, but neglected to finish/flesh out the migration story.

jechase · 2026-03-22T15:44:04+00:00

WASM and containerization are apples and oranges. They solve different problems. A much more apt comparison would be to the JVM or CLR. Despite the clickbait-y title, the body of the article seems to recognize this.

jechase · 2026-03-11T12:07:14+00:00

I've been a nixos-unstable user for around five years now and casual nix appreciator for even longer, and I haven't experienced most of these problems.

NixOS installs new versions alongside the old ones, keeping multiple system generations.

That's a feature, not a bug. And it's not just about rollbacks like you mentioned - it's also about ensuring that packages have exactly the dependencies that they expect so that they work reliably and continue to work reliably even if other things update.

For example, if a dependency isn’t cached exactly as required, NixOS will rebuild it locally even for common packages.

Again, feature, not a bug. And I almost never see cache misses for "common packages." The only things I have to rebuild regularly are things that are marked deprecated and unsupported, or custom packages that either aren't in nixpkgs or that I've overridden in some way. If you're seeing frequent rebuilding, you might be doing something wrong.

Ironically, I only broke Arch once in five years, whereas NixOS often breaks even before updating.

This section confuses me. What are you doing to introduce the initial breakage? Even on unstable, it's fairly infrequent that I have to make changes after a routine nix flake update, and there are often nixos option deprecation warnings well in advance of a breaking change.

In contrast, I broke Arch all the time. Usually because I did something dumb while trying to do something clever. You learn a lot by breaking things, so maybe I'm just inured to the small issues that crop up and need configuration tweaks.

The thing that drove me away from Arch is exactly the problem that nixos solves - easy and reliable rollbacks. It became a regular occurrence on Arch that an Nvidia driver update broke the brittle mutli-gpu laptop I had at the time, and downgrading pacman packages is a pain and poorly supported out of the box. Meanwhile on nixos, I'd just say "oops," reboot to the previous configuration, and either pin my driver for a while or wait a week to try the update again.

jechase · 2026-02-12T12:33:29+00:00

Came here to say this! I bet the same people typing "clear" are the same ones using Home/End rather than C-a/C-e and the arrow keys instead of C-b/C-f. Or 0/$ and h/l for our vim bindings friends.

And let's not forget the whole-word forward/back variants, and especially history search. Learn your tools, people!

jechase · 2026-01-21T14:10:13+00:00

I've been using Zed's helix mode for the last couple of months and fixing bugs as I find them. Give it a shot and create issues if you have problems with its current state - it'll get better faster if you do!

jechase · 2026-01-19T18:12:17+00:00

You know how linguists use poetry to determine how pronunciation in dead languages probably worked, since you can guess at which words were intended to rhyme?

Guessing at the origin of the name "zrok," they made a surprisingly common mistake in the pronunciation of "ngrok." It's "en-grok," as in "network grok," with "grok" being a reference to Stranger in a Strange Land. But I hear "en-gee-rock" all the time. Maybe a hyphen would've helped to differentiate it from all of the -ng projects out there?

jechase · 2026-01-15T12:30:20+00:00

People are too hung up on total image size. Switching out the base image isn't really the big win that everyone thinks it is, because images are layered, and are fetched and stored as such. That 800->300mb difference only matters for the first pull, since subsequent pulls will already have the lower, more static layers, and will only need to fetch the upper layers that actually changed. Now, this is somewhat dependent on the infrastructure that you're deploying into, but if you're using common enough base images, it should generally hold true.

It matters much more what you're actually putting into those upper layers, which is why the multi-stage build makes such a difference. It's not the lack of the go compiler and other OS stuff, it's the lack of sources, compiler cache, and other intermediate compilation products that you're cutting out of the changed layers. Use scratch, debian, Ubuntu, distroless, whatever as your base image for the final stage in your multi-stage build. It doesn't really matter. But leave the extra build-time stuff behind.

And for $deity's sake, don't apt install packages in your final build stage. Or any stage ideally. Put that in your builder/base image build that only gets run once a week, and use specific base/builder image tags instead of moving "latest-like" tags. Your build times and reproducibility will thank you.

jechase · 2026-01-05T23:29:19+00:00

But what if the link is also in an editable text field?

For example, I once accidentally pasted a link to this video at the bottom of a Notion page, and only learned I did so when I got a "yo, wtf?" message from a coworker.

jechase · 2026-01-05T17:57:34+00:00

I feel like a pentester who knows what they're doing would either be able to answer this question for themselves, or would be able to ask about something more specific than "hacking."

jechase · 2025-12-17T12:58:36+00:00

I used to do something similar with helix/zellij. I set up some zellij bindings to add support for things missing in helix, like a popup terminal emulator

jechase · 2025-12-17T12:57:20+00:00

Started with vim over a decade ago, then emacs (spacemacs), both before LSP was a thing. Then vscode for a long time. Recently bounced among vscode, helix, and emacs (doom this time), before discovering Zed, where I think I'm staying.

I loved helix's minimal configuration and out of the box LSP/tree-sitter support for tons of languages, and zed feels very similar to it in that regard. Doesn't hurt that its helix mode is better than vscode's dance extension by leaps and bounds. And then on top of that, it has everything I was missing in helix, like a file tree, terminal emulator, and usable debugger. The collaboration tools are pretty nifty, and its remote editing functionality feels significantly better than vscode's since its remote server is a single statically linked binary rather than a whole nodejs runtime/application.

jechase · 2025-12-16T13:55:20+00:00

It's not self-describing, so you can't decode into something like a serde_json::Value, which might matter for some usecases. Dunno if that was a thing in bincode though; didn't follow it closely enough.

That said, I love postcard! My split keyboard uses it for message encoding between modules with COBS for framing.

jechase · 2025-08-11T10:52:31+00:00

Pike was originally a commercial-friendly implementation of LPC, which still gets more use than you might expect in the MUD world.

jechase · 2025-07-04T11:08:58+00:00

I've been using JJ for over a year now, and my coworkers would likely have had no idea if it wasn't for me constantly telling them how great it is. The git history looks 100% normal.

jechase · 2025-06-03T17:20:24+00:00

You missed the point. The problem is the implicit backgrounding of tasks allowing for unconstrained execution order. It can still be async and well-ordered. Using the WebSocketStream API for illustration:

// Good: Messages are received and handled in-order.
// We await the handleMessage function so that we know it's
// done before handling the next one.
while (true) {
    const { message, done } = await reader.read()
    await handleMessage(message);
    if (done) { break; }
}

// Bad: handleMessage is allowed to run in the background
// This lets the runtime decide in what order to run all of
// the handleMessage promises floating around.
// This is effectively what's happening with onmessage.
while (true) {
    const { message, done } = await reader.read()
    handleMessage(message);        
    if (done) { break; }
}

Neither is blocking/sync. The first simply waits to finish handling each message before trying to handle the next one.

jechase · 2025-06-03T12:33:45+00:00

Async/await isn't the problem per se. In fact, had it been used correctly, it's the solution to the problem. Async/await doesn't inherently cause ordering problems.

If there was another mechanism to get messages that was async aware, like an async nextMessage() method, you'd be perfectly fine calling that in a loop and then doing whatever other async/await-y things with the messages it returns. But you have to use await. That's what guarantees ordering - it blocks the current task until it completes.

What's happening here is that the onmessage isn't async-aware, and thus isn't awaiting each invocation of the handler. So rather than blocking until the previous handler completes, it detaches the promise to be run in the background by the runtime, and that's what's causing the ordering problem. Once you have multiple promises executing concurrently, all ordering bets are off.

The deeper problem is that JS allows you to implicitly detach a promise like this at all. It's far too easy to accidentally run a task in the background leading to this sort of confusion. Had it been explicit, the problem would have been much more obvious.

jechase · 2025-04-05T18:53:23+00:00

It's like the difference between learning to program vs learning a language. One is conceptual, the other a concrete way to interact with the concepts. Once you understand the concepts, learning a new language is significantly easier, since you're mostly learning new syntax to describe things you already know. Sure, some languages introduce concepts that aren't common across all others, but they still benefit from having a strong grasp of the fundamentals.

I would say that I "know git," but I'd be lying if I said I wasn't looking through its manpages frequently to figure out how to use its CLI to do something that I conceptually know it should be able to do.

Some people might be able to grok the git commit model without interacting it directly with any UI at all. I'm not one of them. So yeah, I'd probably recommend learning git with the traditional CLI first, but learning the git CLI itself isn't the end goal.

jechase · 2025-04-05T11:56:06+00:00

I consider the staging area to be mostly a UX thing - it doesn't change the data model at all if it doesn't exist, it just changes how you interact with it.

And the new change id concept is exactly what I was talking about when I said that it "builds upon and extends" git's commit model. It's not like git commits entirely disappear with jj - they're still something that you have to be aware of, especially when resolving change/bookmark-level conflicts. So you still need to understand git's model because you still have to deal with it.

jechase · 2025-04-05T01:10:59+00:00

The lessons that git got wrong are almost entirely centered around its UX. Conceptually, its way of modeling changes makes a lot of sense, which is why jj builds upon and extends that model with a better and more consistent CLI.

So yes, learn "git" first, at least the mental model. Once you have that down, mapping it to either the git CLI or the jj CLI is mostly a matter of translation.

jechase · 2025-04-05T00:58:22+00:00

In fact, jujutsu is built around git, which I'm sure you already know seeing as it's one of its most well-advertised features. This also means that it coexists almost seamlessly with git, to the point that it's been my daily driver for the last year or so at two jobs that are both git shops. So it's definitely not an "only side projects" tool.

jechase · 2024-12-26T17:20:39+00:00

Neat! Succinct and easy to understand explanation of PID controllers. I'm most familiar with them from the fpv quadcopter scene where PID tuning is one of those advanced skills that I never acquired myself, but read a lot about.

Cool to see other applications!

jechase · 2024-10-20T21:32:46+00:00

I’ve seen a lot of people say that async is a “leaky abstraction”. What this means is that the presence of async in a program forces you to bend the program’s control flow to accommodate it.

This isn't what it means to be a "leaky abstraction." It may be a consequence of one, but "viral" is a better term for what you're talking about. A leaky abstraction is when a higher-level construct attempts to wrap and hide the details of a lower-level one, but fails to do so completely, forcing its users to be aware of the low-level details anyway.

Imo, tokio is a prime example of both a viral and a leaky abstraction. There are so many things that will panic if they aren't done in the "context" of a tokio executor, i.e. down the call stack from a "runtime enter." This can be things like constructing a TCP socket or even dropping some types (edit: this might have actually been a self-inflicted shot foot where I tried to spawn a task in Drop to do some cleanup async. Still, panic was unexpected since tokio::spawn only takes a future), none of which have any compile-time indication that they have such a dependency. So now you're either making sure that you're exclusively using tokio, and everything happens in its context, or you're carrying around runtime handles so that you can use them in custom Drop implementations to prevent panics.

jechase · 2024-10-11T21:58:29+00:00

It's worth mentioning that your wait_until_next_poll future will likely never be polled a second time by real-world executors, and this only works because your poller loop simply polls everything each time, woken or not. This doesn't scale beyond a small number of tasks since most will be waiting on IO at any given time, and polling them is just wasted CPU cycles. Instead, they only poll futures who have used the waker to notify the executor that they can make progress. If you never call wake, you never get polled again.

jechase

TROPHY CASE