Я не то чтобы протестую, я скорее спрашиваю и удивляюсь.
В статье «Главное преимущество Go» половина текста про возврат исключения как части результата функции, вторая половина — про встроенную запускалку unit-test'ов. И это мол должно мотивировать писать «правильный» (в представлении автора) код. И это все главное преимущество что ли?
В каментах мы зацепились еще за 2 преимещества: наличие GC и сахар для горутин. Первое, прямо скажем, не очень специфично конкретно для Go. Второе — весьма сомнительная (для меня) заточка, которая делает язык нишевым, менее универсальным. А так ли он хорош в этой нише? Лучше Эрланга? Лучше привычных мне Scala + Akka? Вот это я пытаюсь выяснить.
Ну, следуя той же логике можно заключить, что классы — это крайне важная фича, которая есть в большинстве мейстримных языков. Встроенная многопоточность — маргинальная фича, которая есть в двух не самых мейнстримных языках (при всем моем глубоком уважении к Erlang и Go). Что-то на уровне Scala XML как раз…
Ну кроме многопоточности есть, например, еще распределенность, которая тоже вряд ли куда-то денется. Как там у легковесных потоков со scale-out? Если плохо, то наверное скоро появится (или уже появилась) библиотека, которая умеет scale-up и scale-out одновременно. И горутины могут оказаться больше не нужны.
При чем здесь виртуальная машина и сборщик мусора?
Да, согласен, с GC действительно не все так просто.
Действительно, если у вас в языке существуют указатели сделать сборку мусора проблематично. Но, опять-таки, полно языков без указателей. Есть ли у Go какие-нибудь фишки, которые радикально повышают качество сборки мусора по сравнению с этими другими языками?
Это касалось не только (и не столько) исключений
Ну конкретно меня интересует как раз революционность обработки исключений — ветка началась именно с этого.
В принципе всё это можно с той или иной многословностью сделать библиотечными средствами, но когда оно в языке, код получается лаконичней.
Проблема в том, что лаконичней получается только код, для которого подходит этот конкретный синтаксический сахар. А для какого-нибудь другого кейса (например, создание процесса ОС) — он уже не подходит и приходится писать по полной. Такая избирательность в синтаксисе делает язык неуниверсальным.
Поучительная иллюстрация этой мысли — встроенный XML-синтаксис в Scala. Авторы, когда его делали n лет назад, думали, что с такой мегафичей на уровне языка они всех порвут. Сейчас, когда XML уже не кажется таким актуальным, они думают, как бы выпилить эту монструозную фичу из языка и заменить чем-то более универсальным, чтобы одинакого просто было работать и с XML, и с JSon, и с форматами, которые могут стать востребованы с будущем.
Из ответа vsb в другой ветке осознал про связь GC и языка. Действительно, если у вас в языке существуют указатели сделать сборку мусора проблематично. Но, опять-таки, полно языков без указателей. Есть ли у Go какие-нибудь фишки, которые радикально повышают качество сборки мусора по сравнению с этими другими языками?
Про потоки — на вскидку я могу назвать только 2 языка в которых это сделано частью стандартного синтаксиса это Go и Erlang, тоесть что запустить новый поток нужно написать go, spawn и всё.
Ну, например, в JVM-мире существует Akka. Там работа с акторами, конечно, не встроена в язык. Ну а зачем, спрашивается, встраивать в синтаксис языка общего назначения то, что можно запросто выразить средствами объектно-ориентированного и функционального программирования (функциями, объектами)? С тем же успехом можно встроить в синтаксис работу с логами, сокетами и вообще чем угодно.
про GC, на примере того же C/C++ я себе это слабо представляю
Почему? Для Си нельзя написать виртуальную машину? Причем тут язык-то?
При создании языка решали вполне конкретные проблемы, которые всплыли в процессе разработки в Google на разных языках и Go с этим справляется, что будет дальше покажет время
У меня нет никаких сомнений, что справляется, потому что средства работы с исключениями Go аналогичны таковым в большинстве современных ЯП.
Ну легковесные потоки и GC не имеют отношения к языку как таковому, на мой взгляд. Думаю, такие вещи в принципе можно реализовать для любого языка.
В обработке ошибок (о чем говорит автор) тоже особенной революционности не видно. Предлагаются примерно такие же средства как и в других языках. Аналог связки throw и try-catch — это panic и recover, аналог finally — defer, аналог того, о чем пишет автор — это просто передача исключения как части результата функции.
А в чем революционность именно языка? В Java или в любом другом мейнстрим-языке можно написать функцию, которая будет возвращать Pair<ResultType, Exception> с тем же примерно эффектом.
Было бы интересно понять мотивацию такого решения. Не позволить никому расширять/встраивать Skype? Это и раньше было совсем непросто, но зачем саму возможность-то выпиливать под корень? Или предлагаются какие-то альтернативные инструменты для этого?
Помню, с какой помпой этот Kit презентовали, заламывали за него кучу денег, устанавливали какие-то лицензионные ограничения. Кто-то наверное платил, а теперь, получается, оказался кинут.
Раз уж в посте упомянута Akka, не могу не привести ссылку на разбор авторами этого проекта основных моделей многопоточного программирования Concurrency – The good, the bad, the ugly.
Gradle сам по себе, в отрыве от языка достаточно хороший продукт. Он берет лучшее из тулзовин предыдущего поколения, с которыми знакомо подавляющее большинство java-разработчиков: декларативную модель проекта из maven и императивные таски из ant.
SBT же, на мой взгляд, активно использует несколько не очень релевантных современной сборке проектов идей: рекурсивные проекты; плоский список настроек билда, в котором должно быть все; конфигурационный файл с «упрощенным» синтаксисом, использования которого многие стараются избегать.
Что касается DSL, в Gradle скрипт, конечно, гораздо проще выглядит. В нем может разобраться даже новичок. Но лично я сомневаюсь, что это из-за Groovy. Scala позволяет писать DSL не хуже, причем с полным сохранением типобезопасности (представьте, ошибки в скрипте подчеркиваются непосредственно в IDE). У меня даже была идея написать front-end для SBT с Gradle-like синтаксисом. Первые попытки воспроизвести этот синтаксис показали, что в целом это возможно.
В статье «Главное преимущество Go» половина текста про возврат исключения как части результата функции, вторая половина — про встроенную запускалку unit-test'ов. И это мол должно мотивировать писать «правильный» (в представлении автора) код. И это все главное преимущество что ли?
В каментах мы зацепились еще за 2 преимещества: наличие GC и сахар для горутин. Первое, прямо скажем, не очень специфично конкретно для Go. Второе — весьма сомнительная (для меня) заточка, которая делает язык нишевым, менее универсальным. А так ли он хорош в этой нише? Лучше Эрланга? Лучше привычных мне Scala + Akka? Вот это я пытаюсь выяснить.
Да, согласен, с GC действительно не все так просто.
Ну конкретно меня интересует как раз революционность обработки исключений — ветка началась именно с этого.
Проблема в том, что лаконичней получается только код, для которого подходит этот конкретный синтаксический сахар. А для какого-нибудь другого кейса (например, создание процесса ОС) — он уже не подходит и приходится писать по полной. Такая избирательность в синтаксисе делает язык неуниверсальным.
Поучительная иллюстрация этой мысли — встроенный XML-синтаксис в Scala. Авторы, когда его делали n лет назад, думали, что с такой мегафичей на уровне языка они всех порвут. Сейчас, когда XML уже не кажется таким актуальным, они думают, как бы выпилить эту монструозную фичу из языка и заменить чем-то более универсальным, чтобы одинакого просто было работать и с XML, и с JSon, и с форматами, которые могут стать востребованы с будущем.
Ну, например, в JVM-мире существует Akka. Там работа с акторами, конечно, не встроена в язык. Ну а зачем, спрашивается, встраивать в синтаксис языка общего назначения то, что можно запросто выразить средствами объектно-ориентированного и функционального программирования (функциями, объектами)? С тем же успехом можно встроить в синтаксис работу с логами, сокетами и вообще чем угодно.
Почему? Для Си нельзя написать виртуальную машину? Причем тут язык-то?
У меня нет никаких сомнений, что справляется, потому что средства работы с исключениями Go аналогичны таковым в большинстве современных ЯП.
В обработке ошибок (о чем говорит автор) тоже особенной революционности не видно. Предлагаются примерно такие же средства как и в других языках. Аналог связки throw и try-catch — это panic и recover, аналог finally — defer, аналог того, о чем пишет автор — это просто передача исключения как части результата функции.
А видео нет, посмотреть, что за слайды он показывал?
Помню, с какой помпой этот Kit презентовали, заламывали за него кучу денег, устанавливали какие-то лицензионные ограничения. Кто-то наверное платил, а теперь, получается, оказался кинут.
С огромным интересом почитал бы про интеграцию Freeswitch с колл-центром и отказоустойчивость всей этой конструкции.
SBT же, на мой взгляд, активно использует несколько не очень релевантных современной сборке проектов идей: рекурсивные проекты; плоский список настроек билда, в котором должно быть все; конфигурационный файл с «упрощенным» синтаксисом, использования которого многие стараются избегать.
Что касается DSL, в Gradle скрипт, конечно, гораздо проще выглядит. В нем может разобраться даже новичок. Но лично я сомневаюсь, что это из-за Groovy. Scala позволяет писать DSL не хуже, причем с полным сохранением типобезопасности (представьте, ошибки в скрипте подчеркиваются непосредственно в IDE). У меня даже была идея написать front-end для SBT с Gradle-like синтаксисом. Первые попытки воспроизвести этот синтаксис показали, что в целом это возможно.