Scala i Lift on GAE
Opublikowane przez Jarosław Zabiełło
Google opublikowało listę języków i javowych frameworków dostępnych dla swojego GAE (Google App Engine). Na liście jest m.in. JRuby, Jython, Groovy i Scala. Z powodu ograniczeń dostępności do wątków i JDBC napisano, że Lift nie jest wspierany. Jak jednak można wyczytać z jednym ostatnich wątków na liście dyskusyjnej Scali, trochę pośpieszono się z tą informacją. Lift daje się odpalić na GAE (to jest fork do kodu źródłowego). Scala posiada dwa rodzaje Aktorów – opartych na natywnych wątkach OS oraz opartych na asynchronicznej pętli, bez użycia wątków. Lift nie potrzebuje więc obsługi wątków do swej pracy. Co do JDBC, to sprawa jest trochę mętna, bo udało się uruchomić Lifta na pamięciowej bazie H2. Być może ograniczenie Google’a dotyczy tylko baz relacyjnych?
Updated: Frameworks and libraries supported by Google App Engine Java : List
Kanały RSS
Skoro Google App Enginge będzie wspierał Scalę to popularność tego języka naprawdę wzrośnie.
Ostatnio InfoQ twierdziło że Scala i Lift są wspierane. Oczywiście, mapper O/R Lifta nie ma szansy pójść, gdyż jest to active record oparty na JDBC co mija się z celem w wypadku GAE (jedyny dostępny “magazyn” danych to BigTable). Za to można używać JPA / JDO, więc nie wiem o co jest zamieszanie (wprawdzie nie jest lekko z posługiwaniem się tymi API z poziomu Scali, ale obiekty JPA / JDO to na ogół “anemic models” / “dumb entities” więc można sobie rączki ubrudzić i kawałek kodu w Javie napisać, Lift wspiera takie podejście, vide rozdział o wykorzystaniu Hibernate w Lift Book). Za to ciekawą inicjatywą jest wsparcie Clojure. Nie wiem wprawdzie po co – Clojure jest w końcu przede wszystkim językiem programowania współbieżnego, ale przynajmniej większy kawałek świata ma szansę dowiedzieć się że w ogóle coś takiego jak Clojure istnieje. No i JRuby działa, a podobno i najnowsze Rails, tak przynajmniej twierdzi Ola Bini, a jemu akurat w tej materii wierzę. Sam jeszcze nie mam dostępu do javy na GAE by sprawdzić.
A’propos umieszczonej w Blipie uwago co do PHP 5.3 – rzeczywiście ciekawe, zainteresowało mnie to jakieś pół roku temu jak zaczęto mówić o PHP 5.3. Tyle że niestety to za mało. GC jest OPCJONALNY czyli na ogół będzie wyłączony, zwłaszcza na shared hosting. O semi – trwałych frameworkach takich jak np WSGI można więc jedynie pomarzyć. Wsparcie dla namespaces jest cool, ale co z tego skoro gigantyczna biblioteka standardowa ich nie używa, a PHP podobnie jak Python jest dość analno-retencyjny jeśli chodzi o złamanie wstecznej kompatybilności. Najważniejsza zmiana w efekcie to obiekty funkcyjne, choć obawiam się że ceną za nie będzie mniejsza wydajność niż funkcji “starego typu”. Poza tym taka zmiana zasługuje na poważniejszy numerek niż 5.3, większość adminów nie będzie tego chciała wdrożyć…
Z tym ograniczeniem co do bazy danych to jest troszkę gorzej niż myślisz. Baza danyuch w pamięci nie zda egzaminu z prostego względu: aplikacje na GAE mogą się “przemieszczać” pomiędzy maszynami googla bez Twojej wiedzy, to samo tyczy się kopiowania i odpalania większej liczby instancji. BigTable to jedyne działające rozwiązanie na chwilę obecną.