Microsoft alkaa puhua seuraavan sukupolven ohjelmointikielestä, C# järjestelmäohjelmointiin

Joe Duffy, Microsoftin arkkitehti ja tutkimuskäyttöjärjestelmän kehittäjä, on kirjoittanut blogiin seuraavan sukupolven ohjelmointikielestä, jota he ovat työstäneet parin viime vuoden aikana. Microsoft kuvailee nyt tätä tulevaa kieltä C#:n "järjestelmäohjelmointi"-laajennuksina. Microsoft yrittää esitellä tämän kielen turvallisuus- ja tuottavuuskeskeisen C#:n, Javan jne. ja suorituskykykeskeisen C++:n välillä.

Tässä on kielen 6 tärkeää ominaisuutta,

) Elinikäinen ymmärrys. C++:ssa on RAII, deterministinen tuhoaminen ja tehokas objektien allokointi. C# ja Java houkuttelevat kehittäjiä luottamaan liian voimakkaasti GC-kekoon ja tarjoavat vain "löysää" tukea deterministiselle tuholle IDisposable-sovelluksen kautta. Osa siitä, mitä tiimini tekee, on säännöllisesti muuntaa C#-ohjelmia tälle uudelle kielelle, ja ei ole harvinaista, että kohtaamme 30–50 % GC:ssä vietetystä ajasta. Palvelimissa tämä tappaa suorituskyvyn; asiakkaiden kohdalla se heikentää kokemusta lisäämällä vuorovaikutukseen latenssia. Olemme varastaneet sivun C++:sta — sellaisilla aloilla kuin rvalue-viittaukset, siirtosemantiikka, tuhoaminen, viittaukset/lainaaminen — ja silti säilyttäneet tarvittavat turvallisuuselementit ja yhdistäneet ne toiminnallisten kielten ideoihin. Tämä antaa meille mahdollisuuden pinota allokoivia objekteja aggressiivisesti, deterministisesti tuhota ja paljon muuta.

2) Sivuvaikutusten ymmärtäminen. Tämä on kehitys siitä, mitä julkaisimme OOPSLA 2012:ssa, ja se antaa sinulle C++ const -elementtejä (mutta jälleen turvallisuuden kanssa) sekä ensiluokkaista muuttumattomuutta ja eristystä.

3) Async ohjelmointi mittakaavassa. Yhteisö on ollut ympäripyöreä tämän asian suhteen, eli käytetäänkö jatko-syötteitä vai kevyitä estokorutiineja. Tämä sisältää C#, mutta myös melkein kaikki muut planeetan kielet. Keskeisin innovaatio tässä on koostettava tyyppijärjestelmä, joka on agnostinen suoritusmallin suhteen ja voi kartoittaa tehokkaasti jommankumman. Olisi ylimielistä väittää, että meillä on yksi oikea tapa paljastaa tämä juttu, mutta koska minulla on kokemusta monista muista lähestymistavoista, rakastan sitä, mihin päädyimme.

4) Tyyppiturvallisten järjestelmien ohjelmointi. Yleisesti väitetään, että tyyppiturvallisuus heikentää suorituskykyä. On totta, että rajojen tarkistus ei ole neuvoteltavissa ja että oletuksena suosimme ylivuototarkistusta. On yllättävää, mitä hyvä optimoiva kääntäjä voi tehdä täällä, verrattuna JIT-kääntämiseen. (Ja tarvitsee vain tarkistaa muutamat viimeaikaiset tietoturvatiedotteet, jotta näet, miksi nämä ominaisuudet ovat hyödyllisiä.) Muita alueita ovat muun muassa se, että voit tehdä enemmän ilman varaamista. Kuten lambda-pohjaiset sovellusliittymät, joita voidaan kutsua nollaallokaatioilla (tavanomaisten kahden sijaan: yksi edustajalle, yksi näytölle). Ja alitaulukoiden ja alimerkkijonojen erottaminen ilman kohdistamista.

5) Moderni virhemalli. Tämä on toinen asia, josta yhteisö on eri mieltä. Olemme valinneet sen, minkä uskon olevan makea piste: sopimukset kaikkialla (esiehdot, jälkiehdot, invariantit, väitteet jne.), oletuskäytännöksi Fast-fast, poikkeukset harvinaisille dynaamisille virheille (jäsennys, I/O jne.), ja kirjoitit poikkeukset vain silloin, kun tarvitset ehdottomasti runsaasti poikkeuksia. Kaikki integroitu tyyppijärjestelmään 1. luokan tavalla, jotta saat kaiken oikean alatyypityksen, joka on tarpeen tehdäksesi siitä turvallisen ja luotettavan.

6) Nykyaikaiset puitteet. Tämä on kaiken kattava paketti, joka kattaa esimerkiksi asynkronisen LINQ:n, parannetun luettelointituen, joka kilpailee suorituskyvyltään C++-iteraattorien kanssa eikä vaadi kaksinkertaista käyttöliittymää elementtien poimimiseen jne. Ollakseni täysin rehellinen, tämä on meidän alueemme suurin luettelo "suunnitelluista, mutta vielä toteuttamattomista ominaisuuksista", joka kattaa asioita, kuten void-as-a-1st-class-type, ei-null-tyypit, ominaisuudet, 1. luokan tehostekirjoitus ja paljon muuta. Odotan, että meillä on muutamia näitä vuoden 2014 puolivälissä tarkistuspisteessämme, mutta ei kaikkia.

Lue lisää linkistä tätä.