Вы не правы. Вам выше привели ссылку на то, где авторы 4х системных языков объясняют, что определения размыты и подразумевают разные вещи.
Зачем писать «четкие определения», если они заведомо не четкие, и их нет, и даже ссылки на субъективные определения, справедливые для какой-то одной эпохи, вы не можете нагуглить?
Ну это вы о контейнерах, а я о шаблонах и паттернах которые человек не хочет или не может пересмотреть по мере того, как он пытается освоить новый язык. Начиная с того, что кастят в interface{} некоторые новички в массе других ситуацией, и заканчивая тем, что параметризация очень часто используется там, где она 100 лет не нужна.
Просто потому что языки напрямую влияют на то, как программист смотрит на проблему и как он будет её решать. И мой поинт в том, что когда человек не способен избавится от одного майндсета, навязанного одним языком, и посмотреть, как же можно подходит к проблеме иначе с другим инструментом — то это проблема этого человека, а не инструмента.
Другими словами, если человек привык ездить в Икарусе, и ему неудобно без поручней в Мазерати (не за что держаться стоя), то это не недостаток Мазерати, это недостаток человека, что он так долго адаптируется к новым для себя реалиям.
А вы не отличаете «постоянно сражаюсь с ограниченной системой типов с кастами всего в interface{}» от «как написать параметризованный контейнер»?
Я всё жду, пока вы дойдете до вопроса «А почему авторы Go считают, что в программировании есть что-то иное, кроме параметризованных контейнеров?». Или вы тоже каждый день пишете свои параметризованные контейнеры из года в год?
В Go несколько уникальный подход — есть структуры и интерфейсы, первые определяют данные, вторые — поведение. При этом любая структура с данными может неявно реализовать какое-то поведение (интерфейс), просто имея нужные методы с нужной сигнатурой.
И тут начинается интересное — если понять эту парадигму, особенно после class-ориентированных «ооп» языков, то многие вещи начинают быть проще и понятней. Становится более ясно, когда мы работает с данными, а когда логикой и можно передавать аргументы функциям как через типы-структуры, так и через типы-интерфейсы. Тоесть один тип может быть и структурой и интерфейсом одновременно.
Но людям, которые привыкли к дженерикам, сложно поменять подход к проблеме, который, как известно, формируется инструментарием. Они пытаются в Go все засовывать в некое подобие дженерного типа (interface{} — пустой интерфейс, которому, по логике вещей, удовлетворяют все остальные типы-структуры), и работать с ними. Это очень печальный признак, потому что на Go так не пишут и так даже думают о проблеме.
Вы совершаете ту же ошибку, что и автор статьи — вы боретесь с языком. Вместо того, чтобы понять, как с его помощью решать проблему, вы пытаетесь понять, как с его помощью сделать так, как я привык в других языках.
Не нужно делать из variadic parameters попытку симулировать argument overloading. Поймите, что решить задачу (реальную задачу, которую должна решать программа) можно сделать несколько иным способом, кроме как «найти любой ценой способ передавать дефолтные значения». И ценой вашего болезненного раздражительного «отвыкания» будет более ясный и читабельный для других код.
Сама фраза «системный язык» имеет различные смыслы. Вот в этом видео Александреску, Матсакиса, Страуструпа и Пайка спрашивают как раз один из вопросов про то, что вы считаете «системным языком».
Поэтому, если уж дискутировать о позиционировании, давайте озвучим факт, что под этим термином разные люди понимают разные вещи. Кому-то кажется, что они должны писать собственные аллокаторы, а кому-то важно писать продуктивные программы для облаков.
Кложурщик — если что, это не ругательство :) Я с ним знаком лично, и человек даже на митапе про Go пытался всем навязывать Clojure и рассказывал, что Go и удобства в конкурентности, это не серебрянная пуля, потому что там нет иммутабельных структур, поэтому переходите на Clojure. :)
Дженерики — это не только параметризированные контейнеры, и их важность для реальной разработки программистами из других языков сильно переоценена и приводит к тому, что дженерики используются по поводу и без.
Повеселила статья, которую правильно бы было назвать «Год с моей последней блогозаписи в Go».
Всё что написал автор — попытка более изощренно продать свое «я привык по-другому» за «минусы языка», и я не верю, что он писал год на Go, иначе не голословничал бы от каждого поверхностного суждения, а всё-равно разобрался бы в теме.
Собственно, автор всё сам объяснил вот тут:
Я либо сражаюсь с ограниченной системой типов с кастами всего в interface{} либо занимаюсь копипастой кода который делает практически одно и то же для разных типов.
Такое бывает у программистов, пришедших с других языков, когда они сражаются с языком, пытаясь насадить свои привычные паттерны и подходы к новому языку. Но, как правило, это не длится, даже в самом упоротом случае, больше двух недель. Если же у автора это продолжалось и вправду год, то всё *очень* печально.
Так что, если увидите программиста, который кастит постоянно все в interface{} — особенно на интервью — бегите от него подальше.
Каналы и мьютексы МЕДЛЕННЫЕ. Добавление синхронизации через мьютексы на production настолько снизило скорость работы, что лучшим решением стал запуск процесса под daemontools и его перезапуск в случае падения.
Разумеется, когда каждый может написать за минуту бенчмарк и посмотреть реальную производительность мьютексов и каналов, цифры в посте отсутствуют, как класс. Расчет на то, что читатель все примет на веру и скажет — «да, действительно, раз даже капсом написано, то и вправду медленные».
Строго говоря, утилита для анализа покрытия кода в Go — это хак.
Не важно, что coverage report идет в Go из коробки, не важно, что дает возможность с нулевым усилием получить coverage percentage, не важно, что веб-страничка репорта дает возможность бегать по файлам и смотреть визуально, какие функции и как покрыты. Этот мелкий практический аспект не важен, ведь главное — что это можно назвать «хаком» и, неверно поняв, как работать с инструментом, написать «критику».
Пользователи go хором говоря не пользоваться get, но при этом ничего не делают, чтобы пометить ее как неудачную реализацию и сделать официальную замену.
Все пользуют go get и никто не говорит «не пользоваться get». Это уже становится похоже на типичные приемы пропаганды — говорить заведомо ложные сведения так, как будто нет сомнений в их истинности.
Эта реализация замаскирует паузы сборщика мусора, замедление связанное с гонками выделения ресурсов и другие интересные вещи, если они случаются не слишком часто.
Автор абсолютно не понимает зачем нужны бенчмарки функций. Странно, что он не пожаловался на «замедление связанное с падением нод и рестартом серверов».
многие проверки, которые обычно делает компилятор просто пропускаются — они реализованы в go vet.
Бгг. Как же человек старается насадить свое узкое мнение на реальность.
Все, устал комментировать каждую строчку. Автор не читал документацию по Go (иначе бы он понял, как просто работают поинтеры в Go), весь этот год писал на обожаемом им Эрланге, и собрал все, не фильтруя, что он придумал или не понял, чтобы назвать это минусами языка.
В том-то и дело, что там не нужно делать такие манипуляции. Если человек все кастит в interface{}, значит он пытается перенести абсолютно чужие и крепко засевшие в голове паттерны туда, где они не нужны. Это печально, таких надо отсеивать на первом же собеседовании :)
Вы, наверное, догадываетесь, что их там нет намеренно — на практике, по мнению авторов Go, удобство от наличия одноименных функций с разными сигнатурами параметров оказывается сбивающем с толку и запутывающим программистов. Этот вопрос есть в FAQ: golang.org/doc/faq#overloading
В том же комментарии есть две ссылки, объясняющие, что это research и в продакшене не то что не бегает, но еще даже не планируется. Но спасибо за линк )
Это вы попытались описать своими словами Hype Cycle и наложили свои представления на него, подав как вывод. На самом деле на Go не просто так пишут почти весь современный софт для кластеров и всего вокруг, и все кто строит бизнес на Go уже прекрасно знают, чего ожидать, что язык может, что не может — так что по hype cycle Go уже давно вышел на «плато продуктивности». Если вам еще интересно мнение специалистов, мониторящих технологии, то посмотрите на TechRadar от ThoughtWorks, согласны ли они с вашей оценкой.
go-рутины вообще обыденность какая-то особенно после async-await штук
Однозначно обыденность. Ну чего же вы хотите от Google и Томпсона с Пайком — не все же настолько умны, чтобы знать про «async-await штуки» )
Зачем писать «четкие определения», если они заведомо не четкие, и их нет, и даже ссылки на субъективные определения, справедливые для какой-то одной эпохи, вы не можете нагуглить?
Просто потому что языки напрямую влияют на то, как программист смотрит на проблему и как он будет её решать. И мой поинт в том, что когда человек не способен избавится от одного майндсета, навязанного одним языком, и посмотреть, как же можно подходит к проблеме иначе с другим инструментом — то это проблема этого человека, а не инструмента.
Другими словами, если человек привык ездить в Икарусе, и ему неудобно без поручней в Мазерати (не за что держаться стоя), то это не недостаток Мазерати, это недостаток человека, что он так долго адаптируется к новым для себя реалиям.
Я всё жду, пока вы дойдете до вопроса «А почему авторы Go считают, что в программировании есть что-то иное, кроме параметризованных контейнеров?». Или вы тоже каждый день пишете свои параметризованные контейнеры из года в год?
И тут начинается интересное — если понять эту парадигму, особенно после class-ориентированных «ооп» языков, то многие вещи начинают быть проще и понятней. Становится более ясно, когда мы работает с данными, а когда логикой и можно передавать аргументы функциям как через типы-структуры, так и через типы-интерфейсы. Тоесть один тип может быть и структурой и интерфейсом одновременно.
Но людям, которые привыкли к дженерикам, сложно поменять подход к проблеме, который, как известно, формируется инструментарием. Они пытаются в Go все засовывать в некое подобие дженерного типа (interface{} — пустой интерфейс, которому, по логике вещей, удовлетворяют все остальные типы-структуры), и работать с ними. Это очень печальный признак, потому что на Go так не пишут и так даже думают о проблеме.
Вот одна из статей, объясняющая интерфейсы: go-book.appspot.com/interfaces.html
Не нужно делать из variadic parameters попытку симулировать argument overloading. Поймите, что решить задачу (реальную задачу, которую должна решать программа) можно сделать несколько иным способом, кроме как «найти любой ценой способ передавать дефолтные значения». И ценой вашего болезненного раздражительного «отвыкания» будет более ясный и читабельный для других код.
Поэтому, если уж дискутировать о позиционировании, давайте озвучим факт, что под этим термином разные люди понимают разные вещи. Кому-то кажется, что они должны писать собственные аллокаторы, а кому-то важно писать продуктивные программы для облаков.
С дженериками вопрос же о другом.
Если вам действительно интересна тема, рекомендую вот этот обзор дискуссий о дженериках в Go: docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4/edit#heading=h.vuko0u3txoew
Всё что написал автор — попытка более изощренно продать свое «я привык по-другому» за «минусы языка», и я не верю, что он писал год на Go, иначе не голословничал бы от каждого поверхностного суждения, а всё-равно разобрался бы в теме.
Собственно, автор всё сам объяснил вот тут:
Такое бывает у программистов, пришедших с других языков, когда они сражаются с языком, пытаясь насадить свои привычные паттерны и подходы к новому языку. Но, как правило, это не длится, даже в самом упоротом случае, больше двух недель. Если же у автора это продолжалось и вправду год, то всё *очень* печально.
Так что, если увидите программиста, который кастит постоянно все в interface{} — особенно на интервью — бегите от него подальше.
Разумеется, когда каждый может написать за минуту бенчмарк и посмотреть реальную производительность мьютексов и каналов, цифры в посте отсутствуют, как класс. Расчет на то, что читатель все примет на веру и скажет — «да, действительно, раз даже капсом написано, то и вправду медленные».
Не важно, что coverage report идет в Go из коробки, не важно, что дает возможность с нулевым усилием получить coverage percentage, не важно, что веб-страничка репорта дает возможность бегать по файлам и смотреть визуально, какие функции и как покрыты. Этот мелкий практический аспект не важен, ведь главное — что это можно назвать «хаком» и, неверно поняв, как работать с инструментом, написать «критику».
Все пользуют go get и никто не говорит «не пользоваться get». Это уже становится похоже на типичные приемы пропаганды — говорить заведомо ложные сведения так, как будто нет сомнений в их истинности.
Автор абсолютно не понимает зачем нужны бенчмарки функций. Странно, что он не пожаловался на «замедление связанное с падением нод и рестартом серверов».
Бгг. Как же человек старается насадить свое узкое мнение на реальность.
Все, устал комментировать каждую строчку. Автор не читал документацию по Go (иначе бы он понял, как просто работают поинтеры в Go), весь этот год писал на обожаемом им Эрланге, и собрал все, не фильтруя, что он придумал или не понял, чтобы назвать это минусами языка.
Хороший вброс, одобряю.
А, ну раз звучит фраза «на самом же деле», то это действительно так.
Kubernetes, Etcd, Racket, Docker, Influxdb, Vault, Consul, Salt, CoreOS, Aerospike и тд. Dropbox вообще весь на Go бегает.
Вот, к примеру: engineering.intenthq.com/2015/03/what-is-good-code-a-scientific-definition
Однозначно обыденность. Ну чего же вы хотите от Google и Томпсона с Пайком — не все же настолько умны, чтобы знать про «async-await штуки» )