5 ms·
I personally prefer the async model over synchronization because for me, it's a lot simpler to manage the async/await than having to synchronize. I find golang
by speedgoose 5y ago
I personally prefer the async model over synchronization because for me, it's a lot simpler to manage the async/await than having to synchronize. I find golang to be more difficult than javascript in this aspect. Golang has better concurrency though.
- vbezhenar 5y agoIf you don't want to synchronize, you need to run your app on a single OS thread. That's the case for node.js. You can configure golang runtime to run on a single thread as well, I suppose that it would remove any need of synchronization either. There are plenty of languages with both async model and multicore runtime support. For example Kotlin on JVM. You still need to synchronize on shared resources (or use other patterns like message passing). Async does not magically save you from synchronization. It's just a quirk of node.js implementation.
- speedgoose 5y agoNodeJS has more than one single thread, network IOs notably are on another thread. That's the beauty of it.
- patrickthebold 5y agoWhy would network IO be on another thread? libuv gives node non blocking network IO (or so was my understanding).
- zbentley 5y agoUnsure about network (if it's true that it's on a separate thread, perhaps it's because network operations take cpu time even when readied asynchronously--e.g. even after you select/[e]poll to determine what events to trigger next, the actual read/write/sendfile/whatever ops do take a little time). However, filesystem IO is performed in threads in libuv on many platforms, due to the unavailability of stable async IO capabilities.