The advantage of Go is to be able to use millions of blocking Go routines.
Synchronous programming is much easier than async - especially for streaming protocols. > On Sep 16, 2021, at 4:17 PM, yba...@gmail.com <ybau...@gmail.com> wrote: > > Hello everyone, > > I am trying to design a new library to encode/decode MQTT messages. I began > the work, and now I must decide how to design the TCP processing of my > library, and I am facing two choices: > - Design in a non-blocking tcp way (that is let the user use > select()/poll()/epoll() sycall). > - Or design it with blocking tcp io inside go routines, which would return 2 > channels (read and write). Then let the user do a channel-select in its main > go routine. > > I fail to see which one is superior to the other. > Moreover: one is idiomatic go, but one the other hand I like the idea to > provide a thin wrapper and let the developper user of the library to choose > which way he handles his problematic. > > What would you do? > > Regards > Yves > -- > 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/e900640f-edaa-4f6a-9d8e-7c751841e498n%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/1B897582-B68B-4D78-9434-7E9E92D348FF%40ix.netcom.com.
