To "Async suffix" or not to "Async suffix"?

[Kaarel]

When reading the V2 announcement post (https://nats.io/blog/nats-dotnet-v2-alpha-release/) it was pleasing to see how nice clean the example code looks. It also caught my eye that Async suffix is being used everywhere. So I am wondering is this still necessary this day and age with a completely new greenfield library that is designed with "async all the way" philosophy and lacking accompanying synchronous method overloads (https://github.com/nats-io/nats.net.v2/blob/main/src/NATS.Client.Core/INatsConnection.cs) and given the support from compilers, IDEs, unit tests etc.

The .NET framework and legacy code bases have unavoidable historical reasons to apply an "Async" suffix to async methods. This topic has been discussed in other parts of the internets, see previous discussion of various pros and cons:

• https://stackoverflow.com/questions/15951774/does-the-use-of-the-async-suffix-in-a-method-name-depend-on-whether-the-async
• Async suffix dotnet/runtime#26908
• Don't add Async suffix when making method async dotnet/roslyn#47592

An example of a notable messaging library dropping the suffix https://docs.particular.net/nservicebus/upgrades/5to6/async-suffix

[mtmk]

In my personal opinion we should keep the Async suffix. From a technical perspective (hopefully without being out of my depth too much), let's face it, although async/await is a game changing language feature, it is an afterthought and it has its limitations, mainly in terms of compiler being able to detect and stop certain types of errors. Async/await style programming still requires quite a lot of attention from the developer. One can probably get away without understanding it much and still write useful programs. But, when handling exceptions, avoiding deadlocks, eliding for efficiency, avoiding thread-pool exhaustion and so on, developers need to understand that compiler will generate code that may have huge consequences on runtime behaviour potentially causing horrible bugs if not used as prescribed. On the other hand, from more of a practical perspective, I think runtime libraries should lead the way to keep a consistent developer experience across the board. So, although it may have started as avoiding clashing overloads in the old .NET Framework days, in my opinion, in a library, keeping this hint in method names is still very helpful and less confusing for the end developers, consistent with the .NET platform and worth the sacrifice of noisy API, at least until there is a larger consensus and more clear direction from the core .NET teams.

[Kaarel]

The reason I even started to think about this is I've been doing a lot of JavaScript/TS backend development in the last few years. And noticed that I don't miss the suffix there. Not once have I thought "if only this function had an Async suffix" :) Even though the code is usually a fair mix on sync and async function calls and the IDE / tooling support isn't as good as what I'm used to in the C# land.

But the two ecosystems have a very different history and I agree there is value in being consistent with the rest of the world. Though the world ain't gonna change if we don't change it :) I'm so used to jumping between C# and JavaScript I don't feel the need for the suffix, it's just 5 unnecessary chars to me every time I use an async method. But I don't feel too strongly either way. After all naming things is where the complexity lies in software design :)

Just wanted to make sure, as this is a completely new undertaking, that the Async suffix was a design choice.