In sommige opzichten runnen C en C++ de wereld. Je zou het nooit weten van alle hype over andere programmeertalen, zoals Python en Go, maar de overgrote meerderheid van krachtige desktopapplicaties en besturingssystemen voor de massamarkt zijn geschreven in C++, en de overgrote meerderheid van embedded applicaties zijn geschreven in C. We hebben het niet over smartphone-apps of webapplicaties: deze hebben speciale talen, zoals Java en Kotlin voor Android en Objective-C en Swift voor iOS. Ze gebruiken alleen C/C++ voor innerlijke lussen die een enorme behoefte aan snelheid hebben, en voor bibliotheken die door verschillende besturingssystemen worden gedeeld.
C en C++ hebben de systeemprogrammering zo lang gedomineerd, dat het moeilijk voor te stellen is dat ze worden verdrongen. Toch zeggen veel experts dat het tijd is voor hen om te gaan, en voor programmeurs om betere alternatieven te omarmen. Microsoft Azure CTO Mark Russinovich maakte onlangs furore toen hij suggereerde dat C- en C++-ontwikkelaars in plaats daarvan naar Rust moesten verhuizen. “De industrie zou die talen als verouderd moeten verklaren,” Russinovich getweet.
Veel ontwikkelaars onderzoeken Rust als een productieklaar alternatief voor C/C++, en er zijn andere opties in het verschiet. In dit artikel zullen we de verdiensten en gereedheid van de drie meest geciteerde C/C++-taalalternatieven bekijken: Rust, Carbon en cppfront. Laten we eerst eens terugkijken door de geschiedenis en enkele pijnpunten van C/C++.
C++ pijnpunten
C++ is ontwikkeld door Bjarne Stroustrup bij Bell Laboratories vanaf 1979. Aangezien C++ een poging is om objectgeoriënteerde functies (plus andere verbeteringen) toe te voegen aan C, noemde Stroustrup het aanvankelijk “C met objecten”. Stroustrup hernoemde de taal in C++ in 1983 , en de taal werd beschikbaar gesteld buiten Bell Laboratories in 1985. De eerste commerciële C++-compiler, Cfront, werd op dat moment uitgebracht. Cfront vertaalde C++ naar C, dat vervolgens kon worden gecompileerd en gekoppeld. Latere C++-compilers produceerden objectcodebestanden om te voeden direct in een linker.
Sindsdien is de C++-standaardisatie-inspanning continu geweest, te beginnen met de publicatie van Stroustrup’s 1985 De programmeertaal C++ en jaren 90 ARM—De EENgenoteerde C++ Referentie Mjaarlijks. Deze werden gevolgd door een hele reeks ANSI/ISO C++-normen, in 1998, 2003, 2011, 2014, 2017, 2020, met de volgende gepland voor 2023. Er zijn ook tussentijdse technische specificaties om supplementen te definiëren.
Elke herziening van de C++-standaard heeft extra functies, maar geen enkele heeft de taal gemakkelijker te leren of sneller te compileren gemaakt. Iedereen die een C++-programma met miljoenen regels heeft gebouwd, begrijpt de last van: wachten op compiles. Rob Pike citeert de compileertijd van C++ als zijn motivatie voor het ontwikkelen van Go: “Tegen september 2007 deed ik wat klein maar centraal werk aan een enorm Google C++-programma, een programma waar jullie allemaal mee te maken hebben gehad, en mijn compilaties duurden ongeveer 45 minuten op ons enorme gedistribueerde compileercluster.” De oplossing van Pike was om een nieuwe taal te ontwikkelen, Go, die uiteindelijk veel acceptatie trok, maar niet door C++-programmeurs.
Ik heb persoonlijk aan een C++-programma gewerkt dat “slechts” 2 miljoen regels code bevatte. Destijds kostte het enkele uren om een volledige compilatie en koppeling uit te voeren op een enkele computer met acht kernen, en ongeveer 10 minuten om in Visual Studio te laden en alle symbolen op te lossen. Ik heb het compilatieprobleem met automatisering omzeild: ik had een script dat in het holst van de nacht een nieuwe kopie van de code uit de gedeelde repository haalde en vervolgens het hele ding van de grond af aan compileerde. Ik heb het probleem van langzaam laden omzeild door elke ochtend na het openen van Visual Studio water te koken, thee te zetten en het met teamgenoten te drinken. (Visual Studio heeft sindsdien het probleem met langzaam laden opgelost, is mij verteld.)
Voor ontwikkelaars die op zoek zijn naar alternatieven voor C++, zijn Rust, Carbon en Cppfront allemaal sterke kandidaten. Van de drie is momenteel alleen Rust productieklaar.
Roest als alternatief voor C++
De Rust-lang homepage verklaart drie belangrijke redenen om voor Rust te kiezen: prestaties, betrouwbaarheid en productiviteit. Rust is ontworpen om snel, veilig en gebruiksvriendelijk te zijn, met als overkoepelend doel iedereen in staat te stellen betrouwbare en efficiënte software te bouwen.
Wat de prestaties betreft, is Rust zowel snel als geheugenefficiënt: zonder runtime of garbage collector kan het prestatiekritieke services aandrijven, draaien op embedded apparaten en gemakkelijk integreren met andere talen. Wat de betrouwbaarheid betreft, garanderen Rust’s rijke typesysteem en eigendomsmodel geheugenveiligheid en threadveiligheid – die ontwikkelaars kunnen gebruiken om veel klassen bugs te elimineren tijdens het compileren. Voor productiviteit beschikt Rust over geweldige documentatie, een gebruiksvriendelijke compiler met nuttige foutmeldingen en eersteklas tooling – een geïntegreerde pakketbeheerder en build-tool, slimme ondersteuning voor meerdere editors met automatische aanvulling en type-inspecties, een auto-formatter en meer .
Ondersteunde Rust-gebruiksscenario’s omvatten: opdrachtrege kunt ook onveilige coderingspraktijken inschakelen als u ze nodig hebt, met behulp van de ttribuut. Soms moet u onbewerkte aanwijzers derefereren, C-functies aanroepen, statica muteren of velden van een eze zijn allemaal onveilig, dus u moet ze als onveilig markeren om ze in een Rust-programma te kunnen gebruiken. (Je moet ze ook echt met de hand controleren, omdat je niet op de compiler kunt vertrouwen om fouten die je maakt in onveilige code te corrigeren.)
Koolstof als altern
De gestelde doelen van het Carbon Language-project zijn: prestatiekritische software; software en taalevolutie; code die gemakkelijk te lezen, te begrijpen en te schrijven is; praktische veiligheids- en testmechanismen; snelle en schaalbare ontwikkeling; moderne OS-platforms, hardware-architecturen en omgevingen; en interoperabiliteit met en migratie van bestaande C++-code.
Het project heeft ook expliciete niet-doelen. Een stal ontwikkelen ace: (ABI) voor de hele taal en bibliotheek en het garanderen van perfecte achterwaartse of voorwaartse compatibiliteit zijn geen doelen voor Carbon.
Volgens Kate Gregory leidt een van de projectleiders samen met Richard Smith (van de ISO C++ normcommissie) en Chandler Carruth (een hoofdsoftware-engineer bij Google), waardoor achterwaartse compatibiliteit het project de vrijheid geeft om positieve veranderingen aan te brengen die in de C++-taal niet zouden zijn toegestaan, met als belangrijkste voordeel dat de technische schuld wordt verminderd. In plaats van achterwaartse compatibiliteit biedt Carbon op tools gebaseerde versie-upgrades en C++-migratie. Op tools gebaseerde upgrades en migratie klinken een stuk beter dan de ondraaglijke en langdurige handmatige upgrades die C++-ontwikkelaars moeten doen bij elke grote verandering in de taal.
Er valt veel te absorberen in het onderstaande codevoorbeeld, dat uit de Carbon-repository komt. Ik heb opmerkingen toegevoegd om te helpen.
Ru
