Vlákno názorů k článku
Volné místo v příkazové řádce moderně: duf
od Uncaught ReferenceError: - duf na svých počítačích používám a docela jsem...
-
duf na svých počítačích používám a docela jsem si ho oblíbil, na serverech se samozřejmě držím klasických nástrojů, aby kdokoliv jiný to uměl také spravovat.
Myslím, že go jazyk vypadá jako velice zajímavý na psání podobných nástrojů, kód je krátký přehledný, dobře se to kompiluje pro spousty různých systémů (narozdíl od rustu).
Mimochodem autor má na svědomí řadu dalších pěkných věcí.
-
Jestli se nemýlím, kolega tím myslí cross kompilaci, která v Go jde opravdu snadno (
env GOOS=linux GOARCH=... go builda vyplivne to binárku pro libovolnou architekturu), zatímco s Rustem nejprve musíte sestavit cross-compiler a standardní knihovnu pro nový target (tj. podobně jako se to dělá s gcc). -
Zcela obecně rozumím, ale v dnešní době to snad už není kdovíjak běžné; stabilizace featur Rustu samotného a velkých frameworků myslím pro drtivou většinu použití potřebu používání nightly a jiných edicí, než aktuální stable, odsunula do minulosti.
Pro psaní utilitek typu duf s pár tisíci řádek kódu, tím spíše.
8. 5. 2021, 08:48 editováno autorem komentáře
-
Schválně udělám pokus, mám aktuálně, z historických důvodů, toolchainy
stable-x86_64-unknown-linux-gnu (default)
beta-x86_64-unknown-linux-gnu
nightly-2019-05-22-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu
1.37.0-x86_64-unknown-linux-gnu
1.47.0-x86_64-unknown-linux-gnuZabírají 5.4 GiB. Po ponechání pouze stable je to 1.1 GiB. Přidám pár dalších targetů. Mám
aarch64-linux-android
asmjs-unknown-emscripten
wasm32-unknown-emscripten
wasm32-unknown-unknown
x86_64-apple-darwin
x86_64-pc-windows-gnu
x86_64-unknown-freebsd
x86_64-unknown-linux-gnuToolchainy zabírají 1.6 GB.
Podle mě je problém spíš jinde, k těm targetům je potřeba přidat linkery a další případné potřebné příslušenství, protože cargo build to zázračně sám nevyřeší. Zde bod pro Go, jestliže to zvládá takhle jednoduše.
-
To je pravda.
Treba si však dať pozor, cross compiler nemusí vygenerovať rovnakú binárku ako natívny. Mal som skúsenosť, že cross-compiler (host=darwin-x86-64;target=linux-x86-64) mi generoval kompletne statické binárky a natívny linux-x86-64 bol dynamicky linkovaný voči glibc (teda s nimi fungoval nsswitch).
-
přesně jak píše Cabrón, různé kombinace OS, instrukčních sad jsou v rustu dost těžkotonážní a znamená to dost práce, bug fixing a není to levou zadní (tím nechci pomlouvat rust, jen tohle mu teď tak dobře nejde). Naopak v go to jde naprosto bez problémů a to se mi líbí, nemusím to moc řešit a jsi schopný udělat poměrně rychle jednoduchý nástroj, který běží všude.
-
v go dělám taky jen okrajově, primárně teď python/erlang/rust a právě proto vidím, že v go jdou některé věci snadněji. Nedávno jsme chystali tenký nástroj pro monitoring/reporting pro freebsd/armv6, v rustu se nám to nepovedlo uvést do funkčního stavu, v go to bylo skoro na počkání.
Potkávám poslední dobou právě dost nástrojů pro OS, které jsou napsané v go a dostupné na všech možných platformách. Rust mě technologicky zajímá od počátku, ale když vidím, jak jde něco snadno dělat v go nebo teď nově jak na to přistupuje zig, řikám si, že by rust si zasloužil také více té UX a některé procesy zjednodušit.
