DATEL: Pokud se chce nekdo starat o nastenku tak mu rad pridam prava. Ale u odkazu ktere vypadnou v googlu hned na prvni strance mi to prijde trochu zbytecne.

My jsme nedavno vybirali framework pro jednoduche RESP API pribalene k jinemu programu a vyber se nakonec zuzil na Rocket, Warp a Actix. Rocket jsme zamitli prave kvuli nightly. Nakonec to vyhral Warp, protoze nam prisel vice lightweight coz bylo jedno z hlavnich kriterii pro nase pouziti a i kdyz uz je to asi davno neplatny argument, stale si pamatujeme safety kontroverzi kolem actixu.

SHINING_KATE: V jakem stavu je ted vztah k safety v Actixu, po tom co to puvodni autor zabalil? Predpokladam ze pod vice komunitnim vedenim se to trochu procistilo.

Co se tyka GUI, tak krome aktivity kolem GTK tak jeste existuje Druid, jakozto experimentalnejsi pristup ke GUI. https://github.com/linebender/druid Ale tyto veci jdou mimo mne.

SHINING_KATE: Zatim jsem neprepinal default tj rust-analyzer ale muzu zkusit.

WILD_A: Nejsem emacs user, ale co https://emacs-lsp.github.io/lsp-mode/page/lsp-rust/ ?

MARASAN: Ja pouzivam spise nez interaktivni debugger tak intenzivni logovani a trasovani. Z trasovani pak delame taky performance analyzu. To doplnujeme standardnimi C/C++ nastroji. Ja mam rad callgrind; kolega, ktery je v tom kovany tak jeho nejoblibenejsi tool pro toto je VTune.

NYX: Nevim jestli rozbiti na vice crate az tolik pomuze. Pro pri vyvoji vice crate najednou stejne chce clovek workspace a zase tam bude jen jeden cargo lock. Alespon me nejaka takova kolize trapila davno s nejakou tehdejsi verzi RLS a vice crate mi moc nepomohlo.

co vy a debugger? profiler? VS Code je v tomhle ohledu komfortni nebo ne? pro linux.

SPIRALI: CLion + rust plugin. V teamu to momentálně máme 2x CLion, 2x VSCode + RA a 1x Atom jen se základním Rust pluginem bez autocomplete.

SPIRALI: No rust-analyzer mam vypnuty, nejak mi to kolidovalo s buildem (vyrobil ten cargo lock a build na nej pak ceka). To pouzivam jako pomerne tupy editor :) Takze asi nejsem schopny odpovedet.

Kdyz me to bude dlouhodobe stvat, dam si tu praci a rozbiju to na vic nezavislych crate. Nemelo by to byt moc slozite.

SPIRALI: pouzivam vim s nejakyma pluginama, ale uvazuju, ze zkusim MS VS Code, hlavne kvuli debuggeru.

NYX: Rust Enhanced jsem mel v planu take vyzkouset. Nejaky konkretni zdroj nespokojenosti?

btw: Umi uz RLS nebo rust-analyzer nejake vetsi refaktorizace? (napr. kdyz presunu soubor tak to opravi vsechny importy?)

SPIRALI: Ja jedu v sublime + rust enhanced + rustfmt. Ale nejak zvlast spokojeny s tim nejsem teda.

UETOYO: I kdyz to neni u zadne ISO-like organizace, tak jak to chapu ja, tak je specifikovano vse pomerne presne az na memory model. Coz je trochu problem pri psani unsafe kodu, ale trapi to primarne autory verifikacnich toolu, v praxi se uvazuje LLVM model (~ C++ model), na kterem ted stoji hlavni prekladac.

UETOYO: pardon, moje chyba, špatně jsem to přečetl. Předpokládal jsem, že tam popisují cestu Rustu k RFC procesu u nějaké mezinárodní organizace typu ISO nebo IEEE, ale to je pouze popis interního RFC mechanismu v Rust "komunitě".

Nicméně ta odpověď je hned o pár kliků vedle: https://doc.rust-lang.org/stable/ a https://github.com/rust-lang/rust

Ano, není na tom nikde razítko nějaké "modré" organizace, ale jako specifikace všech částí mi to příjde dostatečné. Například C++ to dělá stejně (draft standardu je na githubu a konkrétní vydýání pak jen "otiskne" ISO).

FALL: souhlasím, jsme tu trochu OT, ale kde je tu diskuze o MCU security? O žádné nevím.
Fyzické útoky jsou oblast, kde klasické MCU končí a nastupují secure produkty, souhlasím. Ale i tam je ta hranice jen o kus dál a pokud má útočník k dispozici neomezený přísun virgin čipů, které si může rozlámat, tak se tím otvírají další možnosti. Nedostupnost těch čipů mimo okruh ověřených zákazníků je prostě součást security.

UETOYO: hmmm, Google? https://www.rust-lang.org/governance