Wpis z mikrobloga

zastanawiam się nad wejściem w #rustlang najpierw hobbistycznie, a potem może kto wie zawodowo. jakie macie wrażenia z używania tego języka, wsparcia community, bibliotek i ich dodawania do projektu, wsparcia cross-compile?

do tej pory zawodowo robiłem w C++, dość mnie to zaczęło męczyć pisanie w nim, sporo rzeczy trzeba od zera robić. trochę w pythonie robiłem, ale brak typowania zmiennych czy nawet czasami brak bindingów do bibliotek jest dla mnie nie do przejęcia, ale zdecydowanie na plus jest łatwość instalacji bibliotek i wieloplatformowość. robię też w Javie, bardzo przyjemnie się mi w tym piszę ale potrzebuje języka bardziej pod embedded

#programowanie
  • 41
@mapache: piszę w tym zawodowo od pewnego czasu. Na początku trochę zajmuje przyzwyczajenie się do borrow checkera i nauczenie się pewnych charakterystycznych idiomów. Potem idzie już bardzo gładko. Ogólnie na plus: dobry tooling (cargo), całkiem szybki kompilator przyrostowy, chyba najlepsze komunikaty o błędach jakie kiedykolwiek widziałem, bardzo wysoka wydajność generowanych programów, język na tyle wysokopoziomowy, że pisze mi się w nim szybciej i. wygodniej niż w Javie, zwłaszcza biorąc pod uwagę
@Krolik: a jak z łatwością implementacji popularnych wzorców? w Javie jest to świetnie rozwiązane, mówię o popularnych wzorcach typu Observer czy Singleton. z ciekawości, na czym polega twój projekt zawodowy gdzie używasz Rust?
@mapache: Rust nie jest OOP w sensie Javy, więc wzorce Javowe / GoF radzę odstawić na półkę. Generalnie kodowanie w Rust w stylu jakby to była Java to proszenie się o bęcki od kompilatora. Projekt nad którym pracuje, to proxy o ultra niskich opóźnieniach na potrzeby rozproszonego systemu baz danych w chmurze, umożliwiające mirroring ruchu.
Rust nie jest OOP w sensie Javy, więc wzorce Javowcy radzę odstawić na półkę. Generalnie kodowanie w Rust w stylu jakby to była Java to proszenie się o bęcki od kompilatora.


@Krolik: mógłbyś rozwinąć? nie jestem jakimś wymiataczem Javowym, i piszę w nim po prostu jak w języku obiektowym
@mapache: 1. Rust nie ma dziedziczenia implementacji 2. Robienie struktur danych w których masz wiele elementów powiązanych referencjami (a jeszcze gorzej - cyklicznymi referencjami) wepchnie Cie w objęcia tzw lifetime annotations albo Arc/Rc, a w przypadku cykli szykuj się na ostrą walkę z kompilatorem 3. W safe Rust generalnie nie ma mutowalnych globali / static. 4. Rust preferuje polimorfizm statyczny; dynamiczny istnieje (dyn) ale ma dużo ograniczeń - dlatego tak gdzie
@mapache: a i jest jeszcze jedna rzecz która mocno wpłynęła na to jak programuje i ułatwiła wiele rzeczy - musisz sobie zdać sprawę że w Rust bardzo wiele wartości / obiektów przekazuje się przez wartość przez tzw move. Przekazywanie nawet dużych kolekcji przez wartość jest bardzo tanie i zajmuje raptem kilka cykli CPU, niezależnie od tego ile faktycznie danych np. masz w takim wektorze. Jak to sobie człowiek uświadomi to przechodzi
jakie macie wrażenia z używania tego języka,

@mapache: dla mnie Rust jest językiem, w którym po prostu przyjemnie mi się pisze, można się pobawić funkcyjnymi rzeczami, a samo to jak język jest zaprojektowany sprawia, że większość bugów które powoduję jest wykrywane w czasie kompilacji

wsparcia community,

z doświadczenia community jest bardzo oddane i żywe

bibliotek i ich dodawania do projektu

z bibliotekami jest różnie, niestety Rust to nadal dosyć młody język
, jedyny problem jaki widzę to że ilość bibliotek bardzo mocno wpływa na czas kompilacji, który i tak krótki nie jest (ale z doświadczenia lepszy od


@Sachees: Rust kompiluje wszystkie zależności ze źródeł. Np. dodanie jako zależności samego GTK4 to ponad 250 tys linii do skompilowania. I jestem pod wrażeniem że zajmuje to mniej niż minutę. Natomiast pocieszające jest to że to wystarczy zrobić raz, a potem kompiluje przyrostowo. Przyrostowy czasy
@Sachees: rozwiązalismy ten problem przez layered image. Generujemy najpierw osobną warstwę tylko z samymi zależnościami, bez naszego kodu, obraz z zależnościami trafia do cache dockera i dopiero nad tym jest właściwy obraz z kodem projektu. Zależności przekompilowuja się tylko jak zmienimy Cargo.toml. Obczaj sobie cargo-chef.
@bajcik: nie każdy ficzer można łączyć z każdym innym. Np. async nie działa w traitach, impl Trait można zwracać tylko w niektórych sytuacjach (np. nie działa w sekcji where albo w innych traitach), const generics działają tylko z wybranymi typami prostymi, nie wszystkie traity można używać z dyn, partial borrowing nie przechodzi przez granice wywołań funkcji (więc czasem extract function nie jest możliwe) itp. Duża część z tych ograniczeń będzie usunięta
via Wykop Mobilny (Android)
  • 0
@mapache: Problem z rustem jest taki, ze komercyjnie używa się go w określonym raczej wąskim zakresie - t gdzie wydajność jest kluczowa i nie da rady np golang. Wiec wybór projektów jest raczej niewielki i raczej na jedno kopyto
@yhbgrobdoivbvwamsv: Rust jest uniwersalny i są firmy, które używają go nawet do CRUDów, aplikacji GUI / mobilnych czy nawet frontendów za sprawą WebAssembly. Oczywiście najbardziej jest używany do pisania komponentów systemów operacyjnych (Google Android), przeglądarek (Firefox, Chrome), systemów baz danych (np. ScyllaDB, DataStax Astra), narzędzi CLI, infrastruktury chmurowej (pokaźna część AWS jest napisana w Rust, między innymi S3), w kryptowalutach, w systemach embedded. Jest oczywiście młodym językiem i wiadomo że łączna
@devopsiarz: chwali się na swoim blogu oraz w wywiadach z pracownikami. Wg jednego z nich na ZDNet: "AWS services built on Rust include Firecracker, the technology behind its Lamba serverless platform for containerized apps, Amazon Simple Storage Service (S3), Elastic Compute Cloud (EC2), its CloudFront content delivery network, and Bottlerocket, a Linux-based container OS." Poza tym zatrudniają wiel kluczowych deweloperów zaangażowanych w ekosystem Rust, m.in. programistów kompilatora oraz programistów Tokio.
Jeśli chodzi o to infrastrukturę, to jeszcze bardzo dużym użytkownikiem Rusta jest Cloudflare. Cloudflare twierdzi na swoim blogu że obsługuje bilion (ang trillion) zapytań HTTP dziennie i że zastąpili Nginx własnym rozwiązaniem w Rust.
Chwali się na swoim blogu oraz w wywiadach z pracownikami. Wg jednego z nich na ZDNet: "AWS services built on Rust include Firecracker, the technology behind its Lamba serverless platform for containerized apps, Amazon Simple Storage Service (S3), Elastic Compute Cloud (EC2), its CloudFront content delivery network, and Bottlerocket, a Linux-based container OS."


Wiem, że mają projekty w Rust, ale swojego talka o S3 dawno nie aktualizowali, więc nie wiem, czy uprawnione
ale pisali, że to nie jest szybsze od nginksa ( dlatego jest w Ruście), tylko coś zrobili jeszcze z architekturą.


@devopsiarz: tak jak pisałem wyżej, wydajność nie zawsze jest powodem używania Rust. Często jest to bezpieczeństwo, poprawność, łatwość utrzymania kodu przy zachowaniu wydajności nie gorszej niż C lub C++. Nie miałbym obiekcji wrzucić na projekt w Rust juniora bo wiem że nie narobi szkód (zabronię mi używać unsafe, a wszelkie miejsca
via Wykop Mobilny (Android)
  • 0
@Krolik: Oczywiście ze jest uniwersalny, tak jak chyba każdy jezyk.
Ale ze względów czysto biznesowych używa sie go tam gdzie się to opłaca.
Nikt nie będzie pisał np prostego sklepu internetowego bo duzo taniej zrobi to np w PHP czy innym pythonie.
Język to jedno, narzędzia to drugie a tez koszt i ilość dostępnych ludzi to jeszcze co innego. (I ich jakosc).
Z tego wzgledu, ze do większości szeroko pojętych prac
Oczywiście ze jest uniwersalny, tak jak chyba każdy jezyk.


@yhbgrobdoivbvwamsv: No nie tak jak każdy język. W Rust napiszesz perfekcyjnie działający sklep internetowy, łącznie z frontendem tegoż sklepu działającym po stronie przeglądarki. Rust ma już obecnie kilka dojrzałych, konkurujących ze sobą frameworków www, podobnie ma dobre API do baz danych, obsługi JSONa itp. Ale w Rust napiszesz też sterownik do bazy danych, system plików czy nawet sterownik karty grafiki i nie
via Wykop Mobilny (Android)
  • 0
@Krolik: Jezu, ja nie twierdze, ze nie napiszesz strony www w ruscie, tylko ze jeśli pptrzbeujesz stronę www to zamiast zatrudniać raczej mocno drogiego programistę tego języka jeśli w ogóle będzie dostępny bierzesz z ogromnego rynku dwóch pehapowcow za ułamek ceny i gotowe.
Jak potem trzeba cos poprawić to znowu za ułamek ceny i w ułamku czasu bierzesz kolejnych pehapowcow.
Z tego powodu na rynku króluje Java, Pyhton czy JS -
Jezu, ja nie twierdze, ze nie napiszesz strony www w ruscie, tylko ze jeśli pptrzbeujesz stronę www to zamiast zatrudniać raczej mocno drogiego programistę tego języka jeśli w ogóle będzie dostępny bierzesz z ogromnego rynku dwóch pehapowcow za ułamek ceny i gotowe.


@yhbgrobdoivbvwamsv: Ok, zgadzam się, ale jednak nie do końca. Z tanimi PHPowcami to ja już trochę miałem do czynienia personalnie i to jest mniej więcej tak jak z tanimi
@Krolik:

Z tym "dużo" bardziej to mam wątpliwości. Zależy też jak liczyć popularność. Go się mocno okopało w k8s / devops / jakiś pierdółkach sieciowych, ale nie jest popularne w takiej dużej liczbie różnych nisz w jakich znalazł się Rust; którego używa się od głupich CRUDów, poprzez bazy danych, narzędzia CLI, aż do systemów operacyjnych i systemów embedded. W efekcie Rust buduje znacznie szybciej duży i bardzo zróżnicowany ekosystem bibliotek.


Go
@devopsiarz: > było potrzebne to właśnie ta "szeroka gama zastosowań jak Rust" -

@devopsiarz: szeroka gama zastosowań powoduje że masz większy zwrot z inwestycji w naukę języka, bo uczysz się raz a używasz do różnych celów. Poza tym RoR był popularny ze względu na Rails a nie Ruby. Inne frameworki w innych językach skopiowały część rozwiązań i potrzeba uczenia się nowego języka zmalała.
Wyfiltruj sobie tylko Go i Rust to zobaczysz, to zupełnie nie ta skala. Próg wejścia do Rusta robił, robi i będzie robił swoje.


@devopsiarz: wg Pypl Index bazującym na Google trends są praktycznie na równi. 11 i 12 miejsce.
@Krolik:

szeroka gama zastosowań powoduje że masz większy zwrot z inwestycji w naukę języka, bo uczysz się raz a używasz do różnych celów.


To imho zły argument, bo RoR używa się tam, gdzie trzeba szybko zrobić i spieniężyć projekt (jakkolwiek - inwestorzy, klienci, itp). I pod to cały ekosystem jest już sprawdzony przez tysiące startupów, a nie tylko 1 jakaś tam biblioteka.

Użycie znacznie trudniejszego języka, z mniej przetestowanymi frameworkami/libami, spowoduje,
@devopsiarz: chyba piszesz o czymś innym. Z punktu widzenia pojedynczego projektu bezpośrednio niby nie jest jakoś bardzo pożądane aby używana technologia miała szerokie zastosowania - i z tym się mogę zgodzić. Jednak inaczej to wygląda z punktu widzenia sukcesu języka jako całości. Co zresztą Twój przykład doskonale obrazuje: Ruby jest obecnie *mniej* popularny niż Rust (i PHP i Python i Go) i notuje trend spadkowy, mimo olbrzymiej popularności kiedyś.

Szerokie zastosowania
Słowem: spóźnimy się nawet na swój pogrzeb, ale będziemy mieć satysfakcję, że mamy "zwrot inwestycji w naukę języka".


@devopsiarz: ale to są tylko jakieś Twoje projekcje. Po pierwsze do projektu najczęściej bierze się ludzi którzy już język umieją, więc to czy nauka zajęła tydzień czy 2 miesiące nie ma znaczenia, bo tego czasu nie wlicza się do projektu. Po drugie nawet jeśli trzeba wyszkolić ludzi pod projekt, to z wyjątkiem jakiś
ale to są tylko jakieś Twoje projekcje.


Dobrze, to jaki znasz +- znany startup, który:

1) Core ma w Rust i to od samego początku, nie że sobie coś przepisał, tylko, że od niego zaczynał
2) Jest w działce z jakąś konkurencją ze strony innych startupów
3) Odniósł sukces, w którym pomógł mu Rust, bo skoro ma konkurencje, to jest szansa, że to przez ten wybór

Wymień choć jeden, w którym rozpoczęli
@devopsiarz: cały czas mylisz ze sobą dwie niezależne od siebie rzeczy: trudność opanowania czegoś z szybkością używania tego czegoś po opanowaniu. Koparke trudniej opanować niż łopatę. Ale jak nauczysz się posługiwać koparką, to zrobisz wykop szybciej niż łopatą. Nie ma też żadnego czasu straconego na działający kod. W czasie kiedy ja poprawiam błąd wyłapany przez kompilator (a właściwie: IDE podczas pisania) Ty jeszcze czekasz na CI na wyniki testów i zakładając
Ty jeszcze czekasz na CI na wyniki testów i zakładając optymistycznie że masz dobre testy, które błąd wyłapią, zaczynasz poprawiać ten sam błąd znacznie później niż ja, mając znacznie mniej informacji odnośnie tego co błąd spowodowało i kończysz te samą robote później


To w takim razie weź mi wytłumacz, na logikę, dlaczego masz testy w swoim projekcie, skoro starczy kompilator? Twoja wypowiedź wskazuje, że to, co wykryją testy, wykryje też kompilator i
@devopsiarz: mam testy, bo nie wszystkie błędy wykryje kompilator. Ale im więcej błędów wykrywa kompilator, tym mniej czasu tracę na poprawianie błędów i powtarzanie testów. Testy w każdym nietrywialnym projekcie trwają dłużej niż kompilacja, a poza tym kompilator dostarcza precyzyjniejszej informacji o tym co jest źle i zwykle dokładnie w momencie gdy napisze błędny kod - mam cały kontekst w głowie na świeżo i poprawianie takiego błędu trwa ułamek czasu w
@Krolik: piszę w Pythonie, Go i Ruście i obserwacje mam taką (mam startup w Ruście): bez testów zrobię dokładnie taki sam błąd jak w Pythonie, Go czy Ruście. Rust ochroni mnie przed oczywistymi błędami związanymi z typami, to wiadome, ale jest absolutnie zero różnicy jak chodzi już o samą logikę biznesową, a ja staram się mocno korzystać z systemu typów (przez co często sobie robię pod górę w Ruście, bo np.
Nawet spojrzałem na issues Twojego projektu, te zamknięte z tagiem bug - to tylko potwierdza to, o czym mówię.


@devopsiarz: co potwierdza? Że na ok. 10k linii w całej historii projektu było całe kilka błędów, żaden nie był crashem aplikacji, blockerem, freezem/hangiem, wyciekiem zasobów? Duża część z tych błędów to pierdółki typu niedostateczny komunikat o błędzie, rzeczy związane z różnymi reprezentacjami ścieżek nie UTF-8 na różnych systemach na których nie mam
@Krolik:

. Poza tym nie wciskaj mi kitu, że w Go popełnisz te same błędy - bo ja trochę w Go pisałem i okazji do strzelenia poważnego błędu jest znacznie, znacznie więcej niż w Rust.


Mając mniejsze skille w tym języku niż w innym, to chyba oczywiste.

Praktycznie na każdym kroku. Możesz zapomnieć posprzątać, możesz zapomnieć sprawdzić czy wywołanie zwróciło błąd, możesz niechcący zmodyfikować dane, do których jest dostęp z innego
@devopsiarz: No fajny fikołek logiczny - twierdzę, że kompilator Rust wykrywa znacznie więcej rodzajów błędów niż Go, a Ty jako kontrargument dajesz, że "ale nie wykrywa wszystkich". No super. Tylko że nikt tu nie twierdził że Rust wykrywa wszystkie błędy. Pasów w samochodzie nie zapinasz? Przecież nie gwarantują, że uchronią Cię przed śmiercią w każdym wypadku.

Ale skoro Ty rzucasz papierem, to proszę bardzo, nie będę dłużny:
https://songlh.github.io/paper/go-study.pdf

Część z ww
ale jak np. regularnie budujesz obraz dockerowy na którym kompilujesz projekt Rustowy to już boli


@Sachees: to zacznij używać cargo chef i layered cache dockerowego