Извини, чувак, но это называется карьерный рост. Код могут писать и более дешевые люди.
Но есть и обратная сторона медали, ты действительно можешь отказаться это делать, но тогда, как и уже много раз сказали, тебе придется что-то отдать взамен, и обычно это деньги :)
И раз уже привели такие глупенькие примеры, задайте себе вопрос: а разве задача вам уже не прилетела? Разве инженер проектируя мост не проектирует его по полученому заказу? Разве художник рисует рисунок на пачке хлопьев не по уже полученому договору? Или сперва делается мост а потом инженер бегает и продает его? Где подвох?
1. Вы хотите помочь пересесть другу с ватсапа на телеграмм
2. Вы даете ссылку другу на скачивание клиента для «какая-то платформа»
3. Он, кликая на Вашу ссылку, открывает ее в телеграмм клиенте? О.о который, предполагается, должен был скачивать
Проблема существует (на сколько я понял из статьи) для людей у которых клиент уже установлен
Современные иде позволяют указывать много брекпоинтов, и их можно указывать не только в одном месте а раскидать по коду чтоб попасть непосредственно в проблемное место, а не гадать почему ошибка и в какой из 100500 строк она обьявилась
Из 4-х вариантов вы выбрали 2 с наименьшим количеством вакансий и все? У оставшихся вариантов вакансий значительно больше чем на го, по сравнению с го вас просто завалят работой, если что.
в первом примере вы забыли что анмаршал ошибку возвращает и это важный момент, пример мне не нравится, разница в пару символов не влияет на «это же короче писать», а читабельность не улучшается, ибо текущий вариант очень понятный сходу.
А второй вариант уже успешно работает, такое можно сделать (да, рефлексия или кодогенерация увы, знаю что у всех аллергия на эти слова).
Второй вариант лучше, но вот проблема, вам ведь контекст нужен будет все равно? А если данные не жсон? Опять же пример ради примера, просто потому что вы работаете конкретно с жсон и лично вам было бы удобней так.
Да, в го хватает копипасты, кое где дженерики ее уберут, но этих мест будет очень мало. Меня больше пугает что их начнут использовать везде, там где надо, там где не надо или просто потому что могут, и это модно стильно молодежно. Новая фича и ее обязательно нужно сунуть везде где ни попадя. И в итоге боли будет больше чем пользы.
Вот пропозал с ошибками отменили а дженерики добавить собираются.
Нет, мне ни разу не понадобилась функция keys. Я редко работаю с мапами, в основном структуры. Я стараюсь писать код так чтоб не было неоднозначности, без пустых интерфейсов и милиона разных типов, если мне надо работать с int и int64 я выберу int64 для обоих вариантов итд. Да, я понимаю что дженерики кое где упростят жизнь, я пришел в го из TypeScript так что о дженериках не по наслышке знаю, но в го мне они, внезапно, перестали быть нужны. Ибо в 99% я точно знаю с чем работаю, либо у меня интерфейс который делает только то что умеет и больше мне от него ничего не нужно.
зы: нет, не махонькие, к слову.
Так говоришь как буд-то твой проект только и делает что фильтрует то да се, а затем делает мап/редьюс и после этого добавляет в массив результат который снова надо фильтровать и поехали заново по кругу. Я выше написал и лично я не могу вспомнить где мне реально понадобилась функция которая заменяет 3 строки кода. В го обработка ошибок только занимает 3 строки кода и делается через каждые 5 минут, это никого не волнует, а написать пару раз фильтр на 3 строки за проект это ужасно много и надо обязательно вынести в функцию в пакет, и сделать универсальной ради пары раз использований.
Сколько у вас в текущем проекте функций filter? Я согласен с дублированием и уже взял свои слова назад. Мне просто интересно на сколько часто вам нужна такая функция. Я просто ща подумал что за последние 4 года мне такая функция понадобилась от силы раз 5, это я беру в учет 4 последние проекта. Мап/редьюс и того меньше. И все эти 4 раза работали с парочкой типов данных от силы.
Может я со своей колокольни по незнанию так сопротивляюсь, а в других местах они часто используются.
А еще можно просто цикл написать, там всего 3 строки, вместо того чтоб делать функцию которая понадобится от силы 3 раза, добавить ее в какой-то пакет непонятный (привет «utils») про который успешно забудет кто-то в большом проекте и возможно будет две одинаковые функции которые делают одно и то же 3 раза в лучшем случае.
Мое «в идеале» выглядит так же как и бесполезная функция «ради дженериков», но ваш код хоть работать будет в отличии от моего )
Нет, не строку, я хотел отдать туда массив интерфейсов.
Но дело взяло неожиданный поворот.
Беру свои слова, ибо я в очередной раз вспомнил про одну особенность в го, которую я успешно про*бал когда с вами общался.
В идеале все должно было выглядеть так: play.golang.org/p/yG5SP2NaHXR но дело в том что го работает с массивами интерфейсов через одно место, и в итоге то что я говорил не будет работать. :)
«it.a == 2» — вот эта строка будет копироваться для каждого типа с которым я работаю. Можно ли считать функцию которая принимает что-то попадающее под сигнатуру и работает с ним вне зависимости от типа универсальной?
Это вы ждете что я напишу для каждого типа реализацию и вы скажете «ага, я же говорил, а теперь еще тип добавьте и будет копипаст», да, так и будет. и?
И вот теперь главный вопрос: а почему ж вы пытаетесь все это затащить в го? Вы ж пишете на ТС или С#?
в го вот этот кусок it => it.a == 2 уйдет в реализацию интерфейса для типа с которым работаешь. Интерфейс с одним методом который фильтрует по полю.
Я ща прям предвижу ответ «но мне же надо 100500 разных типов так фильтровать» или «но мне же надо 100500 разных фильтров». И сразу отвечу, нет, это вы ща синтетику пытаетесь пропихнуть чтоб показать как в го это сильно сложней делается. И я не говорю что в го это супер элементарно и просто. Другое дело что в реальном коде я такого почему-то не встречал, странно правда? Или у вас реально приходят 100500 разных данных в фильтр и вы используете 100500 разных фильтрах на этих данных? Я даже на тс до такого не дохожу.
Не надо делать из го шарпы, пишите на шарпе. в большинстве случаев вы такой код пишете только на хабре чтоб что-то кому-то доказать.
И в итоге нет, 20 символов не проблема, и вам не нужно «для всех» типов писать эти 20 символов, не надо глобализацию устраивать, вы прекрасно знаете что «для всех» ничего не нужно делать.
Но есть и обратная сторона медали, ты действительно можешь отказаться это делать, но тогда, как и уже много раз сказали, тебе придется что-то отдать взамен, и обычно это деньги :)
И раз уже привели такие глупенькие примеры, задайте себе вопрос: а разве задача вам уже не прилетела? Разве инженер проектируя мост не проектирует его по полученому заказу? Разве художник рисует рисунок на пачке хлопьев не по уже полученому договору? Или сперва делается мост а потом инженер бегает и продает его? Где подвох?
2. Вы даете ссылку другу на скачивание клиента для «какая-то платформа»
3. Он, кликая на Вашу ссылку, открывает ее в телеграмм клиенте? О.о который, предполагается, должен был скачивать
Проблема существует (на сколько я понял из статьи) для людей у которых клиент уже установлен
А второй вариант уже успешно работает, такое можно сделать (да, рефлексия или кодогенерация увы, знаю что у всех аллергия на эти слова).
Второй вариант лучше, но вот проблема, вам ведь контекст нужен будет все равно? А если данные не жсон? Опять же пример ради примера, просто потому что вы работаете конкретно с жсон и лично вам было бы удобней так.
Да, в го хватает копипасты, кое где дженерики ее уберут, но этих мест будет очень мало. Меня больше пугает что их начнут использовать везде, там где надо, там где не надо или просто потому что могут, и это модно стильно молодежно. Новая фича и ее обязательно нужно сунуть везде где ни попадя. И в итоге боли будет больше чем пользы.
Нет, мне ни разу не понадобилась функция keys. Я редко работаю с мапами, в основном структуры. Я стараюсь писать код так чтоб не было неоднозначности, без пустых интерфейсов и милиона разных типов, если мне надо работать с int и int64 я выберу int64 для обоих вариантов итд. Да, я понимаю что дженерики кое где упростят жизнь, я пришел в го из TypeScript так что о дженериках не по наслышке знаю, но в го мне они, внезапно, перестали быть нужны. Ибо в 99% я точно знаю с чем работаю, либо у меня интерфейс который делает только то что умеет и больше мне от него ничего не нужно.
зы: нет, не махонькие, к слову.
Может я со своей колокольни по незнанию так сопротивляюсь, а в других местах они часто используются.
Мое «в идеале» выглядит так же как и бесполезная функция «ради дженериков», но ваш код хоть работать будет в отличии от моего )
Но дело взяло неожиданный поворот.
Беру свои слова, ибо я в очередной раз вспомнил про одну особенность в го, которую я успешно про*бал когда с вами общался.
В идеале все должно было выглядеть так: play.golang.org/p/yG5SP2NaHXR но дело в том что го работает с массивами интерфейсов через одно место, и в итоге то что я говорил не будет работать. :)
в го вот этот кусок it => it.a == 2 уйдет в реализацию интерфейса для типа с которым работаешь. Интерфейс с одним методом который фильтрует по полю.
Я ща прям предвижу ответ «но мне же надо 100500 разных типов так фильтровать» или «но мне же надо 100500 разных фильтров». И сразу отвечу, нет, это вы ща синтетику пытаетесь пропихнуть чтоб показать как в го это сильно сложней делается. И я не говорю что в го это супер элементарно и просто. Другое дело что в реальном коде я такого почему-то не встречал, странно правда? Или у вас реально приходят 100500 разных данных в фильтр и вы используете 100500 разных фильтрах на этих данных? Я даже на тс до такого не дохожу.
Не надо делать из го шарпы, пишите на шарпе. в большинстве случаев вы такой код пишете только на хабре чтоб что-то кому-то доказать.
И в итоге нет, 20 символов не проблема, и вам не нужно «для всех» типов писать эти 20 символов, не надо глобализацию устраивать, вы прекрасно знаете что «для всех» ничего не нужно делать.