Native Rust Support on Cloudflare Workers | Hacker News Reader

Native Rust Support on Cloudflare Workers

blog.cloudflare.com

248 pointselithrar45 comments

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).

[0] https://github.com/PSeitz/wana_kana_rust/tree/master/bench_c...

Had the same thought, performance is quite key for most uses I think. Still compiles to web assembly probably because they mention running it in V8.

Looks like it's WASM:

> 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.

What does "natively" mean in this context? Because my impression is "the Cloudflare Workers environment" defines WASM as its "native" architecture.

That's exactly why I ask :)

It seems like this is still WASM. I wonder if this is "Node with Rust bindings" as my EDIT comment alludes too.

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.

See https://developers.cloudflare.com/workers/learning/how-worke...

Edit: "Native" does seem misleading in the title. "Streamlined Rust Support on Cloudflare Workers" would have been more straightforward.

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.

https://github.com/jamsocket/jamsocket

Jamsocket looks really cool! Will take a closer look.

Perhaps a good time to mention that there is a quite active discord channel on cloudflare workers here: https://discord.gg/5aTJwnMZ

A sample app app of cloudflare workers ( a status page with pings in multiple regions): https://github.com/eidam/cf-workers-status-page

And the framework on top of cloudflare workers, inspired on next.js : https://flareact.com/

also a good time to mention that if you build something in in rust using workers, you should submit it to win some free swag:

https://challenge.developers.cloudflare.com/

https://discord.gg/5aTJwnMZ has expired

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.

This looks neat, but I've never had a good use-case for cloudflare workers. Are any of you doing fun things with workers?

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.

Is that loose cache based on the KV propagation delay?

I would imagine so, yeah. Hard to say definitively.

Same except I go POST and version the assets. It's a super fun and awesome way to manage sites IMO.

The idea is what Worker Sites [1] do via KV Asset Handler [2].

Would love to see your code for signed Payload / auth. Or, just hear how you do it. My auth is a bit... weak.

Cheers.

[1] https://developers.cloudflare.com/workers/platform/sites

[2] https://github.com/cloudflare/kv-asset-handler

Built with Workers: https://workers.cloudflare.com/built-with

Don't forget the multiplayer Doom ported to run on Durable Objects + WASM [1]!

[1] https://blog.cloudflare.com/doom-multiplayer-workers/

Or even https://nataornot.com/

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.

Built major parts of our adtech platform on it before, will build the next one completely with Workers.

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'd love a blog post about how you did it!

There's a little bit at the bottom of this[0] blog post, expanding it a little as we speak though!

[0]: https://dev.to/joe8bit/shipping-web-components-in-2020-2h54

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.

>hyper programmable middleware to stitch together multiple vendor solutions

well if that doesn't stir excitement I don't know what does!

I've made a website builder based on KV and Workers, and it has been quite brilliant - especially because of the global geo.

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).

How do you handle this scenario?

Link?

I made a websocket game server with cloudflare workers and durable objects.

I just mentioned it above and then saw your comment, but here is an example cf app:

https://github.com/eidam/cf-workers-status-page

A status page pinging from multiple regions.

I've thought it would be fun to try and implement something like patchbay[0] on workers.

[0]: https://patchbay.pub/

https://crates.live runs on Cloudflare workers (and yep, using Rust)

Very cool! I will definitely use this.

Very excited to see what people build with this!

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.

Would love to see a benchmark on this vs JS, as both would still run through V8?

How does this compare to Fastly's Lucet-based solution?

Can you run Erlang on a Cloudflare Worker?

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.

Reply on news.ycombinator.com