Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reality Check for Cloudflare Wasm Workers and Rust

nickb.dev

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Reality Check for Cloudflare Wasm Workers and Rust

#31

Post by azakai »

brundolf wrote: post #19
merb wrote: post #17

Earlier quoted context omitted.

I'm not sure but if you need any string manipulation at all it will be really hard to not use the rust std?

I think their point is that what's referred to as "tree-shaking" in the JS world is (I'm pretty sure) normal and standard for most statically-compiled languages like Rust. So you won't bring in anything you don't need, though you will still be bringing in lots of stuff you do need

Generally true, but just to add to that, in languages like Rust and C++ you often end up including stuff you don't need due to toolchain limitations. For example, indirect calls (from Rust traits or C++ virtual methods) are hard to get rid of in general.

This is a pretty significant cause of bloat in practice, sadly, but toolchain improvements may help in the future. So for now, JS's advantage of the standard library being in the VM is pretty significant.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#32

Post by ignoramous »

kentonv wrote: post #27
dgreensp wrote: post #4

I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud prov…

> We very much believe Workers can be a stand-alone alternative to other cloud providers.

Time for Durable Workers: Run one Worker (per Durable Object instance) with higher RAM and wall-time ceiling, capable of serving WebSockets and WebRTC data-channels (and gRPC, if we are being ambitious)?

> The "memory limit" on a single worker instance is 128MB, but Cloudflare runs many instances of the worker around the world, so across the network you're really getting many gigabytes of memory.

Throw-in the zonal Cloudflare cache (which is free upto 500MB per cached-object) and some clever workarounds, a lot could be done. May be Cloudflare dev-rel could to add it in a "Workers SDK" of sorts to make this easier, or the eng team can work towards seamlessly exposing it to Workers instances as swap space? :D

Re: Reality Check for Cloudflare Wasm Workers and Rust

#33

Post by kentonv »

azakai wrote: post #30
kentonv wrote: post #27

Earlier quoted context omitted.

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud prov…

Small note on this: > What this article is highlighting is that Wasm is still an immature technology. I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the Web platform. Otherwise very good points!

I don't, actually. Wasm is immature in the browser, too, for the same reasons. Writing a client-side web app entirely in Wasm generally doesn't work well today because you'll force the client to download much more code before the page can run. Lots of work is being done to improve this, like adding built-in garbage collection to the Wasm runtime so that apps written in GC'd languages don't need to ship their own. Dynamic linking will help too, assuming that language runtimes are allowed to be cached across different sites.

In both environments there are certainly use cases where Wasm provides huge advantages. But those use cases are still narrow. Over time it'll grow but there's still tons of work to do.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#34

Post by stavros »

jfrunyon wrote: post #14

I believe a zip file could be streamed - most of the file metadata is duplicated between both the 'central directory record' trailer and a header in front of each file. In other words, the first thing in the zip file is a header that you can use to extract the first file, followed by that file, followed by the next file's header...

You can, yes. You can even download the header, open the zip file, choose which files to extract, and only download those. This is possible with HTTP today, and has been for decades.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#35

Post by azakai »

kentonv wrote: post #33
azakai wrote: post #30

Earlier quoted context omitted.

Small note on this: > What this article is highlighting is that Wasm is still an immature technology. I assume you meant on the server, where wasm is fairly new, that's true. On the browser, wasm is a mature and stable part of the Web platform. Otherwise very good points!

I don't, actually. Wasm is immature in the browser, too, for the same reasons. Writing a client-side web app entirely in Wasm generally doesn't work well today because you'll force the client to download much more code before the page can run. Lots of work is being done to improve this, like adding built-in garbage collection to the Wasm runtime so that apps written in GC'd languages don't need to ship their own. Dyn…

Ah, I think we disagree on the goals of wasm.

Yes, if you want to write a client-side webapp you run into limitations. That wasn't one of our main goals when we created wasm, though! It would be great if that materializes - more options are always good - but JavaScript is frankly the right tool for 99% of sites and we never intended wasm to directly compete with JS there.

Wasm is stable and mature for solving the needs of sites like Google Earth, Unity games, Figma, Meet, Zoom, etc. Those require more than what JS can offer and wasm is the perfect fit for the relevant parts of them.

On those websites wasm is often the difference between shipping and not shipping. That's a huge deal, and why wasm has been focused there. Other use cases like replacing JS with wasm might offer some benefits in speed, perhaps, but the impact of that would be smaller (but it could eventually apply to a wider set of sites, potentially).

Re: Reality Check for Cloudflare Wasm Workers and Rust

#36

Post by kentonv »

azakai wrote: post #35
kentonv wrote: post #33

Earlier quoted context omitted.

I don't, actually. Wasm is immature in the browser, too, for the same reasons. Writing a client-side web app entirely in Wasm generally doesn't work well today because you'll force the client to download much more code before the page can run. Lots of work is being done to improve this, like adding built-in garbage collection to the Wasm runtime so that apps written in GC'd languages don't need to ship their own. Dyn…

Ah, I think we disagree on the goals of wasm. Yes, if you want to write a client-side webapp you run into limitations. That wasn't one of our main goals when we created wasm, though! It would be great if that materializes - more options are always good - but JavaScript is frankly the right tool for 99% of sites and we never intended wasm to directly compete with JS there. Wasm is stable and mature for solving the nee…

Right. Same for server. You can do most of what you want to do in JavaScript and it'll be fine. Use Wasm to fill in the gaps where JavaScript doesn't work. That's a good strategy today with Cloudflare Workers, too.

It's when people want to write entire apps entirely in their language of choice, and want to accomplish this using Wasm, that the technology is still missing things. A lot of people want to do this, both on the browser side and the server side.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#37

Post by nostrebored »

kentonv wrote: post #25
up6w6 wrote: post #9

iirc the compilation time of wasm in Cloudflare Workers is very problematic[1] and right now it contradicts their idea of running low latency fast scripts, does anyone know if anything has changed ? https://community.cloudflare.com/t/fixed-cloudflare-workers-...

Yes, it has changed, which is why the thread you linked has "[FIXED]" in the title. Details can be found later on in the thread.

Your replies throughout the thread have been pretty hostile. You're much closer to this than anyone here. Empathy to that goes a long way.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#38

Post by eloff »

nostrebored wrote: post #37
kentonv wrote: post #25

Earlier quoted context omitted.

Yes, it has changed, which is why the thread you linked has "[FIXED]" in the title. Details can be found later on in the thread.

Your replies throughout the thread have been pretty hostile. You're much closer to this than anyone here. Empathy to that goes a long way.

I think you're assuming tone that isn't there. Look at it again, it's a factual statement. Nothing angry or accusational. As you say, a little empathy goes a long way. Try to interpret tone on the internet in a charitable manner, because you're just guessing at it most of the time.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#39

Post by Gepsens »

kentonv wrote: post #27
dgreensp wrote: post #4

I think the one-sentence version of this is that Workers are meant for small, undemanding tasks (for example, they have tight memory limits and don’t have great performance), so using them to do “serious number crunching” at the edge, which is the advertised use case, seems questionable. I think the blurb about the downsides of Wasm is just too generic, it’s a sort of “why Wasm isn’t preferable to JS in all cases” fo…

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud prov…

I have a a server engine that runs a lot of small (and potentially unique) tasks (say 0.2% of 1vCPU and 30Mb of RAM), but require durable disk (rocksdb, sqlite for instance + some random files) and I want to locate them in specific regions depending on the server they are targeting. Would Cloudflare workers be good enough for that or shall I stick to DO's cheap vms ?

Re: Reality Check for Cloudflare Wasm Workers and Rust

#40

Post by kodablah »

Gepsens wrote: post #39
kentonv wrote: post #27

Earlier quoted context omitted.

> I think the one-sentence version of this is that Workers are meant for small, undemanding tasks Not at all! We're building a platform on which you can build your entire app. What you say may have been the case four years ago when Workers launched, but since then we've added Durable Objects, Cron triggers, much longer time limits, etc. We very much believe Workers can be a stand-alone alternative to other cloud prov…

I have a a server engine that runs a lot of small (and potentially unique) tasks (say 0.2% of 1vCPU and 30Mb of RAM), but require durable disk (rocksdb, sqlite for instance + some random files) and I want to locate them in specific regions depending on the server they are targeting. Would Cloudflare workers be good enough for that or shall I stick to DO's cheap vms ?

Native edge computing (i.e. containers or VMs at the edge) are probably more suitable than workers for such a task. Granted workers do have persistence options (e.g. KV store) but you'll have to target your existing app towards them.

Disclaimer: I work at StackPath which offers containers and VMs at the edge with anycast IPs which is perfect for this use case.

Post reply on HN