Notes for February 8-15

This was a grueling week at work, but I managed to keep polishing my tools, even if I decided to reinvent a couple of wheels in the process.

go-te and webterm

Since I kept coming across weird edge cases in pyte, I decided to create go-te, a Go equivalent that complies with the esctest2 test suite. This was rather a roundabout way to ensure I could port webterm to Go, but the icon alone was totally worth it:

After that was done, porting webterm to use go-te and improve responsiveness only took a couple of hours.

I am very happy with Go as a target language for most of my new projects–I had been meaning to switch to it wholesale a few years back, but the opportunity to have AI deal with all the messiness of its error handling and map out the standard library for me has been unparalleled.

Right now, it’s the best language for my use cases, since it has:

• Native speed (with some runtime overhead, but much better than Python).
• Full portability (including WASM, which I’ve found very useful in go-rdp and webterm).
• The standard library is still not fully “batteries included”, but there is now a huge range of stable libraries that are direct slot-ins for most of my needs, and the ecosystem is finally mature.
• Extreme LLM/AI friendliness (Go’s strict interface definitions and formatting conventions mean it’s almost impossible for an LLM to confuse similar symbols, and I’ve had pretty much zero compilation errors over several projects)
• Great support for testing and fuzzing (even if a tad too basic sometimes)

And yeah, I could probably have done Rust instead, but I prefer code I can read without delving into too many abstraction layers, and I haven’t yet come across a Rust-shaped problem (even if I am eyeing some C++ embedded hardware project ideas).

As far as doing AI-assisted porting, the best results I’ve had have been when I can leverage an existing test suite to steer the LLM towards the right behavior and edge cases. This is especially true when the original codebase is large and complex, and when the target language has a different paradigm or ecosystem.

• The Preact port of the Node-RED dashboard I did over the holiday season didn’t have a lot of tests, but the existing JS code could be coaxed into play. I’ve been poking at it slowly because bun still has broken WebSocket support, but it was one of the first major test-driven ports I did with Codex 5.1, and it showed me how to steer LLMs effectively at medium scale.
• go-rdp plays off the MSRDP specs to build its test suite (and there are copious references on the Internet), and I could leverage a lot of my knowledge and background into steering the models directly towards testing the weird edge cases. I’m using it daily (although I need to clean up and push some tweaks).
• go-ooxml is in a bit of a weird spot right now because the ECMA specifications have some gaps and modern Office versions have enriched the schemas in compliant but formerly unforeseen ways, but it is very much usable and will be part of a future project I’m planning out.
• go-busybox is still churning through the original busybox test suite, and the real sticking point right now is ash and OS signal handling (which I might not even need in a WASM environment, but which I would like to have working).
• go-te, my pyte replacement, used both the pyte and esctest2 test suites to validate terminal behavior and build a completely usable library overnight.
• webterm was ported to Go in less than two hours, largely because the test suite was translatable across as well.
• sashimi, my ongoing port of this site’s Python engine to Go, is pretty much done as well, except for the changes I want to make going forward. The core was “done” in less than two hours, and I had over 9000 “test cases” of live site content (then I spent two more hours having it optimize a custom wordcloud generator to ~87ms, which was a fun intellectual puzzle).

None of these things are perfect, and they’re at most 80% production-grade if you intend to make them load-bearing for a business venture, but they are excellent for my use cases because I had zero alternatives that matched my requirements.

And I am focusing on libraries and tooling on purpose–right now, I don’t think I can trust AI to build a full product from scratch without a lot of human oversight, but this way I can trust it to build the building blocks that I can then stitch together and harden as needed.