HN user

pmoati

20 karma

Fullstack developer, 20 years in the game. Started freelancing in 2005, shipped 30+ mobile apps and 20+ web projects for clients like Michelin, Clarins, Roland Garros.

I put software design, composable architectures and design patterns first — tech choices follow the need, not the other way around.

Currently building Pithos (https://pithos.dev) — a zero-dependency TypeScript utility ecosystem combining data manipulation, schema validation, and functional error handling in one tree-shakable package.

Based in Montpellier, France.

Posts2
Comments13
View on HN

I really like the interface-based auto-registration pattern, so elegeant!

The implementation of HoverHandler seems clever... no manual wiring. That's the kind of API design that makes Go's implicit interfaces shine.

I'm curious: How does error recovery work when a handler panics? Does the server keep the connection alive, or does it tear down?

That's a really good question. Before, I was using Google Translate, which is not perfect. Now I'm using Claude and I think I tend to centralize my tools... Like before, when I was using both Google Search and Google Translate, now I just use Claude for a lot of thing.

Plus, I think Claude is a better model than the one used by Google Translate, but correct me if I'm wrong.

But you're right, DeepL should be perfect to do it, because is model is dedicated for translations !

A really big up for you, I launched my lib https://pithos.dev fews days ago, and I tried to coordinate posts on HN, Reddit, dev.to and Linkedin... but it was a failure because I didn't have accounts for HN and Reddit, so I was not able to post :) Now I understand I have to interact with people to win karma and it's a better way to share and communicate with a community ! Might be you could add this point to your guide ?

I totally agreed with you. I'm French (nobody is perfect ^^), I'm not so fluent in english and I'm dyslexic, that why I often write my message, then I ask to Claude to translate it in english because i'm feeling I will lose the credibility of my message if there is too much mistake... But you're right, so this message is not translated by LLM :D

haha, I know that feeling! I worked on a RAG system for a pharmaceutical client and the hardest part was exactly this: You know, when everything looks fine, without error, but results are silently wrong!!! I think LLMs answering with full confidence on bad data is the most dangerous failure mode.

The Getting Real philosophy aged remarkably well ! "Say no by default" is something I wish more open-source maintainers would internalize... Every feature you add is a feature you maintain forever and knowing where to draw the line is probably one of the hardest skill in software.

Great writeup !

The bitmap trick is elegant and I've seen similar patterns in other contexts. The core insight resonates beyond Rust and SQL: the data structure that's "obvious" at design time can become a bottleneck when the real-world usage pattern diverges from your assumptions. Most fields exist vs most fields might not exist is a subtil but critical distinction.

The fix being a simple layout change rather than a clever algorithm is also a good reminder. I've spent 20 years building apps and the most impactful optimizations were almost always about changing the shape of data, not adding complexity.

I'm building Pithos (https://pithos.dev), a zero-dependency TypeScript utility ecosystem.

Five modules, one package: data utilities (Arkhe), schema validation (Kanon), Result/Option types (Zygos), typed error classes (Sphalma), and a Lodash migration bridge (Taphos).

The idea is that these patterns compose natively: Validate with Kanon, get a typed Result back via Zygos, chain transformations with Arkhe. One pipeline, no try/catch, full type inference.

Benchmarks: ~4x smaller and 5-11x faster than Zod 4, ~21x smaller than Lodash, ~3x smaller than Neverthrow.

Available on npm as @pithos/core