maxmcd
maxmcd on Hacker News
Those care about quickly sending compact messages over the network, but most of them do not create a sparse in-memory representation that you can read on the fly. Especially in javascript.
This lib keeps the compact representation at runtime and lets you read it without putting all the entities on the heap.
Cool!
They're implementing MVCC
does having to maintain the slatedb as a consistent singleton (even with write fencing) make this as operationally tricky as a third party db?
Is this possibly an intentional reference to GNU Linux, or unrelated?
TCP performance gets quite poor over long distances. CDNs are very helpful if you're trying to make your site work well far away from your servers.
I think a lot of the original temporal/cadence authors were motivated by working on event-driven systems with retries. They exhibited complex failure scenarios that they could not reasonably account for without slapping on more supervisor systems. Durable executions allow you to have a consistent viewpoint to think about failures.
I agree determinism/idempotency and the complexities of these systems are a tough pill to swallow. Certainly need to be suited to the task.
I believe you are making use of gVisor’s userspace TCP implementation. I’m not sure if there is something similar in Rust that would be so easy to set up like this.
"Reply in the tone of Wikipedia" has worked pretty well for me
> > You can force an fsync after each messsage [sic] with always, this will slow down the throughput to a few hundred msg/s.
Is the performance warning in the NATS possible to improve on? Couldn't you still run fsync on an interval and queue up a certain number of writes to be flushed at once? I could imagine latency suffering, but batches throughput could be preserved to some extent?
Oh nice, yes I think your threads should be able to perform reads concurrently when the write lock is not held. Would make sure you are in WAL mode as well, since I think that will improve your concurrency.
This will block threads while waiting for other threads to write. That might work great for your threading model but I usually end up putting the writer in one thread and then other threads send writes to the writer thread.
Just that row should be locked since it's: "for update skip locked".
I agree the concurrency limitation is kind of rough, but it's kind of elegant because you don't have to implement some kind of timeout/retry thing. You're certainly still exposed to the possibility of double-sending, so yes, probably much nicer to update the row to "processing" and re-process those rows on a timeout.
Are there any open sourced sharded query planners like this? Something that can aggregate queries across many duckdb/sqlite dbs?
Do they mention transactions anywhere? Maybe it will be OLAP?
zero deps, nice instructions, how nice
Such a cool idea. I have
https://chess.maxmcd.com/ and (before blocking most of them) many bots played thousands of moves deep. I remember bingbot was very active.
Does this become much trickier because they're trying to heat to 600c?
The //indirect dependencies I believe are just there to track dependencies that are not in the project, or to help with caching:
https://github.com/golang/go/issues/36460In go 1.17 they were added so that project loading did not require downloading the go.mod of every dependency in the graph.
For what it's worth I think Go's MVS somewhat meets the desire here. It does not require lockfiles, but also doesn't allow use of multiple different minor/patch versions of a library:
https://research.swtch.com/vgo-mvsI believe Zig is also considering adopting it.
If there are any dependencies with the same major version the algorithm simply picks the newest one of them all (but not the newest in the package registry), so you don't need a lockfile to track version decisions.
Go's go.sum contains checksums to validate content, but is not required for version selection decisions.