Я думаю, что важно не упаковывать в Scala слишком много функциональности. Самостоятельно расширить Scala очень легко, так что давайте сделаем это на некоторое время. Затем, когда какой-нибудь фреймворк станет победителем, он может поставляться вместе со Scala.
Тем из вас, кто пострадал от результатов комитета JCP, пожалуйста, помните о бедствиях преждевременной стандартизации.
Тем не менее, у меня есть свой список желаний :-) Я бы хотел простой DSL для Date. Тот, что из книги DPPs, подойдет.
Внезапно:
Хороший мост scala <-> JDBC. Хороший фреймворк для насмешек. Оболочка Scala для Spring DI.
В произвольном порядке:
Scala-версия библиотек Clojure Incanter была бы действительно очень удобна и, вероятно, могла бы быть даже лучше в использовании, чем Clojure.
Было бы также исключительно здорово, если бы параллельная версия библиотеки коллекции 2.8 была готова к (сегодня!) Выпуску 2.8, а не дожидалась выпуска 2.8.1. Еще круче было бы что-то с мощью и ощущением библиотеки коллекции 2.8, которая переносила вычисления на что-то вроде Hadoop.
Было бы очень хорошо поддерживать стандартную библиотеку для программной транзакционной памяти.
Подключаемый модуль IntelliJ IDEA для Scala - потрясающая работа, но (что неудивительно) по-прежнему отстает от Java в некоторых неприятных моментах, особенно в отчетах об ошибках на лету.
Необходимо создать несколько стандартных прокладок, чтобы различные «корпоративные» библиотеки (Spring / Hibernate / Ibatis / Freemarker и т. Д.) Могли использовать объекты Scala без разброса аннотаций @BeanProperty вокруг и без использования объектов коллекций Java.