It’s just randomly on Twitch somewhere. Video games need consistency as much as anything else, otherwise players immediately learn to exploit the hole. Re other requirements, the key is to put slow stuff like long-term storability on the *back* end, that stuff flows into after
-
-
Replying to @Jonathan_Blow @Nadagast
the interactive loop, so as not to slow down the loop.
1 reply 0 retweets 5 likes -
Replying to @Jonathan_Blow
I'd be surprised if GDocs or other collab systems were putting slow storage into the hot loop! Do you have reason to think they are? Seems like you'd want provable consistency for document editing, whereas with a game, it seems inevitable that there will be some inconsistency
1 reply 0 retweets 3 likes -
Replying to @Nadagast
I have no idea how gdocs is implemented, but it’s quite possible it works by each user independently reading and writing to a generic central database server. This seems to be a very web way to think about things (and was the background assumption behind the on-stream question).
1 reply 0 retweets 5 likes -
Replying to @Jonathan_Blow
Ahh, yeah that's how I'd guess it works too (though perhaps multiple servers around the world?) I'd still not expect them to finish storage in the hot loop (ie prevent you from interacting til the storage step finishes). But maybe I'm misunderstanding
1 reply 0 retweets 1 like -
Replying to @Nadagast
But, the db is going to be set up to guarantee a lot of things that would not otherwise be necessary, thus, be a lot slower than necessary.
1 reply 0 retweets 3 likes -
Replying to @Jonathan_Blow @Nadagast
Collaborative editors are a bad example here because they were (at least until "CRDTs" became the fad) built on the "operational transform" model, which means they run off-line and sync, effectively. So the server side does not need to be in the edit loop.
2 replies 0 retweets 11 likes -
So, although I have not looked at the code, it is very likely the case that if you encounter slowness on Google Docs or something, it is because the client is slow. Like even if they weren't collaborative at all, that is just as fast as their client code runs. Because "web".
3 replies 1 retweet 17 likes -
sure, "web", but I'm very grateful to just visit a URL and get stuff done without installing anything
1 reply 0 retweets 1 like -
Replying to @meoyawn @cmuratori and
That doesn't technically require "web" as we know it. The system could just as well had been that you go to a URL and it downloads a compiled program och runs it. Now with WASM they are attempting to "fix" it in post. Could have been done better if done properly from the start.
1 reply 0 retweets 7 likes
Also when I said "Because 'web'", I did not mean because JavaScript is slow. It's true that it is slow. But it is not nearly slow enough to produce slowdowns in operational transform processing, really. So "because web" meant "because web programming paradigms".
-
-
Replying to @cmuratori @odyssjii and
You can very easily write a fast operational transform engine in JavaScript. It is not a hard problem.
1 reply 0 retweets 0 likes -
Replying to @cmuratori @odyssjii and
I wrote a collaborative engine using CRDTs in Typescript, and it is possible to make it fast. The DOM is the biggest performance hurdle IMHO
0 replies 0 retweets 0 likes
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.