Názory k článku Rust: knihovna ndarray pro práci s n-rozměrnými poli
-
bflmpsvz (neregistrovaný)
Tak nevím, nevím. Ze začátku mě byl Rust sympatický, ale nechápu, co má co dělat programovací jazyk s projektovými soubory a už vůbec nechápu, proč by tam měl být nějaký Cargo, co je spravuje.
Zdá se, že se ten Rust začíná pěkně mrvit.
Když chci programovací jazyk, tak chci programovací jazyk a všechno ostatní si udělám sám pomocí Makefile a nechci, aby se mi do toho sral kdokoliv jiný!!!
-
jarda (neregistrovaný)
Cargo není nutné používat, ale potom bude správa projektů dost humus ve stylu každý pes jiná ves.
Popravdě, já mám taky rád Makefile (ten starý dobrý Makefile, ne automake a podobné mezistupně), ale všimni si, že v jazycích s rozsáhlým ekosystémem to už dávno nestačí, takže máme pip, npm, RubyGems, Maven, nějaký tooly pro vývoj s Qt, LuaRocks, Leiningen atd. atd.
Prostě jsou to dva světy - ten klasický Unix+C, kde se instalují devel knihovny do systému se všemi výhodami a problémy a ten "nový" (dnes už tak 15 let starý), kde se knihovny/moduly řeší jedním centrálním systémem univerzálním pro všechny operační systémy. Podle mě u prvního systému není prakticky šance, aby balíčky šly s dobou a aby bylo rozumně možné mít balíčky ve více verzích.
-
Pavel TišnovskýZlatý podporovatelJe to takto - Rust sám o sobě projekty nijak neřeší, je to v základu "jen" překladač, linker, generátor dokumentace a rozhraní ke GNU Debuggeru, takže docela minimalisticky pojatý toolchain. Ovšem pro jakýkoli trošku větší projekt, kde se používají knihovny mimo https://doc.rust-lang.org/std/ , je dost nepraktické se o správu verzí knihoven, jejich závislostí apod. starat sám.
Navíc je - ne vždycky, ale stane se - někdy nutné se přepínat mezi různými verzemi Rustu, většinou mezi stable a nightly variantou. K tomu ještě Rust instalovaný z repa distribuce bývá většinou dost zastaralý, minimálně u tak rychle se vyvíjejícího jazyka, jakým Rust je.
Takže aby se člověk nezbláznil z neustálého symlinkování, řešení závislých knihoven, nastavování LD_LIBRARY_PATH a nakonec i ruční tvorby Makefile, používá se už řešení odladěné - Cargo pro správu projektů a Rustup pro správu vlastního Rustu, přepínání mezi verzemi, upgrade atd. Kdo nechce, nemusí to používat, ale jak říkám - pro cokoli nepatrně většího, než je "Hello world!" bych už ruční správu projektů neřešil a použil Cargo.
-
haha (neregistrovaný)
Tak já nevím, ale jazyk, který dnes nemá centrální správu balíčků/knihoven je dost na nic... Třeba C++ ... zkoušel jsem třeba Bii ... dnes se to jmenuje Conan ... všechno nad CMake systémem, ale prostě to nějak pořád není ono. Změnit knihovny v C/C++ projektu není rozhodně bezproblémový krok, navíc když to zkoušíte řešit multiplatformě. Zlatý Cargo, Stack (Haskell), Paket (.NET). atd ... je snad dnes jazyk co to nemá? (jo ano C++)
-
KateStříbrný podporovatelJojo. Použít knihovny v systému? Co když není? Nebo není ve správné verzi? Tvořit nový balíček pro věc co stejně potřebuju jenom staticky slinkovat k jedné binárce? Stáhnout a přihodit k projektu? Jak pak ale řešit update knihovny? Prostě je to bordel. Cargo tohle řeší úžasně elegantně.
ČLÁNKY DO MAILU