Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Is this maintained? #100

Closed
aaronc opened this issue Jun 29, 2021 · 9 comments
Closed

Is this maintained? #100

aaronc opened this issue Jun 29, 2021 · 9 comments

Comments

@aaronc
Copy link

aaronc commented Jun 29, 2021

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
Copy link

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
Copy link

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

@alexykot
Copy link

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

@bojanz
Copy link

bojanz commented Oct 28, 2021

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
Copy link

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
Copy link
Member

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
Copy link
Author

aaronc commented Jan 31, 2022

@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
Copy link
Member

@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
Copy link
Author

aaronc commented Feb 7, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants