Zephir - co o nim myślicie? Opcje

[JacekJagiello]

Rok temu ShadowD pisał o Phalconie, jendak chciałbym odnowić dyskusję, ponieważ trochę się zmineiło od tego czasu.

Może krótkie wprowadzenie. Phalcon jest frameworkiem PHP napisanym pierwotnie w C. Dzięki temu jest niesamowicie szybki. W "standardowych" frameworkach PHP przy każdym zapytaniu kod frameworka jest w całości interpretowany od nowa, co zajmuje trochę czasu. Phalcon jest już skompilowany, więc nie ma tego problemu. Wystarczy dodać rozszerzenie w postaci pliku dll dla serwera Aapche.
Ma to jednak swoje wady. Po pierwsze raczej mozemy zapomnieć w phlaconie na standardowych hostingach wpsółdzielonych. Potrzebujemy VPS-a gdyż tylko tam mamy możliwość instalowania własnych rozszerzeń.
Jest też problem rozwoju frameworka. Jest on stworzony dla programistów PHP, ale sam napisany jest w C. Nie każdy programista PHP zna C, a te języki mimo wszystko się różnią. Twórcy frameworka postanowili więc stworzyć własny język programowania, Zephir, który łączy cechy PHP oraz C(a także... Rust i Javascript). Trochę radykalne rozwiązanie, ale Zephir naprawdę wygląda ciekawie. I to głównie temat Zephira chciałbym poruszyć.

Zephir jest językiem zarówno typowanym dynamicznie(jak php czy javascirpt) jak i statycznie©. Zephir jest tłumaczony do C. W przeciwieństwie do PHP, Zephir wymusza pewne dobre standardy, i dodaje funkcje których w PHP brakuje, na przykład:
-Kod musi być umieszczony w klasach. Zephir jest wpełni obiektowy.
-Namespace jest konieczny
-używanie $ nie jest wymagane
-Możemy ustalić jaki typ danych ma zwracać metoda

Dzięki Zephir możemy tworzyć rozszerzenia. Więc całe nasze aplikacje możemy skompilować do C, tym samym znacznie poprawiając wydajność.
Zachęcam do oglądniecia składni zephir na http://zephir-lang.com/intro.html

Co myślicie o projekcie Zephir? Przesada, czy coś naprawdę przyszłościowego?

[irmidjusz]

OK, jakieś to wytłumaczenie jest. Chociaż ja nie rozumiem skąd się bierze ten mit trudności javy. Moim zdaniem, języki typu java/c# były tworzone głównie po to, by tworzenie aplikacji było szybkie i łatwe.

Java i PHP są oczywiście dość podobne w zakresie składni i podstawowego używania, bo to ta sama rodzina języków. Ale nie wystarczy poznać tylko składni języka!!! Programista aby efektywnie i sensownie kodować musi znać całe środowisko programistyczne, w którym pracuje. Biblioteki, rozszerzenia, narzędzia dodatkowe, frameworki, dobre sposoby kodowania (idiomy), najlepsze wzorce implementacyjne itp. To wszystko wymaga czasu i przychodzi z doświadczeniem. Nauczenie się świata Javy to jest jednak kupa roboty. Ja cały czas mam na myśli przecież doświadczonych programistów PHP. Ile czasu potrzeba, aby zostać doświadczonym programistą Java czy C#/.NET? I o ten czas mi chodzi. Taki programista PHP wie i umie wykorzystać ten język oraz wszystko to, co składa się na specyfikę programowania w PHP. Teraz poznanie i zastosowanie Hacka czy Zephira w tym kontekście, to jest pestka. Wymagany na to czas jest po prostu śmiesznie mały.

Po pierwsze, PHP jest tak bardzo wolne (po części wynika to z tego, że jest po prostu językiem interpretowanym, a po części z "błędów technicznych"), że trzeba by się mocno starać, by przepisując kod z php'a na coś innego (w dodatku natywnego) nie otrzymać dużego skoku wydajności.

No przecież właśnie o tym mówię! Użycie Zephira czy Hacka to m.in. znaczący skok wydajnościowy niesamowicie niskim kosztem - dla teamu doświadczonych pehapowców, którzy już mają napisaną (bądź piszą) sporą aplikację to są po prostu genialne narzędzia.

Podobnie w przypadku Zephyra - kompiluje się on do C, potem C jest kompilowane do kodu maszynowego.
To, na ile będzie wydajny kod napisany w zephyrze, zależy od tego jak dobrze skompiluje się kod c do kodu maszynowego (jak wyżej napisałem - każdy kompilator generuje inny kod - "inaczej wydajny"), zależy również od tego na ile wydajny jest "kompilator zephyr -> C".

Jasne! Ale i tak to jest cholernie szybsze, niż odpowiedni kod PHP, który przepisano na Zephir. I o to chodzi! Wszystkie pozostałe teoretyczne rozważania w powyższym akapicie (nie zamieściłem ich) w ogóle tu nie mają znaczenia. Wszystkie benchmarki jasno pokazują, jak daleko w tyle Phalcon zostawia czysty kod PHP (wydajnościowo).

Pisałem już kilka razy - programista PHP nauczy się korzystać z Hack czy Zephir bardzo łatwo.

Nie. Język wprowadza nowe abstrakcje, które trzeba zrozumieć.

Nie zgadzam się, aby to była trudność.
I druga sprawa, że i tak to jest pikuś w porównaniu z ogarnięciem na poziomie zaawansowanym jakiegoś innego, konkurencyjnego języka.

Poza tym wątpię, żeby ktokolwiek teraz rozumiał wydajność Hacka lub Zephira.

No to chyba trzeba zacząć ich używać i osiągnąć to zrozumienie, he? (IMG:style_emoticons/default/wink.gif)

Potrzebne są realne porównania. Zephir ma mechanizmy, których nie ma w C, tworzą one narzut. Dodatkowo język PHP nie jest binarnie kompatybilny z C, czyli odwołania do takich rozszerzeń są kosztowne. Nie wiadomo jak wygenerowany kod się optymalizuje w kompilatorze etc. Pewnie, będzie szybsze od PHP, ale to o absolutnie niczym nie świadczy. I raczej wątpię żeby był chociażby w okolicach 10 krotnego zwolnienia w stosunku do czystego C.

Tak jak wyżej - wciąż jest to znacznie wydajniej (zarówno jeśli chodzi o czas procka, jak i zapotrzebowanie na ram) niż PHP. Ale ale... czemu widzę tu takie porównywanie C i Zephir? Przecież ta dyskusja nie dotyczy tego, czy lepszy jest kod w C czy w Zephir. Dotyczy korzyści, jakie wnoszą technologie typu Zephir/Phalcon czy Hack/HHVM do świata PHP. A to, że przynajmniej Hack/HHVM wnosi, to nie mam wątpliwości, bo gdyby tak nie było, fejsbuk nie byłby przepisywany z PHP na Hack. I uważam, że Zephir/Phalcon to też bardzo obiecujące projekty. Wolisz płacić za 100 serwerów do obsługi ruchu, czy za 20? (IMG:style_emoticons/default/wink.gif)

[solificati]

Dotyczy korzyści, jakie wnoszą technologie typu Zephir/Phalcon czy Hack/HHVM do świata PHP. A to, że przynajmniej Hack/HHVM wnosi, to nie mam wątpliwości, bo gdyby tak nie było, fejsbuk nie byłby przepisywany z PHP na Hack. I uważam, że Zephir/Phalcon to też bardzo obiecujące projekty.

To jest jedna, jedyna firma, w dodatku z syndromem not invented here i dużą kasą. Nic to nie świadczy o użyteczności tego projektu. Dodatkowo f może sobie pozwolić na napisanie wszystkiego w hack. Jaki jest zysk w klasycznej aplikacji hack/zephir gdzie aplikacja spędza 80% czasu w bibliotekach? Zephir/Phalcon staje się sensownym rozwiązaniem - masz chociaż framework, ale jesteś częściowo do niego przymuszony.

Dodatkowa myśl: dlaczego do stworzenia kompilatora AOT dla PHP trzeba zmieniać język? Nie lepiej byłoby kompilować PHP a nie jakąś jego część z rozszerzeniami?

[irmidjusz]

To jest jedna, jedyna firma, w dodatku z syndromem not invented here i dużą kasą. Nic to nie świadczy o użyteczności tego projektu.

Jest jedyna, bo sami to stworzyli. Wymyślili to i zrobili, bo potrzebowali tego ze względów ekonomicznych (wydajnościowych). Nie porzucili tego projektu, przeciwnie, używają go w coraz szerszym zakresie i stale rozwijają. Benchmarki jednoznacznie pokazują, że to działa szybciej. Uważam, że to świadczy o użyteczności.

Dodatkowa myśl: dlaczego do stworzenia kompilatora AOT dla PHP trzeba zmieniać język? Nie lepiej byłoby kompilować PHP a nie jakąś jego część z rozszerzeniami?

No cóż, to już zupełnie inne zagadnienie (IMG:style_emoticons/default/tongue.gif) Jest jak jest, mamy PHP takie, jakie mamy (IMG:style_emoticons/default/smile.gif)