Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

Rust och dependencies

1
Skriv svar
Permalänk
Medlem ★
●

Rust och dependencies

Jag vet inte hur många det är här som har tittat något på Rust?

Har lagt lite tid på sistone på att bekanta mig med det, än så länge på en väldigt grundläggande nivå. Ett väldigt trevligt språk (så länge man inte försöker göra något som Rust inte gillar, tänk inte ens tanken att modifiera arrayer i nästlade loopar!), men en sak jag reagerar på är mängden beroenden man får så fort man tar in någon extern crate, och att ingen riktigt verkar reagera på det.

Du vill ha slumptal? Lägg till rand och få 5 andra crates på köpet.
Du vill ha hjälp att hantera kommandoraden? Lägg till clap och få 9 andra crates på köpet.
Du vill göra ett http-anrop? Lägg till ureq, och få 29 andra crates på köpet.
Du vill rita lite på en canvas? Lägg till ggez och få 211 (!) andra crates på köpet.

När jag har kodat i lågnivåspråk (främst C) så är jag van vid att varje bibliotek man drar in är efter noga övervägande. Framförallt när man håller på med embedded, som ju ändå verkar vara lite av ett fokus för Rust (?).

Är jag gammal och tråkig och det är såhär världen ser ut nu? Eller använder jag Rust fel?

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Nu kan jag inget om Rust men jag känner igen det från .NET Core. Före .NET Core låg väldigt mycket i basramverket. Var det redan installerat (~200 MB) blev programmen väldigt små. Men de gick ju inte att köra utan att installera basramverket. När uppdatering till basramverket gjordes påverkades alla .NET-program på datorn. Med andra ord blev det inte så många uppdateringar för den som brydde sig om driftsäkerhet.

I och med .NET Core ligger allt i NuGet-paket (verkar motsvara crates). Vill man göra något litet (t.ex. för embedded) så behövs förmodligen bara ett NuGet-paket för att utnyttja hårdvaran i den micro-kontroller man vill använda. Vill man göra en webservice som kör på Windows eller Linux blir det sanslöst många beroenden. Med andra ord fungerar denna modell för både embedded och "stora" program.

För den som utvecklar ramverket/en blir det mycket lättare. De kan köra på i full fart och lägga till funktioner och göra uppdateringar. Olika team kan jobba på olika paket oberoende av varandra och releasa när de själva vill. Är du som utvecklare (eller dina kunder) orolig för att något kan sluta fungera med uppdateringarna kan du ligga kvar på gamla versioner (så länge du håller koll på säkerhetsuppdateringar).

Tror alla små paket i första hand är ett sätt att kunna jobba snabbare med flera utvecklare. Alltså löser man ett organisatoriskt problem, men gör det svårare för slutanvändarna som verkligen vill ha koll. Den "gamla" modellen passade bra för stora företag med hierarkisk struktur och få konkurrenter. Den "nya" modellen passar bra för open source och när man vill konkurrera med små lättrörliga företag och open source-projekt som snabbt gör nya saker.

Visa signatur

Min dator: Intel i7 2600K@4.5GHz // 8GB RAM // GTX 780 | Frugans: Intel i7-6700K // 16GB RAM // GTX 1080

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag antar att crates är en mer uppdelad hierarki av bibliotek än man kanske är van vid. Det ger åtminstone möjlighet att referera till färre och mindre bibliotek för enklare saker.

Om vi jämför med C# och jag inkluderar System.Data.SqlClient så ser det ju vackert ut att jag bara har "ett" beroende men motsvarigheten i Rust kanske är 37st crates.

Min poäng är att just antalet crates kanske bara är ett resultat av en finare uppdelning. Fler beroenden behöver ju inte betyda att beroendet är starkare resonerar jag.

Skriver jag som inte har någon erfarenhet av Rust

Visa signatur

Ryzen 7 7800X3D | ASUS TUF Gaming B650-Plus WIFI | Kingston 32GB (2x16GB) DDR5 6GT/s CL30 FURY Beast | Kingston Fury Renegade M.2 NVMe SSD Gen 4 2TB | MSI RTX 4060 8GB | Fractal Design Define S | MSI MPG A850G 850W | Thermalright Phantom Spirit 120 SE | Windows 11 Pro | AOC 27" AGON AG276QZD2 OLED QHD 240 Hz

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av jaqob:

Är jag gammal och tråkig och det är såhär världen ser ut nu? Eller använder jag Rust fel?

Gå till inlägget

Nej, dependency injections visade ju sig vara ett stort problem i node.js men det verkar inte bli bättre...
För att använda inom jobbets nätverk så hade jag föredragit mer utvecklade proxys för att kontrollera vad som egentligen används eller bara kunna kompilera utan att gå förbi brandväggen. (Nu talar jag om min erfarenhet av go men stötte på samma problem.)

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Är det inte så att rand i sin tur är byggd utav andra byggstenar?

Jag antar att du kan skriva allt från scratch och välja själv vad du vill inkludera.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av ojz0r:

Är det inte så att rand i sin tur är byggd utav andra byggstenar?

Jag antar att du kan skriva allt från scratch och välja själv vad du vill inkludera.

Gå till inlägget

Jo, jag förstår att jag får in beroendena för att paketen jag behöver i sin tur har beroenden

Men problemet är att om jag i min bransch skulle använda Rust så förväntas jag ha full koll på alla paket jag använder, analysera säkerhets risker, utvärdera licenser och så vidare. Om det finns hundratals beroenden, som dessutom ofta ändras, så är det i praktiken omöjligt. Vilket i sig nog är ett ganska stort hinder för Rust.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Vad är din bransch mer specifikt? Säkerhetsrelaterat?
Kanske börjar bli dags isf att ta mer betalt för projekten oavsett om det är inhouse eller externt.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Jag jobbar inte i Rust men andra språk som lider av samma problem. Vi använder en dependency scanner (Snyk) som körs vid varje pull request. Det fungerar bra och vi får direkt reda på när något beroende behöver uppdateras eller bytas ut/implementeras in-house.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av monocles:

Jag jobbar inte i Rust men andra språk som lider av samma problem. Vi använder en dependency scanner (Snyk) som körs vid varje pull request. Det fungerar bra och vi får direkt reda på när något beroende behöver uppdateras eller bytas ut/implementeras in-house.

Gå till inlägget

Intressant tjänst, den ska jag kolla lite närmre på.

Skrivet av ojz0r:

Vad är din bransch mer specifikt? Säkerhetsrelaterat?
Kanske börjar bli dags isf att ta mer betalt för projekten oavsett om det är inhouse eller externt.

Gå till inlägget

Jag jobbar med telekom, på Sveriges nog största mjukvaruföretag, så prissättningen är nog noga övervägd, även om det är en lång och intressant diskussion i sig. Ska dock vara tydlig med att Rust är något jag leker med privat, och som absolut inte har med jobbet att göra, men jag har så klart funderat lite på hur man skulle kunna använda det även professionellt. Och verkligheten då är att man i så fall måste göra en ganska seriös analys av varje beroende man tar in, för att förstå exakt hur produkten påverkas, och vad som gäller legalt, och då skulle sättet Rust (egentligen Cargo) hanterar beroenden nog helt enkelt inte fungera.

Men, jag har inte provat Rust på något embedded-system ännu, så det får nog bli nästa steg.

Senast redigerat
Redigera
Citera flera Citera
Permalänk
Medlem
●

Jag skulle nog säga cratesen i rust är mer specifika än vad de är i andra språk som jag jobbat i. Jag menar i C++ så drar man in boost och får nästan allt i hela världen. Det gör det dock lite besvärligt när det kommer till att hålla koll på CVEer och licenser. Men när det kommer till licenser så brukar varje crate vara noga med vilka dependencies de drar in så att de kan fortsätta använda den licenser de valt.

Redigera
Citera flera Citera
1
Skriv svar