Remove @Beta from com.google.common.util.concurrent.RateLimiter

[zaragozamartin91]

RateLimiter has been around since version 13 and it is stilled marked as @Beta

[jbduncan]

For people waiting for RateLimiter to be made stable, an alternative that looks good is resilience4j, which also has a rate limiter, amongst other utilities for "fault tolerance".

I've never actually used it, so I can't personally vouch for it, but Hystrix, an older library in this space, recommends it in their README at the time of me writing this.

[cpovirk]

Thanks, @jbduncan! We've been wondering if we should recommend that, but we haven't found the time to look into it.

[edit: I also just heard of Failsafe. I am mildly discouraged by the fact that both of these libraries appear to also offer retry functionality that defaults to a fixed delay between tries (rather than randomized exponential backoff), but that doesn't mean their rate limiters are bad.]

[jbduncan]

As a side note, Netflix, the creators of Hystrix, say that they've been using a technique called adaptive concurrency limits instead of Hystrix since around 2018. They have a library for this, but I know even less about it than resilience4j and Hystrix.

[darshitpp]

While resilience4j is indeed a rate limiting alternative, I believe both the RateLimiters are different. Guava's RateLimiter is a blocking call, whereas Resilience4j RateLimiter throws an RequestNotPermitted exception. I found Guava's to be easier to use for my use case.

[olehen]

Another alternative is bucket4j which have the option of using blocking calls if you want. But I agree that it would be nice to have this out of Beta. For my use-case I just need the simple functionality that Guava RateLimiter provides, and I would rather not install another dependecy just for that when I already use Guava.

[beanthemoonman]

Is there any sort of thought on how the Rate Limiter API would change before getting marked as stable? The team I work with has an understandable aversion to including new libraries to our codebase, but Guava is currently a library we use and that's not changing. It'd be great to understand what the risk is to incorporating it into our codebase, because the functionality is very useful.