HN

Comments (47)

• Menu

  lemoncucumber
  It’s great that they identified this (incredibly common) pain point and introduced a way to solve it, but I can’t help being disappointed.Reading the examples I found myself thinking, “that looks like a really useful pattern, I should bookmark this so I can adopt it whenever I write code like that.”The fact that I’m considering bookmarking a blog post about complex boilerplate that I would want to use 100% of the times when it’s applicable is a huge red flag and is exactly why people complain about Go.It feels like you’re constantly fighting the language: having to add error handling boilerplate everywhere and having to pass contexts everywhere (more boilerplate). This is the intersection of those two annoyances so it feels especially annoying (particularly given the nuances/footguns the author describes).They say the point is that Go forces you to handle errors but 99% of the time that means just returning the error after possibly wrapping it. After a decade of writing Go I still don’t have a good rule of thumb for when I should wrap an error with more info or return it as-is.I hope someday they make another attempt at a Go 2.0.
• Menu

  ashishb
  Context cancellation (and it's propagation) is one of the best features in Go.Is there any equivalent in major popular languages like Python, Java, or JS of this?
• can3p
  I think this post needs better examples to show case the issue, because right now the issue is not clear. Ideally you would need an example that uses the context.Cause function, see belowThe contexts and errors communicate information in different directions. Errors let upstream function know what happened within the call, context lets downstream functions know what happened elsewhere in the system. As a consequence there isn't much point to cancel the context and return the error right away if there isn't anybody else listening to it.Also, context can be chained by definition. If you need to be able to cancel the context with a cause or cancel it with a timeout, you can just make two context and use them.Example that shows the approach as well as the specific issue raised by the post: https://go.dev/play/p/rpmqWJFQE05Thanks for the post though! Made me think about contexts usage more
• Menu

  mstipetic
  Golang returning tuples but not having pattern matching is something I'll never get. I really feel it's a too dumbed down version of erlang/elixir, especially with this context passing business
• NeutralForest
  You're kind of building a stack of exceptional cases... Wonder what that is :D
• sethammons
  Le sigh. "I don't wrap errors and so I don't know where my errors come from."The code that justifies the special context handling: if err := chargePayment(ctx, orderID); err != nil { cancel(fmt.Errorf( "order %s: payment failed: %w", orderID, err, )) return err } Why not simply wrap that error with the same information?
• gethly
  Never needed this. Nice to have but won't ever use it.