Burak, feel free to correct me if I am wrong, but now I think I understood the heart of the matter:
Your approach to software development is different from mine. Nothing wrong with that. . you normally write sequential code, and uses concurrent code where it fits best. That is fine. . I use to write concurrent code, and use sequential code where it fits best. That is fine as well. Concurrency mechanisms in Go are so easy to use that it allows me to take that approach. With a little bit of caution to not create a big ball of mud[1], you can write clean concurrent code. You said there is a synchronization overhead when a program uses channels. That is true. On the other hand, when we divide the load among several cores we end up with a net gain. Depending on the task at hand the difference can be staggering! I mean 15x faster or more! If we consider that nearly all CPU is multicore these days [2], we will soon conclude that writing concurrent code even for simple tasks makes sense, in order to leverage that processing power. Your concurrent code will run keep running well in newer CPUs. Your single threaded code won't. Again, nothing wrong with your approach, ok? To each its own. [1] http://laputan.org/mud/ [2] https://www.amd.com/en/products/cpu/amd-epyc-7742 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/41a107de-e426-456a-abab-d0b058e39373%40googlegroups.com.
