Přechod z Javy na Rust. Ano či ne?

[anonacct]

echo_zulu: Vem si random program v C++ co má třeba 20 závislostí a zkompiluj ho pro Windows, Linux a Mac.

C++ má totálně idiotský package management (žádný). V jedné firmě jsem dokonce zažil 3 in-house package managery v jednom jediném C++ projektu, který si napsali lidi pro Windows, Linux, a Mac zvlášť, protože jim to asi přišlo cool, popř. protože každá platforma měla nějaké věci, co museli řešit (třeba pro mac nechci svoji zlib, stačí ta systémová...).

Hodně C++ vývojářů má i projekty v rustu, a já sám jsem byl hodně dlouho na straně C++, jenže i já dělám v C++ chyby, protože v C++ se většinou píšou low-level věci - na high-level věci, kde na výkonu nezáleží, na to už máme docela jiné jazyky a možnosti.

Takže, já nechci hanit C++, sám ten jazyk používám a asi budu do konce života, ale... C++ má hodně problémů a prostě to není jazyk, ve kterém bych chtěl dělat nové projekty, když tu je rust, popř. jiné technologie.

C++ měl hodně dlouho monopol, protože to byl jediný jazyk s "C-like" výkonem, co nabízel 1000x víc než C, takže správná volba pro větší projekty a tam, kde byl potřeba výkon. Ale, pak přišel rust, a upřímně když člověk zkusí rust, tak zjistí, jak moc je C++ neergonomický jazyk.

Je to můj názor jako někoho kdo používá C++ víc než 20 let. Podle mě konkurence je potřeba a buď se z toho C++ vzpamatuje a nebo ne...

[Reklama]

[Radek Miček]

C++ má totálně idiotský package management (žádný). V jedné firmě jsem dokonce zažil 3 in-house package managery v jednom jediném C++ projektu, který si napsali lidi pro Windows, Linux, a Mac zvlášť, protože jim to asi přišlo cool, popř. protože každá platforma měla nějaké věci, co museli řešit (třeba pro mac nechci svoji zlib, stačí ta systémová...).

Osobně mi tohle vyhovuje více než třeba cargo.

Závislosti jednoduše postahuji k projektu. Pak mám jednoduchý bat nebo sh soubor, který vše přeloží.

[anonacct]

A teď si představ, že potřebuješ použít nějakou knihovnu nebo framework, který jen tak zbuildit znamená třeba postahovat 30 závislostí, a ten framework se vyvíjí.

Z toho se stane part-time job jen řešit ty závislosti, aby byly aspoň trochu aktuální.

Já jsem třeba na jeden projekt potřeboval použít knihovnu Skia............

[Radek Miček]

A teď si představ, že potřebuješ použít nějakou knihovnu nebo framework, který jen tak zbuildit znamená třeba postahovat 30 závislostí, a ten framework se vyvíjí.

Z toho se stane part-time job jen řešit ty závislosti, aby byly aspoň trochu aktuální.

Přesně tohle nedělám. Snažím se držet závislosti na minimu nebo si nevybírám závislosti, které mají tranzitivně desítky či stovky jiných závislostí. Snažím se totiž každou závislost auditovat - při každé změně pročíst diff a neupdatovat, pokud se mi to nezdá. A bohužel cargo apod. tomu nepomáhají (viz npm poslední dobou).

[Jožka Niemand]

A teď si představ, že potřebuješ použít nějakou knihovnu nebo framework, který jen tak zbuildit znamená třeba postahovat 30 závislostí, a ten framework se vyvíjí.

Z toho se stane part-time job jen řešit ty závislosti, aby byly aspoň trochu aktuální.

Já jsem třeba na jeden projekt potřeboval použít knihovnu Skia............

To je pak otázka, co je pro vás low-level projekt, když má desítky závislostí. Asi ne totéž, co třeba pro mě.
Jinak souhlas s C++, to používám jen z donucení, pokud možno vůbec. Na low-level věci zásadně C, případně Forth, případně Assembler. Na high-level je docela velký výběr.  C++ je moderní obdoba FORTRANu - k ideálu daleko, poznamenán letitým vývojem, halda zdrojáků v něm napsaných. A lidi kolem Rustu - ty si představuji jako takové ty polonahé tlouštíky na čtyřech s koženou maskou pejska, co si je na vodítku tahá domina s důtkami (tj. kompilátor Rustu). Proti gustu... Jen ať mi to nikdo nevnucuje jako to nejlepší, co kdy bylo vymyšleno.

[Reklama]

[BoneFlute]

C++ má totálně idiotský package management (žádný). V jedné firmě jsem dokonce zažil 3 in-house package managery v jednom jediném C++ projektu, který si napsali lidi pro Windows, Linux, a Mac zvlášť, protože jim to asi přišlo cool, popř. protože každá platforma měla nějaké věci, co museli řešit (třeba pro mac nechci svoji zlib, stačí ta systémová...).

Osobně mi tohle vyhovuje více než třeba cargo.

Závislosti jednoduše postahuji k projektu. Pak mám jednoduchý bat nebo sh soubor, který vše přeloží.

Snažím se totiž každou závislost auditovat - při každé změně pročíst diff a neupdatovat, pokud se mi to nezdá. A bohužel cargo apod. tomu nepomáhají (viz npm poslední dobou).

Tohle nechápu.

Pokud je to pocit, tak ok.

Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Představuji si sebe. Když budu dělat malý projekt a budu potřebovat brutálně auditovat, tak mi cargo krásně ukáže, že tahle verze si stahuje tyhle závislosti -> takže tuhle nechci, tenhle balík nechci. Cargo mi v každém okamžiku ukáže kolik je závislostí, stáhne je a já je mohu auditovat. Mohu omezovat, aby těch závislostí bylo co nejmíň. Spoustu ruční práce mi to ušetří.

Druhá věc je smysl balíčků. Jako chápu, že ty to nepotřebuješ. Ale většina vývojářů prostě nejsou topka, a tak můžeme těžit z toho, že můžeme auditovat už něčí auditovaný balíček. Představa, že v každém týmu, který používá závislost X je někdo, kdo to audituje, a nedá vědět ostatním na co přišel, mi přijde nešťastná. Díky tomu ten audit nikdy nemůže být tak dobrý.

[anonacct]

Jo ten audit C++ závislostí bych chtěl taky vidět, to nejde udělat, pokud ty závislosti mají miliony řádků unsafe kódu...

[BoneFlute]

Takže, já nechci hanit C++, sám ten jazyk používám a asi budu do konce života, ale...

Pro mě je C++ mrtvá záležitost. Už se k němu nikdy nechci vracet.

[Franta Kučera]

Jo ten audit C++ závislostí bych chtěl taky vidět, to nejde udělat, pokud ty závislosti mají miliony řádků unsafe kódu...

Slovo „unsafe“ je tady dost zavádějící. Bezpečnostní audit neděláš jen kvůli náhodným chybám (z nichž jen část je způsobena „unsafe“ kódem – spousta z nich jsou chyby v logice – špatně napsaný IF, použití jiného atributu, volání jiné metody nebo metod ve špatném pořadí, chybné parsování vstupu atd.), ale i kvůli záměrným dírám a zadním vrátkům, které tam nechal autor, nebo podstrčil nějaký „brigádník“ či náhodný „přispěvatel“ a za kterými ve skutečnosti stojí nějaká zločinná organizace. A tyhle chyby (nebo spíš záměrně škodlivé vlastnosti) můžou být i v programu či knihovně psaných v tom nejbezpečnějším jazyce na světě.

Balíčkovací systémy jsou obecně dobrá věc a umožňují problém řešit více systematicky. Má to ale svoje úskalí:

1) Tím, jak je jejich použití jednoduché, nad tím lidé míň přemýšlejí. Stačí se podívat, co všechno se stahuje z internetu v rámci sestavení běžné moderní aplikace. To množství knihoven často dosahuje hrůzných rozměrů i u relativně triviálních aplikací, které nic moc nedělají. Množství knihoven, autorů a řádků kódu, které jsou za tím, je enormní. Jak píšu ve svém článku o komplexitě softwaru:

Důležité ale je nezapomínat, proč to děláme a na jakém předpokladu naše rozhodnutí (přidat tu či onu závislost) stálo. Tento předpoklad bychom měli průběžně testovat – a pokud zjistíme, že platit přestal, tak z toho vyvodit patřičné závěry. Neměli bychom zapomínat na to, že samotný vyšší programovací jazyk (např. Java nebo PHP) spolu se svojí standardní knihovnou jsou samy o sobě frameworkem, stejně jako je frameworkem UNIX (resp. dnes převážně GNU/Linux) a že poskytují víc než dostatečnou úroveň abstrakce pro vývoj mnoha aplikací.

Je to trochu paradox, protože ten čas, který nám balíčkovací systém ušetřil, bychom mohli věnovat přemýšlení, jestli tu či onu knihovnu skutečně potřebujeme případně jejímu nahrazení něčím jednodušší. Ale není tomu tak. To pohodlí spíše to přispívá k tomu, že software není příčetný. Zatímco ta ruční správa závislostí fungovala jakási přirozená brzda před tím, aby programátor do projektu nezatáhl kde co. Minimálně u průměrných vývojářů to tak funguje. Čest výjimkám.

2) Balíčkovací systémy specifické pro daný programovací jazyk jsou nešťastné. Někdy vznikaly pod tlakem okolností a z nedostatku jiných řešení nebo neochoty se dohodnout, někdy jsou důsledkem egocentrického myšlení autorů, kteří jsou přesvědčení o výjimečnosti svého programovacího jazyka a trpí utkvělou představou, že teď se do něj přepíše všechen software světa. Podobně jako když si autor programu myslí, že jeho výtvor je středem vesmíru a že se mu ostatní musí přizpůsobit. Ve skutečnosti jsou ale softwarové systémy mnohem pestřejší a heterogenní, vždy budou, a je potřeba se s tím smířit. Proto dávají smysl balíčkovací systém obecné, fungující napříč programovacími jazyky (a kolikrát je potřeba spravovat i data, ne jen spustitelný kód), které umožní správu toho heterogenního celku. Správa závislostí je abstraktní úloha a logika specifická pro konkrétní programovací jazyk by měla být leda zapouzdřena ve volitelném modulu pro daný jazyk, který se do toho obecného balíčkovacího systému připojí.

[Ondrej Nemecek]

Současný UI toolkit pro javu je JavaFX.

Ono je to složitější. JavaFX je modernější než Swing a původně ho měl nahradit. Pak ale Oracle JavaFX opustil (protože si Oracle obecně s desktopovou Javou neví rady, resp. s desktopovými aplikacemi vůbec…) a nyní JavaFX stojí na nepříliš velké komunitě. Takže jeho budoucnost není moc jistá. Naproti tomu Swing je stále součástí Javy a komunita kolem něj (včetně velkých a obřích firem) je tak velká, že o jeho budoucnost není potřeba se bát.

Pro nějaký hobby projekt je JavaFX dobrá volba, pokud by ale měla vzniknout nová desktopová aplikace psaná v Javě, u které by se očekávalo dlouhodobé použití, volil bych Swing.

Typicky dnes ovládá vývojář několik jazyků a celou škálu technologií.

No, typicky dnes vývojář píše v několika jazycích. Do jaké míry je doopravdy ovládá už je různé.

Ale moc Swing nových aplikací asi nevzniká, ne? Podle mě Swing už spíš legacy framework. Javy FX by bylo škoda. Doufám, že dojde k určité renesanci desktopových aplikací.

[Radek Miček]

Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Myslím si, že cargo (nebo i třeba npm či nuget) je mezivrstva, která dělá těžší detekovat backdoory nebo jiný prapodivný kód. Problém je, že v crates repozitáři občas bývá jiný kód než v repozitářích se zdrojovými kódy.

Dokonce studie z minulého roku zjistila více než 15 procent z nejpoužívanějších 999 crate mají na crates jiný kód než v repozitářích. Takže mi to přijde jako časovaná bomba.

Osobně si naklonuji repozitář, projdu si jednotlivé commity a pak si vyberu určitý commit, který vložím do svého projektu. Nebo používám přímo API operačního systému či široce používaných knihoven, kterým věřím víc než nějakým frameworkům.

[anonacct]

Objektivně ale když nepoužiješ cargo, tak naopak ztrácíš spoustu informací které k tomu auditu potřebuješ.

Myslím si, že cargo (nebo i třeba npm či nuget) je mezivrstva, která dělá těžší detekovat backdoory nebo jiný prapodivný kód. Problém je, že v crates repozitáři občas bývá jiný kód než v repozitářích se zdrojovými kódy.

Dokonce studie z minulého roku zjistila více než 15 procent z nejpoužívanějších 999 crate mají na crates jiný kód než v repozitářích. Takže mi to přijde jako časovaná bomba.

Osobně si naklonuji repozitář, projdu si jednotlivé commity a pak si vyberu určitý commit, který vložím do svého projektu. Nebo používám přímo API operačního systému či široce používaných knihoven, kterým věřím víc než nějakým frameworkům.

Jenže dobrý package management znamená, že lidi začnou publikovat menší knihovny, které řeší jednu konkrétní věc. Hledat commit, který ty chceš, když máš N závislostí, a ty závislosti můžou mít tranzitivní závislosti je jen obrovská ztráta času.

Package management řeší totiž i ty tranzitivní závislosti, a popřípadě konflikt mezi něma. Pokud používám ekosystém, kde jsou knihovny na jednu věc, a ne frameworky co mají tunu funkcí, tak tento přístup prostě není možný.

Co je horší, v C++ začal být trend "header-only" knihoven, které lidi dropnou do projektu a už nikdy neaktualizujou. Toto je naprosto katastrofické, protože je ani nezajímá jestli tam třeba není nějaká chyba.

Package management právě řeší dobře ty chyby v závislostech. Nebo chceš mi říct, že když aktualizuješ tvoje závislosti, tak děláš review každého commitu co ty závislosti mají? Tomu nevěřím, že by to bylo možné dělat i u menšího projektu.

Už se mi moc nechce o tom diskutovat. Jen bych doplňil ještě pár věcí o C++:

  - ještě jsem nikdy nezažil C++ projekt, kde by přišli vývojáři a začali hned pracovat - místo toho se začnou hádat o coding style, kde použít exceptions, kde používat result/expected typy, atd... C++ má milion konvencí, co lidi tak nějak používají jednou tu a jednou tam, ale dohodnout se je velmi těžké. I nastavit věci jako automatické formátování atd...

  - když jsem začínal v minulosti C++ projekty, tak nastavit build system a CI, aby tam byly různé sanitizery, testy, podpora pro různé platformy, gtest, SIMD, atd... To je práce na týden a vždycky to dopadlo tak, že jsem vzal jiný projekt a udělal copy/paste základního CMakeLists.txt a CI pipeline, a jen upravil pro potřeby nového projektu. Prostě nastavit C++ projekt je neuvěřitelný opruz a CMake ačkoliv používaný v C++ ekosystému, je ten největší hnus co jsem kdy musel používat.

[Filip Jirsák (forum)]

Ale moc Swing nových aplikací asi nevzniká, ne? Podle mě Swing už spíš legacy framework. Javy FX by bylo škoda. Doufám, že dojde k určité renesanci desktopových aplikací.

Těžko říct, ono nevzniká moc nových desktopových aplikací v Javě obecně. Ale vývojové nástroje od JetBrains jsou Java+Swing, a to je rozhodně pořád živé. Nejspíš se tam nebudou moc přidávat nové vlastnosti (i když JetBrains myslím má nějaká svoje vylepšení), ale zase to není ve stavu, že už by se to jen nechávalo umřít.

[Radek Miček]

Nebo chceš mi říct, že když aktualizuješ tvoje závislosti, tak děláš review každého commitu co ty závislosti mají?

Většinou ano. Pokud se něco změnilo hodněkrát, tak se kouknu na diff přes více commitů. S tím, že API operačního systému a široce používaným knihovnám (např. OpenSSL, SQLite) důvěřuji.

Jinak se snažím používat minimum cizích závislostí.

[BoneFlute]

1) Tím, jak je jejich použití jednoduché, nad tím lidé míň přemýšlejí. Stačí se podívat, co všechno se stahuje z internetu v rámci sestavení běžné moderní aplikace. To množství knihoven často dosahuje hrůzných rozměrů i u relativně triviálních aplikací, které nic moc nedělají. Množství knihoven, autorů a řádků kódu, které jsou za tím, je enormní.

Tím, že to člověk musí stahovat ručně nad tím nezačne víc přemýšlet.

Zrovna včera jsem rozškubal jeden balíček, který sloužil jako mezivrstva. Nelíbilo se mi, že je tam určitá zbytečnost, nelíbilo se mi tam pár dalších věcí. A tak jsem strávil několik hodin, že jsem to nahrazoval vlastním řešením.

Druhý balíček jsem nechal, protože už byl příliš velký a komplexní. A věnovat se tomu by nebylo ekonomické. A rizika nebylo sto předpokládat.

Kdo nepřemýšlí neopoužívání balíčkovacího systemu k přemýšlení nepřinutí.