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

41–50 of 59 posts

Re: Reality Check for Cloudflare Wasm Workers and Rust

#41

Post by kentonv »

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 ?

Probably!

But, it's a little hard to answer the question based on your description, because you've described your setup in traditional server terms that don't translate directly to how Workers does things. Workers doesn't have tasks running in VMs or containers, it's a serverless distributed systems platform where code runs in response to events across a wide network.

So, in order to tell you how to build your application on Workers, I'd need to know what the application actually does.

Most likely, though, you would replace your rocksdb/sqlite storage with Durable Objects storage. You could locate different Durable Objects in specific regions as desired.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#42

Post by jfrunyon »

stavros wrote: post #34
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.

> You can even download the header, open the zip file, choose which files to extract, and only download those.

That bit isn't true, unfortunately; the file list is stored at the end of the file. You either have to (sequentially, file-by-file) scan the zip to find the file you want, or look at the end. Even more unfortunately, there are several variable-length fields between the interesting stuff like the file list and the end of the archive, and the length of those fields is stored before the field itself, so you can't simply use a Range request to retrieve the last bytes from the end, either. (And even more more unfortunately, the very last thing in the file is a "comment" field, which could conceivably contain the magic number that you have to look for in order to read the trailer/footer record.)

The Zip format is truly awful.

https://en.wikipedia.org/wiki/ZIP_(file_format)#Central_dire...

https://github.com/python/cpython/blob/7e465a6b8273dc0b6cb48...

Re: Reality Check for Cloudflare Wasm Workers and Rust

#43

Post by up6w6 »

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.

Yeah, my bad, maybe a better sentence would be asking if the problem was solved completely...

Basically the "[FIXED]" in the thread is about making the compilation time 10x faster, from seconds to hundreds of milliseconds, which is still very incompatible for a service that tries to make use of the few milliseconds from the TLS handshake to eliminate cold start latency.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#44

Post by DenseComet »

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 ?

Workers doesn't really do regions. The code runs in whatever datacenter is closest to the user. It also doesn't have the concept of durable disk. You can use KV, with its trade-off of eventual consistency, or use something like FaunaDB or Firebase, but that means that the request has to wait for the request to the backing service. Its also not super great for long running tasks. The possibility is there with Workers unbound, but I found the pricing structure for it to be a bit opaque.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#45

Post by pugz »

jfrunyon wrote: post #42
stavros wrote: post #34

Earlier quoted context omitted.

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.

> You can even download the header, open the zip file, choose which files to extract, and only download those. That bit isn't true, unfortunately; the file list is stored at the end of the file. You either have to (sequentially, file-by-file) scan the zip to find the file you want, or look at the end. Even more unfortunately, there are several variable-length fields between the interesting stuff like the file list an…

Something I’ve wondered for a while: is there a good modern alternative to zip?

Re: Reality Check for Cloudflare Wasm Workers and Rust

#46

Post by kentonv »

up6w6 wrote: post #43
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.

Yeah, my bad, maybe a better sentence would be asking if the problem was solved completely... Basically the "[FIXED]" in the thread is about making the compilation time 10x faster, from seconds to hundreds of milliseconds, which is still very incompatible for a service that tries to make use of the few milliseconds from the TLS handshake to eliminate cold start latency.

Ah, sorry for misunderstanding. I thought you were referring to the original issue.

The Wasm module in question here was 2.6MB uncompressed, which we consider quite large. IIRC after enabling liftoff it took about 200ms to load. Smaller modules would be expected to load faster. We'd normally recommend doing some tree shaking to get the size down to something in the hundreds-of-kilobytes range, in which case the load time would be expected to be tens of milliseconds, comparable to a TLS handshake.

The developer who reported the problem here considered it to be fixed, and we haven't heard anyone complain about Wasm cold start times since then, so we haven't prioritized further optimizations for the time being. If current cold start times are a problem for you, though, then please let us know.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#47

Post by chubot »

kentonv wrote: post #36
azakai wrote: post #35

Earlier quoted context omitted.

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 o…

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 existing small WASM VM.

I think they will end up with something like the union of JVM and CLR [1], and even that's not enough.

JS already has garbage collection, but its runtime data types can't really host something like Java or OCaml efficiently.

----

The CLR is supposedly language-agnostic, but I'd argue it's not. Visual Basic was "broken" for this reason -- VB.NET is more like C# than VB6. The old code doesn't run.

I've heard PowerShell described as a weird shell-like syntax for writing C# programs.

And I remember F#'s behavior around null, algebraic data types, and exceptions was heavily influenced by the CLR. In some ways it's probably closer to C# than its prime influence of OCaml.

So while I don't know anything about the WASM GC effort (and haven't kept up with it), I'm skeptical that we'll get a true polyglot experience. What's more likely is that some languages will be favored over others, with the "losers" experiencing 2x - 10x slowdowns.

And this doesn't even get into the runtime library issues. For example PyPy is essentially perfectly compatible with CPython at the language level, and has been for over a decade. Still, many applications have difficulty migrating to it because they lose bindings to native libraries, like linear algebra with NumPy, and OpenGL, Win32 bindings, etc. (these are enormous)

I expect the analogous issue to be a big problem for using WASM in a polyglot fashion too.

----

As a separate issue, WASM is still not up to par with native code in terms of protections around the stack and the heap: https://lobste.rs/s/a9ghhz/maintain_it_with_zig#c_ghawis . Thus it favors Rust over C/C++, since Rust enforces more integrity at compile time.

Real apps need to poke many holes in the VM to get anything done, and those attack vectors matter more as that happens. WASM follows the principle of least privilege better but it has regressed in other dimensions (at least if you want to run legacy C code, which was the original use case advertised)

----

[1] Random article from Google suggests that this is HARD, and these are two of the most similar VMs out there: https://www.overops.com/blog/clr-vs-jvm-how-the-battle-betwe...

CLR includes instructions for closures, coroutines and declaration/manipulation of pointers, the JVM does not

Another smaller difference is that the CLR was built with instructions for dealing with generic types and for applying parametric specializations on those types at runtime.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#48

Post by pjmlp »

chubot wrote: post #47
kentonv wrote: post #36

Earlier quoted context omitted.

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 o…

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 cross platform .NET.

Secondly, .NET was also an excuse to reboot VB language, so some QuickBasic quirks were also thrown out, additionally, they have increasingly made VB less painful to migrate old VB 6 code.

Other than that, you are right, and this is also a reason why platform languages always have an edge over guest languages, even if they aren't as shiny in getting new language features out the door.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#49

Post by nostrebored »

eloff wrote: post #38
nostrebored wrote: post #37

Earlier quoted context omitted.

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.

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.

Re: Reality Check for Cloudflare Wasm Workers and Rust

#50

Post by csomar »

kentonv wrote: post #28
csomar wrote: post #7

Earlier quoted context omitted.

> 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) That could be most web apps functionalities. Things like registration, authorization/authentication, sending emails, store/retrieve data, etc... > so using them to do “serious number crunching” at the edge, which is the advertised use case, see…

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

Post reply on HN