So is this still converting the Rust code to Web Assembly (just doing it in a more developer friendly way)?
Or is this allowing actual Rust code to run natively on the Cloudflare Workers environment?
I ask because there is a significant difference in performance between native Rust and Web ASM.
EDIT: I found this benchmark [0]. It appears you can run Rust 3 different ways. 1. Natively (fastest), 2. Node with Rust Bindings (2x slower than native), or 3. wasm (8x slower than native).
I wonder if this announcement is Cloudflare supporting the #2 configuration above (Node with Rust Bindings).
Cloudflare Workers run in V8 isolates, so it would have to be WASM. It would be difficult to do something else and keep the current pricing model (including the free tier), since the overhead per Worker is pretty low with this approach.
> Introducing the worker crate, available on GitHub and crates.io, which makes Rust developers feel right at home on the Workers platform by running code inside the V8 WebAssembly engine.
I think it's WASM, but the title says it's native. Maybe the word "native" has various meanings here. When I first read the title I was under the impression that it wasn't WASM.
I'm excited to try this. I made an attempt at writing a Rust Durable Object a while back and it was cumbersome at the time, so this looks great.
If there's anyone from CloudFlare here, I have a question: does this support WebSockets? At first glance over the docs I don't see an equivalent to WebSocketPair from the JS interface.
Author here! No websocket support yet, but it’s definitely on the roadmap. If you have ideas or suggestions for a nice Rust interface for it please share on the GitHub repo. Would appreciate it!
I've actually been giving this some thought as I've been working on a WebSocket server that hosts a WebAssembly module[1]. So far my approach has been to expose a function on the guest that is called when a message is received, and a function on the host that is called when the guest wants to send a message. It's simple, but it works. It would be pretty cool to have a simple interface like that, but with the power of durable objects as well.
Oh, first time I heard about Cloudflare Workers. Must have been living under a rock. This looks very interesting in many regards.
I'm in the camp "use Rust if you need it". Supporting Rust natively here makes a lot of sense for compute heavy applicatons. There's still some 30 ms latency, so some single digit microseconds don't really matter, but getting in the region of saving 2 digit microseconds in compute, the performance benefits of Rust start paying off (of course depending on the number of requests). So, I guess this is a great examples for choosing Rust.
The combo Cloudflare Workers and Rust is probably the fastest you can get for worldwide delivery of dynamic content. Really interesting stuff.
Quotes from the Cloudflare Q2 earnings call transcript:
We see more and more customers building applications around Cloudflare workers our compute platform. A high-profile new economy delivery company signed a $1.3 million three-year deal. They use a number of our products, but increasingly are building their application using Workers in order to get fast scalable performance. They appreciate the flexibility it provides, as they literally deliver for their geographically distributed customer base.
A financial services software provider signed a three-year $3.3 million deal for a number of our products. They're using Workers as a hyper programmable middleware to stitch together multiple vendor solutions. They love how easy it is for developers on their team to get up and running on the platform, because of the broad programming language support and rich developer tools that have been honed and battle tested in production since Workers launched nearly four years ago.
An Asian fintech provider expanded their use of Cloudflare by $0.5 million, making their annual spend now $1.3 million. They are using Workers to accelerate their development cycle and replace spend with some of the traditional hyperscale compute providers.
So, more than 50,000 developers wrote their first Workers script or code this time [this quarter]. And that's not signed up for an account. That's actually wrote code and deployed an application.
We're increasingly seeing startups that are building entire applications from scratch on the Workers platform.
I host static content with them (with no fallback server) using their keyval stores.
All GETs result in a KV lookup. A PUT uses a signed payload and a set of public keys in another KV store to check that the caller is allowed to store the new page contents.
I can re-deploy a site in a matter of milliseconds and it is only loosely cached (updates are reflected within a minute or so), free for up to 100k requests a month, and serves content in a matter of milliseconds.
I've used them for serving development or debug builds of JS SDKS (e.g. you set a DEBUG=TRUE cookie in the request in production, serve bundle A if not serve bundle B). Made the lives of our Solutions Engineers a LOT easier.
Being able to do this in the CDN infra was pretty powerful.
I have a somewhat unusual use case that Workers are perfect for: I want to collect analytics on a SaaS service that is a CNAME under my domain, but that I do not control.
Did you ever run into a scenario where you had to replace a single file specifically?
I have found that to be quite tricky. There is some data for a site I'd like to be able to update dynamically, without redeploying the whole site (as that may contain draft pages / content).
Random comment, but hoping someone may have an answer for me:
Has anyone here managed to deploy multiple workers sites as part of one worker?
Using KV storage, it should technically be possible to have one worker addressing multiple domains, so then, if you wanted to deploy multiple websites using one worker to serve static assets to multiple domains, could that be doable?
I am only mentioning this, as it still doesn't seem possible to just buy additional workers. You are still limited to 30 sites on workers sites. Which seems quite prohibitive, if you wanted to build a bunch of sites for clients for example.
You can bind one worker to multiple routes to accomplish this. It would probably require some custom routing to check the host not just the path if you want different content.
They run anything that can target WebAssembly (so Erlang would be waiting on Lumen).
This announcement is more that the is now a idiomatic Rust API; you could already run Rust workers fine.
Or is this allowing actual Rust code to run natively on the Cloudflare Workers environment?
I ask because there is a significant difference in performance between native Rust and Web ASM.
EDIT: I found this benchmark [0]. It appears you can run Rust 3 different ways. 1. Natively (fastest), 2. Node with Rust Bindings (2x slower than native), or 3. wasm (8x slower than native).
I wonder if this announcement is Cloudflare supporting the #2 configuration above (Node with Rust Bindings).
[0] https://github.com/PSeitz/wana_kana_rust/tree/master/bench_c...