Cole

Cole

@cole-miller.net

I work on the Zed code editor and post about classical music

50 followers55 following65 posts

Cole reposted

Replying to @hillelwayne.com

10/ You can solve an enormous number of technical problems by taking a walk

Cole reposted

We heard you loud and clear, so we went ahead and built the git graph.

It’s really cool to work at a company that can do this kind of thing in-house!

Zed@zed.dev

Zeta2 is here. 30% better acceptance rate than Zeta1. 200x more training data, LSP-powered context, faster predictions, open weights. Try it now in Zed. We didn't just improve the model. We rebuilt the entire data pipeline behind it: zed.dev/blog/zeta2

Cole reposted

🚀 We just shipped v0.216.0! Word-level diffing just landed. 🎉 It's been a night-and-day difference for us—seeing exactly what changed within each line.

math puzzle I want to work out when I have the chance: there are an infinite number of bugs (B_n) with some probability distribution (p_n). we draw an infinite i.i.d. sequence from this distribution, and then walk through it fixing bugs in the order we see them.

what is the probability that at the ith step we see a bug that was already fixed in a previous step? (for realism we could have the p_n obey a power law)

Cole reposted

It's finally here. Zed is available on Windows. Built from scratch, and rendering at 1 million pixels/millisecond. Download it today 👇

Update your Zed!

Zed@zed.dev

Uhoh, we broke Zed's auto-updater. 🫣 If you're on v0.203.x or v0.204.x, you'll need to manually check for updates via the Command Palette→ "auto update: check" We've already shipped the fix - just need you to unbox the latest, shiniest version of Zed manually this time.

Cole reposted

The Zed codebase generally passes around a type-erased `Task` struct instead of using `async fn` (and in place of `Pin<Box<dyn Future>>`). It took me a little while to get used to this but I'm starting to appreciate its advantages; one is that you can write layered signatures that express...

..."this function does some synchronous work, and then uses its outputs to launch an asynchronous task"; that might look like fn foo(x: Input) -> Result<Task<Option<Output>>> and then you can handle the sync error synchronously in the caller, before awaiting or storing the task.

With `async fn` you can't express "where the async happens" in one signature this way--I think you'd have to split out a sync function. Another benefit: we have separate main-thread and background-pool executors, and to construct a `Task` you have to declare in that scope which one you want to use.

Apparently the president of basketball operations for the Sixers commissioned a musical about basketball that's playing right now in Philly. Feels very 18th-century