19 ms·

are basic languages good though? the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years; I feel like ma

are basic languages good though? the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years; I feel like many times the same sort of c "i dont make mistakes" programmers are attracted to go and they also don't make mistakes there as well...

bjornjaja 7y ago
The problem creating a language that “anyone can get started with quickly” has the problem that it invites a host of people who have limited idea how concurrency, among other things, works. It’s important to understand C++ for that very reason is historical significance and how a system actually works underneath. I think there’s a general gap in people’s knowledge as a lot of people just clock in but don’t read about stuff beyond what’s required “to get the job done.”
ci5er 7y ago
Oh, come on, that's not fair. After I did a million lines in C (way back when), I still made mistakes (but fewer! still: not none!), but I had built better tooling and processes to help me find them earlier. I was (as you say) attracted to Go, but with less accumulated tooling, the bugs take longer to find (that, and playing around with CSP, I guess, which is my own damn fault).
randomdata 7y ago
> the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go. Perhaps the only reason you find concurrency issues in Go so frequently is because Go is more often used where concurrency is necessary, due to it being more suitable to writing concurrent code compared to many other popular languages? I certainly find more DOM bugs in Javascript than other languages, but I'm not sure that is a reflection of the language, only where the language is most often used.
- kerkeslager 7y ago
  > Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go. Concurrency isn't really that hard in Erlang, and Erlang isn't the only language that handles concurrency well. "Concurrency is hard" is usually paired with an implicit refusal to learn paradigms that make concurrency easier. Why are we only comparing Go to popular languages? When I first came across Go, before it was a popular language, I immediately started criticizing it because of the weak type system and ineffective concurrency model: I wanted the attention being given to Go to be given to a better language. Now I'm seeing the same people saying, "Okay, but the type system and concurrency are better than other popular languages." At face value, it makes sense to compare a popular language to other popular languages, but that logic breaks down because the only reason Go is popular is that a lot of people made the bad decision of choosing it before it was popular.

bjornjaja 7y ago

The problem creating a language that “anyone can get started with quickly” has the problem that it invites a host of people who have limited idea how concurrency, among other things, works. It’s important to understand C++ for that very reason is historical significance and how a system actually works underneath. I think there’s a general gap in people’s knowledge as a lot of people just clock in but don’t read about stuff beyond what’s required “to get the job done.”

ci5er 7y ago

Oh, come on, that's not fair. After I did a million lines in C (way back when), I still made mistakes (but fewer! still: not none!), but I had built better tooling and processes to help me find them earlier. I was (as you say) attracted to Go, but with less accumulated tooling, the bugs take longer to find (that, and playing around with CSP, I guess, which is my own damn fault).

randomdata 7y ago

> the amount of go concurrency bugs I've dealt with has been outstanding and quite brutal over the last few years Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go. Perhaps the only reason you find concurrency issues in Go so frequently is because Go is more often used where concurrency is necessary, due to it being more suitable to writing concurrent code compared to many other popular languages? I certainly find more DOM bugs in Javascript than other languages, but I'm not sure that is a reflection of the language, only where the language is most often used.

kerkeslager 7y ago
> Concurrency is hard. Maybe something like Erlang does it better, but compared the concurrency options in most popular languages, and the bugs that go along with those options, I think I would far rather deal with them in Go. Concurrency isn't really that hard in Erlang, and Erlang isn't the only language that handles concurrency well. "Concurrency is hard" is usually paired with an implicit refusal to learn paradigms that make concurrency easier. Why are we only comparing Go to popular languages? When I first came across Go, before it was a popular language, I immediately started criticizing it because of the weak type system and ineffective concurrency model: I wanted the attention being given to Go to be given to a better language. Now I'm seeing the same people saying, "Okay, but the type system and concurrency are better than other popular languages." At face value, it makes sense to compare a popular language to other popular languages, but that logic breaks down because the only reason Go is popular is that a lot of people made the bad decision of choosing it before it was popular.