4 ms·
I think the Go part is missing a pretty important thing: the easiest concurrency model there is. Goroutines are one of the biggest reasons I even started with G
by Rikudou 10mo ago
I think the Go part is missing a pretty important thing: the easiest concurrency model there is. Goroutines are one of the biggest reasons I even started with Go.
- auxiliarymoose 10mo agoAgreed. Rob Pike presented a good talk "Concurrency is not Parallelism" which explains the motivations behind Go's concurrency model: https://youtu.be/oV9rvDllKEg https://youtu.be/oV9rvDllKEg Between the lack of "colored functions" and the simplicity of communicating with channels, I keep surprising myself with how (relatively) quick and easy it is to develop concurrent systems with correct behavior in Go.
- PaulKeeble 10mo agoIts a bit messy to do parallelism with it but it still works and its a consistent pattern and their are libraries that add it for the processing of slices and such. It could be made easier IMO, they are trying to dissuade its use but its actually really common to want to process N things distributed across multiple CPUs nowadays.
- silisili 10mo agoTrue. But in my experience, the pattern of just using short lived goroutines via errgroup or a channel based semaphore, will typically get you full utilization across all cores assuming your limit is high enough. Perhaps less guaranteed in patterns that feed a fixed limited number of long running goroutines.
- theshrike79 10mo agoJust the fact that you can prototype with a direct solution and then just pretty much slap on concurrency by wrapping it in "go" and adding channels is amazing.
- macintux 10mo ago> the easiest concurrency model there is Erlang programmers might disagree with you there.
- kibwen 10mo agoErlang is great for distributed systems. But my bugbear is when people look at how distributed systems are inherently parallel, and then look at a would-be concurrent program and go, "I know, I'll make my program concurrent by making it into a distributed system". But distributed systems are hard. If your system isn't inherently distributed, then don't rush towards a model of concurrency that emulates a distributed system. For anything on a single machine, prefer structured concurrency.
- throwawaymaths 10mo agohave you ever deployed an erlamg system? the biggest bugbear for concurrent systems is mutable shared data. by inherently being distributable you basically "give up on that" so for concurrent erlang systems you ~mostly don't even try. if for no other reason than that erlang is saner than go for concurrency like goroutines aren't inherently cancellable, so you see go programmers build out the kludgey context to handle those situations and debugging can get very tricky
- kibwen 10mo agoI'll disagree with you there. Structured concurrency is the easiest concurrency model there is: https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ https://vorpus.org/blog/notes-on-structured-concurrency-or-g...
- auxiliarymoose 10mo agoBut how does one communicate and synchronize between tasks with structured concurrency? Consider a server handling transactional requests, which submit jobs and get results from various background workers, which broadcast change events to remote observers. This is straightforward to set up with channels in Go. But I haven't seen an example of this type of workload using structured concurrency.
- yxhuvud 10mo agoThe point of structured concurrency is that if you need to do that in code, then there is a need of a predefined structured way to do that. Safely, without running with scissors like how channel usage tend to be.
- kristianp 10mo agoIt would be good to see an example of what that looks like.
- auxiliarymoose 10mo agoBut how does one actually do that? What does the architecture and code look like?
- pornel 10mo agoYou do the same thing, if that's really the architecture you need. Channels communicating between persistent workers are fine when you need decoupled asynchronous operation like that. However, channels and detached coroutines are less appropriate in a bunch of other situations, like fork-join, data parallelism, cancellation of task trees, etc. You can still do it, but you're responsible for adding that structure, and ensuring you don't forget to wait for something, don't forget to cancel something.
- Zambyte 10mo agoThe new (unreleased right now, in the nightly builds) std.Io interface in Zig maps quite nicely to the concurrency constructs in Go. The go keyword maps to std.Io.async to run a function asynchronously. Channels map to the std.Io.Queue data structure. The select keyword maps to the std.Io.select function.
- maherbeg 10mo agoOne other thing I think it misses, is how easy it is to navigate a massive code base because everything looks the same. In a large team, this is crucial and I value the legibility over cleverness (I really dislike meta programming). Really the only thing I found difficult is finding the concrete implementation of an interface when the interface is defined close to where it is, and when interfaces are duplicated everywhere.