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

[anonacct]

To, že něčemu důvěřuješ je sice hezké, ale to ještě neznamená, že tam nejsou kritické chyby. Ty se vždycky objeví i u těch nejdůležitějších projektů. Důležité je mít o tom všem přehled, a ten prostě nemáš, když si děláš všechno sám.

Mít minimum závislostí v C++ projektu není žádný benefit - je to důsledek toho, že C++ nemá package management tak jako ostatní jazyky. Header-only knihovny taky vznikly jen z toho důvodu, aby nikdo nemusel řešit kompilaci těch knihoven, a malé knihovny co řeší jen velmi konkrétní problém v C++ skoro neexistujou a nebo je nikdo nepoužívá kvůli tomu, aby neměl další závislost, o kterou se musí "manuálně" starat.

Mít package management je automatizace, nemít ho znamená dělat všechno ručně... Je to čistá ztráta času vývojáře.

[Reklama]

[Radek Miček]

To, že něčemu důvěřuješ je sice hezké, ale to ještě neznamená, že tam nejsou kritické chyby. Ty se vždycky objeví i u těch nejdůležitějších projektů. Důležité je mít o tom všem přehled, a ten prostě nemáš, když si děláš všechno sám.

S první částí souhlasím. Týká se to samozřejmě i LLVM, kompilátoru, běhového prostředí, standardní knihovny... To je další důvod, proč jsem s Rustem opatrný. Kompilátor Rustu má přes milion řádků kódu a je poměrně komplikovaný, takže je tam velká pravděpodobnost chyb. Podobně i standardní knihovna, která je plná složitého unsafe kódu. Naopak třeba kompilátor C3 je o dost jednodušší a standardní knihovna je téměř primitivní.

Mít minimum závislostí v C++ projektu není žádný benefit

Zkušenost mi ukázala, že to je obrovský benefit. Nejen v C, C++, ale i v F# nebo Rustu. Nejvíc problémů vznikalo po updatu závislostí. Kolikrát to navíc byl i update na nějaké minor verzi, který teoreticky neměl rozbít nic, ale skutečnost byla jiná.

[anonacct]

Já si ale nechci psát vlastní asio, fmt, spdlog, JSON parser, XML parser, YML parser, algebru, OpenCV, ... Nedělal bych nic jiného než si jen psal to co už je 1000x hotové. Pokud si člověk vybere knihovny, které jsou battle tested, tak s tím přece není problém.

Jen super jednoduché projekty nic nepotřebujou.

[Filip Jirsák (forum)]

Nejvíc problémů vznikalo po updatu závislostí.

Což ale neznamená, že nepoužíváním závislostí těch problémů nebudete mít ještě daleko víc.

Kolikrát to navíc byl i update na nějaké minor verzi, který teoreticky neměl rozbít nic, ale skutečnost byla jiná.

To je bohužel realita – sémantické verzování je hezká teorie, ale v praxi nejsou hranice mezi opravou a změnou funkcionality tak ostré.

[Radek Miček]

Nejvíc problémů vznikalo po updatu závislostí.

Což ale neznamená, že nepoužíváním závislostí těch problémů nebudete mít ještě daleko víc.

Používám méně závislostí a těch problémů mám méně. Ale samozřejmě, nemusí to platit obecně.

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

[Reklama]

[snugar_i]

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).

[Jožka Niemand]

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).

Knihovny mají tendenci být komplexní a řešit věci, z nichž většinu pro svůj úkol nepotřebuji, a jediná funkce té pro mě nepotřebné části je, že je akorát potenciálním zdrojem chyb a exploitů. Vždycky je dobré zvážit, zda se vyplatí nějakou prkotinu na pár řádků řešit knihovnou čítající desítky-stovky tisíc LOC, z nichž každý má nějakou nenulovou pravděpodobnost, že je zabugovaný. Nehledě na to, že je nelidské, když třeba mobilní aplikace na pouhé posílání zpráv zabere víc, než byla kapacita mého prvního hard disku na PC.

[anonacct]

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).

Knihovny mají tendenci být komplexní a řešit věci, z nichž většinu pro svůj úkol nepotřebuji, a jediná funkce té pro mě nepotřebné části je, že je akorát potenciálním zdrojem chyb a exploitů. Vždycky je dobré zvážit, zda se vyplatí nějakou prkotinu na pár řádků řešit knihovnou čítající desítky-stovky tisíc LOC, z nichž každý má nějakou nenulovou pravděpodobnost, že je zabugovaný. Nehledě na to, že je nelidské, když třeba mobilní aplikace na pouhé posílání zpráv zabere víc, než byla kapacita mého prvního hard disku na PC.

Já kvůli jedné funkci radši použiju knihovnu fmt, než abych si to psal sám. Je to battle-tested knihovna, kterou už někdo napsal a pořádně otestoval, a jako bonus na ní pořád někdo pracuje a dělá ji rychlejší.

Toto byl jen příklad, který vyvrací to tvrzení o jedné funkci.

Já taky nepotřebuju knihovnu na to, abych zaokrouhlil floating point half way up třeba, ale nechci si psát fmt nebo nějaký high performance logging, atd...

[Franta Kučera]

Napsat si něco sám má své výhody i nevýhody. Výhodou je, že nad tím mám plnou kontrolu - dodržuji zpětnou kompatibilitu, když to potřebuji, nedávám tam funkcionalitu, co nepotřebuji. Nevýhodou je, že stojí čas si to napsat. Občas to je však méně času, než se naučit používat cizí knihovnu, nebo tu cizí knihovnu ohnout, aby fungovala, jak potřebuji.

Ještě jsi zapomněl na jednu další nevýhodu - zavedeš si tam bugy. Žádný kód nejde napsat bez bugů, a na rozdíl od cizí knihovny ti je nikdo neopraví. Všechny je musíš najít a opravit sám (ano, pokud by ta cizí knihovna byla nekvalitní, tak v ní nejspíš bude víc bugů než ve tvojí implementaci, ale u kvalitní, zavedené a "battle-tested" knihovny to až tolik nehrozí).

Knihovny mají tendenci být komplexní a řešit věci, z nichž většinu pro svůj úkol nepotřebuji, a jediná funkce té pro mě nepotřebné části je, že je akorát potenciálním zdrojem chyb a exploitů. Vždycky je dobré zvážit, zda se vyplatí nějakou prkotinu na pár řádků řešit knihovnou čítající desítky-stovky tisíc LOC, z nichž každý má nějakou nenulovou pravděpodobnost, že je zabugovaný. Nehledě na to, že je nelidské, když třeba mobilní aplikace na pouhé posílání zpráv zabere víc, než byla kapacita mého prvního hard disku na PC.

+1, viz také Sane software manifesto:

Depend on small and useful libraries – not on bulky application packages or libraries with large transitive dependencies.

Nicméně tahle diskuse by se dala okomentovat slovy: „nehádejte se, pravdu máte oba“ :-) Protože ona málokterá rada nebo doporučení platí absolutně a řídit se jimi do extrému a bez přemýšlení nadělá víc škody než užitku. Na jedné straně je pravda, že znovupoužitelnost je dobrá věc, že nemá cenu vynalézat kolo znova a znova… ale na druhé straně je taky pravda, že lidi často při psaní i triviálních aplikací nesmyslně navýší komplexitu softwaru, nikoli tím, že by napsali víc řádků vlastního kódu, než je nutné, ale tím, že do něj bezmyšlenkovitě zatáhnou kvanta závislostí, aniž by si uvědomovali dopady, případně si dokonce myslí, že přidáním nějaké závislosti ten software vylepšili. Přitom by v některých případech udělali lépe, kdyby „vynalézali kolo“ a „trpěli NIH syndromem“, protože by jejich software (jako celek) byl jednodušší a ještě by se při tom naučili programovat (a ne jen lepit).

[Ink]

Přitom by v některých případech udělali lépe, kdyby „vynalézali kolo“ a „trpěli NIH syndromem“, protože by jejich software (jako celek) byl jednodušší a ještě by se při tom naučili programovat (a ne jen lepit).

Ano, někdy. Problém nezřídka je, že z prostého kola se časem stane celý NIH-syndrom kombajn, protože když už umíme tak hezky programovat, proč si k tomu kolu ještě nevynalézt hřídel atd.

[Franta Kučera]

Přitom by v některých případech udělali lépe, kdyby „vynalézali kolo“ a „trpěli NIH syndromem“, protože by jejich software (jako celek) byl jednodušší a ještě by se při tom naučili programovat (a ne jen lepit).

Ano, někdy. Problém nezřídka je, že z prostého kola se časem stane celý NIH-syndrom kombajn, protože když už umíme tak hezky programovat, proč si k tomu kolu ještě nevynalézt hřídel atd.

Ale to se pořád točíme kolem toho „nehádejte se, pravdu máte oba“. Jinak mi ale přijde, že tímhle se snažíš řešit spíš problém cca 80. a 90. let (kdy se skutečně významné množství času plýtvalo na opakovanou implementaci téhož), zatímco problém posledních 1-2 desetiletí je spíš v tom, že komplexita softwaru narostla (v důsledku přidávání závislostí a dalších vrstev) obludným způsobem a vůbec neodpovídá komplexitě řešené úlohy. A počítám, že problém příštích desetiletí bude: jak se vyrovnat s enormním množstvím nepříliš kvalitního kódu vygenerovaného pomocí AI, který byl promíchán s kódem napsaným lidmi, a hlavně jak tuhle nevábnou směs udržovat. Možná s tím trochu pomůže AI, ale tím vlastně jen řeší problém, který sama vytvořila.

[Kit]

A počítám, že problém příštích desetiletí bude: jak se vyrovnat s enormním množstvím nepříliš kvalitního kódu vygenerovaného pomocí AI, který byl promíchán s kódem napsaným lidmi, a hlavně jak tuhle nevábnou směs udržovat. Možná s tím trochu pomůže AI, ale tím vlastně jen řeší problém, který sama vytvořila.

Obávám se, že ten problém nevytvořila AI, ale autoři kódu, ze kterého se učila. Mně však její kód z valné části vyhovuje - asi píši jiné prompty.

[novomente]

Nicméně tahle diskuse by se dala okomentovat slovy: „nehádejte se, pravdu máte oba“ :-)

Tak to je teda pravda 

Nicméně trocha hádky o to či ono napoví o problémech a úskalých v programování ve zmíněných jazycích. A to pokládám taky za hodnotný. Teda pokud ta "hádka" nezamrzne jen na jednom tématu (problému, nebo úskalý).