mboost-dp1
C vs Rust
Interessant artikel. Tak for link.
Min umiddelbare reaktion er at mens Rust helt sikkert er det moderne alternativ med advancerede sikkerhedsfeatures, så er C stadig the king of keeping it simple.
Man kan læse og forstå C koden og makroerne i sin helhed på ca. 10 sekunder. Og da makroerne har masker er det hele forholdsvist sikker og robust. Og effektivt.
Rust koden derimod involverer mange kryptiske definitioner. Det giver sikkert god mening det hele, men det er altså en anden learning curve. Og den endelige register definition er bestemt lækker og læsbar, men den lugter af at der sker en masse "deep magic" skjult under overfladen. Noget som C udviklere afskyr :)
Min umiddelbare reaktion er at mens Rust helt sikkert er det moderne alternativ med advancerede sikkerhedsfeatures, så er C stadig the king of keeping it simple.
Man kan læse og forstå C koden og makroerne i sin helhed på ca. 10 sekunder. Og da makroerne har masker er det hele forholdsvist sikker og robust. Og effektivt.
Rust koden derimod involverer mange kryptiske definitioner. Det giver sikkert god mening det hele, men det er altså en anden learning curve. Og den endelige register definition er bestemt lækker og læsbar, men den lugter af at der sker en masse "deep magic" skjult under overfladen. Noget som C udviklere afskyr :)
arne_v (3) skrev:
Det er en generel tendens at sprog bliver mere og mere komplekse.
Det er nemt at lave fejl med C pointere.
Men konceptet er simpelt og nemt at forstå.
Prøv at forklare hvad covariante/contravriante generiske typer er og hvorfor reglerne er som de er i et af de nyere sprog. Håbløst.
#5 Ja. C udmærker sig ved at være et tyndt lag oven på assembler. Men der stopper fordelene dog også :) Rust er bare mere advanceret og det er jo prisen der skal betales for fordelene.
Der er nogle ret formidable successhistorier derude, f.eks. https://www.rust-lang.org/static/pdfs/Rust-Tilde-W... hvor de med rust har minimeret resourceforbrug og aldrig er stødt på en segfault i modsætning til deres eksperimenter med C/C++.
fra sidst i pdffen:
Damn... hvem regner Java's (og lignende sprog's) resourcespild om til spildt energi og CO2 udslip ;)
Der er nogle ret formidable successhistorier derude, f.eks. https://www.rust-lang.org/static/pdfs/Rust-Tilde-W... hvor de med rust har minimeret resourceforbrug og aldrig er stødt på en segfault i modsætning til deres eksperimenter med C/C++.
fra sidst i pdffen:
(...) have begun rewriting the data collection and processing server application from Java to Rust. Rust’s smaller memory footprint was immediately noticeable; while the Java server could use up to 5GB of RAM, the comparable Rust server only used 50MB.
Damn... hvem regner Java's (og lignende sprog's) resourcespild om til spildt energi og CO2 udslip ;)
#7
Den sidste hænger lidt i luften.
Java allokerer temmeligt meget memory for at få environment op at køre. Hele JVM, loaded byte code, native code from JIT compilation etc.. De første 150 MB er brugt inden den egentlige udførsel er startet.
Men begynder vi at tale data strukturer så fylder data jo nu engang hvad data fylder. 10 million 32 bit integers fylder 40 MB uanset teknologi.
Der er enkelte undtagelser hvor data i Java fylder mere. ArrayList<Integer> er f.eks. slem - en sådan med 10 millioner elementer er ikke backet af et int array med 10 millioner elementer, men af et pointer array med 10 millioner elementer og så 10 millioner objekter.
Men medmindre man har ramt et af de specielle tilfælde så bør der ikke være stor forskel på størrelse af data strukturer.
Måske har de brugt en fundamental anderledes data struktur i Rust end i Java.
Eller så har de bare givet Java det memory. Java bruger garbage collection, men Java GC'er ikke hvis der ikke er behove for det. Så giver man Java et antal GB memory (command line option), så vil Java bruge det hele inden den begynder at GC'e.
Den sidste hænger lidt i luften.
Java allokerer temmeligt meget memory for at få environment op at køre. Hele JVM, loaded byte code, native code from JIT compilation etc.. De første 150 MB er brugt inden den egentlige udførsel er startet.
Men begynder vi at tale data strukturer så fylder data jo nu engang hvad data fylder. 10 million 32 bit integers fylder 40 MB uanset teknologi.
Der er enkelte undtagelser hvor data i Java fylder mere. ArrayList<Integer> er f.eks. slem - en sådan med 10 millioner elementer er ikke backet af et int array med 10 millioner elementer, men af et pointer array med 10 millioner elementer og så 10 millioner objekter.
Men medmindre man har ramt et af de specielle tilfælde så bør der ikke være stor forskel på størrelse af data strukturer.
Måske har de brugt en fundamental anderledes data struktur i Rust end i Java.
Eller så har de bare givet Java det memory. Java bruger garbage collection, men Java GC'er ikke hvis der ikke er behove for det. Så giver man Java et antal GB memory (command line option), så vil Java bruge det hele inden den begynder at GC'e.
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Tagwall
Gå til bund