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: opdrachtregelprogramma’s bouwen, compileren naar WebAssembly (een manier om je JavaScript een boost te geven), building netwerkdienstenen het maken van software voor ingebedde systemen met weinig middelen. Roestadoptie in productie wint aan kracht, inclusief gebruik in Firefox, Dropbox, CloudflareNPM, Yelpen InfluxDB IOx. InfluxDB gebruikt nu ook Datafusieeen Rust native SQL-query-engine voor Apache Arrow.
Rust heeft de reputatie moeilijk te leren te zijn, hoewel waarschijnlijk niet zo moeilijk als C++. Een groot verkoopargument is dat het standaard veilig is, wat betekent dat in Veilig roest u hoeft zich geen zorgen te maken over type-veiligheid of geheugen-veiligheid. U kunt ook onveilige coderingspraktijken inschakelen als u ze nodig hebt, met behulp van de unsafe
attribuut. Soms moet u onbewerkte aanwijzers derefereren, C-functies aanroepen, statica muteren of velden van een union
. Deze 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 alternatief voor C++
De nieuwe, experimentele Carbon-taal, aangekondigd op de CPP Noord-bijeenkomst op 19 juli 2022, is bedoeld als een mogelijke opvolger van C++. Hoewel Carbon nog lang niet klaar is voor gebruik, heeft het wn eenikeHet ontbreekt momenteel aan een compiler, een toolchain of zelfs een volledig 0.1-taalontwerp.
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 ontwikkel (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 C++ 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.
Wat vindt Stroustrup van dit alles? Niet veel, op dit moment. “Carbon is zo nieuw en ondergespecificeerd dat ik niet echt zinvolle technische opmerkingen kan maken.”
Cppfront als alternatief voor C++
Herb Sutter heeft tien jaar gediend als voorzitter vanmissie. Hij is sluitbreidingen van C++/CLI, C++/CX, C++ AMP en andere technologieën. Met Cpp2 en cppfront zegt Sutter dat het zijn “doel is om te onderzoeken of er een manier is waarop we C++ zelf kunnen ontwikkelen om 10 keer eenvoudiger, veiliger en bruikbaarder te worden.” Hij legt uit:
Als we een alternatieve C++-syntaxis hadden, zou het ons een “bubbel van nieuwe code die vandaag niet bestaat” geven waar we willekeurige verbeteringen zouden kunnen aanbrengen (bijvoorbeeld standaardinstellingen wijzigen, onveilige delen verwijderen, de taal contextvrij maken en orde- onafhankelijk zijn en over het algemeen 30 jaar aan lessen toepassen), vrij van compatibiliteitsbeperkingen met eerdere bronnen.
Sutter werkte in 2015 en 2016 aan het ontwerp van “syntax 2” (Cpp2) en schrijft sinds 2021 de t hun volledige ontwerpen mogelijk maakt, inclusief andere ingrijpende wijzigingen.
Sutter’s Cen paar dozijn voorbeelden van gemengde C++- en Cpp2-code, en nog een paar dozijn voorbeelden van pure Cpp2. Net als bij de originele Stroustrup Cfront, is Sutter’s Cppfront een brug om Cpp2-ontwikkeling mogelijk te maken en te experimenteren met de nieuwe syntaxis totdat het mogelijk is om Cpp2 rechtstreeks naar objectcode te compileren.
Roest, Carbon of Cppfront?
Rust, Carbon en Cppfront zijn allemaal veelbelovend als C++-alternatieven. Voor Carbon kijken we waarschijnlijk naar een ontwikkelingscyclus van vijf jaar totdat het voor productie wordt vrijgegeven. Cppfront is mogelijk eerder beschikbaar voor productie en Rust is er al.
Alle drie de talen zijn (of zullen) interoperabel zijn met C++ op binair niveau. Dat houdt in dat u met alle drie de talen geleidelijk verbeteringen kunt aanbrengen in bestaande C++-programma’s door nieuwe niet-C++-modules toe te voegen.
In het geval van Cppfront is het mixen van C++ en Cpp2-broncode al geïmplementeerd, althans gedeeltelijk, en is opgenomen in de regressiesuite van Sutter. De tooling van Carbon omvat automatische migratie van C++-broncode. Een open vraag is of dat 100% van je C++-code zal migreren, of dat je handmatig een bepaald percentage van je code moet herschrijven die anders slecht zou presteren, de Carbon-normen zou schenden, of dat je het als onveilig moet markeren als je het wilt verlaten alleen.
Rust demonstreert al geheugenveiligheid. U kunt letterlijk geen Rust-code compileren die de geheugenveiligheid schendt, tenzij u deze als onveilig markeert. Carbon en Cppfront zullen zeker geheugenbeveiligingsmechanismen implementeren. Welke dat precies zullen zijn, weten we nog niet.
Rust is niet erg gemakkelijk te leren, zelfs als je C++ kent, hoewel mij is verteld dat het leren van Rust eigenlijk een beetje makkelijker is dan het leren van C++ als je helemaal opnieuw begint. Niettemin slagen C++- en Go-programmeurs er meestal in om Rust binnen een week of twee op te pikken.
Wat we van Cpp2 van Herb Sutter hebben gezien, maakt duidelijk dat C++-programmeurs het een relatief gemakkelijke overgang zullen vinden, hoewel de door Cppfront gegenereerde C++ momenteel vrij lelijk is. De C++-conversietooling van Carbon zou een side-by-side bewerkingstool mogelijk moeten maken, net zoals de IntelliJ-ondersteuning voor het leren van Kotlin door bestaande Java-code te converteren.
Uiteindelijk, zoals Stroustrup suggereerde in zijn opmerkingen over Carbon, zullen we moeten afwachten hoe elke taal en zijn tooling uitpakken.