joelg

yeah I completely agree, I think there's a whole logic of reasons to using useEffect/useCallback/useMemo that the post didn't acknowledge.

personally, I want to have a comprehensive understanding of exactly when and why each of my components re-renders, and to do that I use hooks and design around referential equality. like you said, it's a kind of documentation, more about organization than performance.

not to say that this way is intrinsically better! just that the style is appealing for its own reasons

my understanding (which is definitely not exhaustive!) is that the case between Galileo and the church was way more nuanced than is popularly retold, and had nothing whatsoever to do with Biblical literalism like the passage in Joshua about making the sun stand still.

Paul Feyerabend has a book called Against Method in which he essentially argues that it was the Catholic Church who was following the classical "scientific method" of weighing evidence between theories, and Galileo's hypothesis was rationally judged to be inferior to the existing models. Very fun read.

one of my biggest subjective takeaways from spending hours scrolling around the map is that my impression that the userbase was dominated by software types was ~mostly wrong! feels like less than half, and the rest is huge swaths of normie, artist, furry, and media people

there are a other few places tracking those stats too; I just counted 14487454 in my database :)

point taken, but as the blog post here and many other comments have pointed out, there is a very sharp qualitative difference between just-Apple and Apple+Google doing this. Apple alone has a minority market share but together they cover enough of the market that many websites would be tempted to only allow connections from trusted clients.

The merkle tree is persisted, and updating it is only log(n). You only have to "hash 2n elements" once, and then incrementally maintain it. It's negligible overhead for free log(n) diffing.

The difference is that a trie over the hashes doesn't preserve lexicographical key ordering or support range queries, which are typically expected from key/value stores. But you're right - if you just need `get` / `set` / `delete`, you could just do that!

it’s definitely not an exact solution, but i’ve been thinking about ways prolly trees could fit into CRDT systems. they essentially give you efficient peer-to-peer entry-wise diffs, so could be good for identifying conflicts after-the-fact. but if you store operations in a prolly tree, you end up hashing them all (plus logarithmic additional space overhead), so it might be a non-starter.

i have a blog post to shill if you haven’t heard of them: https://joelgustafson.com/posts/2023-05-04/merklizing-the-ke...

on bluesky (sorry) the devs have been super active and responsive and eager to explain their approach. they have talked about this specific choice at length - that after an extensive ecosystem review and lots of thought, it seemed like a different architecture had a better chance of working at scale. I hope they find the time to explain this more publicly but it’s definitely a decision they didn’t make lightly.

More generally, I have a ton of respect for the standardization process and for the amount of (mostly volunteer!) engineering over the years that had gone into fediverse, but it’s been so long and growth has been so slow that I don’t think it’s unreasonable for a new project to try something different.

It's much more similar to a related Protocol Labs project: CAR (content-addressable archives) https://ipld.io/specs/transport/car/

Database applications of category theory!

I've been using it with React for a couple months now. In my experience it's been a little awkward but overall fairly usable. It seems like it would be easy to write a wrapper for.

Looks like the NYT ran a short summary https://www.nytimes.com/2020/09/14/technology/facebook-manip...

> At some point a company needs to make money

:-/

OpenAI started as a non-profit.

A simpler definition of fair use would definitely make automation easier! But is the simpler definition one we actually want or intend? Lots of laws are complicated because they’re the product of years and years of iteratively modeling a problem with lots of feedback and edge cases accounted for - why should we prioritize Google’s ease-of-enforcement over _the thing we actually want to be the law_?

I think a lots of people end up having a reaction like "well they're trying their best! what else are they going to do!? it's basically an impossible problem!" to things like this and other recent youtube headlines.

That reaction betrays an assumption that YouTube must exist at its current scale in its current form, just because... it does already. And I think that assumption is dead wrong: we're bumping up on all kinds of emergent phenomenon (conspiracies, runaway recommendations) and issues (copyright, borderline child porn) that cannot be solved, and we shouldn't let Google give us their best-effort compromise. If you can't address these kinds of problems in your product, don't fucking build it.