PDA

Pogčedajte punu verziju : Twitter on Scala


nixa
07. 04. 2009., 03:31
http://www.artima.com/scalazine/articles/twitter_on_scala.html

Ovo je kao poručena tema za jablana :)

Dragi Tata
07. 04. 2009., 15:37
[url]
Ovo je kao poručena tema za jablana :)

Posebno ovaj deo:
": I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now."

jablan
07. 04. 2009., 15:49
Scala je definitivno jedan od jezika koji bih želeo da isprobam u budućnosti i ovo će sigurno pomoći njegovoj popularizaciji. Bilo je malo iluzorno očekivati da će Rubi moći da skalira bek-end sistema poput Tvitera. Štono kažu, right tool for the right job... ;)

nixa
07. 04. 2009., 15:55
Ha ! Najzad !

nn.nn
07. 04. 2009., 16:02
"Most of our recent issues have been related to database management. We have people on it." Alex Payne, on twitter (http://twitter.com/al3x/status/1467263877) ;)

bNasty
07. 04. 2009., 18:50
http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html

Obavezno prochitati komentare, narochito od ljudi iz Twitter-a i RabbitMQ-a

kaizen
10. 04. 2009., 01:38
Posebno ovaj deo:
": I’d definitely want to hammer home what Steve said about typing. As our system has grown, a lot of the logic in our Ruby system sort of replicates a type system, either in our unit tests or as validations on models. I think it may just be a property of large systems in dynamic languages, that eventually you end up rewriting your own type system, and you sort of do it badly. You’re checking for null values all over the place. There’s lots of calls to Ruby’s kind_of? method, which asks, “Is this a kind of User object? Because that’s what we’re expecting. If we don’t get that, this is going to explode.” It is a shame to have to write all that when there is a solution that has existed in the world of programming languages for decades now."

:1002: Ovo nema nikakvog smisla. Pa i kad bi takav kôd portovao na neki statički jezik, opet bi imao proveru tipa.

EDIT: sad pročitah ponovo (pošto sam bio u neverici :)) i videh da je na početku rekao "either in our unit tests or as validations on models", što već donekle ima smisla, mada čini se bespotrebno jer bi drugi testovi (klijent kôda) to trebali da pokriju.

degojs
10. 04. 2009., 04:49
:1002: Ovo nema nikakvog smisla. Pa i kad bi takav kôd portovao na neki statički jezik, opet bi imao proveru tipa.

Zasto? Ako imas funkciju:

func( A b )

Ne moras unutar te funkcije da proveravas da li je b tipa A (tj. kind-of A). Ostaje provera za null. A kod nekih tipova ni to (int, double, itd)..

ivanhoe
10. 04. 2009., 08:04
iskreno, mislim da su ovi iz twittera neopevani lozaci :) Prvo im nije valjao php, pa su pisali sve u rubiju, pa su ga napisali tako da je sve prslo cim je servis postao popularan (ne zbog rubija, nego sto nisu seli i razmislili o skaliranju). Pa su onda sve rewrite-ovali, menjali celu arhitekturu, pa je to neko vreme radilo. Sad opet menjaju sve zivo, i opet uzimaju neki egzoticni jezik, posto kao sad je to prava stvar, to ce im resiti sve probleme... spreman sam da se kladim da ce biti rewrite za pola godine opet... :D

ps. da ne ispadne da pljujem po Scali, nemam pojma o tom jeziku, i nemam nista protiv novih jezika naravno, nego me nervira taj "we are on the bleeding edge of technology" pristup, i svo lozenje koje ide uz to, a onda posle par meseci bude "ups, a vi ste mislili da ovo skalirate, pa trebalo je ranije da mi kazete". :D

kaizen
10. 04. 2009., 10:36
Zasto? Ako imas funkciju:

func( A b )

Ne moras unutar te funkcije da proveravas da li je b tipa A (tj. kind-of A). Ostaje provera za null. A kod nekih tipova ni to (int, double, itd)..

Kapiram ali opet (po meni) to nije dobar stil programiranja jer zagađuje kôd silnim proverama koje nisu ni potrebne jer zašto bi pozvao metodu sa pogrešnim tipom argumenta? To se retko dešava, a čak i ako se desi, pa šta ako "eksplodira" uhvatićeš prilikom testiranja, to nije baš neki "edge case" koji će se potkrasti.

srdjan
10. 04. 2009., 11:27
To se retko dešava, a čak i ako se desi, pa šta ako "eksplodira" uhvatićeš prilikom testiranja

I tako toplina oko srca obuzme svakog CLIPPER programera :seljak:

bNasty
10. 04. 2009., 12:07
pa šta ako "eksplodira" uhvatićeš prilikom testiranja

Kompajler je najbolji unit test

kaizen
10. 04. 2009., 12:25
Kompajler je najbolji unit test

Ih, pa dobro sad. Ja ne osporavam korisnost statičke provere tipa, ja samo mislim da je mnogo veća i za programera značajnija dobit nepostojanja istog - mnogo manje koda, čitljivost, fleksibilnost, ...

ivanhoe
10. 04. 2009., 14:42
po meni je idealno da jezik sam ume da odradi type casting, ali da je moguce hardcodovati proveru tipa tamo gde zelis... isto tako i za deklaracije promenjivih, jezik koji bi to imao kao obavezno bi mi ustedeo bar jedno 70% bagova

bluesman
10. 04. 2009., 14:54
Ja mislim da je njima bilo pametnije da su napravili dobru arhitekturu, sa tim kvalitetom možeš da odradiš kako treba u skoro svakom programskom jeziku. Da li će da bude php, ruby ili neki drugi, to je onda samo stvar ličnih afiniteta. Mislim da je frka što su onui prsli zbog krš arhitekture, pa se sada izvlače kao ne valja programski jezik.

caboom
10. 04. 2009., 15:37
mislim da nije fer nazivati staru twitter arhitekturu "krsh" - prosto nisu mogli da predvide takvo skaliranje - sa druge strane arhitektura jeste bila problem kod twitter-a, takodje - izbor ne bih rekao da je izbor programskog jezika irelevantan, cak ni u slucaju da je jedini razlog za izbor izmedju nekoliko kandidata potpuno subjektivan - ziveces sa tim kodom mesecima, ili godinama.
drugo, micro-blogging na ovoj skali je jedan od najtezih problema koji mi pada na pamet u kontekstu danasnjeg web-a - cak dosta tezi od onoga sa cime se susrece facebook, real-time delivery i ordering nad tolikom mrezom ljudi, malo li je.
trece, skakati za svim sto se pojavi u ekstremnijim uslovima, ili ekstremniji oblik NIH-a, je normalan impuls (osim ako nije hobi) u situacijama kada sve krene da raste, stari servisi krenu da se raspadaju i "ekipa" koja ih je pisala nije prethodno bila u slicnim situacijama - gomila tog "edgy" softvera od pre 5-10 godina je sada postala mainstream, bas zahvaljujuci early adopterima, koji su - gle cuda - bili i commiter-i, ili full-time developeri, na dobrom delu tih projekata. sve je to deo zdrave evolucije i svako od nas moze da bira da li ce da se nalazi medju alfa-geek-ovima, ili udobno baca hejt iz 9-17h common paradigme (been there, done that).
cetvrto - da, twitter ekipa je napaljena, kao i ceo taj neki valley engineering, ali u njihovom slucaju - nije bas da nemaju razlog i zasto. voleo bih da vidim koliko ljudi bi izdrzalo takav pritisak - nije u pitanju "uuu brate, odvalio sam se 48h nisam spavao" (well done, braindead test passed) - nego je "mesecima me gazi product, management i mislim da nisam dovoljno dobar, a radim 80h radne nedelje i nemam pojma gde se nalazim".
peto - scala je dobar izbor sada (izuzetno ekspresivna, bar onima koji nemaju otpor prema sintaksama, ima obicno dovoljno dobre performanse i jako lepo se "lepi" na ogroman set biblioteka i okruzenja koje vec postoje), ruby je bio dobar izbor tada - pre svega u kontekstu tadasnje "baze znanja", oni su bili pokusni kunici po pitanju testiranja i skaliranja ruby-a i RoR-a u ekstremnim uslovima i, pre svega, nisu ocekivali da ce biti u toj poziciji. hats off - preziveli su.

Dragi Tata
10. 04. 2009., 15:41
Ja mislim da je njima bilo pametnije da su napravili dobru arhitekturu, sa tim kvalitetom možeš da odradiš kako treba u skoro svakom programskom jeziku.

Recimo da se ne slažem baš sasvim. Da li su oni imali problem u dizajnu (ne smem da koristim reč "arhitektura" da moj ćale koji je pravi arhitekta to negde ne pročita) ili ne to ne znam, ali činjenica je da je većina programskih jezika prilagođena rešavanju određene vrste problema. Sistemski softver ćeš verovatno da pišeš u nečem kao što je C ili C++, biznis desktop aplikacije u C#u ili VBu, web front-end u PHPu, Rubiju, itd. Naravno, možeš da pišeš web aplikaciju u C-u a šel ekstenziju u PHPu (valjda, nisam siguran) ali je to malo mazohistički a i nisam siguran kakav bi rezultat ispao.

Što se Twittera tiče, oni su rešili da koriste statički jezik (Scala) za pisanje messaging sistema, a dinamički (Ruby) za front-end, što je po meni sasvim logična odluka. Bilo bi logično i da su npr koristili Javu za messaging a PHP za front-end, ali to je već stvar ukusa. Ne bi bilo logično da su uradili obrnuto: (Ruby za messaging a Scala za front-end).

bNasty
10. 04. 2009., 15:56
micro-blogging na ovoj skali je jedan od najtezih problema koji mi pada na pamet u kontekstu danasnjeg web-a
Apropo, zna li neko koje dimenzije su u pitanju kod twitter-a? Koja je frekvencija poruka?
Interesuje me radi poredjenja, trenutno radim na slichnim problemima, dodushe u drugom domenu.

oni su rešili da koriste statički jezik (Scala) za pisanje messaging sistema
Hard-core je uraditi to u hardveru :)

caboom
10. 04. 2009., 18:15
@bNasty
ako se secam dobro, ~10k u sekundi na 3 MQ (kestrel) servera u regularnim peak-ovima i oko 4-5 puta toliko tokom npr. obamine inauguracije, ako mislis na sam message queue?

bluesman
10. 04. 2009., 20:13
@Dragi Tata: nisam mislio bukvalno :D

A ovo sve mi liči na "blame it on...", zato sam i napisao to što sam napisao. Još od pre skoro 20 godina počeo sam da se srećem sa tim, izdavačima je kriv štampar, štamparima je uvek kriv dizajner, dizajnerima je kriv izdavač...uvek je neko drugi kriv.

bNasty
10. 04. 2009., 23:03
@bNasty
ako se secam dobro, ~10k u sekundi na 3 MQ (kestrel) servera u regularnim peak-ovima i oko 4-5 puta toliko tokom npr. obamine inauguracije, ako mislis na sam message queue?

Da, upravo to. Nije nekakva strashna brojka sa stanovishta samog mq-a. Ne znam zashto tvrde da im vec postojece mq implementacije nisu zadovoljavajuce, bilo bi lepo chuti konkretne detalje.

caboom
10. 04. 2009., 23:34
mislim da su pominjali razloge u diskusiji - konkretno amq jeste prilicno trom, sa rabbitmq-om su imali probleme u disproporcionalnom broju producera vs. consumer-a (u trenucima kada krenu da se gomilaju porukice i imaju disproporciju u consumer-ima, desavalo im se da rabbitmq "pukne"), itd. - zapravo, bar sam se prilicno opekao pre 2-3 godine sa amq-om u malo ekstremnijim situacijama, ali cak na daleko manjem broju poruka u sekundi (konkretno - ~50-100 poruka u sekundi u peak-ovima, veliki broj producer-a i porukice od oko 20-40KB) - plus je bilo maltene nemoguce napraviti neki elegantniji monitoring posto bi odr. queue deadlock-ovao - ali bi ostatak queue-ova radio korektno i tako sam redom nailazio na razlicite probleme sa drugim JMS implementacijama (switfmq, mantaray, etc. etc.), tako da je pitanje sta je srecniji izbor - da li potrositi konacno vreme na tune-ovanje nekog od postojecih resenja, ili napisati nesto sto se ponasa dobro unutar okvira koji su potrebni. nemam pojma, nisam pametan - ali twitter ima veoma dobar inzenjerski tim, tako da kontam da razlozi nisu iracionalni. druga stvar je sto su mesecima bili pod izuzetnim pritiskom i sasvim sam siguran da je bar deo inzenjerskih poteza posledica toga.

ivanhoe
11. 04. 2009., 03:20
zar nije Twitter koristio starling za queue-ing ?

degojs
11. 04. 2009., 03:38
Ih, pa dobro sad. Ja ne osporavam korisnost statičke provere tipa, ja samo mislim da je mnogo veća i za programera značajnija dobit nepostojanja istog - mnogo manje koda, čitljivost, fleksibilnost, ...

..i mnogo veća briga prebačena na programera. Vidi primer:


deklaracija x;

...
Dosta šugavog ili komplikovanog koda koji je pisao neko drugi :)
Možda čak i kod koji ima bag pa x prebaci u krivi tip..
...

Kog tipa je x? Ili, npr., šta ću da dobijem kao rezultat x + 2?


Kod statičkih jezika nema mnogo dileme kog tipa je x dole, a kod dinamičkih bi morao da pregledaš kod.. zar ne?

caboom
11. 04. 2009., 04:19
zar nije Twitter koristio starling za queue-ing ?

yep - kestrel je starling-in-scala, ali su takodje ispitivali i jedan deo opensource resenja. imho - zaista razumem NIH u ovom slucaju i mogu da se identifikujem sa pricama tipa "rabbitmq se ne skalira dobro ako je broj producera dovoljno velik u odnosu na broj consumera", iako deluje kao da je ponuda message queue-ova izuzetno velika i da su fantasticno robusni, ova teza se fino urushava u odredjenim slucajevima.