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

41–50 of 101 posts

Re: Python Cloudflare Workers

#41

Post by atomicnumber3 »

pjmlp wrote: post #39

Why anyone would like to slow down their requests using a full interpred implementation is behind me. Don't be surprised by scalability issues.

There's a lot of value in "just write a python thing in 5 minutes".

People tend to hem and haw about performance and "doing it right." But it's often a misplaced argument of "python vs ["right" thing]", it's "python vs not having anything." Often, a shitty python thing is worth a ton and fixes the problem, and then if performance becomes enough of an issue you can evaluate whether you want to prioritize fixing it. And I find that once something that works is in place, and just quietly doing its job, people suddenly find it a lot less objectionable to their sensibilities.

And even if we do replace it, having the python thing taking the heat off the "right" way's timetable lets you actually do it right because you can take your time.

Re: Python Cloudflare Workers

#42

Post by pjmlp »

atomicnumber3 wrote: post #41
pjmlp wrote: post #39

Why anyone would like to slow down their requests using a full interpred implementation is behind me. Don't be surprised by scalability issues.

There's a lot of value in "just write a python thing in 5 minutes". People tend to hem and haw about performance and "doing it right." But it's often a misplaced argument of "python vs ["right" thing]", it's "python vs not having anything." Often, a shitty python thing is worth a ton and fixes the problem, and then if performance becomes enough of an issue you can evaluate whether you want to prioritize fixing it. An…

We all know what is the outcome of that temporary script that was written in 5 minutes.

Re: Python Cloudflare Workers

#43

Post by dom96 »

hoodchatham wrote: post #21
pelletier wrote: post #10

I'm curious to see how the limitation of using pyodide packages only will play out for non-trivial builds. Thinking of all the non-pure python code out there that need to be manually rebuilt to support a non-trivial production app. Maybe Cloudflare's adoption will help bring more packages into the fold, and if it's an 80/20 rule here, would be good enough.

I certainly think there's an 80/20 rule here. Most packages are not very hard to port, and generally the ones that are hard to build use features like threads and multiprocessing, graphics cards, raw sockets, green threads, or other capabilities that have no obvious analogue in a webassembly runtime. As we mention in the blog post, the biggest issues are around supporting server and request packages since they are cl…

As we build out support for some of these features in the Workers Runtime, we should be able to port Python modules to use them. Some features like raw sockets are already available, so we should be able to make some quick headway here.

(Myself and Hood above are the folks who implemented Python Workers)

Re: Python Cloudflare Workers

#44

Post by nstart »

Difwif wrote: post #18
jatins wrote: post #9

Clouflare has a lot of great stuff for hosting and databases but I think they haven't done a great job marketing themselves as developer platform which has lead to platforms like Vercel, Netlify taking significant mindshare. Tangential: does Cloudflare provide container hosting service agnostic of language -- something like Google Cloud Run?

I agree something is wrong with their marketing. I was also initially drawn to Vercel and Netlify but after extended use and not being happy with either I eventually tried Cloudflare and discovered I love it. The pricing and the product is fantastic.

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.

Re: Python Cloudflare Workers

#45

Post by jppope »

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…

Cloudflare's engineering is top notch. I wouldn't expect anything different than what you would get from any of the other major cloud providers.

Workers are also extremely fast/performant and inexpensive... if you are working on a company those two aspects can be fairly important to the success of some types of companies.

Re: Python Cloudflare Workers

#46

Post by rvnx »

nstart wrote: post #44
Difwif wrote: post #18

Earlier quoted context omitted.

I agree something is wrong with their marketing. I was also initially drawn to Vercel and Netlify but after extended use and not being happy with either I eventually tried Cloudflare and discovered I love it. The pricing and the product is fantastic.

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

Re: Python Cloudflare Workers

#47

Post by syrusakbary »

kflansburg wrote: post #40
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…

I believe that your summary misunderstands how we will handle versioning. The pyodide /package versions will be controlled by the compatibility date, and we will be able to support multiple in production at once. For packages like langchain (or numpy as you mentioned) the plan is to update quite frequently. Could you expand on why you believe V8 will be a limiting factor? It is quite a powerful Wasm runtime, and most…

> pyodide /package versions will be controlled by the compatibility date

That's exactly the issue that I'm mentioning. Ideally you should be able to pin any Python version that you want to use in your app: 2.7, 3.8 or 3.9 regardless of a Workerd compatibility date. Some packages might work in Python 3.11 but not in 3.12, for example.

Unfortunately, Python doesn't have the full transpiler architecture that JS ecosystem has, and thus "packaging" Python applications into different "compatibility" bundles will prove much more challenging (webpack factor).

> Could you expand on why you believe V8 will be a limiting factor?

Sure thing! I think we probably all agree that V8 is a fantastic runtime. However, the tradeoffs that make V8 great for a browser use case, makes the runtime more challenging for Edge environments (where servers can do more specialized workloads on trusted environments).

Namely, those are:

  * Cold starts: V8 Isolates are a bit heavy to initialize. On it's current form it can add up from ~2-5ms in startup just by initializing an Isolate
  * Snapshots can be quite heavy to save and restore
  * Not architected with the Edge use case in mind: there are many tricks that you can do if you skip the JS middleware and go all in into a Wasm runtime, that are hard to do with the current V8/Workerd architecture.
In any case, I would love to be proven wrong on the long term and I cheer for <100ms cold starts when running Python in Cloudflare Workers. Keep up the good work!

Re: Python Cloudflare Workers

#49

Post by switch007 »

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…

Your comment would have been great without:

> So, no, we can't just offer full Node.

(Sounds a bit snotty)

Re: Python Cloudflare Workers

#50

Post by neonsunset »

mdasen wrote: post #25
neonsunset wrote: post #14

I with they added Azure Functions style workers using C# too, or AWS style lambdas using NativeAOT. Way lower runtime overhead and time to first response latency. But C# is an underdog language in those lands, so it's understandable.

At the moment, it seems like they're concentrating on using V8 isolates. In the article, there's a good diagram of why: an isolate is able to share so much between different applications. Even with NativeAOT, you're still launching an entire program that has to load everything into memory and execute. In some ways, they're using V8 isolates the way that mod_php was used back in the day. One reason PHP became so domin…

WASM performance and overhead currently make it a poor application for edge serverless scenario for something that is compiled (as it is in many other languages, really, stop adding overhead of yet another runtime undoing decades of optimization work).

"Consumption plan" azure functions as they call it are much more in line with V8 isolates where your function is just an isolated assembly run on a common runtime alongside many other functions. It has limitations and I assume the implementation of this is not open source (I don't know what it runs on exactly as azure functions implementation details never really interested me much).

Post reply on HN