What is broken about the go error type? If anything the fact that it is a simple interface makes the `try` syntax sugar more doable – right?

Let's say you have this:

``` part, err := doSomething() if err != nil { return nil, err }

data, err := somethingElse(part) if err != nil { return nil, err }

return data, nil ```

Then as long as your function followed the contract 0+ returns and then 1 `error` return, that could absolutely be turned into just the 0+ returns and auto-return error.

The fact that the `Error` interface is easy to match and extend, plus the common pattern of adding an error as the last return makes this possible.

What am I missing here?

> What is broken about the go error type?

There's not much broken with the error type itself, but the "real" problem is that the Go team decided not to change the way errors are handled, so it becomes a question of error handling ergonomics.

The article doesn't have a clear focus unfortunately, and I think it's written by an LLM. So I think it's more useful to read the struggles on the Go team's article

https://go.dev/blog/error-syntax

This means you can't pass variables in as function arguments. Even the example in the official go docs doesn't handle the scope correctly:

  func main() {
   var wg sync.WaitGroup
   var urls = []string{
    "http://www.golang.org/",
    "http://www.google.com/",
    "http://www.example.com/",
   }
   for _, url := range urls {
    // Launch a goroutine to fetch the URL.
    wg.Go(func() {
     // Fetch the URL.
     http.Get(url)
    })
   }
   // Wait for all HTTP fetches to complete.
   wg.Wait()
  }

https://pkg.go.dev/sync#example-WaitGroup

You need to use this pattern instead:

   for _, url := range urls {
    url := url
    // ...

This isn’t necessary anymore as of Go 1.22

https://go.dev/blog/loopvar-preview

> This means you can't pass variables in as function arguments.

Well, you could...

    for _, url := range urls {
        wg.Go(func(u string) func() {
            return func() {
                http.Get(u)
            }
        }(url))
    }

> You need to use this pattern instead

Why? Seems rather redundant. It is not like WaitGroup.Go exists in earlier versions.

I would love to -- I'm planning to start with something on the smaller side as a PoC.

Delve into the world of Rust development with this blog post on creating a custom URL shortener, complete with tech stack analysis, middleware integration, and load testing.