Location: Riga, Latvia (EU)

Remote: Yes, remote only

Willing to relocate: No

Technologies: Rust, TypeScript/Node, React, Go, Elixir, OCaml, Postgres, Kubernetes, NATS, gRPC, LLM/agent systems (RAG, tool calling, vector search)

Résumé/CV: https://martinserts.com

Email: martins.erts+hn@gmail.com

20+ years backend and full-stack. Rust and TypeScript in production, plus a long functional-programming background.

Also three AI products built solo, end to end, in Elixir, Go and OCaml, each on infrastructure I set up and still run. One has been live and unattended for months.

Open to contract (B2B) or permanent.

is there a reason to still pick PgBouncer over these newer ones? Or is PgBouncer mostly the default because everybody runs it

As Odyssey maintainer, I have to admit that it is exceptionally difficult to achieve stability (e.i. quality) of PgBouncer.

It has two limitations: it is single threaded and it is developed only re-actively. PgBouncer docs used to say that prepared statements can never be supported, in 2022 we supported it in Odyssey and then PgBouncer implemented it too.

In a sense Odyssey is developed to motivate PgBouncer development. To provide alternatives that keep PgBouncer from stagnation.

Yet, I can't say that scalability with SO_REUSEPORT is a good solution.

I have choose pgbouncer for my small db, because it does one thing and does it good - transaction pooling, other solutions seemed too complicated for me. All that features which should keep you allow to use listen/notify and set was unnecessary for me, i solved it on code level

I did not know this before... Google protobuf is not one thing, it is three! Same import, but:

* old C++ extension

* upb

* pure Python

upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?

This one helped me to dig deeper - https://vectree.io/c/how-python-protobuf-runtimes-work-pure-...

> upb parses FAST, but then every access is still C->Python and it slows it down. So for many reads the slow python one can win?

That is pretty unlikely. TFA's version is in Rust and just barely edges out upb.

rust code tends to be incredibly slow unless you spend a ton of time optimizing (compared to other compiled languages, and contrary to popular belief).

I did not know this until today... vision models don't hunt for the white space between letters like old OCR does. They just chop the whole image into a fixed grid of equal squares (patches) and treat each square like a word in a sentence.

This will help if you want to dig deeper - https://vectree.io/c/how-ocr-works-traditional-pipelines-vs-...

I always used memcached without knowing how it stores things.. never knew about the slab thing.

It is more sophisticated than grab memory per item.

This helped be to understand it better - https://vectree.io/c/memcached-internals-slab-allocation-lru...

actually local MCP just spawns a subprocess and talks via stdin/stdout.. same as CLI tool. Extra layer is only for remote case.

This might help if interested - https://vectree.io/c/implementation-details-of-stdio-and-sse...

You are right, PRs are not in git. format-patch and request-pull are originals designed for mailings lists. Github just put UI on top.

Interesting that DAG model means any branch from anywhere can be merged... the forge is just coordination.

Explored here if curious - https://vectree.io/c/git-graph-theory-logic

The ETH article title is actually fine - "a new trick brings stability."

The hype is in the HN title.

true, but reading this made me learn something new.

Turns out HashCash (system Bitcoin borrowed), was originally built to fight email spam in 1977 - https://vectree.io/c/hashcash-the-proof-of-work-system-cited...

I like the garden analogy.

Writing online used to bring you readers. Now it trains model, which answers the same questions without sending anyone to your site.