• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    SPIRALIRust - Programovací jazyk
    LYCO
    LYCO --- ---
    RESURRECTION: To tvrzení že "ukazatele v Cčku mají jednuduchou a intuitivní sémantiku" je taky blbost. Donedávna se nevědělo co je to ukazatel(!) a teprve nedávno se to asi podařilo vyřešit (https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2676.pdf). Lidštější vysvětlení jsou třeba https://www.ralfj.de/blog/2018/07/24/pointers-and-bytes.html a https://faultlore.com/blah/fix-rust-pointers/#cheri

    (Neptejte se mě na detaily, sám tomu skoro vůbec nerozumím, ale aspoň vím že nevím.)
    MARASAN
    MARASAN --- ---
    SPIKE411
    SPIKE411 --- ---
    Nebo možná spíš
    https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html
    Mobile devices have limited resources and we’re always trying to make better use of them to provide users with a better experience (for example, by optimizing performance, improving battery life, and reducing lag). Using memory unsafe code often means that we have to make tradeoffs between security and performance, such as adding additional sandboxing, sanitizers, runtime mitigations, and hardware protections. Unfortunately, these all negatively impact code size, memory, and performance.

    Using Rust in Android allows us to optimize both security and system health with fewer compromises. For example, with the new UWB stack we were able to save several megabytes of memory and avoid some IPC latency by running it within an existing process. The new DNS-over-HTTP/3 implementation uses fewer threads to perform the same amount of work by using Rust’s async/await feature to process many tasks on a single thread in a safe manner.
    SPIKE411
    SPIKE411 --- ---
    UB asi tohle
    CppCon 2017: Piotr Padlewski “Undefined Behaviour is awesome!”
    https://www.youtube.com/watch?v=ehyHyAIa5so

    https://cpp.mimuw.edu.pl/files/ub.pdf

    Google debunk bude hádám tohle
    Rust fact vs. fiction: 5 Insights from Google's Rust journey in 2022 | Google Open Source Blog
    https://opensource.googleblog.com/2023/06/rust-fact-vs-fiction-5-insights-from-googles-rust-journey-2022.html

    Software in Decline asi tohle
    Software is in Decline - Jonathan Blow
    https://www.youtube.com/watch?v=FeAMiBKi_EM
    MARASAN
    MARASAN --- ---
    RESURRECTION: mi ty tvoje odkazy davaji v Brave Browseru
    <a rel="noopener noreferrer">Google to krásně debunknul</a>
    Nechces prosimte postnout rovnou URLs? Dik.
    SPIKE411
    SPIKE411 --- ---
    RESURRECTION: Skvělé, díky!
    RESURRECTION
    RESURRECTION --- ---
    SPIKE411: Tohle se dost podrobně řešilo na Redditu v C++ i v Rustu. Ten člověk má sice zkušenost s C++, ale s Rustem minimální a základním věcem ani nerozumí, např. co je to unsafe Rust. Já jsem 10 let dělal C++ a teď už pár let Rust a je to tedy nesrovnatelné s tím, že Rust je prakticky ve všem lepší. Když jsem s ním začínal, byl jsem extrémně skeptický, ale vždy když mi něco nesedělo a pak jsem pochopil, proč je to v Rustu jinak než v C++, tak mi to došlo a ve 100 % případů měl "Rust pravdu". Můj dojem z toho byl, že takhle by C++ vypadalo, kdyby vzniklo dneska a ne v roce 1979.

    Ale k tomu článku:
    - Unsafe Rust: Je to normální Rust, jen v něm fungují jiná (komplikovanější) pravidla. Vlastně je to velmi blízko tomu jak C++ funguje normálně. Je to celé invertované, C++ je defaultně unsafe a když se snažíš, tak je safe. Rust je defaultně safe a když chceš, můžeš psát unsafe variantu. Inline assembly příměr je úplne mimo. Spíš C++11/14/17/20 vs C++98/03.

    - Safety Toll: I po 10 letech jsem občas napsal kód, který crashoval. Prostě jsem si kolikrát neuvědomil při psaní ty nuance. Možnost psát Rust, kde je nemožné takové chyby dělat (a mnoho dalších) je naprostý game changer. A ten "trade off" performance vs safety je falešné dilema. Jednak Google to krásně debunknul, ale hlavně když vaše blbost crashuje a neběží, tak může být nejrychlejší v historii, ale nikomu to k ničemu není.

    - UB=optimalizace: Doporučuji následující video: Undefined Behaviour is Awesome. Je to vtipné a velmi děsivé. Kompilátor skutečně na základě UB dělá optimalizace, ale málokdy takové, které fakt chcete. Navíc se na to nedá spolehnout. A opět viz Google výše, v naprosté většině případů je to stejně irelevantní. V článku zmiňované bounds checking mají na dnešních cpu nulový dopad na performance.

    - Cache locality: Nic souvisejícího s C++ a totální nesmysl, že to v Rustu je těžké. Já jsem v tomhle ohledu měl naopak lepší zkušenost v Rustu, kde je všechno explicitní. V C++ jsem vlastně spoléhal na to, že kompilátor udělá co bych chtěl/čekal, protože tam je strašně moc věcí implicitních. Třeba padding apod. Srovnej třeba s std::pin. Přesně věc na to co on popisuje v článku. A je to explicitní, narozdíl od C++, kde se mi přesně podařilo vždy vyskenout chybu v self-referential věcech.

    - Compiler choice: Jop, velká výhoda, když napíšete perfektně validní C++ a pak zjistíte, že na MSVC se to nezkompiluje a v Clangu se to chová jinak než v GCC. Ohromná zábava takové věci "řešit". O nějakých no-name kompilátorech třetích stran ani nemluvim. Tam půlka standardu není implementovaná vůbec a druhá je blbě.

    - Resources: Naprosto nemám problém k jakémukoliv probému (i obskurnímu) najít zdrojek Rustu. K C++ toho je víc, protože existuje 4x dýl (ale často je to zastaralé).

    - The Dubious Benefits of Safety: Tady se asi opravdu neshodneme. Autor článku je ztělesněním fenoménu Software in decline. Píšeme nefunkční sračky a nevadí nám to. Kvalita většiny softwareu je naprosto otřesná. A pak přijde tenhle týpek, který brání jazyk, ve kterém nejde psát bezpečný software at scale (a to říkám jako velký C++ fanboi) slovy "že to crashuje nikomu nevadí". Mezitím Microsoft řeší, že 70 % všech CVE plynou z memory unsafety C++, konrétně use-after-free, kde utápí miliony a miliony dolarů. Ani ne běžné crashe, ale reálné exploitovatelné problémy. Fakt mi přijdou takovéhle hlody jako že bezpečnost softwareu se přeceňuje jako dokonale absurdní. Jestli něco, tak přesně obráceně. Mě otravuje restartovat myčku kvůli memory bugu jednou za měsíc, natož odmávnout to, že Boeing zabil shitózním softwarem 737 MAX 346 lidí, protože k tomu přistoupili přesně takhle. Nemluvě o takových věcech jako neřešit různé bugy jako třeba 70 % všech CVE snižuje celkové náklady na údržbu a tak.


    Po letech zkušeností s Rustem jsem schopen porovnat C++ a Rust a k C++ bych se už nevracel ani za nic. Je to fakt všechno špatně a argumenty jako výše jsou buď zcestné nebo nesmyslné a je snaha si obhájit, proč v tom dál ještě pokračuju. A to jsem C++ skutečně měl hodně rád, ale taky jsem s ním měl hodně problémů. A ty my všechny Rust vyřešil.
    SPIKE411
    SPIKE411 --- ---
    Why I think C++ is still a desirable coding platform compared to Rust
    https://lucisqr.substack.com/p/why-i-think-c-is-still-a-very-attractive
    SPIKE411
    SPIKE411 --- ---
    Why Enums in Rust feel so much better
    https://www.shuttle.rs/blog/2023/11/23/enums-in-rust
    SPIKE411
    SPIKE411 --- ---
    Pár příspěvků od Graydona Hoara, tvůrce Rustu, který před 10 lety z projektu odešel.

    graydon2 | Batten Down Fix Later
    https://graydon2.dreamwidth.org/307105.html

    graydon2 | The Rust I Wanted Had No Future
    https://graydon2.dreamwidth.org/307291.html

    Reddit - Dive into anything
    https://www.reddit.com/r/rust/comments/7qels2/comment/dsqeh1d/
    SPIKE411
    SPIKE411 --- ---
    Certifikovaný překladač pro jazyk Rust je tady - Root.cz
    https://www.root.cz/zpravicky/certifikovany-prekladac-pro-jazyk-rust-je-tady/

    Firma Ferrous Systems zveřejnila svoji verzi překladače jazyka Rust, nazvanou Ferrocene. Jedná se o překladač s certifikacemi ASIL-D a SIL-4, které umožňují jeho používání mimo jiné v automobilovém průmyslu a dalších aplikacích, kde se vyžadují tyto certifikace.

    Open Sourcing Ferrocene - Ferrous Systems
    https://ferrous-systems.com/blog/ferrocene-open-source/

    V blogu asi víc zajímavých článků.
    RESURRECTION
    RESURRECTION --- ---
    SPIKE411: Hezká variace na téma "problém X je složitý a Rust mě ho nutí explicitně řešit". Všechny funkce jsou dvoubarevné, protože mít všechny funkcnce asynchronní je zbytečně drahé. Ale zase je to pohodlné, jak v tom zmiňovaném Go, kde se Google rozhodl ten problém vyřešit jedním konkrétním způsobem (channels) a tím ten problém "skrýt". Je to pohodlné, ale cena za to je garbage collector a nemožnost to udělat jinak. Trochu jako se Rust rozhodl řešit problémy s pamětí Borrow Checkerem a neumožnuje tak všechno to, co třeba C++. Podle mě je dobře, že to Rust dělá explicitně (jako všechno) a nutí programátora vidět složitost věci a nějak se k tomu postavit. Možná můžeme mít nápady jak vylepšit syntax (nicméně už post `.await`je lepší než pre), ale primární je, jak zmiňuje ten blog post:

    "Develop a deep understanding of how these abstractions actually work"

    Protože zkušenost je taková, že psát dobře asynchronní kód je extrémně složité a hluboce znát co to dělá je jediný způsob jak to zlvádnout. Zkopírovat odněkud příklad z Go nebo všude nahodit Arc aby se to zkompilovalo je asi možné, ale při prvním problému a potřebě debugovat do toho člověk bude zírat a nebude tušit, která bije.
    SPIKE411
    SPIKE411 --- ---
    Async Rust Is A Bad Language
    https://bitbashing.io/async-rust.html
    LUDWIG_
    LUDWIG_ --- ---
    RUDOLF: na konkretni verzi to jde fixnout takhle:
    [dependencies]
    bevy = { version = "= 0.11.0", features = ["dynamic_linking"]}
    RUDOLF
    RUDOLF --- ---
    hele, taková drobnost.. která mi vyhovuje, ale které nerozumím a zmátla mě. V cargo.toml nastavuji verzi, ale když je minor fix, tak se dependence automaticky upgraduje, např. na 0.11.2. Jak se tohle kontroluje? To ovlivňuje autor dependence nebo je to vlastnost cargo?

    [dependencies]
    bevy = { version = "0.11.0", features = ["dynamic_linking"]}
    LOG53
    LOG53 --- ---
    RUDOLF: Moc dík za shrnutí -- netušil jsem ani to, že Bevy nemá (ještě?) ani UI a základní sprite/tile editor, to je pro mě asi nejbolavější aspekt. Vlastně ne, nejbolavější aspekt bylo slovo "prgat", z toho mě budou bolet oči ještě dlouho (pardon za takový nůž do zad za snahu pomoci) :P
    LUDWIG_: Díky za tip, mkrnu. Pro můj účel "hravého začátku s Rustem" by to mohlo fungovat.
    UNTOY: Zajímavý kontext, dík.
    LUDWIG_
    LUDWIG_ --- ---
    UNTOY: souhlas, plus Bevy maji vice sponzoru, at uz financnich (viz soupis patron sponsors na https://bevyengine.org/ ) nebo i pracovnich (myslim, ze Embark maj Bevy jako bokovku, i kdyz ho na vyvoj her zatim nepouzivaji, pokud se nic nezmenilo).
    Proto jsem taky rikal, ze na serioznejsi veci spis Godot + godot-rust. Fyrox (stejne jako Bevy) mozna na experimenty, game jamy atp.
    UNTOY
    UNTOY --- ---
    LUDWIG_: Fyrox vypada super, ale ma jeden velky problem - je to one man show. Staci se podivat na commity na githubu. Borec to dela vicemene na fulltime, ale vyjadroval se v tom duchu ze bez vetsich sponsoru je to dlouhodobe neudrzitelny a (pro nej) bohuzel Bevy k sobe pritahuje vetsi pozornost uzivatelu/vyvojaru/sponsoru.
    LUDWIG_
    LUDWIG_ --- ---
    LOG53: jeste existuje
    Fyrox - A feature-rich game engine built in Rust
    https://fyrox.rs/

    ktery ma narozdil od Bevy editor. Nemam velke zkusenosti s Bevy ci Fyrox, ale prisly mi dost pozadu oproti Unity ci UE.
    Na nejake experimenty ci neherni veci (v pripade Bevy) mozna ok. Na vic seriozni herni vyvoj, pokud by clovek trval na Rustu, tak je asi v soucasne dobe nejlepsi kombo Godot + https://godot-rust.github.io/
    (clovek muze samozrejme integrovat Rust v Unity ci UE https://github.com/MaikKlein/unreal-rust ale jeste to neni tak pouzitelne. Ohledne Godotu s Rustem jsem slysel minimalne o jedne indie hre, co byla takhle vyvijena.)
    Kliknutím sem můžete změnit nastavení reklam