Microsoft начинает говорить о своем языке программирования следующего поколения, C # для системного программирования

Джо Даффи, архитектор и разработчик исследовательской операционной системы в Microsoft, написал в блоге о языке программирования следующего поколения, над которым они работали последние пару лет. Microsoft теперь описывает этот будущий язык как расширение «системного программирования» для C#. Microsoft пытается представить этот язык как нечто среднее между C#, ориентированным на безопасность и производительность, Java и т. д. и C++, ориентированным на производительность.

Вот 6 важных особенностей языка:

) Пожизненное понимание. В C++ есть RAII, детерминированное разрушение и эффективное выделение объектов. C# и Java уговаривают разработчиков слишком сильно полагаться на кучу GC и предлагают лишь «слабую» поддержку детерминированного уничтожения через IDisposable. Часть того, чем занимается моя команда, — это регулярное преобразование программ C# на этот новый язык, и мы нередко сталкиваемся с тем, что 30–50% времени мы проводим в GC. Для серверов это снижает пропускную способность; для клиентов это ухудшает качество обслуживания, внося задержку во взаимодействие. Мы украли страницу из C++ — в таких областях, как ссылки rvalue, семантика перемещения, уничтожение, ссылки/заимствования — и при этом сохранили необходимые элементы безопасности и объединили их с идеями из функциональных языков. Это позволяет нам агрессивно размещать объекты в стек, детерминированно уничтожать и многое другое.

2) Понимание побочных эффектов. Это развитие того, что мы опубликовали в OOPSLA 2012, предоставляя вам элементы C++ const (но опять же с безопасностью), а также первоклассную неизменяемость и изоляцию.

3) Асинхронное программирование в большом масштабе. Сообщество постоянно обсуждало этот вопрос, а именно, использовать ли сопрограммы с передачей продолжения или облегченные блокирующие сопрограммы. Сюда входит C#, а также почти все остальные языки на планете. Ключевым нововведением здесь является компонуемая система типов, которая не зависит от модели выполнения и может эффективно сопоставляться с любой из них. Было бы самонадеянно утверждать, что у нас есть единственный правильный способ раскрыть эту информацию, но, имея опыт применения многих других подходов, мне нравится то, к чему мы пришли.

4) Типобезопасное системное программирование. Обычно утверждается, что безопасность типов приводит к потере производительности. Это правда, что проверка границ не подлежит обсуждению и что мы предпочитаем проверку переполнения по умолчанию. Удивительно, что здесь может сделать хороший оптимизирующий компилятор по сравнению с JIT-компиляцией. (И достаточно лишь случайно просмотреть некоторые последние бюллетени по безопасности, чтобы понять, почему эти функции заслуживают внимания.) Другие области включают возможность делать больше без выделения ресурсов. Например, API-интерфейсы на основе лямбда-выражений, которые можно вызывать с нулевым выделением ресурсов (вместо обычных двух: один для делегата, другой для отображения). И возможность легко вырезать подмассивы и подстроки без выделения.

5) Современная модель ошибок. Это еще один вопрос, с которым сообщество несогласно. Мы выбрали то, что я считаю оптимальным: контракты повсюду (предусловия, постусловия, инварианты, утверждения и т. д.), отказоустойчивость в качестве политики по умолчанию, исключения для редких динамических сбоев (синтаксический анализ, ввод-вывод и т. д.), и вводите исключения только тогда, когда вам абсолютно необходимы расширенные исключения. Все интегрировано в систему типов первоклассным образом, так что вы получаете все правильное поведение подтипов, необходимое для обеспечения безопасности и надежности.

6) Современные фреймворки. Это всеобъемлющий блок, который охватывает такие вещи, как асинхронный LINQ, улучшенную поддержку перечислителей, которые конкурируют с итераторами C++ по производительности и не требуют диспетчеризации двойного интерфейса для извлечения элементов и т. д. Честно говоря, это та область, которая у нас есть. самый большой список «спроектированных, но еще не реализованных функций», охватывающий такие вещи, как тип void как тип 1-го класса, ненулевые типы, особенности, типизация эффекта 1-го класса и многое другое. Я ожидаю, что на нашем контрольно-пропускном пункте в середине 2014 года будет несколько таких, но не все.

Подробнее читайте по ссылке здесь.