2 ms·
This is a great point to observe, thanks. My commentary is biased towards web development > But generally the choice isn't async code or sync code; it's async
by pantulis 7y ago
This is a great point to observe, thanks. My commentary is biased towards web development
> But generally the choice isn't async code or sync code; it's async code or multithreading.
So true! years ago I worked with CORBA on top of ACE's libReactor and the result had an interesting mixture of the worst of the worlds of async and threads-and-locks ;)
- kragen 7y agoCondolences! As for web development, JS has been async since day 1. For a little while Opera was multithreading it, but that was really hard to program on, because they didn't even offer locks. And Perl was not normally multithreaded, but before POE it wasn't async either, but rather multiprocess. msql was async, as was FastCGI, originally. So I'm not sure I agree even within the scope of webdev history. Maybe you got started late when lots of people were already using Java?
- pantulis 7y agoSure! I got fed up with all that multithreading Vietnam and cut my web teeth with Rails in '05 and as such my focus has been on the business side of the applications you can build on top of a lot of software pieces that may or may not be async/MT or whatever. For example we ran a lot of Rails code on top of FastCGI with lighttpd but as far as I can remember the Rails code we wrote wasnt affected by the fact that FastCGI was async.