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

Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #105 kdy: 25. 09. 2025, 12:52:11 »
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.
« Poslední změna: 25. 09. 2025, 12:54:34 od anonacct »


Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #106 kdy: 25. 09. 2025, 14:01:36 »
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í.

Citace
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á.


Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #107 kdy: 25. 09. 2025, 14:21:30 »
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.
« Poslední změna: 25. 09. 2025, 14:24:16 od anonacct »

Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #108 kdy: 25. 09. 2025, 17:06:06 »
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é.

Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #109 kdy: 25. 09. 2025, 17:17:30 »
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.


Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #110 kdy: Dnes v 08:51:39 »
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í).

Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #111 kdy: Dnes v 11:05:00 »
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.

Re:Přechod z Javy na Rust. Ano či ne?
« Odpověď #112 kdy: Dnes v 11:35:16 »
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...