On Monday, July 24, 2017 at 6:44:10 PM UTC-6, nat...@honeycomb.io wrote: > > > only use goroutines when you know for a fact that you have an issue which > needs solving via concurrency, e.g., IO-bound workloads. While it's nice to > have goroutines and channels within easy reach, they do complicate program > structure and can cause data races if not used properly. Unless your app is > problematically slow, design everything to be as simple as possible. >
Generally I am a huge fan of this type of mind set.. However there is the contrarian position to this: - Design all programs in such a way that they could be concurrent later, if the app needs to be scaled.. Then imagine one day that all current programs may become obsolete and you will have to write them in a Quantum way rather than a classic way, if quantum computers require massively different programming technique. For example, is there a such thing as a multi core quantum computer or are quantum computers single core, or is quantum computing several quantum micro cores? If so, how would programs look and how would one think about program design? That's a bit off topic but still interesting dreamy thoughts. -- 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. For more options, visit https://groups.google.com/d/optout.
