Why remove sync methods?

[twbaltimore]

I would like to make the recommendation that sync versions of methods be re-introduced into this library. The lack of sync methods forces adopters of this package to invoke the async versions here in a sync over async fashion, such as the following:

var result = cache.GetAsync(key).GetAwaiter().GetResult().ConfigureAwait(false);

The current thread blocks and is idle and potentially another thread is consumed unnecessarily leading to a less efficient, less responsive application/service. It would be better to maintain sync versions of the methods that can continue to be used in synchronous scenarios.

[imperugo]

Hi @twbaltimore
thanks for the feedback.
If you need sync method I think you are using the library on .NET Framework because .NET Core has full complete support of async everywhere and that's absolutely a good thing.

This library has born with few methods on the begging (Get, set and not much else). Right now there are tons of methods and maintaining all of them twice (sync and async version) is a bit expensive for me also no-one before you asked to have sync support (we removed it years ago).

My suggestion is to work on GetAwaiter().GetResult() or migrate to the async version when is possible.

I'm sure you can understand the motivation.
Thanks

[twbaltimore]

Thank you for the response.

Unfortunately, using GetAwaiter().GetResult() is a bit of a hack at best, can still deadlock in some cases. It's also a bad idea for scalability/performance. You're suggesting to your adopters with sync code to write sync over async code as a work around and take on additional load of idle threads, when pure sync would scale better and result in far fewer idle threads in such legacy applications.

Not everyone is in a situation where they can use .Net/.Net Core for all applications/services yet. When we adopted StackExchange.Redis.Extensions years ago, it supported the sync methods that we needed. When you removed them, you essentially put us in a situation where using your library is no longer an option for our legacy applications and services.

Based on your response, we'll need to drop our dependencies on StackExchange.Redis.Extensions.

[imperugo]

Hi @twbaltimore
I partially understand your point, but I'm not going to add sync methods. Right know all the supported version of .NET has the ability to manage async methods natively.
I'm sorry you can't update your project and you have to drop the dependencies of this library, but you are the only one person asked about that and adding this means spending time for your application.

Thanks again