Názory k článku Programovací jazyk Rust: použití FFI pro volání funkcí z nativních knihoven (2. část)
-
xxxxx (neregistrovaný)
S dovolením mírněji offtopic. Jak je to s Rust a signály/Exception Handling (myslím ty low-level windows try-except, nikoli strukturované C++). Je na ně rust nějak zařízen (obdobně jako třeba Visual C try-except) nebo si člověk musí dodělat handlery ručně?
Pokud o tom článek ještě bude, tak zbytečné se rozepisovat teď. Či pokud mi to v rámci seriálu uniklo, tak se omlouvám, nemohu dohledat.
P.S.: Přidával jsem se k pochvale (a že je užitečné), ale si jsem nějak špatně odeslal, že nevidět, tak jen pro jistotu znovu děkuji.
-
dizzy (neregistrovaný)
pokial by som mohol dat nejaku inspiraciu k dalsiemu pokracovaniu serialu - videl som nejaky pokus portovat Rust na microcontroler (konkretne AVR/Arduino). Chlapik to popisoval v nejakom blogu a dostal sa az tak daleko, ze rozbehal nejaky trivialny kod v Rust-e na Arduine a skoncil na tom, ze nemal/musel by portovat core lib (zakladne funkcie Rust-u) pre AVR, co by zrejme nebola uplne trivialna uloha.
Zaujimal by ma nazor autora - je Rust vobec vhodny na taketo nasadenie? Lebo o Rust-e sa prave hovori ako o moznej nahrade C/C++ a mat takto silny jazyk na jednoduchom microcontrolleri by bol docela masaker... -
Pavel TišnovskýZlatý podporovatelTo by mě také docela zajímalo :-) Oficiálně je podporován (až v tier 3) 16bitový procesor MSP-430, který je ovšem docela výkonný (a trošku také inspirovaný klasickými RISCy - https://www.root.cz/clanky/sestnactibitove-mikroradice-ti-rady-msp430/).
Co bych viděl jako potenciální problém je velikost zásobníku na některých architekturách, protože Rust implicitně vše ukládá na zásobník, pokud se nepoužije Box atd.
Jinak jako backend je použito LLVM a generovaný kód se od céčka příliš neliší.
Možným dalším problémem je velikost binárek, do kterých je staticky slinkována standardní knihovna, takže na x86-64 dostaneme nějakých skoro 700 kB kódu. Jde to snížit dynamickým linkováním rustc -C prefer-dynamic na cca 8 kB, ale to si nepomůžeme, protože ta knihovna tam stejně bude muset být. Takže na menších čipech dřív či později dojde k odstraňování některých částí std. knihovny, což je problém, protože to není nijak standardizováno (to je škoda). Mě by se asi líbilo mít std. knihovnu úplně maličkou a všechno další řešit přes "crates" (moduly Carga).
-
Pavel TišnovskýZlatý podporovatel
Vlastně jsem neodpověděl na otázku :-) Takže pro Rust v dnešním stavu si myslím, že pro menší MCU (ATMega atd.) to _zatím_ není vhodná volba, ale na druhou stranu plně 32bitové Cortexy-M se dávají skoro všude (Arduino M0...) a tam to smysl má.
-
dizzy (neregistrovaný)
...ono popravde je treba si asi uvedomit, ze uz aj C++ je na AVR platforme dost na hrane a tiez sa to riesi tak, ze sa orezava libstdc++, pripadne sa tam nedava vobec a vyuziva sa len samotny jazyk (prip. si nejake primitivne triedy pre string alebo ring buffer nabastli kazdy podla potreby), takze netreba mat asi prehnane ocakavania :-(
Existuje dokonca projekt na gitlabe (https://github.com/avr-rust) ktory je prekvapivo zivy. Ale skor si myslim, ze casom nastupia nove mikroconrollery za rozumne ceny, na ktorych uz nebude treba riesit kazdy kilobyte kodu.
Kazdopadne dakujem za odpoved a tesim sa na dalsi diel serialu :-) -
Co se týče UTF-8, tak pozor na pojem znak. Pokud chcete něco vypsat na obrazovku a zalámat to na znaky, tak musíte podporovat i znaky složené z více codepointů. Rozdělit slovo mezi písmenem a háčkem nad písmenem (pokud je zapsáno každé svým codepointem) by bylo rozhodně špatně, a striktní validátory by si mohly stěžovat na neplatnou kombinaci codepointů (háček nad koncem řádku?). Dalším, stále více rozmáhajícím "nešvarem" jsou emoji. Například "" jsou dva codepointy: a , a většina uživatelů má dnes webové prohlížeče, které to podporují. Na mobilních telefonech mají dokonce často emoji nějak přístupné tak, že vám to fláknou do webového formuláře ani nevíte jak.
https://stackoverflow.com/documentation/unicode/6485/characters-can-consist-of-multiple-code-points
https://stackoverflow.com/questions/6579844/how-does-zalgo-text-workP.S. Další špek je při převodu z JSONu. JSON totiž ve formě \uXXXX používá UTF-16 zápis, takže nelze pouze pomocí UTF-8 zakódovat to 16bitové číslo, protože to může být jen půlka codepointu. Takový postgresql si pak pěkně stěžuje, když do něj někdo cpe takto špatně zakódované emoji.
-
atarist (neregistrovaný)
UTF-16 je to nejhorší z obou světů - nemá ani konstantní šířku jako UCS a ani není zpětně kompatibilní s ASCII jako UTF-8. Navíc trpí větším problémem - dost lidí si myslí, že UTF-16 reprezentuje znaky dvěma bajty (tedy jako UCS-2) a vůbec neřeší to, že některé znaky jsou reprezentovány větším množstvím bajtů. Takže ono to v 90% případů bude nějak chodit, ale potom se aplikace nasadí někde v Asii a začne to divně haprovat. Jo a BOM je kapitola sama pro sebe :-)
ČLÁNKY DO MAILU