no, the database
when you build any kind of data storage system you have to deal with limitations, let's say you rent a VPS with a 25Gb disk, and that gives you about 18gb of free space to store your relay's events
so, now, with #realy - you can set your maximum database size at 18gb and depending on how fast it adds new events, set your high and low water marks to trigger purging of events that nobody has looked at in the longest time
reduces the cognitive burden of managing a relay, and also lets you optimize the cost of running one
also just want to mention
rust and its bastard children do have garbage collectors
the biggest difference (aside from OOP data model) between #golang and #rust is that rust forces the programmer to explicitly state where a variable is in scope, the so-called "escape" problem
Go's GC uses a heuristic to try and (conservatively) pick memory allocations that are stale or definitely not in scope whereas Rust forces the programmer to stipulate when a variable is in scope
this lets Rust apps squeeze a little more performance, in the same way as C++, at the expense of high complexity of compilation (read memory and time cost for developers) and a longer test/edit cycle (because of that)
the margin is no more than about 5%
it's not worth it when you consider that it doesn't actually matter that much, 5% better performance, when it costs $5/month for the basic VPS and that means 10 cents saving versus if you wrote your shit in Go, which saves you 5% on the cost of your programmers
nostr:nevent1qvzqqqqqqypzqnyqqft6tz9g9pyaqjvp0s4a4tvcfvj6gkke7mddvmj86w68uwe0qyghwumn8ghj7mn0wd68ytnvv9hxgtcpzamhxue69uhk6mr9dd6jumn0wd68yvfwvdhk6tcqyqwj7rk9fcy077x8d5hhukdy3t248qxay8wkz20qzqu58qp929pvkmququn
also this is why the inventor of #nostr is a #golang programmer
because fiatjaf already understands the fact that Go apps are faster and less painful to build
I see thats good so it deletes just oldest events? or least used events by some metric somehow?
it keeps an record of the last time each event was returned to a client, and it removes the ones that were least recently returned to clients
i tried to justify not keeping this record but ultimately, events have their own "created timestamp" so that's there anyway, and you could maybe implement a GC that just purges by oldest created_at but that would not really be practical for a lot of use cases
Oddbean new post about login | logout