Názory k článku Práce s poli v programovacím jazyku Rust

Třeba se pletu, ale nemělo by se pole procházet v rozsahu 0..délka -1 ?


for i in 0..array.len() - 1 {
println!("item #{} = {}", i+1, array[i]);
}


Rozumím, fakt je, že si čtu seriál hlavně ze zvědavosti a textem dost kloužu, takže pak vygeneruju blbou otázku, no nic, budiž mi to poučením pro příště...

Ve vetsine programovacich jazyku se pouzivaji spis polootevrene intervaly, protoze se s nima lepe pracuje (viz tento priklad), a predejde se tak mj. i fencepost problemu. Priklad s Pythonim range() ktery generuje take polootevrene intervaly:


len(range(m)) == m
len(range(a, b)) == b - a
range(a, a) == []
range(a, b) + range(b, c) == range(a, c)


a treba si precitat i toto
http://nomad.so/2015/03/why-gos-design-is-a-disservice-to-intelligent-programmers/

to je trosku prehnane ne?

tady ten borec v diskusi to mozna trefil: "Go is becoming a success. And I think ultimately, you *hate* that. You want it to fail. Its very existence is an affront to everything you hold dear. If Go were to become a success, it would somehow invalidate all your past successes and efforts."

to asi nekdy citime vsichni, kdyz si jen uvedomim, kolik "effortu" jsem v poslednich 15 letech ztratil technologiemi, ktere se proste neprosadily nebo rovnou umrely... (a to se snazim vyhybat frontendu, tam se to meni snad kazdej pulrok :)

Trošku odlehčeně napsáno, berte hodně s nadsázkou: http://tmikov.blogspot.cz/2015/02/you-dont-like-googles-go-because-you.html

http://www.infoworld.com/article/2947214/open-source-tools/two-reasons-the-rust-language-will-succeed.html

Ten clanek mi prijde takovy pochybny (napriklad odkazovani na 3 roky starou a vyresenou issue).

Jako pokus o objektivnejsi srovnani Go vs Rust mi prije toto:

https://medium.com/@robertgrosse/my-experience-rewriting-enjarify-in-rust-723089b406ad#.uukigyil8

https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf

Já bych s tím, že populární značka prosazuje - nesouhlasil. Ani to nemá oporu v tom, které programovací jazyky se prosadily v průměru za poslední desetiletí.

Prosadit programovací jazyk je extrémně těžká věc - chce to jednak jazyk implementačně dotáhnout do prakticky použitelného stavu, dále dlouhodobá podpora. Zároveň rozumně navržený jazyk a popis standardu. To je náročná práce na 10 let a více - a podle historie to většina "známých značek" vzdá dříve, protože jejich motivace není obětovat se pro prosazení jazyka. Navíc firmy mají většinou jiné cíle, než dopilovat jazyk.

Google i Mozilla navíc jsou extrémně krátkodobé v podpoře čehokoli. Obě rázně a bez milosti neustále řadu projektů ukončují, často i populárních, a proti vůli uživatelů.

Klidně si tipnu, že Go a Rust budou patřit do těch technologií, o kterých se nyní mluví, že převálcují svět a budou tu na věky věků, ale za pár let po nich pes ani neštěkne, a většina IT si ani nebude vzpomínat, co to vlastně bylo - a budou tipovat, že Go a Rust byla značka žvýkačky, limonády nebo něco podobného.

Schválně se uložte tento můj komentář a přečtěte si ho za dva roky. Uvidíte, jak směšný bude v roce 2019 názor "Ten borec to možná trefil: Go is becoming a success. And I think ultimately, you *hate* that."

Každý rok slyšíte o mnoho technologiích, které převálcují svět, a po 99 % z nich za rok dva ani pes neštěkne. Go ani Rust nemají ani 1% šanci, že budou úspěšnými - a budou něčím jiným než krátkodobým štěkem. Zabijí je samy autorské právnické osoby, které je stvořily.

Popravde mam pocit, ze pouziti poli bude asi dost omezene, mozna to tak vyzaduje prekladac, aby vzdycke presne znal delku. Jestli to chapu dobre z tutorialu, tak vektory (vec!) jsou alokovany na heapu a jsou menitelne (pridani prvku napriklad). U poli by me asi vadila ta divna inicializace pres unsafe - to nejde nejak obejit (potom by to bylo ok)?

neni nekde prehledne porovnani array s vec?

V Rustu je podmínka pro alokování na stacku že datový typ musí mít známou velikost, array tohle splňuje. Alokovat na heapu se dá pomocí Boxu ( Box::new([0; 10])), takže alokace na stacku není podmínkou. Data vektoru jsou vždy na heapu.

Vec má dynamickou velikost, array fixní. Kde se krásně setkávají jsou právě ty řezy (slice): řez na Vec je stejný typ jako řez na array.

fn increment_all(slice: &mut [i32]) {
    for i in slice.iter_mut() {
        *i += 1;
    }
}

fn main() {
    let mut array = [0, 1, 2, 3];
    let mut vec: Vec<_> = (0..4).collect();
    increment_all(&mut array);
    increment_all(&mut vec);
    println!("{:?}", array);  // [1, 2, 3, 4]
    println!("{:?}", vec);  // [1, 2, 3, 4]
} 

Ohledně toho unsafe, Rust považuje neinicializovanou paměť za unsafe a nedá se vytvořit array s neinicializovanými prvky bez unsafe bloku.

Když si například napíšu:


fn main() {
let mut a = [1,2,3,4,5,6];
let mut b = &a[3..4];
b[1] = 10;
}


tak kompilátor zařve, že cannot assign to immutable indexed content `b[..]`
Není to moc jasné - a je mutable, b je (asi) mutable reference na slice, tak proč nemůžu přes b změnit prvek v a? Podle https://www.root.cz/clanky/prace-s-poli-v-programovacim-jazyku-rust/#k06 je slice stejně jen ukazatel + délka a v céčku něco podobného udělat jde prakticky stejně (kromě délky).

Problém je v tom, co je vlastně na let mut b = &a[..] mutabilní. b je zde mutabilní proměnná držící typ &[i32], tedy nemutabilní referenci na řez polem. Takže b můžeme přiřadit jakoukoliv jinou hodnotu typu &[i32], ale nemáme mutabilní přístup k hodnotám pole.

let mut b = &a[2..6];
println!("{:?}", b);  // [2, 3, 4, 5]
b = &b[1..];
println!("{:?}", b);  // [3, 4, 5]; 

Naproti tomu let b = &mut a[2..6] nabízí řez polem s mutabilním přístupem, ale samotné proměnné b nelze přiřadit jinou hodnotu typu &mut [i32].

let mut a = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9];
{
    let b = &mut a[2..6];
    b[2] = 0;
    println!("{:?}", b);  // [2, 3, 0, 5]
}
println!("{:?}", a);  // [0, 1, 2, 3, 0, 5, 6, 7, 8, 9] 

Taky díky, teď to chápu, snad to zase nezapomenu (to stejné je u struct-ů že?).

To b je sice mutable, ale obsahuje immutable referenci. Mělo by to být:
let mut b = &mut a[3..4];

aha, takže let mut b ... znamená jen to, že do toho b můžu později přiřadit jiný slice, vůbec to nesouvisí s tím, co přiřazuji?

Jinak díky, takto to valí (v předchozím příkladu byla chyba a[3..4] vrací jednoprvkový slice, takže žádné b[1] neexistuje, sorry)


fn main() {
let mut a = [1,2,3,4,5,6];
let mut b = &mut a[3..5];
b[1] = 10;
for i in b.iter() {
println!("{}", i);
}
}

[psal jsem uz rano, ale prispevek asi nekde ceka na schvaleni :) takze zkusim znovu]

Jaka je vlastne vyhoda poli (array) oproti vektorum? Ja zatim vidim jen lepsi kontrolu prekladace a mozna to, ze se pole mohou alokovat na zasobniku a ne na heapu. Ale treba uz udelani pole s ruzne dlouhymi radky asi jednoduse nejde ne? neni tedy lepsi vzdycky pouzit vektory (tam predpokladam stejne rychly pristup, tj. index*sizeof prvek nebo neco podobne efektivniho, zadne prochazeni seznamem). Me vlastne u poli zarazil kod s unsafe, to vypada dost hnusne popravde receno :)

Pokud to dobre chapu, tak pole ani nejde porovnavat, protoze Eq trait (a dalsi) plati jen pro velikost max. 32 prvku.