A point to consider though, is that often sequential code is used and concurrency is achieved by running multiple processes. This is pretty much the design of the cloud. A top-level coordinator partitions the work-load, and sequential programs process it, and the top-level assembles the results - think map/reduce at scale. Often the complexity of concurrency within a process is not needed (or is completely hidden away).

-----Original Message-----
From: JuciÊ Andrade
Sent: Oct 3, 2019 12:58 PM
To: golang-nuts
Subject: Re: [go-nuts] Channels may not be the best solution in Go

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.




-- 
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/1136160789.5311.1570130467434%40wamui-cheeto.atl.sa.earthlink.net.

Reply via email to