Conc: Better Structured Concurrency for Go

Re:Conc: Better Structured Concurrency for Go by alexeldeib on Wednesday January 11, 2023 @06:05PM (#34346392)

So you've never written code with a bug? There are other ways to panic in go - concurrent map writes, nil pointer dereference. I'm not saying it should happen, but best practice would be a defensive posture especially when it's effectively zero cost, not hoping for the best.

[ Parent | on HN ]

Re:Conc: Better Structured Concurrency for Go by preseinger on Wednesday January 11, 2023 @06:13PM (#34346462)

Crashing the program _is_ the defensive posture. Panics -- concurrent map writes or nil pointer dereferences or almost anything else -- usually mean the program state has become invalid. You can't treat them like errors.

[ Parent | on HN ]

Re:Conc: Better Structured Concurrency for Go by alexeldeib on Wednesday January 11, 2023 @07:04PM (#34346997)

Taking my own example - you can both monitor for panics per http request, while preserving SLO for other requests server by the same process.

Crashing the program is strictly worse imo, since there are other concurrent requests which will now fail for no reason.

I agree unhandled panicking makes sense sometimes. It’s context dependent.

Program state is a good argument, but I think it really depends.

[ Parent | on HN ]

Re:Conc: Better Structured Concurrency for Go by groestl on Wednesday January 11, 2023 @08:15PM (#34347749)

> usually mean the program state has become invalid.

_some_ part of a program's state has become invalid. Probably a variable on the stack. In web servers, almost always a part that becomes very irrelevant as soon as the current request ends. In databases, the same is true at transaction boundaries. In shells it's the REPL. Exit(1) in any of those deep down the stack? No thank you, wouldn't touch that software with a 10 foot pole.

[ Parent | on HN ]

Re:Conc: Better Structured Concurrency for Go by morelisp on Wednesday January 11, 2023 @06:07PM (#34346409)

> So you've never written code with a bug?

No, I write bugs all the fucking time! That's why I want my code to panic, so I know I wrote a bug. If that shit gets stashed away in a 500 response in a Prometheus metric maybe I'll chance to see it three days later. But if the container gets blown away, I'll notice.

[ Parent | on HN ]

Re:Conc: Better Structured Concurrency for Go by pyth0 on Wednesday January 11, 2023 @07:16PM (#34347123)

If your observability tools aren't firing alarms when that panic happens, you have other problems besides the panic. I would much rather find out about a bug that way vs reports from people that the service is down.

[ Parent | on HN ]