Hacker News Reader

Comment by apatheticonion | Hacker News Reader

Wish Pi (and Opencode, DeepSeek Harness, Claude, Claude Desktop, Codex Desktop) was written in a memory and performance efficient language.

I love alternatives to the big players but why is everything written in TypeScript or Python and takes up a gigabyte of ram.

I don't want to `npm install -g` something, just give me a single statically compiled binary that does the thing.

AI lowers the barrier of entry to Rust to virtually 0. As a side experiment, I have been rewriting Codex Desktop in Rust using native desktop APIs (gpui) and have made a cross platform copy that works on Windows, Linux, and MacOS. It runs at 120+fps and uses 40mb of ram. It's not that hard.

In a previous life, before the layoff times, I was working on a FaaS platform. If you need plugins, embed v8, quickjs or wasmtime/wasmer/etc.

People are acting like AI didn't eat up all the RAM on Earth. I had to sell my left kidney for the 8gb ram upgrade in my MacBook

View on HN

They actually mention this at the end of their post on Pi Durable[0]: > Why TypeScript again? Because it is the easiest way to bootstrap this. But as everybody knows by now, it's very easy to port everything to Rust or assembler. We're not ruling this out in the future, but at the moment we are focusing on TypeScript.

[0]: https://earendil.com/posts/pi-durable/

> Why TypeScript again? Because it is the easiest way to bootstrap this.

And when a Linux distro bumps a dependency that Node requires on without updating Node to use the updated dependency, then Pi doesn't start.

There are Rust alternatives to pi and folks are welcome to use them.

I find Typescript more approachable in many ways like compilation speed, extensibility, disk space used by cargo, LLM knowledge, and most devs I know already have node or bun installed anyway but not cargo, including me.

The speed in which pi can modify and extend itself is part of the appeal to me.

Goose and the Pi rust rewrite are great options - but lag behind big-brand competitors in terms of token usage and generated code.

This is more about demanding more of the big software vendors than it is about making an argument for the general software developer to write programs in Rust or Go.

We are talking about trillion dollar companies with highly paid engineers and unlimited token budgets.

As someone who has been writing TypeScript since the beta and started writing Rust professionally only 5 years ago, I'm about as productive in Rust as I am in TypeScript - so if I were distributing software, I'd want to ensure the end user has the best possible experience and that's hard to achieve with the node/python ecosystem.

"Run this bash script to install my CLI tool" behind the scenes it downloads a full copy of Node.js, installs the npm dependencies, add executable scripts for the entry points, updates PATH. It takes almost a second to start up, has no threads and uses way more memory than is necessary. Extend that to Electron applications which not only bundle Chromium, but also bundle Node.js - that's two v8 engines running and a process that starts with a memory footprint of almost a gigabyte.

Compare that to just downloading a portable self-contained single executable and running it. No package manager, no install scripts - just double click.

The end user is not installing cargo, compiling, or anything - they just run the binary.

Those who use a static executable are not the target audience of pi.

It's minimal and intended to be modified.

A static executable doesn't prevent program extensibility. You can use plugins just fine. A static executable makes distribution easier (no npm install, runtime versioning, etc)

When was the last time you patched Pi / OpenCode / Claude dist or source code before running it?

Most people use plugins, and native apps have no issues with that.

I would need cargo to author my own Rust plugins. I'll pass, thanks. Like I said, most peolpe I know already have node or bun, but not rust.

> When was the last time you patched Pi / OpenCode / Claude dist or source code before running it?

Funny you ask. Yesterday I patched opencode to replace \ paths with / depending on some heuristics. Couldn't get a plugin to fix in all cases I needed. Solved in one minute :)

And plugins for executables suck compared to "just create a .ts file in this directory and edit/test it in a few seconds until satisfied".

There's a target audience for rust harnesses but their overlap with pi audience is quite small.

> I would need cargo to author my own Rust plugins.

You could write them in Go, TypeScript, Python, whatever. If you wanted to write your plugin in Rust, you'd need the Rust toolchain though, yes.

Plugins don't need to be in the host language. It's up to the harness writer to ensure the plugin engine makes sense for the patterns of plugin writers.

Then it's up to plugin writers to ensure their plugins are performant so people enjoy using them.

> And plugins for executables suck compared to "just create a .ts file in this directory and edit/test it in a few seconds until satisfied".

Not really? Deno, Node.js are both embeddable within a native application, so plugins can be written in TypeScript without any change in expectations from the plugin dev's perspective. There's also QuickJS and LLRT which use like 1000x less resources than v8 (faster for plugins, slower for servers).

No one is asking plugin devs to change, just that the harness writers provide better platforms to build on top of

It's counterproductive to write the harness in a 2nd language if you're going to embed JS/TS runtimes. Now you need 2 toolchains since you can't just blindly generate TS code and pray it works as a plugin. Not to mention that it's much easier to reason about contracts and behavious within a single language.

You get the worst of both worlds and that's probably why the most harnesses tools don't do that.

What you're describin already exist but the target audience for such is small. I invite you to try and watch the adoption :) It's just a prompt away.

> It's counterproductive to write the harness in a 2nd language if you're going to embed JS/TS runtimes. Now you need 2 toolchains since you can't just blindly generate TS code and pray it works as a plugin.

Why? If you embed Node.js then the developer can develop against Node.js if they want to. It's the same as writing Cloudflare or AWS Lambda functions.

> Not to mention that it's much easier to reason about contracts and behavious within a single language.

That's arguable and depends on the way plugins are supported. MCP is a good example. It's IPC with a well documented JSON API. You can write your MCP server in any language you want and practically every language has bindings for it (it's also trivial to point an agent at the spec and have bindings generated).

> You get the worst of both worlds and that's probably why the most harnesses tools don't do that.

Almost all harnesses support ACP (pretty much a cross language plugin system) and that has enabled harness integration into VSCode, Zed and a plethora of "software factory" tooling. The same goes for MCP (also a cross platform plugin system). We do it all the time.

First mover was a huge part of developing low-effort MVPs but we are passed that point now. You're not going to be the first to market now, so you have to be the best in market.

> What you're describin already exist but the target audience for such is small

I'm not sure what you're arguing for? Are you saying that you think it's acceptable that that multi-billion dollar companies with strong engineers and unlimited token budgets ship low effort products that waste the limited resources available on consumer devices?

Like, if Pi/Claude/Codex/etc used a fraction of the resources and your experience as a developer or plugin developer was unchanged - you're opposed to that?

Are you okay with Microsoft shipping a broken operating system because it's good enough compared to the competitors?

Haha sorry, it's hard for me to comprehend not challenging those with the money and capability to ship great products... not shipping great products.

> I invite you to try and watch the adoption :) It's just a prompt away.

I am actually writing a native harness that is a pixel perfect clone of the Codex Desktop harness haha. I expect no one to use it because adoption is not about quality, it's about marketing and that is dominated by a handful of players.

That's not going to stop me because I'm doing it for fun, but if I can do it with a handful of DeepSeek tokens and a few weekends - there's no excuse for the big players not to.

> because adoption is not about quality, it's about marketing.

Alright if you believe this then we are wasting our time arguing pros and cons of using different technologies.

I'm happy you're creating your own harness. I plan to do that too if pi gets in my way but it is so small and flexible that this has not been the case yet.

Good grief, a voice of reason.-

I am really hoping a combination of the RAM-pocalypse and AI coding will result in less bloat. At some point ...

> I love alternatives to the big players but why is everything written in TypeScript or Python and takes up a gigabyte of ram.

Same reason everything's an electron app now. First mover matters to the makers and to the consumers more than performance and attention to those details.

Totally agree with this sentiment. On your plugin point, I recently did a PoC of QuickJS in wasmtime with a restrictive sandbox (10 syscalls total) for running untrusted plugin code and it was great. Took maybe 3-4 days to pull together and performed more than adequately for the kind of thing this class of software needs, with a security posture that beats pretty much anything widely deployed. When this level of engineering excellence is so cheap to achieve, we really need to bully companies that refuse to do it.

I made just that!

https://3code.capocasa.dev

Written in Nim. Unixy scrollback but cross plaform. Tested for token efficiency.

> AI lowers the barrier of entry to Rust to virtually 0

Not really. It lowers it, sure. By a lot even. But you still have the system requirement for compilation and ecosystem to deal with.

I was so frustrated about this that I ended up writing my own.

Reply on news.ycombinator.com