3 ms·
The author doesn't deconstruct the idea of function color at all: he just claims it's a good thing because threads are hard. The whole reason people talk about
by quotemstr 5y ago
The author doesn't deconstruct the idea of function color at all: he just claims it's a good thing because threads are hard. The whole reason people talk about function color in the first place is that it turns out there's no such thing as a free lunch and there's a good reason threads work the way they do.
- SV_BubbleTime 5y agoYea. It took way too long to get here: > Bob’s rant about function colour is actually a rant about proactor vs reactor programming. His argument is that it is better to write code that blocks on I/O than code that expects its I/O to be done for it elsewhere in the code. Yes, threading is hard. And he’s right that lots of async can be unnecessarily hard too. However… > But you don’t need to do [async]. With care, there is no reason for more than about 10% of your codebase to be async functions. Almost all the rest of your code can just transform in-memory data representations from one form to another. Ok… not sure how he got there. I have a gateway program right now that is definitely not just 10% IO. It’s like 95% IO. It seems a weird generalization to assume my programs will be similar to his.
- quotemstr 5y ago> Ok… not sure how he got there. I have a gateway program right now that is definitely not just 10% IO. It’s like 95% IO. It seems a weird generalization to assume my programs will be similar to his. Agreed. When a program exists mostly to coordinate the activity of other programs, most code in that program will be doing IO of various sorts, not crunching data. It's easy for someone who's written primarily data-crunching code to underestimate just how IO-intensive some other programs are --- and vice versa.