Programovací jazyk Hack (diskuse)

[Ilfirin]

Ty bláho. Chtělo by to přejmenovat C na Cool a Lowrider Lifestyle Virtual Machine.

[koudy]

Jsem pro, konečně bych programoval v něčem zajímavým...

I když opravdoví tvrďáci překládají v Greatest (Norris Unified) Chuck Compiler. (sorry anglicky to je asi hrozná bl*ost :) )

Takový brainfuck zní super, ale zkuste si v tom něco napsat :)

[gsnak]

Nestastne zvolene meno, vygooglit nieco je porod.

[unavensluncem]

hacklang?

[xkucf03]

+1

[njn]

timhle smerem jdou ale vsechny jazyky. jen nektere o dost pomaleji, ale diky tomu, ze je prejazykovano bude rust pocet balastu a jalovych polo-odpovedi na vyvojarskych forech, ktera se do vysledku primychaji a maji podobny ucinek.

[kralyk z abclinuxu]

Hmm, celé by to mohli sloučit zpátky do PHP, pořádně pročistit standardní knihovnu a udělat z toho PHP6. Jenže to už je skoro možná méně práce udělat novej jazyk

[Bystroushaak]

Hmm, celé by to mohli sloučit zpátky do PHP, pořádně pročistit standardní knihovnu a udělat z toho PHP6

Myslíš PHP7. PHP6 už tu bylo a na rozdíl od ostatních verzí, které byly faily jen z poloviny, to byl fail úplný. Viz: And the winner is... a PHP RFC: Name of Next Release of PHP.

Další pikantní zajímavosti z mrzáckého života PHP viz lolphp.

[kralyk z abclinuxu]

ROFL, tomuhle jazyku už nic nepomůže. Kill it with fire. Problém je, že hosting pro tuhle platformu je stále směšně levný a stále se v PHP píše dobrý software... Osobně mám taky ještě rozdělaný jeden projekt s php částí (ale pomalu pokukuju, čim to nahradit...).

[snajpa]

PHP nikam nepujde minimalne do doby, nez se v jinem jazyce podari uspechy (z hlediska rozsirenosti) jako Wordpress, Drupal, Magento a podobne. Sranda je, ze je spousta lidi, kteri tyhle CMS pouzivaji denne a tak nejak pomalu ani netusi, ze jsou v PHP (vlastni zkusenost, kdyby jednou, jsou jich desitky).

[Olaf]

Proto už skoro vše dělám ve spustitelném pseudokódu jménem Python. :) Jeho webové frameworky je radost používat. Nevím, proč ty hostingy nepodporují i Python, vždyť je v základu každého unix-like systému.

[mirec]

Python má svoje vlastné problémy.

[Bystroushaak]

Proto už skoro vše dělám ve spustitelném pseudokódu jménem Python. :) Jeho webové frameworky je radost používat. Nevím, proč ty hostingy nepodporují i Python, vždyť je v základu každého unix-like systému.

Python se dá provozovat na levných VPS, kde jsou ceny už od stovek korun ročně (ta moje třeba stojí cca 600kč/rok).

[kralyk z abclinuxu]

ta moje třeba stojí cca 600kč/rok

Link prosím?

[Bystroushaak]

hukot.net (ten promo kód platí i příští rok).

[kralyk z abclinuxu]

Dík

[trekker.dk]

Nevím, proč ty hostingy nepodporují i Python, vždyť je v základu každého unix-like systému.

Možná vám to přijde divné, ale hostovat PHP je MNOHEM jednodušší než hostovat třeba Python nebo Ruby.

Pro PHP se snadno zajistí běh v FastCGI režimu - na straně Apache je mod_fcgid, na straně PHP se spustí interpreter php5-cgi a je to. Každý proces běží pod systémovým uživatelem specifickým pro konkrétního klienta, což je bezpečnější a mimo jiné to umožňuje, aby si lidi nemohli vzájemně koukat do dat. A dokonce to mohlo bez problémů běžet se zapnutým safe_mode, když ještě existovalo. Ta nejdůležitější výhoda je ale v tom, že specifický interpreter pro CGI režim umožňuje běh aplikace navržené pro mod_php (což je AFAIK častější případ), aniž by se ta aplikace musela měnit.

Neříkám, že pro Python/Ruby neexistuje CGI režim - existuje, ale aplikace mu musí být přizpůsobená. Teda aspoň podle toho, co jsem našel na netu, tak vždycky v aplikaci byla nějaká smyčka čekající na FastCGI požadavky. To v PHP aplikaci nutné není. A ve chvíli, kdy je víc možností a nejsou vzájemně kompatibilní, jsou to komplikace - klient si něco nahraje na server, ono to nefunguje, protože to není přizpůsobené prostředí, musí se to řešit a výsledkem je třeba to, že klient i provozovatel služby tráví zbytečně tráví čas něčím, co se nakonec nevyřeší a klient odchází jinam, což obě strany stálo čas.

Další věc - u PHP lze v konfiguraci nastavit spoustu věcí týkajících se interpreteru. Třeba zakázat funkce, které nechci, aby se používaly. Nechci, aby se procesy forkovaly a zůstávaly viset v systému? Zakážu pcntl_ funkce. Chci zakázat spouštění věcí shellem - pryč s shell_exec a spol. Nestojím o to, aby si procesy mohly vytvářet naslouchající sockety? Pryč se socket_listen. Pokud něco takového jde udělat v Pythonu/Ruby, tak jsem to nenašel. Totéž třeba pro maximální dobu běhu nebo zabranou paměť.

Jasně, tohle všechno jde udělat mimo ten interpreter. Ale je to práce navíc a ne úplně málo - třeba co se týče toho disable_functions = socket_listen, tak jediná alternativa, která mě napadla, je zavřít ten proces do vlastního net namespace. Který se pak nějakou virtuální síťovkou musí zapojit do skutečné sítě, aby se ta aplikace dostala na net, když odtud něco potřebuje. A odchozí spojení NATovat.

Že je něco v systému nainstalované, je fakt jenom drobný detail. Jo, zjednoduší to práci, když si člověk staví server pro svoje vlastní weby. Ale mezi tímhle a (dobře udělaným) hostingem je kus cesty.

[pavlix]

To bude asi tím, že nemá smysl srovnávat na web zaměřené PHP s obecným Pythonem, ale na web zaměřené PHP s nějakým konkrétním způsobem vystavení Pythonu, i kdyby tím konkrétním způsobem měl být právě FastCGI. Jediná věc, která je na PHP z hlediska hostování dobrá, je že je tak zkurveně omezené, že prostě nikdo nepočítá s tím, že by se mohlo používat i nějak jinak. Bohužel má spoustu dalších vlastností, které způsobují, že aplikace nemusí na hostovaném PHP vůbec běžet a to ani při dodržení verze.

Pokud jde o omezování různých akcí, tam bych dal přednost omezování na úrovni OS spíš než na úrovni runtime, už jen proto, že omezování na úrovni OS se může používat pro všechny možné runtime a tím je mnohem lépe otestované. V tomhle ohledu je jistě stále, co dohánět, ale technicky vzato ty možnosti už existují.

[trekker.dk]

To bude asi tím, že nemá smysl srovnávat na web zaměřené PHP s obecným Pythonem, ale na web zaměřené PHP s nějakým konkrétním způsobem vystavení Pythonu

Proč bych měl porovnávat nějaký "konkrétní způsob vystavení"? U PHP je to jedno, ergo je v tomto pohledu (= snadnost provozu na hostingu) lepší než Python, kde to musím řešit. To je celé.

Bohužel má spoustu dalších vlastností, které způsobují, že aplikace nemusí na hostovaném PHP vůbec běžet a to ani při dodržení verze.

Jasně, když se aplikace udělá tak, že jakmile to běží na localhost při vývoji, je to hotové, tak se snadno může stát, že při nahrání někam na hosting fungovat nebude. Osobně bych tohle spíš viděl jako pozitivum, protože to odfiltruje skripty, jejichž autorovi nevadilo, že za běhu spotřebují půl giga RAM.

A o tom, jak moc na prd je PHP jako jazyk, se dohadovat nechci. Mluvil jsem jenom o to, že je mnohem jednodušší hostovat PHP než Python.

Pokud jde o omezování různých akcí, tam bych dal přednost omezování na úrovni OS spíš než na úrovni runtime ... tomhle ohledu je jistě stále, co dohánět, ale technicky vzato ty možnosti už existují.

No když ty možnosti existují, tak to já se rád poučím. Jak byste řešil tohle: cílem je omezit některé funkce a u jiných omezit, s jakými parametry je lze volat. Abych byl konkrétní, chci (pro začátek) zcela zakázat fork(), execve() a omezit bind() tak, aby jej bylo možné volat pouze se socketem typu AF_INET, SOCK_STREAM, přičemž smí být použito jenom jedno konkrétní číslo portu a adresa. Omezující podmínky: použité řešení musí být v mainline a nestojím o žádné triky s LD_PRELOAD.

Pokud vím, výše popsané umí akorát tak seccomp2, které je momentálně ve vývoji a - pokud s tím za poslední dobu nepohnuli - na nějaké brzké začlenění to nevypadá.

[petr_p]

SELinux.

[Bystroushaak]

Proč bych měl porovnávat nějaký "konkrétní způsob vystavení"? U PHP je to jedno, ergo je v tomto pohledu (= snadnost provozu na hostingu) lepší než Python, kde to musím řešit. To je celé.

U PHP to také není PHP jako jazyk, ale PHP jako web framework (kde je například $_GET a echo vypisuje na výstup k uživateli, ne na terminál na serveru). Proto je dobré nehledat Python jako jazyk, ale nějaký python web framework.

[tacoberu]

Z pohledu programátora: na PHP proti Pythonu je zásadní typehinting. Ducktyping je pro mě prostě konečná.

[Radek Miček]

To se vám bude líbit PEP 484 a mypy.

[little.owl]

Zajimave. Guido van Rossum mi prisel vzdy jako skalni obhajce duck typing a ted tohle. Vitam to.

[Bystroushaak]

Tohle přece duck typing pythonu nebere, jen to přidává možnost, která zde nebyla. Osobně se mi to nelíbí, protože chudáci programátoři, kteří budou dostávat do rukou kód, kde je po někom takhle najavíno.

[little.owl]

To nerikam, jen me prekvapilo, ze jeden z predkladatelu.

[Radek Miček]

Guido k tomu psal mail.

[mirec]

No ruby sa dá celkom dobre automatizovať (bundler funguje dobre, dokonca knižnice môžu byť zdieľané). U pythonu je pip izoolovaný, aplikácie teda nemôžu zdieľať rovnaké verzie knižníc, beh python weboevej aplikácie je tak o niečo náročnejší. Napr. slovenský websupport bez problémov podporuje RoR (v admine sa dá vyklikať), ale uwsgi s pythonom 2.6 si treba požiadať u adminov (je to bezplatne).

[snajpa]

Rejpava, ale spojeni Websupport a "bez problemov" mne fakt uprimne rozesmalo

[pavlix]

Neměl bys rýpat do „konkurence“. :)

[snajpa]

Asi ne, no :)

[mirec]

Neviem aké problémy s tým majú ostatní, ja som to riešil so supportom (keďže na python nemajú vo webadmine rozhranie), mám tam asi 5 projektov a v každom prípade boli schopní po poslaní požiadavky nastaviť wsgi do hodiny. Jediné problémy boli v mojej aplikácii ale to som si poriešil sám, len som vždy uistil podporu že error 500 pochádza z mojej aplikácie a to si už poriešim sám. Inak to funguje stabilne a rýchlo.

[trekker.dk]

Krom toho "bez problemov" pro uživatele ještě nemusí znamenat, že je to dobře udělané. Slyšel jsem i o hostingu, kde všechny Rails weby běžely pod www-data

[Bystroushaak]

Neříkám, že pro Python/Ruby neexistuje CGI režim - existuje, ale aplikace mu musí být přizpůsobená. Teda aspoň podle toho, co jsem našel na netu, tak vždycky v aplikaci byla nějaká smyčka čekající na FastCGI požadavky.

Pro python existuje WSGI, kde není zapotřebí dělat nějaké velké přizpůsobení. Ale CGI mi přijde dost lowlevel. Osobně teď používám bottle.py, ale znám lidi, kteří si velmi pochvalují Django (zde není problém sehnat docela levný hosting).

Další věc - u PHP lze v konfiguraci nastavit spoustu věcí týkajících se interpreteru. Třeba zakázat funkce, které nechci, aby se používaly. Nechci, aby se procesy forkovaly a zůstávaly viset v systému? Zakážu pcntl_ funkce. Chci zakázat spouštění věcí shellem - pryč s shell_exec a spol. Nestojím o to, aby si procesy mohly vytvářet naslouchající sockety? Pryč se socket_listen. Pokud něco takového jde udělat v Pythonu/Ruby, tak jsem to nenašel. Totéž třeba pro maximální dobu běhu nebo zabranou paměť.

Kdysi jsem uměl většinu z těhle nastavení obejít. PHP hostingy jsou totiž často tak děravé, že je to spíš vyjádření přání, než vynucení nastavení.

[pavlix]

Ale CGI mi přijde dost lowlevel.

To by ničemu nevadilo, spíše jde o to, že CGI stojí na principu, že co požadavek, to proces. A to je značně limitující a v kombinaci s pomalu se načítajícím software (větší knihovny v pythonu, etc) a omezeným hardware (hosting, slabší virtuál, starší hardware) vražedná kombinace. Pro obecné použití potřebuješ něco ve stylu FastCGI/WSGI.

[trekker.dk]

v kombinaci s pomalu se načítajícím software (větší knihovny v pythonu, etc) a omezeným hardware (hosting, slabší virtuál, starší hardware) vražedná kombinace.

Tipnul bych si, že s CGI by vám větší web napsaný v Pythonu neustál návštěvu Seznambota a podobných ani se silným hardware.

[mirec]

O čo je iný hosting pre django než hosting pre bottle? Oba bežia prevažne na wsgi.

[Bystroushaak]

Bottle má podstatně nižší nároky, než django. Je to minimální framework (celý zdrojový kód má ~3000 řádek), který toho zas tak moc nenabízí, ale na spoustu věcí stačí. Django je kanon na vrabce, dobrý třeba na podnikové systémy a tak.

[mirec]

Poznám oba i keď v poslednej dobe už aj na embedded používam django, pri troche snahy sa z toho dajú vyhádzať zbytočnosti. Zaujala ma ale táto časť (nezaznamenal som špeciálne hostingy na django s lepšou cenou než na bottle keďže deploy robím rovnako):

velmi pochvalují Django (zde není problém sehnat docela levný hosting).

[Bystroushaak]

Ah, tak já tohle mám jen zprostředkovaně, sám v djangu nedělám (což je docela škoda, bráchovi jsem v něm teď dohodil zakázku za 50k, která mohla být moje :D). Co jsem teď rychle vygooglil, tak třeba: roští, kde píšou od 1,70 Kč/den.

[pavlix]

Cena hostingu je tak jako tak prakticky nulová položka.

[trekker.dk]

Pro python existuje WSGI, kde není zapotřebí dělat nějaké velké přizpůsobení. Ale CGI mi přijde dost lowlevel. Osobně teď používám bottle.py, ale znám lidi, kteří si velmi pochvalují Django (zde není problém sehnat docela levný hosting).

No dobře. Tak mi řekněte, když vezmete svoji aplikaci s tím bottle, a dáte ji na hosting, kde se používá WSGI, bude to fungovat? Když vidím ten příklad na úvodní stránce, tak se mi zdá, že ne, protože ta aplikace bude očekávat sítové spojení a HTTP požadavek, ne CGI přes unix socket. Hosting si vás jako zákazníka může škrtnout nebo nabízet dvě varianty nastavení, jednu s WSGI, druhou s tím bottle.

U PHP nic takového není potřeba řešit. Když vezmu PHP aplikaci a pustím ji na serveru, kam jsem jako masochista nainstaloval mod_php, bude fungovat. Když ji pustím ve FastCGI režimu, bude fungovat. Když rozběhnu php-fpm a Apache se k tomu bude připojovat přes TCP, tak to furt bude fungovat. Proto si můžu vybrat jednu variantu a jedna je míň než dvě, ergo je s tím míň práce než s tím Pythonem. U kterého navíc musím řešit to, co jsem psal výše, tj. jak vám s tím bottle zabránit naslouchat na libovolném portu, který si usmyslíte.

[Bystroushaak]

No dobře. Tak mi řekněte, když vezmete svoji aplikaci s tím bottle, a dáte ji na hosting, kde se používá WSGI, bude to fungovat?

Pokud to bude předpripraveno na bottle, tak ano. Jinak to bude chtít nějakou tu konfiguraci (cesty a tak). Viz Apache mod_wsgi.

[trekker.dk]

Měl jsem na mysli WSGI na straně Pythonu a mod_fcgid na straně Apache, tedy třeba tohle https://blogs.oracle.com/oswald/entry/good_idea_python_with_fastcgi (první odkaz v Google). Nastavení Apache je dané, bude na tom fungovat ten kód, který jste linkoval?

Abychom se tu netočili v kruhu. Nemusíte mi tady vysvětlovat, jak věci jdou udělat a jak nastavit Apache, aby to fungovalo s tím kterým nejúžasnějším řešením, které zrovna někdo vymyslel. To si v případě potřeby najdu. Moje argumentace se celou dobu zabývá pouze tím, že konfigurace hostingového serveru pro provoz PHP je jednodušší než konfigurace Python hostingu, a to je důvodem, proč je nabídka PHP hostingů větší. Pokud se mnou nesouhlasíte, ukažte, jak je jednodušší nakonfigurovat Python hosting, ne jak zkonfigurovat Apache pro django.

[pavlix]

Není potřeba. Obojí je to natolik jednoduché, že bych se zabýval pouze poptávkou.

[trekker.dk]

Obojí je to natolik jednoduché

To mi přijde spíš jako tvrzení než jako argument...

[pavlix]

Přeber si to dle vlastních potřeb.

[trekker.dk]

Přebírám si to tak, že vám argument chybí.

[pavlix]

V pořádku, každý má právo na svůj názor.

[trekker.dk]

Kdysi jsem uměl většinu z těhle nastavení obejít. PHP hostingy jsou totiž často tak děravé, že je to spíš vyjádření přání, než vynucení nastavení.

Doufám, že jste to taky hlásil jako chyby upstreamu.

[Bystroushaak]

Doufám, že jste to taky hlásil jako chyby upstreamu.

To bych šel sám proti sobě.

[trekker.dk]

Tím se u mě řadíte na úroveň zmrdů, co hledají (nebo zanášejí) do open source aplikací chyby, aby je pak mohli prodat.

[Bystroushaak]

Ještě štěstí, že je mi to jedno.

[pavlix]

+1

Navíc je to nesmysl. Zanášet chyby do projektů je sabotáž, tedy činnost zcela odlišná od nechání si zjištěné chyby pro sebe.

[trekker.dk]

Činnost je odlišná, výsledný stav je stejný - v open source projektu je chyba, kterou může najít a zneužít někdo další.

[kralyk z abclinuxu]

Stejně by to pravděpodobně bylo označeno za NOTABUG. Většina těhle věcí jsou v PHP feature.

[trekker.dk]

Problém je, že hosting pro tuhle platformu je stále směšně levný a stále se v PHP píše dobrý software...

Ono je to jednoduché. PHP hosting je levný, protože je to masová záležitost se spoustou klientů. Větší trh a víc návodů na netu umožňuje kdekomu rozjet si LAMP server na nějaké VPS a nabízet ho komerčně (třeba tak, že někomu udělá web = nainstaluje wordpress a rovnou ho dá na svůj server.) Víc uživatelů znamená větší zájem a tím pádem víc vývojářů, takže se projekty v PHP víc rozvíjí a umí toho víc, než alternativy v jiných jazycích. Lidi pak shání web, najdou si wordpress, vidí, že to umí spoustu věcí a vyžaduje PHP, tak shání hosting s PHP. A kruh je uzavřený.

A z finančního pohledu je to taky jednoduché - pokud si uděláte server s PHP, snadno seženete spoustu klientů, můžete dát menší cenu a furt se to zaplatí. Server s Rails, Pythonem a spol. tak rychle a snadno zákazníky nenajde, takže se nevyplatí kvůli nákladům ztracené příležitosti, nebo musí být dražší.

[pavlix]

A sehnat si pár PHPkářů taky není úplně drahé :).

[trekker.dk]

No, za poslední dobu mi přijde, že se neshání PHPkáři, ale instalátoři wordpressů

[njn]

php6 a cistka v knihovne uz tu probehla. jeste stesti, ze se nechytnul ten gramaticky fasismus OOP a zvitezil zdravy rozum stavajicich uzivatelu. kdyz se to jemenuje php, tak je to aspon zarukou relativne stabilniho neidiotsky prehypovaneho vyvoje na vlnach modnich trendu.

https://philsturgeon.uk/blog/2013/01/php-6-pissing-in-the-wind/

[Olaf]

"Supr" název. Trošku mi to připomnělo německou heavymetalovou kapelu Trance založenou v 70. letech. Chudáci si ze zjevných důvodů museli později změnit jméno. Zvolili Trancemission, aby se za čas takto jmenoval taneční festival (bez "e").

[pushkin]

Zrovna jsem chtěl připsat, že být vývojářem, tak na to ani nesáhnu. Leda, že by napsali HeavyMetal Virtual Machine

[Odin1918]

Hack? Hiphop? Kdo je autorem? Nejaky zastydly geek||nerd?

[mirec]

No hack aspoň celkom vystihuje jazyk ;)

[little.owl]

Dalsi jazyk, a jeste s takovym nazvem ...

Zacina to vypadat, ze pokud kdejaky IT megamoloch netlaci svuj jazyk, neni patricne 'technologically advanced'.

Jako by nam na vsechno nestacil Lisp ... .

[Rovnej kšilt rulezzz]

Hopec kámo
tak na čem frčíš?
Na Cracku? Já na Hacku.
Krutá smažka.
Peace!

[pavlix]

Někdo radši BSD.

[njn]

a ti co jeli na BSOD uz jsou tuzi.

[xkucf03]

I tohle je důvod, proč se víc zamýšlet nad výběrem názvu pro jazyk nebo VM