Ontwikkelaars van Git overwegen verplichte ondersteuning voor Rust

De ontwikkelaars van het decentrale versiebeheersysteem Git overwegen ondersteuning voor Rust verplicht te maken. Een van de hoofdontwikkelaars overweegt Rust aan de huidige C-ondersteuning toe te voegen, wat zou kunnen betekenen dat Git op minder systemen zou werken.

Ontwikkelaar Patrick Steinhardt schrijft in een maillijst dat hij wil experimenteren met de toevoeging van Rust in de corecode van Git. Daarvoor heeft Steinhardt een kleine, op zichzelf niet heel belangrijke patch doorgevoerd waarbij een specifiek subsysteem in C wordt omgebouwd naar Rust. "Daarmee kunnen we verifiëren dat de conversie van C naar Rust werkt zoals verwacht en kunnen we wat uitproberen met tools", schrijft Steinhardt.

Op termijn, zegt Steinhardt, willen de ontwikkelaars drie zaken onderzoeken. In de eerste plaats willen ze experimenteren met Rust-ondersteuning en de juiste buildinfrastructuur opzetten. Daarnaast willen ze met het experiment ontwikkelaars de tijd geven om te wennen aan nieuwe verplichtingen die de Rust-ondersteuning met zich meebrengt; Rust werkt bijvoorbeeld niet op alle systemen en platformen.

Het derde doel is volgens Steinhardt om aan te kondigen dat Git 3.0 Rust verplicht moet ondersteunen. Vooralsnog is dat niet aan de orde; Git zit momenteel op versie 2.51. Git heeft al langer optionele ondersteuning voor Rust, maar nog geen verplichte.

Reacties (98)

[arendvw]

Voor de duidelijkheid: Rust is alleen vereist om git vanaf code te compileren. Voor de ontwikkelaars van git en systemen die git vanaf source bouwen is dit nodig.

Maar voor 99.9% van de overige ontwikkelaars (die niet aan git, maar met git werken) zal gewoon een binary genoeg zijn, en hiervoor zijn géén rust tools vereist, zoals dat ook voor bijvoorbeeld firefox niet nodig is.

De platformen waar misschien problemen verwacht worden zijn de platformen waar rust niet geautomatiseerd bij elke build getest wordt. Meer uitleg over rust support is hier

[Reactie gewijzigd door arendvw op 21 september 2025 19:06]

[MarcoC]

Inderdaad, dit lijkt mij wel essentieel om te benoemen in het artikel.

[ZinloosGeweldig]

Correct me if I'm wrong, maar het gaat er toch ook om dat er een rust compiler is die het betreffende platform kan targeten? Wordt anders lastig een binary voor dat platform te bouwen die de gebruikers kunnen gebruiken.

[Piemol]

En wat is op langere termijn het doel van Rust binnen git? Wat kan daarmee wat nu niet kan?

[bwerg]

Rust is inherent memory safe terwijl C notair memory unsafe is. Daar merk je als eindgebruiker niks van, totdat een programmeerfoutje voor bugs zorgt. In het ergste geval security-bugs. Bepaalde klassen van security-bugs komen in memory-safe talen gewoon niet voor omdat de taal/compiler die voorkomt.

Al met al begint C steeds meer een gedateerde taal te worden. Voor veel toepassingen zijn er over de jaren gewoon betere alternatieven ontwikkeld.

[ShadowBumble]

Rust is inherent memory safe terwijl C notair memory unsafe is. Daar merk je als eindgebruiker niks van, totdat een programmeerfoutje voor bugs zorgt. In het ergste geval security-bugs. Bepaalde klassen van security-bugs komen in memory-safe talen gewoon niet voor omdat de taal/compiler die voorkomt.

Al met al begint C steeds meer een gedateerde taal te worden. Voor veel toepassingen zijn er over de jaren gewoon betere alternatieven ontwikkeld.

Als toevoeging:

Het programmeren in een "Memory Safe" taal zoals Rust is geen garantie dat er "unsafe" code blocks in zitten en bij rust doel ik dan specifiek op code blocks buiten je "unsafe parameter" code block. Het enige wat de compiler voorkomt is dat je code gecontroleerd wordt op hoe je geheugen afhandeling is (automatische cleanup, garbage disposal etc van je variablen nadat ze gebruik en weer vrij gegeven worden) en bij moderne talen zoals Rust maar ook C# etc wordt dat al gedaan tijdens compilen en daardoor grijpt je compiler in, echter in C moet je het geheugen beheer als programmeur volledig zelf doen.

Een programeer fout kan zowel in een "memory safe" als "memory unsafe" taal gewoon voor risico's zorgen. Een Buffer overflow, use-after-free, heap corruption bugs worden namelijk niet voorkomen in "Memory Safe" talen maar door simpel weg verkeerde afhandeling in je code. Dit worden ook wel "Logic Bugs" genoemd en laten die zogenoemde "Logic Bugs" nu een relatief groot deel van de in "Memory Bugs" geklassificeerde lijst in CISA's KEV zijn van de afgelopen 5 jaar (schommelend tussen de 45% en de 25% per jaar).

[bwerg]

Een Buffer overflow, use-after-free, heap corruption bugs worden namelijk niet voorkomen in "Memory Safe" talen

Ja, dat voorkomt een memory safe taal wel. Dat is nou net de hele definitie van memory safety, en met die definitie is wikipedia het eens. Die noemt expliciet die categorieën als memory safety bugs. Net als dat een type-safe taal typerings-bugs voorkomt.

In memory-managed talen als java heb je bijvoorbeeld helemaal geen controle over de stack of over memory-(de)allocatie, precies om de programmeur de mogelijkheid te ontnemen om dit soort fouten te maken. Rust bereikt dat op een andere manier.

Ja, een taal kan toelaten dat je ergens wat unsafe/native code in je verder memory-safe programma stopt, dat is dan een expliciet gekozen niet-memory-safe uitzondering (en als je strikt bent, dan is de taal dus niet memory-safe). En je kan natuurlijk linken aan externe libraries die misschien niet memory safe zijn, dat ligt aan hoe die geprogrammeerd zijn, maar dan zit die bug in die externe library, niet in jouw programma. En de compiler of runtime kan zelf natuurlijk ook bugs bevatten die memory safety breekt, maar dat is natuurlijk geen eigenschap van de taal op zich.

[Reactie gewijzigd door bwerg op 21 september 2025 14:45]

[GertMenkel]

In projecten waar C met Rust gemixt wordt, is de geheugenveiligheid maar beperkt bruikbaar. De bestaande C-code werkt vaak met struct pointers en globale constanten die veel bijgewerkt worden, en hoewel je een interfacelaag kunt maken om daar veilig bij te komen levert dat vaak technische uitdagingen en complexe code op.

Zie bijvoorbeeld de code die bij deze testballon hoort. Alle code is unsafe. De geheugenbescherming van Rust doet hier niets.

Nu heeft Rust ook andere voordelen boven C. Programmeurs zullen wellicht bekend zijn met "undefined behaviour" dat je in C heel eenvoudig kunt bereiken, waar Rust een stuk strikter is in wat de compiler toestaat.

Ook kun je naarmate meer code in Rust geschreven wordt, meer veiligheidsfuncties van Rust gebruiken, maar dat zal in bestaande projecten jaren gaan duren.

[Stetsed]

Ik denk dat je hier wat duidelijker moet zijn. Rust unsafe blocks laat je gebruik maken van unsafe operations, did zijn operations waar de reguliere memory guarantees die rust geeft niet kunnen bestaan. Wat je hier dus moet doen is ZELF deze garanties geven. Hierdoor heb je vaak bindings tussen rust en de C code die worden gebruikt, waarin deze checks worden gedaan. Een package voorbeeld kan bijvoorbeeld rustix zijn.

Wat je doet wanneer je een unsafe block gebruikt is je verteld de Rust Compiler "De code die hierin staat stel ik dat deze aan jou benodigheden voldoen". Dit betekent echter niet dat de rust compiler niks doet, van veel dingen kan je nog steeds niet, echter de GARANTIE dat je het niet kan doen is er niet meer, want de rust compiler gaat er van uit dat jij dit controleert.

Ik heb bijvoorbeeld een tijdje terug voor een klein project tijdens school een rust binding gebruikt. Een van de dingen hier was dat ik een struct aan de onderliggende C code gaf, en dat ik deze dan terugkreeg met de verwerkingen. Maar dit wou ik niet elke keer in een unsafe block doen, dus wat ik uiteindelijk deed was ik maakte er een functie van. Hierin nam ik de lijst van garanties die nodig waren, en controleerde ik of ze waren voldaan. Het voornamelijk probleem is als er iets is aan de onderliggende code waardoor jij deze garanties niet kan geven, en dan is er een probleem.

Bijvoorbeeld had ik in een ander project gebruik van ffmpeg-rs, deze had een onderliggend probleem in de FFI omdat het een bepaalde pointer niet controleerde of hij NULL was, en omdat dit een unsafe block was vertrouwde de rust compiler dat dit niet mogelijk was, waardoor met gebruik van die functie er een crash was door die null-pointer(Of om precieser te zijn, het veroorzaakte undefined behaviour).

[Reactie gewijzigd door Stetsed op 21 september 2025 19:34]

[ClementL]

Een Buffer overflow, use-after-free, heap corruption bugs worden namelijk niet voorkomen in "Memory Safe" talen maar door simpel weg verkeerde afhandeling in je code.

Nou weet ik niet helemaal zeker of ik je punt begrijp, want het verhaal komt me eerlijk te zijn een beetje warrig over, maar dit zijn precies de problemen die Rust voorkomt. Het ownership en borrow systeem met lifetime checker voorkomen use-after-free: een reference ("borrow") kan niet langer leven dan de owner van de variabele, en dus het geheugen ook niet benaderen nadat het vrijgegeven is. Het gebruik van array bound checks en veelvuldig gebruik van iterators voorkomen buffer overflows. Heap corruption is normaal het gevolg van de eerdere problemen en data races, die ook onmogelijk zijn in Rust.

De genoemde 25-45% logic bugs in memory bugs bevestigt juist het voordeel van Rust - het elimineert de overige 55-75% van niet-logische geheugenbugs die wél door het taalontwerp worden voorkomen.

[Djerro123]

Logic bugs worden niet voorkomen nee, maar use-after-free, buffer overflow en heap corruption bugs zijn nou net géén Logic bugs.

Dit zijn juist de bugs die Rust voorkomt. Tenzij je unsafe code gebruikt/nodig hebt, dan neem je expliciet de verantwoordelijkheid voor de soundness van je code. Maar in safe Rust zou het onmogelijk moeten zijn om UB te hebben.

[Blokker_1999]

En toch blijft C een belangrijke taal en zien we dat ook Rust niet zonder problemen is zoals we vorige maand nog hebben gezien met een ernstige bug in de Windows Kernel in een deel dat net in Rust was geschreven. Een taal die je beter beschermd betekend niet dat je niet moet opletten met wat je schrijft en hoe je het schrijft.

[Chiwn]

Dat is helemaal waar, Rust maakt niet automagisch je code bug-vrij. Dat neemt niet weg dat Rust een erg geschikte oplossing is om memory bugs te voorkomen, die er in C doorheen hadden kunnen glippen.

[Navi]

M.a.w het is een skill issue en rust voegt functioneel niets toe 😜

[StijnArnauts]

Een skill issue is nog steeds een issue. In een wereld waarin elke ontwikkelaar grondige kennis en jarenlange ervaring heeft over alle mogelijke manieren waarop je in C++ memory leaks kan krijgen en je deze kan voorkomen, én nooit een mindere dag heeft waarin de concentratie net iets lager ligt, voegt Rust inderdaad niets toe. Dat is echter niet de wereld waarin we leven.

[bwerg]

Zelfs al heb je kennis, ervaring en concentratie, dan kan tooling nog steeds allerlei zaken veel effectiever en beter dan dat een mens kan. Met de hand problemen oplossen die een tool sneller en effectiever kan is gewoon tijd en geld weggooien. En dan heb je het nog niet over de impact als er toch ergens een foutje insluipt.

[Stetsed]

Dit argument zie ik altijd bij discussies tussen C en andere talen zoals Rust. Nee het maakt je programma niet compleet veilig, maar betekent dat we gewoon niet moeten boeien? "Waarom heb we riemen want als iedereen gewoon veilig rijd hebben we toch geen problemen".

Het is niet alsof deze bugs niet gebeuren, toevoegend op wat @StijnArnauts zegt zelfs wanneer concentratie niet minder is, kan het gewoon zijn dat er een interactie is tussen componenten die niet verwacht is er een probleem komt. En deze reactie is er zoiezo well ergens, we zien dit ook gewoon binnen groote bedrijven en projecten zoals de Linux Kernel, waar een substantieel percentage van bugs memory gebaseerd zijn.

Volgens Microsoft in 2019 was het bijvoorbeeld 70% van bugs, hebben microsoft engineers gewoon zoveel skill issue?[1]

[1]. https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/#ftag=RSSbaffb68

[Reactie gewijzigd door Stetsed op 21 september 2025 19:41]

[Remzi1993]

Precies, dit is een van de redenen waarom ik de discussie niet aan ga met mensen die als een schaap "skill issue" napraten. Een dom en zwak argument. Als het een skill issue zou zijn dan was niet de hele industrie vol met memory safety bugs. Computers zijn gewoon goed met het nalopen en berekenen van dingen, wij als programmeurs moeten ons richten op de logic, en niet memory management laat dat over aan de computer.

Er zijn al genoeg logic issues in software.

[uiltje]

Precies. Het is hetzelfde als bedenken dat we de user moeten laten opdraaien voor security problemen door ze te trainen. Zelfs als het theoretisch klopt vecht je dan een verloren oorlog. En ik ken genoeg "C en C++ experts" om te weten dat het praktisch gezien onmogelijk is om alles veilig te doen in zo'n taal. En dat is dan nog zonder "native" bibliotheken gerekend.

[Remzi1993]

Precies haha 😂 We zitten op 1 lijn, jammer dat niet iedereen zo praktisch en pragmatisch denkt. Logica is vaak ver te zoeken helaas.

[vgroenewold]

Skill issues zijn normaal, zeker als je onder druk vanalles aan code eruit moet gooien. Om simpelweg dat voor te zijn is een taal wat sommige zaken niet mogelijk maakt, handig. Betekent totaal niet dat je er verder meer aan hebt nee.

[downtime]

Die auto waar Red Bull het zo moeilijk mee heeft is ook een skill issue. Max presteert redelijk en zijn teamgenoot is in de meeste races in geen velden of wegen te bekennen.

Dan kun je wel zeggen dat het een skill issue is maar daardoor gaat zijn teamgenoot niet beter presteren. Ik denk dat we het snel eens kunnen worden dat een betere auto meer problemen oplost dan alles afdoen als een skill issue.

[Sfynx]

Een elektrische zaag voegt functioneel ook niets toe in vergelijking met een handzaag, maar toch vinden we het erg handig om 1 of andere reden. Dit is hetzelfde, het stelt je in staat om sneller en foutlozer te werken.

[Reactie gewijzigd door Sfynx op 21 september 2025 16:11]

[gaskabouter]

Goed gereedschap maakt geen goede vakman. Maar het maakt het hem wel makkelijker. En een amateur wordt geen vakman met goed gereedschap, maar maakt het hem wel makkelijker

[bwerg]

100% correctheid gaat geen enkele programmeertaal garanderen, maar het is gewoon zonde op nog klasses van bugs in je software te hebben die een moderne taal/compiler gewoon wel 100% kan voorkomen.

Zaken als stack overflows of te vroeg vrijgeven van geheugen kan al snel ernstige en onvoorspelbare gevolgen hebben, en daar hoef je met een moderne taal gewoon helemaal niet meer over na te denken.

[Reactie gewijzigd door bwerg op 21 september 2025 13:18]

[Powerblast]

Rust is veiliger maar of het in deze use case ook voordelen zou opleveren weet ik niet. Is source control echt performance kritisch? Dat is voor mij nog altijd de hoofdreden om Rust te kiezen. Memory safety is ook een sterk punt van Rust maar dat kun je op andere manieren ook nog krijgen. Het is de combinatie van memory safety met performance dat Rust redelijk uniek maakt. Je betaalt echter wel zeer hard in learning curve en vage syntax met momenten .

Ik vermoed dat Git in de tijd in C geschreven is omdat Torvalds dit gewoon goed kende en het toen de main language was. Of je met Rust hier nu voordelen uit zou halen betwijfel ik echter. Als puur het doel geen of minder memory bugs is zou je hier denk ik ook support voor C# ofzo kunnen toevoegen.

[Reactie gewijzigd door Powerblast op 21 september 2025 12:36]

[bwerg]

Met talen als C# of java heb je een extra runtime-omgeving nodig, en heb je een complete garbage collector aan boord. Natuurlijk, alles kan, en je kan die hele runtime ook in je gecompileerde executable meebakken, maar het is wel even een ander abstractieniveau en een heel ander niveau van geheugengebruik. Voor je dikke developer-bak niet zo'n probleem, maar op minder krachtige hardware of op minder gangbare OS'en is dat toch jammer en misschien ook minder portable.

In dat opzicht ligt Rust veel dichter bij C.

En ja, de leercurve... ik zie het maar zo: het denkwerk om iets bug-vrij te krijgen moet je toch doen, bij een veiligere taal moet je ook even de moeite nemen om dat denkwerk aan de compiler over te brengen, met bijbehorende syntax van dien. Of je doet dat denkwerk niet, en dan kom je er met "hacks" inderdaad veel makkelijker doorheen, maar op de lange termijn wordt je software daar niet beter op.

[Powerblast]

En ja, de leercurve... ik zie het maar zo: het denkwerk om iets bug-vrij te krijgen moet je toch doen, bij een veiligere taal moet je ook even de moeite nemen om dat denkwerk aan de compiler over te brengen, met bijbehorende syntax van dien. Of je doet dat denkwerk niet, en dan kom je er met "hacks" inderdaad veel makkelijker doorheen, maar op de lange termijn wordt je software daar niet beter op.

Deel zeker die mening hoor. Ik wou alleen opmerken dat performance en memory safety op zich niet uniek zijn aan Rust. Het is de combinatie van de twee die het uniek en interessant maakt. Zoals je zegt, je moet de compiler veel meer hints geven dan bij andere talen, wat vooral voor mensen die van high level languages komen een serieus struikelblok kan zijn.

Ik ben er zelf nog altijd niet goed genoeg in om wat te kunnen zeggen over Rust in the long run of bij heel grote projecten. Vermoedelijk eens je er volledig mee weg bent is het zo productief als andere talen. Merk alleen dat als ik wat snel in elkaar wil zetten om te zien of het idee werkt, dit niet zo vlot gaat in Rust dan bijvoorbeeld in C#/Java. Volledig normaal natuurlijk want daar is de taal ook gewoon niet voor bedoelt.

[ari3]

Als je in Java een commandline tool bouwt krijg je inderdaad vanzelf een afhankelijkheid op de runtime-omgeving van Java. Omdat het opstarten van de runtime-omgeving best lang duurt is het inbouwen van de runtime in de executable geen goed idee.

Java commandline tools als Maven en Gradle lossen dit op door (per terminal) de java runtime eenmalig in de achtergrond te starten waardoor iedere aanroep op de commandline gebruik kan maken van dezelfde, reeds opgewarmde, runtime-omgeving.

[Goderic]

Is source control echt performance kritisch?

Jij hebt nog nooit met SVN gewerkt zeker? Source control is zeer performance kritisch

[Navi]

Niets mis met een goede SVN setup 😀

Jarenlang gedaan, nu al jaren Git uiteraard en hoewel en hier en daar wat voordelen zijn, zijn er ook een hoop nadelen zoals hogere complexiteit, geen rechten (iemand altijd hele repo access geven), etc.

En ja, ook snel even feature brachen en terugmergen kan gewoon in SVN.

En ook Git geeft gewoon een mergeconflict als je op dezelfde regel hebt zitten rommelen.

[Reactie gewijzigd door Navi op 21 september 2025 13:25]

[Goderic]

Met apt-get remove subversion is inderdaad niets mis

En ja, ook snel even feature brachen en terugmergen kan gewoon in SVN.

Branches zijn een hack in SVN en zijn veeel trager dan in git. In een niet super groot project waar op heb gewerkt duurde een branch maken letterlijk ettelijke uren.

[Reactie gewijzigd door Goderic op 21 september 2025 13:30]

[Navi]

Ik herken dat echt totaal niet, jaren gewerkt in een flinke SVN repo met zo'n 120.000 files en branchen was in 1 tot 5 sec gebeurd, praktisch instant.
Ook commits van 3.000 files ging prima als bv een groot source pakket bijgewerkt werd.

Enkel een volledige checkout duurde misschien 30 sec, maar goed dat doe je niet zo vaak.

Uren klinkt alsof er gewoon ergens een probleem in de server zat.

Nog een toevoeging, mogelijk heeft de opkomst van de SSD ervoor gezorgd dat het allemaal een stuk sneller verliep. Het blijven natuurlijk allemaal kleine file acties.

[Reactie gewijzigd door Navi op 21 september 2025 16:24]

[Powerblast]

Ja hoor, ik heb 20j geleden even met SVN gewerkt. Vond het persoonlijk niet fijn werken. Weet alleen niet meer of het de performance was die me stoorde. Sinds dan eigenlijk alleen met git en mercurial.

[84hannes]

Performance was een van de primaire redenen voor Linux om aan Git te beginnen:

He cited an example of a source-control management system needing 30 seconds to apply a patch and update all associated metadata, and noted that this would not scale to the needs of Linux kernel development, where synchronizing with fellow maintainers could require 250 such actions at once.

[Argantonis]

Tja maar dan gaat het om slecht opgezette software met allerlei dingen erin gehangen, maar niet omdat de performance door de programmeertaal zo slecht is, of dat dat een groot verschil zou maken tussen C en bijv. C#

[Jeoh]

Op de schaal waarop Git gebruikt wordt zijn besparingen van milliseconden vele mensenuren waard.

[Djerro123]

Performance zou nou juist een van de dingen zijn die niet hoog op mijn lijstje staat van voordelen tov C. Soms kan het performantie uitpakken, maar vaak ook helemaal niet. Zeker als je clang gebruikt, want dan compileer je feitelijk beide uiteindelijk met LLVM.

C# is afaik een runtime based language die JIT compileert tot machine code. Daarmee ga je nooit de performance benaderen van Rust of C, simpelweg omdat er on-runtime nog een vertaalslag tussen zit. Java en # zijn geen system languages zoals C en Rust dat zijn.

(er staat mij iets vaags bij dat er wel mogelijkheden zijn om C# te compileren naar machine code, maar weet het niet zeker. Is dat nog een ding geworden?)

[cmpxchg]

Rust is inherent memory safe terwijl C notair memory unsafe is. Daar merk je als eindgebruiker niks van, totdat een programmeerfoutje voor bugs zorgt. In het ergste geval security-bugs. Bepaalde klassen van security-bugs komen in memory-safe talen gewoon niet voor omdat de taal/compiler die voorkomt.

Al met al begint C steeds meer een gedateerde taal te worden. Voor veel toepassingen zijn er over de jaren gewoon betere alternatieven ontwikkeld.

Er zijn ook zeer ervaren C++ developers die kijken hoe rust 'features' zoals memory safety, naar moderne C++ syntax en C++-compilers gebracht kunnen worden, in een maintable manier, zoals dit voorstel:

https://safecpp.org/draft.html

Noot dat memory safety zowel in Rust al C++ omzeild kan worden. Performance kan ook nog een overweging zijn. Reductie van complexiteit kan ook belangrijk zijn voor meer formele security-analyse.

Eeuwig voordeel van C++ en sommige andere talen is dat je memory copies flink kan reduceren, en er geen beperkingen zijn qua performance-optimisaties op dat vlak.

Met tools als DPDK kun je netwerkkaarten ook direct in userspace-memory laten schrijven en -lezen, waardoor het onderste uit de hardware-kan kan worden gehaald.

Het onderste uit de hardware-kan halen kan economisch het beste uitpakken, powerconsumptie, schaalbaarheid etc. Security, stabiliteit en availability zijn allemaal systeem-level problemen.

Uiteindelijk is software en programmeertalen geen religie/kerk - het is de kunst van het maken van de assembly/machinecode voor de hardware-statemachines, welke eenmalig geimplementeerd zijn in de chips (CPU en GPU etc) die tezamen je computer vormen.

[Reactie gewijzigd door cmpxchg op 21 september 2025 20:35]

[cdwave]

Aangezien de git binaries doorgaans short-lived zijn, is het effect van eventuele memory bugs miniem.

Git commando's worden doorgaans in een process uitgevoerd en daarna eindigt de executable, en daarmee komen alle resources die die geclaimd zou kunnen hebben weer vrij.

[bwerg]

Je vergeet dat die kortdurende commando's een externe SSH-verbinding openen, daarbij credentials kan verwerken, een hele boel data download, je hele folderstructuur waar git op dat moment werkt overhoop gooit, daar weer zooi uitvist, en die het internet opslingert. Tal van plekken waarop bugs corrupte bestanden of security vulnerabilities zou kunnen introduceren. Waarbij git zowel als client als server draait.

[cdwave]

Mooie beschrijving van hoe short-lived niet perse "klein" hoeft te zijn, dank daarvoor.

Git verwerkt gelukkig geen credentials, dat doet SSH. En ook de server eindigt zodra die verbinding dicht gaat.

[bwerg]

Git kan nog steeds met username/password draaien die je gewoon in je configs kan zetten of die je elke keer moet intypen.

Dat is tegenwoordig niet meer aan te raden, maar het kan.

[djwice]

Rust heeft standaard een aantal memory safe features in de taal. Je kunt er makkelijker inherent veilige software mee bouwen.
Terwijl de gecompileerde software typisch even efficiënt werkt als c++.

[Sylph-DS]

In theorie, efficiënter schrijven van code die veilig is en een relatief laag aantal bugs heeft. (in de git codebase).

Of dat praktisch ook zo uitpakt is nogal afhankelijk van de aanpak/uitvoering.

Als gebruiker van git merk je er waarschijnlijk niet veel van.

[foobar79]

Rust is een programmeertaal die “memory safe” is. Onder andere hierdoor is kans op bugs vele malen kleiner in rust code dan in C.

Dit terwijl Rust amper trager is dan C.

[lkruijsw]

Rust is ook gewoon een veel modernere taal. Met dictionaries, arrays die kunnen groeien etc. In C moet je dan je eigen data structuur opzetten. Dat is de ellende van C, dat je dat niet hebt. Ook als je bijvoorbeeld met strings gaat werken die geen vaste lengte hebben. Dat standaard in je taal hebben is van groter gemak dan OO.

[MiesvanderLippe]

Het is fijn om in te ontwikkelen. De tools eromheen zijn mee ontwikkeld met de taal. De taal zelf is zo ingericht dat je minder makkelijk fouten maakt, onder andere door hoe het omgaat met verschillende datatypes. Je kunt de meeste rust projecten compileren en starten door simpelweg cargo run te typen - op elk systeem dat Rust ondersteunt.

[Dirk J]

Iedereen roept hier memory safety maar er is nog een andere, zeer belangrijke reden: het aantrekken van nieuwe maintainers. Rust staat vaak bij bovenaan de lijstjes met meest gewilde programmeertalen (zie bijvoorbeeld de StackOverflow survey). Het zou daarmee dus makkelijker moeten zijn om op termijn een gezonde basis van maintainers te onderhouden.

[TheGhostInc]

Rust werkt bijvoorbeeld niet op alle systemen en platformen.

Dit klinkt meteen alsof er systemen uit worden gesloten, maar als ik ga zoeken waar het niet op draait, dan zit je ondertussen op hardware die 40 jaar oud is of in je oude tandenborstel zit (de nieuwste tandenborstels waarschijnlijk al wel ).

[Goderic]

Het probleem is blijkbaar een niche gesloten systeem, NonStop dat geen documentatie en enkel een C compiler heeft. https://lwn.net/Articles/998115/

Als de gebruikers van die systemen zo graag Git willen moeten ze de verkoper maar overtuigen om een Rust compiler toe te voegen.

[svenk91]

Er is ook een grote kans dat oude git 2.x versies nog lange tojd zullen blijven werken als git 3.0 uit is. Ook nu zorgt het gebruik van oude git versies voornamelijk dat je bepaalde configs niet goed kan gebruiken, maar de kern van git is erg stabiel.

[jeroen3]

Die begrijp ik ook niet helemaal. Want volgens mij is Rust, net als C, een gecompileerde programmeertaal waarbij er geen afhankelijkheden op de host nodig zijn, zoals met .NET of java.
Ik vermoed dat dit eerder een test is voor de onwikkelingsplatformen dan de productie.

[Bedge85]

Het klopt dat Rust een gecompileerde taal is. Na het compileren heb je een binary. De binarys moeten voor een specifiek platform gebouwd worden. Vermoedelijk ondersteunt de Rust compiler minder platformen dan C.

[bwerg]

Aangezien C al een hele tijd meegaat en ook veel gebruikt wordt voor veel low-level/embedded spul zal dat vast het geval zijn. Maar aangezien Rust o.a. naar LLVM compileert heeft het toch een behoorlijk brede en solide ondersteuning voor verschillende platformen.

[jb044]

Dat is een verkeerde voorstelling van zaken: software draait op een OS, dus bij een pre-gecompileerde programmeertaal is er wel ondersteuning voor dat OS nodig, in de zin dat je het kan compileren voor dat OS. .NET of java heeft juist als voordeel dat het in principe in ongewijzigde vorm op meerdere OSen kan draaien, via de OS specifieke runtime inderdaad dan.

[MSalters]

Gecompileerde talen linken een runtime library mee. Daarom heb je ook daar geen OS afhankelijkheid.

[jb044]

Ik zal wel dom zijn maar je moet toch kunnen compileren naar het target OS? Volgens mij is dat de reden dat met rust het nog niet zo breed kan draaien als met C.

offtopic:
Een rust binary is best mooi want die werkt gewoon, maar andersom als je rust source code hebt en er een binary van wilt maken kan het best vervelend worden. Laatst nog gehad met een mooie tool om podman config om te zetten naar quadlets definities, gelukkig heeft rust tooling om eenvoudig een rpm te maken van een project, maar netjes een pakket maken op dezelfde manier als dit op Fedora is gedaan door de rust depencies via het OS beschikbaar te maken was echt 1 grote 'dependency hell' :D

[MSalters]

Je moet compileren naar de target ABI. Die kan fysiek of virtueel zijn.

De Linux kernel zelf is in C en die kan je natuurlijk niet compileren voor een target OS. De target ABI is daar de CPU zelf.

[Bensjero]

.NET en Java hebben zeker wel afhankelijkheden van de host. .NET Runtime wordt/werd meegeleverd met Windows, maar daar ben je echt wel afhankelijk van. Java vergelijkbare situatie.

[djwice]

Precies, die opmerking verbaasde mij ook, ik heb in mijn IT landschap geen systeem waar Rust niet op werkt, het werkt zelfs op de 40+ jaar oude mainframes.
En het werkt ook gewoon in de AWS Lambda omgeving. Sterker nog samen met AWS heb ik https://docs.aws.amazon.c...est/ug/what-is-guard.html vanaf het begin af aan (ruim 5 jaar terug al weer) in Rust gemaakt.
=> https://github.com/aws-cloudformation/cloudformation-guard/

[Reactie gewijzigd door djwice op 21 september 2025 12:32]

[jmvdkolk]

Kan jij mij wijzen naar een site die aangeeft dat Rust op z/OS werkt? Ik neem aan dat dit de officiele documentatie is en daar zie ik het niet: https://doc.rust-lang.org/nightly/rustc/platform-support.html

Ik hoop dat de link hierboven niet klopt, want alles dat geen Tier 1 support heeft is niet echt gesupport. Er is nogal veel dat dan niet echt gesupport is.

Iets heel anders. Als we mainframes 40+ jaar oud noemen, zullen we Windows ook 40+ jaar oud gaan noemen? Voor mij geeft 40+ jaar oud een gevoel van oud of achterhaald zijn. Mainframes worden net zo modern gehouden als Windows, en beide systemen zijn modern.

[djwice]

Gewoon op de site van IBM zelf.

Wij hebben machines waar we de onderdelen 2e hands of ouder van moeten bij kopen. Ja fysiek dus echt 40+.

Een groot deel van de software die er op draait ook. Bijvoorbeeld uitvoer naar matrix printers.

[Reactie gewijzigd door djwice op 21 september 2025 19:26]

[jmvdkolk]

Gewoon op de site van IBM zelf.

Aha, dus geen officiele support maar support door IBM

Wij hebben machines waar we de onderdelen 2e hands of ouder van moeten bij kopen. Ja fysiek dus echt 40+.

Dat is vrij bijzonder in de mainframe wereld. Ik vraag mij of hoeveel andere organisaties er zijn die iets vergelijkbaars doen. Bij mijn weten gebruiken ze in Japan de oudste mainframes, met op dit moment nog een enkele zEC12 in gebruik.

Mainframes zijn heel goed qua backwards compatibility, inclusief nog steeds support voor matrix printers. Kan je iets zeggen over waarom jullie echt die oude hardware behouden?

[djwice]

We hebben onderandere code die gebruik maakt van de overflow aan het einde van een memory bank om zo een jump te besparen.

[jmvdkolk]

Grappig dat dat zo lang kan overleven. Ik zou denken dat de nieuwe processoren zoveel sneller zijn dat het besparen van die jump niet meer relevant is. Maar als je zo specifiek voor een specifieke machine hebt geoptimaliseerd dan zullen er vast meer afhankelijkheden zijn.

[djwice]

Ja, dat is het voornaamste probleem de gene die de code gemaakt hebben zijn al jaren met pensioen en we kunnen het niet riskeren dat een batch niet goed zal lopen.

[theguyofdoom]

Er zijn achter gesloten deuren ongelofelijk veel gare stukjes custom silicon die alleen met een halfbakken vendor-specific C compiler werken omdat ze een of andere instruction set extension hebben ingebouwd.

De taal C is/lijkt ontworpen om zo makkelijk mogelijk een compiler te schrijven, daarom heb je er zoveel van. Rust is geschreven om zo goed mogelijk de programmeur te helpen, maar daarvoor heb je nogal een brute compiler nodig – al is een minstens zo groot probleem dat Google / LLVM (terecht) gewoon niet om gekke targets geven.

[Reactie gewijzigd door theguyofdoom op 22 september 2025 07:38]

[xorpd]

Heb je daar een voorbeeld van, van zo'n stukje custom silicon plus compiler? Ik kan het me namelijk bijna niet voorstellen dat zoiets niet gewoon in gcc kan. En niets houdt je tegen om een klein stukje asm mee te linken of te integreren.

[theguyofdoom]

Dat zijn allemaal klanten onder NDA.

[xorpd]

Je hoeft die klanten ook niet te noemen. Is ook niet interessant. Gaat het om DSPs, encryptiehardware, DMA controllers? Die laatste zijn bij moderne ColdFire CPUs closed source, dat is het enige vergelijkbare wat ik ooit ben tegengekomen.

[Powerblast]

Vraag me persoonlijk ook af of je daar dan wel iets zoals Git nog wel op wil draaien. Stel dat het wel nog zou kunnen omdat Rust het ondersteund. Je zit met dergelijk ancient platformen vrees ik met andere problemen. Daar wil je toch niet nog iets zoals Git op gaan draaien .

[Expresso]

Ik vraag mij af of de verschillende projecten die draaien op obscure platforms dan nog wel verder kunnen met git? Het hoofd natuurlijk niet automatisch zo te zijn dat ze ook op die platforms ontwikkeld worden, maar je weet maar nooit.

[GertMenkel]

Het grootste probleem zijn de platforms met gesloten compilers. Zo is er een merk voor een serverplatform dat alleen een door de fabrikant gemaakte fork van gcc aanbiedt.

Nu kun je met gcc gewoon Rust compilen (gcc's implementatie verifieert veel garanties niet maar de code draait) maar dan zal iemand die compiler voor dat platform moeten bouwen.

Mijns inziens vind ik niet dat git zich door deze platforms zou moeten laten beperken. Voor de Linuxkernel is het lastiger die afweging te maken, maar een platform dat de nieuwste features van git niet ondersteunt omdat de fabrikant hun compiler niet bijwerkt vind ik in de categorie "jammer maar helaas" vallen.

[TheVivaldi]

De vraag is natuurlijk waar je je op richt. Het lijkt mij logisch om je op de meeste gangbare systemen te richten, want dat is waar de grootste groep ontwikkelaars zit. Dan heb je dus Windows, macOS en Linux, en daar werkt Rust uitstekend op. Dan heb je ook nog bijvangst van BSD en Redox OS, waar Rust eveneens op draait en ook wat ontwikkelaars zitten. Denk dat je dan echt wel 98% van de ontwikkelaars te pakken hebt.

[MatiasG]

Rust werkt niet op PowerPC Mac OS X 10.4 en 10.5. Beide worden nog wel gewoon netjes ondersteund door GCC. Ik gebruik nog dagelijks Git op mijn late 2005 Power Mac G5 om software binnen te halen en te compileren. MacPorts maakt hier ook hevig gebruik van.

Ik gebruik de meest recente versie van Git met moderne cURL, OpenSSL en dergelijke. Zie: https://kemonomimi.nl/ppcports/software/git/

[Reactie gewijzigd door MatiasG op 21 september 2025 13:09]

[Arrigi]

Maar kan zo'n systeem niet gewoon linux draaien? Het is een OS dat inmiddels waarschijnlijk al 15 jaar geen updates krijgt. Da's jammer dan, maar ik zou zo'n systeem liefst niet meer online hebben.

[MatiasG]

Ja dat klopt, ik dualboot ook powerpc64 Linux met waar Rust, Firefox 142 en dergelijke wel werken.

Maar ik wou even een mooi voorbeeld geven van een platform wat wel ondersteund wordt door C maar niet door Rust. En er zullen ongetwijfeld meer gevallen zijn.

[Sissors]

Een compleet ander OS draaien is imo niet echt een oplossing. Dan kan je beter waarschijnlijk gewoon een niet 20 jaar oude computer gebruiken. Ik zou me meer afvragen of in dat geval het uitmaakt dat je op een wat oudere versie van GIT blijft hangen.

[Arrigi]

Als het nog voldoet en men niets anders wil kopen is het eigenlijk wel een oplossing, mits het alternatief OS bestaat. Mijn punt was eerder dat zo'n niet-ondersteund nicheplatform (met bestaand alternatief!) een moeilijk aan te nemen contra-argument is.

Net zoals Rust een systeem met een linux 2.6.x kernel niet meer ondersteunt. Dat is intussen ook zo'n 15 jaar geleden terug afgerond. Héél goede kans dat het systeem nieuwere software ondersteunt. Pas daarna ergens is de kernel gestopt met ondersteuning voor een 80386, dus het moest al héél oud zijn om geen upgrade aan te kunnen.

Ik zag ergens de vermelding van "Nonstop", een compleet op zich staand highly redundant systeem dat geen Rust support heeft(had?) en hierdoor getroffen zou zijn. Dat is nog wat anders, maar als het écht zo belangrijk is kan HPE daar zelf resources voor vrijmaken, al is het via betalingen aan Rust developers.

[cricque]

Dikwijls moeten er nu eenmaal keuzes gemaakt worden en vroeger waren er genoeg bedrijven die geen mac versie hadden en omgekeerd dikwijls ook. Dat was ook een keuze. Maar op een gegeven moment moet je keuzes maken, welke platformen kan ik ondersteunen en heeft het ook nut om dat te doen

[GertMenkel]

Voor ontwikkeling is het wellicht niet de beste keuze, maar https://github.com/Rust-GCC/gccrs zou toch gewoon op die platforms moeten draaien? Nu is dat een redelijk minimale implementatie, maar ik verwacht niet dat git nu hele complexe dependencies gaat toevoegen buiten de standaardbibliotheek.

De GCC-frontend doet niet alle validaties en optimalisaties, maar voor het compilen van de code zou dat geen probleem moeten zijn. Alleen mensen die actief ontwikkelen zullen moeten valideren dat de veiligheidsregels worden gevolgd.

Nu is die frontend, evenals de C code generator backend aan de LLVM-kant, nog niet in volledig bruikbare staat, maar het zal nog jaren duren voor je de allernieuwste features van git echt nodig gaat hebben voor het compilen van software.

[Reactie gewijzigd door GertMenkel op 21 september 2025 17:04]

[Blokker_1999]

Maar Git is in de basis een set van standaarden, een definitie van een versioneringssysteem. Hoe je dat implementeert mag toch niet uitmaken? Dat de referentie implementatie hierdoor niet meer op bepaalde systemen zal werken daar kunnen de beheerders van die systemen weer rondon werken door een eigen fork te starten lijkt mij.

[Bensjero]

Nee, Git is geen definitie maar een stukje open source software. En software is geschreven in een bepaalde taal die afhankelijk is van de host waarop het draait en soms dus een extra runtime nodig heeft om zn ding te kunnen doen, en soms zit dat ingebakken in een OS dat op een host draait.

[trick2011]

dus een extra runtime nodig heeft om zn ding te kunnen doen

volgens mij heeft rust geen runtime nodig. Het probleem lijkt het gemist van compilers te zijn voor bepaalde obscure platforms

[xorpd]

ELK programma heeft een runtime nodig. Dat het niet opvalt dat C een runtime heeft is omdat die slechts een handvol bytes is. Wat doet de C runtime?

• slaat %rdx op als exit handler (deze wordt geleverd door ld.so)
• converteert de stack naar argc, argv en envp
• alignt de stack op 16-bytes
• roept main aan
• roept eventueel de exit handler aan
• roept exit aan met de return code van main

Ook ld.so (voor dynamically linked executables) kan gezien worden als deel van de runtime.

[trick2011]

ff snel gecheckt want ik ben geen expert in rust. maar linkt rust (op dit moment) niet met libc voor deze functionaliteit?

verder een nitpick. je kan zonder runtime, daar krijg je alleen erg statische programmas van zoals in de microcontroller wereld.

[xorpd]

Dat zit in /usr/lib/gcc/x86_64-linux-gnu/crt1.o (wat gcc automatisch meelinkt i.g.v. C).

Beargumenteerd kan worden dat libc.so ook onderdeel is van de runtime.

[Reactie gewijzigd door xorpd op 22 september 2025 20:20]

[fdboer68]

Kan iemand mij de security voordelen duiden in het geval git een transitie naar rust maakt? Misschien zie ik iets over het hoofd, maar git draait toch alleen in user space?

Zie ook YouTube: rust is causing a lot of problems...

[Reactie gewijzigd door fdboer68 op 21 september 2025 12:56]

[bwerg]

User-space doet niet ineens alle (security) bugs verdwijnen.

[Keyb]

Rust ook niet.

[thePiett]

Inderdaad. Het lijkt haast wel een hype; software is geschreven in Rust en dus is het "veilig".

[Dykam]

Ik neem aan dat jij een gordel draagt, ondanks dat het autorijden niet 100% veilig maakt.

Zo is dat natuurlijk ook met Rust. Het maakt de kans op bepaalde type fouten significant kleiner.

[hackerhater]

git-servers (centrale repo's) hangen bijvoorbeeld vaak vast aan SSH voor authenticatie.
Maar zelfs met het draaiende in user-space. Je wilt geen memory-bugs hebben in software die code-beheer doet.
Gunstigste geval maak je dan de repo corrupt, ergste geval geef je schrijfrechten op een repo waar mensen niet aan mogen kunnen.

[Zoijar]

Daarbij, hoe vaak heb je gezien dat een bestaand project naar een andere taal wordt geport en er dan beter uit komt? Het is altijd hetzelfde, "dat kunnen wij beter, oh, dit is allemaal niet nodig" ... oops het was toch wel nodig, 50 regressies...

[thePiett]

"Distributiesysteem" git? Dus git is een systeem voor distributiecentra van Ahold?

Git is een gedistribueerd versiebeheersysteem.

[somatik]

Ligt het aan mij of is dit een erg verwarrend artikel? De term "ondersteuning" lijkt hier gebruikt te worden ipv "vereiste". Je hebt vanaf nu rust nodig om git te compileren.

[Tubby]

Klopt, de titel lijkt de suggestie te wekken dat je rust moet installeren om git te kunnen gebruiken. Maar ze zeggen dus dat ze de codebase van git richting rust willen migreren. Dat heeft dus primair te maken voor de mensen die (mee)bouwen aan git en niet de gebruikers van git.