I’m really curious how you would create libraries in any language that can be used by editors in every language. If I’m missing generational knowledge here, please enlighten me!
-
amongst themselves? I sincerely hope you can appreciate the danger of an entire generation believing that replacing something so fundamental and simple as synchronous function calls with asynchronous HTTP-requests to a JSON-RPC HTTP-server is somehow desireable and good. It's not
The one thing I didn’t mention in the talk, too, is that once you have N servers, the claim “this insulated your program from a crash” is clearly untrue, because have fun trying to recover when some guy in the middle of that web dies and restarts.
-
-
If they are stateless (caching aside), crashing/restarting can be a way of life. And there is no "web" implied - what is the need for communication between servers?
-
Because libraries use libraries, all the time. I explain this in the talk. It's easy to say "stateless", but try the actual exercise of looking at every API you use and seeing what would be required to make it stateless, and what would be the corresponding drop in efficiency.
-
(And also, what would be the corresponding increase in complexity of the control logic.)
-
If your API is designed for potentially high latency (which is a good practice in many cases anyways), and you have a language-native client that wraps the IPC, there is no reason writing client code would be more difficult to write.
-
However the server code would be much more complicated to write. It's also much more complicated to debug and reason about from the perspective of the client. Additionally, the OS must task switch to the server process which in itself has a significant latency and cost, and back.
-
This also means you'll have to carefully design the API to too many calls, which means the API is both harder to design and use, and less flexible. When the result is meant to be presented to the user it's easy for the overhead/latencies to stack up and you can no longer hit
-
60/144FPS. So you'll spend more time refining the API to add more caching (which is really complicated to get right) and bulk-functions or you'll just do as most seem to do nowadays, "meh, 200ms is fast enough for opening a dialog".
-
That being said, server/IPC is surely the right tool for some jobs, but it's a really bad tool for solving interop.
- 22 more replies
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.