feznyng
feznyng on Hacker News
In-process sandboxed llm-generated code execution. Considerably lighter weight, faster to boot (assuming pre-compilation) than Docker or spinning up micro-VMs.
The dose makes the poison.
Did you get a chance to evaluate coding performance?
This is cool stuff, have you considered submitting any of these exploits to
https://hackmyclaw.com/? Email being the only allowed injection vector might be tricky though.
You could maybe rearchitect the backend to be provider-agnostic and sell this as a native client for users of Discord, Matrix, Zulip, Stoat, etc. That way you can capture a larger market and you're fine even if Discord kicks you out for ToS violations. Although, I suspect there's a bunch of complexity in papering over each platform especially when you factor in voice/streaming.
> I think maybe there's a mid-ground with buy forever, 1 year updates, so people get the product they paid for, and if they want updates or support the development they can re-buy, however I'm yet to hear opinions on this model.
As far as desktop software is concerned, I think this a commonly accepted approach. Sublime Text is probably the most notable example.
Can you treat kqueue as infallible? I've found FSEvents sometimes drops events at high volume (unless I'm misunderstanding how to use it).
Could still be useful; maybe for overnight async workloads? Tell your agent research xyz at night and wake up to a report.
How? There's a bunch of annoying problems here:
- Where do you source real time traffic data, ferry schedules, etc? Google APIs get you part of the way there but you'd need to crawl public transit sites for the rest.
- How do you keep track of what went into the fridge, what was consumed/thrown away?
- How do you track real world events like buying a physical pass?
Sure, if I'm building something for myself or fellow hobbyists this approach works (though in that case I'd prefer a good TUI/CLI). But if you're building an app for the average person, how it looks has a big effect on whether they choose it over an alternative.
That isn't secure is the issue, the more things you have it hooked up to the more havoc it can cause. The environment being locked down doesn't help when you're giving it access to potentially destructive actions. And once you remove those actions, you've neutered it.
How do you make your win32 app look good to the average person?
My extremely paranoid take is they might intend to replace you with someone who will RTO but need to keep you around for a while until they find that replacement.
How does WASM solve the platform lockdown problem? That WASM will run in a third-party app that is subject to those restrictions. The system interface exposed within that runtime is still going to be limited in the same way a native app can't get real access to the filesystem, etc.
LSPs rely on a parser to generate an AST for a given language. This parser needs to be error-tolerant because it needs to return usable ASTs despite often parsing incomplete, incorrect code and fast enough to run on every keystroke so it can provide realtime feedback.
Most of the time they rely on their own hand-rolled recursive descent parser. Writing these isn't necessarily hard but time-consuming and tedious especially if you're parsing a large language like C++.
Parser generators like yacc, bison, chumsky, ANTLR etc. can generate a parser for you given a grammar. However these parsers usually don't have the best performance or error reporting characteristics because they are auto-generated. A recursive descent parser is usually faster and because you can customize syntax error messages, easier for an LSP to use to provide good diagnostics.
Tree-sitter is also a parser generator but has better error tolerance properties (not quite as good as hand-written but generally better than prior implementations). Additionally, its incremental meaning it can reuse prior parses to more efficiently create a new AST. Most hand-written parsers are not incremental but are usually still fast enough to be usable in LSPs.
To use tree-sitter you define a grammar in JavaScript that tree-sitter will use to generate a parser in C which you can then use a dynamic or static library in your application.
In your case, this is useful because you can compile down those C libraries to WASM which can run right in the browser and will usually be faster than pure JS (the one catch is serialization overhead between JS and WASM). The problem is that you still need to implement all the language analysis features on top.
A good overview of different parsing techniques: https://tratt.net/laurie/blog/2020/which_parsing_approach.ht...
LSP spec: https://microsoft.github.io/language-server-protocol/overvie...
VSCode's guide on LSP features: https://code.visualstudio.com/api/language-extensions/progra...
Tutorial on creating hand-rolled error-tolerant (but NOT incremental) recursive descent parsers: https://matklad.github.io/2023/05/21/resilient-ll-parsing-tu...
Tree-sitter book: https://tree-sitter.github.io/tree-sitter/
As you said, you need to have a proper legal entity for about 2 years before this becomes an option.
My low-stakes conspiracy theory is that MS is deliberately making this process awful to encourage submission of apps to the Microsoft Store since you only have to pay a one-time $100 fee there for code-signing. The downside is of course that you can only distribute via the MS store.
Try entering about:debugging in the address bar then “This Firefox” in the sidebar and installing it from there. I can’t remember if you need to turn on a particular setting but it should work on standard Firefox. It will go away when the app is closed though.
If anyone does decide to pursue this, you can use napi-rs [0] to write Rust modules and call it from JS. Lower overhead than IPC but you will crash your process if there's an issue in your Rust code.
[0] https://napi.rs/
Assuming this is hosted on Vercel (which the URL indicates) and everything's done/stored locally (as stated) I don't think there's passive cost associated with providing this service (besides dev time).
If you're doing language implementation work in Rust, an excellent crate to get similar diagnostic layouts to the Rust compiler is Ariadne[0].
[0] https://github.com/zesterer/ariadne
Posted by
feznyng on Sunday March 16, 2025 @12:43PM
from the wired.com dept.
You could make this a bring your own key product. But that will likely limit your market to technical users and businesses already invested enough in AI to have a key.
Upside is you just have to price for basic infra.
Really great for quickly building features but you have to be careful about how much context you provide i.e. spoonfeed it exactly the methods, classes, files it needs to do whatever you're asking for (especially in a large codebase). And when it seems to get confused, reset history to free up the context window.
That being said there are definite areas where it shines (cookie cutter UI) and places where it struggles. It's really good at one-shotting React components and Flutter widgets but it tends to struggle with complicated business logic like sync engines. More straightforward backend stuff like CRUD endpoints are definitely doable.
You might be interested in sigstore[1], although I'm not sure if/how it can be used in an iOS app.
[1] https://www.sigstore.dev/
iOS has a system level API for this sort of thing. Android does not.
You’re supposed to use the hide button for this.
This is why I’m a bit skeptical of the o3 results. If it’s spending a bunch of time reasoning aren’t the chances of it simply regurgitating a solution it saw in its training data at some point in its output stream higher? It still needs to be clever enough to identify it as the correct answer but it’s not as impressive as an original solution.
Depends on the language, some have runtime optimizations to make copies fast (usually FPs with purely immutable data). Not sure if that’s the case in something like Java.