Na Google groeit ook bij Microsoft de weerstand tegen C en C++. De twee populaire programmeertalen veroorzaken te veel bugs. Tijd om ze in te ruilen voor de kakelverse taal Rust?
De technisch directeur van Microsoft Azure vindt dat de software-industrie moet afstappen van C en C++. Deze twee staan hoog in de Computable index van populairste programmeertalen: C++ op plek 4 en C op plek 6.
Volgens de cto is het alternatief Rust. Dit is een taal die pas enkele jaren geleden de stabiele versie 1.0 bereikte en sindsdien in opmars is. Onder meer het Android Open Source Project (AOSP), Meta (Facebook), Amazon Web Services (AWS) en Microsoft gebruiken Rust. De taal wordt ook gebruikt voor ontwikkelingen in de Linux-kernel.
Geheugen
Rust werkt aan de hand van geheugenverliesgaranties, waardoor developers het geheugen van een programma niet langer handmatig hoeven beheren. Dit verkleint het risico op geheugengerelateerde beveiligingsfouten, die bij C en C++ vaak opdoken.
Is het wel slim om als marktdominant bedrijf te pleiten voor een programmeertaal waarvan de eerste stabiele versie pas een paar jaar in de markt is? Wordt het niet tijd om meer aandacht aan Rust te schenken tijdens ict-opleidingen?
Zijn er voor C en C++ geen structurele oplossingen te verzinnen voor terugkerende bugs in software? Zijn we het eens met de kritiek op deze twee programmeertalen en wordt het inderdaad tijd voor een adieu?
Kortom: Computable is op zoek naar de mening van de experts. Weg met C en C++, op naar Rust?
Goede schoenen weggooien voordat je de nieuwe ingelopen hebt is niet erg slim. Diederik vergeet dat de stelling niet gaat om weg met C en C++ maar om de vraag of het nog raadzaam is om deze talen te blijven gebruiken. Het lijkt me nogal dom als je daarin niet rekening houdt met zoiets als het onderhoud van het verleden. Weg met Computable en op naar iets anders gaat tenslotte om de behoudendheid, mijn mening als ex-expert gaat niet om een marktdominantie maar de markt.
Wat betreft aandacht schenken aan een programmeertaal in opleidingen heb ik het idee dat het meer om C# dan C of C++ gaat.
Ik ben benieuwd naar de vraag achter de vraag. Waarom duiken geheugengerelateerde beveiligingsfouten op bij C en C++? Wat is de rol van programmeertalen bij terugkerende bugs in software? Dit betoog doet denken aan een populaire betoogwijze uit de jaren 80 en 90 van de vorige eeuw: “Mijn programmeertaal is beter dan de jouwe”.
Laten we liever kijken naar eigenschappen van programmeertalen. Kunnen we bijvoorbeeld iets zeggen over programmeerfouten als we declaratieve programmeertalen en niet-declaratieve programmeertalen naast elkaar zetten? Ander voorbeeld: Welke rol speelt sterke typering in programmeertalen in de onderhoudbaarheid van software? Over dat soort vragen verschijnt ook met enige regelmaat wetenschappelijke onderzoek. Dat maakt hopelijk een wat meer inhoudelijke en genuanceerde discussie mogelijk dan simpelweg: “we moesten C en C++ maar eens vervangen door Rust”.
Wat betreft vraag achter de vraag leidt recursie in de regel tot nog meer geheugenproblemen 🙂
“we moesten C en C++ maar eens vervangen door Rust” omdat
“Rust werkt aan de hand van geheugenverliesgaranties, waardoor developers het geheugen van een programma niet langer handmatig hoeven beheren. Dit verkleint het risico op geheugengerelateerde beveiligingsfouten, die bij C en C++ vaak opdoken.”
Wie wel eens iets in C geschreven heeft, kan zich er wel wat bij voorstellen.
Het artikel gaat niet over functionele fouten, of onderhoudbaarheid van code.
Tis meer van devops doet het met c en devsecops met rust.
C en C++ zijn talen die van de programmeur goede discipline vragen als het gaat om geheugenbeheer. Vooral het rekenen met pointer-adressen is een bron van problemen. Het is heel eenvoudig om net die ene variabele met de laatste pointer naar dat 1Mb geheugengebied te verliezen wat uiteindelijk leidde tot een ‘out of memory’ die weer leidde tot een veiligheidsprobleem.
Het is dat ene moment dat de pointer voorbij het geclaimde geheugengebied mocht komen en het geheugengebied ging overschrijven waardoor… Kortom het is oppassen, of er moeten hulpmiddelen komen die dat gaan voorkomen.
Rust is een taal die de ontwikkelaar _helpen_ bij het bewaken van dit soort dingen, de aanroepende methode/functie moet expliciet toestemming geven om een variabele van waarde te laten veranderen.
Maar net als alle andere talen (C, C++, Java, Python, Cobol, Assembly, noem ze maar op) is het met Rust ook mogelijk om programma’s te schrijven die de boel vernaggelen. Het zal een stuk moeilijker zijn, er zijn meer hordes te nemen, maar zoals het oude adagio gaat: “A fool with a tool is still a tool”.
Natuurlijk zullen er managers gaan opstaan die maar de helft (als dat al) van het verhaal echt begrijpen en de IT afdeling en masse naar Rust cursussen gaat sturen omdat de KPI daartoe stuurt.
Leiders daarentegen zullen zich eerst flink achter de oren krabben en kijken hoeveel van de huidige problemen (en die uit het verleden) nou echt te wijten zijn aan de taal (en niet aan fouten of vergissingen van de ontwikkelaars).
Het begint er op te lijken, nog steeds zijn er taken die makkelijk in biosniveau afgehandeld kunnen worden en zeker in deze SSD tijd, al die geheugen en CPU taken, dat hoeft toch echt niet. Ga het nou gewoon is regelen. Okay binairycode gaat iets te ver maar dit lijkt de goede weg op te gaan, proficiat