• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPIRALIRust - Programovací jazyk
    BONEFLUTE
    BONEFLUTE --- ---
    JON: Supr. To by mohlo být ono. Díky moc.
    JON
    JON --- ---
    BONEFLUTE: hledej doubly linked list, neni to v rustu uplne jednoduche.

    Simple doubly-linked list in safe Rust · GitHub
    https://gist.github.com/matey-jack/3e19b6370c6f7036a9119b79a82098ca

    LinkedList in std::collections - Rust
    https://doc.rust-lang.org/std/collections/struct.LinkedList.html
    BONEFLUTE
    BONEFLUTE --- ---
    CUCHULAIN:
    Pardon. Dovysvětlím:
    Chci vytvořit strom komponent. App je kořen. Má kolekci Window. A každý Window má odkaz na svého rodiče. Tudíž předpokládám, že mu nemohu předat jen ten odkaz na App, protože bych tomu předal vlastnictví, a ony všechny ty okna odkazují na stejného rodiče. Nebo uvažuju špatně?
    Potřebuju, aby každý Window se dostal ke svému rodiči (bude mu totiž posílat zprávu).
    CUCHULAIN
    CUCHULAIN --- ---
    BONEFLUTE: takhle na první pohled mě napadá, že Window, ale nevím, co od toho očekáváš.
    BONEFLUTE
    BONEFLUTE --- ---
    Zdravím. Prosím o radu.

    Dělám strukturu asi takto:
    struct App {
        windows: Vec<Window>,
    }
    struct Window {
        parent: App,
        items: Vec<Control>,
    }
    struct Control {
        parent: ...
    }

    A teď uvažuju, jakého typu má být ten parent. Box[App]? Nebo Rc[App]?

    Zkoušel jsem to tak nějak různé, a vždycky z toho vylezla divná obluda. Prolejzal jsem zdrojáky knihoven, že se inspiruju, ale ty jsou na mě zase nad moje znalosti. Trochu se v tom topím.

    Předem díky.
    JUNIOR
    JUNIOR --- ---
    SHINING_KATE: Díky za perfektní odpověď. Přesně podobnou zkušenost jsem hledal, hlavně přesně s tím Actix a jak si dělá věci po svém. Nakonec po zralé úvaze to zkusím s Axum. Díky moc!
    SHINING_KATE
    SHINING_KATE --- ---
    JUNIOR: Ale disclaimer, to co děláme je docela komplexní aplikace, třeba jedna z našich servis musí zpracovávat jak HTTP Api, tak požadavky které přichází přes MLLP protokol, máme built-in request queue abychom zaručili odeslání requestů dalším službám (https://gitlab.com/famedly/company/backend/libraries/requeuest) a tak. Pro normální Api server bude Actix fajn, a má opravdu dobrou dokumentaci. Jen bych opravdu začala vývoj už na betě 4.0 a počítala s nějakým refaktoringem, protože mezi různými beta verzemi se dost měnilo api.

    A vyhla bych se Dieselu na databáze. Je v tom částečně osobní antipatie k ORM, ale diesel navíc pořád není async, má naprosto šílené chybové hlášky s šílenými typy a obecně mi spíš házel klacky pod nohy. Super je sqlx :)
    SHINING_KATE
    SHINING_KATE --- ---
    JUNIOR: actix si dělá spoustu věcí po svém. Vlastní http typy, vlastní server, vlastní http klient, vlastní runtime. Crates jako http, tokio a hyper jsou momentálně v podstatě industry standard a velká část ekosystému je používá , což vedlo k nutnosti otravných konverzí typů. A míchání víc async runtimes v jednom projektu je velký špatný.

    Actix-rt je v podstatě wrapper nad tokio, ve stabilní verzi actix je ovšem založený na tokio 0.2 - většina ekosystému už staví na tokio 1.x a je nekompatibilní. Dá se to řešit používáním actix 4 beta, tam ale dochází k dost překotnému vývoji a pořád se rozbíjí. Navíc se tím rozbíjí kompatibilita s 3rd party middlewary. Věřím že stabilní verze Actix 4 tohle vyřeší, momentálně je to dost mess :) Pro soukromý projekt je ale 4 beta asi v pohodě.

    Actix-rt je single threaded. Actix-web aplikace je sama o sobě multithreaded, ale je to prostě několik jednovláknových async workerů. Teoreticky to vede k vyššímu výkonu - nic se neposílá mezi systémovými thready, na stranu druhou, pokud dojde nedopatřením / chybou vývojáře k zablokování threadu, neexistuje jiný thread co by si přebral tasky které jsou tam naplánované.
    Navíc to vede k tomu, že actix futures a typy jsou !Send, což nám v některých situacích komplikovalo práci.

    Actix sám o sobě je hodně dobrý. Má skvělou dokumentaci, rozsáhlý ekosystém, ale je tam to ale v "sám o sobě" :)
    JUNIOR
    JUNIOR --- ---
    SHINING_KATE: Mohla by jsi prosím více rozvést v čem konkrétně vám actix nevyhovoval a ty velké skoky mezi verzemi? Já bych nerad to moje api za rok předělával.

    A proč je pro vás tak důležité Tokio?
    VELDRANE
    VELDRANE --- ---
    SHINING_KATE: ja sem rust zacatecnik ale potrebuju tu sbastlit jakesi api a ten poem mne na to prisel jako dobrej napad. Ale uznavam ze mam jeste velky mezery ve vzdelani a proto se ptam i tady :)
    SHINING_KATE
    SHINING_KATE --- ---
    Poem vypadá zajímavě

    U nás ve firmě jsme začali na actix-web, a postupně po vydání frameworku axum přesedlali na něj (actix měl dost nestandardních věcí, úplně se nám nelíbil actix runtime a divoké skoky mezi verzemi… A axum má jako podvozek hyper, používá tower services, je těsně svázán s Tokio projektem… Prostě, víc zapadá do ekosystému :)

    Na podporu openapi ovšem ještě čekáme.
    VELDRANE
    VELDRANE --- ---
    JUNIOR: Mam podobnej problem, tak kdyz se nekdo ozve budu rad.

    Zatim backend patlam v poem a sem vcelku spokojenej, umi to nativne openapi, mel by na to jit naroubovat prometheus exporter a to je vsechhno co potrebuju
    JUNIOR
    JUNIOR --- ---
    Ahoj,
    mám v plánu si udělat jeden vlastní projekt a rád bych na to použil Rust.

    Bude to webová aplikace na principu bazaru, kde budu potřebovat registrovat uživatele, aby si mohli uploadovat obrázky, mezi sebou hodnotit produkty a profily, rozesílání emailů a časem možná platební brána.

    Jsem si dělal research a zatím mi nejlépe vychází framework Actix. Jaký framework či runtime si vybrat ? Na co si dát pozor ? Přeci jen Rust není tak rozšířený tak bych se rád vyhnul problémům v budoucnu.

    Děkuji
    SHINING_KATE
    SHINING_KATE --- ---
    Trochu self-proma, pokud někdo stavíte aplikaci postavenou nad sqlx a potřebujete použít databázi v testech, není to nic jednoduchého.

    Napsala jsem kvůli tomu proc-macro knihovnu, která funguje podobně jako `tokio::test` makro, umí pracovat s tokio runtime a actix runtime, a která provede všechny databázové migrace potřebné pro vaši aplikaci a následně exponuje proměnnou s databázovým poolem do vaší testové funkce.

    Každá takhle vytvořená a zmigrovaná databáze má jméno založené na UUIDv4, takže by neměla hrozit kolize ani při několika paralelně spuštěných testech.

    https://crates.io/crates/sqlx-database-tester

    feature requesty vítány.

    (Kvůli naší firemní politice je licence AGPL, ale pokud to použijete v testech / pipelines, výsledný kód neobsahuje z knihovny nic, takže je viralita licence celkem zbytečná a neměla by nic ovlivnit, ale nejsem právník)
    SHINING_KATE
    SHINING_KATE --- ---
    UETOYO: Už na něj přecházíme v práci :)
    SHINING_KATE
    SHINING_KATE --- ---
    Team kolem tokio před týdnem oznámil nový projekt, webový framework axum https://tokio.rs/blog/2021-07-announcing-axum

    A po vyzkoušení se dost rychle stal mou novou volbou pro příští projekty :)

    Výhody (některé z nich nejspiš subjektivní):
    - naprosté minimum NIH: používá čistou tokio runtime (looking at you, actix), používá hyper, umí využívat middlewary psané pro Tower
    - přehledný routing a vnořené cesty (tohle mi chybí u Rocket), možnost implementovat middleware jen na jeden endpoint, skupinu cest, celou aplikaci (Tohle třeba rocket nedává vůbec)
    - jednoduchý error handling (tohle je dost bolest třeba u Warpu)

    Nevýhody:
    - Fakt nevím, napadá mě jen, že některé frameworky umí generovat OpenAPI specifikaci přímo z kódu, tohle Axum (alespoň zatím) nezvládá.

    Každopádně doporučuji vyzkoušet, zatím jsem dost nadšená :)
    MYKEZ
    MYKEZ --- ---
    UETOYO: Mohl bys prosím popsat, jak vypadá ta symbióza, resp. na co ještě používáš Python, a co už naopak raději děláš v Rustu, a jakej mezi nima máš interface?
    UETOYO
    UETOYO --- ---
    Tak ten článek je naštěstí naprostý blábol plný takových sugestivních názorů. Tehnicky i filozofiíí je Rust je spíš podobný OCamlu (v němž byl napsaný i jeho první kompilátor) než Haskellu. Haskell opravdu začal jako akademický jazyk, stále je to akademický jazyk a posledních pár let se v něm tu a tam objeví komerční projekt (zajímavá firma co dělá napůl v Haskellu a napůl v Rustu). Rust to má samozřejmě naopak tak nějk podobně jako ten OCaml, který to valil od počátku mnohem víc pragmatičtěji. Na aroganci jsem nenarazil v žádném ze zmiňovaných jazyků ani kokomunitě. Ale díky za příspěvek. BTW: Přecházím z Pythonu pomalu zcela na Rust. Poslední co jsem řešil je "nenahraditelný" Pandas. Už je nahrazen :) https://github.com/pola-rs/polars-book
    CABOWITZ
    CABOWITZ --- ---
    (zaroven mam pocit, ze nejaky ten parochialismus nebo aroganci v rust komunite zatim nevnimam - ale ja taky jen tak otukavam po povrchu)
    CABOWITZ
    CABOWITZ --- ---
    What killed Haskell, could kill Rust, too · GitHub
    https://gist.github.com/graninas/22ab535d2913311e47a742c70f1d2f2b
    UETOYO
    UETOYO --- ---
    GitHub - rustviz/rustviz: Interactively Visualizing Ownership and Borrowing
    https://github.com/rustviz/rustviz
    SPIRALI
    SPIRALI --- ---
    Tak v nejblizsich dnech vyjde 1.53 a konecne se zaclenenym "|" uvnitr pattern marching vyrazu (i.e. Some(1 | 2)). Yay!
    SPIRALI
    SPIRALI --- ---
    SHINING_KATE: Vyhrala jsi prava na nastenku:)
    SHINING_KATE
    SHINING_KATE --- ---
    In other news, hlavně asi pro Rust začátečníky, Jon Gjengset oznámil vydání své knihy pro No Starch Press :)
    Rust for Rustaceans | No Starch Press
    https://nostarch.com/rust-rustaceans

    Jeho videa na youtube můžu taky vřele doporučit :)
    SHINING_KATE
    SHINING_KATE --- ---
    Tohle repo by se mohlo hodit i do záhlaví :)

    https://github.com/mre/idiomatic-rust
    REDGUY
    REDGUY --- ---
    Uhm... a jak tohle prosim souvisi s Rustem? Slo by to prosim resit nekde jinde?
    SHINING_KATE
    SHINING_KATE --- ---
    Já zas zažila pohovor ve stylu „Je to ženská, musím ji na něčem nachytat“, zatímco známý co šel do stejné firmy měl pohovor podstatně snazší, protože u chlapa se ty znalosti předpokládají :)

    Každopádně, diverzity kvóty u nás ve firmě nejsou (a ani by nebyly potřeba, hiring pool rust devů je hodně pestrý). Ta poznámka v inzerátu má spíš za účel odradit někoho, kdo v pestřejším teamu nedovede pracovat bez konfliktů.
    MARASAN
    MARASAN --- ---
    MART1NKA: mne v jedne praci predstavovali v kanclu developeru a meli tam slecnu, nejspis junior dev, predstavili mi ji jako ozdobu, doslova.
    ANT_39
    ANT_39 --- ---
    MART1NKA: Kamarád mi říkal, že u nich je befel u tzv. diverzitnich kandidátů mhouřit víc oči, nedávat vůbec technický testy, atd. Že bude nějaká firma až tak... cynická? že to tomu kandidátovi prostě řeknou, bych ale nečekal.
    Kliknutím sem můžete změnit nastavení reklam