Or is the claim not that one approach is more effective than other in terms of positive impact, but that the wealthy, for their own sake, would be better off founding their own organizations?

For question 3 on the ordering, I was imagining the following kind of scenario: one thread maybe calls a system library function to read a cursor position and another calls a system library function to write a cursor position. So even though they're separate functions, they interact with the same state. Do you require users to manually call to the recorder library to give the recorder runtime extra info in this kind of scenario? Sorry if this is a dumb question, I haven't really done any programming at this level.

1) How does the step backward functionality work? Do you take snapshots every so often of the Javascript environment? How do you handle destructive assignments?

2) Does Replay record actual syscalls made by the browser, or is it recording calls to the browser APIs by the javascript code (which I guess are effectively syscalls from the javascript code's perspective)?

3) The ordered lock technique described in https://medium.com/replay-io/recording-and-replaying-d6102af... makes sure that threads access a given resource in the same order, but what about threads accessing different resources in the same order? e.g. when recording, thread 1 accesses resource A before thread 2 accesses resource B. It seems like the ordered lock technique doesn't help you maintain that ordering in the replay. Is maintaining that kind of ordering across resources not actually necessary most of the time?

I think this project's use case is that you have a fixed query, but the dataset over which you're running that query is changing over time (getting streaming updates). The wasm part is doing the work of running the query over the dataset and updating the query results as new data streams in. So the assumption is that rendering isn't the bottleneck, but running the query is.

> Stern and Rogan are already super rich. The difference between $50mm/year of profit and $100mm means zero to their day-to-day lifestyle. What I imagine does matter to them is the size of their audience and their impact, and both made choices that will limit that forever.

So I guess you're right, nothing I can think of quite fills the niche that Rust does, if compiling to a native binary is a hard requirement. Also I'm not aware of any widely-adopted language with borrow checking, if that's a feature that's valuable for your use case.

I used to code a lot in C++, but I've come to the conclusion that manual memory management is a cost that has to be considered seriously. e.g. one burden is that when you're declaring a field on a struct in Rust, you have to consider whether it needs to be a reference, value, automatic reference counted, boxed, if its a reference, what the lifetime is, etc. The only thing I miss about manual memory management is the RAII pattern.

Rust moves down a level of abstraction that IMO is not useful for most applications.

Also, I haven't been following the Go ecosystem lately, so I could be wrong, but they seem to have done a good job at creating standard libraries for common stuff like http serving, and those libraries seem to have aged just fine.