Scala i Lift on GAE

Opublikowane przez Jarosław Zabiełło Mon, 13 Apr 2009 04:32:00 GMT

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

Tagi , , , , , , , , , ,  | 3 comments

Comments

  1. Avatar Jan Koprowski powiedział about 1 hour later:

    Skoro Google App Enginge będzie wspierał Scalę to popularność tego języka naprawdę wzrośnie.

  2. Avatar Jiima powiedział 2 days later:

    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ć…

  3. Avatar Hubert Łępicki powiedział 3 days later:

    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ą.

(leave url/email »)

   Pomoc języka formatowania Obejrzyj komentarz