А ну да

Это же канал

Все верно

У него нет индекса

Так вопрос был в том почему у меня валится цикл на 0 элементе слайса

В слайс надо append

А вы как map[int]string добавляете

Понял

Спасибо

в мапе можно resul[i] = ololo, а в слайс надо slice = append(slice, ololo)

var i int var results []string for data := range in { fmt.Println(i) results[i] = data.(string) i++ }

Слайс results не сделан.

У него нет поинтера на какой-нибудь массив.

Я уже понял что фигню сморозил

Что он пустой

Попробуйте или через make, или results []string{}. Поинтер на пустой массив

Так можно было бы делать если бы я создавал массив

Да

Я это понимаю

Затупил)

?

Теперь бы еще с дедлоками разобраться)

Теперь бы еще с дедлоками разобраться)

Если все горутины заблокированы(ждут что-то из канала), то наступает deadlock.

Если все горутины заблокированы(ждут что-то из канала), то наступает deadlock.

Да я знаю

Понять бы почему)

Если все горутины заблокированы(ждут что-то из канала), то наступает deadlock.

А получается если мы закроем канал из которого они ждут, то и они закроются?)

А получается если мы закроем канал из которого они ждут, то и они закроются?)

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

Если тип канал int, то 0, если string, то "".

А как тогда правильно поступать?

Чтобы проверить закрыт канал или нет, можно использовать такую структуру: Value, ok := <- chan int.

Если ok будет false, то значит что канал закрыт

Ааааа

Вот это я затупил

Также, вы можете использовать цикл for each для чтения из канала. Когда канал будет закрыт и в его буфере не будет значений, программа выйдет из цикла.

Также, вы можете использовать цикл for each для чтения из канала. Когда канал будет закрыт и в его буфере не будет значений, программа выйдет из цикла.

Можно пример?

Чтобы проверить закрыт канал или нет, можно использовать такую структуру: Value, ok := <- chan int.

Это получается в бесконечном цикле?

Это получается в бесконечном цикле?

Если я правильно понимаю контекст, то да

С каналами для меня самая сложная тема наверное

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

https://gobyexample.com/range-over-channels

Канал по сути очередь данных. Одни горутины в эту очередь данные закидывают, другие горутины забирают.

https://gobyexample.com/range-over-channels

For each работает до тех пор, пока есть данные в канале и канал не закрыт, после происходит выход из цикла. Если же вы просто берёте данные из закрытого канала, то вам будут возвращаться дефолтные значения.

Посмотри https://gobyexample.com/range-over-channels

Тут пишут что если закрыть канал то и for-range закрыться должен

Посмотри https://gobyexample.com/range-over-channels

Да, он закроется, но только после того как в канале не останется сообщений.

Да, он закроется, но только после того как в канале не останется сообщений.

А мне так и нужно

Тогда используйте foreach

Можно ссылку?

https://m.habr.com/post/308198/

Ну не сказать, чтобы много.

Тогда используйте foreach

foreach?!

Ну не сказать, чтобы много.

Ну для одного файла имхо много

Очень

Или я не правильно понял?

Ну для одного файла имхо много

Монолит это когда у тебя все работает в едином сервисе

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

Там неважно сколько файлов

foreach?!

В чем, собственно, проблема?

Нет такого слова

https://m.habr.com/post/308198/

Как по мне, уровень абстракций в этом коде слишком большой

По крайней мере, я бы такую структуру проекта не выбрал :)

Мне кажется адекватно реализованный 2 подход самое то

Не?

Стиль Rails?

Да

Я говорю за стиль который предлагает автор

ERROR: S client not available

Ну я понял

Вы бы какой выбрали?

Для среднего проекта?

Ни один из перечисленных наверное

Но нечто близкое к Rails подходу

А вот есть пакет который работает с пользователями, другой с записями (например)

И все они требуют подключения к дб

Как передавать конект?

Я не понимаю зачем разбивать на несколько пакетов

Проще использовать общий пакет, допустим, models

Микросервисыыыыы

И в нем иметь бизнес правила

Кажется я понял

И пакет usecases, который в себе содержит бизнес логику и взаимодействует с пакетом models

Я так делаю

Микросервисыыыыы

Сложна

Благодарю

Буду пробовать

Сложна

В тренде)

Ну как-то пока не приходилось использовать

Тренды дело такое

Скоро будем RPC использовать вместо REST

На самом деле - просто

На самом деле - просто

Ну да api делаешь для каждого

И функционал минималистичный

Да

И рыдаешь, когда ты обновил либу, от которой завися 5 сервисов из 7

имхо: микросервисы - это перенос сложности кода в сложность интеграции. т.е. конечный профит не так велик, как многие считают

Конечный профит сложно измерить

Пока монолит жив - он отрицательный

Как помрет - бесконечный

Есть же вполне себе живучие монолиты Это я к тому, что подход надо подбирать исходя из задачи, а не плыть на волне мейнстрима/хайпа