W ramach dzisiejszej edycji zastanawiamy się, czy istnieje coś takiego jak „język idealny”, porozmawiamy o reperkusjach usunięcia Dockera z Kubernetesa, a także z archeologicznym zacięciem przyglądniemy się kodowi źródłowego z roku 1995. Miłej soboty!
1. Dlaczego wciąż szuamy “lepszego” Rusta?
Zacznę od filozoficznego pytania… czy da się poprawić idealne?
![](https://vived.io/wp-content/uploads/2022/06/img_62a88aad23484.png)
Bo przecież Rust uchodzi za taki chodzący po ziemi ideał, a jednak w dalszym ciągu powstają nowe języki, próbujące ulokować się w jego niszy. Jednym z nich jest Hare, o którego premierze w zeszłym miesiącu miałem ochotę nawet napisać, ale stwierdziłem, że jest to kolejny język który trochę #nikogo. Jak się okazuje, Sylvain Kerkour, popularny rustowy blogger, postanowił się jednak nad nim pochylić i wykorzystać go jako pretekst do rozważań nad tym, w których miejscach Rust projektantom podwinęła się noga.
Okazuje się, że jest ich tak naprawdę całkiem sporo. Sylvain w swojej analizie wskazuje braki związane z biblioteką standardową, podejściem do modularyzacji, managerami pakietów czy nawet zarządzaniem pamięcią, z której Rust przecież słynie. Obrywa się również mocno podejściu do rozwoju języka i metodom jego zarządzania, zaśmiecaniu całości nadmiarowymi (zdaniem autor) funkcjonalnościami, które zaburzają oryginalną klarowność API. Także, ideałów nie ma, drodzy wierzący (zwykle nie praktykujący) wyznawcy kościoła pod wezwaniem Świętego Rust.
![](https://vived.io/wp-content/uploads/2022/06/img_62a88ab07162a.png)
A jeśli lubicie tego typu ranty, to ostatnio pojawiły się również dwa duże dotyczące Go. Jeden z nich jest analizą krytyczną niedawno dołożonych do języka generyków, drugi zaś to już istne mieszanie z błotem, jednak dosyć konstruktywne. Nawet jeśli nie piszecie w tym języku, podobnie jak w przypadku Rusta dalej warto sobie moim zdaniem do powyższych tekstów zerknąć, pozwalają bowiem zrozumieć pewne kontrowersyjne decyzje designerskie twórców języka.
BTW: Podoba Wam się czytanie o Rust czy Go? Jeśli tak, już niedługo w Vived App będziemy mieli dla Was ważne ogłoszenie 😉 Stay Tuned.
Źródła
- The Hare programming language
- What a better Rust would look like
- Crimes with Go Generics – Xe
- I want off Mr. Golang’s Wild Ride
Zainstaluj teraz i czytaj tylko dobre teksty!
![phone newsletter image](https://vived.io/wp-content/uploads/2021/12/ad2-min-1.png)
2. Kubernetes ostatecznie pozbywa się Dockera
No i mamy nowe duże wydanie Kubernetesa. Po “Ostatniej Granicy” (bo tak nazywało się wydanie 1.23 z grudnia) dostajemy “Obserwowacza Gwiazd”. Jest to wydanie naprawdę duże, ponieważ… wraz z nim Kubernetes ostatecznie pozbywa się Dockera. Zmiana zapowiadana była od lat, ale podejrzewam, że z programistami jak z drogowcami końcem roku, także spieszę wytłumaczyć o co chodzi.
Żeby zrozumieć na czym polega problem, niezbędne jest zerknięcie nieco pod maskę tego jak działa konteneryzacja w 2020. Zarówno Kubernetes, jak i Docker (a także każde inne narzędzie działające z kontenerami) posiada środowisko uruchomieniowe, pozwalające na wykonywanie dostarczonych obrazów. Kubernetes przez lata wspierało zarówno swój standard (CRI-O) jak i Dockerowy (containerd). Problem polega na tym, że Docker jest rozwiązaniem przeznaczonym do obsługi przez człowieka, przez co posiada sporo nadmiarowych funkcjonalności. Do tej pory Kubernetes je emulowało, wraz z wersją 1.20 rozpoczął się proces ich porzucania – całość zakończyć się miała wraz z wersją 1.22, w drugiej połowie 2021… ale całość się spóźniła o calutki rok.
![](https://vived.io/wp-content/uploads/2022/06/img_62a88ab685806.png)
Mamy zatem bardzo dobry przykład tego, jak zbawienną rzeczą są standardy. Docker może pozostać narzędziem używanym w developmencie lokalnym, zaś na Kubernetesie wygenerowane obrazy będą uruchamiane po prostu na ich własnym runtime. Jeżeli jesteście ciekawi rozszerzonej historii tak zwanego dockershimu, całość znajdziecie pod tym linkiem.
![](https://vived.io/wp-content/uploads/2022/06/img_62a88ab6cd7c0.png)
Jednak Kubernetes 1.24 to nie tylko ostateczne pozbycie się Dockera. To również możliwość rozszerzania podpiętych wolumenów bez downtime, Nowy Kubernetes to także testowe wsparcie formatu OpenAPI v3, a także kryptograficzne podpisywanie artefaktów wypluwanych przez Kubernetesa, co ma zwiększyć bezpieczeństwo i podatność na ataki supply-chain. Takich mniejszych i większych zmian jest więcej, ale to już pozwolę sobie odesłać Was do pełnych release notes.
Źródła
- Kubernetes 1.24: Stargazer
- Kubernetes 1.24: Volume Expansion Now A Stable Feature
- Updated: Dockershim Removal FAQ | Kubernetes
Zainstaluj teraz i czytaj tylko dobre teksty!
![phone newsletter image](https://vived.io/wp-content/uploads/2021/12/ad2-min-1.png)
3. Kod źródłowy Windows 3D Movie Makera trafia na GitHuba
A na koniec, po bardo przyziemnym opracowaniu Kubernetesa, teraz odjedziemy w kosmos i zajmiemy się niesamowitym prezentem od Pana Microsofta.
Każdy użytkownik Windowsa kojarzy pewnie program Windows Movie Makers, powstałą w 2000 roku aplikacje do domowego montażu wideo. Niewiele osób zdaje sobie jednak sprawę (min. ja jeszcze tydzień temu), że tak naprawdę jest to już kolejna aplikacja pod tą nazwą. Już w 1995 roku Microsoft wydał bowiem… 3D Movie Makera. Była to aplikacja przeznaczona dla dzieci, która pozwalała na przygotowywanie prościutkich filmików w 3D. Niestety, pojawiła się jeszcze w czasach przed YouTubem, więc świat o niej zapomniał. Wyobrażam sobie jednak alternatywną rzeczywistość, gdzie świat machinim poszedł zupełnie inną, alternatywną ścieżką.
![](https://vived.io/wp-content/uploads/2022/06/img_62a88ab72f2af.png)
Dlaczego o tym piszę? Ponieważ w zeszłym tygodniu Microsoft wypuścił cały jego kod źródłowy do internetu. Stanowi on uroczy artefakt czasów w których powstał i społeczność, która zaczęła rozkładać go na czynniki pierwsze znalazła sporo ciekawych kwiatków. Moim ulubionym kawałkiem programistycznej trivi jest informacja, że programiści preferowali kiedyś jednoliterowe zmienne bo… rozdzielczość monitorów była mała i pozwalało im to po prostu oszczędzić miejsce w linijce. Podobnych ciekawostek jest sporo, dlatego polecam powiązane z repozytorium wątki Redditowe i HackerNewsowe.
A na zakończenie, jak już pozostajemy w świecie Windowsa – ktoś próbował napisać grę na nowy Windowsowy Terminal i okazało się, że wydajność narzędzia dramatycznie spada w momencie użycia dwudziestego pierwszego koloru. Dlaczego? Jeżeli jesteście ciekawi, to twórcy oprogramowania wzięli sobie zgłoszenie na poważnie i zrobili naprawdę ciekawą analizę problemu.
![](https://vived.io/wp-content/uploads/2022/06/img_62a88ab7a14f7.png)
BTW: Dawno i nieprawda: Przez krótki czas bawiłem się w pisanie serii, podczas której brałem “na warsztat” trendujące repozytoria githubowe i robiłem im review, próbując zrozumieć, jak działają pod spodem. Dajcie znać, jeśli ktoś miałby ochotę na powrót takiej serii, może w trochę luźniejszym formacie 😉 Czasem korci mnie, żeby do tego wrócić.