Hacker News Reader

Comment by steve_adams_86 | Hacker News Reader

I like the looks of this, and the idea behind it, but TypeScriot via Deno is an audited language with a good security model, a good type system, and sandboxing in an extremely well-hardened runtime. It's also a language that LLMs are exceptionally well-trained on. What does Mog offer that's meaningfully superior in an agent context?

I see that Deno requires a subprocess which introduces some overhead, and I might be naive to think so, but that doesn't seem like it would matter much when agent round-trip and inference time is way, way longer than any inefficiency a subprocess would introduce. (edit: I realized in some cases the round-trip time may be negligible if the agent is local, but inference is still very slow)

I admittedly do prefer the syntax here, but I'm more so asking these questions from a point of pragmatism over idealism. I already use Deno because it's convenient, practical, and efficient rather than ideal.

View on HN

It's a legitimate question to ask about any new language post AI - given there is no training dataset, any other language would work better with AI.

The bigger problem is maintainability over the long term, Deno is built by Node.js creator and is maintained for half a decade now, that's hard to compete with. In a way it's much more about social trust rather than particular syntax.

> given there is no training dataset, any other language would work better with AI.

I guess it depends on what "would work better" really means, but I don't think it's always a given. I've made my own languages, there is no available training set on exactly those, but AI with a prompt can figure out how to effectively use them as much as any other language, it seems to me. I guess it helps that most languages are more similar to each other than different, but even experimenting with new syntax seems to work out OK for me.

To me it seems like a pretty strong given because context windows are an important thing.

I can tell an llm "write hello world in C", and it will produce a valid program with just that context, without needing the C language spec nor stdlib definition in the context window because they're baked into the model weights.

As such, I can use the context window to for example provide information about my own function signatures, libraries, and objectives.

For a language not well-represented in the training data-set, a chunk of my context has to be permanently devoted to the stdlib and syntax, and while coding it will have to lookup stdlib function signatures and such using up additional context.

Perhaps you're trying to argue that the amount of tokens needed to describe the language, the stdlib, the basic tooling to look up function signatures, commands to compile, etc is not enough tokens to have a meaningful impact on the context window overall?

In basic scenarios agree it’s possible. I’ve similarly toyed with building a small language and LLM picks it up. But that’s an additional context and it’s never felt like it worked “out of the box” vs say Typescript. Just saying that it’s an adoption barrier established languages don’t have.

I'd also add all the other things that users expect around a language:

- GitHub syntax highlighting

- IDE integrations, LSP

- Modules and dependency management

I don't see an agent first language becoming a thing while humans are still ultimately responsible.

Coding is a verifiable domain, so I think you actually have it backwards on that first point. We can now synthesize Stack Overflow sized datasets for an arbitrary new language, and use those to train LLMs to understand it.

It's expensive of course, but if a new language is genuinely better for LLMs to write and understand, that would not be an issue.

Synthetic codebases are certainly an option, but if top models remain closed I don’t see them building datasets for every new language.

It's all about relative difficulty. It's not trivial to convince LLM vendors to include your pet new language in their internal synthetic datasets, and you can build your own and publish it but it'll be fiddly and expensive.

But compared to the immense amount of effort that goes into convincing a critical mass of humans to learn and write about your new language, and using _that_ material to train an LLM, I think it's fair to say things have gotten easier, not harder.

One thing that comes to mind, more of a first reaction than a considered opinion, is the complexity of V8 getting in the way. JavaScript and Typescript present a challenge to language implementors.

There is something to be said about giving AIs a clean foundation on which to build their own language. This allows evolution of such systems to go all the way into the compiler, beyond tooling.

I cannot comment on the new language, but Typescript is a huge spec. Yes, it has guardrails, but there is a lot of complexity to handle.

Something purpose built to enable embedding allows it to be used in more contexts. Maybe I want a Mog plugin for my latest video game. Embedding JS is possible, but no fun.

Right, this is probably the most compelling case for Mog. TypeScript is a beast. Everything you've mentioned here has been an obstacle for me at some point(s) or another.

I didn't mean to suggest there's no need for Mog either. I love to see developments like this. Deno is a practical solution for me today, but I see why it isn't a perfect forever-solution too.

But typescript is already trained in every model, and needs no additional work.

I generally agree. TypeScript is a great language, and JS runtimes have certainly had a lot of money and effort poured into them for a long time. I would add WASM to this category, as probably the closest thing to Mog. Write a program in some language, compile it to WASM, and load it into the host process. This is (probably) nice and safe, and relatively performant.

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.

Wasm is definitely designed to be compiled, either ahead of time or JITed. Wasm interpreters are few and far between.

Huh you're right. I had worked with interpreted WASM before, which is why I thought that was more common.

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

Wasm is explicitly not designed for interpretation (https://arxiv.org/abs/2205.01183)

I agree with this take. What does this bring to the table that can't be done with pretty much any preexisting toolset? Hell, even bash and chroot jail...

Reply on news.ycombinator.com