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
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.
> 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 just suck compared to "just create a .ts file in this directory and edit/test it in a few seconds until satisfied".
> I would need cargo to author my own Rust plugins.
Only if you wanted to write them in Rust, I guess? You could also write them in Go, TypeScript, Python, whatever.
Plugins don't need to be in the host language. It's up to the harness writer to ensure the plugin system makes sense for the patterns of plugin writers.
Then it's up to plugin writers to ensure their plugins are performant so people like 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.
> 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?
> 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.
> 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.
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.
apatheticonion · · focus · HN ↗
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
bel8 · · focus · HN ↗
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.
apatheticonion · · focus · HN ↗
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.
bel8 · · focus · HN ↗
It's minimal and intended to be modified.
apatheticonion · · focus · HN ↗
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.
bel8 · · focus · HN ↗
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 just suck compared to "just create a .ts file in this directory and edit/test it in a few seconds until satisfied".
apatheticonion · · focus · HN ↗
Only if you wanted to write them in Rust, I guess? You could also write them in Go, TypeScript, Python, whatever.
Plugins don't need to be in the host language. It's up to the harness writer to ensure the plugin system makes sense for the patterns of plugin writers.
Then it's up to plugin writers to ensure their plugins are performant so people like 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
bel8 · · focus · HN ↗
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.
apatheticonion · · focus · HN ↗
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?
> 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.
bel8 · · focus · HN ↗
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.
Bluestein · · focus · HN ↗
I am really hoping a combination of the RAM-pocalypse and AI coding will result in less bloat. At some point ...
joshAg · · focus · HN ↗
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.
schlarpc · · focus · HN ↗
jacquesm · · focus · HN ↗
solarkraft · · focus · HN ↗
Not really. It lowers it, sure. By a lot even. But you still have the system requirement for compilation and ecosystem to deal with.
redrix · · focus · HN ↗
[0]: <a href="https://earendil.com/posts/pi-durable/" rel="nofollow">https://earendil.com/posts/pi-durable/
geauxvirtual · · focus · HN ↗
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.
capocasa · · focus · HN ↗
<a href="https://3code.capocasa.dev" rel="nofollow">https://3code.capocasa.dev
Written in Nim. Unixy scrollback but cross plaform. Tested for token efficiency.