Let's Go

Благодаря посту одного хорошего человека, я узнал про других хороших людей. Что не может не радовать.
Людям хочется сделать C, но лучше. Завидую. Завидую тому, что у них достаточно мозгов, времени и денег, чтобы заниматься этим интересным и малоперспективным (ясен пончик, IMHO) делом.
Как я понял, ваяют язык именно системного программирования, ну там драйверы, оп.системы, инструментарий, СУБДы и всякое такое. Не для того, чтобы манипулировать элементами DOM в браузере, к примеру.


Что особо интересно (выцепил, читая FAQ-и):


Языком занимается Ken Thompson.
Этот точно может сделать Си, но лучше.

Ощущается как динамический язык, но скорость и безопасность (безопасность? вот так?) у него, как у статического языка.
Типа, пишется как на яваскрипте, а результат как на Си.

Система типов не имеет иерархии.
Вообще, хорошее решение. Лично мне никогда особо не надо было применять наследование, хотя академически это красиво. Правда, без иерархии придется часть кода повторять, посмотрим, как с этим справятся.

Это попытка уменьшить количество типизаций и печатных знаков. Нет упреждающего обьявления и заголовочных файлов, всё обьявляется только раз, инициализация (переменных) выразительна, автоматизирована и легка в использовании. Заикание типа
Topobase.Tracing.Algorithms.Reachability rb = new Topobase.Tracing.Algorithms.Reachability();
(это вот заикание лично меня бесит безмерно, а теперь будет типа так:
rb := Topobase.Tracing.Algorithms.Reachability();)
снижено через конструкцию "обьяви-и-инициализируй". Типам не надо разьяснять их взаимоотношений, они (типы) просто есть, никакой иерархии.

Принцип ортогональности концептов. Методы могут быть реализованы для любого типа; структуры представляют данные, тогда как интерфейсы представляют абстракции; и т.д. Это дает легкость понимания происходящего при смешивании всех этих вещей.
Мой опыт говорит, что быдлокодер на любом языке может замутить совершенно непредставимый и непонятный код. Ортогональность не панацея, хотя с ней гораздо лучше.

Адресной арифметики нет, по соображениям безопасности.
Сборка мусора сильно упрощается. Эффективность циклов не страдает.
А нужды остальных закроют слайсы.

Идентификаторы (имена переменных, функций и пр.) могут быть в юникоде.
В смысле, можно писать программы по русски, китайски и как угодно.
Интересно, как мы будем читать китайские или индийские программы? Я иероглифы не разбираю.

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

Интерфейсы и типы без иерархии приводят к потрясающему упрощению их совместного применения.
Похоже так и есть. Но к этому надо привыкать.

Перегрузки методов и операторов нет.
На мой вкус, так и даром не надо. Полностью согласен с аргументацией авторов.

Неявного преобразования чисел нет.
А обещали "чувствуется как динамический язык". Забавно.

Модель поддержки параллелизма выросла из Взаимодействующих Последовательных Процессов (CSP -Communicating Sequential Processes).
Блин, надо срочно найти букварь на эту тему.

goroutines - вместо тредов. Идея в мультиплексировании функций выполняющихся независимо. Есть набор тредов - работяг, на них оно и едет. Один блокируется, горутины переводятся на другой, едущий. Экономно, стек маленький, удобно.
Видимо, рантайм может иметь заточку под железо, тогда вместо тредов можно использовать процессы? И столько, скольно ядер в камнях?

Операции с map-ами не безопасны, в смысле параллельности. Неконтролируемой работой с мэпами в многопоточной программе можно ее поломать (программу).
По статистике авторов, мэпы редко используются таким образом. Поэтому сэкономили.
А обещали "безопасность". Как интересно.

Что в итоге:

Складывается впечатление, что это будет более безопасный Си, не такой развесистый как С++ и с намеком на динамичность, типа Питона, но сильно не Питон.
Ну типа да, Си, но лучше. Параллельные системные программы писать будет легче и их смогут писать менее квалифицированные программеры (чем сейчас). Что приведет к массе низкокачественных программ очень быстро глючащих на оченьмногоядерных камнях. Гы, это плохой прогноз.
Хороший прогноз - в языке будут решены потенциальные пробелы в безопасности (с помощью пакетов проверенных библиотек от Интел сотоварищи) и мы увидим много хороших программ и довольных программистов. Высокие профессионалы Си-шники будут недовольны.