Názory k článku
Rust 1.90.0 přechází na rychlejší linker LLD, Cargo umí vydat celý workspace

Jaké jsou vůbec garance kompatibility?

Ptám se, protože přidání nových implementací může rozbít existující kód (nevím, jestli to dokonce nemůže změnit jeho význam).

Linker? Existující kód? Změnit význam?

Kromě linkeru přidali i impl (implementace) nějakých traitů. Když ta změna šla do nightly, tak rozbila nějaké testy - viz issue 143164.

Tady je ten mechanizmus popsaný v Breakage from new trait impls. A píší tam i

This kind of breakage can be ok, but a crater run should estimate the scope.

Ale říkám, jestli je jedno, kolik věcí ta změna rozbije, nebo velké rozbíjení už zamítnou?. A pak také, zda může nastat situace, kdy se změní chování existujícího kódu. AFAIK v Haskellu to možné bylo, ale tam byl systém typových tříd a jejich instancí o dost bohatší než v Rustu.

Jakákoliv změna významu by byl bug, pro takovou míru nekompatibility jsou tu edice (A ani tam si nevybavuju situaci, kdy by se stejný kód kompiloval s jiným výstupem).

Po několika letech zaměstnání jako Rust vývojářka na čistě Rust codebase si nevybavuju na situaci, kdy by mi nové implementace traitů rozbily build, takže to bude asi spíš vzácnost. Na co spíš občas narazím jsou nové defaultní linty, ale to je snadná oprava (A pochopitelně by se tomu dalo předejít nastavením)

Já jsem se třeba poohlížel po nějaké rust pozici a bylo toho hodně málo. C++ market je tak 1000x větší, takže zůstávám zatím tam. Časem ale uvidím.

Mám už i trochu problém s Golangem. Původní myšlenka byla, že jedna knihovna umí jednu věc a nebudou nikdy potřeba verze. Dneska je to jinak, máme moduly, což je sice fajn, ale netuším, proč někteří autoři potřebují až 4 verze knihoven k tomu, abych se připojit k databázi, která je golang native.

Pokud někdo potřebuje zásadně změnit knihovnu, tak má vydat novou verzi pod novým názvem. Tohle byla původní myšlenka.

Dost divná myšlenka. Představa, že něco někdo vždy vymyslí od začátku dokonale...

V okolním fyzickém světě to tak funguje. A i když to není dokonalé, tak by to aspoň mohlo zůstat zpětně kompatibilní.

Ona zpětná kompatibilita je spíš ideál než něco dosažitelného. Když je nějaký bug potřeba opravit protože je pozorovatelný, tak na to špatné chování může někdo i spoléhat. A při implementaci verzování je s tím třeba počítat.

Však v enterprise řešeních je bug součástí chování verze. Zpětně se opravují jen security bugy.

22. 9. 2025, 15:27 editováno autorem komentáře

Ono s tím při implementaci verzování stoprocentně počítat nelze. Co je pro jednoho chyba je pro jiného očekávané chování. Co je pro jednoho oprava chyby pro jiného je breaking change.

Sémantické verzování popisuje, jak se to bude chovat pro většinu lidí, přesněji jak si vývojáři myslí, že se to bude chovat pro většinu lidí. Ale nikde není zaručeno, že to tak bude zrovna pro vás. Bohužel si spousta lidí myslí, že sémantické verzování je něco naprosto přesného, na co se dá 100% spoléhat. Nedá.

> Pokud někdo potřebuje zásadně změnit knihovnu, tak má vydat novou verzi pod novým názvem. Tohle byla původní myšlenka.

Jako že major verze se má pro účely verzovacího systému strčit do jednoho stringu spolu s názvem knihovny?

Ale jo, pro megakorporát, který je známý svým monorepem a "not invented here" sydromem to může i fungovat.

Pokud je knihovna X verze Y+1 nekompatibilní s verzí Y, tak proč ne. Stejně jako máme třeba gtk2, 3, 4 a Qt4, 5, 6.