cockroachdb / apd

Arbitrary-precision decimals for Go
https://pkg.go.dev/github.com/cockroachdb/apd/v2
Apache License 2.0
664 stars 36 forks source link

Is this maintained? #100

Closed aaronc closed 2 years ago

aaronc commented 3 years ago

I tried posting an issue a while ago (#98) and haven't heard anything. It seems like apd is still used in cockroachdb in production, which is a good sign but this repo itself doesn't look like it's had a ton of activity recently. So I'm wondering if this has a maintainer assigned, if we can expect anyone to look at issues or potential PRs, etc. We are considering using this library in a critical production code base and if there is no maintainer, we will likely fork or choose a different approach. Thanks 🙏 .

alexykot commented 3 years ago

Same question here. We do already depend on this library in production since 2019, and if this is not maintained - we will have to probably fork it.

sergiu128 commented 2 years ago

Could anyone recommend some alternatives to apd in case it is not maintained anymore?

alexykot commented 2 years ago

We've started migrating to github.com/ericlagergren/decimal.

bojanz commented 2 years ago

Funny enough, I have stayed on apd because ericlagergren/decimal hasn't been maintained. apd's last release is June 2020 with no PRs pending, while ericlagergren/decimal's last release is January 2019, with go mod support still pending.

alexykot commented 2 years ago

We've used ericlagergren/decimal in some performance-constrained use cases, and we've reached out to Eric directly asking to help with performance improvements in his library specific to our use case.

He was happy to help and we were happy to fund relevant open-source development, so it worked out well for us, and we're confident in future support and maintenance of ericlagergren/decimal should we need it.

nvanbenschoten commented 2 years ago

Hi all, apologies for the radio silence on this thread. I don't think there was anyone directly subscribed to notifications on this reposity for a period of time, so it fell through the cracks.

This library is still maintained and is still in active use in CockroachDB. In fact, it just received a series of performance improvements that were included in v3.0.0. We'll do a better job of monitoring the repro going forward.

aaronc commented 2 years ago

@nvanbenschoten great to hear! Excited to see the improvements in v3.

We have been using apd v2 in a few places and are considering adopting it more widely.

We would like to commit to one of these projects (apd or ericlagergren/decimal) and are willing to contribute cash and/or developer time to make sure things are battle-tested and high performance.

Would be great to get some sense from others in this thread where to put resources. ericlagergren's approach and apd seem quite similar in a lot of ways. IMHO it'd be better to have 1 first-class decimal library in go rather than two occasionally-maintained ones.

@nvanbenschoten how much interest/energy does CockroachDB have in engaging with outside contributors on this?

nvanbenschoten commented 2 years ago

@nvanbenschoten how much interest/energy does CockroachDB have in engaging with outside contributors on this?

@aaronc It depends on the focus of the contributions. CockroachDB's primary motivation for this library will be to maintain a decimal implementation to back the NUMERIC data type in our SQL layer. I don't think that will come as much of a surprise. So to the extent that outside contributions are making this library more battle-tested, more correct, and higher performance, we'd absolutely welcome and be interested in engaging with outside contributions.

There are some constraints here, like that CockroachDB attempts to provide a high level of compatibility with PostgreSQL, so we would be hesitant to break compatibility for performance (e.g. limit coefficient precision to eliminate memory indirection in the extreme cases). Beyond that, I think we'd also like this library to continue to adhere to the GDA specification without it accumulating much additional complexity or surface area on top of that.

So with all that said, what kind of contributions did you have in mind?

aaronc commented 2 years ago

Correctness is our biggest concern. Things must be as battle tested as possible. Performance is also important obviously but within the bounds of a safe, correct algorithm.