А может кто-нибудь объяснить, зачем какой-то стандартный тип заменять своим именем? Всякие type lol int Я могу понять, если его потом расширять какими-то функциями, но когда просто заменяют и все. Красоты и эстетики ради?

нууу, как тебе сказать.. type celsius int type fahrenheit int это одно и тоже или разное? :)

тут нужно почитать про типы (кейворд type) и как это можно использовать при использовании в ООП, например. У меня в свое время отпали почти все вопросы ;)

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

Мне это нравится чисто из эстетических соображений, но прям какой-то вау пользы не вижу

коллеги, вы про какие алиасы?

ну просто от каких-то ошибок тебя компилятор спасет, если будешь пытаться выезжать на типах. например: https://play.golang.org/p/FDpbtTNSJO и в больших проектах это весьма удобно порой ;)

но вот алиасы интов и стрингов - какая-то херня

type siski int func (s *siski) touchThem() { ... }

и в Context рекоммендуется класть ключи алиасного типа, чтобы случайно по именам не пересечься

не думал о навешивании ф-ций на простые типы, интересно

можно поподробнее?

что именно надо развернуть?

какое слово непонятно?

капец, кто-то ночью рассуждает об ООП и его отсутствии в GO это был троллинг или серьёзно?

Из default city? Для кого ночь, а для кого то день ))

Добрый день! Подскажите, пожалуйста, есть функция, которая постоянно получает приходящие через веб-сокеты сообщения. Каналов для сокетов много, и прослушивание каждого из них запущено через горутину, приходящие сообщения пишутся в канал. Возникли следующие вопросы: 1 как правильно захендлить ошибки, которые внутри каждой горутины могут возникнуть? 2. канал для сообщения никогда не закрывается. должен ли я как-то его регулярно очищать, чтобы он не забивался кучей данных?

>а как я сразу узнаю, что в канал пришла ошибка? Использовать отдельный канал для ошибок

а как только из канала что-то присвается переменной, оно извлекается из канала, так сказать? использование вот таких бесконечных циклов в го - нормальная практика?

>использование вот таких бесконечных циклов в го - нормальная практика? цикл будет заблокирован до тех пор, пока не появится сообщений в канале

на самом деле желательно предусматривать отмену горутины с корректным закрытием все ресурсов т.е. юзать например  context.WithCancel

на самом деле желательно предусматривать отмену горутины с корректным закрытием все ресурсов т.е. юзать например  context.WithCancel

на самом деле желательно предусматривать отмену горутины с корректным закрытием все ресурсов т.е. юзать например  context.WithCancel

>использование вот таких бесконечных циклов в го - нормальная практика? хотя, быть может лучше будет сделать for err:= range errChan { ... }

>а зачем для хендлинга ошибок тоже запускать горутину? с горутиной https://play.golang.org/p/z6LUaieMKk без горутины https://play.golang.org/p/w9eOQ6ZnNA

вы тут выше писали, что имеет сложности в работе ) по-моему не мудрено ) >и в Context рекоммендуется класть ключи алиасного типа, чтобы случайно по именам не пересечься о чем тут речь? context.WithValue ? это само по себе антипаттерн