> Разумеется, это просто мои мысли и причины перехода твиттера на Scala мне неизвестны.
Так почитайте (например, здесь: www.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html) прежде чем выдумывать сказки про «монструозные языки». Скалу любят в том числе за то, что она может дать скорость разработки и гибкость динамических языков, не жертвуя типобезопасностью и скоростью выполнения.
в 2012 году Китай вложил в образование 294 млрд долларов
США — 454 млрд долларов.
Российское правительство пообещало поддержку в размере 184 млн долларов на улучшение своих позиций в мировых рейтингах.
Разница на 3 порядка выглядит чудовищной. Но насколько сопоставимы категории «вклад в образование» и «поддержка на улучшение позиций в рейтингах»? Очевидно, только этой поддержкой траты на высшее образование не ограничиваются. Хотелось бы увидеть какие-то сопоставимые цифры, для объективности картины.
> Если вы намекаете на Javadoc и Pythondoc, то а) их нужно ставить отдельно
Не нужно. javadoc идет в комплекте с jdk, в питоне, как я понимаю — аналогично.
> для них нужно учить/запоминать специальный синтаксис
Что за синтаксис? Давайте-ка сравним доки Go и Java. Вот пример на Go (взятый здесь: blog.golang.org/godoc-documenting-go-code)
// Fprint formats using the default formats for its operands and writes to w.
// Spaces are added between operands when neither is a string.
// It returns the number of bytes written and any write error encountered.
func Fprint(w io.Writer, a ...interface{}) (n int, err error)
Вот похожий код из Java:
/**
* Writes a string.
*
* param str
* String to be written
*
* @throws IOException
* If an I/O error occurs
*/
public void write(String str) throws IOException
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Что интересно, по той же ссылке на блог Go можно найти такой текст:
> Godoc is conceptually related to Python's Docstring and Java's Javadoc, but its design is simpler. The comments read by godoc are not language constructs (as with Docstring) nor must they have their own machine-readable syntax (as with Javadoc). Godoc comments are just good comments, the sort you would want to read even if godoc didn't exist.
Автор в общем признает, что по сути подход такой же, как в Java и Python. Правда потом зачем-то начинает решать за меня, какие комментарии мне читать приятнее. Но видимо, это такая черта Go-евангелистов.
> И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
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. Можно запускать миллионы акторов на одной машине, можно — распределять по многим машинам.
Так почитайте (например, здесь: www.redfin.com/devblog/2010/05/how_and_why_twitter_uses_scala.html) прежде чем выдумывать сказки про «монструозные языки». Скалу любят в том числе за то, что она может дать скорость разработки и гибкость динамических языков, не жертвуя типобезопасностью и скоростью выполнения.
На каких конкретно научных знаниях построена данная статья? Есть ли исследования, подтверждающие эффективность предложенной модели?
Разница на 3 порядка выглядит чудовищной. Но насколько сопоставимы категории «вклад в образование» и «поддержка на улучшение позиций в рейтингах»? Очевидно, только этой поддержкой траты на высшее образование не ограничиваются. Хотелось бы увидеть какие-то сопоставимые цифры, для объективности картины.
Не нужно. javadoc идет в комплекте с jdk, в питоне, как я понимаю — аналогично.
> для них нужно учить/запоминать специальный синтаксис
Что за синтаксис? Давайте-ка сравним доки Go и Java. Вот пример на Go (взятый здесь: blog.golang.org/godoc-documenting-go-code)
// Fprint formats using the default formats for its operands and writes to w.
// Spaces are added between operands when neither is a string.
// It returns the number of bytes written and any write error encountered.
func Fprint(w io.Writer, a ...interface{}) (n int, err error)
Вот похожий код из Java:
/**
* Writes a string.
*
* param str
* String to be written
*
* @throws IOException
* If an I/O error occurs
*/
public void write(String str) throws IOException
Ничего не скажешь, невероятно сложный синтаксис, несколько лет надо учить.
Что интересно, по той же ссылке на блог Go можно найти такой текст:
> Godoc is conceptually related to Python's Docstring and Java's Javadoc, but its design is simpler. The comments read by godoc are not language constructs (as with Docstring) nor must they have their own machine-readable syntax (as with Javadoc). Godoc comments are just good comments, the sort you would want to read even if godoc didn't exist.
Автор в общем признает, что по сути подход такой же, как в Java и Python. Правда потом зачем-то начинает решать за меня, какие комментарии мне читать приятнее. Но видимо, это такая черта Go-евангелистов.
> И реальность такова, что на практике проектов, которые следуют этим правилам, гораздо меньше, чем тех, которые не следуют. В Go это полностью наоборот.
Можете ли как-нибудь доказать этот тезис?
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. Можно запускать миллионы акторов на одной машине, можно — распределять по многим машинам.