JuciÊ, I'm not going to endorse or dispute you assertions in the general case.
But, I do want to point out that the OP started with "I've been working on a math library". It then provides a link to the library on github. It may be a matter of personal choice and style when writing an application, or code for private use. However, when one is writing a library intended for public use, a good programmer needs to consider things a more deeply. In the specific case outlined in the OP, I believe providing simple blocking function is the best approach. If the library returns a channel, it is imposing the channel overhead, as well as adding unnecessary goroutines, and potential complexity, to the code of the library user. The library user may not want or need concurrency for their specific use case, but they are stuck with it. On the other hand, If only a blocking function is provided, it is few trivial lines of code to funnel that into a channel if the user wants to. IMHO, in the OP's case it sounds like a blocking function is the correct API for their library. Of course, if they want to provide a channel version in addition, that's fine. On Thursday, October 3, 2019 at 1:58:57 PM UTC-4, JuciÊ Andrade wrote: > 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/f5fc3aec-1f0d-4130-a757-82cded8cca29%40googlegroups.com.
