Из ответа 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 синтаксисом. Первые попытки воспроизвести этот синтаксис показали, что в целом это возможно.
Ну, например, в JVM-мире существует Akka. Там работа с акторами, конечно, не встроена в язык. Ну а зачем, спрашивается, встраивать в синтаксис языка общего назначения то, что можно запросто выразить средствами объектно-ориентированного и функционального программирования (функциями, объектами)? С тем же успехом можно встроить в синтаксис работу с логами, сокетами и вообще чем угодно.
Почему? Для Си нельзя написать виртуальную машину? Причем тут язык-то?
У меня нет никаких сомнений, что справляется, потому что средства работы с исключениями Go аналогичны таковым в большинстве современных ЯП.
В обработке ошибок (о чем говорит автор) тоже особенной революционности не видно. Предлагаются примерно такие же средства как и в других языках. Аналог связки throw и try-catch — это panic и recover, аналог finally — defer, аналог того, о чем пишет автор — это просто передача исключения как части результата функции.
А видео нет, посмотреть, что за слайды он показывал?
Помню, с какой помпой этот Kit презентовали, заламывали за него кучу денег, устанавливали какие-то лицензионные ограничения. Кто-то наверное платил, а теперь, получается, оказался кинут.
С огромным интересом почитал бы про интеграцию Freeswitch с колл-центром и отказоустойчивость всей этой конструкции.
SBT же, на мой взгляд, активно использует несколько не очень релевантных современной сборке проектов идей: рекурсивные проекты; плоский список настроек билда, в котором должно быть все; конфигурационный файл с «упрощенным» синтаксисом, использования которого многие стараются избегать.
Что касается DSL, в Gradle скрипт, конечно, гораздо проще выглядит. В нем может разобраться даже новичок. Но лично я сомневаюсь, что это из-за Groovy. Scala позволяет писать DSL не хуже, причем с полным сохранением типобезопасности (представьте, ошибки в скрипте подчеркиваются непосредственно в IDE). У меня даже была идея написать front-end для SBT с Gradle-like синтаксисом. Первые попытки воспроизвести этот синтаксис показали, что в целом это возможно.