JS has the fastest, most robust and widely deployed sandboxing engines (V8, followed closely by JavaScriptCore which is what Bun uses). It also has TypeScript which pairs well with agentic coding loops, and compiles to the aforementioned JavaScript which can run pretty much anywhere.

▲

otterley 2 hours ago | parent | next [-]

Note that "sandboxing" in this case is strictly runtime sandboxing - it's basically like having a separate process per event loop (as if you ran separate Node processes). It does not sandbox the machine context in which it runs (i.e. it's not VM-level containment).

▲

Brass_Hopper an hour ago | parent | next [-]

When you say runtime sandboxing, are you referring to JavaScript agents? I haven't worked all that much with JavaScript execution environments outside of the browser so I'm not sure about what sandboxing mechanics are available.

▲

otterley an hour ago | parent [-]

https://nodejs.org/api/vm.html

Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm), while Node says "The node:vm module is not a security mechanism. Do not use it to run untrusted code." I'm not sure whom to believe.

	▲	Brass_Hopper 12 minutes ago \| parent \| next [-]
		It's interesting to see the difference in how both treat the module. It feels similar to a realm which makes me lean by default to not trusting it for untrusted code execution. It looks like Bun also supports Shadow Realms which from my understanding was more intended for sandboxing (although I have no idea how resources are shared between a host environment and Shadow Realms, and how that might potentially differ from the node VM module).
	▲	Jarred 40 minutes ago \| parent \| prev [-]
		The reference docs are auto generated from node’s TypeScript types. node:vm is better than using the same global object to run untrusted code, but it’s not really a sandbox

▲

Muromec an hour ago | parent | prev [-]

Running it in a chroot or a scoped down namespace is all your need most of the time anyways.

▲

mrcsharp an hour ago | parent | prev [-]

> It also has TypeScript which pairs well with agentic coding loops

The language syntax has nothing to do with it pairing well with agentic coding loops.

Considering how close Typescript and C# are syntactically, and C#'s speed advantage over JS among many other things would make C# the main language for building Agents. It is not and that's because the early SDKs were JS and Python.

▲

chamomeal an hour ago | parent | next [-]

Typescript is probably generally a good LLM language because - static types - tons and tons of training data

Kind of tangent but I used to think static types were a must-have for LLM generated code. But the most magical and impressively awesome thing I’ve seen for LLM code generation is “calva backseat driver”, a vscode extension that lets copilot evaluate clojure expressions and generally do REPL stuff.

It can write MUCH cleaner and more capable code, using all sorts of libraries that it’s unfamiliar with, because it can mess around and try stuff just like a human would. It’s mind blowingly cool!!

▲

wiseowise an hour ago | parent | prev [-]

> C#'s speed advantage over JS among many other things would make C# the main language

Nobody cares about this, JS is plenty fast for LLM needs. If maximum performance was necessary, you're better off using Go because of fast compiler and better performance.

	▲	mrcsharp 40 minutes ago \| parent [-]
		> Nobody cares about this And that was my point. The choice of using JS/TS for LLM stuff was made for us based on initial wave of SDK availabilities. Nothing to do with language merits.