[prog.c++] Идея развития темы, начатой в статье "A declarative data-processing pipeline on top of actors? Why not?"

Давеча опубликовал на Хабре большую статью на английском языке "A declarative data-processing pipeline on top of actors? Why not?", в которой описал старый, но доведенный "до ума" пример make_pipeline из состава SObjectizer-а. К самой статье Григорий Демченко задал интересные вопросы в комментарии. Плюс на Reddit-е подсунули ссылку на (как мне показалось) недоделанную и полузаброшенную библиотеку RaftLib.

В общем, появилось навязчивое желание сделать продолжение этой темы.

По сути, тема создания пайплайнов (или графов в общем случае) обработки данных на C++ состоит из двух частей. Можно сказать, что есть верхняя и нижняя части проблемы.

Нижняя часть -- это то, как работа распределяется по рабочим контекстам. Т.е. это вопросы, связанные с тем, что из себя на самом деле представляют стадии пайплайна, как стадии привязываются к тем или иным рабочим нитям, как происходит передача информации между стадиями пайплайна. В принципе, нижнюю часть не обязательно делать с нуля самому. Можно использовать какой-то готовый инструмент. Скажем, Intel TBB. Или, как в моем случае, SObjectizer. С нижним уровнем связано несколько вопросов и мне хочется посмотреть, какие ответы на эти вопросы может (и может ли) предоставить SObjectizer.

Верхняя часть -- это тот DSL, который будет предоставляться пользователю для конструирования своих пайплайнов. И здесь есть ряд интересных и не исследованных для меня вопросов. Начиная от того, какую функциональность пользователь сможет получить в свои руки. И заканчивая тем, как выразить эту функциональность в C++ коде, дабы получить контроль за какими-то ошибками прямо в compile-time.

Пока что есть желание потратить несколько дней на эксперименты в этой области. Первые соображения о том, какие цели преследуются и какие мысли уже есть, изложены под катом. Кому интересно, милости прошу подключаться к обсуждению.

[prog.flame] Почему Rust может быть намного более пригоден для прикладного программирования, чем C++

Несколько запоздалое дополнение к двум постам с прошлой недели (раз, два). Хочу немного поговорить о неоднократно услышанном от Rust-евангелистов мнении, что Rust отлично подойдет не только для системного (и околосистемного) программирования, но и для прикладного.

Лично для меня не понятно, зачем тянуть в прикладное программирования языки без GC. Т.е. как вспомогательный инструмент для устранения узких мест и повышения производительности каких-то операций -- это понятно. Но как основной язык для всего приложения?

Прежде чем пойти дальше отпрыгнем в сторону и попробуем хоть как-то определить само понятие "прикладного программирования". По большому счету к прикладному программированию можно отнести все, что не касается системного и низкоуровневого программирования. Т.е. если код не решает каких-то специфических задач, интересных только программистам (ядро ОС, компилятор, линкер, MQ-шный брокер, сервер БД, утилита типа grep и т.д.) или не управляет каким-то оборудованием (вроде бортового ПО автомобиля или самолета), то это прикладное ПО. К сожалению, в этом случае в "прикладное ПО" попадает слишком большой спектр софта: скажем, от Microsoft Word или Adobe Lightroom до склепанного на коленке в Wordpress сайта-визитки. Но есть подозрение, что если попытаться конкретизировать термин "прикладное ПО", то возникнет ощущение насильственной подгонки условий под нужный результат. Посему более жестких условий накладывать не будем.

Итак, есть тезис о том, что Rust отлично подойдет для прикладного программирования...

[prog.sadness] Похоже, разработчики D решили закопать свой язык еще глубже

За последние месяцы я несколько подзадолбался как с разработкой на C++, так и с общением с придерживающимися разных взглядов C++никами, так и c продвижением наших C++ных разработок в сильно сегментированном C++ сообществе. Настолько, что стал уже мечтать о том, чтобы закрыть ближайшие "долги" по работам вокруг SObjectizer-а и устроить себе отдых от C++. Пропрограммировать что-то для души на чем-то более современном и удобном, чем C++.

На D.

А вот сегодня на HackerNews увидел ссылку на статью Вальтера Брайта (это автор D и его основной разработчик) про возможность добавления в D механизмов Ownership и Borrowing из Rust-а. Смысл статьи в том, что изначально Брайт думал, что borrow checker из Rust в D не запихнуть, но потом у него появились идеи, которые Брайту кажутся вполне себе реализуемыми. Поэтому Брайт начинает активно копать в этом направлении.

Ну что тут сказать. Один раз Брайт и Ко уже основательно поднасрали своему детищу. Это кода в 2008-го году, всего через полгода после официального релиза D 1.000 было заявлено, что начинаются работы над D2, который будет несовместим с D1. Сказано это было в тот момент, когда вокруг D не было никакой существенной экосистемы и количество нормальных библиотек для D измерялось, в лучшем случае, несколькими десятками.

Да, D2 получился гораздо более интересным и мощным языком, чем D1. Но лет через шесть после D 1.000. И, по факту, он появился уже тогда, когда окно возможностей для D захлопнулось благодаря C++11/14, Go, хайпу вокруг Rust-а. Так что D отличный язык для небольших проектов маленьких команд и энтузиастов. Но широкого применения ему, увы, уже не светит.

А тут в D хотят впихнуть еще одну мегафичу. И мне непонятно нахрена это нужно делать :(

Ну вот основная фишка в том, что это продвинутый язык с GC для нейтива. И как раз GC дает D те преимущества, о которых C++никам остается только мечтать, если на C++ пытаться разрабатывать что-то более-менее высокоуровневое.

Казалось бы: ну и развивайте D как язык с GC. У вас и в этой области работы будет выше крыши. Зачем вы еще куда-то лезете? Делаете GC отключаемым, придумываете какой-то betterC... Теперь вот еще и borrow checker в язык затаскиваете...

Ну вот явно "чувство меры" -- это не то, что свойственно разработчикам D.

Пичалька, что еще скажешь. Вот так и разрушаются мечты :(