Здравствуйте, vaa, Вы писали:

vaa>Scala тоже университетский проект. к слову.

Да, я в курсе. Это язык, в котором специально хотели сделать самую сложную систему типов. Сложную — с теоретической точки зрения. Её дальнейшее разрешение очень быстро приводит к неразрешимым системам (Тьюринг-полная система с проблемой останова). И долгое время язык искал себя.

Потом в 2010-м году (шесть с половиной лет языку) в Scala 2.8 добавили акторы. На них прекрасно ложатся некоторые специфические задачи с глобальным изменяемым состоянием. Использование сопоставления с образцом (pattern matching) является большим преимуществом при написании обработчика всяких сообщений (в Java был бы длинный if/else-if с проверками типов и прочими гадостями). Продвинутая система типов здесь совсем не при делах (акторы вообще принимают нетипизированные сообщения, akka typed с контролем типов сообщений появилась гораздо позже). Полезны только case classes для определения сообщений.

В 2011-м году выходит Scala 2.9. Команда основывает компанию Typesafe (теперь уже Lightbend) для коммерческой поддержки языка. И это было одним из решающих факторов в дальнейшей успешности языка. Компании берут Scala для использования акторов и активно предоставляют обратную связь и запросы на улучшение через коммерческую поддержку. В результате в 2013-м году выходит Scala 2.10. Из нее выкинуты акторы (которые реализуются библиотекой). Зато добавлено много языковых возможностей, включая строковую интерполяцию (string interpolation), динамики (dynamics) и прочий полезный сахар. Посмотреть можно здесь. Именно этот набор изменений сделал язык очень удобным для практических задач. А higher kinds является просто дополнительным бонусом, который можно использовать, раз уж он есть. Я лично не уверен, что готов был бы агитировать за использование Scala 2.9 в реальной компании. Там для практических задач (прочитать из базы, отправить json) не так много преимуществ по сравнению с Java было бы. А вот в 2.10 улучшения заметны и на Java я обратно ну совсем не хочу.

Хотя сложная система тоже сыграла свою роль. Добавлять типизацию для новых синтаксических конструкций было бы очень больно. Поэтому все новые возможности в 2.10 сводятся к преобразованию кода в вызов функций. Оно может быть в несколько этапов (for-comprehension + implicit conversion + implicit resolution, например). Но зато в вычислительной модели там по сути лямбда-исчисление и еще несколько специальных конструкций (блоки, if, while, do, скобки, объявления в блоках, try/catch/return, match). На этом фоне типичная для Java экосистема Spring кажется жутко сложной. Там все на аннотациях, которые обрабатываются черной магией по своим правилам.

Так что Scala в современном виде сложилась в результате обработки обратной связи, возникшей при применении языка для решения узкого класса практических задач. Для Flix пока не хватает какого-нибудь убедительного примера, использующего его основные возможности. Ну например, сделать алерты на основе входящего потока метрик. Алерты записывать как предикаты на прологе, метрики — читать из каналов и генерировать факты. И показать, что, например, можно это делать лучше, чем в существующих системах мониторинга (проще читать или можно выразить гораздо больше полезных условий). Или сделать какой-нибудь автоматизированный поиск основной причины отказа. Например, упала база. Из-за нее упало два сервиса. А потом по цепочке упало еще двадцать. В типичном мониторинге будет 23 красных сервиса. А хотелось бы одну красную базу и 22 "оранжевых" (не работают, но проблема скорее всего не в них) сервиса. И вот чтобы топологию и критерии "root cause" описывать на прологе, а потом к этому прикручивать ввод/вывод через каналы. Задачи мониторинга сейчас как раз актуальны. И ограничения языка (отсутствие полиморфизма, например) здесь не важны. И вот уже на основе реальных применений можно было бы тоже понять, что получилось хорошо, а что еще стоило бы улучшить.