Comments 23
Хоть это и перевод, но полностью согласен с каждым словом.
Go это как лего - простые для понимания стандартные кубики, из которых можно построить прекрасные и сложные вещи. Модули и версионность - отличное решение для разбиения кода.
Реально большие и сложные вещи лучше решить генераторами кода, чем извращениями с дженериками и тд, которые имеют огромный шанс отстрелить колени.
Простой пример - для полного раскрытия дженериков нужно использовать any на вход. Но это небезопасно, а проверка типов внутри с последующим вызовом методов с нужными типами - собственно и зачем в итоге дженерик? Не говоря уже про то, что проверки типов жрут ресурсы и такой "сахар" противопоказан в высокопроизводительном приложении
Простой пример - для полного раскрытия дженериков нужно использовать any на вход. Но это небезопасно, а проверка типов внутри с последующим вызовом методов с нужными типами - собственно и зачем в итоге дженерик?
Это уже звучит не как дженерик, ведь они вычисляются на этапе компиляции, а не в рантайме. Можете привести пример?
проверки типов жрут ресурсы
В Go type cast в рантайме это один if, так что сложно в такое упереться
В дотнете для значимых типов (value types) в роли параметров-типов с соответствующими ограничениями (where T: struct) генерируются отдельные реализации. Тут с примерами.
А что мешает синтаксисом дженериков объявить параметр с типом указателя-интерфейса в компилируемом языке? Если так, то сгенерится одна общая реализация и полиморфизм будет динамическим. Если будет предполагаться конкретный тип известного при компиляции размера - компилятор будет делать реализации под каждый конкретный используемый тип, т.е. статический полиморфизм. Так это в Rust работает, где в компилируемости сомнений нет. Да и в C# именно так, с поправкой на отложенную компиляцию/JIT.
В Go "гибридный" подход. Все дженерики выводятся во время компиляции, кроме указателей. Указатели и интерфейсы будут выводиться как указатели на uint8, а затем в рантайме будет выводиться конкретный тип указателя(косвенный вызов). Автор на счет дженериков к слову неправ, просто дженерики создавались не для того же, для чего делались шаблоны в Go. В Go библиотеках очень много случаев когда дублируются функции для обработки строк и слайса байтов итп. В таких случаях дженерики в Go работают прекрасно и позволяют без потери в производительности избавиться от дублирования. Плюс дают дорогу к пакетам подобным slices без рантайм проверок входных данных
Это прекрасный пост, но позволю на правах оффтопа спросить, вы на книги по мобильному программированию окончательно забили?
дженерики Go не поддерживают родовые методы на родовых типах
Даже те функции, которые согласны с сигнатурой, не всегда согласны с семантикой.
строкам, фрагментам, картам и каналам
Имейте в виду, что последний цикл неявно преобразуется в первый код с явным вызовом обратного вызова.
Я могу понять нежелание тратиться на переводчика, но неужели в издательстве не нашлось редактора?
"Go гораздо проще в использовании, чем Rust. Почему Rust проигрывает в гонке "
В оригинале:
"Go is much easier to use than Rust. Why losing Rust in performance race? "
может надо перевести как:
"Go гораздо проще в использовании, чем Rust. Почему он Rust-у проигрывает в гонке?"
Вводят излишние усложнения в язык, забросив в полурабочем состоянии остальное - например плагины.В виде отдельно библиотеки не собрать, зависимость от окружающей среды сборки и основного кода, отсутствие поддержки Windows (issues-19282, 7 лет проблеме!).
Когда программист уходит из PHP в Go средний уровень IQ повышается и там и там
Как говорится: "Не жили хорошо, нечего и начинать". В изначально бедном в языковом плане Go, который затачивался на отсутствие этих конструкций, они, действительно, выглядят инородно.
Весь язык Go - ошибка дизайна. Фундаментальная идея сделать "простой" язык обречена на провал. За кажущейся простотой кроется скудность возможностей и как следствие излишняя самоповторяемость и многословность кода. А улучшить теперь ничего уже толком нельзя, т. к. улучшения поверх скудной основы получаются весьма проблематичными.
Сама идея, лежащая в основе данного языка порочна. В мечтах его создателей язык был простым в освоении и позволял писать при этом более-менее сносный код. Но на практике вышло, что более опытным программистам ограничения языка мешают. Более целесообразным было бы сделать язык удобным именно для опытных программистов, чтобы максимально повысить их производительность.
Хочу добавить, что многословность кода ведёт и к его усложнению. Приходится сосредотачиваться на чтении "лапши" даже в довольно простых для "богатых" языков случаях. Я думаю никого не нужно убеждать в том, что программу на ассемблере будет сложнее и писать, и читать, чем программу на Си, хотя языки ассемблера очень простые. Бедность языка приводит к тому, что сложную программу приходится выражать в сложном нагромождении простых конструкций, вместо того, чтобы выразить в простом наборе сложных, как это можно сделать в богатых языках.
Но на практике вышло, что более опытным программистам ограничения языка мешают.
Чушь полнейшая. Более опытные разработчики ревьювят код чаще, чем сами пишут. И простота чтения тут очень сильно помагает
Язык должен развиваться. Иначе он умрёт. Главной фишкой языка всегда были горутины, классы без классов и быстрое подключение модулей. Дженерики - лишь приятное дополнение. Ещё бы тернарный оператор не помешал. Это все можно не использовать, не заставляют же. А претензия про плохо читаемый код - абсолютно пустая. Выпендрежники и так пишут такой код, что фиг поймёшь.
Так что если там кому-то что-то кажется, то пусть подождёт, пока в плюсы рефлексию подвезут и модули довезут.
Я один не понял, зачем нужен вызов strings.Clone вместо обычного присваивания?
становится труднее понять, что происходит, просто читая код
1) нужно уметь писать 2) нужно уметь читать
Не абстракции ли дают упрощение? Гдето слышал, что они скрывают детали, которые можно игнорировать.
Хороший язык - богатый инструмент. Хочешь - пиши лапшу, а не хочешь - не пиши.
Эти фичи нужны не для написания производственного кода а для стандартизации библиотек.Я не буду использовать итераторы,но с удовольствием буду использовать библиотеки которые их применяют
Go развивается в неверном направлении