Czy Cloudflare podsłuchuje Patoarchitektów? A może mamy zdolność przewidywania przyszłości?
Ciekawe linki i inne znaleziska z tego odcinka:
Szymon Warda [SW]: Cześć! Słuchacie Patoarchitektów short. Prowadzą Szymon Warda
Łukasz Kałużny [ŁK]: i Łukasz Kałużny. Linki do tego odcinka znajdziecie na: patoarchitekci.io/46. Przy okazji – jeżeli chcecie żebyśmy coś skomentowali, chcecie zadać nam pytanie lub dorzucić swój link do zestawień, to możecie wrzucić to na: patoarchitekci.io/short lub zerknijcie w opis odcinka, żeby kliknąć w link. Dobra, Szymonie, jaki dzisiaj link z Twojej strony?
SW: Ponieważ mówiliśmy wcześniej, o czym będziemy dzisiaj rozmawiali, to mnie tak naszło… Bardzo ciekawy link od strony InfoQ. Naprawdę – dający do myślenia i można powiedzieć, że całkowicie techniczny. Chodzi o koszt frameworków. Kiedy dobierać frameworki, jak je wybierać, jakie są ich plusy i minusy. W artykule w kilku zdaniach jest opisane, o co z nimi chodzi. Chodzi o to, że de facto jak każda technologia, każdy wybór, frameworki pewne rzeczy tworzą i sprawiają, że są łatwiejsze, a pewne rzeczy powodują, że są trudniejsze. Szczególnie to widać we front-endach. To bardzo widać, bo gdy jest projekt, to mówimy, że pierwsze ustalenie to jest w jakim frameworku. Ale… Więc to… Jeżeli dobierzemy framework, sorry ale na pałę, nie znając dokładnie kontekstu biznesowego, to potem często nie liczymy się kompletnie z jego kosztem. Fajny artykuł, który pokazuje, jakie są koszty, jak patrzeć na frameworki, jakie mogą być konsekwencje wyboru. Było tam takie fajne zdanie, że de facto dobre design patterny to też jest sposób na usprawnienie pewnych decyzji. I taka fajna myśl z tego artykułu wybrzmiewa, że nie śpieszmy się z frameworkami, szczególnie na back-endzie. Na wszystko jest czas. Wpierw poznajmy domenę biznesową i problem, który rozwiązujemy. I to jest idealne i aplikuje się do wszystkiego, że tak to powiem.
ŁK: Wiesz co, to jest fajne stwierdzenie, tylko taka łyżka realizmu: biorą sobie dwie najpopularniejsze rzeczy, a nawet więcej. Wieźmy, dobra, .NET, JavaScript, Python, Node.js. W przypadku Javy lub .NETu już musisz lecieć frameworkiem, bo w czystej Javie to byłaby mordęga porównując do takiego spring boota , samego… Jako stos, biorąc samego spring boota. A .NET, .NET…
SW: Czy ja wiem, czy spring jest takim frameworkiem? To jest zestaw bibliotek de facto. Bo jaka jest różnica między frameworkiem a biblioteką? Przynajmniej dla mnie? Framework mówi Ci, co i jak masz dokładnie robić i tylko stawiasz kod w pewne miejsca. A biblioteka de facto mówi: ok, używaj mnie. I, żeby nie było, springa widziałem ostatni raz na oczy parę lat temu, ale wtedy to było na zasadzie: ok, dajemy ci platformę, która umie hostować, która umie zwracać wyniki.
ŁK: Nie. Teraz to ona… Nie. To jest framework. teraz jest naprawdę… ma swój kierunek i pokazuje, w którą stronę iść. Jeżeli mówimy o samym… Bo nawet już nazwa się zmieniła, jak wiesz… Jak patrzysz na spring boot, ale patrzysz, że to jest spring framework i całą tą… i ma wszystkie warstwy po kolei idące. .NET de facto, czego byśmy nie wzięli, to jest framework.
SW: No właśnie nie. Właśnie wydaje mi się, że nie.
ŁK: Jeżeli popatrzysz na web API i inne rzeczy, które powstały wokół serwowania… powiedzmy tak: serwowania API, no to mają swoje podejście. W świecie .NETowym to jest trochę wymieszane tak naprawdę z patternami, bo sam .NET framework nie ma takiego mocnego narzucania, jak ma to wyglądać. Nie jest taki silnie zatypowany, w jaki sposób masz ułożyć projekt.
SW: Wydaje mi się, że dużo wcześniej widzisz framework. Dla mnie jak ktoś mówi framework, to jak ktoś ma różnicę między angularem a na przykład Vue, ogólnie front-endowy. Że są zupełnie inne podejścia. To co .NET robi, dla mnie to jest takie… Dla mnie .NET to jest taki boilerplate, de facto, na określenie całości.
ŁK: Ja się… Mamy inne do tego podejście, więc… Ale to ten świadek wyboru rozwiązania. A drugi aspekt, który de facto w tym sobie istnieje, wybór wyborem, ale zawężasz go do tego, co umie Twój zespół, albo do kompetencji, jakie możesz pozyskać od dostawców. To dość mocno zawęża ten wybór.
SW: Tak. Bez dwóch zdań, skill zespołu jest często pomijany, bo często pobierane jest to… Często się nabijam z tego, że decyzje w IT podejmujemy tak samo, jak podejmujemy decyzje, co zjeść na lunch. Bierzemy to, co wybraliśmy wczoraj lub to, co bierze większość de facto. Bo wtedy będzie pewnie dobre.
ŁK: Albo to, co chcemy sprawdzić. (śmiech)
SW: Tak. Jeszcze albo lecimy po liście. Dokładnie. Tak to wygląda. Dla mnie skill… Powiedziałeś o zespole. Tak, bardzo ważne. Do mnie ten artykuł trafił, bo jeszcze pamiętamy, ty też jeszcze pamiętasz: była taka mania na start .NETa, że prawie każdy softwearhouse, każda firma, w ogóle każda spółka, pisała swój własny projekt, który potem miał być używany company white i on miał dać wartość firmie. I tak dalej.
ŁK: (śmiech) No, Szymon… Sam jesteś, przepraszam, że teraz tak palcem wskażę, Ty…
SW: Jestem, tak.
ŁK: Ty nawet robiłeś coś takiego dla pojedynczego projektu, jakby nie patrzeć.
SW: Dużego projektu. Ale, żeby nie było, to jest dalej wykorzystywane i dalej się obroniło.
ŁK: Ja wiem. Jestem ciekaw, jak (śmiech) obecnie teraz klną (śmiech).
SW: A właśnie byś się zdziwił, bo mam kontakt i nawet jeszcze wykorzystują, więc zobaczymy. Ale tak czy siak, pamiętajmy, że frameworki wybieramy w kontekście problemów, więc roboty którą mamy rozwiązać. Bo każdy z nich coś ułatwia, ale jak coś ułatwia, to musi coś utrudnić.
ŁK: No.
SW: Fajny artykuł. Naprawdę. Dość długawy, ale naprawdę niezły. Polecam do przeczytania, tak do przemyśleń wewnętrznych. Łukasz, a co u Ciebie?
ŁK: Ja wybrałem… Bo dostałem, przepraszam nie pamiętam kto mnie kopnął, przy publikacji zeszłych odcinków, gdzie dość mocno rozmawialiśmy o Cloudflare. Między nagraniem odcinka a publikacją, dokładnie dzień przed publikacją odcinka, Cloudflare ogłosił, że na bazie swojej usługi storage, do key-value, dodaje relacyjną bazę danych, o której rozmawialiśmy, że to jest brakujący puzzel.
SW: Tak.
ŁK: I de facto właśnie dwa dni po naszym nagraniu, a dzień przed publikacją została ogłoszona baza D1 z SQL interfejsem. Czyli brakujący klocek, o którym rozmawialiśmy, został zapowiedziany dwa dni po naszym nagraniu. I teraz zobaczymy, jak to sobie pójdzie. Tak jak powiedziałem: nakładka SQL lightowa.
SW: Tak przeglądam go… I tak… Bym powiedział, że oszczędny jest ten wpis. Znaczy on jest faktycznie długawy, dużo jest o łączeniu się, ale tak na przykład mało jest porównań… Oszczędny jest mimo wszystko.
ŁK: Znaczy bo to jest preview. Oni właśnie piszą, że to jest private preview. I jak sobie popatrzymy, że mają problemy z transakcjami…
SW: O dziwo… Jak wszyscy.
ŁK: …to wiadomo. O tym też rozmawialiśmy, że to będzie problem. I jestem ciekawy, jak będą to rozwiązywali.
SW: Łukasz, to jest prawie beta dopiero. Nawet nie preview.
ŁK: Tak. Private beta w świecie Microsoftowym. Ostatnio przez Azure jestem do preview przyzwyczajony. Ale mamy tak: Your SQL executes inside your D1 database (primary for writes, the nearest replica for reads). Więc jestem ciekaw, w jaki sposób będą się w tym bawili. Już teraz widać, że na razie to jest… To będzie taki właśnie multitenant typu: tylko jedna replika do zapisów. Więc jestem ciekaw, jak to sobie poleci wydajnościowo i co z tym będą robić. I jestem ciekawy, jaki stos wybrali. Bo widać, że zrobili coś swojego na bazie API od SQL light.
SW: A ja jestem ciekaw jednej rzeczy, podstawowej: jaki będzie rozmiar zbieranej bazy danych. Bo to będzie wszystko działało, jak te bazy będą małe, ale ciekawe, czy ktoś tam kiedyś wrzuci parę TB albo parędziesiąt TB. Bo wszystko jest ładne, łatwe, jak baza ma 1 GB. Fajne, ja to będę obserwował. Bo z Cloudflare ciekawe rzeczy mogą rosnąć.
ŁK: Tak. I druga rzecz, która się pojawiła, to same workery. Silnik od workerów został częściowo opensourcowany. To też jeden z tych newsów, który się pojawił tego samego dnia. To już bardziej jako taka ciekawostka. Będzie to też oznaczało o wiele prostszy lokalny development.
SW: To się zawsze przydaje. Dobrze, ale to chyba nie jest ostatni temat, jaki dzisiaj mamy. Bo mamy coś jeszcze, tak?
ŁK: Tak, lecimy. To było takie pytanie, żeby troszeczkę wydłużyć naszego shorta i trochę bardziej podyskutować i się powymieniać opiniami. Dobra, Szymon, załóżmy, że możesz teraz zrobić sobie… Startujesz z nowym projektem, co wybierasz jako stos technologiczny?
SW: Dobrze, to tu będzie pierwsze… Nie będziemy się zgadzać. (O dziwo przygotowujemy się wcześniej do tych odcinków). Wybieram cokolwiek, co nie ma front-endu.
ŁK: (śmiech) Dobra. Ja jestem realistą i front-end będzie musiał być.
SW: A właśnie coraz więcej widzę systemów, gdzie front-end jest… znaczy mówię, że nie ma. Front-end nie jest główną wartością de facto. On jest…
ŁK: Tak…
SW: On jest do demonstracji, do niczego więcej.
ŁK: Tak, ale jeżeli coś takiego będziemy mieli, to poszedłbym tędy, że prawdopodobnie angular. Z tego trochę jak wspomniałeś… Teraz angular jest mocno wytypowany w sposób: weź tu wstaw kod. Ma jakiś swój próg wejścia. Ale w przeciwieństwie do tego, jak widzę w projektach reaktowych, jak są bootstrapowane, jak to wygląda w przypadku (śmiech)…
SW: Tu się zgodzę. Tak.
ŁK: Tak u Reacta nie ma czegoś takiego, jak powinien wyglądać projekt i powinien być rozwijany. Bo co zespół, co lead, to ciekawsze pomysły.
SW: A to ja bym się z tobą nie zgodził. Jakbym miał wybierać, to właśnie wziąłbym React.js albo Vue. Zdecydowanie. Nie angulara.
ŁK: Vue gdzieś tam też jest po drodze. Angular ze względu, że jest mocno wyspecyfikowane.
SW: To jest religia. Angular jest religią.
ŁK: (śmiech) Słuchaj, najważniejsze, ważne, żebym nie musiał tam pisać kodu. O!
SW: To się z tym zgodzę.
ŁK: Tak, to nie jest moja… Dobra. To sobie pogadaliśmy. Dobra, Szymon, jaki język programowania?
SW: A ja będę tutaj… Tu się znowu nie zgodzimy. Dwa języki, bo dwa się przydają z reguły. Pierwszy: .NET. Czemu? Dobry, w miarę uniwersalny – do większości projektów się nada, może być korporacyjny, może być lekki i do, powiedzmy, ciężkich obliczeń back-endowych jest. Ekosystem jest też dobry. Rozwinął się. Śmiga. Do rzeczy lekkich front-endowych. Żeby nie było, ja bardzo lubię architekturę Redditową, to się super wpisuje. A do rzeczy front-endowych, typowo front-endowych, czyli rzeczy, które komunikują się z ludźmi, czyli muszą mieć szybki czas odpowiedzi, to byłby to Node.js. Czemu? Masę ludzi koło niego jest. Do .NET tez jest masa ludzi. Dwa popularne frameworki: nie będzie problemów z rekrutacją, nie będzie problemów z ludźmi. Zgrane są ładnie, z reguły wspierane jako pierwsze języki w większości providerów chmurowych, duży ekosystem, duża społeczność – can’t get wrong with it.
ŁK: Dobra, to ja tutaj… Mamy jedno wspólne trafienie. Bo ja .NETu bym, mimo że znam, używam…
SW: Znałeś…
ŁK: Znałem (śmiech). Złośliwcze. Wybrałbym Node.js jako pierwszy wybór. Pewnie strzeliłbym, patrząc na to, co się tworzy, Node.js. Jako drugi wybór mam problem, bo zerkam troszeczkę na ROR-a, na Ruby on Rails. Chociaż ekosystem ludzi jest za mały w tym. To jest taki jego problem, mimo że można szybko tworzyć.
SW: Powiem Ci, czemu bym nie widział ROR-a.
ŁK: No?
SW: To jest fajny framework, fajny język, fajny ekosystem, ale on już jest w trybie utrzymaniowym de facto. To już nie jest coś, o czym huczy i się dzieje.
ŁK: Nie, jest… Tak, ale jest ciągle rozwijany.
SW: Rozwijany. Ale jak teraz powiesz komuś… Znaczy… Pula ludzi do ROR-a jest ograniczona. Ich nie przybywa zbyt dużo. Dlatego właśnie bym ROR-a zdecydowanie nie wziął.
ŁK: A drugi w kolejności właśnie jako ROR, to wybrałbym… Język, który zawsze jest drugim najlepszym językiem w każdej kategorii…
SW: Nie wiem… GO to nie będzie… Java?
ŁK: Python!
SW: Python! Python też mi się…
ŁK: Ze względu na uniwersalność, tak.
SW: I ekosystem jego.
ŁK: Tak.
SW: Ilość biblioteki i ilość rzeczy.
ŁK: Tak. Ilość tych… Można przebierać we frameworkach i innych rzeczach, od bardzo lekkich do kobył typu: Django czy parę innych. Więc jest tego sporo.
SW: Tak. Python… W tym masz dwa języki, które są pod cięższe projekty obliczeniowe, średnio się nadają, choć mają dużo portów, które się importują z C albo C+.
ŁK: No właśnie, no właśnie… Teraz jest zawsze pytanie, czy to będzie taki projekt czy nie. Bo gadamy sobie o wymarzonym stosie, gdyby było ciężkie obliczeniowe, to uśmiechnąłbym się, wziął Golanga i przytulił.
SW: Dobrze.
ŁK: To w ten deseń. Dobra.
SW: To skoro mamy bazę. To powiedzmy teraz, gdzie byśmy te dane trzymali. I tu się zgadzamy. W jednym obszarze, że byłby to SQL.
ŁK: Raczej… Ale jaki?
SW: Patrząc na ceny, pewnie Postgres.
ŁK: Ok. Tak. Tu jest niestety tak, że Postgres ma, naszym zdaniem niestety prowadzi, tak. Patrząc na cenę versus możliwości, kompetencje rynkowe i sama technologia pod spodem jest…
SW: A ja bym.. A jeszcze jedna rzecz. Postgres jest dobry do wszystkiego. Chcesz w nim zrobić bazę key-values - zrobisz. Chcesz bazę obiektową – masz głęboki zestaw do Jsonów i tak dalej. Postgres jest tak na prawdę dobrym graczem cały czas.
ŁK: I nawet. Tak. Plus załadujesz dodatki typu timescale i masz bazę TimeSerious, która żyje dobrze i potrafi się wyskalować. Jeszcze jedna rzecz – jak mam Node.js, to z drugiej strony troszeczkę uśmiech w stronę Mongo.
SW: Nigdy w życiu.
ŁK: I dokumentów ich (śmiech). Ale to zależy od potrzeb. Dobra, na czym hostujemy?
SW: Tu się zgadzamy całkowicie. Ja chcę mieć z tym jak najmniej problemów, więc to będzie albo FaaS, albo K8s zarządzany.
ŁK: Dobra.
SW: Tyle. Po prostu.
ŁK: Tutaj tak w FaaS-a prawdopodobniej ja bym poszedł. Function as a Service, bo użyłeś skrótu, a nie rozwinąłeś.
SW: O, tym razem ja…
ŁK: Z Function as a Service poleciałbym prawdopodobnie na AWS-a. Na lambdę. Tak patrząc częściowo na ekosystem i na to, że serverless framework, który w JavaScripcie pięknie daje środowisko pracy. Nie trzeba wymyślać na nowo koła. Dodając jeszcze step functions, które tam są.
SW: A to dla mnie znowu właśnie, jeśli mówimy o takich step function/druble function, to powiem, że zdecydowanie to, co MS zrobił z druble functions, samą orchiestracja, modelem aktorów, to nawet step functions AWS-owe się nie umywają. Tutaj MS naprawdę wyprzedził. I według mnie jest dużo lepsze. Ale serverless jako taki jest bardzo fajny, tak. Tu się z tym zgodzę. I lepiej gra z AWS-em.
ŁK: Tak. Ze step function te zabawy, bo można teraz wywoływać natywne akcje na obiektach, czego trochę w Azure czy Google, czy właśnie w tym modelu… pozwala Ci wywoływać end-point API tak naprawdę dowolnej usługi chmurowej w ramach tego. Tak jak miałeś te wywołania po prostu implentowe. To powoduje, że ten kod jest trochę przyjemniejszy. Nie trzeba żadnej integracji robić i innych rzeczy. Że wywalasz tego kodu sporu. W AWS-ie.
SW: Do integracji, tak. Mnie druble of functions urzekło super implementacją modelu aktorów. To jest dla mnie… To fajnie zrobili.
ŁK: Tak, jeszcze tylko performance niech skończą poprawiać.
SW: Jeszcze co?
ŁK: Performance niech skończą poprawiać.
SW: Tak. Tak, zgadza się.
ŁK: A drugi element to K8s tak naprawdę. Tak na pierwszy wybór zarządzanych, chyba że cena czyni cuda, to gdzieś na jakichś dedykach… Bo de facto z zarządzanego K8s-a… Jeżeli zbootstrapujesz go rozsądnie, to wartość zarządzanego nie jest duża. Jeżeli nie odpalisz się w stos technologiczny wokół.
SW: Czekaj, czekaj, bo jedną rzecz powiedziałeś, to może ustalmy… Czy lecimy na on-premie, czy lecimy na chmurze? Bo jeżeli Twój wymarzony projekt jest na on-premie, to mamy inną rozmowę.
ŁK: Nie. Poza on-premem. Ale można wziąć od dostawcy zawsze kawałki wirtualek i będzie taniej.
SW: Yyyy… tak. Ja po prostu nie chcę, żeby mnie głowa bolała. Więc zarządzam jak najbardziej. Mniej odpowiedzialności na mojej głowie, tym lepiej.
ŁK: Dobra. Zostało nam tak naprawdę: cashe, kolejki. Jakie masz do tego podejście?
SW: I to był element, który mi trochę chodził już po głowie. Jeżeli chodzi o cash, powiem od razu: Redis. Możliwości…
ŁK: Tak, chyba nie ma…
SW: …dwojakie. Po pierwsze: na Redisa wiele osób patrzy jak na system do cachowania. Tam ma dużo więcej rzeczy do zrobienia. Ale Redis też ma fenomenalnego Pub/Sub. Żeby było jasne: on jest fajny, bo jest szybki. Jest nietrwały i w ogóle nie nadaje się do niczego innego niż inwalidacja cacha rozproszonego. Do tego nadaje się fenomenalnie. A jeżeli chodzi o główny mechanizm komunikacji, to właśnie tak… Coś cały czas mi chodziło właśnie, co wybrać. I znowu: kierując się tym, żeby nie mieć problemów, wybrałbym Rabbita. Bo po prostu działa. Myślałem o Kafce, ale żeby ją trzymać w tym K8s i żeby postawić wewnętrznie i nią zarządzać, to jest tyle roboty… Po prostu łatwiej jest zrobić na Rabbicie tak naprawdę. A większość systemów, sorry, jak ktoś mnie słuchał, ja nie będę robił event sourcingu na Kafce, uważam, że to jest zły pomysł. I tego odtwarzania Kafkowego, trzymania dłużej pików wolumenowych, to można sobie poradzić inaczej. Po prostu z Rabbitem żyje się trochę łatwiej. Kafka ma też swoje miejsce, jak najbardziej. Tyle. A u Ciebie?
ŁK: Inaczej. Z tym Async’iem oczywiście dopiero wprowadzamy element, jak go naprawdę potrzebujemy. I to jest…
SW: Nie. Nie.
ŁK: Nie. Od razu nie.
SW: Od razu. Wiesz czemu? To zmienia podejście ludzi do modelowania procesów biznesowych. Bardzo. To jest danie takiego capability na poziomie platformy, że: ok, macie, korzystajcie. I to od deweloperów zależy, z czego będą korzystali. Ale to musi być na samym starcie. Tak samo jak scentralizowane logowanie. Nieustandaryzowane i tak dalej. Jakie rzeczy daje się na sam start po prostu.
ŁK: No więc, jak to byłby Twój projekt, to byś inaczej na to… Byłbyś w stanie zrobić to bez tego i dopilnować, żeby to było w tym kierunku.
SW: No ok. Tak
ŁK: Tak. Dobra. To jest to. Więc pewnie skłaniam się ku temu… Jeżeli byłoby to… leciałbym na FaaS-ie i na tych natywnych usługach cloudowych, to co dostawca preferuje i to, co ma najbardziej wygrzanego u siebie, Pub/Suba, którego ma u siebie wygrzanego. W chmurze, w której bym robił. W ten sposób. Gdybym miał zrobić self-costing czy cokolwiek na tym K8s-ie, to też poszedłbym w Rabbita. Niestety są…
SW: Ooo…
ŁK: …nie… Smart broker… Inaczej: świadomie postawiony smart broker wygrywa.
SW: Tak, no właśnie.
ŁK: To tak zupełnie szczerze. Smart broker, co bym nie chciał, używa w tym użyciu. Kafka w tym roku dojrzewa, bo wyrzuca zookeepera, będzie coraz prościej.
SW: Tak. Zookeeper trochę truchłem, że tak powiem, pod górkę.
ŁK: Tak. Dla doszczegółowienia: czemu się czepiamy zookeepera? Bo teraz, żeby do tej pory utrzymać Kafkę, trzeba było mieć zookeepera, który robił za quorum, wybór lidera i samą Kafkę. Czyli de facto utrzymywaliśmy prawie że 2 klastry oprogramowania. A Kafka dorobiła się własnej implementacji w środku, Rafta, która się dogrzewa. Znaczy… W samym open sourcie jest uznana za produkcyjną, a confluent, który ma… przepraszam. W opensource jest jako produkcyjna, a confluent, który utrzymuje komercyjną wersję, przygotowuje się do uproduktywnienia. Bo już jest w ich dystrybucji, ale jeszcze bodajże w becie preview jeszcze oznaczone, że nie do produkcji, jeżeli dobrze kojarzę.
SW: Z tych danych jakie mają historyczne, tych, którzy może pamiętają, czemu powstał Elastic. Bo przed Elastikiem był Solr, który dalej w ogóle jest. Jaki był główny motywator, że powstał Elastic? To właśnie, że do klastrowania wymagał zookeepera i utrzymanie zookeepera było po prostu bólem wiadomo czego. Historia się niejako powtarza, bo znowu ktoś chce wywalić Elastica, znaczy wywalić zookeepera. Tak, zookeeper jest upierdliwy w hostowaniu.
ŁK: Tak, bo ty się męczyłeś z Solrem. Tak. Już… (śmiech)
SW: Ja go bardzo lubię.
ŁK: (śmiech) Mówię od strony utrzymania.
SW: Tam go trochę mniej lubię.
ŁK: Tak, dobra. Z zabaw ze stosu to byłby każdego z nas gdzieś tam wymarzony stos, jakby musiał coś ruszyć i robić od zera i miałby do tego ludzi. Bo jeżeli jest już jakiś zespół czy cokolwiek, to te decyzje już nie są po ulubieniach.
SW: Ale realnie ten stos jest bardzo podobny do tego de facto, jakie stosy z reguły wykorzystujemy, że tak powiem.
ŁK: Tak. Język tylko często się zmienia. Ten on-top się często zmienia.
SW: Fluktuuje. Tak. Dobrze, to powiedziawszy, to chyba kończymy.
ŁK: Tak, na razie!
SW: Trzymajcie się!