Vlákno názorů k článku
Další síťová karta bude mít jaderný ovladač v Rustu od Calculon - Na Ruste je nieco hnile. Nie je mozne, aby...

Na Ruste je nieco hnile.
Nie je mozne, aby (re)kompilacia samotneho prostredia vyzadovala 20GB disk space a take kvanta CPU.
Low level ovladace ? Preco preboha.

Ale samozřejmě, že to je možné. Když může hloupá malá webová stránka stahovat gigabyte javascriptových zdrojáků.

V Rustu ty inference a borrow checker nejsou zadarmo, za ty kontroly se platí strojovým časem při překladu. Existoval i hodně přísný překladač Cčka a překvapivě byl mnohem pomalejší než gcc.

Strojový kód se nemusí překládat vůbec. ASM jen malinko. Cčko už něco potřebuje, C++ se šablonami a STL trvá a Rust je ohledně kontrol ještě přísnější.

Každá úroveň abstrakce a kontrol ten překlad zesložiťuje.

Pamatuju Java server s GWT, nestačilo tomu pro překlad 10 GB RAM a úplně to vytížilo desktopový Xeon (nějaký Dell desktop z doby před 10 lety).

Já v Rustu napsal komplet run-to-completion runtime a radiový stack pro embedded mikrokontroler. Maličké STM32 se 32K FLASH a 8K RAM. A to samé i v C++ (bez výjimek). Ten Rust byl nakonec hezčí a lépe udržovatelný, ale možná spíš proto, že C++ dovolilo některé "nebezpečné" operace a pro Rust jsem musel mnohem víc dbát na správné interní členění a správnou abstrakci nad unsafe bloky.

V Rustu ty inference a borrow checker nejsou zadarmo, za ty kontroly se platí strojovým časem při překladu.

Podobné typy jako má Rust zvládl kompilátor jazyka ATS (Applied Type System), překládat rychleji. A i výsledný kód byl rychlejší (protože na rozdíl od Rustu nebylo třeba nic kontrolovat za běhu - např. indexy do pole).

To by mě zajímalo, jak se řeší indexy do pole, když je to pole plněné dynamicky a indexy mohou být vzaty v podstatě odkudkoli. Jazyk, kde není třeba nic kontrolovat za běhu, je dost nepraktický, ne? Jinak vždy, když vidím nějaký podobný akademický superjazyk, který dává na zadek nějakému jazyku z praxe, říkám si, proč tedy všichni nepoužíváme ten superjazyk.

To by mě zajímalo, jak se řeší indexy do pole, když je to pole plněné dynamicky a indexy mohou být vzaty v podstatě odkudkoli.

Funkce jsou schopny přijmout "důkazy" (vhodné typy). Například funkce pro indexování pole

fun{a:t@ype}
indexuj_pole
  {n:int}{i:nat | i < n} (A: arrayref(a, n), i: size_t i): (a)

má dva normální parametry v kulatých závorkách A (pole s prvky typu a o délce n) a i (index do pole, který má hodnotu typového parametru i).
Pak ale potřebuje dva typové parametry. První typový parametr n s velikostí pole. Druhý i s velikostí indexu a omezením jeho velikosti.

Konkrétní hodnoty n a i nemusí být známy v době kompilace. V době kompilace se jen ověří, že to jsou čísla, a že i má požadovaný rozsah.

Jinak vždy, když vidím nějaký podobný akademický superjazyk, který dává na zadek nějakému jazyku z praxe, říkám si, proč tedy všichni nepoužíváme ten superjazyk.

To je dobrá otázka. V tomhle by asi také šlo psát jádro.

Osobně si myslím, že je to jazyk z rodiny Standard ML, která není moc oblíbená. Ale nevím proč.

Děkuji za tip na zajímavý jazyk.

Každopádně nepřijde mi to moc k tématu. Rust je jazyk, kterému se podařilo etablovat na konkrétní niku. Dělá věci výrazně líp než starousedlíci (C, C++). Přináší výrazně pohodlnější a modernější koncepty než aktuální mainstraim (C#, Java). A hlavně funguje!

Nikdo ale netvrdil, že je to topka (Haskell, Idris). Ve skutečnosti fakt, že to není jen lepší jak C, ale dokonce o tolik lepší, přináší určité lidské potíže.

> Přináší výrazně pohodlnější a modernější koncepty než aktuální mainstraim (C#, Java).

S tymto absolutne nesuhlasim. Ja som Rust opustil v prospech C# prave pre to, ze C# je vyrazne pohodlnejsi, je velmi moderny a vykonostne je to skoro to iste ako Rust.