I wanted that same harness as a single native binary, with no Node.js requirement and the option to compile my extensions in.
This is maybe one level of "why", but why is this something one wants? What was the theory of how it would improve on the original? I hear a lot about single native binaries these days. Native is fast, right? One of something is simpler, right? I don't know, though...
On its last run (Linux x86_64, 1 CPU, 10 runs), pig --version had a median
of 21.5 ms against 300.3 ms for Pi 0.87.1, and peak memory was 24.6 MiB
against 101.5 MiB.
Benchmarking --version just tells you how fast each program does nothing, which isn't really a useful measurement when both programs are meant to run continuously.
And a harness spends most of its time waiting on model streams, tool
processes, and the terminal, which is the kind of concurrency Go handles
with less ceremony than most languages
I'm not sure that Pi actually suffers in this area. Highly concurrent software involving a lot of I/O is already NodeJS's strong suit.
Under the "why" section, there's a graphic showing Pi in gray and PiG in green, but the Pi option still looks better to me.
This is a significantly more complex design, staying (nearly) Pi-compatible while offering an extension SDK in several languages, as well as the runtime orchestration needed for all these different Go, TS, Python and Rust processes that are running.
It might have a better memory profile, but it's not clear what scaling problems this solves that make maintaining a full rewrite worth the trouble.
Plus, if you keep using even one TypeScript Pi extension, it doesn't actually rid you of Node. If the implied argument is that Node brings a minimum memory cost, the PiG's overall memory profile is arguably comparable with, maybe even a little worse than Pi's.
Try PiG if a native binary, shareable Piglets, or extensions in Go, Rust, or Python solve a problem you have.
I want to hear more about the problems PiG has solved for the author. The only real problem the piece explicitly describes is that usage-based pricing is coming soon. If the usage billing concern is real, why essentially lock yourself into recurring payments on keeping pace with Pi? And why add so much complexity on top?
You are kidding, right? The JavaScript ecosystem is a garbage dump of infinite dependencies. I refuse to install any random projects that use it. This fact alone is more than enough reason to justify this effort, as I am hardly the only developer that feels this way about it.
And you are missing the point. The author spends basically zero effort explaining why he made this choice. None. I have no idea if what you say is why he did it. Probably not! because (again!) you haven't escaped Node if you're still using Pi extensions written in TS.
Under the "why" section, there's a graphic showing Pi in gray and PiG in green, but the Pi option still looks better to me.
This is a significantly more complex design, staying (nearly) Pi-compatible while offering an extension SDK in several languages, as well as the runtime orchestration needed for all these different Go, TS, Python and Rust processes that are running.
It might have a better memory profile, but it's not clear what scaling problems this solves that make maintaining a full rewrite worth the trouble.
Plus, if you keep using even one TypeScript Pi extension, it doesn't actually rid you of Node. If the implied argument is that Node brings a minimum memory cost, the PiG's overall memory profile is arguably comparable with, maybe even a little worse than Pi's.
I want to hear more about the problems PiG has solved for the author. The only real problem the piece explicitly describes is that usage-based pricing is coming soon. If the usage billing concern is real, why essentially lock yourself into recurring payments on keeping pace with Pi? And why add so much complexity on top?You are kidding, right? The JavaScript ecosystem is a garbage dump of infinite dependencies. I refuse to install any random projects that use it. This fact alone is more than enough reason to justify this effort, as I am hardly the only developer that feels this way about it.
pi has pretty minimal dependencies.
And you are missing the point. The author spends basically zero effort explaining why he made this choice. None. I have no idea if what you say is why he did it. Probably not! because (again!) you haven't escaped Node if you're still using Pi extensions written in TS.