Also created: capnproto.org, sandstorm.io, lanparty.house
- A few years back I patched the memory allocator used by the Cloudflare Workers runtime to overwrite all memory with a static byte pattern on free, so that uninitialized allocations contain nothing interesting.
We expected this to hurt performance, but we were unable to measure any impact in practice.
Everyone still working in memory-unsafe languages should really just do this IMO. It would have mitigated this Mongo bug.
- > In Java, Python, JavaScript, and C# an exception thrown from a finally block overwrites the original exception, and the original exception is lost.
Pet peeve of mine: all these languages got it wrong. (And C++ got it extra-wrong.)
The error you want to log or report to the user is almost certainly the original exception, not the one from the finally block. The error from the finally block is probably a side effect of the original exception. Reporting the finally exception obscures information about the root cause, making it harder to debug the problem.
Many of these languages do attach the original exception to the new exception in some way, so you can get at it if you need to, but whatever actually catches and logs the exception later has to go out of its way to make sure to log the root cause rather than some stupid side effect. The hierarchy should be reversed: the exception thrown by `finally` should be added as an attachment to the original exception, perhaps placed in a list of "secondary" errors. Or you could even just throw it away, honestly the original exception is almost always all you care about anyway.
(C++ of course did much worse by just crashing in this scenario. I imagine this to be the outcome of some debate in the committee where they couldn't decide which exception should take priority. And now everyone has internalized this terrible decision by saying "well, destructors shouldn't throw" without seeming to understand that this is equivalent to saying "destructors shouldn't have bugs". WELL OF COURSE THEY SHOULDN'T BUT GOOD LUCK WITH THAT.)
- FWIW, the limit these days is 10MB (after compression).
https://developers.cloudflare.com/workers/platform/limits/
That said, thank you for fighting library bloat! Small libraries tend to perform better (not just on Workers but in general).
- They say swap is highly highly recommended even if you have plenty of memory.
I don't care, I disable it anyway. Have been doing so for decades. Never caused a problem.
- When your system is out of memory, you do not want to return an error to the next process that allocates memory. That might be an important process, it might have nothing to do with the reason the system is out of memory, and it might not be able to gracefully handle allocation failure (realistically, most programs can't).
Instead, you want to kill the process that's hogging all the memory.
The OOM killer heuristic is not perfect, but it will generally avoid killing critical processes and is fairly good at identifying memory hogs.
And if you agree that using the OOM killer is better than returning failure to a random unlucky process, then there's no reason not to use overcommit.
Besides, overcommit is useful. Virtual-memory-based copy-on-write, allocate-on-write, sparse arrays, etc. are all useful and widely-used.
- > - There's actual standard logic for remotely-existing objects vs. just RPC
Cap'n Proto is an object-capability system that very much has a uniform representation of remote objects. Object references are first-class types. You can send someone a remote object reference, embedded in some other message (e.g. params or return value of another RPC). When they release that reference, you get notified that the object can now be cleaned up.
Is there something else you were looking for here that Cap'n Proto doesn't do?
Not meaning to argue, just curious to understand. (I'm the author of Cap'n Proto.)
> - An object implementing multiple interfaces retains the same identity (niche thing but useful in my use cases)
FWIW Cap'n Proto objects can implement multiple interfaces. That said, identity of remote objects is a surprisingly complicated subject, and at present it's not necessarily possible to tell whether two references point to the same object.
> - Somewhat larger scope of supported languages (very important that I don't have to start from scratch in few projects)
This is definitely a limitation of Cap'n Proto right now.
> - Established patterns for discovery, naming, and few other cases (pretty much DIY on RPC systems)
There is definitely a lot CORBA does here that Cap'n Proto doesn't. Cap'n Proto itself only defines object lifetimes within the context of an RPC session. Persistence and long-term object identity are left to a higher layer.
- Out of curiosity, like what?
- You can run your wasm app in a DO, same as you run it in a Worker.
- 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 am the lead engineer for Workers.)
- I built Cloudflare Workers?
- You aren't the only one who was confused! We bungled the messaging there.
- This is a bit of a misunderstanding.
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.
- Well... it doesn't. It just hides the one window.
(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!)
- I don't use workspaces and I've been a happy gnome user for decades...
- What's the difference between "minimize" and "hide"? "Hide" is readily available in the context menu of a window (right-click on its toolbar).
(Personally I rarely hide anything, I just have a messy stack of a zillion windows all the time... but I suppose that's not for everyone.)
- > BTW here's Deno saying Deno Deploy is process-per-deployment with seccomp.
And that part isn't open source, AFAICT.
> Because you can't, in the general case, recreate the setup on a different platform?
You also can't recreate Lambda on Google Cloud since Lambda's scheduler is not open source.
But you can use Google Cloud Functions instead.
None of these schedulers are open source. Not Deno Deploy, not Supabase, and yeah, not ours either. Standard practice here is to offer an open source local runtime that can be used with other schedulers, but not to open source the cloud scheduler itself.
> Pretending you don't see the whole argument for why people want the option of self-hosting the whole real thing
Yes I get that everyone would like to have full control over their whole stack and would like to have it for free, because of course, why wouldn't you? I like those things too!
But we're a business, we gotta use our competitive advantage to make money.
The argument that I felt mariopt was making, when they said "being tied to only 1 vendor is problematic", is that some proprietary technology locks you in when you use it. Like if you build a large application in a proprietary programming language, then the vendor jacks up the prices, you are stuck. All I'm saying is that's not the case here: we've open sourced the parts needed so that you can switch vendors. The other vendor might not be as fast and cheap as us, but they will be just as fast and cheap as they'd have been if you had never used us in the first place.
I will also note, if we actually open sourced the tech, I think you'd find it not as useful as you imagine. It's really designed for running a whole multi-tenant hosting service (across a globally distributed network) and would be massive overkill for just hosting your own code. workerd is actually better for that.
> Durable Objects
I want to be forthright and admit my argument doesn't currently hold up here. workerd's implementation of Durable Objects doesn't scale at all, so can't plausibly be used in production. We actually have some plans to fix this.
- I am not very familiar with Supabase edge functions, but it appears to be based on Deno. According to Deno's documentation, it does not implement hardening against runtime exploits, instead recommending that you set that up separately:
https://docs.deno.com/runtime/fundamentals/security/#executi...
The intro blog post for Supabase edge functions appears to hint that, in production, they use Deno Deploy subhosting: https://supabase.com/blog/edge-runtime-self-hosted-deno-func...
Note that Deno Deploy is a hosting service run by Deno-the-company. My understanding is that they have proprietary components of their hosting infrastructure just like we do. But disclaimer: I haven't looked super-closely, maybe I'm wrong.
But yes, it's true that we don't use containers, instead we've optimized our hosting specifically for isolates as used in workerd, which allows us to run more efficiently and thus deploy every app globally with better pricing than competitors who only deploy to one region. Yes, how we do that is proprietary, just like the scheduling systems of most/all other cloud providers are also proprietary.
But how does that make anyone "tied to one vendor"?
I did, of course, test it, and anyway we now run into the "freed memory" pattern regularly when debugging (yes including optimized builds), so it's definitely working.