Eduard Edison

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

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

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

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

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

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

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

Ну да, тред работает, только остальные горутины остались в пролете. Бесконечный цикл скорее всего исключение, но вот долгое выполнение вполне реально может случиться. Пользователю то пофиг, тред твой тормознулся или занят непонятной херней, ему главное чтобы сайт не тормозил, а вместо этого получит 503.

Да я откуда знаю, может есть еще и другие способы. Тем не менее, это работает не так как написал qrKot. Это не плохо и не хорошо, это примерно также как и у других.

Вы так говорите, как будто это уникальная фича go, да у всех асинхронных серверов так. Понятно что в старых языках типа Java остались синхронные апи для I/O, ну сам себе буратино что используешь их в асинхронном методе. Ну кстати не всегда и требуется переписывать на асинхрон, я как-то переписал консольную утилиту и она стала медленнее работать, накладных расходов потому что стало больше чем полезного кода.

В реальном мире да, когда в той же Java на ожидание ответа системного вызова блокируется весь поток.

Чуда не произошло в вашем чудном примере.

UPD: "поставить колом целиком поток" не тоже самое, что поток будет исполняться. Поставить колом — это блокировать, например.

А чего вы хотите увидеть? Я пока вас не понимаю.
В Go кооперативный (почти) планировщик, планирует goroutine по доступным тредам — у вас 8 goroutine не блокируются, не делают системных вызовов, просто инкрементят счетчик, всегда в running состоянии.

Только вот в реально мире такого не будет. Вот добавьте всего одну строчку (fmt.Println(t) в цикле функции test) и у вас совсем другой результат.

func main() {
    for i := 1; i < 100500; i++ {
        go test(0)
    }
    time.Sleep(1)
    go fmt.Println("main 1")
    fmt.Println("main 2")
}

func test(t int) {
    fmt.Println("start")
    for true {
        t = t + 1
        fmt.Println(t)
    }
    fmt.Println("stop")
}

А зачем вы добавили runtime.GOMAXPROCS(1)?

То что в го есть только корпоративная многозадачность

В Go не совсем кооперативный планировщик (https://github.com/golang/go/issues/10958), а еще есть предложение — https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md

Но не думаю что будут менять радикально что-то.

1. Не знаю что там в C#, говорю как удобно в Go (опять же начались примеры в стиле "а вот в X языке точно такая же фича"). Ну и даже краткость записи — уже ведь лучше, да? Ведь тут все хейтят Go с if err != nil. В вашем примере мне не понятно, что такое Task, это ваш класс или со стандартной библиотеки?

   
   

2. Можно сделать все что угодно, только вот в Go это часть стандартной библиотеки (как и пакеты context и sync для управления goroutine).

   
   

В сумме все это очень упрощает написания конкурентного кода.

Связка tokio+futures-await так же удобны в использование как горутины.

Прям вот точно также удобны?
Удобство goroutine в том, что их просто стартануть (go перед любой функцией/методом) и то, что есть каналы для их взаимодействия. В Rust тоже есть каналы?

Я уже почти 4 года программирую на Go: мне не нужно генерировать шаблонный, мне не нужны дженерики, уже давно есть удобный пакетный менеджер (сейчас еще модули завезли), компилятор очень сильно помогает (зависит с чем сравнивать, да?). В основном я пишу/писал web сервисы (нагрузка от 30к до 400к RPS), стрим процессинг с Kafka, тулзы для Kubernetes, etc.
Мне нравится Go, мне нравится вот это if err != nil, после Java я совсем по другому начал относится с ошибкам.

И я совсем не понимаю, почему пользователи Хабра в каждом посте про Go начинают бегать туда-сюда с криками насколько Go ужасный язык, при этом 80% из них на Go не программируют. Начинают сравнивать отдельные фичи Go с фичами других языков — а вот в Х яызке это лучше, а вот в Y языке другое лучше:
— Но я использую Go, мне нравится X фича и для моих задач Go подходит идеально. Тем более у нас есть опыт на Go.
— Ты не понял, Go говно, там if err != nil, вот тебе Rust/C++/Haskell/JavaScript там еще лучше. Монад ведь нету в Go? Воот, ерунда ваш Go.

В каждом посте овер 200 комментов, больше половины из которых вот такие бессмысленные срачи.

fn call<F>(a: i64, _b: i64, c: F) -> i64
where
    F: Fn(i64) -> i64,
{
    c(a)
}

fn main() {
    let example_fn = |a| a;
    println!("{}", call(10, 10, example_fn));

    println!("{}", example_fn(String::from("hello"))); // ошибка
}

В примере выше вывод типа происходит у аргумента замыкания. В примере с функцией call, так же вывод типа происходит у аргумента замыкания за счёт того, что в сигнатуре функции явно указан тип аргумента замыкания.

Можете дать ссылку на документацию?

Потому что в примере:

let example_fn: &Fn(String) -> String = &|a| a;
println!("{}", example_fn("Hello, world!".into()));

Вы же указали тип функции и тип аргумента функции, вот же он &Fn(String). Функция example_fn ждет первым аргументом String. Если там не String — то ошибка компиляции.

Ваш изначальный пример — это свойства анонимных функций, а не вывод типа анонимной функции из сигнатуры.

Тип анонимных функций определяется при первом использовании. Потому, если я все правильно понял.
Вот у вас функция: println!("{}", call(10, 10, |a, b| a + b));, а вот тут первое использование — c(a, b).
a и b имеют тип i64, потому у этой анонимной функции будет тип Fn(i64, i64) -> i64, а не потому что в сигнатуре where F: Fn(i64, i64) -> i64.

let example_fn = |a| a;
println!("{}", example_fn(String::from("Yo"))) // вот тут уже будет тип Fn(String) -> String

let example_fn2 = |a| a;
println!("{}", example_fn(2)) // вот тут уже будет тип Fn(i64) -> i64

Отсутствие зависимостей всегда лучше их наличия и ansible тут не панацея.

1. Тулзе А нужна 2.2 версия, а тулзе Б 3.1. Блин, надо virtualenv настраивать?
2. Потом pip или yum — чем мы там python зависимости ставим? А уже везде дефолтная версия python3? Ахх, тут на 100 серверах yum'ом установили, а на другой сотне pip'ом.
3. Блин, ansible yum модуль поставил библитеку libA-2.3.0 хотя я явно же написал поставить libA-1.9.0 (ох state: latest игнорит версию в названии пакет).
4. Блин, OS команда не дает нам root (не доверяют), а мне надо бы новую зависимость установить, опять virtualenv настраивать, а как же с C зависимостями?

И так далее.

Преимущество есть и оно большое (может быть конечно не "невообразимое").

Я пытался провернуть такое с traefik, но схема собери и запусти не работает без настроенного рабочего окружения с этими всеми GOPATH и прочим.

А, кстати, как, если дженериков или рефлексии (что рантайм, что компилтайм) нет?

encoding/json использует рефлексию.

В моем случае это был Azure. Там проблем бтв тоже не было.

А это уже зона ответственности PaaS-платформы, которой вы пользуетесь.

В дотнете риск существует только при обновлении.

Предлагаете делать кластер просто чтобы конфиги перегружать?