За что я не люблю Go

Причем тут это.
Вот скажите, какая разница во времени будет?

using System;
using System.Threading;
using System.Threading.Tasks;

namespace TestSharp
{
    class Program
    {
        static async Task Main(string[] args)
        {
            Console.WriteLine(DateTime.Now.ToString("HH:mm:ss"));

            await Task.Delay(10000);

            Console.WriteLine(DateTime.Now.ToString("HH:mm:ss"));

        }
    }
}

За что я не люблю Go

Вы до сих пор не поняли как await работает? Дока же есть, почитайте.

За что я не люблю Go

Вот вам дока — docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/await

The await operator is applied to a task in an asynchronous method to insert a suspension point in the execution of the method until the awaited task completes.

Все как я и говорил вот тут

await Task.Delay(2000);  // вот тут вы не запустили `Task.Delay` в отдельном потоке, то есть тут вы реально будет ждать
Console.WriteLine($"Work: {await q.Dequeue()}");

За что я не люблю Go

Так зачем вы привели другой код? У вас же в первом варианте `await Task.Delay(2000);` в цикле.

За что я не люблю Go

А чего сейчас у вас нету await в цикле?

За что я не люблю Go

await Task.Delay() не блокирует поток, но вот этот поток, где выполнялся Main, будет выполнять Task.Delay(). Хоть у вас и два асинхронных метода, но они синхронизированы await'ом.
То есть:

await Task.Delay(2000);  // вот тут вы не запустили `Task.Delay` в отдельном потоке, то есть тут вы реально будет ждать
Console.WriteLine($"Work: {await q.Dequeue()}");

Вы же сами доку кидали на это.

К чему готовиться в 2019 году: тренды в программировании

А что такое HW VM?

К чему готовиться в 2019 году: тренды в программировании

Ученный объявили неделю срачей, количество постов про Go увеличилось в два раза.

За что я не люблю Go

await это просто синхронизация двух асинхронных методов — один асинхронный метод (methodA) ждет пока закончится второй асинхронный метод (methodB), при этом, как я понял, methodB будет выполняться в потоке методаА.
То есть это просто делает два асинхронных метода синхронными (между собой). При этом methodA все так же будет асинхронным в отношении вызывающего его метода.

Мысленный эксперимент: Flutter на Go

Но считать, что без дженериков удобней чем с ними — извините, но я не понимаю этого.

Дак вроде никто так не считает, gudvinr говорит как раз про «можно жить без дженериков».

За что я не люблю Go

Уточню — это не флаги, а тэги, флаги вот golang.org/pkg/flag
Сделали так тэги, чтобы вся информация о даном поле был на одной линии, когда грепните поле — вся информация будет сразу же перед вами. Тоже самое во время редактирования — все на одной строке, а не несколько, тяжелее сделать ошибку.
А вот почему это «уродливо» кроме как вашей вкусовщины, я не понял. Тем более не понял, почему это неудобно. Надо аргументировать, а не 10 раз говорить «уродливо».

За что я не люблю Go

В гоу, по сути, ошибки — это просто строка, которая никак статически не типизируется, я не могу увидеть список возможных ошибок и я не могу адекватно обработать определенную ошибку.

Это чисто ваша фантазия, в Go ошибка это интерфейс, потому сама переменная — интерфейсная переменная, которая хранит тип ошибки.
Я соглашусь, сделано не идеально (ну чисто потому что позволяет делать многое с ошибками), но тут уже вы сами решаете, облегчить ли самим себе жизнь и использовать типизированые ошибки и, например, очень удобный пакет github.com/pkg/errors, или использовать throw new Exception("...") errors.New("...")

За что я не люблю Go

Так еще раз — вот в вашем примере, что будет делать handle(error)? Вы же пример привели с обработкой ошибок, вот мне и интересно, что там за обработка и есть ли преимущество у данной обработки. Если там будет просто логирование или возврат, то какое тут преимущество то с такой обработкой.

За что я не люблю Go

Вы так и не ответили на вопрос, написав отсебятины про ошибки в Go (особенно «В Гоу вообще возвращаются, по сути, строковые ошибки, ничего кроме логирования с ними не сделать.»). Про ошибки в Go мы можем поговорить позже.
И все же — как вы определите какой вызов функции (из двух вызовов http.get()) вернул ошибку и как обработаете?

За что я не люблю Go

И какого рода обработка ошибок будет? Как вы определите какая функция вернула ошибку и что потом сделаете?
Пока я не вижу преимуществ такой обработки, как часто бывает в языках с исключениями — один большой try-catch на все случаи (а часто просто с логированием).

Я вот в таких ситуациях делаю обертки с обработкой ошибок (в нем, например, retry, зависит от задачи).

За что я не люблю Go

Это как-то делает то, что в Go становится сложно? Еще раз, разговоров о том, что в Go очень просто и удобно писать конкурентный код (горутины, каналы, контекст).

За что я не люблю Go

напомню что разговор был не про «короче», а про «просто». Я сказал, что очень просто запустить горутину (к этому прицепились сразу) и управлять ее, и взаимодействовать (каналы).

За что я не люблю Go

Я умываю руки, продолжайте и дальше бороться со своими мельницами. Удачи.

За что я не люблю Go

Не надо лукавить! А где запись в канал?

В функциях getData1 и getData2, но даже вы не показали что там внутри.

У этих функций не было такого параметра, это могла быть какая нибудь http.get(), которую нельзя было доработать.

Раз уж вы еще больше выдвигаете требований, можно так:

ch1, ch2 := make(chan string), make(chan string)
go func() { ch1 <- getData1() }()
go func() { ch2 <- getData2() }()
result = foo(<-ch1, <-ch2)

Но сути это не меняет.

За что я не люблю Go

ch1, ch2 := make(chan string), make(chan string)
go getData1(ch1)
go getData2(ch2)
result = foo(<-ch1, <-ch2)