Transactions are supported in Durable Objects. In fact, with DO you are interacting with the SQLite database locally and synchronously, so transactions are essentially free with no possibility of conflicts and no worry about blocking other queries.
Extensions are easy to enable, file a bug on https://github.com/cloudflare/workerd . (Though this one might be trickier than most as we might have to do some build engineering.)
Try Durable Objects. D1 is actually just a thin layer over Durable Objects. In the past D1 provided a lot of DX benefits like better observability, but those are increasingly being merged back into DO directly.
What is a Durable Object? It's just a Worker that has a name, so you can route messages specifically to it from other Workers. Each one also has its own SQLite database attached. In fact, the SQLite database is local, so you can query it synchronously (no awaits), which makes a lot of stuff faster and easier. You can easily create millions of Durable Objects.
I would love to see Wasmer compared there, as we should have way better timings than all the options compared (for each of the use cases). Is there any way you can open the benchmark in Github or start comparing Wasmer as well? Thanks!
We are not sunsetting Pages. We are taking all the Pages-specific features and turning them into general Workers features -- which we should have done in the first place. At some point -- when we can do it with zero chance of breakage -- we will auto-migrate all Pages projects to this new implementation, essentially merging the platforms. We're not ready to auto-migrate yet, but if you're willing to do a little work you can manually migrate most Pages projects to Workers today. If you'd rather not, that's fine, you can keep using Pages and wait for the auto-migration later.
And when they move to workers we lose access to generic pages urls? Everything I generate going forward has my username in it? It would be nice to leave the first come first serve anonymous urls as an option.
Thank you for the clarification, sir. I wish that they had run that original Cloudflare blog post by you, especially this particular paragraph:
> Now that Workers supports both serving static assets and server-side rendering, you should *start with Workers*. Cloudflare Pages will continue to be supported, but, going forward, all of our investment, optimizations, and feature work will be dedicated to improving Workers. We aim to make Workers the best platform for building full-stack apps, building upon your feedback of what went well with Pages and what we could improve.
... which sounds (at least to me) more like an “either/or” situation, and a “Pages-is-going-into-maintenance mode” situation, than your answer suggests. But perhaps that’s just how I took it.
(Which personally is what I want. I hate it when multiple windows are grouped together just because they happen to be instances of the same application. For me that has nothing to do with whether or not they are related to the same task!)
In my experience FSD doesn't like staying in the left lane. It'll use it to pass but then gets out of it as soon as it can. Often too soon as it just has to shift left again to pass the next car...
How do you meaningfully count interventions, though?
I intervene on FSD all the time, but only due to differences of opinion, like I want to take a different route, or I think it's being too cautious, or I want to change lanes earlier / later than it decided to. In a year of use I can't remember a time when I intervened to prevent an accident.
So if you just looked at number of interventions in my data, it doesn't really tell you anything except that I'm too much of a control freak to just let it do its thing...
Tesla has the data from Austin, they closely track when the supervisor pulls the e-stop. But that data, the most critical data, is unsurprisingly absent here.
The dude has got six weeks to get those supervisors out of the car, and he isn't even giving the most critical data around them. Not a good sign.
Elon will probably find a near closed loop around an empty development in Austin, put two robotaxis there without a driver, and let people do a loop. Tesla contractors will walk the area an stop people from crossing when a robotaxi is near. Then he will proclaim there are driverless taxis in Austin and that they will expand to the rest of the US by mid 2026, and then talk about how actually optimus robots in 2027 are the real thing to focus on.
Honestly, I kind of think that ffmpeg should just document that it's not secure and that you're expected to run it in a sandbox if you plan to use it on possibly-malicious input. All the big cloud users and browsers are doing this already, so it would hardly even change anything.
ffmpeg is complaining that security bugs are such a drag that it's driving people away from their hobby/passion projects. Well, if fixing security bugs isn't your passion, why not just say that? Say it's not your priority, and if someone else wants it to be a priority, they can write the patches. Problem solved?
Extensions are easy to enable, file a bug on https://github.com/cloudflare/workerd . (Though this one might be trickier than most as we might have to do some build engineering.)
reply