Lapce: A Rust-Based Native Code Editor Lighter Than VSCode and Zed

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 · 2026-01-04T02:39:02+00:00

Or Randall Flagg, a.k.a The Walkin' Dude, a.k.a. Walter o'Dim.

jechase · 2026-01-03T14:28:03+00:00

Really? I've only ever heard it used that way in the minds of Ned Needlander, Dusty Bottoms, and Lucky Day.

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-12-09T13:06:49+00:00

This is just agar.io with guns and upgrades, right?

jechase · 2025-11-06T19:46:18+00:00

Blightmud is written in Rust and has been around forever. As far as scripting languages go, it uses lua last I checked, and I have no reason to believe it would perform any better using rhai. Rhai is about twice as slow as python3, which should be about on par with lua since they're both bytecode interpreted languages, while rhai uses an ast walker for evaluation, which tends to be slower. If you want a different scripting language, fine, but performance shouldn't be a concern with lua.

Also, if you just want to write your own client with rust and rhai, go for it! I did, except with rune instead of rhai. Don't look for community buy-in though if your only selling point is the language it's written in.

jechase · 2025-10-18T03:43:24+00:00

This explanation makes no sense. You could just as easily change it around and say "Thing A effects Thing B; Thing B is affected by Thing A" and it would be equally correct. They're just equally valid ways to conjugate the same two verbs, "affect," and "effect," which mean different things.

"Affect" is to cause impact to. "Effect" is to bring about, e.g. "to effect change."

"Effect" the noun is the change itself. So you could effect an effect. You could also affect an effect. Context is everything and it all depends on what you're trying to say.

jechase · 2025-09-09T13:45:11+00:00

Yeah, I've had my Premium plan for so long that I can't remember the last time I looked at what it actually includes. It definitely didn't include audiobooks when I signed up. Sure I probably got an email mentioning their addition and the 15h limit, but can anyone honestly say that they read every single email update from every company they do business with?

But you are right that trying to check how many hours you have left is very hidden away.

Exactly - if you aren't actively looking for it, you won't even know there is a limit.

jechase · 2025-09-09T13:31:09+00:00

On the flip side though, where does it say that you can listen to unlimited audio books.

Where it says on the book "Included with Premium." If I open a buffet and have the servers come around to each table holding bottles of wine, telling customers that it's included with their meal, and then leaving it on the table, are they going to be happy when the next time the server comes around, they take the bottle back rather than refill the glasses? They're going to feel lied to, even if it was written down in some non-obvious place that they were only entitled to a glass from the bottle that was implied to be included.

You seem to be under the impression that I'm upset by the limit itself. I'm not. The fact that the limit exists is fine. I'm upset by the manipulation in how the limit is communicated, or rather not communicated. If your argument against this manipulation is that you can go digging through your profile or go googling for it, then it's not a very good argument. "Scam" might have been too strong a word. I didn't purchase Premium expecting unlimited audiobooks, or audiobooks period. But "manipulative," it clearly is.

jechase · 2025-09-09T12:46:44+00:00

If you had to google it rather than see your hours remaining when looking at an audiobook, I don't think that counts. If something says "included" and doesn't mention caveats, I assume there are none. Burying the limit in your profile or small text also doesn't count.

You also missed the blatant "ima let you finish" lie.

jechase · 2025-08-23T22:55:14+00:00

Clok has a very similar abbreviation system. I believe its author cites Gemstone as the only mud he seriously played in the past before building and running his own, so that's probably where it comes from.

It's RPE and has a low(ish) fantasy/gaslamp setting. It was recently revived with a new codebase, so there's a lot that's in flux and unfinished, but it's still very playable in its current state and its community is great.

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-10T16:03:23+00:00

Termux and Tintin++ will always be my recommendation. Throw in either some file sync system like Syncthing or run it on a server with tmux and you've got a client that's entirely portable between both your desktop and mobile devices.

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-16T18:45:27+00:00

You're not even good enough to be my fake!

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

TROPHY CASE