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

Python Cloudflare Workers

blog.cloudflare.com

Post reply on HN
Print view View original

71–80 of 101 posts

Re: Python Cloudflare Workers

#71

Post by hoodchatham »

panqueca wrote: post #34
syrusakbary wrote: post #33

This is awesome, I'm happy that Cloudflare is adding more attention into running Python via WebAssembly at the Edge. I'll try to summarize on how they got it running and what are the drawbacks that they have from their current approach (note: I have deep context on running Python with WebAssembly at the Edge as part of my work in Wasmer). Cloudflare Workers are enabling Python at the Edge by using Pyodide [1] (Python…

Does this architecture supports uvloop?

Pyodide uses its own event loop which just subscribes to the JavaScript event loop. My suspicion is that this will be more efficient than using uvloop since v8's event loop is quite well optimized. It also allows us to await JavaScript thenables from Python and Python awaitables from JavaScript, whereas I would be worried about how this behaves with separate event loops. Also, porting uvloop would probably be hard.

Re: Python Cloudflare Workers

#72

Post by devwastaken »

It compiles python to we assembly which then runs on their modified V8 runtime. We assembly is generally a non solution to any problem, especially not this one. While it is convenient it is a clear lack of engineering ability that they can't implement a proper Python runtime.

The reasons to not use wasm are many - the tool chains for emscripten are not well documented, hacky, and we're not built to the quality you'd expect from a compiler. After all it's doing something nothing was designed for.

The performance will never be an improvement over a native engine, much of the context is lost in translation when compiling to wasm.

Re: Python Cloudflare Workers

#73

Post by Terretta »

"This is about more than just making bindings to resources on Cloudflare more Pythonic though — it’s about compatibility with the ecosystem."

Someone might be getting editorial help from GPT-4.

// Or a human might be getting fine-tuned interacting with LLMs, which I've noticed happening to me.

Re: Python Cloudflare Workers

#74

Post by [deleted] »

syrusakbary wrote: post #33

This is awesome, I'm happy that Cloudflare is adding more attention into running Python via WebAssembly at the Edge. I'll try to summarize on how they got it running and what are the drawbacks that they have from their current approach (note: I have deep context on running Python with WebAssembly at the Edge as part of my work in Wasmer). Cloudflare Workers are enabling Python at the Edge by using Pyodide [1] (Python…

[deleted]

Re: Python Cloudflare Workers

#75

Post by victorbjorklund »

alfor wrote: post #35

I don't see how people will start using a completely new way python is running. If you are just experimenting and having fun, sure. But would you bet your company or many many months of developpement on this? What happen if you get random bugs? The advantage need to be extremely high to make it worth it. Maybe for specialized work that need to happen at the edge and then, why not use js instead that is the bedrock of…

I can totally see it being used for small services where python has better libaries

Re: Python Cloudflare Workers

#76

Post by amirhirsch »

kentonv wrote: post #32
ssijak wrote: post #16

Can we just get full node runtime? Cloudflare is amazing, but without a full node runtime, we (and most of the usual apps) can't switch from things like Vercel/Netlify to Cloudflare.

The unique architecture of our runtime is what enables most of our competitive advantages. It's what lets us run your application in hundreds of locations around the world while also charging less than competing serverless platforms. If we used a full Node runtime, we would need to charge a lot more money, or only run your app in a couple central locations, or both. So, no, we can't just offer full Node. However, we…

I like that you answered this, but the request wasn't about workers but rather easing migration to Cloudflare. People want to migrate their entire business to Cloudflare. Provide dedicated servers and a container service, then the applications can migrate to workers. You can even produce an AI to do it for them.

Re: Python Cloudflare Workers

#77

Post by kentonv »

derefr wrote: post #66
nstart wrote: post #44

Earlier quoted context omitted.

I think it’s because the experience of familiarizing oneself with the platform and getting to a hello world level crud app/basic static site is done a lot better with vercel and netlify than it is with cloudflare. Cloudflares site and docs are not built with the approach of getting an app from 0 to 1 ASAP.

I get the sense that Cloudflare Workers is targeted almost exclusively at existing customers of Cloudflare, who have a “legacy” app proxied through Cloudflare DNS, who use Page Rules and Firewall Rules and the like. For these customers, Workers are an incremental optimization of an existing app — shifting some work to the edge, or allowing some systems to have a previously-internal backend stripped out, leaving them…

Workers started with that use case, but these days we're definitely aiming to be a general-purpose platform for app hosting, especially for new apps. It sounds like we're not getting that message across very well.

Re: Python Cloudflare Workers

#78

Post by vorador »

rvnx wrote: post #46
nstart wrote: post #44

Earlier quoted context omitted.

I think it’s because the experience of familiarizing oneself with the platform and getting to a hello world level crud app/basic static site is done a lot better with vercel and netlify than it is with cloudflare. Cloudflares site and docs are not built with the approach of getting an app from 0 to 1 ASAP.

Pricing also. 0.40 USD / month for a globally deployed site @ CF versus 199 USD / month for a static site with limited traffic usage @ the supposedly premium other hosts

I've heard rumors that lots of these premium hosts are running on top of AWS/GCP which means they have much worse unit economics than Cloudflare.

Re: Python Cloudflare Workers

#79

Post by kentonv »

ssijak wrote: post #70
kentonv wrote: post #32

Earlier quoted context omitted.

The unique architecture of our runtime is what enables most of our competitive advantages. It's what lets us run your application in hundreds of locations around the world while also charging less than competing serverless platforms. If we used a full Node runtime, we would need to charge a lot more money, or only run your app in a couple central locations, or both. So, no, we can't just offer full Node. However, we…

I understand what you said. I did not expect full node runtime workers with all the other benefits that you listed that current workers have (global distribution, no cold starts, cost..). But it would be great to have a choice. I feel it would benefit both users and Cloudflare to support both (with different tradeoffs). For example, selecting "I want node runtime for this app workers," I would need to select the regi…

Yeah, in theory we could build a parallel service that's more Lambda-like and hosts apps in a more centralized way. It's certainly something we've thought about.

The challenge is, can we actually build that in a way that is significantly better than the existing competition? It's a crowded space. If we just build the same thing everyone else is doing, will it attract enough use to be worth the investment?

It sounds like you would be interested. What in your mind would potentially make our product more attractive than competitors here?

Post reply on HN