Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - anonacct

Stran: [1] 2 3 ... 12
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 01. 10. 2025, 23:44:39 »
Já jen použil příklad co tu byl, kdybych měl vytvořit vlastní tak by zněl takto:

```
struct Point {
  double x, y;
};
```

Chci vůbec mít member funkce? Já třeba preferuju `distance(p1, p2)` než `p1.distance(p2)`. To samé když vidím třeba `a.dot(b)`, atd... přijde mi to až přehnané API navrhovat takto.

2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 01. 10. 2025, 14:39:08 »
Kód: [Vybrat]
vaha.zvazit(osoba)
osoba.zvazitSe(vaha)

Oboji je spatne. Melo by to byt akce::zvazit(osoba, vaha) - a je to. Osoba nemusi znat nic o vaze, a vaha muze umet vazit treba i zvirata nebo mouku.

Cele OOP je do jiste miry divne, nuti nas vazat akce na konkretni objekty, ktere by klidne mohly byt naprosto nezavisle.

3
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 26. 09. 2025, 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...

4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« 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.

5
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« 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.

6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 22:13:22 »
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.

7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 18:23:31 »
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...

8
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 13:59:27 »
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............

9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 24. 09. 2025, 13:35:56 »
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...

10
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 23. 09. 2025, 15:48:17 »
To je ale logické, že bug v unsafe kódu má vliv i na safe kód a platí to pro jakýkoliv programovací jazyk.

11
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 23. 09. 2025, 14:50:36 »
Safe API můžeš udělat nad unsafe API a je to naprosto běžná věc. Otázka jen je, kolik toho unsafe kódu musíš napsat. V rustu je zvykem ho izolovat, v ale C++ může být kdekoliv, protože unsafe je úplně všechno a pointer aliasing je tak nějak všude (např. iterátory).

12
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 23. 09. 2025, 13:36:15 »
Rust ale vytvořili právě lidi, co už měli C++ plné zuby, že jo :)

Je to zatím jediný jazyk, který umožňuje napsat to co v C++, ale naprosto safe, a jazyk, který se dostává do různých projektů, právě kvůli jeho kvalitám. To zatím žádný jiný jazyk nenabídl. A navíc rust má i built-in package management, takže žádné ohavnosti typu vcpkg nebo conan. A žádný cmake!

13
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 14:41:50 »
Moje odpověď je rust, ale hodně firem použije na server věci prostě golang, i když pro mě je golang prostě ošklivý jazyk a chybí mí tam "const".

Drbat se dnes s C++ prostě nestojí za to. U legacy kódu to chápu, ale u nového kódu ne.

14
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 22. 09. 2025, 11:20:18 »
Safety profiles a C++, dovolil by si sdílet tento link:

https://www.circle-lang.org/draft-profiles.html

Je to od člověka, který chtěl fakt C++ pomoct a udělal toho víc než všichni ti diskutující tady dohromady. Problém ale je, že C++ committee prostě nikdy nechce nic dobrého, a vždycky se jde cestou zmetků a věcí, které vývojáři nechcou.

C++ jde nevyhnutelně ve špatné trajektorii a dnes už není moc důvod použít C++ na nový projekt - jsou mnohem lepší jazyky.

15
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« kdy: 20. 09. 2025, 21:02:02 »
Rust konkuruje více jazykům - C, C++, Go, node.js, Java, atd...

Ono se to nezdá, ale rust je celkem multiúčelový a díky package managementu je celkem jednoduché ho použít pro různé věci. Já už bych třeba nikdy nechtěl psát server nějaké služby v C++. Kdysi jsem měl oblíbený node.js právě pro tu jednoduchost napsat v tom nové věci nebo nějaké jednoduché služby, co jsem potřeboval, ale dnes mám radši rovnou použít rust.

Lidi co říkají, že rust nenahradí C++ žijou ve vlastním omezeném světě. Ono už se to totiž děje, sice salámovou metodou, ale jede se.

Stran: [1] 2 3 ... 12