суббота, 10 июня 2017 г.

[prog.c++] В очередной раз про Rust. О том, почему до сих пор меня Rust не прельстил

На C++ я программирую уже давно. Лет 25 точно. Не могу сказать, что знаю C++ хорошо, но, наверное, хорошо знаю, как использовать C++ так, чтобы не было мучительно больно. Тем не менее, не могу не признать, что C++ уже весьма стар, сложен и противоречив. Хоть программировать на нем в последнее время становится удобнее, но есть серьезные родовые травмы, которые будут постоянно отравлять жизнь C++ разработчикам. Посему лично я был бы не прочь со временем сменить C++ на что-то более современное, удобное и безопасное.

На мой взгляд, из того, что сейчас существует для разработки из нативных языков без GC, самой реальной и серьезной альтернативой для C++ является язык Rust. Так же мне кажется, что Rust -- это всерьез и надолго. Как много Rust переманит именно C-шников и C++-ников -- это отдельный вопрос, думаю, что изрядное количество Rust-программистов будут составлять те, кто пришел в Rust не из мира C/C++, а из мира безопасных языков с GC и, вероятно, из мира функциональщины.

Сам я пока в Rust всерьез не вложился и причины тому вовсе не какие-то идеологические, а весьма прозаические. Мы с коллегами пытаемся создать бизнес вокруг инструментария для программистов. Что именно начнет приносить нам деньги -- продажа продуктов, продажа коммерческих лицензий, обучение, консалтинг, заказная разработка или что-то другое -- это выяснится со временем. Поскольку у нас большой опыт в C++, то сейчас мы концентрируемся именно на инструментарии для C++. Ибо здесь есть рынок: по некоторым оценкам количество C++ разработчиков в мире насчитывает более 3 миллионов человек, накоплена огромная кодовая база на C++, которая никогда не будет переписана на других языках, да и новые проекты на C++, пусть не часто, но начинают (и выбор C++ в качестве языка реализации нового проекта в современных условиях вполне имеет смысл). Так что в области C++ есть и какой-никакой рынок, и нам есть что на нем предложить.

А вот для Rust-а такого рынка, насколько я могу судить, пока еще нет. Вроде как есть какой-то совсем небольшой спрос на Rust-разработчиков, но вряд ли сейчас найдется много желающих покупать коммерческие библиотеки для Rust-а, или коммерческие лицензии на такие библиотеки. Да и вряд ли кто-то будет готов платить за консультации по Rust-у или за обучение Rust-у разработчиков, переходящих на Rust с других языков программирования. Думаю, что не ошибусь, если скажу, что не смотря на весь хайп вокруг Rust-а, реальное присутствие Rust-а в коммерческой разработке ПО в мире находится где-то на уровне статпогрешности. Посему достаточно емкого рынка инструментария для Rust-а еще просто нет. Может через 3-5 лет такой рынок сложится и достигнет достаточного объема, чтобы на нем можно было бы зарабатывать. Но сейчас это не так.

Ну а поскольку самый дефицитный ресурс -- это время, то я пока не вижу смысла тратить этот ресурс на Rust, если его можно потратить на что-то с более реальными перспективами продажи. И это, наверное, главная причина, почему мы до сих пор не вложились в Rust. Хотя из поля зрения его и не выпускаем.

Но сегодня я бы хотел затронуть еще один аспект. Он касается того, насколько сильно придется перестраивать мозги старому C++нику, вроде меня, при переходе с C++ на Rust. И будет ли такая перестройка того стоить.

среда, 7 июня 2017 г.

[prog.c++] Жалел ли кто-нибудь об отсутствии Erlang-style супервизоров в SObjectizer?

Вопрос к тем читателям блога, которые в какой-то мере интересуются SObjectizer-ом: возникало ли у вас при знакомстве с SObjectizer-ом сожаление о том, что в SObjectizer-е нет механизма супервизоров, как в Erlang-е?

Вопрос вызван тем, что сейчас дополнительный проект so_5_extra, который мы хотели бы зарелизить в этом месяце, наполняется функциональностью. Наш интерес состоит в том, чтобы добавить в so_5_extra вещи, которые бы были востребованы потенциальными и актуальными пользователями SObjectizer-а. Если кому-то в SObjectizer не хватает Erlang-овых супервизоров, то мы могли бы их реализовать в so_5_extra вне зависимости от моих персональных взглядов на этот счет.

Ну а если никому не нужны, то "раз врач сказал в морг, значит в морг" :) Все-таки работа с небезопасным C++ сильно отличается от работы с безопасным Erlang-ом.

PS. Здесь можно высказать любое соображение касательно того, чего не хватает в SObjectizer. Или что хотелось бы видеть сделанным по-другому.

PPS. Сейчас в so_5_extra уже есть однопоточная инфраструктура, позволяющая запустить SO-5 с использованием Asio в качестве бэкэнда. В варианте simple_not_mtsafe. Кстати, нужна ли кому-нибудь такая же инфраструктура в варианте simple_mtsafe или инфраструктура, которая позволяет использовать Asio-бэкэнд при работе Asio на пуле потоков? Так же в so_5_extra уже есть реализация round-robin mbox-а. Пока мы закрываем ряд юридических вопросов вокруг so_5_extra, есть возможность включить в so_5_extra еще что-нибудь полезное. Например, те же самые супервизоры, если они кому-то нужны.

понедельник, 5 июня 2017 г.

[prog.thoughts] Внезапное осознание момента в модели publish/subscribe и топиков с wildcard-ами в именах.

Внезапно поймал себя вот на чем: есть publish/subscribe, которая доступна посредством разнообразных MQ-шных брокеров (т.к. IBM WebSphere MQ, RabbitMQ или mosquitto). Там можно подписываться на топики, в именах которых есть wildcard-ы (спецсимволы вроде +, * и #). Например, кто-то публикует сообщение в топике с именем /temperature_sensors/floor/1/n001/value. А приходит это сообщение к тем, кто подписался на топики /temperature_sensor/floor/+/+/value и /temperature_sensors/floor/#.

Так вот, внезапно осознал, что в 90% случаев (а может и в 99.9%) при использовании wildcard-ов нужно иметь точное имя топика, в котором сообщение опубликовано. Т.е. в 90% случаев нужно не только уметь подписаться на /temperature_sensors/floor/+/+/value, но нужно еще обязательно вместе с сообщением получить и имя топика (будь то temperature_sensors/floor/1/n001/value или temperature_sensors/floor/10/n100_10_03/value). Без знания точного имени нет пользы от самого лишь сообщения из топика.

PS. Понятно, что я старый тормоз. Но когда пользуешься готовыми MQ-брокерами, в которых имя топика-источника сообщения есть всегда, то об этом не задумываешься. А вот когда размышляешь о чем-то таком собственном, то вдруг осознаешь, что этой "мелочи" раньше даже и не замечал.

PPS. А вообще это пост на тему о том, как полезно использовать "проектирование на бумаге" с очень ранними прикидками того, как то, что ты хочешь сделать, должно будет использоваться. На реальных или более-менее похожих на реальные примерах.