Readit Newsleontrolski commented on Venn Diagram for 7 Sets moebio.com/research/seven... · Posted by u/bramadityaw
For usable diagrams, beyond 3 sets, I always recommend upset plots, I wrote a little piece on them rather recently:
https://medium.com/@harithajayasinghe/beyond-venn-diagrams-d...
Ditto, another Upset blog post - https://leontrolski.github.io/upset.html
leontrolski commented on A Early History of Algebraic Data Types hillelwayne.com/post/algd... · Posted by u/todsacerdoti
Lovely writeup!
> Pascal did not have sum types because Wirth thought they were less flexible than untagged unions
I'm not sure whether my dream language would have tagged or untagged unions (Scala 3 has both it seems). I'd be interested if anyone has any further points of comparison beyond:
Tagged unions, eg. in Rust: enum Tagged {A(i64), B(String), C(f64)} Untagged unions, eg. in typed Python: Tagged = int | str | float
Tagged unions are better as you can represent duplicated types and types with no data, eg: enum Tagged {A, B(f64), C(f64)}
Untagged unions are better as you can willy nilly create new subsets and intersections of types. I find often in AST-ish work I want to express eg: def f(x: A | B | C) -> A | B
leontrolski commented on Do not download the app, use the website idiallo.com/blog/dont-dow... · Posted by u/foxfired
A reminder of all the features available right now with PWAs - https://whatpwacando.today
leontrolski commented on Postgres LISTEN/NOTIFY does not scale recall.ai/blog/postgres-l... · Posted by u/davidgu
Polling is the way to go, but it's also very tricky to get right. In particular, it's non-trivial to make a reliable queue that's also fast when transactions are held open and vacuum isn't able to clean tuples. E.g. "get the first available tuple" might have to skip over 1000s of dead tuples.
Holding transactions open is an anti-pattern for sure, but it's occasionally useful. E.g. pg_repack keeps a transaction open while it runs, and I believe vacuum also holds an open transaction part of the time too. It's also nice if your database doesn't melt whenever this happens on accident.
> also fast when transactions are held open
In my linked example, on getting the item from the queue, you immediately set the status to something that you're not polling for - does Postgres still have to skip past these tuples (even in an index) until they're vacuumed up?
leontrolski commented on Postgres LISTEN/NOTIFY does not scale recall.ai/blog/postgres-l... · Posted by u/davidgu
I'd be interested as to how dumb-ol' polling would compare here (the FOR UPDATE SKIP LOCKED method https://leontrolski.github.io/postgres-as-queue.html). One day I will set up some benchmarks as this is the kind of thing people argue about a lot without much evidence either way.
Wasn't aware of this AccessExclusiveLock behaviour - a reminder (and shameless plug 2) of how Postgres locks interact: https://leontrolski.github.io/pglockpy.html