[prog.flame;humour] А ведь на самом деле интересно где же доказательства, что .NET и Java с GC лучше, чем Rust?

Этот вопрос я впервые озвучил в Facebook-е четыре года назад. Прошло столько времени, а он, как мне кажется, все еще остается актуальным.

Вот, кстати, вспомнился еще один момент, который забавляет, когда Rust начинают противопоставлять Java и .NET-у.

Ведь в Rust-е же, по сути, такая же система управления памятью, как и в C++. Есть автоматическая память. Есть динамическая. В динамической есть аналог unique_ptr (Box), есть аналог shared_ptr (Rc, Arc).

Да, Rust следит за тем, чтобы вы корректно работали со своей памятью. Но ведь система не меняется. Либо ограниченное скоупом время жизни (автоматические переменные, Box), либо подсчет ссылок (Rc, Arc).

Но где же аргументы со стороны языков с GC о том, что подсчет ссылок -- это удар по производительности? Где убедительные бенчмарки, которые показывают, что стоимость аллокации в языке с GC -- это всего лишь инкремент одного указателя на вершину хипа? Где упоминание такой фундаментальной проблемы, как фрагментация памяти (которой, как все знают, подвержены поголовно все программы на C++)? Где напоминание о таком волшебном средстве, как compacting GC?

Где, где все те срачи, в которых сторонники Java и C# так яростно убеждали нас, что GC гораздо лучше для управления памятью, чем ручная работа? И не только с точки зрения безопасности. Но и с точки зрения производительности.

А?

[prog.c++] Впечатлился рассказом RisingWave Labs о переписывании cloud database с C++ на Rust

История от стартапа RisingWave Labs: "Building a Cloud Database from Scratch: Why We Moved from C++ to Rust". И дополнение к ней в виде интервью с основателем этого стартапа Yingjun Wu на medium: "The founder of the database rewrite with Rust is back: Was it worth deleting 270,000 lines of C++ code?" (только осторожно, это интервью на medium под звездочкой, поэтому открывать лучше в incognito window, чтобы не нарваться на ограничение по числу бесплатных просмотров).

История хорошая. Если вкратце: некий стартап решил запилить новую cloud database (чтобы это не значило) и начал пилить на C++, т.к. C++ вполне себе естественный выбор, плюс у этих людей был опыт в C++ (а сам Yingjun Wu, как выяснилось в интервью кроме как на C++ больше ни на чем проектов не делал). Пилили-пилили семь месяцев, забабахались вылавливать баги и бороться с проблемами управления зависимостями. И решили все переписать на Rust. Что и сделали. За пару месяцев (да, всего за пару месяцев).

В общем, история реально хорошая и поучительная, посему рекомендую обратиться к первоисточникам, чтобы я не оказался испорченным телефоном.

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

Здесь же я попробую сформулировать свое впечатление о том, как RisingWave дошли до жизни такой, затрону несколько показавшихся мне странными моментов, попробую высказать свое мнение о том, как использовать на C++, чтобы затем не пришлось переписывать все на другом языке программирования.

Кому интересно милости прошу под кат.

[life] Посмотрел интервью Олега Тинькова на канале "Русские Норм!" Зачем-то

Где-то, если не ошибаюсь, в LinkedIn, увидел небольшую подборку фрагментов из этого интервью, захотелось посмотреть полную версию. Посмотрел. Жалею о потраченном времени.

Собственно, вот: https://www.youtube.com/watch?v=AsB3aGyl62Y

Главное впечатление: зачем вообще слушать Олега Тинькова в вопросах, которые не касаются бизнеса?

У многих людей есть такой стереотип: если человек достиг успеха на каком-то поприще, то его мнение становится более весомым даже по вопросам, которые не имеют отношения к этом самому поприщу.

Вроде бы тем, кто застал СССР в уже сознательном возрасте, такие вещи должны бы быть знакомы. Вот, например, были в СССР отличный актер Олег Басилашвили и прекрасный режиссер Станислав Говорухин. Авторитеты в своем ремесле. Известные люди. К мнению которых многие прислушивались. И, что ужасно, прислушивались даже когда Басилашвили и Говорухин рассуждали не о кино или актерском мастерстве, а о политике и управлении государством.

Теперь уже и непонятно почему прислушивались.

Вроде бы прошло больше 30 лет, можно было бы сделать соответствующие выводы.

Но нет. Наверное, выросло новое поколение.

Примечательно, что Олег Тиньков сам же обозначил два ключевых момента, которые позволяют смело направлять изрядную часть его высказываний прямиком в /dev/null.

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

Во-вторых, он признал, что последние годы, когда он бывал в России, он жил как бы в изолированном пузыре, слабо представляя себе что такое остальная Россия. Но теперь ставит диагнозы и делает прогнозы для всей страны.

---

Для меня важным триггером стали два момента, озвученных Тиньковым когда он пытался сравнивать уровень развития России и США:

• выработка электроэнергии в США в 50 (пятьдесят, это не моя опечатка, сам Тиньков на этом внимание заострял) раз больше, чем в России. Первая же ссылка в Гугле идет на Wikipedia (со ссылкой на British Pertroleum), где сказано, что за 2021-й год в США было произведено 4406 ТВт-ч, тогда как в России -- 1157 ТВт-ч.
• протяженность железных дорог в США и России. Опять же, смотрим в Wikipedia и видим, что на 2022-ой год суммарная длина ж/д в США 293564км, тогда как в РФ всего 85500км. Казалось бы да, существенная разница (хотя здесь надо было бы учесть и длину дорог в бывших республиках СССР, и даже в Польше и Финляндии, которые когда-то входили в состав Российской Империи). Но вот если послушать знающего человека, то окажется, что не все так однозначно и не в длине счастье.

---

В общем, в вопросах бизнеса и маркетинга Олег Тиньков, для меня лично, величина.

А вот зачем слушать его мнение на счет геополитики мне не понятно.

[life.cinema] Кратко о фильме "На Западном фронте без перемен" 2022-го года

Посмотрел на выходных новый фильм от Netflix "На Западном фронте без перемен", по мотивам одноименной знаменитой книги Ремарка.

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

Книгу "На Западном фронте без перемен" прочитал в выпускном классе школы и она перевернула мои представления о том, что из себя представляет война. Т.к. в советских книгах о войне, которые издавались в 60-70-х и начале 1980-х, такой жести именно про быт на войне, про ощущения простого человека, не писалось. Ну или мне не попадалось. Подозреваю, что наши редакторы и цензоры намеренно щадили читателей, особенно молодых, тех, кто о войне мог знать лишь из рассказов дедушек и бабушек. А вот Ремарк цинично срывает с читателя розовые очки героической военной романтики.

Поскольку сама книга на меня произвела сильное впечатление, то фильм удивить чем-то не смог. Да я, собственно, и не ожидал.

Посему, если говорить в двух словах, то получается как-то так: если вы читали книгу, то фильм можно и не смотреть. А если книгу не читали, то лучше таки ее прочесть, а кино можно и не смотреть.

Пожалуй, главное, чего не хватило именно мне -- это передачи мироощущения молодых людей, которые после войны были названы "потерянным поколением" (к которым, помнится, принадлежал сам Ремарк). Вчерашние школьники, которые попали на фронт прямо из-за парты. И которые ничего, кроме войны, не видели, и ничего, кроме войны, не умеют. И которые не понимаю ради чего на этой войне выживают. И не знают, что их ждет позже. Дилогия Ремарка "На Западном фронте без перемен" и "Возвращение", как мне показалось, именно про это.

Тогда как фильм от Netflix, по ощущениям, пытается сконцентрироваться только на том, что война -- это ужас-ужас. И все, не более того.

Еще одним недостатком, опять же для меня лично, стало то, что фильм снят в какой-то "фестивальной манере": длинные паузы, крупные планы, взгляды главных героев чуть ли не прямо в глаза зрителю и вот это вот все. Как по мне, так все это разрушало динамику и лишало происходящего нерва.

Визуальная часть вполне себе OK, хотя даже здесь нет никаких открытий и откровений. Спасти рядового Райана, Во имя чести и 38-я параллель задрали здесь планку качества так, что не только лишь все могут до нее дотянуться.

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

В общем и целом, не шедевр, но по нынешним временам вполне себе добротный фильм про ужасы войны. Однако, исходная книга куда страшнее.

[work.memories] Понравилась мне на Хабре статья от корпоративного архитектора в Сбербанке

Отличная статья: Как я в зеленом банке архитектором работал.

Думал просто просмотреть по диагонали, но залип.

Вспомнилось всякое из прошлого, т.к. в свое время доводилось иметь дело с разработкой для банков (к счастью, не долго и немного), и для этого самого зеленого банка в частности :)

Я у себя в VK недавно давал ссылку на свой старый текст в блоге, а там был вот такой фрагмент:

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

Если кому-то показалось, что я преувеличивал, то почитайте вышеупомянутую статью на Хабре :) Думаю, что в мое время в Сбербанке регламенты были послабже и вопросы решались несколько быстрее...

Вообще статья вызвала массу эмоций. Одна из самых сильных -- это ощущение того, насколько же я стар для всего этого дерьма. Думаю, что время давно уже показало, что моя вотчина -- это маленькие проекты силами крошечных команд, где каждый играет все доступные роли, от бизнес-аналитика и солюшен-архитектора (что бы это не значило на мелком проекте), до тестировщика, технического писателя, внедренца и специалиста всех линий техподдержки сразу. И где главный принцип "если не ты, то никто".

Кстати говоря, приведение в чувства оставшихся без присмотра копролитов мамонта, так же зачастую попадает в эту категорию.

Вероятно, я один из немногих "последних из могикан", кто не только умеет, но и любит так работать. И для таких как я работы на рынке уже просто не остается от слова совсем.

Но, тем не менее, как вспомню всю эту корпоративную херню, так не по себе становится.

Кстати, о корпоративной херне. Последние пару лет работы в "Интервэйле" прошли под знаком попыток перехода на бюрократизированные рельсы. Фактичести, менеджеры с бэкграундом в банковской сфере попытались перестроить правила работы софтверной компании. Со всеми вытекающими.

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

И ведь разбирались, что характерно.

Ну и последнее впечатление, которое хотелось бы озвучить, -- это степень наивности автора статьи. На вот этом вот фрагменте:

Корпоративный архитектор же, наоборот, снимает сырую информацию напрямую с бизнес заказчика, а не получает сухую техническую выжимку, прошедшую до него несколько рук. Для решения задач у него есть бесконечный инструментарий из возможностей: использовать существующие решения или подготовить требования для разработки чего-то нового. Даже если используются существующие компоненты, необходимо проработать сценарии использования, подготовить описание интеграций, договориться со всеми стейкхолдерами о необходимых доработках их продуктов. А как завораживающе смотрится этот высоколобый муж у вайтборда, рисующий многозначительные диаграммы. И главное, он участвует в трансформации компании, приносит свежие решения, оптимизирует текущие процессы, каждое его действие наполнено глубоким смыслом и пользой для организации и ее продуктов, по крайней мере, я так думал.

Мой мимиметр зашкалил от уровня мимишности этих ожиданий.

Какой "наивный чукотский юноша" :) Говорю это без отрицательных конотаций. Просто лучшего афоризма для обозначения столь высокой степени наивности не вспомнилось.

PS. Никаких практических выводов и сухого остатка не будет. Просто захотелось поделиться впечатлениями.

[life.cinema] Очередной кинообзор (2022/10)

Подошло время очередного отчета о просмотренных за минувший месяц фильмах. По традиции в начале располагаются фильмы/сериалы, которые понравились больше, ну а в самом конце списков -- откровенный шлак.

Фильмы

Добрый медбрат (The Good Nurse, 2022). Хорошее кино. Но! Его нужно смотреть не читая предварительно описание того, о чем эта картина. Иначе никакой интриги не будет, останется только наблюдать за хорошей игрой актеров.

Массовый побег (Pacto de Fuga, 2020). Нормальный фильм, даже не хочется ни к чему придираться. Но, все-таки, мне не хватило какого-то нерва, чтобы переживания за главных героев нарастали и к концу фильма достигли своего апогея.

Большой куш (Jipuragirado japgo sipeun jimseungdeul, 2020). Мне зашел, но мне нравятся такого рода истории, когда куча независимых на первый взгляд сюжетных нитей в итоге тесно переплетаются. Разве что динамизма хотелось бы чуть побольше.

Лучшие в аду (2022). Суровое кино. Пожалуй, лучшее на военную тематику за последний год (если не больше). Меня, правда, сильно раздражали вставки с пояснениями и ТТХ вооружений. Однако, думаю, что если бы этих вставок не было, то фильм бы воспринимался еще более суровым и трагичным.

Бандит (Bandit, 2022). Так себе кино. Потенциально интересную историю рассказали настолько убого, что получился какой-то дешевый водевиль.

Код Красный (Red Joan, 2018). Красиво, добротно. И не такой шлак, как "Красный воробей". Но, тем не менее, явно снято для внутреннего потребления нашим "вероятным противником", с замшелыми штампами про кровавого тирана Сталина и преувеличением значимости английской ядерной программы во время Второй Мировой войны.

Быстрее пули (Bullet Train, 2022). Динамично, да и снято весьма качественно. Но вот в меня не попал совершенно. Какой-то юмористический комикс на фоне горы трупов и жестоких убийств.

Человек из Рима (The Man from Rome, 2022). Из хорошего только отличная операторская работа. Все остальное откровенная халтура, начиная от шаблонно-картонных персонажей и заканчивая откровенно дерьмовой постановкой тех немногих сцен с рукопашными схватками, которым нашлось место.

Средневековье (Jan Žižka, 2022). Мне фильм показался затянутым и плохо раскрывающим суть происходящих событий (кто кем и кому приходился и из-за чего весь сыр бор). Да и работа оператора меня, мягко говоря, раздражала.

Сериалы

Дивный новый мир (Brave New World, 2020, первый сезон). Сам исходный роман не читал, поэтому оцениваю только то, что увидел и понятия не имею насколько это все соотносится с оригиналом. Снято красиво. Но, такое ощущение, что фильм должен быть интересен разве что молодой аудитории, лет до 25, может быть до 30, пока еще гормоны бурлят. Для людей постарше эта вся излишняя концентрация на сексе выглядит уже странно.

Художник (первый сезон, 2021). Редкостная халтура. Смело можно не смотреть.

Кино вне категории

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

[prog.c++] Дикая идея о том, как можно было бы еще улучшить fmtlib и std::format

Навеяно срачем на RSDN вот в этой теме.

По сути, там были указаны реальные проблемы, которые есть при использовании fmtlib и, соответственно, std::format.

Одна из этих проблем в том, что для описания форматера для моего типа T мне нужно делать специализацию для fmt::formatter, а это нельзя сделать в моем пространстве имен. Поэтому, если я в своем пространстве имен только что определил тип T, то мне нельзя здесь же определить и фоматтер для него, нужно сперва закрыть свое пространство имен, а потом открыть его вновь.

Еще одна проблема показана вот в этом комментарии. Позволю себе процитировать:

Сейчас также все не сахар. Форматер в виде специализации класса не вызывается и всё, пока ты правильно не подберёшь синтаксис перегрузки. С шаблонными классами это бывает не очень просто. Вот пример у меня в коде:

namespace htlib::v2 { template<typename type_t> struct is_point {     static std::false_type test(...);     template<htlib::v2::uint_t dimensions, typename other_t>     static std::true_type test(const htlib::v2::pointxd_t<dimensions, other_t>&);     static constexpr bool value = decltype(test(std::declval<type_t>()))::value; }; template<typename type_t> inline constexpr bool is_point_v = is_point<type_t>::value; } // namespace htlib::v2 template<typename char_t, typename point_t> class std::formatter<point_t, char_t, std::enable_if_t<htlib::v2::is_point_v<point_t>>> { //... }

Вот такие мета-функции приходится писать что бы написать форматер для всех наследников базового шаблонного класса.

Хотя в случае с функциями была простая перегрузка, типа:

template<htlib::v2::uint_t dimensions, typename other_t> void formatter(const htlib::v2::pointxd_t<dimensions, other_t>&);

В обсуждении прозвучала идея о том, что лучше бы было, если бы за парсинг и форматирование значений отвечали бы не классы, а свободные функции. Свободные функции могли бы размещаться в пространстве имен пользователя, соответственно, они бы подхватывались посредством ADL.

Очень хорошо выгоды от свободных функций сформулированы здесь:

если бы std::format для кастомизации использовал бы не шаблон класса со специализациями, а неквалифицированный вызов функции с каким-то предопределенным именем, это могло бы дать ряд преимуществ:

• Пользователь мог бы определять кастомные форматтеры в том же пространстве имен, что и пользовательские типы. Это удобнее писать и удобнее читать, потому что не нужно рвать пространства имен или выносить определения в какие-то отдельные места;
• При определении кастомных форматтеров пользователь мог бы использовать дополнительные параметры по умолчанию — как в списке шаблонных параметров, так и в списке формальных параметров функции, что дает возможность использования SFINAE и вообще дает большую гибкость в тех случаях, когда кастомизацию нужно сделать не для одного конкретного типа, а для какого-нибудь сеймейства типов, объединенных каким-то признаком;
• Как частный случай — форматтер, определенный для базового класса автоматом будет работать и для всех производных, для которых не предоставлена своя собственая версия форматтера;
• Используя квалифицированные вызовы, пользователь мог бы внутри кастомго форматтера повторно использовать форматтеры из других пространств имен, что дает возможность декорирования форматтеров.

Хотя лично мне перспектива писать свободные функции parse и format для своих типов не очень нравится, имхо, класс formatter с методами parse и format для таких целей удобнее, имхо. Да и совместимость с уже написанным кодом терять не хочется, так что подход со свободными функциями должен как-то сочетаться с уже написанными formatter-ами.

Посему возникла дурацкая идея о том, как можно подружить оба эти подхода.

Суть в том, чтобы оставить класс formatter как он есть. Но не создавать его напрямую, а получать посредством свободной функции-фабрики. Как раз эту самую функцию-фабрику можно будет определить в собственном пространстве имен рядом со своими типами.

Под катом слепленный на коленке за 10 минут пример того, как это может быть.

Насколько это все реально внедрить в fmtlib не знаю. Заглянул в исходники, но там не то, чтобы все сложно. Но это таки большой проект, в котором я ни бум-бум. Сходу не разобраться.

А копать глубоко нет возможности. Я тут, к сожалению, слегка зашился и чувствую, что едва хватает сил на выполнение обязательств по текущему проекту. Даже за PR для RESTinio не могу взяться :(

Поэтому зафиксирую идею здесь, в блоге. Если у кого-то из читателей будет желание довести это все до мейнтейнеров fmtlib, то хорошо. Если нет, значит кто-то другой придумает что-то получше и сможет довести до внедрения и реализации.

Напоследок скажу, что на RSDN-е были таки обозначены актуальные проблемы, с которыми люди сталкиваются в fmtlib и std::format. И было бы хорошо тем или иным способом решить эти проблемы. Наверняка способы найдутся.