[questioner8216]

I dislike some of this article, my impression is similar to some of the complaints of others here.

However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place? If only immutable messages are shared between goroutines, it should be way easier to avoid many of these issues. That is of course not always viable, for instance due to performance concerns, but in theory can be done a lot of the time.

I have heard others call for making it easier to track mutability and immutability in Go, similar to what the author writes here.

As for closures having explicit capture lists like in C++, I have heard some Rust developers saying they would also have liked that in Rust. It is more verbose, but can be handy.

[Someone]

> However, are Go programs not supposed to typically avoid sharing mutable data across goroutines in the first place?

C programmers aren’t supposed to access pointers after freeing them, either.

“Easy to do, even in clean-looking code, but you shouldn’t do it” more or less is the definition of a pitfall.

[lenkite]

There is a LOT of demand for explicit capture clauses. This is one thing that C++ got right and Rust got wrong with all its implicit and magic behaviour.

https://www.reddit.com/r/rust/comments/1odrf9s/explicit_capt...

[silisili]

Go is a weird one, because it's super easy to learn -if- you're familiar with say, C. If you're not, it still appears to be super easy to learn, but has enough pitfalls to make your day bad. I feel like much of the article falls into the latter camp.

I recently worked with a 'senior' Go engineer. I asked him why he never used pointer receivers, and after explaining what that meant, he said he didn't really understand when to use asterisks or not. But hey, immutability by default is something I guess.

[badc0ffee]

He must have been a senior in some other sense, not in Go experience.