Názory k článku
Google přepisuje do Rustu části linuxového jádra důležité pro Android

Tohle je extrémně zajímavé: «Rust has many different pointer types that it uses to encode ownership semantics into the type system, and this is probably one of the most important aspects of how it helps in Binder.»

Jo prepsat to nechaj AI...

Kdo nedokaze napsat bezpecny kod v C, by opravdu nemel programovat.

(a je to v analogii stejny, jako kdyz chci od ridicu, aby respekovali pravidla silnicniho provozu)

Roztomilá představa světa dokonalých bytostí, kde nejsou zapotřebí žádné bezpečnostní pomůcky, neboť nikdo nedělá chyby a nic se tak nemůže stát. Ale realita je taková, že zjevně ani nejbohatší firmy typu Google nemají těch dokonalých dost.

Bezpečnostní pomůcky, jako připnutelná kolečka po straně kola? Jinak ten Google si na tohle udělal vlastní jazyk(y) (např. Go). 10x jednodušší než Rust a dělá to samý (pro jejich potřeby).

Kdyby Go dělalo totéž co Rust, nepoužíval by Google i Rust. To je přece elementární logika.

Zbytek nekomentuju, škoda slov.

Google není jeden člověk/tým. Já hodnotil to, že většina zvolila spíš Go než Rust.

Ono stačí když projekt přeroste a dělá na něm desítky lidí. A můžou být dobří jak chtějí ale prostě čas od času jim něco uteče.
Tyhle prohlášení mají lidé, co sami moc dobří programátoři nejsou a nikdy na žádném větším projektu nedělali.

To je spis problem projektoveho rizeni, ze se rekne "dost" a nikdo neni alokovan na opravy, dokud to opravdu nehori.

Neni to otazkou velikosti projektu, ale pristupu.

A další perla, pojďme to hodit na projektové řízení. Nebylo by lepší, kdyby se těm chybám předcházelo a ne řešit až na ně někdo přijde? Navíc tohle už řeší jenom následky, když už tam ty chyby jsou.
Jak tohle zajistíte třeba v Blink, Linux atp.? Tohle prostě není vůbec možné, od určité velikosti se tam ty chyby prostě udělají ať na tom bude dělat kolik chce geniálních programátorů.

Navíc RDa vůbec neřeší, jak se na tu chybu přijde. Prostě nějak magicky už ví, jaká chyba tam je a jenom stačí ji opravit. A zrovna chyby ve vícevláknovém zpracování se hledají docela těžko.

Což, pokud to má být opravdu garantovaně memory a thread safe, zahrnuje i neustálý kompletní audit všech závislostí při každém update a neustálý audit veškerého dosavadního kódu aplikace, jestli je safe i v novém kontextu.

Reálně se ten tvůj post dá přeložit jako "nikdo by neměl programovat", protože ne, tohle u čehokoliv většího dělat nejde.

4. 11. 2023, 09:57 editováno autorem komentáře

Ono by stacilo kdyby existovala nejaka specifikace - ceho chteji autori dosahnout. Bohuzel casto vidim hromadu kodu, ktera neco dela, a pak neustaly stream patchu, proc to nedelat tak jak se to delalo.. to aby se v tom prase vyznalo ze.

Motáš se v kruhu. To Tvoje "ono by stačilo" se moc dobře nedá škálovat až do nejnižších levelů a zvlášť ne, když jazyk je takový lepší assembler. A při každé změně či opravě by se to muselo znovu a znovu updatovat, což prakticky není v lidských silách. Natož aby to někdo byl ochotný a schopný ověřovat (myslím manažera, ne kodéra).

A nejlépe i s popisem, co jak pracuje s pamětí. A pak ještě kontrolovat, že to stále odpovídá. Nemáme na to nějaký nástroj?

Doufám, že vy tedy neprogramujete.

Proč zrovna C? Co třeba: „Kdo nedokáže napsat bezpečný kód ve strojovém kódu, opravdu by neměl programovat.“

Ano, je to analogie jako s řízením dopravních prostředků, nejen aut, ale i vlaků, letadel, lodí. Tam se také snažíme eliminovat případy, u kterých se notoricky ukazuje, že lidem nejdou. Proto máme na silnicích semafory, v autech ABS a parkovací automaty, na železnici traťové a vlakové (teda to my nemáme, ale to je jiná písnička) zabezpečovací zařízení. Proto jsou ve velkých letadlech dva piloti, proto je na věži letový dispečer, proto mají letadla spoustu přístrojů a dá se létat i jen podle přístrojů.

Programovat by neměl ten, kdo odmítá používat nástroje, které umožňují psát lepší a bezpečnější kód nebo které umožňují programovat efektivněji.

Kdo napise prasacky kod v C, tomu nepomuze sebelepsi nastroj. Protoze dane individuum je zrejme absolutni nesika a nema zadne vlohy k programovani - a chapani souvislosti, jak to v pocitaci vlastne funguje.

Pro tyhle "opice" existuje javascript, html a electron.. protoze potrebuji neustale zachranovat pred strilenim se do vlastni nohy.

Ne - lepsi nastroje opravdu nejsou resenim problemu, ktery je jinde.

Prasácký a nebezpečný kód jsou ortogonální věci.

Lepší nástroje umožňují s omezenými lidskými schopnostmi řešit věci, které by jinak byly mimo lidské možnosti. A nebo umožňují řešit věci snáze. Vykopat jámu pro dvoupatrové garáže můžete i lopatou, ale udělat to bagrem bude daleko efektivnější. A když jsou mraky až nad zem, pilot svýma očima skrz ně nevidí a nemohl by přistát. Ale použití nástrojů mu umožní vidět skrz mraky a přistát.

Super. A teď chci vidět toho dokonalého C/C++ programátora který dovede udržet v hlavě celý paměťový model své aplikace a všech knihoven co používá.

Sorry. Kód od C++ programátora co ví že se v tom psát bezpečně nedá respektuju. Kód někoho kdo sebejistě tvrdí že to jde dělat bezchybně... Nope. Někdo kdo je takhle delusional tam naseká chyb mnohem víc, protože reálně, neví o čem mluví.

Kdo napíše prasácky strojový kód, tomu nepomůže sebelepší nástroj ani C

[RDa]

Myslim, ze jeste porad hodne z tech lidi, kteri maji vytky proti C/C++ napsat bezpecny kod C/C++ dovedou. Ale presto nechteji. Z nejruznejsich duvodu. Prijde jim to neohrabane, zdlouhave, najivne veri tomu, ze stroj muze jejich (nebo druhych) opominuti ve vsech situacich odchytit, napravit, a nebo dokonce nahradit lidsky intelekt a dumysl na nizsich urovnich. Nebo proste jen, proto ze v dnesni uspechane dobe tlaci terminy a oni nechteji drahoceny cas venovat na hlidani si inicializaci/a­lokace/dealoka­ce pameti (a pod). Dovedu to pochopit.

Co ale nedovedu pochopit, je, ze jsme ochotni dopustit, aby se to zmenilo v nastroje prachsproste lenosti a zhnilosti pohnout mozkovymi zavity a zpohodlnele lidstvo vrsi na sebe ne sebe velmi slozite binarni kosticky o nich jednak mnohdy dnes ani nevi jak funguji, jednak je jim to uplne jedno, stejne tak jaky to ma v globalu dopad na uzivatele a jejich systemy jako celek (za vsechno se plati). Hlavne ze mam produkt, rychle, levne a pokud mozno s minimem namahy. Stavime nase pohodli na vrchol piramidy nad znalosti a lidskou praci a zlenivelost se stava normou. Myslim, ze vseak realne hrozi, ze se ty vyse zminovane kosticky na nas jednou plnou vahou zhrouti a hodne lidi bude nestastnych. Asi bude pozde premyslet jak to napravit a litovat, ze jsme to nechali zajit tak daleko...

Ja s tebou do urcite miry souhlasim a pokud splnuji to co jsi psal, chapu i nektere argumenty druhe strany. Jen posledni dobou se desim toho jak moc se naduzivaji... ne zneuzivaji technologie i tam kde jich neni vubec potreba a staci se jen na chvili zastavit a trochu zmyslet....

Da se to rict i jednoduseji - cca pred rokem jsem potkal jedno ze svych Linuxovych guruu. Dali jsme si kafe a ja mu polozil celkem osobni otazku "Proc ty se svym talentem a vzdelanim uz nedelas v IT, vzdyt...?". Ani me nenechal domluvit: "S IT to jde do cim dal tim rychleji do p****e a ja se na tom nechci podilet." Mlcel jsem - na to jsem nemel co rict....

5. 11. 2023, 13:16 editováno autorem komentáře

Pro ty co odmitaji akceptovat, ze ne-programatora zachrani lepsi, nekdy az magicke nastroje hodne nekonecne adorace (jako Rust), zde mate priklad (inspirovany realnou situaci, kterou jsem videl u kamarada programatora).

#include <stdio.h>
#include <stdint.h>

void recursion(uint32_t level) {
    if ((level%1000)==0) {
        printf("level = %d\n",level);
    }
    if (level==1000000000) {
        return;
    }
    recursion(level+1);
}


int main( int argc, char* argv[] ) {
    recursion(0);
    return 0;
}

vs:

fn recursion( level: u32 ) {
    if (level%1000) == 0 {
        println!("level = {}",level);
    }
    if level == 1000000000 {
        return;
    }
    recursion(level+1);
}

fn main() {
    recursion(0);
}

A vysledek:

$ gcc recursion.c -o recursion
$ ./recursion
...
level = 260000
level = 261000
Segmentation fault

$ rustc recursion.rs
$ ./recursion
...
level = 103000
level = 104000

thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted

Oba kody se prelozi bez varovani prekladace, oba kody padnou.

Sebelepsi nastroj vas nezachrani, kdyz neumite programovat.

A ten v Rust-u padne drive, protoze pracuje evidentne mene optimalne se zasobnikem pri volani funkci. Nerikal nekdo ze Rust je lepsi? Aha.. tak asi ne jako.

Velikost vysledne binarky bych radeji nekomentoval - ale 14.7K vs 4225K taky nelze prehlidnout (ale o tom tento priklad neni).

Argumentační klamy Ti (ne)jdou. Rust je jistě v něčem lepší, stejně jako je v něčem lepší bagr než kávová lžička. Pokud ale kopeš jámu na špatném místě, tak je určitě lepší ta lžička.

Pro ty co odmitaji akceptovat, ze ne-programatora zachrani lepsi, nekdy az magicke nastroje hodne nekonecne adorace
Slovo „zachrání“ jste tu použil jediný vy, nikdo jiný. Slovo „magické“ jste použil vy, nikdo jiný. Nekonečnou adoraci tu také nikdo nepředvádí.

Oba kody se prelozi bez varovani prekladace, oba kody padnou.
Oba překladače nikdy netvrdily, že dokážou zabránit problémům tohoto typu.

Sebelepsi nastroj vas nezachrani, kdyz neumite programovat.
Polemizujete s něčím, co nikdo netvrdil.

Nerikal nekdo ze Rust je lepsi? Aha.. tak asi ne jako.
Nikdo neříkal, že je ve všem lepší.

Velikost vysledne binarky bych radeji nekomentoval
Možná byste se měl podívat do kalendáře, jaký je rok. 4 MB binárky na PC fakt není něco, co by někoho trápilo.

To že pracuje méně optimálně jste myslel jak?

Viz pocet cyklu pred padem.

Predpokladam ze zasobnik je stejne veliky by default a ani jeden program bez meho svoleni nesaha na zmenu ulimit.

Lisit se to muze samozrejme zaplnenosti tim, co se tam nahaze pred spustenim main().

Pak uz jenom nastava rekurzivni volani a na zasobnik se ukladaji (nekdy) argumenty a navratova adresa. Mozna tam Rust uklada i neco dalsiho, o cem nevime ze potrebujeme/chceme ale je to tam?

Jaky je tedy calling convention v rustu? (obecne neni definovany, a zde byla platforma 32bit x86 linux)

EDIT: na druhe pomysleni me napada ze je mozna situace, ze GCC ten argument prenasi v registru, a RUSTC ho uklada vzdy na zasobnik?

4. 11. 2023, 17:48 editováno autorem komentáře

Fascinující, stack overflow dovede potkat jakýkoliv jazyk co pracuje se stackem. Jen to vede k pádu aplikace, ne ke spuštění arbitrary kódu, nebo exfiltraci dat z paměti. A prostě ignorujme x chyb kterým jazyk předejde, tady je jedna kterou nevyřeší :)

Velikost binárky je dost stupidní argument btw. Ok, možná se věc velikosti "hello world" liší, ale chce to spíš porovnat reálnou aplikaci co něco dělá, velikost runtime hned ztratí význam proti zbytku kódu.

Jaky runtime probuh??
Nemel by vystup rustc byt nativni strojovy kod, je to prece kompilovany jazyk!

Aby si clovek vytracoval instrukce a cestu kterou to provede skrze ty megabajty.. rekl bych ze se z toho neprovede o moc vice, nez u bezneho C hello world. Proste neni zadny duvod tam poustet neco dalsiho a je to jen neoptimalni balast.

ono i to cecko do toho Hello world dava nesmysly. Nejaky puts je jedno volani jadra, exit/return je druhe volani jadra. Dohromady je to na par bajtu, trosku to naroste kvuli strukture binarky (uz ne a.out ale vetsi ELF), ale porad to jsou max. kilobajty. Ale ceckovej runtime do toho dava veci okolo libc, startup kod atd. A Rust - to je trosku zahada, co tam vsechno je (musi byt?).

V zásadě to samé, samozřejmě to jde celé zahodit při no_std vývoji, kdy se zahodí std a dá se použít jen core library.

Úplně stejný jako má třeba C++ https://stackoverflow.com/a/1824550
https://www.quora.com/What-is-the-C++-runtime-system-and-how-does-it-work?top_ans=20541236

Hele, fakt by to chtělo nejdřív znát základy a pak kritizovat jazyky :)

C++ prekladac mi nijak moc balastu neprida - pouhe 4B:

$ g++ recursion.c -o cpp
$ gcc recursion.c -o c

$ du -b c*
14704   c
14708   cpp

Takze sory, kecy ze nejaky runtime z C++ ma vliv na to neberu.
Funguje to presne jak ocekavam.