3 ms·
I'll take your bet. First of all, the difference between threads is not nearly as severe as the difference between (remote) machines. There is an analogy to be
by stickfigure 4y ago
I'll take your bet.
First of all, the difference between threads is not nearly as severe as the difference between (remote) machines. There is an analogy to be made, but that's all it is - an analogy. Most applications don't care about nitty gritty thread-management performance.
Second, people said all that shit about network calls and yet... here we live in the age of distributed computing and it keeps getting more distributed. It's rapidly getting to the point where remote boundaries are something you consider as an optimization step. Most boring old business applications are "fast enough" even though the XyzService lives on another machine.
- valenterry 4y ago> First of all, the difference between threads is not nearly as severe as the difference between (remote) machines The whole reason for Loom is to improve performance of code that would otherwise be blocking. So what code is blocking? Exactly: code that waits for the OS (files, network, etc.). A call from one thread to the other isn't really a blocking call and that is not really what project Loom's main focus is about - at least as far as I can tell.