What's Sentry's commitment to Go?

[mattes]

There are a lot of open and valid issues and unmerged PRs dating back as far as 2016. It seems as if @mattrobenolt has too many things on his plate and nobody is officially maintaining this repo:

As for unaddressed PRs and issues, this is really hard for us right now. At the moment, we don't have a dedicated person on our team for raven-go. Go isn't used very heavily on our platform at the moment. I am the only one who even pokes at issues, while I don't write Go for my job anymore. I use it for side projects, but it's not a big part of my day to day anymore.
With that said, there's a reason why PRs sit open and issues unaddressed, because I'm not as comfortable merging them since I don't have the ability to commit the time needed to make sure they're correct and stable because I want to assure what exists does continue to work well.

Nothing majorly blocking for us, but it would be nice to know if Sentry is taking this Go repo seriously and maybe add more contributors that can help?

cc @VladCretu

[kzap]

@dcramer ?

[dcramer]

We've been discussing this internally. We intend to put more formal support into updating the project and bringing it in line with our well supported languages. That said, it's likely we're not going to officially get around to it until at least Q1. There's a few reasons this hasn't been high priority for us:

1. Go hasn't always been great to work with when it comes to things like error handling -- y'all are likely all to familiar with its quirks.
2. A lot of our customers who had used Go showed less interest in Sentry (vs JavaScript users who absolutely understand the need)
3. We don't actually use Go ourselves (our Rust client certainly doesn't exist due to overwhelming use of Rust ;)
4. No one championed the project internally and we're still a small team so often unless someone is going to go out of their way (from their normal work duties) we end up relying on the community

That said, if any of the community does want to help in the mean time we'd be happy to provide guidance. It's also possible we (Sentry the company) could afford to bring in a contractor to get the project up to speed, as we've done that with some others in the past.

[kzap]

#hacktoberfest ? :D

[nicpottier]

For what it's worth we are paid Sentry customers (for five+ years) and though our stack used to be mostly Python, we are using Go more and moae (and enjoying it). So without a few raven shortcomings addressed (mainly around facilitating real tracing through wrapping of errors) it is likely we'd move off onto rollbar or the like before long.

[dcramer]

@nicpottier we're sorry to here that, but it unfortunately doesn't change how we resource things. We're confident in the maturity of Sentry both from a product and technical point of view, and I think you'll find that smaller organizations are even less polished on many of these SDKs, or have a set of their own problems. I'd also encourage your team to see what's really blocking usage of the Go SDK, and see if its something they'd be interested in helping contribute to. It's not something we expect, but it is fully open source after all (and our ingestion API is well documented).

[nicpottier]

Sure sure. Though one would hope that having your paying customers speak up saying this is an important thing to them would eventually affect how you resource things. Just giving you some data, do with it what you will.

Just tweaked what error package we were using to see if we could contribute on the stack trace front, so us submitting some PRs may not be far off. (though having someone manage those PRs is an obvious dependency)

[dcramer]

@nicpottier yep understand -- just want to be transparent about our plans. We do really intend to address Go, but still likely not til Q1 since the team is heads down with some of the other SDKs right now (and building some larger new things that are needed for future SDKs).

[ernestoalejo]

and our ingestion API is well documented

We had problems to send breadcrumbs for example. They aren't really documented anywhere at the API level and we had to reverse engineer the Javascript SDK and the JSON of the events through the Sentry UI to create our own JSON structs to send them from Go.

With a clearer documentation of the expected JSON, and it would be something not specific to Go, it would be much easier to customize the steps we need; e.g. mapping custom errors to the stacktraces that Sentry expects.

We currently use code like this where most of the interfaces are custom to send all the info of the error correctly to Sentry that would otherwise be empty or missing:

    interfaces := []raven.Interface{
      &customException{
        Stacktrace: stacktrace,
        Module:     "backend",
        Value:      appErr.Error(),
        Type:       appErr.Error(),
      },
      &customBreadcrumbs{
        Values: []*customBreadcrumb{
          {
            Timestamp: time.Now(),
            Type:      "default",
            Message:   message,
            Category:  category,
            Level:     level,
          },
        },
      },
      raven.NewHttp(r),
    }

    packet := raven.NewPacket(appErr.Error(), interfaces...)
    packet.AddTags(map[string]string{
      "rpc_service": info.rpcService,
      "rpc_method":  info.rpcMethod,
    })

    eventID, ch := client.Capture(packet, nil)

[ernestoalejo]

Note that I know that this page exists now: https://docs.sentry.io/clientdev/interfaces/breadcrumbs/ ; I wanted to express that having a generic NewPacket + that documentation is a great help for us.

[dcramer]

We're going to try to work with the existing PRs, get those merged, and publish a new version. There's likely some concerns around Go 1.11's release since it changed packaging and that might hold up a few things.

[mattes]

Thank you @dcramer 👍

[dcramer]

FYI I tagged v0.1.0