Scala je fajn jazyk, ale co se týče komplexity, nezadá si s C++. Osobně mám raději Clojure, který je (z jazykového hlediska) mnohem jednodušší - byť křivka učení pro většinu lidí bude strmější - jedná se o LISPový jazyk a nejlepší vývojové prostředí je Emacs (heh, Netbeans Platform framework jsem se naučil dřív než kombo Clojure+Emacs!).
Ale do typického korporátního prostředí plného patlalů (téměř) bez základního vzdělání bych to nedával - tohle chce (minimálně "zatím") malý tým motivovaných lidí, ne prostředí, kde o nasazených technologiích rozhodují manažeři, kteří o nich nemají ani páru a používat to budou i lidé, kteří v životě nečetli ani GoF Design Patterns.
Sorry, ale z hlediska hledání zaměstnání v ČR to není nejlepší volba.
Java EE "is here to stay". Jak už zaznělo - korporátní prostředí chce stabilní vývojové prostředí a v naší firmě (za stěnou máme Javisty; já jsem .Neťák) vidím projekty v Java EE 5 (teď je nejnovější 7; Java 8 je stále jen ve verzi SE). Prostě 10 let staré aplikace musí fungovat, když odejde člověk, musí se rychle zaučit nový (nováček v produkci = s*ačka ve verzovacím systému; se s*ačkou v Javě se pracuje mnohem lépe než ve Scale nebo v Clojure - jednoduchý, "bezpečný" (minimálně přítomnost garbage collector nutná), silně staticky typovaný jazyk s dobrým vývojovým prostředím (které podporuje automatický refaktoring) je nutnost). A hlavně žádné časté změny, každá novinka zvyšuje finanční náklady (musí se zaučit stávající lidi + ti, kteří to za 10 let budou udržovat, přijdou do kontaktu s nekonzistentním kódem - někde se bude dělat "po novemu" a jinde "po staru"). Nicméně TOHLE je častá realita běžného života, ne žhavé novinky. Je to úplně jiný svět než lze vidět na weblozích nadšenců píšících o nejnovějším server-side JavaScript frameworku, mnozí z nich si nikdy nesáhli na aplikaci s delším životním cyklem než 2 roky od zrodu do hrobu. A v .Netu to není jiné, já jsem nedávno dostal na stůl úpravu ASP Classic (technologie nevyvíjená snad 15 let!) aplikačky, která stále běží v produkci. V posledních 10 letech se o to nikdo moc nestaral a vystřídala se na tom kupa programátorů, kteří tu technologii v životě neviděli (jako třeba já). Podle toho ten kód vypadá - s*anec jak cyp. Nikdo to nebude přepisovat - dokumentace neexistuje a nejsou peníze na vývoj nové. "Welcome to corporations." Volba technologie není o tom, co chcou lidi dělat a jak chctějí profesně růst, ale jak manažerům vyjdou čísla - ostatně programátoři jsou čísla v položce "náklady" a to ne zrovna malá čísla.
Spring Framework je hodně oblíbený (ale spíš na menších projektech) a byť ke svému běhu potřebuje "jen" Java SE (takže lze využít Java
, je zaměřený na podobnou klientelu, která by jinak nejspíš sáhla k Java EE (EJB+ESF). Spring 4 rozhodně není o tunách XML kódu a přehnaných složitostech, Spring Boot dokáže dokonale "vykopnout" (funkční aplikačka během pár vteřin), dokumentace je fajn (i pro mě - člověka rozmazleného z MSDN) a hostování na serveru je záležitostí spuštění příkazu "java -jar myKillerApplication.jar". Byl jsem velmi mile překvapen. Když jsem hledal kvalitní hosting pro malou triviální aplikaci (která ale musí běžet furt, jinak přijdu o "reputaci"), zjistil jsem, že ceny cloud serverů jsou velmi podobné cenám lepšího hostingu - tak co bych se (byť i na triviální web) štval s nějakým PHP nebo platil licence za Windows, když mám tohle zadarmo. Radost pracovat. Jenomže tohle je "můj kšeft", můj server (na kterým si dělám co chci já) a náklady jdou z mojí kapsy - úplně jiný svět než korporace.
O Wicketu je též hodně slyšet. Ale je to trochu jiná liga než Spring - Spring chce být kompletní náhrada za Java EE a Spring MVC je MVC framework, Wicket je čistě webový framework s komponentovou architekturou (ne MVC). Wicket je tedy framework na "vyšší úrovni abstrakce" než Spring MVC (což podle mě není dobře, ale názory se různí - JSF je též komponentový fwk). Znáš-li Play, zkus Spring MVC přes Spring Boot. Je to asi tak nejblíž (už jsem zmínil - přes Spring Boot si můžeš vybrat, jestli výstup bude .jar s integrovaným kontejnerem nebo .war - je to otázka drobné změny v pom.xml).