v8 isolates aren't actually a great sandbox and I would not trust them implicitly in the AI era. This is probably why they wrap them in an additional sandbox.
Without commenting on v8 isolates specifically, this doesn't necessarily hold in any isolation situation; many customers are running code on behalf of their customers, which are often submitting jobs on behalf of theirs, and so on. Isolation breaches within a platform customer can result in significant cross-user data breaches.
You're right, but there are cases when the risk can be managed. Like if you're running an auth lambda in one isolate, and another isolate is running the exact same copy of the code, I'd say malicious exploitation would be low enough a risk, that I'd be comfortable running things like this.
Not only are they shared kernel... They're shared process, shared address space, shared memory pool and allocator... In fact, there is very little isolated about them at all.
I bet there are a million ways to cause side channels allowing learning about other code or data on the same machine, and just one V8 bug (of which there have historically been thousands) let's you take over or modify code in another isolate.
But those same things (and more), in the majority case of completely benign workloads, are significantly better for resource utilization and performance.
I don't think their model is "run everything in V8 isolates as the only isolation primitive", I believe it's closer to "run things with V8 isolates as the floor, dynamically trading efficiency for security in response to runtime (and I'd also assume static) analysis". They also add restrictions to make it more difficult/expensive for code to exploit side-channels (ex. changing the resolution and behavior of `performance.now ` and `Date.now` , no multithreading, no SharedArrayBuffer , etc.). Code attempting to exploit side-channels usually has a fingerprint. If you can classify it well enough, and the cost of a false positive is paying for the process isolation you'd otherwise have paid for everything all the time, you probably end up with healthier margins.
I don't disagree that there are real issues, but I don't think that Cloudflare necessarily misrepresents them (though they do perhaps fall quite a bit short of saying "don't run security critical workloads on our platform"). If you can accept the risk though, you get cheap compute with someone else managing all the infrastructure. If you can't, you probably shouldn't be using Workers (and maybe not even cloud compute in general).
It's true that V8 isolates are more risky than micro VMs*. However, it's also true that micro VMs are more risky than giving each tenant their own machine.
At some point you have to decide where along the spectrum you want to put the boundary of "acceptable" for your workload.
Some people argue that isolates are below the necessary threshold and micro VMs are above it. But this isn't really based on any rigorous mathematical analysis, it's mostly vibes. It used to be that people said VMs weren't secure enough for critical workloads, but few people say that these days.
I would argue that we (Cloudflare) have demonstrated that the isolate model can work fine if done carefully: we've been doing it this way for nearly a decade with no breaches.
* Not "strictly riskier", though. There are some risks micro VMs have that V8 isolates do not. Micro VMs that allow tenants to run arbitrary x86 code place a huge amount of trust in the hardware to be exactly correct; a trusted JIT makes it much easier to work around hardware bugs when they are found.
I'm the original poster that said v8 isolates aren't a great sandbox and I would state that I didn't say they were impossible to use as a sandbox. I know you all at cloudflare are doing a ton on top of v8 isolates to make them secure.
I think as a general rule you'd just want multiple uncorrelated layers of isolation. If you aren't willing to spend what cf does on securing v8 isolates I think process isolation + seccomp + v8 isolates might be enough, otherwise all of our browsers would be ticking time bombs.
I agree! Just to be clear, by "security critical" I mean the tier where you'd also refuse shared VMs. I'm not convinced most people have workloads and threat models that actually need the isolation they say they want, nor a fully considered notion of what their preferred primitive buys them (per your footnote, and any number of other issues I'm completely unaware of). But I like and appreciate Workers, and am grateful to be paying less because Cloudflare bin-packed more.
Indeed! Why not? The reason why humans need variables, functions, types, etc are all cognitive limitations of the human brain. "AI" should not be helped by those constraints.
Less ironically, because LLMs need the patterns of human cognition embodied in source. There's just not enough well commented assembly to train LLMs to imitate.
didn't expect someone to post us here yet, we're still working on our launch!
We have been building BAML for around 3 years -- originally it was a DSL for getting structured outputs from llms using what we call 'llm functions'
Our users told us they wanted to do more, so we made it an actual turing-complete language, still with a focus on people building AI workflows and calling nondeterministic models. This is why we added very flexible testing capabilities into BAML itself for test parameterization, dynamic tests, etc.
As we were building it, we realized humans weren't going to be the ones writing the code, so we started researching what we could do on this front. This led us to design BAML to use all fully-qualified-names for everything (classes, enums,functions etc) to name one example. We found in some cases AI agents saved 30% tokens navigating baml codebases vs TypeScript ones. There's no imports to track down, etc.
We do aim to keep humans in the loop, and we'll do some more deep dives that tackle each feature.
I'm always surprised as well when new languages targeting widespread use launch without an official one. Dotnet/C#, Go and other languages that come batteries included with the package manager built into some kind of compiler/SDK binary, make the out of the box experience so much smoother, and the community hasn't fragmented nearly as much as say Java, Python and JS have into competing third party package management and project build tools.
Everyone in the Go community more or less uses the same Go modules support built into the SDK binary, much like how almost the entire DotNet community uses the NuGet package manager support built into the dotnet SDK binary. There are no extra dependencies to grab your project dependencies and build it.
My experiences in those langauges is that there is so much less debate over tooling, and people just get work done. No one in DotNet is waging an equivelent holy war about Gradle vs Maven etc...
I'm all for choices, but the languages who have made package management a first class citizen in their SDKs tend to be the languages I've enjoyed working in the most. I think package management tooling is a critical piece of developer ergonomics.
People used to joke a lot about how JS has a new framework every week, but I feel that way about Python build tooling! I've now had to use uv, poetry, pipenv, hatch...
I find your choice of examples (dotnet and go) baffling to me. Both enjoyed a very long life (8-10 years) past “1.0” before getting a standard package manager. The other examples, Java, python and JS are significantly older than Go (and even dotnet). Python and JS also had a significantly different intended use (scripting) than where they ended. Expectations of a language and its ecosystem changed. The compiler, linker, build system, package manager, LSP, linter, formatter, debugger, and plenty more are expected of any new language now.
Well not Go's package manager, right? Go modules came out 2019, Swift 2015?
I wasn't arguing against Swift needing a default package manager, I agree with that. Just the examples you picked to compare with are odd in context. You could compare Swift to its contemporaries like Rust or Zig and come to the same conclusion.
Because a package index isn’t actually core to a programming language, and specifically with Swift, Apple tried to ship as many of the necessary types as possible in the standard library
It's 'basically, a made-up language'. It's just tongue-in-cheek because when we started this it was just a ridiculous proposition to try and make a DSL.
Boundary (YC W23) | Software engineer (compilers) | Seattle, USA (in person) | Full-time
We are building a new programming language (BAML) to build AI agents -- the "typescript" for LLMs. We are open source: https://github.com/BoundaryML/baml
A big part of this language is all the tooling around visualizing non-deterministic code, visualizing code, and getting great observability (e.g. our language has type information at runtime unlike TS).
We are looking for engineers with experience with Rust, programming languages, and/or compilers. Any amount of experience is fine.
To apply: send an email to aaron@boundaryml.com with your resume and mention you came from HN
reply