Considering a lot of people will be using Gemini on fullstack or frontend applications, it doesn't make sense to write the CLI in Rust and integrate with JS/TS separately, as opposed to writing it in TypeScript so that you can directly work with packages within the ecosystem designed for that ecosystem.

Excuse my ignorance, but... What? It runs cli commands, why would the language it's written in matter for the integration? What am I missing here?

From a practicality standpoint, writing in TS allows you to execute arbitrary JS in-process with a simple exec() call; I have no doubt they'll use this to more deeply integrate agents with existing codebases in the near future. E.g. agents rather than just reading the code, will be able to directly import the data structures themselves, use libraries within the JS/TS ecosystem to parse code into an AST, and execute in-process test harnesses to validate behavior while editing.

And the MCP field is already pretty heavily saturated with TypeScript and JSONSchema, so using TS for it is a very ergonomic experience. Also since it's written in TypeScript, it's much more easy to integrate it with editors like VSCode (or Google's new Antimatter) which are built on top of Electron.

Are they using it this way? I think if you have access to the cli you can do whatever you want, and it already does use tools and use libraries and parse code. It's just using the cli. Not to mention it's much better this way because I can see it doing all these things. I can see what commands it wants to run and it asks me about it.

no. i think your reasoning is flawed.

think about how it would do the same for python/golang/lua/etc.

I would never write a TUI like this and simply `eval` in the same scope as the TUI frames.

you shell out and run it with the language engine required.

Opencode has the ability to lean on LSP and Formatters, but these are not required to be written in the same language as the TUI