3 ms·

The thing about Go is that some parts, like channels and goroutines I have written a fair share of Go now and have only rarely used channels or goroutines. In

The thing about Go is that some parts, like channels and goroutines I have written a fair share of Go now and have only rarely used channels or goroutines. In practice, channels are only a good model for a subset of concurrency scenarios and they come with problems. Also, those criticizing Go are right (of course). No amount of Go usage will alleviate its shortcomings. The lack of parametric polymorphism is incredibly annoying, error handling is mediocre (Rust handles this much better), and the lack of support for even simple abstractions (algebraic data types) is jarring. Nonetheless, I continue to use Go, because they also got a lot of things right: compile times, tooling, a very-well documented standard library, good compatibility between 1.x releases, a UNIX feel, low-barrier entry for other contributors to Go projects, and a thriving ecosystem for a relatively young language. (Of course, the JVM and Java do as well on these points, except for UNIX-feel.)

fauigerzigerk 11y ago
Where goroutines have helped me a lot is with networking code. The part of the system I'm writing in Go controls several instances of three different kinds of networked services, plus one command line tool. There are hundereds of tasks that request access to these services. The job of my Go code is to schedule, rate limit and coordinate access by these tasks to the network services. I did parts of it in C++ initially (because other parts of the system are written in C++) using queues and timers (could have done the same in Java) and then I rewrote it in node.js but wasn't happy with the asychronous design or with my productivity. So I think the reason why goroutines and channels have helped me so much is specific to this kind of project. Go's other language features (or lack thereof) wouldn't have enticed me into taking a closer look. But now that I have taken a closer look, I do like the library and tools a lot as well. To sum it up, if a program is basically a ton of loops doing blocking reads and writes that depend on each other, then goroutines and channels make the code look very similar to the idea. Mental load drops. Life is easier.

fauigerzigerk 11y ago

Where goroutines have helped me a lot is with networking code. The part of the system I'm writing in Go controls several instances of three different kinds of networked services, plus one command line tool. There are hundereds of tasks that request access to these services. The job of my Go code is to schedule, rate limit and coordinate access by these tasks to the network services. I did parts of it in C++ initially (because other parts of the system are written in C++) using queues and timers (could have done the same in Java) and then I rewrote it in node.js but wasn't happy with the asychronous design or with my productivity. So I think the reason why goroutines and channels have helped me so much is specific to this kind of project. Go's other language features (or lack thereof) wouldn't have enticed me into taking a closer look. But now that I have taken a closer look, I do like the library and tools a lot as well. To sum it up, if a program is basically a ton of loops doing blocking reads and writes that depend on each other, then goroutines and channels make the code look very similar to the idea. Mental load drops. Life is easier.