Head in the Zed Cloud
35 points by maxdeviant
35 points by maxdeviant
Just FYI for that job posting, since it’s open to workers in Colorado (hi, I’m also in Boulder), by law you need to list the salary range: https://cdle.colorado.gov/dlss/labor-laws-by-topic/equal-pay-for-equal-work-act
Similarly for New York since they hire remotely: https://dol.ny.gov/pay-transparency#:~:text=Pay%20Transparency-,Overview,@labor.ny.gov.
I saw this uses Cloudflare Workers and Rust.
I was considering Cloudflare Workers for a random project and tried out their Rust hello-world example. It didn't compile. The issue was a simple mistake; I went so far as to find the PR that broke it.
What do I take away from this? Genuinely not sure. Could be nothing, and I just got unlucky when I tried it. Could be worrying that this wasn't tested, and indicative of the maturity of the project. The latter was definitely what I was trying to feel out.
After writing the above paragraph I checked back on the project. It looks like they added CI coverage of this when fixing my issue. I could've seen that going either way, and I guess concludes things on a positive note.
In my experience, I would say that using Rust with Cloudflare Workers is still a bit nascent. I don't think it's as well-trod as using JS/TS to write Workers.
That being said, our original foray into using Cloudflare Workers with Rust was using the workers crate and it worked fairly well. One big downside was that since everything was tied to JS/Wasm we needed to write our tests in TypeScript using Vitest, and some of our tests were quite brittle as we didn't have enough control over simulating things inside of Miniflare.
We ultimately went with the approach I described in the post, where we wrote our own framework and run all of our tests using native Rust code. We still have some tests that do target Miniflare and ensure that our platform bindings are working as expected when running under Wasm, but all of our business logic tests are going against our SimulatedPlatform.
My ultimate impression from (very superficial!) poking at it was also that they managed to fit Rust+Wasm into a JS-based system, but I left it out above because it was just an impression. So I guess I'm trying to say "that is what it seems like to me too". It makes path dependent sense given the history of workers, but before I looked at it I had kinda been imagining it would instead have been more like Wasm speaking directly to a hosting interface. I guess ultimately as a user it doesn't matter how it works, except for exactly your testing experience is the sort of place where it shows.
At least for my (trivial) webapp I concluded I might as well just write it in TS if I was gonna use workers. I get for your system Rust makes sense though!
I had a similar issue last year when using Astro + React 19 on workers (the project couldn't deploy without an obscure workaround), and my colleagues had an even worse experience going as far as to deploy a site with OpenNext only for them to find request times skyrocketing & reverted to classic containers on GCP (I think the issue was reported somewhere). Workers is a nice platform when going down the treaded happy paths, but exotic setups still need some ironing out.
My experience with JS and Cloudflare Workers was pretty good compared to the other "serverless" platforms. Especially the local dev story was miles ahead and the focus on web APIs was nice. Were there any other considerations instead of Workers, e.g. shuttle.dev?
I am quite curious about the WASM and Zed story, extensions use WASM as well, and I didn't find the experience as pleasant as writing a plugin in other editors. But it's still quite exciting to see people venture into this!
Especially the local dev story was miles ahead and the focus on web APIs was nice.
I haven't tried too many other serverless platforms, but the tooling around Cloudflare Workers does seem to be second to none.
Were there any other considerations instead of Workers, e.g. shuttle.dev?
We didn't look too hard at other platforms. Partially because some of components of Cloudflare's offering—namely Durable Objects—seemed like a very powerful primitive to be able to build upon.
I am quite curious about the WASM and Zed story, extensions use WASM as well, and I didn't find the experience as pleasant as writing a plugin in other editors.
Curious to hear what sorts of things you didn't find as pleasant?
I would attribute more of the potential friction in writing a Zed extension to how new/limited the extension API is moreso than it being in Wasm. It is true that currently Zed extensions basically need to be written in Rust—due to the investments made in Rust's Wasm story/tooling—but we don't want that to be the case forever. We'd love to be able to have extensions written in other languages while still targeting Wasm.
Partially because some of components of Cloudflare's offering—namely Durable Objects—seemed like a very powerful primitive to be able to build upon.
We built an open-source alternative to Durable Objects over at Rivet. It includes experimental native Rust support since we're not tied to a boutique runtime.
Big fan of what y'all are doing over at Zed.
Whoa, Rivet looks cool!
As much as I like Cloudflare, it is nice to see that they're not the only game in town for this sort of thing :)
We didn't look too hard at other platforms. Partially because some of components of Cloudflare's offering—namely Durable Objects—seemed like a very powerful primitive to be able to build upon.
Ah I see, I am quite a fan of those durable workflow type of tools, they are indeed powerful!
Curious to hear what sorts of things you didn't find as pleasant?
I also attributed the experience to the extension API being new( 0.0.1 , so I was fully aware of what I was getting into :P ), the flow has been improved though with dev plugins being easier to install and reload.
What I found a bit cumbersome was that I was writing Rust for the language server and then small bits of TOML config across two files(extension.toml and then languages/{lang}/config.toml). Paired with the slow loop of compiling the WASM file made for an experience that felt slower compared to the same type of thing I did in helix or emacs.
I also wanted to add a MCP command to the plugin, but I couldn't figure out how to the equivalent of worktree.which("binary to find in PATH") like with the language server config part, and only saw examples that pulled in a npm package.
Ah I see, I am quite a fan of those durable workflow type of tools, they are indeed powerful!
Friendly correction – this is not quite right, the "durable" in "Durable Objects" is misleading.
Durable Objects are an implementation of virtual actors. TLDR: actors with persistence & hibernation. The "durable" is meant to imply it's a "JavaScript object that lives forever."
It can be used to build durable workflows – I'm fairly certain it powers Cloudflare's own Workflows product. However, that's a tiny subset of what they are.
Ah thank you! I confused some terms there. And always nice to see Orleans referenced, I tried experimenting with it and F# a few years ago :P.
P.S. Rivet looks nice!
This Platform trait: isn’t it a pain to maintain? And to jump through it for every go to definition?
And are the test/simulation impl good enough? Don’t you end up implementing every feature CF workers have, only to find issues in prod when they don’t match 1:1?
(Not judging in any way just super curious - this was very surprising to see)
This Platform trait: isn’t it a pain to maintain? And to jump through it for every go to definition?
I don't think it's been painful, so far. I think most of the time when building something on top of the Platform, you generally don't need to go digging into the details. And if you do, you can "Go to Definition" to get to the trait method and then "Go to Implementation" to pull up the implementers of the trait method.
And are the test/simulation impl good enough? Don’t you end up implementing every feature CF workers have, only to find issues in prod when they don’t match 1:1?
Diverging from what's happening in production is a definite risk that we run when using the simulator.
However, for many things an approximation of reality is enough to test most of the business logic. For example, a Workers KV store can be approximated using a regular HashMap.
We do have ways of injecting failures into parts of the simulator that leverages our deterministic async runtime.
And then we do have a suite of tests for the platform itself that run in a Wasm environment and test that our CloudflarePlatform implementation matches our expectations.
I think it would be interesting to be able to run our test suite against both the SimulatedPlatform and the CloudflarePlatform, but I think that constantly testing against the CloudflarePlatform (e.g., in CI) would be too brittle, as we don't have the same level of control over what happens in the Miniflare environment.
It's funny to hear how we're now racing to build the same stuff but with the Zed team working with data and plugins in Rust/WASM where I'm doing it all in JS.
Also from what I've heard Zed just wants to build all its new stuff on top of git but I want to replace git.
It'll be interesting to see if our work converges at some point!