Как стать автором
Обновить

Комментарии 27

Судя по фамилиям в списке людей, внесших вклад в релиз этой версии, у Scala в СНГ очень даже неплохие перспективы.
Ну и за новость спасибо. Это хорошая, годная новость.
Недавно обратил внимание на такое явление как «локальная» популярность языков по странам. Например, у меня создалось впечатление, что в Китае очень популярен язык Go, может быть даже более чем PHP.
Или на то, что во всем мире Groovy более популярен чем Scala. Java на порядок более популярна чем Javascript опять же. Однако читая хабр складывается впечатление что на острие прогресса находятся совсем не они. Две с половиной статьи про тот же groovy. Странно как то. Разве он хуже Scala? Что скажете, евангелисты Scala? Сравнивали ли вы их?
Как тут не упомянуть вот эту цитату:

I can honestly say if someone had shown me the Programming in Scala book by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy.
(с)James Strachan

Я сравнивал. Groovy — прикольное дополнение к java. Но даже близко не дотягивает до Scala. Более осмысленно Java-8 со Scala сравнивать, чем Groovy.

Если интересно — могу расписать.
Да, интересно. А то обычно все обсуждения сводятся к этой цитате и в «scala болше фич». Фич конечно больше, но разве они решают в конечном счете? Давайте сравним легкость вхождения, читабельность кода, поддержку в ide, количество и качество фреймворков, развитость комьюнити.
Ну тут же не только синтаксис решает.
У них например разница в производительности существенна.
Ну и статическая типизация многое дает.
Вы холивар решили устроить? Так всегда пожалуйста =)

1. В scala поддержка ФП и immutable структур данных (и удобная работа с ними), отсюда крайне удобная работа с многопоточностью и асинхронностью.

2. Scala — набор лаконичных концепций. Groovy — набор фич.
Например одни и те же методы для работы с Option, коллекциями, Try, Future, etc…

3. На Groovy REPL без слез не взглянешь после Scala. А это крайне полезный инструмент для экспериментов.

4. Статическая типизация с выводом типов очень упрощает работу. Ну и да, быстродействие.

5. Мне документация по Scala показалась гораздо более удобной. Но это, возможно, дело вкуса.

По вашим пунктам:

1. «легкость вхождения» — это вам в PHP. Мне на вхождение в scala понадобилось 2 недели на чтение 1 книги и нескольких статей.

2. «читабельность кода» — мне гораздо проще читать код в immutable стиле — меньше держать в уме приходится. Ну и да, типизация очень помогает.

3. «поддержку в ide» — для scala есть IDEA (не только она, но я другими не пользовался). А вот для groovy полноценная поддержка где-нибудь есть? С гарантированным выводом типов, проверкой корректности вызова методов, рефакторингом с возможностью, например, переименовать метод класса во всем коде (не трогая одноименные методы других классов)?

4. «количество и качество фреймворков» — в scala множество оберток над java-фреймворками и своих собственных. Учитывая не совпадение вкусов, холивар на эту тему совершенно безыдеен.

5. «развитость комьюнити» — заходите на огонек. На SO в 3 раза больше вопросов по Scala, чем по Groovy. Чтобы ответить первым на простой вопрос надо уложиться в 5 минут — через 15 уже будет несколько ответов. Есть, конечно, вопросы на которые ответ найти сложно. Единственный мой вопрос, связанный с groovy, так и висит не отвеченным.
Еще пару русскоязычных Skype-каналов могу подсказать.
Вообще мне интересно. Оставлю и свое впечатление для сравнения.

Да, согласен, в Scala гораздо больше возможностей «из коробки». В Groovy приходится использовать библиотеки. Но это одновременно и минус. У меня осталось ощущение что Scala похожа на мультипарадигменную кашу из всего на свете. По Groovy достаточно посмотреть по диагонали что он может чтобы понять как этим пользоваться. Час vs 2 недели на изучение.

Он медленнее, но теснее интегрируется с явой. Можно написать критичный низкоуровневый код на яве.

Скала плагин под идею это отдельная боль. Scala compiler has complex type system, which is not implemented in scala plugin yet, until this will be implemented, you can't see all compiler errors on the fly (like in Java or Groovy). Он же не совместим с текущим релизом комьюнити едишен? А я пишу и под андроид. Я начинаю нервничать когда половина кода подчеркнуто красным, но на самом деле там все в порядке. Медленная компиляция вымораживает. Какие то странные чудесатые глюки, когда код не работал, пока я не удалил и не написал заново строку, промучавшись с этой непонятной ошибкой несколько часов. Сами идеевцы говорят что со скалой все так непросто, потому что язык слишком запутанный и неоднозначный. Сложный проще говоря. Поэтому они и начали разработку Kotlin. Типа такой простой Scala. Для меня это стало решающим фактором в конечном счете, после которого я перескочил на груви-ява связку.

Насчет количества вопросов — я расстроен( Правда по груви до сих пор просто вопросов как то тупо не возникало. А по Scala — да, гуглил отчаянно чтобы тупо понять что происходит в этом участке кода. Наверно у меня мозг уже поражен явой(
Да, согласен, в Scala гораздо больше возможностей «из коробки».

В scala из коробки не возможности, а идеология и расширяемость. Сейчас уже даже стандартную библиотеку растаскивают на куски.
В scala огромное количество библиотек, причем благодаря метапрограммированию и системе типов библиотекой можно реализовать очень многое, чуть ли не изменить сам язык. Богатейшие возможности по созданию DSL.

Он медленнее, но теснее интегрируется с явой.

Scala интегрируется с java несравнимо лучше. 1 плагин к мавену и можно в java-проект добавлять scala. В любой же scala проект (sbt) можно добавлять java по умолчанию. И при этом можно использовать scala-классы из java. Единственное ограничение — неудобно использовать implicit из java и наследоваться от trait. Не невозможно, а неудобно. Большей же частью scala совместима с java в одном проекте в обе стороны.

Можно написать критичный низкоуровневый код на яве.

Кроме того, что в любой scala проект можно добавлять java классы, можно еще и просто писать на scala в java-стиле, получая ту же производительность при сохранении части преимуществ scala.

you can't see all compiler errors on the fly (like in Java or Groovy)

Учитывая, что компилируемость кода на груви в силу его динамической природы ни о чем не говорит…

Медленная компиляция вымораживает.

Меня устраивало, но, учитывая, что в 2.11 повышение скорости компиляции заявлено одной из основных целей, спорить не буду.

Сложный проще говоря.

Сложный он для компиляции. Идеевцам надо фактически реализовать компилятор заново. В scala на компилятор переложили очень многое для упрощения работы программиста, так что да, реализовать IDE не просто, но это не моя проблема.
Мне текущей поддержки в IDEA хватает. Она заведому лучше, чем возможна поддержка любого динамически типизированного ЯП.

Ну а котлин… по мне он, как и груви, — набор фич, вместо набора концепций. И поддержка неизменяемых структур данных слабовата. И возможность к расширению подкачала. А компилировать его проще, но мне это как-то безразлично. Он, конечно, лучше груви, но не думаю, что они догонят по популярности хотя бы scala.

А количество вопросов — не главное, главное — количество и скорость ответов, то есть поддержка сообщества. По scala меньше не отвеченных вопросов, больше отвечающих.
спасибо, конструктивно
Он же не совместим с текущим релизом комьюнити едишен?

Пару недель назад все работало.
Я как раз бы сказал, что сильная сторона Scala в том, что многие «фичи языка» на самом деле библиотеки. Просто они идут в поставке с компилятором, но сила в том что не мешает сделать свои новые.

Многие из проблем описанных вами (особые сложности в системе типов, быстрая компиляция, итд) должен решить новый компилятор(правда для чуть-чуть другого языка) github.com/lampepfl/dotty
Разве dotty в случае успеха не собирались слить со скалой? Так что язык будет не другой.
У меня язык не поворачивается сказать, что это тоже язык(хотя я и scala 2.6 не назвал бы scala 2.11, разные они), когда за ним другая теория типов, другие возможности и ограничения.

Большинство кода, который был написан для Scala 2.11 будет валидным Dotty кодом. Но — если вы используете «черные стороны Scala» (например структурные типы или early definition) — Dotty намеренно этого лишена.

Также будет небольшое количество отличий логики (в частности lazy vals по умолчанию не treadsafe а volatile lazy val намного быстрее чем в scala и намного более deadlock-proof), для решения большинства которых пишется migration tool.
Спасибо за информацию!
Где-нибудь можно про lazy val почитать подробнее? Ясно, что повторное вычисление в большинстве случаев не проблема, но как будет обеспечиваться безопасная публикация?
началось все тут,
docs.scala-lang.org/sips/pending/improved-lazy-val-initialization.html
Оригинальная идея авторства Alexander Prokopec.
Я ее «перенял», чуть подкрутил, подтюнил, и реализовал. Потом было обсуждение тут
groups.google.com/d/msg/scala-internals/4sjw8pcKysg/GlXYDDzCgI0J

Подробное описание будет, когда Dotty будет «хоть в каком то смысле стабильна». Сейчас может все еще поменяться.
Спасибо.

Поведение по умолчанию без безопасной публикации выглядит несколько пугающе. Не ожидаешь на immutable объекте получить гейзенбаг. Надеюсь, что в итоге останется только безопасное поведение.
Груви чем хорош, он может быть одновременно и javascript'ом и java'ой — за счет опциональной типизации. Очень напоминает Dart в этом плане.
Еще одна заманчивая особенность — полнейшая динамичность. Например, не только резолвинг методов выполняется по типу получателя (виртуальность, как в java), но и резолвинг методов по типу сигнатуры в runtime (мультиметоды, как в obj c, smalltalk). В общем-то из за такой сверх-динамичности на груви весьма удобно городить всякое метапрограммирование и DSL. В ущерб скорости, конечно, но всегда можно тормозящее написать на java.
НЛО прилетело и опубликовало эту надпись здесь
Уже обсуждали этот вопрос в IRC, но к определённым выводам так и не пришли, поэтому спрошу здесь: а в чём заключается поддержка Java 8 в компиляторе Scala?
так генерация байткода с нужным magic-намбером и лямбдами + поддержка новых jdk классов в JavaConvensions, не?
Самый известные:

Новый способ генерации байткода для лямбд: SI-8359.
Не требовать определять default методы: SI-7825, а в идеале реализовывать через них трейты.
А где можно почитать историю scaladotnet и о том, почему решили не допиливать поддержку .NET framework?
Добрый день,

Про апогей по данной теме можно найти здесь, а насчет почему прекратили, я к сожалению пруф линк найти не смог, но я видел статью где говорилось о консолидации сил для более перспективных направлений, и где так же говорилось что если вы хотите запускать код scala на .net вы можете воспользоваться ikvm.
Лично общался с разработчиком .net frontend-а.
Если коротко — в тот момент dotNet был очень сырой(32 и 64 версии вели себя очень различно, даже баги были местами разные), плохо шел на контакт, да и интереса большого он похоже не вызвал.

Человек, который над этим работал сейчас уже покинул команду, и работает над внутренностями будущих JVM
Еще убрали arity limit > 22 с case classes. А еще Scala Actors deprecated в пользу Akka
Отличная новость, буквально неделю назад пытался найти дату релиза, так и не смог. Скажите пожалуйста, это я плохо искал, или она было очень глубоко спрятана?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации