3 ms·

I like Go and have no major complaints about it. I especially like the highly performant garbage collector and the fact that there are a lot of libraries for it

I like Go and have no major complaints about it. I especially like the highly performant garbage collector and the fact that there are a lot of libraries for it. With the libraries you have to be careful, though, quality of 3rd-party libraries differs a lot on Github. There is also one point of critique, I believe that Go got its concurrency primitives wrong. I fear people will hate me for saying this, but I say it because almost every library I've tested that uses lots of goroutines fails or produces some serious concurrency errors at one point or another. Not only are there many race conditions in Go code, there are also many libraries that silently fail. For example, scan Github for parallel directory walkers or check out uses of sync.atomic. I personally believe that both transactional memory and the actor model are easier to use although it might be harder to implement and make them efficient. I also think that thread local storage and Goroutine identities would have been useful, despite what the language purists say. Generally speaking, I think Go's choices of concurrency primitives are too low level. (I'm not saying there is anything wrong with them per se, just too low-level for most of Go's users, and I'm not excluding myself in this assessment.)

dilap 6y ago
Yeah, bounded channels ended up being more effective as a hype mechanism than a great concurrency primitive, I would say. Coming from Go and kicking the tires a bit on Rust, I was impressed w/ how much nicer it was to write parallel code using Rust + the crossbeam library than Go. At the end of the day Go's concurrency story is just traditional threads and mutexes, with custom syntax for one particular datastructure. But, you do get a great runtime race detector & the M:N scheduler, so you can use lots of goroutines w/o blowing out memory, avoiding async hassles.
coder543 6y ago
I agree with a lot of this. I'm especially looking forward how generics should make it easier to build a library of high level concurrency patterns that people can use in Go, instead of everyone trying to build their own. Promises (which would allow you to start a number of parallel tasks, then wait on the results), "parallel for" with controlled amounts of concurrency, etc. The M:N scheduler is great, and the ability to easily spin off Goroutines is really nice, but I think most people shouldn't need to manually launch goroutines most of the time. Goroutines should just be an implementation detail.
sangnoir 6y ago
Always read the documentation of your libraries to see if they give any thread-safety assurances - if they don't mention thread-safety, assume they do not have it. Concurrency in general, is really hard: hard to express and hard to debug - none of the languages I know do it perfectly. However, I like Go's concurrency primitives & tooling the most. Javascript and Erlang are runners up - for the record, the languages I'm familiar with are Erlang, Go, Python, Java, Javascript and C. I wouldn't know where C# or Rust would fit.

dilap 6y ago

Yeah, bounded channels ended up being more effective as a hype mechanism than a great concurrency primitive, I would say. Coming from Go and kicking the tires a bit on Rust, I was impressed w/ how much nicer it was to write parallel code using Rust + the crossbeam library than Go. At the end of the day Go's concurrency story is just traditional threads and mutexes, with custom syntax for one particular datastructure. But, you do get a great runtime race detector & the M:N scheduler, so you can use lots of goroutines w/o blowing out memory, avoiding async hassles.

coder543 6y ago

I agree with a lot of this. I'm especially looking forward how generics should make it easier to build a library of high level concurrency patterns that people can use in Go, instead of everyone trying to build their own. Promises (which would allow you to start a number of parallel tasks, then wait on the results), "parallel for" with controlled amounts of concurrency, etc. The M:N scheduler is great, and the ability to easily spin off Goroutines is really nice, but I think most people shouldn't need to manually launch goroutines most of the time. Goroutines should just be an implementation detail.

sangnoir 6y ago

Always read the documentation of your libraries to see if they give any thread-safety assurances - if they don't mention thread-safety, assume they do not have it. Concurrency in general, is really hard: hard to express and hard to debug - none of the languages I know do it perfectly. However, I like Go's concurrency primitives & tooling the most. Javascript and Erlang are runners up - for the record, the languages I'm familiar with are Erlang, Go, Python, Java, Javascript and C. I wouldn't know where C# or Rust would fit.