undefined | Better HN

0 pointsbheadmaster2y ago0 comments

> And sure, plenty of people will tell if you do it "right" you'll have no issues.

Go is inspired a lot by CSP, and allows you to apply CSP calculus when using goroutines and channels.

It doesn't make it impossible to make mistakes, but it does give you tools needed to reason about your concurrent program, which is more than can be said of most other languages' concurrency support.

0 comments

dontlaugh2y ago

And yet goroutines share the same address space, don’t have a good way for the parent to wait for them and even panic silently.

There’s a reason many projects ban the go keyword in favour of a wrapper that fixes some of this.

Go requires constant vigilance, sadly.

bheadmasterOP2y ago

Yes, as I said, Go doesn't make it impossible to make mistakes. It doesn't hold your hand and slap you when you go off-road.

But saying it "requires constant vigilance" is an overstatement. As long as you put a little bit of thought in the concurrent code you're writing, it's very easy to do things right. Data races are easy to avoid if you only transfer ownership by sending pointers through channels.

dontlaugh2y ago

It would’ve been trivial to make the language disallow nil, separate goroutine address spaces, crash the process on unhandled panic in any goroutine, etc.

The reason Go annoys people is the unforced errors. Sure, it gets a lot right. But what it gets wrong had solutions long before Go existed and those solutions were wilfully ignored.

1 more reply

weakfish2y ago

Can’t the parent wait by simply using the waitgroup sync functionality? That’s what I’ve been doing in my greenfield Go project at work.

dontlaugh2y ago

Sure, but you can neglect to do it or get it wrong. The language could expose primitives that don’t allow it instead.

In practice, where I work we disallow the go keyword in review and require use of a wrapper that takes in a closure and also is a wait group. It’s much harder to get wrong.

j / k navigate · click thread line to collapse

0 pointsbheadmaster2y ago0 comments

> And sure, plenty of people will tell if you do it "right" you'll have no issues.

Go is inspired a lot by CSP, and allows you to apply CSP calculus when using goroutines and channels.

It doesn't make it impossible to make mistakes, but it does give you tools needed to reason about your concurrent program, which is more than can be said of most other languages' concurrency support.

0 comments

dontlaugh2y ago

And yet goroutines share the same address space, don’t have a good way for the parent to wait for them and even panic silently.

There’s a reason many projects ban the go keyword in favour of a wrapper that fixes some of this.

Go requires constant vigilance, sadly.

bheadmasterOP2y ago

Yes, as I said, Go doesn't make it impossible to make mistakes. It doesn't hold your hand and slap you when you go off-road.

dontlaugh2y ago

It would’ve been trivial to make the language disallow nil, separate goroutine address spaces, crash the process on unhandled panic in any goroutine, etc.

The reason Go annoys people is the unforced errors. Sure, it gets a lot right. But what it gets wrong had solutions long before Go existed and those solutions were wilfully ignored.

1 more reply

weakfish2y ago

Can’t the parent wait by simply using the waitgroup sync functionality? That’s what I’ve been doing in my greenfield Go project at work.

dontlaugh2y ago

Sure, but you can neglect to do it or get it wrong. The language could expose primitives that don’t allow it instead.

In practice, where I work we disallow the go keyword in review and require use of a wrapper that takes in a closure and also is a wait group. It’s much harder to get wrong.

j / k navigate · click thread line to collapse