• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
    • přihlásit
    registrace
    ztracené heslo?
    SPIRALIRust - Programovací jazyk
    JUNIOR
    JUNIOR --- ---
    1 odpověď+1
    BONEFLUTE: A když spustíš cargo tak ti to vyhodí co za error ? Ten debug v Rustu je naprosto skvělá věc
    BONEFLUTE
    BONEFLUTE --- ---
    2 odpovědi
    JON: Tak já už nevím.

    Zkoušel jsem už všechno co mě napadlo. Ale vždycky jsem se na něčem zasekl. Já prostě nedokážu protlačit ten parent v metodě append.
    Tak jak to mám níže mi to nefunguje, protože jako `append(&mut self,` mi to vrací `Root`, místo `Rc[Root]`.
    Zkoušel jsem i nevracet Rc[Self] ale přímo Self. Ale tam jsem opět zasekl v append. Divoce jsem to vydereferencoval (`*(&*self)`) až do fáze, že to chtělo Copy trait. Což nechci.

    Můžete se mi prosím podívat na následující "ideální" kód, a poradit mi, jak to upravit?

    use std::rc::Rc;
use std::fmt::Display;


struct Item {
	name: String,
	parent: Rc<Root>,
}
impl Item {
	pub fn new(parent: &Rc<Root>, name: String) -> Rc<Self> {
		Rc::new(Self {
			name: name,
			parent: parent.clone(),
		})
	}
}


struct Root {
	name: String,
	items: Vec<Rc<Item>>,
}
impl Root {
	pub fn new(name: String) -> Rc<Self> {
		Rc::new(Self {
			name: name,
			items: vec![],
		})
	}
	pub fn append(&mut self, itemname: String) {
		self.items.push(Item::new(&self, itemname));
	}
}
impl Display for Root {
    fn fmt(&self, w: &mut std::fmt::Formatter) -> std::result::Result<(), std::fmt::Error> {
        write!(w, "{} [", self.name)?;
        for x in self.items.iter() {
            write!(w, "{}, ", x.name)?;
		}
        write!(w, "]")
    }
}


fn main() {
	let tree = Root::new("Kay".to_string());
	tree.append("Alfa".to_string());
	tree.append("Beth".to_string());
	println!("{}", tree);
}
    BONEFLUTE
    BONEFLUTE --- ---
    JON: Supr. To by mohlo být ono. Díky moc.
    JON
    JON --- ---
    2 odpovědi
    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 --- ---
    1 odpověď
    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 --- ---
    1 odpověď
    BONEFLUTE: takhle na první pohled mě napadá, že Window, ale nevím, co od toho očekáváš.
    BONEFLUTE
    BONEFLUTE --- ---
    1 odpověď+1
    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 --- ---
    +1
    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 --- ---
    1 odpověď+3
    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 --- ---
    1 odpověď
    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 --- ---
    2 odpovědi
    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 --- ---
    2 odpovědi+2
    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 --- ---
    +5
    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 --- ---
    +1
    UETOYO: Už na něj přecházíme v práci :)
    UETOYO
    UETOYO --- ---
    +2
    UETOYO: Jsem zapoměl odkaz, tak přidám něco navíc
    - https://www.fpcomplete.com/rust/
    - https://www.fpcomplete.com/blog/philosophies-rust-haskell/
    - https://www.youtube.com/watch?v=HKXmEFvsi6M&t=3222s&ab_channel=LambdaShow
    SHINING_KATE
    SHINING_KATE --- ---
    +8
    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 --- ---
    +5
    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?
    Kliknutím sem můžete změnit nastavení reklam