I would recommend tracking this data over time. I work on Cloudflare's KV cache for Kimi K2.6, and while there are periods where our cache rate is low, we are frequently in the 80-90% range. OpenRouter shows us at 87.3% at the time of this post. We observe cache rates change quite a bit from hour to hour.
> an if let expression over an RWLock assumed (reasonably, but incorrectly) in its else branch that the lock had been released. Instant and virulently contagious deadlock.
I'd love to see this comparison between Garmin and Oura. I ditched Whoop because it was too easy to get 100 sleep scores, but my Garmin watch is much harder to please. I do think it offers better signal, but I've never scored over a 90, so maybe it is too critical?
I was responding to your point about isolates and cold starts. Snapshots are unique to Python, but V8 does not seem relevant here, all this is doing is initializing the linear buffer that backs Wasm memory for a particular instance. We have a lot of ideas here, some of which are mentioned in the blog post.
We discussed a separate configuration field for Python version. It’s not technically challenging, this was a design choice we made to simplify configuration for users and encourage more efficiencies in terms of shared dependencies.
Your concerns about V8 would impact JavaScript Workers as well and do not match what we see in production. It is also definitely possible to invoke C++ host functions directly from Wasm with V8.
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 of the optimizations we have planned don’t really depend on the underlying engine.
Edit: Also just want to clarify that this is not a POC, it is a Beta that we will continue improving on and eventually GA.
You can find an IV that makes sense for a single option with invalid other parameters, but things will break down when you go to price other expirations / strikes.
When trading, you don't want to wait to see an "updated" IV, you would want to respond directly to changes in important and well understood parameters like underlying price.
It's not really implied volatility, it's the actual volatility between now and expiration. Everyone can only estimate at what that will be.
IV is essentially using prevailing prices to understand what everyone else has estimated that forward volatility to be.
Beyond that, you will also find that IV differs across strikes [1]. Still, being able to fit a vol smile from incomplete market data (and some other adjustments if you are very sophisticated) and then price an arbitrary option is pretty useful.
Cloudflare Workers is hiring for multiple roles to help build the leading serverless platform, powered by Cloudflare’s edge network. Our platform is growing rapidly, with industry leading cold-start times and advanced features like Hyperdrive and Workers for Platforms. Cloudflare builds a large portion of our software with open source, such as workerd (runtime), Wrangler, workers-rs, Pingora, and Foundations.
We are looking for experienced C++ developers to work on the Workers Runtime or Durable Objects:
Nice! I always end up implementing some portion of this on every major project I do. After using something like Rust's Serde crate, you really miss this functionality in Python.