8 ms·
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 w
by chatmasta 11mo ago
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 11mo agoNote 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 11mo agoWhen 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 11mo agohttps://nodejs.org/api/vm.html https://nodejs.org/api/vm.html Bun claims this feature is for running untrusted code (https://bun.com/reference/node/vm 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.
- Jarred 11mo agoThe 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
- Brass_Hopper 11mo agoIt'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).
- sheepscreek 11mo agoDoesn’t Bun use JavaScriptCore though? Perhaps their emulation, rather implementation, leans more towards security.
- Muromec 11mo agoRunning it in a chroot or a scoped down namespace is all your need most of the time anyways.
- mrcsharp 11mo ago> 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 11mo agoTypescript 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!!
- miguelspizza 11mo agoClojure is such an underrated language for vibe coding for this very reason. Makes me wonder what a theoretical “best possible language for vibe coding” would look like
- justatdotin 11mo agowhoa, instant upgrade. thanks!
- wiseowise 11mo ago> 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.
- 11mo ago
- parentheses 11mo agoNot to mention the saturation of training data
- catlover76 11mo ago[dead]
- locknitpicker 11mo ago> It also has TypeScript which pairs well with agentic coding loops, (...) I've heard that TypeScript is pretty rough on agentic coding loops because the idiomatic static type assertion code ends up requiring huge amounts of context to handle in a meaningful way. Is there any truth to it?
- deleted 11mo ago[deleted]
- miguelspizza 11mo agoNot sure where you heard this but general sentiment is the opposite. There was recently a conference which was themed around the idea that typescript monorepos are the best way to build with AI
- locknitpicker 11mo ago> Not sure where you heard this but general sentiment is the opposite. My personal experience and anecdotal evidence is in line with this hypothesis. Using the likes of Microsoft's own Copilot with small simple greenfield TypeScript 5 projects results in surprisingly poor results the minute you start leaning heavily on type safety and idiomatic techniques such as branded types. > There was recently a conference which was themed around the idea that typescript monorepos are the best way to build with AI There are also flat earth conferences.
- conartist6 11mo agoIt's especially tricky since monorepos are an obvious antipattern to begin with. They're a de-separation of concerns: an encouragement to blur the unit boundaries, not write docs, create unstable APIs (updating all usages at once when they change), and generally to let complexity spread unchecked.
- miguelspizza 11mo agoHate to say it but this sounds like a skill issue. The reason Typescript monorepos are gaining popularity for building with AI is because of how powerful TS's inference system is. If you are writing lots of types you are doing it wrong. You declare your schema with a good TS ORM then use something like TRPC to get type inference from your schemas in your route handlers and your front end. You get an enforced single source of truth that keeps the AI on track with a very small amount of code compared to something like Java. This really only applies to full stack SAAS apps though.
- deleted 11mo ago[deleted]