Pig: Pi in Go, a port that plans on keeping up | Hacker News Reader

Pig: Pi in Go, a port that plans on keeping up

developer.hpe.com

5 pointstnspacetime5 comments

    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.

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.

You do escape the Node garbage, because Pi extensions in TS are now optional and not mandatory anymore. I would re-write every TS extension that I have in Rust or Python just that I don't need to deal with the Node hell.

This. The JavaScript ecosystem is a dumpster fire within a miasma-infested cloaca. I love Pi, but I hate that I have to deal with the npm garbage.

Every time I run "pi update --extensions" I get this:

added 1 package, removed 1 package, changed 8 packages, and audited 320 packages in 6s

4 vulnerabilities (2 moderate, 2 high)

For the love of god I still haven't been able to fix those ominous 4 vulnerabilities. I even set gpt-6-sol/max on the problem and even it failed to fix my npm installation.

Pi in any other language would be god-sent, just that I don't have to deal with the npm garbage.

Reply on news.ycombinator.com