#realy now has a tested working garbage collector functionality, previously it was scratched in from previous work but i wrote a revised tester that fits in with the new schema of everything in realy

it is the afternoon and i have a little work to do now to update an Internet Computer #layer2 eventstore implementation, that allows relay operators who somehow like ICP to run a relay that uses a sharded blockchain database to store events

it is of course of interest to said shitcoiners, and good for them, and you know what i mean when i say good for you

my life would be misery without my bad jokes so also, good for you, directly

but it's also nice for people who want to run a plain and simple realy instance, now you can contain the event storage with typical low/high water mark cache management options and your specified gigabyteage with just one little .env file

and did i mention that it's also got the fastest JSON encoder and event store database out there?

some day in the future, when i have more time on my hands, i will build a test rig that lets me really see realy head to head with #strfry and i'm almost certain that realy is not gonna be far behind it, and probably, on a parity hardware basis, better

good for hoyte and his C++ lunacy 

 +1 interest in the benchmark 

 what do you mean? doesnt go already have a garbage collector? 

 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 

 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