3 ms·

Great little guide. Now...my negative view on using Futures as per the examples in the guide: Futures (and concurrency in general) make your code much harder

Great little guide. Now...my negative view on using Futures as per the examples in the guide: Futures (and concurrency in general) make your code much harder to reason about, and much harder to debug. Sequential code running in one thread makes life much easier for the developer. Faced with the problem presented in the guide (3 method calls total 400 ms), I'd try hard to optimise the methods. Once I've squeezed every potential performance gain out of the sequential method, I'd then investigate caching. Finally, if I still had significant performance problems would I then look at concurrency.

chrisseaton 11y ago
That's a strange criticism of futures to make, because the great strength of them is that you should be able to think about them sequentially, and then as long as they do not have conflicting side effects that model will hold to a concurrent implementation.
- hyperpape 11y ago
  Agreed. There's a basic level of thread safety that any server code needs to meet[1]: there aren't global variables or objects shared between requests that are modified in unsafe ways. Once you have that, futures are often pretty easy to reason about. You do have to make sure you're being careful what you pass into your futures--perhaps using immutable objects or defensive copies. It's not trivial, but it's not horrible either. [1] Yeah, I know there are cases where people use separate processes each running single-threaded, but c'mon.
_Codemonkeyism 11y ago
I agree with concurrency making code harder to reason and read. Beside flow variables I've found Futures a readable solution though. The example should be considered IO code, which is hard to speed up as you're limited by the other side, not your code. Also I'd say it's much faster in real production environments but you have more calls than three to backend services. I will try to make the calling of backend services clearer in the guide, thanks.

chrisseaton 11y ago

That's a strange criticism of futures to make, because the great strength of them is that you should be able to think about them sequentially, and then as long as they do not have conflicting side effects that model will hold to a concurrent implementation.

hyperpape 11y ago
Agreed. There's a basic level of thread safety that any server code needs to meet[1]: there aren't global variables or objects shared between requests that are modified in unsafe ways. Once you have that, futures are often pretty easy to reason about. You do have to make sure you're being careful what you pass into your futures--perhaps using immutable objects or defensive copies. It's not trivial, but it's not horrible either. [1] Yeah, I know there are cases where people use separate processes each running single-threaded, but c'mon.

_Codemonkeyism 11y ago

I agree with concurrency making code harder to reason and read. Beside flow variables I've found Futures a readable solution though. The example should be considered IO code, which is hard to speed up as you're limited by the other side, not your code. Also I'd say it's much faster in real production environments but you have more calls than three to backend services. I will try to make the calling of backend services clearer in the guide, thanks.