Post ATXmTg0U9MldRpliue by hikhvar@norden.social
 (DIR) More posts by hikhvar@norden.social
 (DIR) Post #ATXa1XHDodr8oWPc3s by Merovius@chaos.social
       2023-03-12T11:34:37Z
       
       0 likes, 0 repeats
       
       Unpopular opinion hill I will die on: The overwhelming majority of #golang code should not use channels or goroutines directly. Instead, it should rely on high-level libraries like errgroup and context. These two alone are probably enough for ~90% of code.
       
 (DIR) Post #ATXa1XzBBD1B0qyiZs by Merovius@chaos.social
       2023-03-12T11:38:06Z
       
       0 likes, 0 repeats
       
       I understand why, in the beginning, channels and goroutines where advertised as a major Go feature. But 10y of seeing them used taught me that they are ultimately too hard to use, too error-prone and that their use tends to make code incomprehensible. Not always. But very often.
       
 (DIR) Post #ATXa1YjcOYAHKshnxg by galdor@emacs.ch
       2023-03-12T13:22:48Z
       
       0 likes, 0 repeats
       
       @Merovius You are not wrong. A 2019 paper (https://songlh.github.io/paper/go-study.pdf) showed that message-based concurrency in Go was not less error prone than concurrenced based on shared memory, and that matches my experience.The core issue is that goroutines, channels, wait groups are primitives, the same way as threads or mutexes. If you are not comfortable with low level multithreading, you should not use them at all. But Go sold the image of an easy-to-learn and easy-to-use language, so developers got a bit too bold.It got better though. When I started using Go around 2016, it was common to recommend complex "pipelines" where data would be moved from goroutine to goroutine to somehow "scale" and/or be "more modular". Then the majority realized it did not make any kind of sense, and what I see nowadays is a lot more simple: you spawn goroutines to handle network connections or for parallel workloads (most of time some kind of map/reduce), and you avoid passing data through chans as most as possible.
       
 (DIR) Post #ATXmTg0U9MldRpliue by hikhvar@norden.social
       2023-03-12T15:42:20Z
       
       0 likes, 0 repeats
       
       @galdor @Merovius yeah, I developed some codebase for 5 years. You could clearly spot the early code. Full of go routines for business logic. The later code used go routines mostly in "library" code providing foundations like clients, observability and server frameworks.
       
 (DIR) Post #ATYM45H3BJOwdKc3Ps by galdor@emacs.ch
       2023-03-12T22:21:07Z
       
       0 likes, 0 repeats
       
       @tjpcc @Merovius I'm not going to single out Rob Pike, especially since he also co-created UTF-8. But a huge amount of insanity in software engineering comes from cargo culting. Someone perceived as important expresses an opinion about how to write software, and suddenly all startups rush to do the same.We still have to suffer from a well known but misguided article about how rewriting software is the worse thing possible.Funny thing is that it is similar in management. I remember working for a company which copied the Spotify model with everything including the stupid names (tribes, squads, etc.). Even confronted with the shortcomings, they simply could not change: Spotify did it, so it was the right thing to do.