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

51–59 of 59 posts

Re: Reality Check for Cloudflare Wasm Workers and Rust

#51

Post by nyanpasu64 »

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 don't see how your response addresses the article's issues where workers don't have enough memory, space, or runtime to perform number crunching, meaning that for people with those use cases it's not a full "alternative to other cloud providers".

Re: Reality Check for Cloudflare Wasm Workers and Rust

#52

Post by mwcampbell »

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…

Still, as you wrote earlier this year [1], there are valid use cases for something chunkier than isolates (and yes, I know that lifting and shifting existing web apps isn't one of them). I'm looking forward to your edge containers becoming more widely available.

[1]: https://blog.cloudflare.com/containers-on-the-edge/

Re: Reality Check for Cloudflare Wasm Workers and Rust

#53

Post by kentonv »

csomar wrote: post #50
kentonv wrote: post #28

Earlier quoted context omitted.

> Cloudflare workers don't run in the background. They block the HTTP request. For serious computation, Cloudflare should offer background workers that can run for extended periods of time. You can use `event.waitUntil()` to schedule a task that runs after the HTTP response has completed, and you can use cron triggers to schedule background work in the absence of any HTTP request at all. You can even build a reliable…

Thanks. I didn't know about waitUntil, that can unlock some powers. > we're working on improving that. I'd assume you are working for Cloudflare. Do you see it going the way of firebase?

I'm the tech lead for Cloudflare Workers. :)

I don't know much about Firebase, to be honest, so I'm not sure how to answer that question. But, our aim is that every type of server compute should be something you can build on Workers. Meanwhile, our design philosophy is that Workers should feel like you're programming one big, globe-spanning computer, rather than lots of individual servers.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#54

Post by chubot »

pjmlp wrote: post #48
chubot wrote: post #47

Earlier quoted context omitted.

I agree that's a common desire, but how likely is it that actually becomes feasible? I think programmers underestimate the degree to which languages and VMs are coupled. Adding GC to WASM makes it essentially like the JVM because it has to know about the layout of every type (to find pointers, etc.) As far as I can see, this effort is like bolting a VM that's 2x-5x as big (in terms of semantics) on top of the existin…

Some corrections in regards to CLR. The language that fully exposes its capabilities is C++/CLI and not C#. In fact, most of the performance improvements since C# 7, have been how to surface those C++ capabilities into C#, while keeping the generated MSIL verifiable. C++/CLI is also able to generate unsafe MSIL sequences. This is specially relevant since C++/CLI is Windows only, so one cannot just switch to it in cro…

Hm very interesting! So what it sounds like is that CLR started out like a JVM-like VM, but now they're adding a WASM-like VM to it :)

That is, WASM is a much more natural target for C++/Rust than anything higher level. It can also express unsafe code when you consider the issues brought up in the paper, i.e. that it's unaware of heap integrity. Conversely, the JVM/CLR was traditionally better for Java/C# like languages and you couldn't run C/C++ naturally.

This makes sense as I've heard some of the more recent C# features are to recover performance, like value types, slicing, etc.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#55

Post by kentonv »

nostrebored wrote: post #49
eloff wrote: post #38

Earlier quoted context omitted.

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.

I work in customer facing roles. Responses like that are considered hostile. If I responded like that in a professional capacity -- like the parent comment -- I'd have a lot of questions to answer. And from the reply, the response wasn't even correct. Bad form.

You're right, I should have been more careful when writing that comment. I was trying to express that the original issue was fixed (and the "new issue" isn't actually an issue as far as we can tell), I didn't mean for it to come out hostile but I definitely see how it looks that way. I could have done better.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#56

Post by wibagusto »

azakai wrote: post #15
wibagusto wrote: post #11

Correct me if I’m wrong but the memory copying issue is not an issue if you pass an array buffer into WASM from JavaScript. In that scenario there’s no data copying. E.g. similar to how you’d pass the canvas data to WASM for direct manipulation.

No, this is an issue currently, both for network data and canvas data. All wasm instructions can do is read and write from the wasm Memory that the wasm is initialized with. They can't even refer to separate things like a new ArrayBuffer from JS. So you do need to copy. Newer wasm additions like reference types allow an ArrayBuffer to be referred to inside wasm, but only as an opaque reference to the entire thing (an…

So the workaround is to initialize WASM with an array buffer which allows direct manipulation of the data in WASM it seems. The canvas bytes can be used in WASM so long as the bytes are passed in at initialization.

In that case, JavaScripts only duty is to pack input data into the byte array and pass control to WASM which writes to an output buffer (also shared byte array) and passes control back to JavaScript to process result avoiding an unnecessary data copy.

You’d have to have some types in JS which can process the data using bit shifts and whatnot though in a lower level way.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#57

Post by pjmlp »

chubot wrote: post #54
pjmlp wrote: post #48

Earlier quoted context omitted.

Some corrections in regards to CLR. The language that fully exposes its capabilities is C++/CLI and not C#. In fact, most of the performance improvements since C# 7, have been how to surface those C++ capabilities into C#, while keeping the generated MSIL verifiable. C++/CLI is also able to generate unsafe MSIL sequences. This is specially relevant since C++/CLI is Windows only, so one cannot just switch to it in cro…

Hm very interesting! So what it sounds like is that CLR started out like a JVM-like VM, but now they're adding a WASM-like VM to it :) That is, WASM is a much more natural target for C++/Rust than anything higher level. It can also express unsafe code when you consider the issues brought up in the paper, i.e. that it's unaware of heap integrity. Conversely, the JVM/CLR was traditionally better for Java/C# like langua…

You got it wrong, CLR supports C++ since version 1.0, released in 2002, including the concept of safe and unsafe code.

It is WebAssembly that tends to be "sold" as if it was the first of its kind.

In fact even the CLR wasn't the first one, there were other bytecode formats for languages, like EM from Amsterdam Compiler Toolkit, IBM and Unisys mainframes/micros.

And around 2003, there was a Swedish startup trying to push a mobile OS that used a VM capable of J2ME, C and C++, the name I cannot longer remember, just some Sony-Ericson models used to have it.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#58

Post by wtetzner »

Yoric wrote: post #20
wtetzner wrote: post #6

Earlier quoted context omitted.

There's also js_of_ocaml if a good type system is desired.

When we wrote opalang, the size of generated JS was problematic, despite serious efforts at minimizing it. Does js_of_ocaml do better?

I'm not familiar with opalang, but I haven't noticed size issues with js_of_ocaml (though I've only used it for personal projects). It works by compiling OCaml bytecode to JS. I think the main thing you'd need to be careful about in terms of code size is which libraries you end up relying on.

EDIT: There's also bucklescript, which goes from OCaml to JS (skips the bytecode), but I think it is more relaxed in terms of preserving OCaml behavior. i.e., it relies on how JS behaves for certain operations, instead of trying to preserve how natively compiled OCaml would behave.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#59

Post by wtetzner »

brundolf wrote: post #13
wtetzner wrote: post #6

Earlier quoted context omitted.

There's also js_of_ocaml if a good type system is desired.

I think that's out of scope for the OP's needs/wants. They like TypeScript for catching basic API mistakes, the only thing they don't want is configuration headaches. I didn't get the sense they would be interested in learning a new language for this use-case, especially since I'm going to guess Cloudflare doesn't publish OCaml types for their JavaScript API.

That's fair. Guess I just got excited about an opportunity to plug js_of_ocaml ;)
Post reply on HN