why typescript and not go

[samarth-na]

not much else to ask really

[ryanjsalva]

We wanted to...

1. Make it easy to contribute. JS (63%) and TS (38%) are consistently among the top 5 most used languages, making them accessible to an outsized portion of the community.
2. Leverage the ecosystem. There were some excellent tools already available in the JS/TS community that allowed us to iterate quickly (e.g. Ink).
3. Build something portable. JS/TS is probably one of most portable technologies. It's easy to run everywhere.
4. Work with something familiar. The team is pretty small, and TS was a familiar language. We optimized for moving fast.

Honestly, a CLI in Rust or Go would be fantastic. Who knows? Maybe we'll do it all over again. 😉

[loadingalias]

Why not Rust? Don't you feel like you're leaving stable perf updates on the table? We could be using ripgrep instead of grep; fd instead of find; eza instead of ls.

We'd have much higher performance and less weight.

I can't understand the choice outside of access to Ink... which is great for beautiful CLI... but is a bowl of spaghetti to read.

edit
I'm sorry I'm lazy and didn't read your response first. FML - embarrassing.

[allenhutchison]

We aren't precluded from running the faster rust based tools. In fact we were talking about this in a team chat yesterday with the idea of looking for those alternatives on the system and if they exist using them instead of the slower more widely available versions.

[zessu]

[samarth-na]

dude i just asked why

[scidomino]

I don't think it's revealing anything to say that we did seriously consider using Go and even did some actual prototyping of it. The decision was ultimately made for complex reasons including the Gemini Model just being better at typescript (since there are a lot more examples in it's training data).

[qiyi]

I've put a great deal of effort into trying to convert gemini-cli into a standalone executable binary, but I haven't succeeded yet. The reason is that I need to use gemini-cli in an environment where Node.js is not installed and installing it is impractical.

[allentv]

The key is to have an static binary that doesn't require any dependencies to execute on a target system. Go has very good tooling for cross compilation and some nice TUI libraries my favorite being BubbleTea. I am sure there would not be any problems with getting contributors or getting LLMs to work with Golang. Happy to dig deeper into any potential issues that you see.

[zessu]

why though? that's your particular use case, this does not seem to be the main issue for most people. The project has 2.3k issues and > 350 pull requests, I think starting to talk about rewrites is a waste of time esp considering this is a simple terminal app. What benefit would switching to rust/c++/go/nim/odin/zig or whatever else bring to this project?

[arrufat]

I think it's fair to ask what the technical reasons were.

From my experience with Claude Code (TS), Gemini CLI (TS) and Codex (Rust), there's just no comparison.

• memory usage of Codex is less than 10% of the other tools, so I can spawn multiple sessions without worrying. It amazes me how these tools can use 100s of MiB of RAM when the model is not even running in our machine: just read text, make api calls, parse the response, make edits.
• responsiveness is also noticeable greater: Claude Code has noticeable typing lags if you use it for a while (or while the model is working (typing lags in a terminal app? that's unheard of)
• start and close times are instant in Codex

So I guess Go makes sense here, for something in between (probably closer to Rust).