Strona główna Polish Python Coders Group
   Strona główna   Pomoc Zaloguj się Rejestracja  
Witamy, Gość. Zaloguj się lub zarejestruj.
Czy dotarł do Ciebie email aktywacyjny?

Zaloguj się podając nazwę użytkownika, hasło i długość sesji

Aktualności: PyData Warsaw :: https://pydata.org/warsaw2018/
Szukaj Szukaj
Strony: 1 2 [3] 4 5   Do dołu
Drukuj
Wątek: Czy używacie Pyramid?  (Przeczytany 23781 razy)
« Odpowiedz #30 : 22:20 25/12/17 »
sześćnocy Offline
Hello World!

Zobacz profil
*

Reputacja: -12
Wiadomości: 14


Trochę się interesowałem Elixirem i wyczytałem, że on jest dość wolny. Ma sporo zalet przejętych z Erlanga, ale kod wykonuje się stosunkowo powoli. Nie jest to demon szybkości w porównaniu z najszybszymi technologiami.

Chyba też niewiele dużych stron powstało w Elixir / Phoenix. Znacie jakieś? Może się to oczywiście zmienić w najbliższych latach. Poza WhatsApp w Erlangu specjalnie nie słyszałem o dużych projektach, a w Django czy w ogóle w pythonie trochę przecież ich wykonano.

Elixir/Phoenix to relatywnie nowe technologie w porównaniu do rzeczy robionych w php czy pythonie. Ciągle są w fazie gwałtownych zmian, nawet jeśli chodzi o samą koncepcję działania. Oprócz WhatsApp zwróć uwagę na Bleacher Report - jak widać system bardzo wymagający - wykorzystuje się to do czego erlang został zaprojektowany, niezawodność i sprawność aplikacji "real time". Pewnie można by zrobić to wszystko z javie, ale ten stack ciągle wymaga większych zasobów sprzętowych niż stack erlang/elixir/phoenix .
Z tego co wiem Pinterest przesiadł się na Elixira. Zgadnij z czego Duży uśmiech
I bardzo sobie chwalą
Ciekawie prezentuje się też Go(lang), pod względem wymagań i prędkości bije na głowę technologie spod znaku Pythona czy Ruby. I ma inne, naprawdę fajne zalety, np. kompilację do binarki. O wadach nie będę pisać, można samemu  sobie poszukać.

Co prawda jest teraz tzw. hype na Pythona, naprawdę nie wiem czym spowodowany, ale wg mojej opinii przyszłość należy do technologii, które sprawdzą się w IoT, czyli o jak najmniejszych wymaganiach sprzętowych, potrafiących obsługiwać "real time" i szybkich (response time). Takie czynniki jak produktywność mogą zejść na plan dalszy.
Tutaj chyba mamy 3 faworytów, wspomniany już stack Erlang/Elixir/Phoenix, Go, i pewnie wybije się coś na JVM, może Clojure, może Scala. A może będzie to R?

Czekałem bardzo długo na jakąkolwiek rozsądną zapowiedź czy deklarację nowych features w Pythonie 4, ale się nie doczekałem. Obawiam się, ze nie będzie rewolucji, coś jak przeskok z 2 na 3, dużo zamieszania i mało zysku

Każda z technologii ma pewien cykl życia, każda powstaje w pewnym celu i w pewnych okolicznościach. PHP był pierwszą swobodnie dostępną i tanią ofertą dla twórców dynamicznych stron www.
Railsy były pierwszym produktywnym frameworkiem (ale wiedziałem, że Ruby jako mało popularny język pociągnie to na dół, dlatego bez poczucia straty przesiadłem się na pythona)
Jak na razie widać, że takie technologie jak php, python czy ruby mają już raczej bliżej niż dalej swojego schyłku. Powstały w innym Internecie, inne zadania im stawiano, inne są teraz wymagania sieci.
To oczywiście nie znaczy, że znikną z rynku szybko, będą istnieć ze względu na masowość zastosowania pewnie jeszcze ze 20 lat, albo i dłużej. Będzie im się robić protezy unowocześniające, coś jak w Railsach obsługę "real time" czy w pythonie wprowadzenie asyncio.
Natomiast będą rzadziej wybierane jako technologie dla nowych projektów.
Oczywiście, trzeba to rozpatrywać w kategoriach możliwości i funkcji poszczególnych narzędzi. Nikt do napisania prostego bloga nie użyje JVM i Scali, bo to sensu nie ma.
A taki bottle.py znakomicie się sprawdza przy serwowaniu prostego api i serwera http (Glances).
Tak jak pisałem, do każdego zadania efektywnie można wybrać technologię.
Tak mi się wydaje, mnie Trollowi pl.python.org
 Spoko

Korzystając więc z okazji chciałbym złożyć najserdeczniejsze życzenia z okazji Świąt Bożego Narodzenia.


Alleluja i do przodu.
Nie trzymajcie się kurczowo sań, bo daleko nie odlecicie.
Zapisane
« Odpowiedz #31 : 22:43 25/12/17 »
DJangoL Offline
Professional Python User

Zobacz profil
***

Reputacja: 27
Wiadomości: 377


Wesołych Świąt!



Cytuj
Co prawda jest teraz tzw. hype na Pythona, naprawdę nie wiem czym spowodowany, ale wg mojej opinii przyszłość należy do technologii, które sprawdzą się w IoT, czyli o jak najmniejszych wymaganiach sprzętowych, potrafiących obsługiwać "real time" i szybkich (response time).

Hype na Pythona? Czy ja wiem. Python jest popularny, bo jest wszechstronny, można w nim zrobić prawie wszystko i na każdą platformę.

A co do IoT - to póki co chyba bardzo mało się dzieje w tej dziedzinie? Nie znam zbyt wielu firm działających w Internecie rzeczy, szczególnie w PL. (jakby co jest dla pythona kivy i micropython).


Cytuj
Takie czynniki jak produktywność mogą zejść na plan dalszy.

W IoT czy ogólnie?

Cytuj
Tutaj chyba mamy 3 faworytów, wspomniany już stack Erlang/Elixir/Phoenix, Go, i pewnie wybije się coś na JVM, może Clojure, może Scala. A może będzie to R?

Elixir ma nerves dla IoT. Go ma Gorobot. Na JVM też jest coś dla IoT, ale nie pamiętam nazw....ale R??? - R ma coś do zaoferowania w IoT? Albo w web dev?  Z tego co wiem to język dla obliczeń statystycznych i ML.


Cytuj
Czekałem bardzo długo na jakąkolwiek rozsądną zapowiedź czy deklarację nowych features w Pythonie 4, ale się nie doczekałem. Obawiam się, ze nie będzie rewolucji, coś jak przeskok z 2 na 3, dużo zamieszania i mało zysku

Rzeczywiście Python 4 raczej nic ciekawego nie wniesie... Ale Javovcy podobnie  narzekają, że Java 9 nic nadzwyczajnego nie wniosła (głównie moduły, REPL i kilka mniej istotnych rzeczy). C# chyba też stoi w miejscu...Uśmiech
Zapisane
« Odpowiedz #32 : 00:36 26/12/17 »
sześćnocy Offline
Hello World!

Zobacz profil
*

Reputacja: -12
Wiadomości: 14


Wesołych Świąt!



Hype na Pythona? Czy ja wiem. Python jest popularny, bo jest wszechstronny, można w nim zrobić prawie wszystko i na każdą platformę.

A co do IoT - to póki co chyba bardzo mało się dzieje w tej dziedzinie? Nie znam zbyt wielu firm działających w Internecie rzeczy, szczególnie w PL. (jakby co jest dla pythona kivy i micropython).


W IoT czy ogólnie?

Elixir ma nerves dla IoT. Go ma Gorobot. Na JVM też jest coś dla IoT, ale nie pamiętam nazw....ale R??? - R ma coś do zaoferowania w IoT? Albo w web dev?  Z tego co wiem to język dla obliczeń statystycznych i ML.


Rzeczywiście Python 4 raczej nic ciekawego nie wniesie... Ale Javovcy podobnie  narzekają, że Java 9 nic nadzwyczajnego nie wniosła (głównie moduły, REPL i kilka mniej istotnych rzeczy). C# chyba też stoi w miejscu...Uśmiech
Odpiszę Ci krótko i ogólnie, to będzie mój ostatni post na tym forum, szukałem innego community  chciałem się przekonać, czy będzie gdzie odłowić potencjalnych współpracowników. Podjąłem decyzję o przepisaniu najważniejszych swoich projektów na inne technologie. Tutaj nie ma ani czego, ani kogo szukać.
Za bardzo się skupiłeś na tym IoT. Wskazałem jedynie kierunek w którym technologie zaczną dryfować - uniwersalność i prostota staną się mniej znaczącym features, zaczną bardziej się liczyć takie cechy jak wydajność, optymalizacja, specjalizacja i koszty utrzymania systemu. R był podany jak pewnie zauważyłeś na samym końcu, nie jako przykład zastosowania w IoT ale tego, że może powstać coś zupełnie nowego i nadjeść z najmniej spodziewanej strony, albo będzie to zupełnie nowe rozwiązania, może atomizacja technologii, albo jak w przypadku Elixira bazujące na niszowej i mało popularnej platformie. Kto by się spodziewał, ze skrajnie niszowy Erlang dostanie drugie życie?
Argument, że w javie też nie ma rewolucji jest słaby - java jest tak zoptymalizowana i przygotowana na obsługę nowych technologii, że python ma się do niej nijak. Kłania się  tutaj np obsługa najnowszych wielordzeniowych procesorów.
Tak samo moja uwaga o produktywności - gdyby tylko chodziło o produktywność, to wszyscy by pisali w Railsach i Django. A jak ktoś kiedyś dawno temu stwierdził na forum Railsów - to są technologie dobre do prototypownia, w przypadku gdy projekt zaskoczy będzie wymagać przepisania na wydajniejsze rozwiązanie.

A w Polsce to w ogóle się mało dzieje. I nie bez powodu - jesteśmy technologicznie zacofanym krajem, a ze znajomych Polaków pięciu z którymi chętnie bym współpracował czterech siedzi za granicą. I nasze rządy pod tym względem to totalna beznadzieja, a i przemysł z gospodarką za słaby.
Tak to realnie wygląda.

Trzymajcie się ciepło, rączki grzecznie na kołderce.
BB
Zapisane
« Odpowiedz #33 : 02:54 26/12/17 »
DJangoL Offline
Professional Python User

Zobacz profil
***

Reputacja: 27
Wiadomości: 377


Cytuj
.....szukałem innego community  chciałem się przekonać, czy będzie gdzie odłowić potencjalnych współpracowników. Podjąłem decyzję o przepisaniu najważniejszych swoich projektów na inne technologie. Tutaj nie ma ani czego, ani kogo szukać.

Szukasz ludzi do projektów na forum pythona, jednocześnie pisząc, że python się do nich średnio nadaje ?!?  Szok  To pomyliłeś fora Mrugnięcie


Zapisane
« Odpowiedz #34 : 23:55 26/12/17 »
sztosz Offline
Expert Python User

Zobacz profil WWW
****

Reputacja: 76
Płeć: Mężczyzna
Wiadomości: 594


Trochę się interesowałem Elixirem i wyczytałem, że on jest dość wolny. Ma sporo zalet przejętych z Erlanga, ale kod wykonuje się stosunkowo powoli.

To zależy co testujesz i gdzie czytałeś, przykładowo według bardzo popularnego https://www.techempower.com/benchmarks/ tutaj https://www.techempower.com/benchmarks/previews/round15/#section=data-r15&hw=ph&test=query&l=zg1ou7&f=zg1xj3-zik0zj-zik0zf-zijzen-zhxjwf-zik0zj-zik0zj-e7 Railsowy ActiveRecord jest szybszy od czystego SQL'a w Go.

Dużo też zależy jak liczysz latency, czy to co robi sam framework od momentu kiedy zachce mu się przyjąć żądanie, czy od momentu kiedy klient rozpoczął żądanie.

Z mojego doświadczenia i z tego co czytam, wynika że na takiej samej maszynie Elixir jest w stanie zapewnić odpowiedź w rozsądnym czasie (kwestia setek milisekund) o wiele wiele większej ilości klientom na raz niż np. Cokolwiek w Pythonie czy Rubym, przy jednoczesnym na tyle wysokim poziomie abstrakcji kodu, że jest on łatwy do napisania, czytelny i zwięzły jak chociażby Python czy Ruby (albo może i nawet bardziej czytelny, ale to różnica między językami funkcyjnymi i obiektowymi, a nie chce o tym zaczynać dyskusji). Natomiast Go który być może i jest szybszy, ale jest na tyle prymitywny pod względem semantyki i po kompilacji nie daje żadnych gwarancji związanych z wykonaniem kodu bez błędów związanych z semantyką, że po krótkiej przygodzie powiedziałem sobie nigdy więcej Go. Jak mam schodzić tak nisko to zamiast babrać się w nieszczęsnym Go wolę z naprawdę czystą przyjemnością pisać w Ruście.

Ale co do frameworków, języków i ich szybkości... jak to mówią są 3 rodzaje kłamstw, małe kłamstwa, duże kłamstwa i statystyka.

Elixir/Erlang ma ogromną zaletę nad Pythonem (Rubym i mnóstwem innych języków) jeżeli chodzi o współbieżność.

Jeżeli masz jakiś trochę większy system gdzie np jest potrzebne przetwarzanie w tle, to prawdopodobnie w Pythonie bez sięgnięcia po Cellery + Redisa/Rabbita/whatever się nie obędzie. Nawet jak chcesz to samemu robić, to nie ma mowy też praktycznie o tym żeby coś robić w wątkach, trzeba sięgnąć po stosunkowo "ciężkie" procesy, do tego dochodzi standardowy problem, czyli synchronizacja pomiędzy procesami. A nawet do małych rzeczy, jeżeli potrzebujesz  zapisać gdzieś dane to albo Postgres (moze Maria) albo jakiś NoSQL (naprawdę nie chcę wdawać się w dyskusje co jest lepsze w tej materii).

Natomiast w Elixirze/Erlangu masz wszystko to od ręki dane w takiej formie że po prostu używasz i zastanawiasz się dlaczego takie rzeczy są tak trudne w innych językach. Napisanie aplikacji która będzie działała na kilku maszynach w klastrze nie nastręcza większych problemów, ponieważ nie ma żadnych problemów z synchronizacja pomiędzy wątkami, bo pamięć nie jest pomiędzy nimi w ogóle współdzielona, a sama architektura pozwala an tworzenie tysięcy lekkich wątków, które dzięki temu że to jest "pre-emptive scheduler" będą dostawały tyle samo czasu na wykonanie operacji które mają wykonać (bardziej to przypomina architekturę procesów w systemie operacyjnym, niż wątków znanych z C itp). Do większości zadań nie ma najmniejszej potrzeby korzystania z zewnętrznych narzędzi (typu Redis). A do przechowywania danych niewielkich aplikacji wystarczą też wbudowane narzędzia takie jak DETS, czy np Mnesia która jest rozproszoną bazą danych typu "key->value storage", co oczywiście nie znaczy, że mając dane z relacjami nie sięgniesz po Postgresa Mrugnięcie Do tego dochodzą mechanizmy nadzoru procesów, całe drzewa tych "supervisorów" i cała filozofia "let it crash", z resztą jeżeli będziesz chciał to możesz napisać tak aplikację, że deployment i update kodu na serwerach może się odbyć z zupełnie zerowym downtimem. Taki hotupgrade aktualizuje Ci kod bez przerwania działających procesów, tak naprawdę to możesz się połączyć przez konsolę erlangową i naprawić jakiegoś buga w cały czas działającym systemie. Nie twierdzę że to ma powszechne zastosowanie, ale wyobraź sobie np. serwer gry MMO w którym bugi są łatane bez żadnego restartu serwera czy zerwania połączenia z graczami Mrugnięcie

To też nie jest tak że uważam że Python jest zły, a Erlang/Elixir dobry. Po prostu w dzisiejszych czasach, pomijając znajomość danej technologii, bo to może mieć decydujące znaczenie przy wyborze tejże technologii, do webdev'u ani Python ani np. Ruby (w którym ostatnie półtora roku zawodowo pisałem) ani np. JS i wiele innych języków niczym szczególnym się nie wyróżnia. Nie dają te języki nic takiego co by je mogło postawić nad innymi.

Z kolei np. Rust daje szybkość na poziomie C i memory safety (C, C++ i podobne mogą o tym tylko marzyć.) A Erlang/Elixir dają concurency + fault tolerancy (o których większość innych jezyków też może co najwyżej pomarzyć)

Co do wydajności i szybkości elixira to właśnie doskonałym przykładem jest Bleacher Report https://www.techworld.com/apps-wearables/how-elixir-helped-bleacher-report-handle-8x-more-traffic-3653957/ Ale z innych, oprócz wspomnianego jest też bet365 https://sbcnews.co.uk/features/2017/05/30/erlang-solutions-functional-programming-bookies/

Wiem też, że Adobe też używa coraz więcej Elixira ale teraz nie mogę linków znaleźć, ale oni nie chwalą się swoim stackiem technologicznym, tylko po ofertach pracy było raczej widać.
Zapisane
« Odpowiedz #35 : 01:01 27/12/17 »
DJangoL Offline
Professional Python User

Zobacz profil
***

Reputacja: 27
Wiadomości: 377


Dzięki sztosz za przybliżenie zalet Elixira i Phoenixa. Na pewno dużo osób z chęcią to przeczyta (boję się nawet, że tu na forum Pythona będą jeszcze większe pustki niż dotychczas Mrugnięcie A ponoć jest hype na Pythona Uśmiech ).

Co do prędkości / wydajności, to rzeczywiście odpowiedzi na żądania odbywają się szybko (nieliczne technologie są szybsze). To co przytoczyłem to odnosiło się głównie do obliczeń (tu Erlang i Elixir wypadają przeciętnie) i pewnych zastosowań (raczej mniej związanych z web).

Do prostszych appek DJANGO wydaje mi się jednak ciekawszą opcją (choćby ze względu na panel Admina, w Elixirze dopiero powstaje exAdmin czy jak on się nazywa). Jakoś to wszystko wygląda przystępniej, a w Elixirze....no może kwestia praktyki i przyzwyczajeń.

Zalety Erlanga i Elixira podejrzewam, że można dopiero docenić przy dużych, rozbudowanych projektach web i takich które mają dużą liczbę wejść.

Może za kilka lat Elixir się mocniej przebije... O Adobe słyszałem.

Tu jest artykuł potwierdzający skalowalność Elixira:
https://blog.discordapp.com/scaling-elixir-f9b8e1e7c29b
Zapisane
« Odpowiedz #36 : 21:32 27/12/17 »
sztosz Offline
Expert Python User

Zobacz profil WWW
****

Reputacja: 76
Płeć: Mężczyzna
Wiadomości: 594


To co przytoczyłem to odnosiło się głównie do obliczeń (tu Erlang i Elixir wypadają przeciętnie) i pewnych zastosowań (raczej mniej związanych z web).
Heh, to prawda, tylko pytanie przeciętnie na tle czego? Uśmiech Nie założę się, ale biorąc pod uwagę optymalizcje erlangowej maszyny wirtualnej BEAM (bo Elixir jest kompilowany właśnie do bytecodu tej maszyny), to w większości operacji matematycznych Elixir będzie szybszy od Pythona czy Rubiego itp. Natomiast ze względu na immutability na pewno będzie wolniejszy przy skomplikowanych operacjach na macierzach. Ale tu też można i to w prosty stosunkowo sposób, tak samo jak np. Python wspierać się rozszerzeniami w C, Ruście, Ocamlu czy co tam, tak na prawdę chcesz Uśmiech

Erlang/Elixir doskonale się nadają do pisania aplikacji wszelkiego typu, gdzie poszczególne, krytyczne pod względem prędkości elementy są napisane w innych "szybkich" językach. Elixir może uruchamiać i nadzorować każdy "job" który "ciężki" obliczeniowo i wtedy odpada większość problemów synchronizacji wątków, serwerów, klastrów (gdzie pisanie tego w czystym C/C++ to jest w porównaniu do Erlanga po prostu katorga)

Do prostszych appek DJANGO wydaje mi się jednak ciekawszą opcją (choćby ze względu na panel Admina [...]
Akurat jeżeli piszemy prostego CRUD'a, to tak jak pisałem, moim zdaniem technologia nie ma znaczenia, jeżeli coś już trochę bardziej skomplikowanego to z mojego doświadczenia wynika że prościej napisać samemu panel admina, niż dopasowywać to co daje nam Django (ale może to kwestia specyfiki projektów które pisałem). Ale do prostego CRUD'a z wbudowanym prostym panelem admina rzeczywiście prościej może być pisać w Django. Ja w ogóle nie chcę negować Django czy Pythona, bo sam przez ostatnie dwa miesiące pisałem w Django + Elasticsearch (tylko że zupełnie bez żadnej innej bazy danych).

Zalety Erlanga i Elixira podejrzewam, że można dopiero docenić przy dużych, rozbudowanych projektach web i takich które mają dużą liczbę wejść.
Zalety języka funkcjonalnego z pattern-matchingiem i immutability, w stosunku do języków OO można od razu docenić... a to że Elixir jest akurat tym funkcyjnym a Python tym OO to po prostu zbieg okoliczności Uśmiech Pewne klasy problemów w tych funkcyjnych rozwiązuje się szalenie prosto, wręcz intuicyjnie, być może inne w językach OO łatwiej rozwiązywać, ale ja akurat nie trafiłem na taki i nie jest to próba polemiki tylko raczej kwestia moich osobistych doświadczeń. Jedno, gdzie zawsze łatwiej mi sięgnąć do Pythona, to proste... może nawet nie tyle proste, co jednorazowe skrypty które są odpalane raz, albo tylko w szczególnych sytuacjach i które wykonują konkretne, z góry ściśle określone zadanie.


PS. Mimo że nie mam ochoty już nigdy więcej pisać w Railsach (czystym Rubym też raczej ni) to mimo wszystko nie mam jakichś wielkich oporów żeby zawodowo pisać w Pythonie, czy konkretnie Django, nawet mimo tego że pewnie wolałbym w Elixirze czy Ruście pisać Uśmiech
Zapisane
« Odpowiedz #37 : 21:02 04/01/18 »
nuncjo Offline
Hello World!

Zobacz profil
*

Reputacja: 7
Wiadomości: 21


Nawiązując do tematu wątku i pytania..

Na Pylons/Pyramid z powodzeniem od lat hulają pewne aplikacje w bankowości obsługujące miliony klientów. To bardzo dobry framework dla kogoś kto wie dokładnie czego potrzebuje. Nie narzuca tak struktury jak inne "większe" rzeczy (Django) lub prostsze (Flask).

To framework reklamujący się jako przeznaczony dla programistów rzemieślników lubiących mieć wszystko pod kontrolą i rzeczywiście w pewnym sensie tak jest. Bardzo poważne projekty zostały na nim zbudowane i nie ma się co obawiać że zniknie.


 
Zapisane
« Odpowiedz #38 : 00:35 13/02/18 »
gr00by Offline
Hello World!

Zobacz profil
*

Reputacja: 5
Wiadomości: 36


Cześć.

Cytuj
Czy używacie Pyramid?

Tak, ale z planami rezygnacji na rzecz Django.

Pyramid jest elastyczny do tego stopnia, że sposób działania apki trzeba niekiedy oddzielnie wykładać. Po dłuższym czasie niezaglądania w kod, sam autor implementacji będzie zdezorientowany. Kolejna sprawa - znalezienie ludzi do ogarnięcia Pyramida nie jest proste. Większość kandydatów zostanie skutecznie odstraszona, a pozostali nawet nie spluną w twoim kierunku Mrugnięcie

Dobry framework, choć czasem trudny w zrozumieniu (szczególnie po grubych miesiącach przerwy w programowaniu pod niego)

Cytuj
Do prostszych appek DJANGO wydaje mi się jednak ciekawszą opcją

Do zaawansowanych też, ale dostaniesz nie raz po tyłku. Konieczne są wycieczki do raw sql lub sqlalchemy (da się to sensownie wpiąć, ale nie jako zamiennik builtina).


Cytuj
Do webdev'u to ja bym sobie w ogóle darował Pythona, w Erlangu czy Elixirze są o wiele lepsze rozwiązania i które wydajnością i łatwością użycia biją na głowę wszystko co jest w Pythonie

Pewnie zależy do czego. Najważniejsze są dane, później stabilny interfejs (np. webowy, może nawet REST-owy), na końcu implementacja warstwy aplikacji. W dużych projektach miesza się różne technologie.

Cytuj
[Elixir] Napisanie aplikacji która będzie działała na kilku maszynach w klastrze nie nastręcza większych problemów [...] Do większości zadań nie ma najmniejszej potrzeby korzystania z zewnętrznych narzędzi (typu Redis).

Cenię sobie możliwość trackowania poszczególnych jobów, w tym ich ponawiania. Z resztą  pewnie zależy o jakich jobach mowa. Nie wiem jak się robi deployment z Elixirem, ale z Pythonem trzeba sporo włożyć od siebie w skalowanie.

A czy te wątki są lekkie czy nie - może nie mieć nawet znaczenia poza benchmarkami i specyficznymi zastosowaniami. W razie braku mocy przerobowych dla background tasks dostawia się po prostu kolejne maszynki.

Z perspektywy czasu stawiam stabilność i przewidywalność na najwyższym poziomie. Truchleję na wieści o "robieniu bugfixów na serwerach liveowych". Te możliwości są fantastyczne, ale obawiam się narodzin innych problemów, szczególnie złych praktyk.

Albo Mnesia... To że jest w Erlangu i środowisku Erlanga nie czyni jej dla mnie wyjątkową, skoro (bazując na opinii ze stacka) wymaga ręcznej interwencji po padzie węzłów i generuje problemy ze współbieżnym dostępem do wierszy.  Z resztą - rozpraszanie db to nietrywialny problem, szczególnie w utrzymaniu.

Zero-downtime przy upgrade osiągam z Pythonem. Nic specjalnie trudnego. Więcej problemów tworzy drastyczna zmiana schematu db niż warstwa aplikacji.

Nie zgadzam się ze stwierdzeniem, że Python nie nadaje się do webapps. Nadaje się jak każdy inny język, który nie zezwala na arytmetykę na tekście i liczbach, i który nie dopuszcza wystawiania faktur z dniem 30 lutego.

Cytuj
Podjąłem decyzję o przepisaniu najważniejszych swoich projektów na inne technologie. Tutaj nie ma ani czego, ani kogo szukać.

Szczerze? Głupia decyzja. Podwójnie. Oparta na dyskusji na półmartwym forum oraz generująca zbędne koszty.

Dobranoc!
Zapisane
« Odpowiedz #39 : 21:53 22/02/18 »
sztosz Offline
Expert Python User

Zobacz profil WWW
****

Reputacja: 76
Płeć: Mężczyzna
Wiadomości: 594


Najważniejsze są dane, później stabilny interfejs (np. webowy, może nawet REST-owy), na końcu implementacja warstwy aplikacji.
A tu się zupełnie nie zgodzę, bo ja uważam że najważniejsza jest logika biznesowa aplikacji, później odpowiednia abstrakcja wejścia i wyjścia, a dopiero później dobudowanie takich rzeczy jak interfejs z którym współpracuje użytkownik czy warstwa utrwalania danych. To czy interfejsem użytkowania jest CLI, REST'owe API, HTML, czy cokolwiek nie może dyktować warstwy logiki biznesowej, tak samo to gdzie są zapisywane dane nie może dyktować warstwy logiki biznesowej.

Jeżeli to jak wygląda interfejs ma dyktować logikę biznesową, to niestety dodanie innego interfejsu bywa często bardzo problematyczne, a tych problemów można uniknąć, jeżeli najpierw się porządnie przynajmniej zaprojektuje logikę biznesową i interfejsy tejże logiki.


Cenię sobie możliwość trackowania poszczególnych jobów, w tym ich ponawiania.
Ale technologia a możliwość śledzenia i ponawiania to chyba problemy dość ortogonalne względem siebie.
Nie wiem jak się robi deployment z Elixirem, ale z Pythonem trzeba sporo włożyć od siebie w skalowanie.
Żeby cokolwiek sensownie skalować, zawsze trzeba trochę pracy włożyć. Ale Elixir/Erlang daje Ci na dzień dobry klocki z których łatwo właśnie coś sensownego zbudować.
A czy te wątki są lekkie czy nie - może nie mieć nawet znaczenia poza benchmarkami i specyficznymi zastosowaniami. W razie braku mocy przerobowych dla background tasks dostawia się po prostu kolejne maszynki.
Jak ktoś tak łatwo pisze o dostawianiu maszynek zawsze mnie zastanawia czy ten ktoś miał do czynienia z aplikacją na rzeczywiście sporą skalę. A jeżeli tak, to mogę tylko pozazdrościć tego, że ktoś sobie tak może maszynki dostawiać nie licząc się z kosztami. Przy, tak pi razy oko, 400 maszynach których używamy w firmie (co prawda na lwiej większości jest Go, ale to też akurat też m.in. ze względów wydajnościowych, ja w ogóle nie lubię Go), gdybyśmy mieli płacić za np. dwa razy mocniejsze maszyny, albo dwa razy więcej maszyn... no po prostu koszty są niebagatelne.

Z perspektywy czasu stawiam stabilność i przewidywalność na najwyższym poziomie.
I bardzo dobrze. Ja się przekonałem że jedną z podstaw przewidywalności jest immutability, tego niestety w Pythonie brak. A jeżeli chodzi o stabilność, to akurat systemy w Erlangu należą do najstabilniejszych. Lwia część stabilności zależy od logiki biznesowej, ale jak już sam kod pominiemy, to BEAM, czyli wirtualna maszyna Erlanga pod względem stabilności bije prawie wszystko na głowę, ale to oczywiście też zależy od tego co rozumiemy przez stabilność.
Truchleję na wieści o "robieniu bugfixów na serwerach liveowych". Te możliwości są fantastyczne, ale obawiam się narodzin innych problemów, szczególnie złych praktyk.
Ja nie truchleję, nie fixuję na live serwerach, ale możliwość wpięcia się w system i debugowania na żywo daje spore możliwości. Zgodzę się że jest to obosieczny miecz, ale mimo wszystko wole mieć taką możliwość, bo są takie systemy gdzie nie można sobie pozwolić na rolling restart, albo może koszty z tym są zwiane są tez niebagatelne.
[...]skoro [Menesia](bazując na opinii ze stacka) wymaga ręcznej interwencji po padzie węzłów [...]

Nie wymaga jeżeli poustawiasz to wszystko w konfiguracjach master-slave.
[...]i generuje problemy ze współbieżnym dostępem do wierszy.
Akurat tego za bardzo nie rozumiem, bo wszystko się tu w transakcjach standardowo odbywa (chociaż można robić dirty read/write). Ale nie ma tu większych problemów ze współbieżnym dostępem niż przykładowo w Postgresie.

Ogólnie Mnesia jest reweleacyjnym rozwiazaniem gdzie potrzebujesz key->value store,  a nie chcesz mieć kolejnego 3rd party "single point of failure", bo w sumie po co byś chciał mieć? Mrugnięcie


Zero-downtime przy upgrade osiągam z Pythonem. Nic specjalnie trudnego.
A to naprawdę chciałbym wiedzieć jak to można osiągnąć skoro przy każdej nowej wersji kodu albo restartujesz proces, albo przynajmniej zmieniasz instancję aplikacji. Też bez dodatkowych 3rd party narzędzi chyba się nie da tego obejść. Naprawdę mnie interesuje jak można zrobić zero-downtime przy upgradzie w Pythonie.

Nie zgadzam się ze stwierdzeniem, że Python nie nadaje się do webapps.
Też się z tym nie zgadzam Uśmiech Jestem mocno przekonany że są po prostu lepsze narzędzia, języki. Ale to czy warto coś nowego webowego napisać w innym języku, zależy przede wszystkim od tego jak dana osoba/team zna dobrze Pythona/Django, a jak ten nowy język/narzędzie/framework. Ja się nauczyłem Elixira dla siebie, zupełnie poza pracą zarobkową. Pisze mi się w nim szybciej i lepiej (jakość kodu, łatwość testowania mojego kodu itd) niż w Pythonie czy Rubym. Dzięki immutability i temu, że jest to język funkcyjny o wiele łatwiej mi jest myśleć o samych przekształceniach danych, bo programowanie w sumie do tego się sprowadza.
Zapisane
« Odpowiedz #40 : 13:58 23/02/18 »
gr00by Offline
Hello World!

Zobacz profil
*

Reputacja: 5
Wiadomości: 36


Cześć.

Pisałem to już kilka dni temu, więc nie wszystko mogę pamiętać, ale nie przypominam sobie abym logikę biznesową uznawał za nieistotną. Ona jest ważna z definicji. Jej implementacja może być zreazliowana różnie, także w grubym serwerze rdbms (tj. nie w warstwie aplikacji) więc ją dosyć naturalnie pomijam w rozważaniach dotyczących frameworka dla webapp.

Na pewno są wygodne czy wygodniejsze rozwiązania do skalowania. Jak już wspominałem nie potrafię porównać tego do Elixira/Erlanga. Może ma jakieś dobre klocki, ale nie zmieni to mojego spojrzenia na wypracowany (czytaj: sprawdzony) stack i posiadany codebase w py. Pewnie kiedyś wymrę wraz z innymi pythonowcami i będzie królował dajmy na to Erlang, ale póki co wolę rozwiązania przewidywalne (czytaj: znane mi, łatwo supportowalne). W tym konktekście parę ułatwień, np. w postaci istnienia "gotowych klocków", nie przekonują mnie do wymiany całej warstwy czy architektury.

Zero-downtime deployment w py możesz robić prymitywnie przez restarty węzłów w sekwencji, gdzie na przodzie masz sensowny balancer. Ale są też ciekawe opcje w samym uWSGI (The Art of Graceful Reloading). Tak, są konieczne zewnętrzne (względem Py) narzędzia, ale co z tego?

Nie, nie mówię ani o 10-ciu ani o 400-tu węzłach. Mówię o relatywnie niskim koszcie zwiększenia zasobów sprzętowych w stosunku do zysku z użycia technologi w jakimś % bardziej optymalnej. Z resztą Erlang nie jest wprost porównywalny z Pythonem, bo wydajność czy skuteczność będzie zależeć od wielu czynników. A jeśli masz aż takie wymagania, gdzie liczy się każdy kb i każda ms, to używaj tego co się najlepiej nadaje. Natomiast tam, gdzie ta wydajność nie jest krytyczna, takie różnice w praktyce nie mają znaczenia.

Zapisane
« Odpowiedz #41 : 15:18 23/02/18 »
sztosz Offline
Expert Python User

Zobacz profil WWW
****

Reputacja: 76
Płeć: Mężczyzna
Wiadomości: 594


[...] nie przypominam sobie abym logikę biznesową uznawał za nieistotną
Może źle rozumiem to co napisałeś: "[...]na końcu implementacja warstwy aplikacji." Na pewno dla mnie najmniej ważne jest to jakiego frameworka, bazy danych, czy interfejsu użytkownika się użyje.

ale nie zmieni to mojego spojrzenia na wypracowany (czytaj: sprawdzony) stack i posiadany codebase w py.
Tak z ciekawości wypadało by się zatem zapytać, a w ilu rożnych językach pisałeś, ile technologii chociaż liznąłeś. Zawsze lepsze jest wrogiem dobrego. Akurat erlang jest starszy od Pythona i od samego początku był nastawiony na rozwiązywanie problemów związanych z dostępnością i niezawodnością (w rozumieniu usług sieciowych) i rozwiązuje te problemy cholernie dobrze. Python z GIL'em, oraz tym że wątek może zablokować cały process to nawet nie jest ta sama liga, jeżeli mowa o sprawdzonym stacku.

I tu nie chodzi o to że ja jestem jakimś wrogiem Pythona. Tylko jakiś czas temu zacząłem sięgać do innych technologii, czy języków poza Pythonem/Rubym czy to ile liznąłem C++/Java/C#. Wyszedłem poza swój tzw. "comfort zone" i otworzyły mi się oczy. I im więcej pisałem w tych "egzotycznych" językach, tym bardziej się okazywało, że większość da się napisać i lepiej i szybciej. Jeżeli język daje Ci na starcie pewne gwarancje, a wcale nie sprawia że jesteś mniej wydajny, to nie widzę powodu dla którego miałbym używać języków które tych gwarancji nie dają.

W tym konktekście parę ułatwień, np. w postaci istnienia "gotowych klocków", nie przekonują mnie do wymiany całej warstwy czy architektury.

Nie, nie mówię ani o 10-ciu ani o 400-tu węzłach. Mówię o relatywnie niskim koszcie zwiększenia zasobów sprzętowych w stosunku do zysku z użycia technologi w jakimś % bardziej optymalnej.

Ja też bym nie przepisywał całego codebase'u dla kilku procent. Ale jeżeli trzeba coś nowego napisać, to nie widzę powodów dla których nie wybrać czegoś co jest relatywnie lepsze.

Zero-downtime deployment w py możesz robić prymitywnie przez restarty węzłów w sekwencji, gdzie na przodzie masz sensowny balancer. [...] The Art of Graceful Reloading
Ale to nie jest zero-downtime deployement. Co w sytuacji kiedy masz na serwerze sesję, masz np. kilku klientów spiętych przez serwer ze sobą. Niech to będzie nawet głupi chat, albo rozmowa głosowa. Jak sobie w Pythonie z tym poradzisz? Zero-downtime deployment to jest wtedy kiedy deploymnet nie przerywa istniejących procesów/wątków, ale każdy nowo tworzony korzysta już z nowego kodu. Mrugnięcie

Natomiast tam, gdzie ta wydajność nie jest krytyczna, takie różnice w praktyce nie mają znaczenia.
Jeszce jakiś czas temu bym się być może z tobą zgodził, ale takie myślenie doprowadziło do tego że mamy wysyp aplikacji elektronowych. Odpal kilka takich (które normalnie powinny zajmować po kilkadziesiąt MB ramu max) i masz już zawalony cały ram w systemie. Ja miałem taką sytuację że na służbowym Macbooku Air z 4GB ramu nie byłem już w stanie po prostu pracować. Koniec końców skończyło się na tym, że przyniosłem prywatnego, desktopa do biura żeby normalnie dało się pracować, właśnie przez to że developerzy nie myślą o wydajności.

Zapisane
« Odpowiedz #42 : 15:49 23/02/18 »
gr00by Offline
Hello World!

Zobacz profil
*

Reputacja: 5
Wiadomości: 36


W ilu językach? Jak ja lubię mierzenie członków..  asm 6502, 680XX, ia32, basic atari, amos, blitz,, c, c++, c#, java, php, python, javascript, krótko w rubym i objective c, cholera... nie pamiętam wszystkiego. Ale to o niczym nie świadczy, z resztą większości nie znam już ani biegle albo nie pamiętam, a poza tym większość nie ma za wiele wspólnego ze współczesnymi webapps. ...foxpro, visual basic, prolog, pascal/delphi... Bardziej istotne jest runtime env, cały stack, niż sam język.

GIL jest słabą stroną Pythona, fakt - tam gdzie masz do czynienia z obliczeniami. W webapps najczęściej wąskim gardłem jest I/O, a tu threads z gilem są ok. O ile wiem są jakieś implementacje Pythona bez GIL, ale mało mnie to (już) obchodzi.

Tak, gdybym miał robić coś from scratch i nastawione na obliczenia w chmurze, to pewnie rozważałbym coś innego. Ale do tego co się w większości robi w kontekście webapps, po prostu nie ma takiej potrzeby. Mało tego nie widzę problemu w mieszaniu różnych rozwiązań, zatem do moich projektów możesz dorobić cloud computing w Erlangu. Cokolwiek na websockets mogę oprzeć o nodejs (lub coś innego - Erlang?), bo szczerze mówiąc te hacki pythonowskie mnie wkurzają.

O jakich sesjach mówisz przy zero-downtime? HTTP jest stateless, więc jeśli procesy zamykasz gracefully, to end user nie zauważy żadnego restartu. Nie wiem jak jest z websockets, ale coś tam uWSGI wspiera. Nie stosuję websockets.

Nie jestem ani wrogiem Erlanga ani ewangelistą Pythona. Po prostu Py też obsłuży dużą ilość wejść (to był czyjś tam, twój?, argument).  Może przesiadłeś się z Py na Erlang za wcześnie, tj. nie znając analogicznych rozwiązań po jego stronie i teraz Erlang wydaje się być lekiem na całe zło. Albo miałeś inne potrzeby. Na pewno każdy język i każde środowisko ma swoje wady i zalety. Dla mnie istotnym czynnikiem jest też ilość kandydatów na programistów w danym języku.

 
Zapisane
« Odpowiedz #43 : 15:59 23/02/18 »
gr00by Offline
Hello World!

Zobacz profil
*

Reputacja: 5
Wiadomości: 36


A propos interfejsu i tego wątku z logiką biznesową. Są dwie cholernie istotne rzeczy w całym tym gównie - dane i publiczny interfejs (interfejs systemu dla otoczenia, nie jakieś tam API warstwy aplikacji). Dane, bo przeżyją nie jednego pytona, erlanga i wszelakie mutacje warstwy aplikacji. Interfejs, bo wszystkie zintegrowane systemy powinny działać niezależnie od zmian pod spodem, gdyż ich fail to fuckup wizerunkowy oraz kosztowy.
Zapisane
« Odpowiedz #44 : 18:06 23/02/18 »
sztosz Offline
Expert Python User

Zobacz profil WWW
****

Reputacja: 76
Płeć: Mężczyzna
Wiadomości: 594


W ilu językach? Jak ja lubię mierzenie członków.. 

Tu nie chodzi o mierzenie członków tylko o nabranie pewnego dystansu. Jest ogromna rzesza programistów którzy nie spróbowali nigdy napisać w niczym innym poza JS i są święcie przekonani że JS to lek na całe zło. A naprawdę poznanie wielu języków bardzo poszerza horyzonty.

[...]websockets [...]
Tutaj Phoenix w Elixirze bije chyba na głowę wszytko co znam. Ale websockety to jest ogólnie bardzo trudny problem w większości języków, ze względu na to że ogólnie jakakolwiek współbieżność jest w nich trudna.

O jakich sesjach mówisz przy zero-downtime? HTTP jest stateless, więc jeśli procesy zamykasz gracefully, to end user nie zauważy żadnego restartu. Nie wiem jak jest z websockets, ale coś tam uWSGI wspiera. Nie stosuję websockets.
Ale HTTP to jest tylko protokół, to że protokół jest stateless, nie oznacza że aplikacja musi być stateless. Tak naprawdę w dzisiejszych czasach aplikacja nie może byś stateless bo to daje za małe możliwości i z zasady klientom się nie ufa Mrugnięcie Tak więc to że de fakto sesje (czyli dane które są spersonalizowane dla danego "klienta") trzymasz w bazie danych i przy każdym requeście HTTP odczytujesz i zapisujesz je do bazy nie sprawia że aplikacja jest stateless, to raczej jest efekt uboczny tego, że po pierwsze większość języków nie ma odpowiedniego wsparcia dla utrzymywania sensownej ilości procesów w pamięci, a po drugie nie ma żadnego fault-tolerancy i jeden wątek/proces z błędem/bugiem powoduje że się wywala cała aplikacja zamiast tylko ten konkretny proces.

Tak więc utrzymywanie sesji w aplikacji sieciowej czy stricte webowej nie jest niczym dziwnym jeżeli popatrzysz na to z ogólnej perspektywy. Owszem utrzymywanie sesji w pamięci może się
wydawać dziwne w Pythonie, ale to dlatego że Python sobie zupełnie z czymś takim nie poradzi, jak będziesz chciał obsłużyć np. na raz stosunkowo niewiele, powiedzmy 10K procesów w Pythonie, to albo maszyna Ci tego nie wytrzyma, albo co jest o wiele bardziej prawdopodobne, w Pythonie sobie po prostu nie poradzisz z synchronizacją i nadzorowaniem od strony aplikacyjnej tego wszystkiego.

Owszem dla zwykłych prostych CRUD'ów to i w PHP można pisać czy nawet w VB.NET, jak ktoś ma duże doświadczenie w VB (ja bym sobie prędzej żyły podciął). Co nie zmienia faktu, że jak aplikacja przestaje być trywialna, to naprawdę warto spróbować wyjść poza swój "comfort zone" i użyć narzędzi bardziej odpowiednich. 

Może przesiadłeś się z Py na Erlang za wcześnie, tj. nie znając analogicznych rozwiązań po jego stronie i teraz Erlang wydaje się być lekiem na całe zło.
Akurat ja się przesiadłem z Pythona na Rubiego, a potem, jak miałem dość, to wróciłem dla jednej apki którą w spadku dostałem, do Pythona, a że była problematyczna i wiele rzeczy nie działało w niej wcale, to przepisałem ją po kawałku prawie od zera w Pythonie, ale jak trzeba było napisać nowe rzeczy czy też przepisać logikę już istniejących to się okazało że  prototypy w Elixirze nie dość że działają sprawniej (wydajniej), to są czytelniejsze i łatwiejsze w testowaniu.

Dla mnie chyba największym skokiem jakościowym jest przesiadka z języków OOP na język (języki) funkcyjne.

Są dwie cholernie istotne rzeczy w całym tym gównie - dane i publiczny interfejs [...] wszystkie zintegrowane systemy powinny działać niezależnie od zmian pod spodem.

Zgadzam się. Dlatego ani logika biznesowa nie może być uzależniona od tego jak przekazujesz dane, bo to gdzie trzymasz dane nie może być powodem do przepisywania całej aplikacji. Tak samo zmiana w logice biznesowej nie może wpływać bezpośrednio na to jak wygląda interfejs przez który się użytkownik końcowy komunikuje. A żeby nie miał to wpływu, to musisz mieć odpowiednio wyabstrahowane wewnętrzne interfejsy logiki biznesowej których używasz w tworzeniu interfejsu dla użytkownika. Jeżeli najpierw napiszesz interfejs "użytkownika" a później logikę biznesową, to prawie zawsze jest niepotrzebnie ściśle ze sobą powiązane, bo zamiast wypracowywać model działania aplikacji zgodny z dziedziną której aplikacja dotyczy, wypracowujesz modele które są wygodne dla "użytkownika" końcowego, gdzie są wymieszane i ściśle powiązane obiekty które należą do zupełnie innych dziedzin danego problemu.

Co do samych danych, to większość aplikacji ma często zupełnie inne potrzeby co do tego jak te dane powinny być przetwarzane, a inne jeżeli chodzi o to jak powinny być prezentowane. Ideałem jest wtedy posiadać osobne miejsca gdzie się trzyma dane które są przetwarzane, i osobną hurtownie danych z której przetworzone dane są raportowane.

Oczywiście dla prostych aplikacji to jest niepotrzebne komplikacja bo modele są łatwe do ogarnięcia w rozumie, ale programiści którzy niestety nauczyli się pisania prostych aplikacji od tworzenia schematów baz danych (czy to w kodzie aplikacji, czy na papierze czy w UML to już znaczenia nie ma), te złe nawyki przenoszą dalej i skomplikowane systemy też zaczynają od tego gdzie i jak przechowywać dane, albo w jaki sposób wyświetlać dane, zamiast zająć się na początku core problemu, czyli tego jak my chcemy te dane przetwarzać. Bo jakby nie patrzeć, nas jako użytkowników systemu interesują już przetworzone dane.
Zapisane
Strony: 1 2 [3] 4 5   Do góry
Drukuj
Skocz do:  

© 2007 - 2018 Polish Python Coders Group
Powered by SMF 1.1.21 | SMF © 2006-2009, Simple Machines | Theme by PixelSlot