denisftw

В Scala абсолютно все заточено под SBT и его инкрементальную компиляцию. Если вы используете что-то другое (Maven, Gradle), то будьте готовы к тому, что время компиляции станет проблемой.

Второй момент, мало кто использует Spring (Spring Boot в том числе) из Scala - не потому что это невозможно, а потому что это глупо. В Scala-экосистеме есть решения, которые и быстрее и надежнее, и лучше вписываются в язык и т.д. Соответственно, результат изучения нового языка тоже будет не очень. Кстати, по поводу того, как разработкичи Spark'a используют Scala вот почитайте:

https://www.reddit.com/r/scala/comments/2ze443/a_g...

Лучше было бы взять SBT, Play, MacWire (и т.д.) - меньше проблем и гораздо больше пользы.

Зависит от целей. Если нужно получить теоретический обзор по всем возможным подходам, то да, можно посмотреть на книгу "Learning Concurrent Programming in Scala", которую написал Александр Прокопец из EPFL. Если интересуют более практические вещи, то это конечно лишнее.

По большому счету, основная абстракция для организации асинхронной обработки в Scala - это Future. Они типизированы, они composable, они поддерживаются практически всеми mainstream-библиотеками, описаны практически в любой книге по Scala 2.10+. Основной их минус - это то что они не lazy by design, из-за чего начинают сразу выполняться и требуют ExecutionContext для большинства операций. У Typelevel-тусовки есть множество альтернатив, которые этого недостатка лишены - ScalaZ Task, FS2 Task и наконец, Monix Task (кстати, очень хорошая документация - https://monix.io/docs/2x/eval/task.html).

Akka, как таковая, конечно не является альтарнативой Future'ам - и применяться должна весьма ограничено: Actor'ы не типизированные, не composable. Основной их use case - это долгоживущие процессы с изменяемым состоянием. STM и блокировки на Scala практически никто не использует.

Ну, самый очевидный пример - это использование готовых абстракций из ТК для интеграции некоторого кода с другими библиотеками или разных библиотек друг с другом. Я об этом немного более подробно пишу тут:

appliedscala.com/blog/2016/fp-in-java8-kotlin-scala

Если нужен конкретный пример, то вот возьмите, например, библиотеку Monix. Эта библиотека помимо всего прочего предагает такой тип как Task - что-то вроде Future, но "ленивый". Если некий код работает с Future'ми, то запихать в него Task конечно можно, но это потребует дополнительных усилий. А вот если этот код работает с type class'ом Monad (например в редакции от Cats), то проблем не будет никаких, так как и для Future и для Task можно найти/написать самому соответствующий инстанс. Здесь на самом деле используется не ТК в чистом виде, а сочетание category theory + type classes, но в Scala они всегда идут вместе.

Уровни, которые дает Одерски на старом сайте, для проверки знаний совершенно не годятся. Скорее всего он их придумал просто чтобы показать, что для продуктивного использования Скалы не обязательно лезть в дебри - может в 2011 это было акутально, сейчас любой нормальный человек это и так понимает. Критика от Тони Морриса, в принципе обоснована, но то что он предлагает выглядит ничуть не лучше.

Вообще, Скала - достаточно минималистичный язык в том плане, что там не так много специфики. Скорее, более продвинутые разработчики владеют более продвинутыми техниками и библиотеками, знают сильные с слабые стороны того или иного подхода. Юмор заключается в том, что даже среди "экспертов" не наблюдается конценсуса даже по совершенно базовым вопросам, типа "Future или Actor".

Вообще, с точки зрения изучения, Kotlin и Scala очень похожи. Здесь нужно отдать должное ребятам из JetBrains, которые не стали изобретать велосипед, а взяли очень удачный синтаксис у Scala и немного разбавили его C#-подобными фичами.

У Scala есть два преимущества - это гораздо более развитая экосистема (плюс, полноценная стандартная библиотека, как правильно заметил @Sirikid) и наличие "второго дна" в виде Typelevel-тусовки. До последнего доходят далеко не все, но если интересно, то в чисто функциональных Scala-библиотеках вовсю используются type classes и category theory и тут не то что Java 8 не подойдет - такое вообще далеко не на всех ФП-языках получится сделать.

Котлин быстрее компилируется и за счет этого может легко встраиваться в существующие Java workflow. Scala этого себе позволить не может, так как продуктивная разработка практически всегда подразумевает использование SBT - обычным Maven'ом тут не обойтись. Сейчас многие используют Котлин для Андроида, но тем не менее, писать Веб-приложения на Котлине вполне можно - об этом у меня есть книга - "Modern Web Development with Kotlin".

То что у Scala якобы проблемы с интероперабельностью с Java - это популярный миф. Например, мой самодельный блогогенератор s2gen без проблем использует как чисто Scala-библиотеки типа Monix и Circe, так и чисто Java-библиотеки типа Apache Commons, Logback и FreeMarker. Для Scala действительно написано много оберток, но это следствие распространенности языка, только и всего. Лет через пять для Котлина количество оберток будет точно таким же, если не больше - собственно, они уже появляются, например, "jackson-module-kotlin" или "RxKotlin".

Наконец, по поводу, Java. Java действительно в большинстве проектов не нужна - и Котлин, и Скала дают схожую производительность при этом увеличивая продуктивность как минимум раза в полтора. Другое дело, что есть еще организационные барьеры - научить всех разработчиков новым языкам, перевести систему сборки, CI и т.д. - но если поиск работы не является приоритетом, то это и неважно.

По моим субъективным наблюдениям, большая часть вакансий на Scala - это как раз вчерашние Ruby-шопы, которые пилят что-то на Play Framework, ну и само-собой все что связано с BigData и Spark.

По первому вопросу - конечно подходит, хотя может пока и не для фриланса.

Была недурственная презентация на SlideShare, где сравниваются Play 2 и Rails:
www.slideshare.net/danicuki/play-vs-rails

И более провокационная от инженера из SoundCloud на ту же тему:
www.slideshare.net/pcalcado/from-a-monolithic-ruby...