Читабельность падает существенно

она наоборот увеличивается за счет абстракции

Пусть так. Почему это проблема?

почему деградация - проблема? сложный вопрос

Чувак не видел дженериков кроме темплейтов цпп и теперь думает, что везде дженерики такие.

Генерики я видел в яве. Темплейты - это другого уровня инструмент

она наоборот увеличивается за счет абстракции

Нет

Нет

аргументированно :)

Генерики я видел в яве. Темплейты - это другого уровня инструмент

Не многим лучше, нормальные дженерики в ML'ах и русте.

Нет

Да.

Нет

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

Так тупо, в го постоянно, чтобы понять что делает код мне приходится читать простыни с if err != nil через строчку, в каком нибудь русте обычно хватает сигнатур и автоматически сгенеренной доки. И это при том, что на го мне приходится писать на порядок больше.

почему деградация - проблема? сложный вопрос

Кто вас неволит?

аргументированно :)

А в том, на что я ответил - больше аргументации?

(а на моё обилие аргументации ответите? t.me/proGO/146092 t.me/proGO/146094 t.me/proGO/146107 )

она наоборот увеличивается за счет абстракции

https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ Аргумент из 2001 года.

(там даже не упоминаются дженерики)

у него есть ещё и такая статья (с жирным намёком на дженерики; upd: не только намёком, но даже явным словосочетанием "you might want to abstract it into a generic function" ) https://www.joelonsoftware.com/2006/08/01/can-your-programming-language-do-this/

https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/ Аргумент из 2001 года.

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

Ты и тут свои гифки постишь, давай новые.

Давайте за обсуждение дженериков и эксепшнов выдавать readonly на пару дней? Чат забит этим флудом всё то время, что он существует. Для этого есть специальный @goflood чат.

Давайте за обсуждение дженериков и эксепшнов выдавать readonly на пару дней? Чат забит этим флудом всё то время, что он существует. Для этого есть специальный @goflood чат.

какое то странное сообщение. уходить в другое место от такой насыщенной темы, которая относиться к сабжу - понял! Вы просто спамер и рекламируете другой чат! кхх)

Давайте за обсуждение дженериков и эксепшнов выдавать readonly на пару дней? Чат забит этим флудом всё то время, что он существует. Для этого есть специальный @goflood чат.

Давайте за предложение "давать read only" давать write only

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

Плохой аргумент. Генерализованным быват только тривиальный, там нечего править

Плохой аргумент. Генерализованным быват только тривиальный, там нечего править

не очень понял вас, если честно

не очень понял вас, если честно

Ну типа обобщёнными могут быть только очень простые алгоритмы, в которых тупо нечего исправлять

но... как же...

в общем, ответ "там нечего править" ещё хуже предыдущих аргументов "за" дженерики

Плохой аргумент. Генерализованным быват только тривиальный, там нечего править

А если учесть, что существует жизнь за пределами микросервисов?

Плохой аргумент. Генерализованным быват только тривиальный, там нечего править

Вот скажи, каналы настолько тривиальны, что там нечего править? Если нет, то почему они "генерализованны"?

коллеги, вы очень смешные. в go нет генериков, и их нет по вполне ясным соображениям. кой толк тут рассуждать о том, какие они прекрасные, генерики... да, генерализованный код - тривиальный, и да, код каналов тривиален тоже. там есть подвязки на стек и шедулер, и они немного разбавляют скуку, но в принципе - там слайс и три мутекса. написать канал можно примерно за час, и будет в нем сотня строк. рассуждать о том, как сильно генерики повышают читабельность кода - ну, такое... если с первого взгляда на код нельзя сказать, в каком каталоге надо искать имплементацию - это читаемость не повышает, совсем не повышает. отдельно, конечно, прекрасны отсылки к rust и meta language. если он прекрасны - пишите на них, никто же не неволит вас писать на go. ах, вакансий нет? ну извините...

коллеги, вы очень смешные. в go нет генериков, и их нет по вполне ясным соображениям. кой толк тут рассуждать о том, какие они прекрасные, генерики... да, генерализованный код - тривиальный, и да, код каналов тривиален тоже. там есть подвязки на стек и шедулер, и они немного разбавляют скуку, но в принципе - там слайс и три мутекса. написать канал можно примерно за час, и будет в нем сотня строк. рассуждать о том, как сильно генерики повышают читабельность кода - ну, такое... если с первого взгляда на код нельзя сказать, в каком каталоге надо искать имплементацию - это читаемость не повышает, совсем не повышает. отдельно, конечно, прекрасны отсылки к rust и meta language. если он прекрасны - пишите на них, никто же не неволит вас писать на go. ах, вакансий нет? ну извините...

Как именно интерфейс дает знание в каком каталоге нужно искать имплементацию?

коллеги, вы очень смешные. в go нет генериков, и их нет по вполне ясным соображениям. кой толк тут рассуждать о том, какие они прекрасные, генерики... да, генерализованный код - тривиальный, и да, код каналов тривиален тоже. там есть подвязки на стек и шедулер, и они немного разбавляют скуку, но в принципе - там слайс и три мутекса. написать канал можно примерно за час, и будет в нем сотня строк. рассуждать о том, как сильно генерики повышают читабельность кода - ну, такое... если с первого взгляда на код нельзя сказать, в каком каталоге надо искать имплементацию - это читаемость не повышает, совсем не повышает. отдельно, конечно, прекрасны отсылки к rust и meta language. если он прекрасны - пишите на них, никто же не неволит вас писать на go. ах, вакансий нет? ну извините...

Вот вы пишете тираду о генериках. > если с первого взгляда на код нельзя сказать, в каком каталоге надо искать имплементацию Но при чём тут интерфейсы?

Я просто оставлю это здесь

А ведь вначале

Мы начали

Из фразы про изучений С

Толпы леммингов теперь эту картинку будут пихать везде и повсюду

Как первого яп

Толпы леммингов теперь эту картинку будут пихать везде и повсюду

А более упоротые и многочисленные толпы будут продолжать заниматься отрицаловом очевидного

Как именно интерфейс дает знание в каком каталоге нужно искать имплементацию?

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

ещё как повышают

а ещё писабельность тоже

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

У вас очень странное понимание читабельности кода

я понял, у вас альтернативное представление о читабельности

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

Точно так же как и генерики. Вопрос: если генерики не нужны, зачем в го структуры основанные на генериках? Почему map и channel не реализовали на интерфейсах?

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

правильно я понимаю, что make(whatever) вам не нравится так же, как и мне? (очень не нравится)

правильно я понимаю, что make(whatever) вам не нравится так же, как и мне? (очень не нравится)

Может, даже сильнее.

я понял, у вас альтернативное представление о читабельности

Читабельный код в вакууме, это когда ты можешь прочитать какой-то кусок кода и понять, что он делает без того, чтобы идти вглубь по символам. При этом на читабельность влияют такие факторы как краткость, информативность и понятность. Код Го и вправду частно очень понятный код, но он сильно проседает по части краткости и информативности. Гошного кода приходится читать много, названия функций и методов в го часто малоинформативны из-за отсутствия обобщённых интерфейсов.

Точно так же как и генерики. Вопрос: если генерики не нужны, зачем в го структуры основанные на генериках? Почему map и channel не реализовали на интерфейсах?

Потому, что авторы думают, что гранаты можно выдавать людям - им - но нельзя обезьянам - нам

Но и понятность Го теряется тогда, когда начинаются пляски с interface{} и прочими рефлексиями.

А пляски эти часто начинаются именно из-за отсутствия генериков.

А у меня применение пустого интерфейса не пролезет сквозь ревью

Потому, что авторы думают, что гранаты можно выдавать людям - им - но нельзя обезьянам - нам

Хорошее самомнение, интересное.

А у меня применение пустого интерфейса не пролезет сквозь ревью

marshal/unmarshal?

А?!

А у меня применение пустого интерфейса не пролезет сквозь ревью

Обеспечение безопасности с помощью кодревью... Где-то (в С++) мы это уже видели и это не работает

А?!

кастомный marshal у вас не пройдёт ревью?

Хорошее самомнение, интересное.

у всех такое б было как у данилы и хорошо бы было. а то каждый мнит себя человеком, которому можно доверить гранату.

А у меня применение пустого интерфейса не пролезет сквозь ревью

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

Кастомный маршал с пустым интерфейсом? Нет

Кастомный маршал с пустым интерфейсом? Нет

а можно сделать кастомный marshal+unmarshal без interface{}? через strings.Split?

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

Нет таких мест, где это было бы необходимо

ERROR: S client not available

а можно сделать кастомный marshal+unmarshal без interface{}? через strings.Split?

Конечно.

пример срочно

Нет таких мест, где это было бы необходимо

То есть у вас в коде не существует мест, где вы ожидаете значение одного из конечного числа типов?

Доку почитайте. В районе интерфейса Marshaler

То есть у вас в коде не существует мест, где вы ожидаете значение одного из конечного числа типов?

Только на стыке с внешней либой

Только на стыке с внешней либой

Ну то есть существуют такие места.

Подскажите, не могу решить, уже не знаю что придумать. На AJAX приходит ответ json, в одном из массива лежит строка с названием функции с её параметрами. Как можно из вызвать?

Подскажите, не могу решить, уже не знаю что придумать. На AJAX приходит ответ json, в одном из массива лежит строка с названием функции с её параметрами. Как можно из вызвать?

switch case, либо сложить функции в мапу

(PS: там дальше reflect через каждое слово, это лучше, чем interface{} ?)

switch case, либо сложить функции в мапу

Свитч при этом читабельней

(PS: там дальше reflect через каждое слово, это лучше, чем interface{} ?)

Вам часто на ревью stdlib приходит?

но вы же сами предложили посмотреть

Я предложил посмотреть, как своему типу приписать кастомный (un)marshaler

В районе 100 для интов поиск был быстрее

кстати интересно а как внутрях работает итерация по мапе. не будет for _, v:=range mapa { if v.id == id {} } быстрее чем mapa[id]

кстати интересно а как внутрях работает итерация по мапе. не будет for _, v:=range mapa { if v.id == id {} } быстрее чем mapa[id]

Первое безопасней как минимум.

не понял

впрочем я предпочитаю: if e, ok := mapa[id]; ok { }

а. ну проверку на присутствие это понятно.

Как пхпшнику мне кажется что ваш код полное дерьмо

а то что отсутствие асинхронности, CGI, интерпретируемость языка, его runtime и прочее жрут лишние ресурсы вам не кажется?

товарищи, как бесконечно залупить массив? подскажите плз

товарищи, как бесконечно залупить массив? подскажите плз

for { if i == len(array) { i = 0 } }

for { if i == len(array) { i = 0 } }

вот только хотел написать - проверять на каждой итерации счётчик а не последний ли это индекс - как-то не комильфо. Элементов много, а полезная ситуация - одна. Есть какой то более эффективный способ?

тип Type тоже экспоррируется, ничего не понимаю

вот только хотел написать - проверять на каждой итерации счётчик а не последний ли это индекс - как-то не комильфо. Элементов много, а полезная ситуация - одна. Есть какой то более эффективный способ?

если ты представляешь, как в памяти выглядит ring buffer, то никак

если ты представляешь, как в памяти выглядит ring buffer, то никак

а если не представляю? то как? )))

узнать, и понять, почему в го из коробки так нельзя