Wybór języka Java vs Python w Google App Engine

Obecnie Google App Engine obsługuje zarówno język Python, jak i Javę. Obsługa języka Java jest mniej dojrzała. Jednak wydaje się, że Java ma dłuższą listę bibliotek, a zwłaszcza obsługę kodu bajtowego Java, niezależnie od języków używanych do pisania tego kodu. Który język zapewni lepszą wydajność i większą moc? Proszę doradź. Dziękuję Ci!

Edytuj: http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1

Edycja: Przez „moc” rozumiem lepszą możliwość rozbudowy i włączanie dostępnych bibliotek poza ramy. Python dopuszcza jednak tylko czyste biblioteki Pythona.

Jestem stronniczy (jestem ekspertem od Pythona, ale dość zardzewiałym w Javie), ale myślę, że środowisko uruchomieniowe Python w GAE jest obecnie bardziej zaawansowane i lepiej rozwinięte niż środowisko uruchomieniowe Java - w końcu ten pierwszy miał dodatkowy rok na rozwój i dojrzewanie .

Trudno jest oczywiście przewidzieć, jak będzie dalej postępować - popyt jest prawdopodobnie silniejszy po stronie Javy (zwłaszcza, że ​​nie chodzi tylko o Javę, ale także o inne języki na JVM, więc jest to sposób na uruchomienie np. PHP lub kod Ruby w App Engine); zespół Python App Engine ma jednak tę przewagę, że ma na pokładzie Guido van Rossuma, wynalazcę Pythona i niesamowicie silnego inżyniera.

Jeśli chodzi o elastyczność, silnik Java, jak już wspomniano, oferuje możliwość uruchamiania kodu bajtowego JVM utworzonego w różnych językach, nie tylko w Javie - jeśli jesteś w sklepie wielojęzycznym, jest to dość duży plus. I odwrotnie, jeśli nienawidzisz JavaScript, ale musisz wykonać jakiś kod w przeglądarce użytkownika, Java GWT (generująca JavaScript dla Ciebie z kodowania na poziomie Java) jest znacznie bogatsza i bardziej zaawansowana niż alternatywy po stronie Pythona (w praktyce, jeśli wybierzesz Python, w tym celu sam napiszesz JS, a jeśli wybierzesz Java, GWT jest użyteczną alternatywą, jeśli nie lubisz pisać JS).

Jeśli chodzi o biblioteki, to jest to dość pranie - JVM jest wystarczająco ograniczony (brak wątków, żadnych niestandardowych programów ładujących klasy, brak JNI, brak relacyjnej bazy danych), aby utrudniać proste ponowne wykorzystanie istniejących bibliotek Java tak samo lub więcej niż istniejący Python Biblioteki są podobnie utrudnione przez podobne ograniczenia w środowisku wykonawczym Pythona.

Jeśli chodzi o wydajność, to myślę, że to pranie, chociaż powinieneś testować własne zadania - nie polegaj na wydajności wysoce zoptymalizowanych implementacji JVM opartych na JIT, dyskontując ich długi czas uruchamiania i zużycie pamięci, ponieważ silnik aplikacji środowisko jest bardzo różne (koszty uruchomienia będą często płacone, ponieważ instancje aplikacji są uruchamiane, zatrzymywane, przenoszone na różne hosty itp., wszystko to jest oczywiste dla Ciebie - takie zdarzenia są zazwyczaj znacznie tańsze w środowiskach wykonawczych Pythona niż w przypadku maszyn JVM).

Sytuacja XPath / XSLT (żeby być eufemistyczną ...) nie jest do końca idealna po obu stronach, westchnij, chociaż myślę, że może być odrobinę mniej zła w JVM (gdzie, najwyraźniej, można zmusić znaczące podzbiory Saxona do działania , z pewną ostrożnością). Myślę, że warto otwierać problemy na stronie Appengine Issues z XPath i XSLT w ich tytułach - w tej chwili są tylko problemy z pytaniem o określone biblioteki i to jest krótkowzroczność: nie obchodzi mnie, JAK zaimplementowano dobry XPath / XSLT, dla Pythona i / lub Javy, o ile będę go używać. (Określone biblioteki mogą ułatwić migrację istniejącego kodu, ale jest to mniej ważne niż możliwość wykonywania takich zadań, jak „szybkie stosowanie transformacji XSLT” w JAKIŚ sposób! -). Wiem, że wystąpiłbym z takim problemem, gdyby był dobrze sformułowany (zwłaszcza w sposób niezależny od języka).

Last but not least: pamiętaj, że możesz mieć różne wersje swojej aplikacji (używając tego samego magazynu danych), z których niektóre są zaimplementowane w środowisku wykonawczym Python, inne w środowisku wykonawczym Java, i możesz uzyskać dostęp do wersji różniących się od „domyślnej / aktywnej” "jeden z wyraźnymi adresami URL. Możesz więc mieć zarówno kod Pythona, jak i kod Java (w różnych wersjach aplikacji), aby używać i modyfikować ten sam magazyn danych, zapewniając jeszcze większą elastyczność (chociaż tylko jeden będzie miał „ładny” adres URL, taki jak foobar.appspot.com - co chyba jest ważne tylko dla dostępu dla interaktywnych użytkowników w przeglądarkach, tak sobie wyobrażam ;-).

Obejrzyj tę aplikację, aby zobaczyć zmiany w wydajności Pythona i Java:

http://gaejava.appspot.com/ (edytuj: przeprosiny, link jest teraz uszkodzony. Jednak następujący akapit nadal obowiązywał, gdy widziałem, że działa jako ostatni)

Obecnie Python i używanie niskopoziomowego API w Javie są szybsze niż JDO w Javie, w tym prostym teście . Przynajmniej jeśli zmieni się podstawowy silnik, ta aplikacja powinna odzwierciedlać zmiany wydajności.

Opierając się na doświadczeniach z uruchamianiem tych maszyn wirtualnych na innych platformach, powiedziałbym, że prawdopodobnie uzyskasz więcej surowej wydajności z Javy niż Pythona. Nie lekceważ jednak zalet Pythona: język Python jest znacznie bardziej produktywny pod względem linii kodu - ogólna zgoda jest taka, że ​​Python wymaga jednej trzeciej kodu równoważnego programu Java, pozostając tak samo lub bardziej czytelny. Ta korzyść jest mnożona przez możliwość natychmiastowego uruchomienia kodu bez jawnego kroku kompilacji.

Jeśli chodzi o dostępne biblioteki, przekonasz się, że znaczna część obszernej biblioteki wykonawczej Pythona działa po wyjęciu z pudełka (podobnie jak Java). Popularny framework sieciowy Django ( http://www.djangoproject.com/ ) jest również obsługiwany przez AppEngine.

Jeśli chodzi o „moc”, trudno jest wiedzieć, co masz na myśli, ale Python jest używany w wielu różnych domenach, zwłaszcza w Internecie: YouTube jest napisany w Pythonie, podobnie jak Sourceforge (od zeszłego tygodnia).

Czerwiec 2013: ten film to bardzo dobra odpowiedź inżyniera Google:

http://www.youtube.com/watch?v=tLriM2krw2E

TLDR; jest:

• Wybierz język, w którym Ty i Twój zespół jesteście najbardziej produktywni
• Jeśli chcesz zbudować coś do produkcji: Java lub Python (nie Go)
• Jeśli masz duży zespół i złożoną bazę kodu: Java (ze względu na statyczną analizę kodu i refaktoryzację)
• Małe zespoły, które szybko iterują: Python (chociaż Java również jest w porządku)

Ważną kwestią, którą należy rozważyć przy podejmowaniu decyzji między Pythonem a Javą, jest to, w jaki sposób będziesz używać magazynu danych w każdym języku (a większość innych punktów widzenia pierwotnego pytania została już dość dobrze omówiona w tym temacie).

W przypadku języka Java standardową metodą jest użycie JDO lub JPA. Są świetne do przenoszenia, ale niezbyt dobrze nadają się do magazynu danych.

Dostępny jest niskopoziomowy interfejs API, ale jest to poziom zbyt niski do codziennego użytku - jest bardziej odpowiedni do tworzenia bibliotek innych firm.

W przypadku języka Python istnieje interfejs API zaprojektowany specjalnie w celu zapewnienia aplikacjom łatwego, ale wydajnego dostępu do magazynu danych. Jest świetny, z wyjątkiem tego, że nie jest przenośny, więc blokuje Cię w GAE.

Na szczęście opracowywane są rozwiązania dla słabych punktów wymienionych dla obu języków.

W przypadku języka Java niskopoziomowy interfejs API jest używany do tworzenia bibliotek trwałych, które są znacznie lepiej dostosowane do magazynu danych niż JDO / JPA (IMO). Przykłady obejmują projekt Siena i Objectify .

Niedawno zacząłem używać Objectify i uważam, że jest bardzo łatwy w użyciu i dobrze pasuje do magazynu danych, a jego rosnąca popularność przełożyła się na dobre wsparcie. Na przykład Objectify jest oficjalnie obsługiwany przez nową usługę Google Cloud Endpoints. Z drugiej strony Objectify działa tylko z magazynem danych, podczas gdy Siena jest „inspirowana” magazynem danych, ale została zaprojektowana do pracy z różnymi bazami danych SQL i magazynami danych NoSQL.

W przypadku Pythona czynione są wysiłki, aby umożliwić korzystanie z API magazynu danych Python GAE poza GAE. Jednym z przykładów jest backend SQLite, który Google wypuścił do użytku z SDK, ale wątpię, czy zamierzają to przekształcić w coś gotowego do produkcji. Projekt TyphoonAE ma prawdopodobnie większy potencjał, ale nie sądzę, że jest jeszcze gotowy do produkcji (popraw mnie, jeśli się mylę).

Jeśli ktoś ma doświadczenie z którąkolwiek z tych alternatyw lub zna innych, prosimy o dodanie ich w komentarzu. Osobiście bardzo podoba mi się datastore GAE - uważam, że jest to znacząca poprawa w stosunku do AWS SimpleDB - dlatego życzę powodzenia tym wysiłkom, aby złagodzić niektóre problemy związane z jego używaniem.

Gorąco polecam Javę dla GAE i oto dlaczego:

1. Wydajność: Java jest potencjalnie szybsza niż Python.
2. Rozwój Pythona jest pod presją braku bibliotek innych firm. Na przykład w ogóle nie ma XSLT dla Python / GAE. Prawie wszystkie biblioteki Pythona są dowiązaniami C (a te nie są obsługiwane przez GAE).
3. Memcache API: Java SDK ma ciekawsze możliwości niż Python SDK.
4. Datastore API: JDO jest bardzo wolne, ale natywny Java datastore API jest bardzo szybki i łatwy.

Obecnie używam Java / GAE w programowaniu.

Jak już zauważyłeś, korzystanie z maszyny JVM nie ogranicza się do używania języka Java. Listę języków i linków JVM można znaleźć tutaj . Jednak Google App Engine ogranicza zestaw klas, których możesz użyć, ze zwykłego zestawu Java SE, i będziesz chciał sprawdzić, czy któraś z tych implementacji może być używana w silniku aplikacji.

EDYCJA: Widzę, że znalazłeś taką listę

Nie mogę komentować wydajności Pythona. Jednak JVM jest bardzo wydajną platformą pod względem wydajności, biorąc pod uwagę jej zdolność do dynamicznego kompilowania i optymalizowania kodu w czasie wykonywania.

Ostatecznie wydajność będzie zależeć od tego, co robi Twoja aplikacja i jak ją kodujesz. Wobec braku dalszych informacji myślę, że nie można podać więcej wskazówek w tej dziedzinie.

Byłem zdumiony, jak czysty, prosty i bezproblemowy jest Python / Django SDK. Jednak zacząłem napotykać sytuacje, w których musiałem zacząć robić więcej JavaScript i pomyślałem, że mógłbym chcieć skorzystać z GWT i innych narzędzi Java. Przeszedłem dopiero w połowie samouczka Java GAE i miałem jeden problem po drugim: problemy z konfiguracją Eclipse, zapalenie wersji JRE, oszałamiająca złożoność Javy oraz mylący i prawdopodobnie zepsuty samouczek. Sprawdzenie tej strony i innych linków z tego miejsca przyniosło mi sukces. Wracam do Pythona i zajrzę do Piżamy, aby pomóc mi w wyzwaniach związanych z JavaScriptem.

Trochę spóźniłem się na rozmowę, ale oto moje dwa centy. Naprawdę ciężko mi było wybrać między Pythonem a Javą, ponieważ dobrze znam oba języki. Jak wszyscy wiemy, obie strony mają wady i zalety, dlatego musisz wziąć pod uwagę swoje wymagania i ramy, które najlepiej sprawdzają się w Twoim projekcie.

Jak zwykle w tego typu dylematach szukam liczb, które potwierdzą moją decyzję. Zdecydowałem się na Pythona z wielu powodów, ale w moim przypadku był jeden wątek, który był punktem zwrotnym. Jeśli wyszukasz „Google App Engine” w GitHub od września 2014 r. , Zobaczysz następujący rysunek:

W tych liczbach może występować wiele błędów, ale ogólnie repozytoriów GAE Python jest trzy razy więcej niż repozytoriów Java GAE. Co więcej, jeśli wypiszesz projekty według „liczby gwiazdek”, zobaczysz, że większość projektów Pythona pojawi się na górze (musisz wziąć pod uwagę, że Python istnieje dłużej). Dla mnie jest to mocna argumentacja dla Pythona, ponieważ biorę pod uwagę adopcję i wsparcie społeczności, dokumentację i dostępność projektów open source.

To dobre pytanie i myślę, że wiele odpowiedzi zawiera dobre opinie na temat zalet i wad po obu stronach ogrodzenia. Wypróbowałem zarówno Python, jak i AppEngine opartą na JVM (w moim przypadku używałem Gaelyk, który jest frameworkiem aplikacji Groovy zbudowanym dla AppEngine). Jeśli chodzi o wydajność na platformie, jedyną rzeczą, której nie brałem pod uwagę, dopóki nie spojrzała mi prosto w oczy, jest implikacja „Żądania ładowania”, które występują po stronie ogrodzenia w języku Java. Podczas korzystania z Groovy te żądania ładowania są zabójcze.

Złożyłem post na ten temat ( http://distractable.net/coding/google-appengine-java-vs-python-performance-comparison/ ) i mam nadzieję, że znajdę sposób na obejście problemu, ale jeśli nie, myślę, że wrócę do kombinacji Python + Django, dopóki zimne uruchamianie żądań Java nie będzie miało mniejszego wpływu.

Opierając się na tym, jak bardzo słyszę, jak ludzie Java narzekają na AppEngine w porównaniu z użytkownikami Pythona, powiedziałbym, że korzystanie z Pythona jest znacznie mniej stresujące.

Istnieje również projekt Unladen Swallow , który najwyraźniej jest finansowany przez Google, jeśli nie jest własnością Google. Próbują zaimplementować oparty na LLVM backend dla kodu bajtowego Pythona 2.6.1, aby mogli używać JIT i różnych ładnych optymalizacji kodu natywnego / GC / wielordzeniowych. (Niezły cytat: „Nie chcemy wykonywać żadnych oryginalnych prac, zamiast tego wykorzystywać jak najwięcej badań z ostatnich 30 lat”). Szukają pięciokrotnego przyspieszenia CPythona.

Oczywiście to nie odpowiada na twoje bezpośrednie pytanie, ale wskazuje na „zamknięcie luki” (jeśli taka będzie) w przyszłości (miejmy nadzieję).

Piękno Pythona w dzisiejszych czasach polega na tym, jak dobrze komunikuje się z innymi językami. Na przykład możesz mieć zarówno język Python, jak i Javę na tej samej tabeli z Jythonem. Oczywiście jython, mimo że w pełni obsługuje biblioteki java, nie obsługuje w pełni bibliotek Pythona. Ale jest to idealne rozwiązanie, jeśli chcesz zadzierać z bibliotekami Java. Umożliwia nawet mieszanie go z kodem Java bez dodatkowego kodowania.

Ale nawet sam Python poczynił pewne kroki, które zostały pominięte. Zobacz na przykład ctypes, blisko C speed, bezpośredni dostęp do bibliotek C, wszystko to bez rezygnacji z komfortu kodowania w Pythonie. Cython idzie o krok dalej, umożliwiając łatwe mieszanie kodu C z kodem Pythona, a nawet jeśli nie chcesz zadzierać z C lub C ++, nadal możesz kodować w Pythonie, ale używaj zmiennych typu statycznego, dzięki czemu Twoje programy w Pythonie będą tak szybkie jak aplikacje w C . Nawiasem mówiąc, Cython jest używany i obsługiwany przez Google.

Wczoraj nawet znalazłem narzędzia dla Pythona do wbudowanego C lub nawet asemblera (patrz CorePy), nie możesz uzyskać mocniejszego niż to.

Python jest z pewnością bardzo dojrzałym językiem, nie tylko stojącym na sobie, ale potrafiącym łatwo współpracować z każdym innym językiem. Myślę, że to właśnie sprawia, że ​​Python jest idealnym rozwiązaniem nawet w bardzo zaawansowanych i wymagających scenariuszach.

Dzięki pythonowi możesz mieć dostęp do C / C ++, Java, .NET i wielu innych bibliotek z prawie zerowym dodatkowym kodowaniem, co daje również język, który minimalizuje, upraszcza i upiększa kodowanie. To bardzo kuszący język.

Zrezygnowałem z Pythona, mimo że GWT wydaje się idealnie pasować do rodzaju aplikacji, którą tworzę. JPA jest dość pomieszane w GAE (np. Brak @Embeddable i inne niejasne nieudokumentowane ograniczenia). Spędziwszy tydzień, mogę stwierdzić, że Java po prostu nie czuje się w tej chwili dobrze w GAE.

Jedną z rzeczy, które należy wziąć pod uwagę, są ramy, których zamierzasz używać. Nie wszystkie frameworki po stronie Java są dobrze dostosowane do aplikacji działających w App Engine, który różni się nieco od tradycyjnych serwerów aplikacji Java.

Należy wziąć pod uwagę czas uruchamiania aplikacji. Dzięki tradycyjnym aplikacjom internetowym Java nie musisz o tym myśleć. Aplikacja uruchamia się, a następnie po prostu działa. Nie ma znaczenia, czy uruchomienie trwa 5 sekund, czy kilka minut. Dzięki App Engine możesz znaleźć się w sytuacji, w której aplikacja zostanie uruchomiona dopiero po nadejściu żądania. Oznacza to, że użytkownik czeka na uruchomienie aplikacji. Nowe funkcje GAE, takie jak wystąpienia zarezerwowane, pomagają tutaj, ale najpierw sprawdź.

Inną rzeczą są różne ograniczenia GAE psoes w Javie. Nie wszystkie frameworki są zadowolone z ograniczeń dotyczących klas, których możesz używać, lub faktu, że wątki są niedozwolone lub nie możesz uzyskać dostępu do lokalnego systemu plików. Te problemy są prawdopodobnie łatwe do znalezienia, po prostu googlując na temat zgodności GAE.

Widziałem również, jak niektórzy ludzie narzekali na problemy z rozmiarem sesji w nowoczesnych frameworkach UI (mianowicie Wicket). Ogólnie rzecz biorąc, te frameworki zwykle wymagają pewnych kompromisów, aby uczynić programowanie przyjemnym, szybkim i łatwym. Czasami może to prowadzić do konfliktów z ograniczeniami App Engine.

Początkowo zacząłem pracować nad GAE z Javą, ale z tych powodów przerzuciłem się na Pythona. Moje osobiste odczucie jest to, że Python jest lepszym wyborem dla rozwoju App Engine. Myślę, że Java jest bardziej „w domu”, na przykład na Amazon's Elastic Beanstalk.

ALE dzięki App Engine sytuacja zmienia się bardzo szybko. GAE zmienia się i staje się coraz bardziej popularne, a frameworki również zmieniają się, aby obejść jego ograniczenia.