4 ms·
The big problem with this kind of stuff is how debug them. Also, that despite the intention, all is really coupled: Don't make sense to cancel a order before cr
by mamcx 13y ago
The big problem with this kind of stuff is how debug them. Also, that despite the intention, all is really coupled: Don't make sense to cancel a order before create it, so the order of the actions are important.
The benefit is (only ?) easy of scaling, IMHO. How solve this? I understand that GO keep the ordering of the calls and is not harder than doing imperative...
- aliostad 13y agoWell, first of all, debugging while developing an actor is actually easier: you just have to debug an actor in isolation and make sure it does the right thing and sends the right event in response to the incoming event. In terms of debugging issues when in live, you have to rely on tracing and let something such as Logstash handle search, etc. The ordering of the workflow is preserved. As I explained, FraudCheck is only ever done after an order's payment has been authorised. Hope this makes sense.
- twic 13y agoWell, first of all, debugging while developing an actor is actually easier: you just have to debug an actor in isolation and make sure it does the right thing and sends the right event in response to the incoming event. No. No, this is terrifyingly incorrect. Making each component do the right thing in isolation is easy. Most of the difficulty in systems - in developing, testing, and debugging them - arises from what the components do when they're together, because it turns out your ideas about how they need to behave in isolation were mistaken.
- mamcx 13y agoExactly. Sometimes is necessary to step into the call of another function/actor, see what is is doing, note is necessary to step into more into a deeper function, etc. Or stop when a certain value arrive, and inspect the code. If this could be done with actor/csp, then is good idea to jump onto it.