1. Взять статью Грэма о лиспе
2. Написать, что язык X проще «в написании», «в понимании», «для деплоя»
3. Толсто намекнуть, что остальные языки рядом не валялись, «тут слишком много плюсов и ноль минусов»
4. ???
5. PROFIT!!!
Согласен с автором, что только «быстрота» и результаты бенчмарков, где сравнивают теплое с мягким, — это плохой критерий для выбора языка.
Чисто для контраста процитирую пост(*) недельной давности:
>… мы много занимаемся машинным обучением на очень больших массивах данных. Раньше для разработки прототипов мы использовали связку IPython + Pyhs2 (hive драйвер для Python) + Pandas + Sklearn. В конце лета 2014 года приняли принципиальное решение перейти на Spark, так как эксперименты показали, что мы получим 3-4 кратное повышение производительности на том же парке серверов.
Есть конкретная задача из жизни. Есть мотивация улучшить проект. Люди рассматривали разные варианты, анализировали плюсы/минусы. В итоге:
> Мы решили выбрать Scala, так как именно на нем написан Spark, то есть можно анализировать его исходный код и при необходимости исправлять ошибки, плюс — это JVM, на котором крутится весь Hadoop.
*Ссылка на полную версию: habrahabr.ru/company/retailrocket/blog/258543
Да, Spark очень радует тем, что постепенно перетягивает народ с других платформ на Scala. Сколько же, если не секрет, занял процесс обучения и перехода к продуктивной разработке на Scala для команды, где изначально этот язык никто не знал?
Автор выбрал платформу Java. При наличии подходящего решения внутри платформы, использовать альтернативный кусок на другой платформе просто нерационально.
Как правильно сказано в первом комментарии, главное — этот как раз контракт. Если значения может не быть — делаешь Option. Если видишь Option — готовься к тому, что значения может не быть.
Падать или не падать — вопрос второстепенный. Можно без Option явно проверять все аргументы на null и не падать. Можно наоборот не глядя делать Option.get и падать.
> насколько я вижу отсюда, планировщик в Akka занимается несколько другим
Он там просто называется Dispatcher, и он там не один (http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html)
> именно когда у вас актор можно по середине бесконечного цикла остановить из вне
Единица планирования — сообщение. Т.е. остановить извне можно в любой момент, когда актор не обрабатывает сообщение (до того, как он получил хоть одно, между сообщениями и после того, как получил все). Если бесконечный цикл внутри обработки одного сообщения — остановить «по-хорошему» нельзя (да и незачем). Для таких «подвисающих» задач используются выделенные потоки ОС. Примерно так же делается и в Go, насколько я слышал.
> вы можете расшифровать абстрактное «какие-то другим способом», что именно вы хотите делать?
Допустим, вас не устраивает стандартный алгоритм планировщика. Вы его хотите заменить на другой, более быстрый/конфигурируемый/расширяемый/масштабируемый.
> компилируемый это значит на выходе получается машинный код, насколько я знаю Scala выполняется на JVM, то есть по сути является интерпретируемой.
Это называется JIT-компиляция. Происходит в рантайме. На выходе получается вполне себе машинный код. Интерпретируемой «по сути» не является.
> ну по сути это и есть брокер сообщений
«По сути» это планировщик с кучей полезной обвязки. Такой же планировщик (только поменьше полезной обвязки) стоит и за горутинами.
> никто не мешает сделать «Akka» для Go, никаких противоречий со встроенной много-поточностью тут нет
Акку как любую стороннюю библиотеку можно подключить или отключить, можно без проблем заменить на другую. Горутины зачем-то встроены в язык. Захотите работать с потоками каким-то другим образом и весь сахар горутин окажется бесполезным, более того — вредным, раз нельзя полностью исключить его использование.
а почему наличие встроенной многозадачности должно делать язык нишевым?
Если отсылки к Go чаще всего всплывают в контексте легковесной многопоточности. Если она считается одной из основных фич языка. Если (на мой взгляд) сама по себе многопоточность — является скорее библиотечной функциональностью, чем элементом языка общего назначения. То можно сделать вывод, что Go заточен под многопоточность и берется ее обеспечивать просто и быстро. Это выглядит как некая ниша, которую Go стремится занять. Не утверждаю, что единственная.
про GC — а сколько вы знаете компилируемых языков со сборщиком мусора?
Много, например Scala. Вот, кстати, бенчмарк от Google (https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf), в котором Scala по всем параметрам кроме времени компиляции выглядит достаточно выигрышно на фоне Go.
я правильно понимаю, что Akka это по сути брокер сообщений?
Нет, Akka — это реализация actor model с поддержкой таких вещей как supervision, remoting, clustering. Можно запускать миллионы акторов на одной машине, можно — распределять по многим машинам.
Я не то чтобы протестую, я скорее спрашиваю и удивляюсь.
В статье «Главное преимущество 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, и с форматами, которые могут стать востребованы с будущем.
1. Взять статью Грэма о лиспе
2. Написать, что язык X проще «в написании», «в понимании», «для деплоя»
3. Толсто намекнуть, что остальные языки рядом не валялись, «тут слишком много плюсов и ноль минусов»
4. ???
5. PROFIT!!!
Чисто для контраста процитирую пост(*) недельной давности:
>… мы много занимаемся машинным обучением на очень больших массивах данных. Раньше для разработки прототипов мы использовали связку IPython + Pyhs2 (hive драйвер для Python) + Pandas + Sklearn. В конце лета 2014 года приняли принципиальное решение перейти на Spark, так как эксперименты показали, что мы получим 3-4 кратное повышение производительности на том же парке серверов.
Есть конкретная задача из жизни. Есть мотивация улучшить проект. Люди рассматривали разные варианты, анализировали плюсы/минусы. В итоге:
> Мы решили выбрать Scala, так как именно на нем написан Spark, то есть можно анализировать его исходный код и при необходимости исправлять ошибки, плюс — это JVM, на котором крутится весь Hadoop.
*Ссылка на полную версию: habrahabr.ru/company/retailrocket/blog/258543
Что-то трудновато сходу в это поверить. Нельзя ли пруф?
А можно поподробнее про непонятную поддержку коннектора для Кассандры? Пользуюсь этим коннектором для чтения, вроде все нормально.
Падать или не падать — вопрос второстепенный. Можно без Option явно проверять все аргументы на null и не падать. Можно наоборот не глядя делать Option.get и падать.
Он там просто называется Dispatcher, и он там не один (http://doc.akka.io/docs/akka/snapshot/scala/dispatchers.html)
> именно когда у вас актор можно по середине бесконечного цикла остановить из вне
Единица планирования — сообщение. Т.е. остановить извне можно в любой момент, когда актор не обрабатывает сообщение (до того, как он получил хоть одно, между сообщениями и после того, как получил все). Если бесконечный цикл внутри обработки одного сообщения — остановить «по-хорошему» нельзя (да и незачем). Для таких «подвисающих» задач используются выделенные потоки ОС. Примерно так же делается и в Go, насколько я слышал.
> вы можете расшифровать абстрактное «какие-то другим способом», что именно вы хотите делать?
Допустим, вас не устраивает стандартный алгоритм планировщика. Вы его хотите заменить на другой, более быстрый/конфигурируемый/расширяемый/масштабируемый.
Это называется JIT-компиляция. Происходит в рантайме. На выходе получается вполне себе машинный код. Интерпретируемой «по сути» не является.
> ну по сути это и есть брокер сообщений
«По сути» это планировщик с кучей полезной обвязки. Такой же планировщик (только поменьше полезной обвязки) стоит и за горутинами.
> никто не мешает сделать «Akka» для Go, никаких противоречий со встроенной много-поточностью тут нет
Акку как любую стороннюю библиотеку можно подключить или отключить, можно без проблем заменить на другую. Горутины зачем-то встроены в язык. Захотите работать с потоками каким-то другим образом и весь сахар горутин окажется бесполезным, более того — вредным, раз нельзя полностью исключить его использование.
Если отсылки к Go чаще всего всплывают в контексте легковесной многопоточности. Если она считается одной из основных фич языка. Если (на мой взгляд) сама по себе многопоточность — является скорее библиотечной функциональностью, чем элементом языка общего назначения. То можно сделать вывод, что Go заточен под многопоточность и берется ее обеспечивать просто и быстро. Это выглядит как некая ниша, которую Go стремится занять. Не утверждаю, что единственная.
про GC — а сколько вы знаете компилируемых языков со сборщиком мусора?
Много, например Scala. Вот, кстати, бенчмарк от Google (https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf), в котором Scala по всем параметрам кроме времени компиляции выглядит достаточно выигрышно на фоне Go.
я правильно понимаю, что Akka это по сути брокер сообщений?
Нет, Akka — это реализация actor model с поддержкой таких вещей как supervision, remoting, clustering. Можно запускать миллионы акторов на одной машине, можно — распределять по многим машинам.
В статье «Главное преимущество Go» половина текста про возврат исключения как части результата функции, вторая половина — про встроенную запускалку unit-test'ов. И это мол должно мотивировать писать «правильный» (в представлении автора) код. И это все главное преимущество что ли?
В каментах мы зацепились еще за 2 преимещества: наличие GC и сахар для горутин. Первое, прямо скажем, не очень специфично конкретно для Go. Второе — весьма сомнительная (для меня) заточка, которая делает язык нишевым, менее универсальным. А так ли он хорош в этой нише? Лучше Эрланга? Лучше привычных мне Scala + Akka? Вот это я пытаюсь выяснить.
Да, согласен, с GC действительно не все так просто.
Ну конкретно меня интересует как раз революционность обработки исключений — ветка началась именно с этого.
Проблема в том, что лаконичней получается только код, для которого подходит этот конкретный синтаксический сахар. А для какого-нибудь другого кейса (например, создание процесса ОС) — он уже не подходит и приходится писать по полной. Такая избирательность в синтаксисе делает язык неуниверсальным.
Поучительная иллюстрация этой мысли — встроенный XML-синтаксис в Scala. Авторы, когда его делали n лет назад, думали, что с такой мегафичей на уровне языка они всех порвут. Сейчас, когда XML уже не кажется таким актуальным, они думают, как бы выпилить эту монструозную фичу из языка и заменить чем-то более универсальным, чтобы одинакого просто было работать и с XML, и с JSon, и с форматами, которые могут стать востребованы с будущем.