Názory k článku
Prohlížeč Ladybird plánuje přejít z C++ na Rust, práce urychlují AI systémy

I know this will be a controversial move, but I believe it’s the right decision for Ladybird’s future. :^)

Tak i programovací jazyk je dnes kontroverzní.

Rust je známý především jako jazyk rozbitého softwaru, který je často hypován jako 'X napsáno v Rustu' a pak rychle zabudnut spolu s komunitou, která ti bude doslova vyhrožovat násilím, pokud se odvážíš vystoupit z řady a myslet trochu jinak. Skutečnost, že je v poslední době spojován s AI slopem, také nepomáhá

Jo, denně používám Fish, Ruff, RipGrep, atd. a fakt to jsou rozbité a opuštěné věci. Vlastně ne, nežiju v Tvém vesmíru.

Když kouknu co pravidelně používám mimo tebou zmíněné tak ještě Zellij, Niri wm, typst, starship shell, helix. Pak třeba rustdesk, velká část moderního Python toolingu...

A opuštěných OSS nedodělků je spousta v každém jazyce, fakt mi nepřijde že by v tom byl Rust výjimka.

Jasně že není. V OSS světě je strašná spousta nedodělků ve verzi 0.x. A opuštěných projektů, které chodily, ale už se o ně nikdo nestará. Jinak starship mám taky, pak např. fd, bat atd. atp. Niri jsem třeba neznal, takže díky za tip!

25. 2. 2026, 13:56 editováno autorem komentáře

Z výše zmíněného mám zkušenost nejvíce s Ruff a jen okrajově s Helix. Ruff jako formátovač python kódu funguje velmi hezky. S Helix jsem také neměl problém. Jsou to ale všechno nástroje, které jsem si sám vyhledal a nainstaloval a vyhovují mi. Co mi ale obecně na ekosystému Rustu vadí je právě to přesvědčení, že se jedná o jediný správný programovací jazyk a proto bychom měli "všechno" přepsat do něho. A často se argumentuje paměťovou bezpečností jakoby to bylo něco na čem stojí a padá celé odvětví SW vývoje. Tedy ne že by to nebylo důležité ale k čemu vám to bude když aplikace nakonec nebude dělat to co má. Protože paměťová bezpečnost neimplikuje neděravost aplikace. Stačí se podívat jak se v Ubuntu mordují s coreutils.

Takže ano, chyba není ani tak v jazyce jako spíš v lidech co ho tlačí celkem nevybíravě hlava nehlava.

Jistě, a když budu hledat dost dlouho, najdu něco dobrého a udržovaného i ve Visual Basicu. Z každého pravidla jestvuje výjimka.

Tak můžeš začít hledat.

Rozdíl je v tom, že budeš hledat dlouho a pracně, abys skončil s pár výsledky. U Rustu používá dnes kde kdo docela dost programů, většinou aniž by to věděl.

Většina jazyků za své vývojáře opravdu nemůže.

Jistě, ale když vybuduješ komunitu na nenávisti a pocitu vlastní nadřazenosti, automaticky to přitahuje určitý typ lidí. Není náhoda, že projekty napsané v D nemávají svůj původ vrytý ve svých názvech.

Nemyslím si, že by lidé, kteří nenávidí Rust, byli nějaká komunita. To se tak holt lidem stává, že když se objeví něco nového a oni vidí, že by se tím měli zabývat, ale nechce se jim do toho, tak to začnou nenávidět a začnou mít pocit nadřazenosti – že oni jsou ti, kteří to ještě jako poslední dělali dobře, ale ta dnešní zkažená mládež…

Spousta projektů v různých jazycích má svůj původ vrytý ve svém názvu. Třeba u knihoven je to dost podstatné, pro který jazyk je ta knihovna určena. A je to něco, čím se odlišuje od spousty jiných knihoven.

To s tím pocitem vlastní nadřazenosti.

Jsou lidé, kteří nemají problém o sobě prohlásit, že velmi dobře ovládají Postgresql (například). Protože ho opravdu velmi dobře znají, nadělali v něm spoustu projektů během mnoha let.

Jenomže pak jsou lidé, na které takové prohlášení působí strašně namachrovaně a vyvolává to v nich různé, většinou negativní pocity.

Rust je ve stejné situaci. On to není jen další jazyk v řadě. Je to jazyk, který slibuje velmi lákavé záruky. A čím víc se ukazuje, že to nejsou jen sliby, tím víc to na některé lidi působí velmi ...

Tak změna jazyka u nějakého existujícího projektu byla "zajímavá" vždycky. A flamewarů kolem výběru jazyka si taky pamatuju hódně. :)
Takových kontroverzních věcí by se našlo - endiany, mezery/taby, west a east const, ... Nebo třeba editor war?

Zdá se, že Rust bude optimální jazyk pro umělou inteligenci :-)

Jazyk ani ne (i když ta typová a paměťová kontrola hodně pomůže), ale překladač a pomocné nástroje té AI hodně pomáhaji. rustc, rustfmt i clippy totiž často ukazují přímo diff, který opraví nalezenou chybu. A to těm AI agentům fakt usnadňuje psaní kódu.

Obecně celý ekosystém kolem cli Rustu se hodně snaží o "viditelnost" (nevím jak jinak přeložit discoverability). Když se kouknete na helix, zellij a jiné nástroje, tak ukazují uživateli nápovědy a cestu dál při každém stisku něčeho aktivního.

Objevitelnost je blíž, ale hezký překlad to není ;-)

Ono je lepsi neprekladat. Idealne se dohoudnout, ze stejne, jako ma medicina latinu, tak technika anglictinu. Preklady jsou casto uplne silene a matou.

25. 2. 2026, 12:02 editováno autorem komentáře

Spíš jako ma medicina anglictinu, tak technika anglictinu. ;-)

Prečo myslíte, že to nie pekný preklad? Nemôže to byť tým, že už v pôvodnom jazyku je to slovo zvolené nevhodne? Alebo naopak popisuje vhodne to, čo tá vlastnosť systému v skutočnosti znamená v celom spektre použití?

Ono vzdy potesi ak projekt ktory je vo faze ze je v podstate este nepouzitelny a clovek caka na finalny produkt. A programatory sa rozhodnu teraz ho prepisat do ineho jazyka...

No někteří se řídí heslem, že "cesta je cíl". Radši něco pořád dělat(resp. vykazovat činnost) než to dokončit a přesunout se na něco jiného.

Tak lepší se přesunout v půlce "sprintu" do cíle když ví člověk že mu zvolená technologie (jazyk etc.) nebude stačit než vydat verzi 1.0, cutnout to a udělat přepis nad Xkrát větším codebase. Navíc je trochu rozdíl ve kvalitě kódu když člověk ví že to píše stejně aby to hned potom přepsal nebo když věří tomu že to bude finální řešení.

Na druhou stranu, když je jasné že je třeba udělat nějakou změnu, tak je lepší ji neodkládat.

Vzpomeň si, jak vznikla Mozilla. Chtěli předělat Netscape a pak se rozhodli to udělat radši od nuly. Pravda, tenkrát ještě nebyl Rust, ale to by je nezdrželo, spíš naopak.

Ja to teda nesledujem, ale nevznikol rust kvôli tomu, že v ňom chceli napísať prehliadač? Alebo to bolo jadro? Už je to hotové?

Ne, byl to osobní projekt jednoho vývojáře (Graydona Hoarea), který si Mozilla adoptovala pro vývoj nového experimentálního prohlížečového jádra (Servo).

Re: "konstrukce od AI nejsou optimální, jde vlastně o „zrustovatělý C++ kód“, ale funguje to a postupem doby se budou těmito částmi probírat a optimalizovat je"

no to bude ta nejhorší možná práce. Pochopit slop code a nahradit lepším...hmm. Jako neříkám, že to nejde, ale asi na to nebude vůle... (asi všichni už narazili na části kódu, do kterých nikdo raději nešahá a je rád, že to nějak funguje)

Pořád to ale umožňuje psát okolní kód v Rustu a spolehnout se na kontroly Rustu. Navíc věřím, že zrovna v tomhle se ještě může AI posouvat a že bude umět přepsat C a C++ kód do Rustu tak, aby výsledný kód byl napsaný v Rustu, ne syntaxí Rustu napsaný v C/C++. Mimo jiné i proto, že zrovna o přepis z C/C++ do Rustu pravděpodobně bude zájem, takže se na to AI bude trénovat.

Jinak stále platí, že opravdový Fortran programátor dokáže psát ve Fortranu v libovolném jazyce. A platí to pro všechny zdrojové jazyky. Zdrojové kódy Xercesu pro Javu jsou také syntaxí sice Java, ale myšlením je to C++. Nebo Angular podle mne vznikl proto, aby bylo možné psát Javu v JavaScriptu.

Zajímavé, dřív říkali, že Rust není vhodný, protože není dost objektový, takže se v něm těžko modeluje DOM a další API prohlížeče, která jsou objektová.

Říkají to i teď, ale jelikož rustí i chrome/firefox, jdou s proudem.

Zdá se mi to, nebo přepis Firefoxu tak nějak stagnuje?

Jo, jako celá Mozilla. Ale od úplného přepisu do Rustu, pokud to teda vůbec kdy byl plán, upustili asi už dávno.

V originálním blog postu to píšou přesněji: "...Rust ... is not great at C++ style OOP". Což vůbec neznamená, že se v něm nedá (dobře) psát objektový kód. Někdo by se mohl dokonce dohadovat, že to je právě naopak : ) V tom smyslu jim fandím a ať velese přepisují.

Ale zvolená strategie zdá se mi poněkud nešťastná: "This is not becoming the main focus of the project. We will continue developing the engine in C++, and porting subsystems to Rust will be a sidetrack that runs for a long time."

Takže plánují dál psát v C++ a z ručně psaného C++ automaticky překládat pomocí AI slop-like Rust kód, který chtějí následně ručně přepisovat do idiomatického Rustu 🫡

> V originálním blog postu to píšou přesněji: "...Rust ... is not great at C++ style OOP". Což vůbec neznamená, že se v něm nedá (dobře) psát objektový kód.

Ono samotné objektové programování je hodně závislé na použitém jazyce. Dokonce bych si troufl i tvrdit, že jde o několik různých paradigmat, co spolu mají jen málo společného.

Ano, v podstatě s Vámi souhlasím. Já to myslel zjednodušeně řečeno tak, že za "kánonické" OOP považuji paradigma tak jak ho popsal Alan Kay, což nemá nic společného s tím, jak to má implementováno C++. A potom si myslím, že Rust se hodí spíše na OOP(Alay Kay) než na OOP(C++).

Jo? Přijde mi že OOP podle Kaye je hodně dynamické a rust naopak hodně statický.

Zrovna prohlizec je typ software, ktery muze dost tezit z mnohych vlastnosti Cpp, ktere Rust nema. Delat v nem nejakou abstraktnejsi ronstrukci mi prijde proti modernimu Cpp jako krok dost zpatky.
Jak jsou k tomu motivace?

25. 2. 2026, 12:13 editováno autorem komentáře

Vlastností jako třeba..?

dědičnosti, polymorfismus, templates, overloading, reflection, tvorba a udrzovani ABI.
Něco v rustu jde, ale je to krajne neergonomicke, neco nejde vubec.

Zkus spíš jmenovat něco, co v tom C++ ergonomicky jde ;-)

Dědičnost: Osobně jsem v táboře "Composition over inheritance", ale to i spousta C++ vývojářů. Znám dost lidí co dědičnost používají prakticky jen na abstract classes. Takže dost podobně jako Rust s traity. Ale ano, pokud považuješ class inheritance za dobrý nápad, Rust to nemá.

Templates: Generika v Rustu jsou o něco méně schopná než templates, na stranu druhou, C++ podle mě nemá srovnání s tím co umí Rust makra.

Polymorfismus: Tak tady fakt netuším co ti chybí
Reflection: Odkdy má C++ reflection?
Overloading: Function overloading? Jde částečně přes traity, ale beru

Ale pokud budem hrát "Jazyk něco nemá" hru, tak třeba mimo zmíněných maker:

- Pattern matching + rozumnou práci s tagged unions
- Iterátory
- Rozumný error handling (vyhodit výjimku a modlit se že ji někdo nezapomene chytit neberu jako rozumný)
- Async / Await

25. 2. 2026, 15:23 editováno autorem komentáře

Tak třeba iterátory v c++ jsou, jen mají kapku jiné rozhraní než ty v rustu.

Ale celkově mi to zní, že acx by chtěl psát c++ kód v rustu. Což jde samozřejmě dost blbě.

async/await nie je sucastou Rustu, ale len jeho tretostrannych kniznic.

Ad reflexe – myslím, že to Rust naopak v nějaké podobě může mít díky makrům. Všeobecná reflexe jako v Javě by asi neseděla k filozofii jazyka (a ani v Javě není tak všeobecná, pokud použijeme native-image – ze stejného důvodu), ale nějakou omezenou reflexi mohou přinést makra. Znamená to metadata navíc (podobně jako v native-image) nebo ji použít compile-time (i zde je trochu analogie k native-image – během generování native-image lze reflexi používat bez omezení). V nějaké omezené podobě to IMHO dělá třeba serde.

Assembler je energeticky najvýhodnejší.?!

to by bylo zajimave zjistit jaka uroven abstrakce je ok a co uz je moc a nebo malo pro lidsky mozek.

A teď pro který mozek. Myslím si, že každý vývojář to má trochu jinak.

Jen teoreticky. Ve skutečnosti může třeba Rust nebo C++ dělat optimalizace, na které i programátor v ASM typicky nemá v praxi možnost sáhnout. Nebo si vem JIT kompilátory, které mohou přizpůsobovat kód dynamicky podle dat.

Škoda že zavrhli ten Swift, mohl to být velmi zajímavý počin.

Já jim to nezávidím. Hodně často vidím neoptimální kód vygenerovaný AI, kterému nevěřím, ale někdo jiný ho mergnul.

Tento automatický přepis znamená jen to, že někdo sice docílí vymítění C++, ale bude to opravdu lepší, když tam bude kód, který nikdo nenapsal? Starat se o desetitisíce a možná v budoucnosti statisíce řádků vygenerovaného kódu... Good luck....