Microsoft begint te praten over hun volgende generatie programmeertaal, C# voor systeemprogrammering

Joe Duffy, een architect en ontwikkelaar van een onderzoeksbesturingssysteem bij Microsoft, heeft geblogd over de volgende generatie programmeertaal waar ze de afgelopen jaren aan hebben gewerkt. Microsoft beschrijft deze opkomende taal nu als "systeemprogrammering" -extensies voor C #. Microsoft probeert deze taal te pitchen als een kruising tussen op veiligheid en productiviteit gerichte C#, Java, enz. en Prestatiegerichte C++.

Hier zijn de 6 belangrijke kenmerken van de taal,

) Levenslang begrip. C++ heeft RAII, deterministische vernietiging en efficiënte toewijzing van objecten. C# en Java zorgen er allebei voor dat ontwikkelaars te veel vertrouwen op de GC-heap, en bieden alleen "losse" ondersteuning voor deterministische vernietiging via IDisposable. Een deel van wat mijn team doet, is het regelmatig converteren van C#-programma's naar deze nieuwe taal, en het is niet ongebruikelijk dat we 30-50% tijd in GC doorbrengen. Voor servers doodt dit de doorvoer; voor klanten verslechtert het de ervaring door latentie in de interactie te injecteren. We hebben een pagina uit C++ gestolen — op gebieden als rvalu-referenties, semantiek verplaatsen, vernietiging, verwijzingen / lenen — en toch de noodzakelijke veiligheidselementen behouden en ze samengevoegd met ideeën uit functionele talen. Dit stelt ons in staat om toewijzingsobjecten agressief te stapelen, deterministisch te vernietigen en meer.

2) Begrip van bijwerkingen. Dit is de evolutie van wat we in OOPSLA 2012 hebben gepubliceerd, waardoor je elementen van C++ const (maar opnieuw met veiligheid) krijgt, samen met eersteklas onveranderlijkheid en isolatie.

3) Asynchrone programmering op schaal. De gemeenschap is hier rond en rond geweest, namelijk of ze continu-passing of lichtgewicht blokkerende coroutines moeten gebruiken. Dit omvat C#, maar ook vrijwel elke andere taal op de planeet. De belangrijkste innovatie hier is een composable type-systeem dat agnostisch is voor het uitvoeringsmodel en efficiënt kan worden toegewezen aan een van beide. Het zou arrogant zijn om te beweren dat we de enige juiste manier hebben om dit spul bloot te leggen, maar door ervaring met vele andere benaderingen, ben ik dol op waar we zijn beland.

4) Type-veilige systeemprogrammering. Er wordt vaak beweerd dat typeveiligheid gepaard gaat met een inherent prestatieverlies. Het is waar dat grenscontrole niet onderhandelbaar is en dat we standaard de voorkeur geven aan overloopcontrole. Het is verrassend wat een goede optimaliserende compiler hier kan doen, in tegenstelling tot JIT-compiling. (En je hoeft slechts terloops enkele recente beveiligingsbulletins te controleren om te zien waarom deze functies hun waarde hebben.) Andere gebieden zijn onder meer dat je meer kunt doen zonder toe te wijzen. Zoals het hebben van op lambda gebaseerde API's die kunnen worden aangeroepen zonder toewijzingen (in plaats van de gebruikelijke twee: één voor de gedelegeerde, één voor het display). En in staat zijn om gemakkelijk sub-arrays en sub-strings uit te snijden zonder toe te wijzen.

5) Modern foutenmodel. Dit is er weer een waar de gemeenschap het niet mee eens is. We hebben gekozen voor wat volgens mij de goede plek is: overal contracten (precondities, postcondities, invarianten, beweringen, enz.), Fail-fast als het standaardbeleid, uitzonderingen voor de zeldzame dynamische storing (parsing, I/O, enz.), en getypte uitzonderingen alleen als u absoluut uitgebreide uitzonderingen nodig hebt. Allemaal geïntegreerd in het typesysteem op een eersteklas manier, zodat je al het juiste subtype-gedrag krijgt dat nodig is om het veilig en gezond te maken.

6) Moderne kaders. Dit is een allesomvattende bucket die zaken dekt als asynchrone LINQ, verbeterde enumeratorondersteuning die qua prestaties concurreert met C++-iterators en geen dubbele interface-verzending vereist om elementen te extraheren, enz. Om helemaal eerlijk te zijn, is dit het gebied dat we hebben de grootste lijst met "ontworpen maar nog niet geïmplementeerde functies", met zaken als void-as-a-1st-class-type, niet-null-types, eigenschappen, eersteklas effecttypering en meer. Ik verwacht dat we er een paar hebben in ons checkpoint medio 1, maar niet allemaal.

Lees meer via de link hier.