К сожалению, апелляции к авторитетным источникам не дают никаких результатов. Их просто никто не хочет слышать. Поэтому я прекращаю аргументированно отвечать на подобные голословные утверждения.
В начале статьи я писал, что я пишу на Go уже свыше двух с половиной лет. Из них более двух лет я посвятил разработке масштабируемого высоконагруженного проекта, написанного полностью на Go. Почему так долго? Потому, что я полностью писал его сам, параллельно изучая тонкости языка. В добавок к этому выступал еще и в роли аналитика. Это позволяет мне судить о достоинствах и недостатках языка. До этого работал с разными языками PHP, C++, Delphi, Prolog. Поэтому с уверенностью могу сказать, что Go НЕ предназначен для низкоуровневых операций. В нем нет указательной арифметики. На нем не совсем удобно обрабатывать даже простые строки в юникоде. Например, на нем много тяжелее даются парсеры, чем в том же Delphi или C++. Для таких сложных низкоуровневых операций я бы предпочел выбрать другой язык. Однако, Go, при необходимости, может подключать внешние плагины, да и к тому же у него есть CGo (хотя надобность в нем все уменьшается).
Что касается сайта продаж, то такие проекты (а также микросервисы) в основном и реализуются на Go. Причем реализуются весьма просто и элегантно. Многие используют для этого фреймворки, хотя best practics и не рекомендует это делать.
Что же касается продолжения статьи, то его скорей всего на Хабре не будет, поскольку в Recovery Mode я публиковать свои статьи не собираюсь (карма не позволяет). Возможно, продолжение просто выйдет на каком-нибудь другом сайте.
Пару лет назад (насколько я помню) у него:
* не было полнокачественной среды (только плагины).
* не было race detector.
* было ручное форматирование и документирование кода.
* было весьма немногочисленное комьюнити с относительно небольшим количеством библиотек.
Несмотря на то, что язык хорош, ему трудно состязаться с такими монстрами, как Google.
Если Вам нужна всего лишь обработка данных, возможно Вам вообще не нужно программирование на императивных языках. Эта отрасль называется DataSince и для нее используют языки типа (R, Python), однако существует ряд визуальных сред где такая обработка может быть проведена с минимальными трудозатратами.
Раньше разработчиков учили, на это тратилось время, но потом они могли писать хороший поддерживаемый код. Теперь разработчиков сажают сразу на манки работу, где сломанный компонент проще переписать заново, но так как программисты только из универа, они очень дешевые, и это получается выгодно. За чей счет банкет? За счет разработчиков. Кто в итоге в плюсе? Бедный-бедный гугл.
Вот я и привел вам аналогию с токарем. Если человек в совершенстве изучил одну операцию — это еще не повод монетизировать ее всю жизнь.
Ни один язык из двадцатки самых популярных, который был придуман за последние 10 лет не обходится без генериков.
К сожалению, Go уже перерос указанный возраст, так как разработка началась в 2007, а анонсировался он в ноябре 2009 года.
Ну давайте проясним тогда, что имелось ввиду? Мне очень интересно.
Ранее вы писали:
Лично я цитату «они умные, но при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ» как раз-таки как завуалированное сомнение в этих-самых способностях, иначе зачем эта часть в статье я вообще затрудняюсь сказать. Уверен, у большинства читающих сложилось то же впечатление.
не надо быть без недостатков, достаточно быть лучше, причем только в какой-то одной сфере, а в других просто быть не хуже. Это парето-оптимальность еще называется.
Вот Go и хорош на 80%, причем на вопрос нужно смотреть шире: язык не только сам по себе достаточно хорош (в свое время я остановился на Rust), но его инфраструктура и выгоды для командной работы на текущий момент одни из лучших. Даже IDE для него от JetBrains одна из лучших.
Я вообще всегда считал, что чем ближе язык к динамическим, тем умнее надо быть чтобы на нем программировать.
Это правда, но если проводить аналогию с естественными языками, то тогда самые умные люди говорят исключительно на китайском языке.
В таком случае, Вам могут подойти языки типа Lua, а, лучше, Python (имеет большую практическую ценность), как самые легкие в изучении. Следом за ними идет Go.
парадигма программирования, заключающаяся в таком описании данных и алгоритмов, которое можно применять к различным типам данных, не меняя само это описание. В том или ином виде поддерживается разными языками программирования. Возможности обобщённого программирования впервые появились в виде дженериков (обобщённых функций) в 1970-х годах в языках Клу и Ада, затем в виде параметрического полиморфизма в ML и его потомках, а затем во многих объектно-ориентированных языках, таких как C++, Java, Object Pascal[1], D, Eiffel, языках для платформы .NET и других.
Таким образом, обобщенные функции можно писать, даже если параметрический полиморфизм явно не поддерживается языком.
За аналогиями обычно пытаются скрыть отсутствие аргументации. Давайте прямо скажем, что за токари, на чем они писали, и кому они теперь не нужны? И что за риторический вопрос в конце, при чем тут мир? Мы вроде обсуждаем более приземленные вещи.
Это можно назвать как прецедентом так и метафорой. В юридической системе обычно прецедент является веским аргументом.
Статистику в студию, потому что мой личный опыт говорит о противоположенном. Я даже в прикладном коде часто подобные обобщения:
Статистику привести не могу, поскольку не занимался этой проблемой, однако, можете сами посмотреть на github проекты и посмотреть составляющий их процент копипаста. Например, вы можете посмотреть мою ветку проекта Echo(http://github.com/adverax/echo). Да, там есть копипаст, однако процент его не так уж и велик. Существует множество языков без дженериков и все отлично обходятся без них. Однако, когда заходит речь о Go, почему-то 90% народа считают их краеугольным камнем.
как завуалированное сомнение
Сомнения — это домыслы каждого. Каждый судит в меру своей распущенности.
Ну давайте сравним с Rust, благо он появился примерно в то же время. Давайте с C#/Kotlin, которые не менее «тырпрайзные» и приземленные, не в угоду ленивым теоретикам с низким IQ.
Нет ни одного языка программирования, лишенного всех недостатков. Да, Rust, неплохая альтернатива, однако его экосистема оставляет желать лучшего.
Записывать или не записывать себя в категорию начинающих, ограниченных или какую-либо другую группу, личное дело каждого. А вот если вас не устраивает результат разработки ведущей мировой компании Google (в частности язык Go) и вы придумываете для него оскорбительные эпитеты, значит вы можете предоставить собственные разработки, значительно превосходящие их по качеству. Предоставьте их, пожалуйста, в студию.
Спасибо за развернутое мнение по статье.
Вкратце пройдусь по некоторым пунктам Вашего комментария.
Раньше разработчиков учили, на это тратилось время, но потом они могли писать хороший поддерживаемый код. Теперь разработчиков сажают сразу на манки работу, где сломанный компонент проще переписать заново, но так как программисты только из универа, они очень дешевые, и это получается выгодно. За чей счет банкет? За счет разработчиков. Кто в итоге в плюсе? Бедный-бедный гугл.
У каждой медали две стороны. Вы заняли пессимистическую позицию. Представьте ситуацию: токарь 30 лет работал, вытачивал одну и ту же деталь. Причем вытачивал в совершенстве. В один прекрасный момент пришел инженер изменил конструкцию так, что эта деталь стала не нужна. Вопрос: что от этого потерял мир? Так может лучше остановить технический прогресс вообще?
Тогда безусловно самый лучший язык это brainfuck, как ближайший аналог тьюринг машины. И вот из него действительно нечего удалить, потому что без любой операции машина не сможет выполнять программы.
Язык Go хорош тем, что он легко читается даже непосвященным человеков (практически не тяжелее псевдокода).
Свобода это рабство, мир это война. Отсутствие элегантных абстракций это достоинство.
Любые элегантные абстракции возможны только на предметно-ориентированном языке. Так, ни в одном языке нет всей полноты математических выражений, встроенных в язык. За все в этом мире нужно платить, в том числе и за элегантные абстракции.
Но ведь у нас нет системы типов :) Мы постоянно пишем interface {} и отказываемся от них. Из системы типов у нас одни только примитивы, по сути. Да и с типами ничего сделать нельзя, потому что они раскрываются вкупе с обобщенным программированием (которое Generic), а его и нет. А с interface {} никакие типы не нужны, можно было бы как в питоне писать и все бы работало.
Все совсем не так. Большинство кода вообще не требует работы с generic. Именно там нам и дает выигрыш Go, как сильно типизированный язык.
Хотел давно задать вопрос, а почему мы сравниваем Го с языком 33 летней давности? Неужели с тех пор ничего полезного не изобрели? И да, этот VARIANT остается тем, чем я сказал, признанием в бессилии системы типов и переходом в динамику.
Мы сравниваем его с разными языками, в том числе и с C++, который еще более древний. А язык Delphi, как и C++ существовал и будет существовать еще длительное время.
Что же касается бессилия системы типов, то да, в некоторых случаях и дженерики не всегда могут помочь в решении проблемы. Например, в том же Delphi мы пишем предметно-ориентированную библиотеку для работы с той же математикой. Мы можем использовать тип Variant, который должен работать с комплексными числами, автоматическим приведением типов, а также с выводом результатов на экран. Ни один дженерик в этом нам помочь не сможет.
Попробуйте забыть обработку ошибки на примере раста.
Согласен, но вы забыли указать, что у большинства то языков нет таких встроенных механизмов.
И тут БАХ, и всех несогласных объявили «эгоистами-диванными-теортиками с низким IQ».
Вы немножко передернули. В статье же явно сказано
при условии, что мы измеряем ум именно этими критериями, а не коэффициентом IQ
Don’t repeat yourself, DRY (рус. не повторяйся) — это принцип разработки программного обеспечения, нацеленный на снижение повторения информации различного рода, особенно в системах со множеством слоёв абстрагирования. Принцип DRY формулируется как: «Каждая часть знания должна иметь единственное, непротиворечивое и авторитетное представление в рамках системы»
Здесь ни слова не говорится про то, что он применим только к коду.
Если же приходится выдавать справки в виде псевдокода, мы получаем следующие минусы:
* Дополнительная работа для программиста, которая отрывает его от основной работы.
* Устаревание информации. Через некоторый интервал времени сведения устаревают, после чего требуется псевдокод писать заново.
* Отсутствие цельной картины. Тот кто работал с аналитикой, поймет, что выдавая псевдокод, мы формируем срез по решению конкретной проблемы. Эти отрывочные данные не позволяют увидеть всю многомерную картину.
Если мы введем операции умножения и деления, то у нас появится потенциальная ошибка деления, которую в Go мы легко сможем обработать (не буду приводить реализацию). Нормальный разработчик должен всегда смотреть не только на текущую ситуацию, но и прогнозировать изменчивость разрабатываемой системы. Это позволяет сократить технические долги, за которые потом прийдется расплачиваться.
Что касается длины программы, то отвечу цитатой про читаемость на языке PERL:
У этого языка есть миллион способов сделать код другого человека полностью нечитаемым, а его немногословность заставляет даже самые простые вещи выглядеть невнятно.
Толковый словарь определяет термин страдалец, как: «Человек, испытавший много страданий, переживающий мучения физические или душевные.». Если это действительно про вас, тогда вам лучше вообще сменить профиль деятельности.
Если же командная работа имеет приоритет выше, чем личные амбиции, если важен быстрый результат и его непрерывная эволюция, если вас интересует минимизация потребляемых ресурсов и их эффективное использование, то, безусловно, вы остановите свой выбор на Go.
Написание псевдокода требует дополнительных усилий, что противоречит принципу DRY. К примеру:
* DDD стремится избежать концептуальных классов, стремясь, чтобы они слились с архитектурными классам, этим не только уменьшается объем работы и документации, но и вводится единый язык.
* В современных проектах документирование пишется в комментариях к коду и на основе его мы получаем чистовую документацию.
Язык разрабатывался как индустриальный стандарт, который простыми методами позволяет решать поставленные задачи. Причем он в разы выигрывает при использовании agile методик, поскольку код очень легко поддается рефакторингу. Этим язык способствует прежде всего целям заказчика, а уже потом, разработчика.
Большинство других языков требуют очень тщательного предварительного проектирования. Этим они ближе к водопадной модели создания ПО.
Если же программист желает получать эстетическое удовольствие — добро пожаловать в Haskell.
Все дело в том, что Go консервативный язык, поэтому недостаточно проработанную модель никто внедрять не торопится. Аналогично в процессе и расширенная обработка ошибок habr.com/ru/post/422049, но сроков выхода релиза Go 2.0 никто не знает. Сравните, к примеру, реализацию объектной модели в PHP версии 4.0 и 5.1. На мой взгляд консервативный подход правильней, поскольку попросту экономит человеческие ресурсы.
Вообще вы правы, тема дженериков в Go не до конца покрыта. Однако, актуальность проблемы можно существенно снизить за счет правильного применения различных приемов программирования. Некоторые из них вы привели правильно. Еще можно добавить обобщенное программирование с использованием замыканий, а также постараться свести задачу к использованию полиморфных кластеров и универсальных типов данных. Другими словами, правильная архитектура приложения существенно снижает остроту проблемы. Именно поэтому разработчики Go не стали реализовывать серебрянную пулю.
Что касается сайта продаж, то такие проекты (а также микросервисы) в основном и реализуются на Go. Причем реализуются весьма просто и элегантно. Многие используют для этого фреймворки, хотя best practics и не рекомендует это делать.
Что же касается продолжения статьи, то его скорей всего на Хабре не будет, поскольку в Recovery Mode я публиковать свои статьи не собираюсь (карма не позволяет). Возможно, продолжение просто выйдет на каком-нибудь другом сайте.
* не было полнокачественной среды (только плагины).
* не было race detector.
* было ручное форматирование и документирование кода.
* было весьма немногочисленное комьюнити с относительно небольшим количеством библиотек.
Несмотря на то, что язык хорош, ему трудно состязаться с такими монстрами, как Google.
Вот я и привел вам аналогию с токарем. Если человек в совершенстве изучил одну операцию — это еще не повод монетизировать ее всю жизнь.
К сожалению, Go уже перерос указанный возраст, так как разработка началась в 2007, а анонсировался он в ноябре 2009 года.
Ранее вы писали:
Вот Go и хорош на 80%, причем на вопрос нужно смотреть шире: язык не только сам по себе достаточно хорош (в свое время я остановился на Rust), но его инфраструктура и выгоды для командной работы на текущий момент одни из лучших. Даже IDE для него от JetBrains одна из лучших.
Это правда, но если проводить аналогию с естественными языками, то тогда самые умные люди говорят исключительно на китайском языке.
Таким образом, обобщенные функции можно писать, даже если параметрический полиморфизм явно не поддерживается языком.
Это можно назвать как прецедентом так и метафорой. В юридической системе обычно прецедент является веским аргументом.
Статистику привести не могу, поскольку не занимался этой проблемой, однако, можете сами посмотреть на github проекты и посмотреть составляющий их процент копипаста. Например, вы можете посмотреть мою ветку проекта Echo(http://github.com/adverax/echo). Да, там есть копипаст, однако процент его не так уж и велик. Существует множество языков без дженериков и все отлично обходятся без них. Однако, когда заходит речь о Go, почему-то 90% народа считают их краеугольным камнем.
Сомнения — это домыслы каждого. Каждый судит в меру своей распущенности.
Нет ни одного языка программирования, лишенного всех недостатков. Да, Rust, неплохая альтернатива, однако его экосистема оставляет желать лучшего.
Вкратце пройдусь по некоторым пунктам Вашего комментария.
У каждой медали две стороны. Вы заняли пессимистическую позицию. Представьте ситуацию: токарь 30 лет работал, вытачивал одну и ту же деталь. Причем вытачивал в совершенстве. В один прекрасный момент пришел инженер изменил конструкцию так, что эта деталь стала не нужна. Вопрос: что от этого потерял мир? Так может лучше остановить технический прогресс вообще?
Язык Go хорош тем, что он легко читается даже непосвященным человеков (практически не тяжелее псевдокода).
Любые элегантные абстракции возможны только на предметно-ориентированном языке. Так, ни в одном языке нет всей полноты математических выражений, встроенных в язык. За все в этом мире нужно платить, в том числе и за элегантные абстракции.
Все совсем не так. Большинство кода вообще не требует работы с generic. Именно там нам и дает выигрыш Go, как сильно типизированный язык.
Мы сравниваем его с разными языками, в том числе и с C++, который еще более древний. А язык Delphi, как и C++ существовал и будет существовать еще длительное время.
Что же касается бессилия системы типов, то да, в некоторых случаях и дженерики не всегда могут помочь в решении проблемы. Например, в том же Delphi мы пишем предметно-ориентированную библиотеку для работы с той же математикой. Мы можем использовать тип Variant, который должен работать с комплексными числами, автоматическим приведением типов, а также с выводом результатов на экран. Ни один дженерик в этом нам помочь не сможет.
Согласен, но вы забыли указать, что у большинства то языков нет таких встроенных механизмов.
Вы немножко передернули. В статье же явно сказано
Здесь ни слова не говорится про то, что он применим только к коду.
Если же приходится выдавать справки в виде псевдокода, мы получаем следующие минусы:
* Дополнительная работа для программиста, которая отрывает его от основной работы.
* Устаревание информации. Через некоторый интервал времени сведения устаревают, после чего требуется псевдокод писать заново.
* Отсутствие цельной картины. Тот кто работал с аналитикой, поймет, что выдавая псевдокод, мы формируем срез по решению конкретной проблемы. Эти отрывочные данные не позволяют увидеть всю многомерную картину.
Что касается длины программы, то отвечу цитатой про читаемость на языке PERL:
Если же командная работа имеет приоритет выше, чем личные амбиции, если важен быстрый результат и его непрерывная эволюция, если вас интересует минимизация потребляемых ресурсов и их эффективное использование, то, безусловно, вы остановите свой выбор на Go.
* DDD стремится избежать концептуальных классов, стремясь, чтобы они слились с архитектурными классам, этим не только уменьшается объем работы и документации, но и вводится единый язык.
* В современных проектах документирование пишется в комментариях к коду и на основе его мы получаем чистовую документацию.
Большинство других языков требуют очень тщательного предварительного проектирования. Этим они ближе к водопадной модели создания ПО.
Если же программист желает получать эстетическое удовольствие — добро пожаловать в Haskell.