WASM is a great system, but quite complex -- the spec for Mog is roughly 100x smaller.

It's also designed to be run in an event loop. I've tested this with Bun's event loop that runs TypeScript. I haven't tried it with other async runtimes, but it should be doable.

As for the browser, I haven't tried it, but you might be able to compile it to WASM -- the async stuff would be the hardest part of that, I suspect. Could be cool!

Since it's new, Mog will likely not yet beat existing systems at basically anything. Its potential lies in having better performance and a much smaller total system footprint and complexity than the alternatives. WASM is generally interpreted -- you can compile it, but it wasn't really designed for that as far as I know.

More generally, I think new execution environments are good opportunities for new languages that directly address the needs of that environment. The example that comes to mind is JavaScript, which turned webpages into dynamically loaded applications. AI agents have such heavy usage and specific problems that a language designed to be both written and executed by them is worth a shot in my opinion.

JIT means the code is interpreted until some condition kicks in to trigger compilation. This is obviously common and provides a number of advantages, but it has downsides too: 1) Code might run slowly at first. 2) It can be difficult to predict performance -- when will the JIT kick in? How well will it compile the code?

With Mog, you do have to pay the up-front cost of compiling the program. However, what I said about "no process startup cost" is true: there is no other OS process. The compiler runs in process, and then the compiled machine code is loaded into the process. Trying to do this safely is an unusual goal as far as I can tell. One of the consequences of this security posture is that the compiler and host become part of the trusted computing base. JITs are not the simplest things in the world, and not the easiest things to keep secure either. The Mog compiler is written entirely in safe Rust for this reason.

This up-front compilation cost is paid once, then the compiled code can be reused. If you have a pre-tool-use hook, or some extension to the agent itself, that code runs thousands of times, or more. Ahead-of-time compilation is well-suited for this task.

If this is used for writing a script that agent runs once, then JIT compilation might turn out to be faster. But those scripts are often short, and our compiler is quite fast for them as it is in the benchmarking that I've done -- there are benchmarking scripts in the repo, and it would be interesting to extend them to map out this landscape more.

Also, in my experience, in this scenario, the vast majority of the total latency of waiting for the agent to do what you asked it is due to waiting for an LLM to finish responding, not compiling or executing the script it generated. So I've prioritized the end-to-end performance of Mog code that runs many times.

- Mog is a statically typed, compiled, embedded language (think statically typed Lua) designed to be written by LLMs -- the full spec fits in 3,200 tokens. - An AI agent writes a Mog program, compiles it, and dynamically loads it as a plugin, script, or hook. - The host controls exactly which functions a Mog program can call (capability-based permissions), so permissions propagate from agent to agent-written code. - Compiled to native code for low-latency plugin execution -- no interpreter overhead, no JIT, no process startup cost. - The compiler is written in safe Rust so the entire toolchain can be audited for security. Even without a full security audit, Mog is already useful for agents extending themselves with their own code. - MIT licensed, contributions welcome.

Motivations for Mog:

1. Syntax Only an AI Could Love: Mog is written for AIs to write, so the spec fits easily in context (~3200 tokens), and it's intended to minimize foot-guns to lower the error rate when generating Mog code. This is why Mog has no operator precedence: non-associative operations have to use parentheses, e.g. (a + b) * c. It's also why there's no implicit type coercion, which I've found over the decades to be an annoying source of runtime bugs. There's also less support in Mog for generics, and there's absolutely no support for metaprogramming, macros, or syntactic abstraction.

When asking people to write code in a language, these restrictions could be onerous. But LLMs don't care, and the less expressivity you trust them with, the better.

2. Capabilities-Based Permissionsl: There's a paradox with existing security models for AI agents. If you give an agent like OpenClaw unfettered access to your data, that's insecure and you'll get pwned. But if you sandbox it, it can't do most of what you want. Worse, if you run scripts the agent wrote, those scripts don't inherit the permissions that constrain the agent's own bash tool calls, which leads to pwnage and other chaos. And that's not even assuming you run one of the many OpenClaw plugins with malware.

Mog tries to solve this by taking inspiration from embedded languages. It compiles all the way to machine code, ahead of time, but the compiler doesn't output any dangerous code (at least it shouldn't -- Mog is quite new, so that could still be buggy). This allows a host program, such as an AI agent, to generate Mog source code, compile it, and load it into itself using dlopen(), while maintaining security guarantees.

The main trick is that a Mog program on its own can't do much. It has no direct access to syscalls, libc, or memory. It can basically call functions, do heap allocations (but only within the arena the host gives it), and return something. If the host wants the Mog program to be able to do I/O, it has to supply the functions that the Mog program will call. A core invariant is that a Mog program should never be able to crash the host program, corrupt its state, or consume more resources than the host allows.

This allows the host to inspect the arguments to any potentially dangerous operation that the Mog program attempts, since it's code that runs in the host. For example, a host agent could give a Mog program a function to run a bash command, then enforce its own session-level permissions on that command, even though the command was dynamically generated by a plugin that was written without prior knowledge of those permission settings.

(There are a couple other tricks that PL people might find interesting. One is that the host can limit the execution time of the guest program. It does this using cooperative interrupt polling, i.e. the compiler inserts runtime checks that check if the host has asked the guest to stop. This causes a roughly 10% drop in performance on extremely tight loops, which are the worst case. It could almost certainly be optimized.)

3. Self Modification Without Restart: When I try to modify my OpenClaw from my phone, I have to restart the whole agent. Mog fixes this: an agent can compile and run new plugins without interrupting a session, which makes it dynamically responsive to user feedback (e.g., you tell it to always ask you before deleting a file and without any interruption it compiles and loads the code to... actually do that).

Async support is built into the language, by adapting LLVM's coroutine lowering to our Rust port of the QBE compiler, which is what Mog uses for compilation. The Mog host library can be slotted into an async event loop (tested with Bun), so Mog async calls get scheduled seamlessly by the agent's event loop. Another trick is that the Mog program uses a stack inside the memory arena that the host provides for it to run in, rather than the system stack. The system tracks a guard page between the stack and heap. This design prevents stack overflow without runtime overhead.

Lots of work still needs to be done to make Mog a "batteries-included" experience like Python. Most of that work involves fleshing out a standard library to include things like JSON, CSV, Sqlite, and HTTP. One high-impact addition would be an `llm` library that allows the guest to make LLM calls through the agent, which should support multiple models and token budgeting, so the host could prevent the plugin from burning too many tokens.

I suspect we'll also want to do more work to make the program lifecycle operations more ergonomic. And finally, there should be a more fully featured library for integrating a Mog host into an AI agent like OpenClaw or OpenAI's Codex CLI.

Comments URL: https://news.ycombinator.com/item?id=47312728

Points: 163

# Comments: 83

Most AI agents have trouble enforcing their normal permissions in plugins and hooks, since they're external scripts.

Mog's capability system gives the agent full control over I/O, so it can enforce whatever permissions it wants in the Mog code. This is even true if the plugin wants to run bash -- the agent can check each bash command the Mog code emits using the exact same predicate it uses for the LLM's direct bash tool.

Mog is a statically typed, compiled, memory-safe language, with native async support, minimal syntax, and its own compiler written in Rust and its own runtime, also written in Rust, with `extern "C"` so the runtime can easily be embedded in agents written in different languages.

It's designed to be written by LLMs. Its syntax is familiar, it minimizes foot-guns, and its full spec fits in a 3200-token file.

The language is quite new, so no hard security guarantees are claimed at present. Contributions welcome!

Comments URL: https://news.ycombinator.com/item?id=47279263

Points: 3

# Comments: 2

Of course getting permissions to work well might be easier said than done, but I like this direction.

It's quite possible that's wrong. If so, I would write llm_reduce like this: it would spawn a sub-task for every pair of elements in the list, which would call an LLM with a prompt telling it how to combine the two elements into one. The output type of the reduce operation would need to be the same as the input type, just like in normal map/reduce. This allows for a tree of operations to be performed, where the reduction is run log(n) times, resulting in a single value.

That value should probably be loaded into the LCM database by default, rather than putting it directly into the model's context, to protect the invariant that the model should be able to string together arbitrarily long sequences of maps and reduces without filling up its own context.

I don't think this would be hard to write. It would reuse the same database and parallelism machinery that llm_map and agentic_map use.

Urbit is a long-term project starting from the foundations and working up the stack. It'll be stable soon, but it probably won't be ready to run something as heavy as a modern web browser for a while. That being said, it does work, and it's fun to play with as-is.

Urbit is a program you can run on Linux or MacOS intended to provide a complete personal computing experience on its own. It runs as a virtual machine for now, although it could run as a unikernel on bare metal (good project for a contributor who's interested!).

This VM acts like an operating system, in the sense that it loads and runs other applications within itself, and in the sense that it presents an application switcher and overall system management tools to the user.

This VM is designed from scratch to be as simple as possible, based on the thesis that the reason everyone has thought of a personal server but nobody runs one is that it's too complicated to do your own sysadmin.

Why is it complicated to do your own sysadmin? Because Linux is 15 million lines of code, and then there are tons of layers on top of that. What percentage of programmers even know how the internet works? A fair number of programmers have a decent sense for some corner of the modern computing world, but even seasoned professionals don't usually know the full structure of the digital world. How does BGP interact with the IP protocol? How do you make sure fsync() actually did what you wanted it to do? How does Linux overcommit_memory work? etc.

Urbit is weird, but that's mostly because it's a parallel universe of computing, not because it's inherently crazier than the alternative. We all have Stockholm Syndrome about 'ls -alH', and don't tell me 'grep' is an intuitive name.

In fact, there are very few basic building blocks in Urbit: binary trees of integers, the idea of a persistent event-log-based computer, and cryptographic identities. Pretty much everything is constructed out of those components.

And it's designed for a modern world with billions of users who might not all be completely trustworthy, so whole categories of complexity go away -- such as NATs.

So there's no standard industry term for describing this system, because there are no direct analogs or competitors.

Why would you want to use Urbit? The same reasons you want to use the modern consumer internet, which Urbit intends to pave over and replace with something better.

How is Urbit better? Because you'll have all your data and programs on one machine, which you control, using an open source operating system. You can build a peer-to-peer twitter or facebook clone on Urbit in a day or two, because the OS handles more of the distributed systems and identity problems that have killed most peer-to-peer projects in the past.

It's still in alpha, so it's a bit slow and buggy, and a lot more work has been put into kernelspace than userspace so far. What will make you way "wow this is cool" varies widely, but some good candidates are: - an internet experience not predicated on surveillance capitalism - no ads - control over your UI - a minimal aesthetic - interesting people to talk to on the network - lack of the twitter "thunderdome" feel - if you like to write programs, the Urbit system is fascinating to work with; I've learned a lot more CS from working on it

The other thing that's cool is that this new world isn't yet fully settled. You can write a little talkbot or something and still have a big effect on the culture.

Spoken programming languages FTW.

The pronunciations are no more exclusionary than learning Cyrillic, and the effort pays off.

The OS itself runs as a VM on your machine (either a Linux or MacOS host, for now), and that is the only place your data lives.

Urbit does implement a peer-to-peer encrypted, authenticated network among these VMs. It's not solely socially focused, though.

It's also intended to be your personal archive for things like your personal financial data, pictures, nusic, notes, and private documents like tax records and medical histories.

And not only an archive, but also your personal "agent", in the sense that it's a program that's on all the time, on the network on your behalf, to serve your blog, for example.

You can access Urbit through the command-line or a webpage that it serves for you.

The state of an Urbit VM is a folder on the host OS. You can zip it up, move it to another computer, and restart it there seamlessly.

None of these features by themselves is particularly interesting. What's unique about Urbit is that all of this is accomplished using a very small set of primitives, making it easier to write applications that don't go through some huge company that tracks your every move and has a conflict of interest between serving you and serving advertisers.

If you're interested in learning more details of how it works, there is actually quite a bit of technical documentation at https://urbit.org/docs

We're obviously still trying to figure out how to describe this thing. It doesn't occupy a slot that people already have in their minds for a piece of software, except maybe "personal server", but even that is somewhat vague.

Because there's a different world of computing inside Urbit, with its own libraries, apps, languages, etc., it can take a while to wrap your head around.

What's funny about this is that the Urbit world is orders of magnitude simpler than a standard Unix-based stack. We've just spent so much time learning things like DNS A records vs. CNAMEs and what 'xzvf' do for tar, that a parallel universe of these constructs seems bewildering again.

Comments URL: https://news.ycombinator.com/item?id=11306479

Points: 17

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=5335008

Points: 63

# Comments: 35