I'm expressing my frustration here somewhat, but why do many new libraries only have asynchronous APIs? For example I'm creating a small utility to fetch a web page and parse some data from it. However, making use of HttpClient from the System.Net.Http namespace in .net core requires a lot of async and await boilerplate code, from this [web page](https://dotnetcoretutorials.com/2018/02/27/loading-parsing-web-page-net-core/) for example:

```
async static Task Main(string[] args)
{
}

```

Then the contents of Main:

```
HttpClient client = new HttpClient();
var response = await client.GetAsync("http://www.nzherald.co.nz/");
var pageContents = await response.Content.ReadAsStringAsync();
Console.WriteLine(pageContents);
Console.ReadLine();

```

I feel that c# has become a very wordy language and I'm not happy to have to code in the async style like this. I have been writing c# programs since .net 1.0, and I find it hard to reason about what is happening behind the scenes of the compiler: is creation of threads for async code going to impact performance? How can I throttle the rate of calls if I'm calling GetAsync in a loop? 

My Question is: has the c# team gone in the right direction creating this async paradigm in the language? I feel that go's approach of creating a thread by just saying `go myfunction()` is less long-winded, but I know it has it's performance penalties due to the green-threads used.

Look at [this question](https://softwareengineering.stackexchange.com/questions/206683/when-is-it-necessary-or-when-should-a-controller-be-async?rq=1) for example, it has the same type of concerns about async, and the single answer isn't very helpful.