pmoati

Joined 8 months ago

Karma
20
Submissions
16
Member since
Mar 6
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.

View on Hacker News

Recent submissions

Comment · 7 months ago
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?

Comment · 7 months ago
Thanks! And I'll never try to sell you scam crypto ! :D
Comment · 7 months ago
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 !

Comment · 7 months ago
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 ?
Comment · 7 months ago
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
Comment · 7 months ago
Comment · 7 months ago
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.
Comment · 7 months ago
oups, I just realized you already explain you're using a git worktree. Sorry about that!

I think the demo statement idea is really clever! Without something like that, agents always build layers of plumbing that never connect to anything visible...

I've seen the same problem by using CC on my own projects.

Comment · 7 months ago
I'm sometime using Claude Code for the work, and I really like to parallelize multiple agents. So I'm wondering how you manage two workers who are editing a same file?
Comment · 7 months ago
The "patch file" approach for LLM output on large files is spot on. I've hit the same wall and forcing targeted replacements instead of full rewrites is the only sane way past a certain codebase size. Also respect for managing state manually in 9k lines of vanilla JS without reaching for a framework.
Comment · 7 months ago
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.
Comment · 7 months ago
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.

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton