В жизни каждого человека есть время разбрасывать камни, а есть время собирать. После 12 лет работы в космической отрасли настало и мое время.  И как мне видится есть противоречие между трендом в спутникостроении и технологическим процессами.  В чем суть? Главный тренд – это снижение стоимости аппаратов за счет более адекватной оценки рисков. И по идее весь процесс должен выглядеть так:  вначале создается  адекватная модель того, как будет жить и существовать спутник, затем с опорой на нее мы его строим, потом запускаем,  получаем данные, корректируем нашу модель. Но реальность такова: Да-да, вы все правильно поняли, наземные испытания самые бесполезные для исходных моделей. Хотя казалось, это единственный момент, когда под нашим контролем все. Как мне кажется тут дело, в том, что в глазах конструкторов это просто железка, когда по факту, современные спутники - это беспилотники.   Которые уже могли бы решать, что им делать в части нештатных ситуаций, но эта задача целиком и полностью (ну почти) лежит на людях, управляющих аппаратом. А почему? – Да просто потому, что нету моделей, симулирующих подобные случаи. Потому что опыт их устранения вообще никак не используется в дальнейшем проектировании. Но чтобы это в принципе было бы возможно, нужно чтобы логика, положенная в основу моделей, была единой для всей цепочки проектирования и управления. Поэтому я предлагаю создать единую библиотеку которое позволит что-то типа следующего:  Одно кольцо объединит их… К-хм... Понятно, что это только инструмент и чтоб исправить вышеозначенную проблему нужно еще много организаторский работы, но при такой схеме сделать это проще. Почему? Отвечаю: Классическое преимущество разделенного кода - меньше времени на отладку и на внедрение исправлений. Уже при разработке моделей можно разработать методики автоматизированной проверки на земле и обработки данных в процессе лета.  Позволяет проектировать опираясь на то, как будут аппаратом управлять и как его будет принимать заказчик. Прежде, по крайне мере в мире свободного ПО, такой задачи никто не ставил. Поэтому будем действовать по принципу: «Новое вино следует наливать в новые мехи». Сформулируем наши желания, пока не утруждая структурированием и конкретизацией: Хочется, чтобы созданная библиотека не должна навязывать разработчикам язык программирования, на котором они будут писать; Хочется, чтобы возможно было разрабатывать как клиент-серверные приложения, так и однопользовательские; Хочется, чтобы можно было писать как целые комплексы взаимодействующих приложений, так и одно-единственное, работающее само по себе.  Из этого следует два вывода:  Выбирать приходится из С++ и Rust. В противном случае, всем остальным придется писать на том же языке, что и мы, быть может, добавится пара-тройка скриптовых, типа Python. Нам точно потребуется ОРП-библиотеки, с помощью которых можно легко (относительно) переключится между серверной БД, например PostgreSQL и встроенной, такой как SQLLite. И желательно, чтобы он были на том языке, на котором написана вся библиотека. И, казалось бы, все очевидно: Rust спроектирован с учетом накопленного опыта развития Си\C+, значит надо переходить на него, но не все так просто. Java, C#, D, были также разработаны с учетом того же, но C++ по-прежнему жив и активно развивается. А все дело в  цене – сборщике мусора, который как не крути, приводит к увеличения времени исполнения, объему потребляемой памяти, а также порождает проблему неопределенности во времени высвобождения объекта. Это видно по многочисленным тестам.  Мой же опыт еще добавляет к этому, что проблемы с утечками памяти, хоть и уменьшаются, но не исчезают, а вот трудность обнаружения возрастает на порядки.  У Rust же другая беда. С++ хоть и считается мультипарадигменном, но сквозь весь язык просвечивает понятие «объект». А вот у нашего пациента в основу положена другая сущность - «данные».  Казалось бы, в чем проблема? А она есть. Хотя я уверен, что все знают основное свойство информации, но все же напомню: «Если Вы знаете математику, а Толя нет, то если вы передадите свои знания, то и Вы и Толя будут знать математику».   А вот «объект» пришел из физического мира, и там совсем другие свойства: «Если у Вас есть апельсин, а у Толи нет, то если Вы его передадите, то у Толи будет апельсин, а у вас нет». И принципы ООП тоже взяты оттуда же, вы только  вспомните всех этих уточек у классиков. Именно наличие повседневного опыта облегчает мозгу уложить эту абстракцию в голову. А вот с «данными» у нас ничего подобного нет, и по первости подсознательно пытаемся натянуть сову на глобус. Естественно, это не проходит бесследно ни для качества кода, ни для его производительности. И еще два года назад подобное можно было наблюдать в популярных математических библиотеках. И надо сказать, что последнее обстоятельство сыграло немалую роль в том, что я поначалу отвернулся от Rust, и первый маленький прототип был создан  на C++. Когда же я стал писать статью я решил проверить, как сейчас обстоят дела. Как оказалось много лучше чем в 2020.  Ну что ж, тогда рассмотрим те особенности, которые могут послужить на жизнестойкость проекта.  Rust C++ Кем развивается Rust Foundation Конгломератом различных компаний, специалисты которых раз в н лет собираются, чтобы утвердить новый стандарт. Компиляторы rustc gcc, clang, msvc, icc и т.д. Средства сборки Встроенный cargo Встроенных нет, стандарт де-факто cmake, а вот альтернатива qbs прекратила развиваться Средства документирования Встроенные Встроенных нет, стандарт де-факто doxygen ОРП-библиотеки diesel ODB, QxOrm и т.д. Библиотеки пользовательского интерфейса Azul  Qt, WxWidgets и т.д. Что можно сказать: разработка Rust ведется гораздо более централизовано чем C++ . В этом есть как плюсы, например, скорость внедрение нововведений, так и минусы, например разработчики и менеджеры могут видеть будущее языка по-разному.  Децентрелизованность порождает большую живучесть, с одной стороны, но при этом принятие стандарта, а потом его реализация в каждом отдельном компиляторе может затянуться на годы, и то нет гарантий, что стандарт будет воплощен в полном объеме.  С++ древний язык, да при этом обеспечивающий прозрачную совместимость с С. Хороших проектов написанных на нем много. А Qt, по моему опыту, лучшее что существует для кроссплатформенной разработки пользовательского интерфейса. Но и в Rust дела уже идут в гору. Глядя на структуру diesel в его будущее верится без проблем. А вот что с будет с Azul мне лично не очень ясно. Но опять же, никто не мешает в проектах на Rust использовать сишное наследие в виде GTK, благо есть специальный пакет, актуальность которого поддерживается скриптами. Так что считаем, что по основным параметрам паритет. Но есть еще один беспокоящий момент: поддержка cстандартной библиотеки в операционных системах реального времени.  Убедил, что Rust не нужно рассматривать? Нет? Вот и я себе не убедил, хотя, повторюсь, у меня был уже минимальный рабочий проект на C++. Но чтобы понять куда двигаться дальше придется его реализовать и на ржавчине. И вот подобный поворот я не ожидал, когда сел писать эту статью. Он поломал всю логику повествования и то, что я хотел сейчас сказать. И в следующей статье, которые неизвестно когда будет, по всей видимости, я буду сравнивать Rust и C++.  Небесный механик