Здравствуйте, Pavel Dvorkin, Вы писали:

1)Запретить языки с динамической типизацией.
Недостатки:
а)Тормоза.
б)Потребление памяти на ровном месте.
в)Не ловят ошибки программистов.
г)Невозможно создать качественную IDE.
Достоинство:
Нужно писать меньше кода по сравнению с явой.
По сравнению с немерле разница становится минимальной. И на практике не всегда в пользу динамически типизированных языков. Ибо они примитивные.

2)Запретить нативный код.
Проблема нативного кода в том, что он не даёт заменять систему команд процессоров.
Через пару лет после того как не станет нативного кода x86 сдохнет.
Исключение можно сделать только для совсем дохлых микропроцессоров где даже ОС нет.

3)За основу ОС берем мидори. http://joeduffyblog.com/2015/11/03/blogging-about-midori/
а)Зачищаем ВМ и язык от .НЕТ'ных анахронизмов.
б)Для эффективного управления памятью и эффективной передачи графов объектов между процессами добавляем это:
Re: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 29.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

Re[2]: Мысли о эффективном автоматическом управлении памятью

Автор: WolfHound
Дата: 30.10.14

mutable, readonly и immutable становятся атрибутами кластеров.
в)Добавляем http://halide-lang.org/ для параллельного программирования.
г)Заменяем контракты на это: https://www.microsoft.com/en-us/research/project/dafny-a-language-and-program-verifier-for-functional-correctness/
Учим компилятор вставлять рантайм проверки в тех местах где он не смог статически доказать корректность.
Если проверка провалилась, то молча прибиваем процесс.
Если статически доказано что ошибка будет всегда, то выдаём ошибку компиляции.
Обоснование тут: http://joeduffyblog.com/2016/02/07/the-error-model/
Делаем 3 уровня:
1)Никогда не вставлять. Если программист что-то не доказал выдаём ошибку.
2)Всегда вставлять, но вместо ошибки выдавать предупреждение.
3)Молча вставлять.

Большая часть кода будет всегда жить в третьем режиме. В этом случае мы получаем код в стиле явы и C#. Но так как пред и пост условия всё равно можно будет писать то большая часть проверок будет выполнена статически. И код будет быстрее.
Более того ошибки будут обнаружены там, где они произошли, а не где попало.

Второй режим нужен при начальном написании ответственного кода.
Сначала пишем в третьем режиме. Ибо писать сразу в первом довольно трудно. Когда код написан переходим во второй и начинаем доказывать. Когда все предупреждения закончились переключаем в первый.