a rust+serde worker might be faster...

Right, forgot to mention that i'm using

lossless-json

to parse since I need to not lose accuracy when dealing with small numbers or really big ones. i.e. convert a big number to a string instead of losing accuracy.

ah 😅

rust+serde will definitely be faster then haha

Can you use rust on workers? Wouldn't you need to convert it to wasm which has a host of other issues?

you have to build to wasm, yes

🦀

Have you built workers with rust? Do you have an opinion on the state of affairs? i.e. is it production ready assuming simple use cases

Oh there is a separate channel!

It's plenty usable, but there'll be rough edges here or there

Lots of the Rust ecosystem has WASM support, I can't say I have run into any crates I wanted to use that didn't work or didn't have a viable alternative

Observability is so-so

hardest part is probably finding an off the shelf rust library to parse big numbers

dunno if you can plug that into serde

num-bigint

seems to have a

serde

feature

Last publish was Nov. 2021 so there might be a newer alternative, but this one could also just be feature complete

afaik serde has arbitrary precision as a builtin feature: https://github.com/serde-rs/json/blob/master/Cargo.toml#L78

our Workers last much longer than 30 seconds when streaming responses, but it seems like when immediately returning a response and trying to do a long running task in

waitUntil

they are getting killed after ~30 seconds. I didn't realize this would happen - is this expected and is there a workaround?

unfortunately this doesn't happen when running locally, so I didn't realize this limitation until testing in staging

it's a bug with waitUntil

it should be 30 seconds after the response has finished streaming but it's currently 30 seconds after the response headers are sent

ahh shoot

neither will work for our use case because this particular response we are not streaming, just immediately returning a 200 and kicking off a long running task

😦

Sounds like Queues might be a better option?

yeah that is was what I was looking at, will probably switch to it

I've gotten bitten by these small inconsistencies several times now, a couple times they even made it to production 😦 for example if you don't

await

a DO request in a Worker before returning a response locally then it still goes through. but when pushed live the request doesn't go through

> To send and receive messages, you must use a Worker. @kian can I send to queue from DO directly?

I read on this forum that workers-ai is no longer a thing. But am wondering, now with WebGPU support in the browser enabled, is there work being done on supporting that in Cloudflare workers (given its also v8 based) ? Hopefully someone can shine a light on this. If its not coming anytime soon I need to figure out an alternate solution.