[prog.flame] Адекватен ли выбор языка программирования для такой задачи (Rust для Radicle)?

Часто говорят, что язык программирования нужно подбирать под задачу. Мол, не нужно брать C++ для того, что легко делается на Python. И не нужно брать Python там, где потребуется что-то более быстрое и менее ресурсоемкое.

Недавно узнал о Radicle -- это что-то вроде GitLab и Gitea, т.е. инструмент для совместной работы над программным кодом.

Radicle написан на Rust-е.

Не на Python-е. Не на Ruby. Не на Node.js. Не на Java или C#. Не на Go. А на Rust-е.

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

Посему лично я в недоумении и сам бы для проекта, подобного Radicle, точно бы не стал брать C++ или Rust. Как по мне, так здесь достаточно языка со сборкой мусора: Java, Kotlin, C#, возможно даже Go (простите, динамика в лице Python/Ruby/JavaScript идет лесом, т.к. не из тех мазохистов, которые делают что-то большое на динамически-типизированных языках).

А вот брать нативный язык без GC с претензией на околосистемность... Зачем?

Собственно, непонимание и привело к появлению этого поста. Надеюсь, в комментариях мне напихают в панамку и объяснят насколько я дебил и отстал от современных трендов. Ибо я реально не понимаю, почему в 2020-х нужно отказываться от всего, что накопилось в мире безопасных языков с GC и трахать себе мозг Rust-ом в задаче, где не нужна ни супер-пупер производительность, ни супер-пупер экономия ресурсов, ни тотальный контроль за происходящим.

---

Если не лень, то напишите в комментариях, плиз, какой бы вы язык программирования предпочли для реализации проекта по типу Radicle/GitLab/Gitea. Я бы лично выбирал бы между C#, Kotlin и Go (хотя не на одном из них не программировал), но точно бы не C++ и не Rust.

[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++, чтобы затем не пришлось переписывать все на другом языке программирования.

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

[prog.flame] Стабильному Rust-у исполнилось 6 лет

Шесть лет назад состоялся релиз "стабильной" версии Rust 1.0. Так что именно с 15-го мая 2015 года можно смело отсчитывать возраст языка программирования Rust.

Давеча в FB я уже высказался на эту тему. А данный пост можно рассматривать как расширенную и дополненную версию FB-шной заметки.

Революции не случилось

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

[prog.flame] В этих наших Интернетиках уже начали закапывать Rust?

Как я могу видеть, новость о том, что экспериментальный браузерный движок Servo, который долгое время был флагманской разработкой на Rust-е, передан под крыло Linux Foundation, вызвала разговоры о том, что к Rust-у постепенно приближается северный пушной зверек. Типа сперва Mozilla выгнала команду разработчиков Rust-а на мороз, теперь вот Servo отправили в могильник. И светлое будущее, о котором так много говорили растофанаты, неизбежно сменяется унылым настоящим с беспросветными перспективами...

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

Или, другими словами, Rust скорее всего переживет многих, кто ждет его смерти. Как это уже случилось с COBOL-ом и Fortran-ом.

Да, Rust лишается хорошей крыши. И вряд ли обретет другую такую же.

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

Кто-то, наверное, может сказать, что по сравнению с Python-ом того же Ruby и нет. Но по факту, всего трем-четырем языкам довелось получить популярность и распространенность, которая есть у Python-а (в их число входят, наверное, еще чистый C, Java и JavaScript). Все остальный вынуждены довольствоваться лишь долей той распространенности, которой обладает Python.

Так что если со временем популярность и распространенность Rust-а окажется на уровне нынешней популярности и распространенности Ruby, то Rust спокойно проживет еще не одно десятилетие.

---

Есть несколько моментов, которые лично меня заставляют думать о том, что будущее у Rust-а все-таки не такое радужное, как многим рисуется (хотя и быстрая смерть Rust-у не грозит).

Во-первых, это величина хайпа, который все еще сопровождает Rust. Я ничего подобного не могу припомнить со времен пришествия Java. Но там-то были миллионы долларов, целенаправлено вложенных Sun-ом в маркетинг. В случае же с Rust-ом хайп генерируют восторженные пользователи. И это странно. Ну не может быть у Rust-а такой армии активно использующих его программистов. Большая часть раздувателей хайпа -- это просто сочувствующие, не написавшие на Rust-е ничего сложнее очередного HelloWorld-а.

Так что здесь я жду пока маятник качнется в другую сторону. Должен же. И если таки да, то будет интересно посмотреть, во что все это выльется.

Во-вторых, это ниша применения Rust-а.

Да, вероятно, Rust -- это лучшая замена чистого C и даже C++ на данный момент. Проблема, однако, в том, что сама ниша применения C и C++ в последние годы сужается. И это правильно. Так что, в перспективе, для массового софтостроения Rust так же (не)нужен, как и C++.

Поэтому полагаю, что для многих Rust является отдушиной после мира Java, C#, Python-а, JavaScript-а и Ruby. Которые либо не слишком быстрые, либо слишком тяжелые (в плане run-time). И Rust у этих людей вызывает восторг потому, что пока что не видно хорошего, простого и удобного языка с GC, который бы компилировался в нативный код и не требовал бы таскать за собой многомегабайтные JVM/.NET.

Таким языком мог бы в свое время стать D. Но не стал.

Зато таким становится Go. Хотя Go все-таки пока слишком убог и не нравится тем, кто привык к традиционному ООП, полноценным генерикам (шаблонам) и синтаксическому сахару.

В общем, думаю, что если бы на данный момент были полноценные и кросс-платформенные условные JavaNative, C# Native или KotlinNative, то и интерес к Rust-у со стороны нынешних JavaScript-еров и Python-истов был бы гораздо меньше.

А вообще, вот этот пост почти что двухлетней давности еще не утратил своей актуальности ;)

[prog.flame] Тут опять поднимается волна хайпа вокруг Rust-а, а мне интересно, насколько просто будет на Rust-е...

...делать какие-то вещи из привычной мне окружающей реальности.

Данный пост навеян двумя факторами:

• после поверхностного знакомства с Rust-ом при написании кода на C++ я зачастую задумываюсь о том, а как такие же вещи можно было бы сделать на Rust-е и насколько бы сложно было бы объяснить Rust-овому компилятору, что я сам понимаю, что делаю;
• прозвучавшей на днях в этих наших Интернетиках статьей в которой кто-то выступил от имени всего Microsoft-а: "Microsoft: Rust Is the Industry’s ‘Best Chance’ at Safe Systems Programming".

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

Вкратце суть такова: есть класс-родитель, который владеет неким объектом child. При этом у класса-родителя есть метод replace_child:

class child; using child_unique_ptr = std::unique_ptr<child>; class parent {    child_unique_ptr m_child; public:    void replace_child(child_unique_ptr new_child)    {       m_child = new_child;    }    ... };

Класс child -- это интерфейс, который имеет несколько реализаций. Что-то вроде:

class child {    parent & m_parent; public:    ... // some pure virtual methods. }; class first_stage : public child {...}; class second_stage : public child {...}; class third_stage : public child {...}; ...

А фокус в том, что объекты-дети заменяют у родителя сами себя. Т.е. есть код вида:

class first_stage : public child {    ...    void on_some_event() override    {       ...       m_parent.replace_child(std::make_unique<second_stage>(...));    } };

Обратить внимание нужно на то, что только parent владеет указателем на child. И вызов replace_child синхронный. Поэтому, когда child вызывает replace_child у своего parent-а, то parent внутри replace_child-а уничтожает того child-а, который и сделал вызов replace_child.

Это ведет к тому, что значение this после возврата из replace_child будет невалидным. И, если в first_stage::on_some_event после возврата из replace_child будут происходить какие-то обращения к this (например, вызовы каких-то нестатических методов и/или чтение/изменение полей объекта), то возникнет UB.

В общем-то, примененное мной решение явно опасное и неоднозначное. Да и вообще программист из меня так себе, поэтому пишу код как умею. Отсюда и такие спорные решения.

Однако, если уж мне не удалось найти более безопасного решения в C++, то программируй я на Rust-е, то и на Rust-е бы я пришел бы к чему-либо подобному. И вот тут как раз и возникает вопрос, который мне любопытен:

А можно было бы в Rust-е применить такой же прием, не прибегая к unsafe?

Мои поверхностные знания Rust-е не позволяют дать точный ответ. Есть смутные подозрения, что без unsafe не обойтись.

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

[prog.flame] Ай да молодцы в Dropbox! Взяли и переписали свой sync engine на Rust. Ну молодцы же, да?

Речь про вот этот пост: Rewriting the heart of our sync engine. Dropbox переписал часть своей системы, отвечающей за синхронизацию, с Python-а на Rust и выкатил на публику победную реляцию об этом достижении.

Вот казалось бы, имей голову на плечах и напиши все сразу на C++... И работало бы это все годами.

Не нравится C++, а Rust-а еще нет не свете? Но ведь есть Ada, есть Eiffel...

Но нет. Сперва нужно написать на Python.

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

А потом выбросить результаты всех трудов на помоечку (с) и с криками восторга и другими проявлениями щенячей радости переписать все на Rust.

Ну и для тех, кто типа умеет читать между строк: это пост не про то, что C++ хорош, а Rust плох. Rust хорош. И для подобных задач его выбор ничуть не хуже, а может и лучше, чем выбор C++. Он про то, что выбор по принципу "пользуем то, на что надрачиваем, а ничего другого просто не знаем", в конце-концов приводит к потере времени и денег.

Да и еще не могу удержаться и не пройтись по любимой теме:

Almost all of our code runs on a single thread (the “Control thread”) and uses Rust’s futures library for scheduling many concurrent actions on this single thread. We offload work to other threads only as needed: network IO to an event loop, computationally expensive work like hashing to a thread pool, and filesystem IO to a dedicated thread. This drastically reduces the scope and complexity developers must consider when adding new features.

Это как раз то, что SObjectizer умеет делать с самого начала: распределять работу между сущностями, каждая из которых работает на нужной ей контексте. Хоть на общей рабочей нити, хоть на пуле потоков, хоть на выделенной отдельной рабочей нити. Собственно, для этого SObjectizer и создавался много лет назад.

[prog.rust.flame] "Говорил я вам. Не прислушались. Так и получилось. Как говорил я вам..."

На выходных, лениво пожевывая попкорн почитывал срачик на Habr-е, в котором светлые рыцари ордена safe Rust-а громко доказывали, что писать код так, как сделал автор Actix-Web, ни в коем случае нельзя. Занимательное чтиво, аж душа пела.

Пела потому, что когда лет 5-6 назад первые упоротые в своей воинственности Rust-оманы начали бегать по профильным форумам и убеждать всех тех, кому Rust вообще не был интересен, что Rust -- это самое лучше, что произошло с софтостроением после изобретения перфокарт, некоторые скептически настроенные старпёры сердито ворчали: "Ну подождите пару-тройку лет, в этот ваш Rust обязательно придут люди, которые начнут использовать unsafe, скажем так, весьма творчески. Вот тогда и посмотрим, насколько Rust окажется safe в реальной-то жизни".

Ну вот и дождались.

Вполне ожидаемо оказалось, что это во влажных мечтах оторванных от реальности фанатов в боевом коде на Rust-е unsafe либо не будет вообще, либо он будет локализован, тщательно оттестирован и аналь огорожен.

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

PS. А для всех свято верующих в то, что в реальной жизни unsafe в Rust будут использовать исключительно правильно, а прецидент Actix-Web-а -- это досадное исключение, ВИА "Громыка" исполняет свой незабвенный шлягер, строчка из которого была вынесена в заголовок заметки.

[prog.open-source] Автор Rust-ового фреймворка Actix-Web: "I am done with open source."

На HackerNews разгорелся один из самых больших срачей, который попадался мне там на глаза: A Sad Day for Rust (steveklabnik.com). Этот срач посвящен блог-посту "A sad day for Rust" (как я понимаю, за авторством кого-то из именитых Rust-евангелистов). В свою очередь этот блог-пост посвящен эмоциональному решению автора Rust-ового фреймворка Actix-Web закрыть свой проект. На GitHub-е по адресу https://github.com/actix/actix-web сейчас размешен только относительно небольшой README-файл, озаглавленный как "Actix project postmortem".

В "Actix project postmorten" автор пишет о том, как он задолбался бороться с борцунами с unsafe. Что работа над Actix-Web перестала приносить удовольствие. И что он решил послать все и всех куда подальше:

It’s been three years since I started actix project (time flies). I learnt a lot, i meet new people, I found language that I really like and want to use it fulltime, I found fun job. But damage to the project's reputation is done and I don’t think it is possible to recover. Actix always will be “shit full of UB” and “benchmark cheater”. (Btw, with tfb benchmark I just wanted to push rust to the limits, I wanted it to be on the top, I didn’t want to push other rust frameworks down.) Everything started with actix, then actix-web and then actix-net. It took a lot of time to design api and architecture. Each of this projects was rewritten from scratch at least 4-5 time. I hope I expanded some boundaries and found few new patterns, I hope other developers will check source code and find inspiration to move even further. Nowadays supporting actix project is not fun, and be part of rust community is not fun as well.

I am done with open source.

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

Любой проект может сдохнуть в любой момент.

Итак, первое впечатление, как это ни странно -- это вспомнившаяся откуда-то "мудрость": если долго сидеть на берегу, то можно увидеть, как мимо проплывает труп твоего врага. Так уж вышло, что мы так же пилим свой "типа Web-фреймворк", но для C++. Поэтому в какой-то мере RESTinio и Actix-Web конкуренты. В небольшой степени, но все-таки.

И вот один конкурент сходит с дистанции (по крайней мере в своем первоначальном виде). А мы остаемся. Мы живы, движемся вперед и это не может не радовать.

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

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

Се ля ви. Ничего не поделаешь.

Все вокруг все знают гораздо лучше тебя...

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

Собственно, то что эмоционально рассказал в "Actix project postmortem" Николай Ким -- это оно и есть. В чистом виде.

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

Rust-сообщество зачастую напоминает стадо упоротых разрушителей старого мира во имя новой религии, имя которой "safe во все поля".

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

Причем отдельным фетишем для упоротых Rust-оманов является safe. Который должен быть во все поля.

А если safe во все поля нет, то это ай-ай-ай, это все старый мир, который должен быть до основания... И далее по тексту.

Просто иначе я не могу себе представить причин происхождения тех волн агрессии на Actix-Web от сторонников safe Rust. Ну реально: вот есть проект, он сделан, он работает, он показывает крутые результаты. Ну есть там unsafe. Ну так не просто же так он там оказался. Да и если проект работает, покрыт тестами, новый функционал добавляется, баги правятся, так не все ли равно, есть там unsafe внутри или нет? Вам шашечки или ехать, в конце-концов?

Но вот оказывается, что шашечки важнее. <img src="СергейЛавров.jpg">

Так за чей счет сей банкет?

И, пожалуй, главное впечатление -- это актуальность моих недавних заметок про OpenSource и заработок на OpenSource (раз и два).

Отлично понимаю вот эти слова Николая Кима в его "Actix project postmortem": "Seems everyone believes there is large team behind actix with unlimited time and budget."

Как мне представляется, сейчас к OpenSource сложилось исключительно потребительское отношение. Т.е. все привыкли к тому, что используемые ими инструменты должны быть открыты. И не просто открыты, но и бесплаты. Более того, начинают звучать голоса, которые говорят о том, что пермиссивные лицензии, которые требуют указания факта использования OpenSource проекта (как это обязывает делать, например, BSD-3-CLAUSE лицензия), не есть хорошо. Что следует использовать лицензии типа Boost Software License, которые позволяют задействовать открытый проект и даже не упоминать об этом...

При этом, полагаю, большинство пользователей OpenSource разработок даже не задумывается, а за счет чего OpenSource проект живет и развивается. Да и зачем об этом задуматься? Вот же лежит бесплатно, так что дайте два, да еще и заверните в подарочную упаковку.

ИМХО, это ненормальная ситуация. Могу предположить, что чем дальше она будет развиваться, тем чаще будут происходить случаи, когда даже большие и знаковые для каких-то сообществ проекты будут внезапно умирать. Просто потому, что их авторам нужно на что-то жить, обеспечивать свои семьи, давать образование своим детям, помогать своим родителям и т.д., и т.п. А моральное удовлетворение от решения сложных задач и удовольствие от того, что твою OpenSource-разработку использовали там-то, там-то и еще вот там-то, как оказывается, в деньги не конвертируется...

Так что за словами "I am done with open source.", как по мне, скрыт очень и очень большой смысл.

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

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

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

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

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

[prog.flame] Пятничное дополнение ко вчерашнему посту. Снова про Rust

По поводу тяпницы и в качестве продолжения вчерашнего поста решил поделиться с читателями блога вопросом, на который у меня пока нет ответа:

А что будет, когда на Rust-е начнут программировать разработчики уровня сильно ниже среднего?

Вопрос отнюдь не праздный. Ибо не смотря на то, что Rust вышел в свет более 4-х лет назад, а активный его PR начался еще за пару лет до того, каких-то серьезных рассказов о последствиях применения Rust-а в полевых условиях пока что не так уж и много.

Между тем история показала, что для языка, претендующего на широкое использование, толерантность к "дятлам от программирования" крайне важна.

Так, на примере C++ видно, что есть языки, которые не прощают тупость разработчика.

Что-то похоже, полагаю, можно сказать и про Scala. Там, правда, последствия не такие катастрофические, как в C++, но несопровождабельный код, который проще переписать, чем понять, на Scala пишется легко.

Тогда как языки Java и Go зарекомендовали себя просто отлично с этой стороны. Высказывание "на Java можно посадить толпу индусов" -- это уже давно не фигура речи, а многократно подтвержденный успешный менеджерский опыт. Причем "индус" здесь не национальность, а уровень квалификации.

Так вот, мне не понятно, что будет происходить с разработкой на C++, когда туда придут персонажи, вроде RussianFellow с RSDN-а. Чтобы было понятно, о чем речь, вот замечательный образчик. И если кто-то думает, что подобные персонажи -- это редкость, то смею вас разуверить. Не редкость.

В свое время, когда C++ был настоящим мейнстримом, таковых было множество. Со временем, к счастью, изрядная их часть перешла в Java и C#. Но часть, к сожалению, еще осталась. И, если Rust продолжит набирать популярность, они неизбежно туда подтянутся.

Имхо, вариант Haskell-я, когда посредственности в этот язык просто не идут, здесь не прокатит. Т.к. Haskell в силу разных причин никогда и не мог претендовать на широкое использование. В отличии от Rust-а.

Так что будет интересно посмотреть на то, что произойдет. Выпрямит ли Rust-овский компилятор растущие из жопы руки? Или этот самый компилятор наеб*т посредством расставления unsafe в коде, ибо дедлайны, нужно фичи в прод выкатывать, а не ублажать borrow checker.

[prog.flame] Предлагаю новый слоган для D: "Fast as C++, safe as Rust, easy as Java"

Намедни в LOR-овском срачике сформулировал свое впечатление от наблюдений за тем, кто, как и откуда переходит на Rust. На мой взгляд, в Rust идут люди, которые всю жизнь программировали на безопасных языках с виртуальной машиной. Ну там Java, Python, Ruby, JavaScript, Erlang, Clojure и т.д. А так же C++ники, которые толком C++ не освоили, а уж о том, что такое современный C++, вообще не имеют никакого понятия.

А потом довелось прочитать серию постов небезызвестного своими "плачами Ярославны" НикиТонского: "С высоты", "С высоты-2" и "С высоты-3". И еще более утвердился в том, что мои наблюдения более-менее коррелируют с действительностью.

[prog.thoughts] Rust дал compiler-driven development широким массам

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

С учетом того, что к Rust-у я не прикасался, наверное, с апреля прошлого года (когда мне пришлось проштудировать доку по Rust-у для участия в панельной дискуссии на C++ CoreHard-е), было, скажем так, любопытно.

Стало понятно, что имеют в виду растоманы, когда говорят, что компилятор им помогает писать код.

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

Поэтому не остается ничего другого, как делать то, что тебе говорит компилятор. А потом оно раз! И работает.

Ну понятно, почему у людей крышу-то сносит. Особенно у тех, кто на Rust с динамики, вроде JS, Python или Ruby приходит.

Имхо, здесь есть сильная аналогия с тем, какую серьезную роль в разработке софта в середине-конце 1990-х годов произвели IDE. Сперва Delphi, затем IDE для Java (при этом IDE для C++, имхо, в те времена, да и потом, сильно недотягивали до Java-аналогов, что обуславливалось особенностями языка). Можно сказать, что в 1990-х сформировался IDE-driven development, который пышным цветом расцвел в 2000-х. Да и сейчас, наверное, цветет и пахнет.

А вот Rust, похоже, делает доступным для широких масс такую штуку, как compiler-driven development.

Что, как мне кажется, неизбежно скажет свое веское слово в индустрии софтостроения.

Но знаете, что по-прежнему удивляет меня сильнее всего касательно Rust-а? Это то, что не смотря на всю крутотень Rust-а и толпы писающих кипятком фанатов для Rust-а еще не появилось ни одного сколько-нибудь заметного GUI-фреймворка. За 3.5 года после выхода стабильного Rust 1.0. За три с половиной, мать его за ногу, года.

Да в 1990-е на первых версиях C++ GUI-фреймворки в одно рыло клепались только в путь и росли как грибы после дождя. Первая версия Qt была сделана за четыре года. В 1990-е, на древнем C++. Маленькой командой. Без GitHub-а. Только вдумайтесь. Да и сейчас люди делают вещи вроде ImGui и Nana. Для C++, не для Rust-а. Загадка, однако.

[prog.thoughts] "За*бало" как основная причина хайпа вокруг Rust?

Поводом к написанию данной заметки стали комментарии от ув.тов Сергея Скороходова, свежая запись в блоге ув.тов.kaa.python про социальные факторы и Rust, а так же ссылка на эту статейку, найденную на Hacker News.

[prog.flame] Управление памятью в Rust: придумалась хорошая аналогия

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

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

Итак, давайте посмотрим, как эволюционировали носители для письменности. Грубо, не вдаваясь в дебри истории, просто на уровне банальной бытовой эрудиции.

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

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

[prog.humour] Открыл статью о Rust, увидел пример кода, закрыл статью о Rust-е ;)

Иногда мне кажется, что у наиболее активных растоманов какой-то стокгольмский синдром в терминальной стадии :) Вот, например, свежая статья о Rust-а на Хабре: "Так ли страшен Rust, как его малюют", автор которой, будучи C#-разработчиком, активно защищает Rust в различных хабрасрачах.

Так вот, автор сперва приводит пример кода на Rust-е:

let mut guess = String::new(); io::stdin().read_line(&mut guess)     .expect("Failed to read line"); let guess: u32 = guess.trim().parse()     .expect("Please type a number!"); println!("You guessed: {}", guess);

А потом говорит, что можно сделать существенно проще и приводит вот такой аналог:

let mut guess = String::new(); io::stdin().read_line(&mut guess)?; let guess: u32 = guess.trim().parse()?; println!("You guessed: {}", guess);

Я, наверное, уже слишком старый и потихоньку начинаю выживать из ума. Поскольку мне не понятно, за счет чего второй пример "существенно проще" первого, ведь выполняется все ровно тоже самое и в той же самой последовательности. И разница состоит только в замене явного вызова expect с вменяемыми сообщениями на менее явные вопросительные знаки.

При том, что оба примера -- это попытка записать вот такой двустрочник на C#:

var number = int.Parse(Console.ReadLine()); Console.WriteLine($"You guessed: {number}");

В очередной раз убеждаюсь, что у Rust-а на данный момент две очень серьезных проблемы: ужасный синтаксис (то, что к нему можно привыкнуть не изменяет того факта, что синтаксис жуткий) и упоротые активные растоманы :)

---

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

[prog.thoughts] Под впечатлением от свежей статьи про Rust на Хабре

Просмотрел только что свежую статью на Хабре про Rust: Приемы обобщенного в Rust: как мы переводили Exonum с Iron на actix-web.

Похоже, я могу понять, почему к Rust-у такое внимание. И от кого это внимание исходит. Если всю жизнь программировал на Python, Ruby, JavaScript или даже Go, то в один прекрасный момент динамическая типизация и невысокая скорость исполнения может основательно подзадолбать.

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

Может быть Ada? Или какой-нибудь Eiffel? Сильно вряд ли. Про них мало кто знает. Eiffel вообще платный (но есть GPL-ная версия) и где он сейчас непонятно. Ada вроде как жива и развивается, но модным и молодежным этот язык точно назвать нельзя. Да и у сегодняшней молодежи попытка изучить Ada может вызвать стойкий рвотный рефлекс, особенно если всю жизнь программировал на чем-то вроде JavaScript-а.

Можно еще и D. Но его популярность и распространенность колеблется где-то возле статпогрешности.

Вот и остается Rust. Который был построен на базе всех популярных страшилок и хайпов 2000-х годов. ФП во все поля, ООП сосет, безопасное многопоточное программирование (на самом деле нет), отсутствие и GC и утечек памяти, иммутабельность by default, ...

Так что почему на Rust переходят люди с Python/Ruby/JS и даже с C# или Java, мне вполне понятно.

Только вот глядя на более-менее практичные примеры кода на Rust я не понимаю двух вещей:

Во-первых, какой смысл сейчас разрабатывать прикладное ПО на Rust-е или C++? Ну т.е. такое, которое решает проблемы конечных пользователей. Зачем писать на Rust или C++ очередной HTTP-сервер, MQ-брокер, СУБД или компилятор я могу понять. Не понятно, зачем на Rust-е делать что-то прикладное, типа взяли данные отсюда, проверили, преобразовали, сохранили в БД, отдали вот сюда.

Ну вот, действительно, какой смысл? Порог входа в язык высокий. Код, который будет разрабатываться, особой читабельностью отличаться не будет. Посадить на проект какого-то "индуса" заместо выбывшего "индуса" не получится. Поскольку язык безопасный, с кучей проверок к run-time, по производительности он будет побыстрее, наверное, Java и .NET-а, но не на порядки. Да и вряд ли в разы быстрее, скорее на десяток-другой процентов, да и то вопрос. Экосистема еще только формируется и наполняется библиотеками...

Во-вторых, зачем C++ника пересаживаться на Rust? Не, я понимаю, что ФП во все поля, ванильные трайты вместо утиных шаблонов, синтаксические макросы, компилятор бьет по рукам, cargo и все дела... Но блин, в Rust-овом коде будет все тоже самое, что и в C++ном: лес из абстракций и обобщенных конструкций, построенных каким-то сумрачным гением. Так что в красивой обертке матерый C++ник обнаружит все тот же говнокод, наполненный трехэтажными шаблонами, с которым ему и так приходится иметь дело постоянно. И еще непонятно, какой из них ближе к криптограммам ;)

---

В общем, в очередной раз можно пожалеть, что D не взлетел. Сперва он появился слишком рано, когда еще не было надобности в шустром, но безопасном нативном языке с GC. Всех вполне устраивали Java с JVM и C# с .NET. Плюс к тому, затеяли переход от D1 к D2 и профукали момент, когда выстрелил Go в контейнерах, где нужна и скорость и отсутствие тяжелых ран-таймов.

Да и сейчас авторы D, как мне кажется, продолжают думать, что основные конкуренты для них -- это C и C++ (ну, может быть еще и Rust). Тогда как на мой взгляд, основные конкуренты для D -- это Go и грядущие Kotlin/Native, Scala/Native, Crystal, Nim и т.д. И вот эта неправильная оценка ситуации приведет к очередному профуканому шансу. Вместо betterC нужно в D другими вещами заниматься, имхо.

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

[prog.flame] И еще раз про Rust. Как я к Rust-у отношусь на самом деле

Судя по статистике посещений, недавние посты про Rust (№1, №2 и №3) продолжают привлекать к себе внимание. И, к сожалению, у некоторых альтернативно одаренных личностей складывается впечатление, что я пытаюсь гнобить Rust. Поэтому нужно расставить все точки над ё.

[prog.fuck] А не пора ли гнать активных растоманов ссаными тряпками?

Ей Богу, скоро начну Rust-оманов, которые пытаются мне что-то объяснить, посылать жестко и матерно. Ибо складывается ощущение, что они полюбили Rust потому, что мозгов разобраться с чем-то еще у них просто не хватает.

Upd. Всем тем, кто думает, что в данном посте я гноблю именно язык Rust, а не активных пидора растоманов, настоятельно советую прочитать вот это.

[prog.thoughts] В догонку к посту про Rust 1.27

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