Google профинансирует работу над Rust for Linux

Разве это ещё актуально?

Скорее нет, но ms старые замашки не забывает, windows 11 говорят и довольно новые процессоры не поддерживает.

Что-то не так. Мы либо оперируем исходниками, вроде cargo так и делает, и получаем одно, либо бинарными файлами - другое.

Здесь нет вопрос «окружения», смысл как раз в том, что бы от него максимально абстрагироваться. Сам ПМ должен предоставлять равно-однаковую среду, на любой машине.

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

Что это значит? Это значит, что «гадкий утенок» может в один день стать «белым лебедем». Одно дело, когда ты вынужден полагаться на десятоки разрозненных внешних инструментов в рамках парадигмы unix-way. И совсем другое, когда ты получаешь в руки вертикально интегрированное решение, способное автоматизировать работу с большими кодовыми базами в современных окружениях (гетерогенность, облако и т.п.).

Не значит. Ты просто создашь один из этих «внешних» инструментов. Пока это не будет частью языка, стандарта - воз будет там же. В с\с++ по другому уже не получится, ибо на взлёте момент упущен.

Короче, то, что именно нужно — это всё сильно сложнее, чем просто пакетный менеджер. Но рано или поздно те отдельные инструменты, которые сейчас уже есть, будут лучше интегрированы с компиляторами. Работа идет)

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

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

У С++ и Rust сейчас разные (хоть и перекрывающиеся) области применения, определяемые существующими библиотеками и инструментами. И это существенно определяет прагматику языка. Скажем, cargo для Rust более чем достаточен. Но вот его близкий функциональный аналог Vcpkg для С++ недостаточен, хотя он более чем достаточен в тех сценариях, в которых cargo достаточен для Rust. Поэтому, когда мне просто нужно собрать несколько либ для Мемории, я использую Vcpkg, и я доволен результатом.

Но я бы расстроился, если бы сейчас Vcpkg, CMake и ninja стандартизировали как пакетный менеджер и систему сборки для С++, потому что этот функционал недостаточен для не очень часто встречающихся на гитхабе, но всё же важных сценариев использования С++, которые сейчас у людей перекрываются самописными инструментами.

В частности, я бы хотел, чтобы и система сборки, и пакетный менеджер были охвачены полноценно метапрограммированием. Но тут есть куча технических вопросов, потому что само метапрограммирование в С++ еще «не очень», мягко говоря. Т.е., пока мы дойдем до вопроса пакетного менеджера, нужно еще много чего решить. Жизнь — боль.

Поэтому, я (и не только я) предпочитаю пользоваться Vcpkg и не педалировать сейчас вопрос пакетного менеджера на уровне языка.

Когда же мы спускаемся на уровень конкретного компилятора, тут есть гораздо больше степеней свободы. В Clang есть нормальный JIT и много уже готовых элементов платформы для управления кодом и аналитики над ним. И тут можно относительно быстро выкатить весьма продвинутый прототип платформы, который со временем может превратиться в TR для языка или даже в стандарт. В С++ оно сейчас так работает: есть идея — предлагай прототип. Сlang продвинутый и легко хакается.

Но я бы расстроился, если бы сейчас Vcpkg, CMake и ninja стандартизировали как пакетный менеджер и систему сборки для С++

Зачем стандартизировать реализацию, а не принцип ? Можно просто ввести условный синтаксис для подключения либ, скомпилированных или нет. Описать синтаксис версионирования и тд.

Условно назовём это в стандарте CppPM. А как вокруг этой концепции будут делать реализации, это уже десятый вопрос. Ты просто пишешь, и твой код работает на любом ПМ который поддерживает cppPMv1.

Как я понимаю, стандарт должен работать так, по крайне мере в мире с\с++ где всё завязано на стандартизации, а не на эталонной реализации.

Ну, мне твоя идея нравится и кажется годной. Я бы сам так и делал, внедряя PM постепенно. Надо посмотреть, может что делается как раз в этом направлении.

Почему бы не пойти дальше, и не сделать полностью интегрированный бекенд, доступный по RESTful-подобному API?

Мысль интересная и я уже было начал спорить (набирал несколько предложений и стирал) из-за того, что не уверен, что с Language Server всё так гладко. Но не буду: всё-таки я недостаточно в это погружался. Кажется, что обобщить всю машинерию ИДЕ с одной стороны и системы сборки и языковые фичи с другой будет непросто. Хотя может и реально.

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

Ну перепиши компилятор С так чтобы получилась джава. Или джава не нужна, да?

Но я бы расстроился, если бы сейчас Vcpkg, CMake и ninja стандартизировали как пакетный менеджер и систему сборки для С++, потому что этот функционал недостаточен для не очень часто встречающихся на гитхабе, но всё же важных сценариев использования С++, которые сейчас у людей перекрываются самописными инструментами.

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

Немного о Cargo - на первый взгляд это очень простая штука: проект декларативно описывается и всё. Процентам этак 80, если не больше, проектов этого хватает. Тем не менее, у этого инструмента есть точки расширения. Например, в проекте может быть билд-скрипт на расте в котором (естественно) можно делать вообще всё, что угодно. Не сомневаюсь, что извращённый пытливый ум сможет придумать ситуацию когда этого всё равно не хватит. Но мне попадались проекты, которые использовали велосипед вместо тоже же CMake не из-за того, что возможностей не хватало, а потому что автору CMake «не нравился».

Я вообще то для более точного исследования кода чтобы ошибки вылезли на этапе компиляции а не исполнения. Долго, за то на выходе будет более безопасный код.

Я вообще то для более точного исследования кода чтобы ошибки вылезли на этапе компиляции а не исполнения.

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

Мне надо утренние дела разгрести, я потом отпишусь подробнее, что я имел в виду и зачем.

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

Мне помогло.

Неужели гибкости CMake для чего-то не хватает?

Если говорить конкретно про CMake, то это весьма своеобразная система, которая решает искусственно созданные проблемы. Это ведь не система сборки, а система генерации скриптов сборки для других систем. И в этом смысле её возможности весьма сильно ограничены. Потому что генерируется оно CMake-ом (исполнение cmake-скриптов), а вот исполняться будут другой системой.

Например, если у тебя есть в проекте кодогенератор, и он создает много файлов, имена этих файлов должны быть известны на этапе выполнения cmake-скрипта, чтобы последний мог создать граф зависимостей между файлами. Но кодогенератор твой выполняется на этапе сборки, т.е. запускается уже make-ом, msbuild-ом или ninja. Поэтому приходится запускать кодогенератор дважды: один раз cmake-ом непосредственно в --dry-run режиме, когда он ничего не делает, а только создает список файлов. И второй раз уже на этапе сборки. Это не то, чтобы неудобно, но кодогенератор должен быть уметь интегрироваться с cmake (сообщать список создаваемых файлов). Ну и, каждый раз, когда генератор может создать дополнительный файлы, нужно перезапускать cmake на проекте. Если ты сам руками добавляешь новый исходник, то ты знаешь, что надо cmake перезапустить. А что там кодогенератор насоздает — глазами это не видно.

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

Сейчас ситуация еще более щекотливая. Ninja кроссплатформенный и стал уже фактически стандартом сборки. И cmake над ним уже воспринимается как совершенно лишняя сущность. Cmake по сути нужен только тогда, когда тебе нужно проект для сборки в VC сгенерить.

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

Позже отпишусь, что же именно я бы хотел видеть.

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

Совершенно правильное замечание. Я поясню подробнее, чтобы было понятнее, что же именно я предлагаю сейчас.

Я по роду занятий бекендщик, но с сильным уклоном в инженерию данных. Не спарки-хадупы, а серьезную. Мы идентифицируем неявно существующий data space, и делаем его явным, превращаем в state, охватывая по ходу автоматизацией, инструментами хранения и обработки, а так же различными сервисами. В этом ракурсе я и вижу систему сборки, как систему интегрированных сервисов. Мы их уже имеем в виде Github, его пайплайнов, сторонних билд-систем, CI-систем, публикаторов документации и т.п. Но я именно на этот уровень сейчас не лезу, я фокусируюсь на менее респектабельной, но гораздо более сложной проблеме: как эффективно организовать state такого проекта.

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

Пакетные — это то, что мы имеем сейчас: множество исходников на входе, множество артефактов на выходе. Надо собрать заново — запускаем всё заново. Все просто, понятно и хорошо работает до тех пор, пока не нужна интерактивность.

Интерактивность (или событийную реактивность) обеспечивают стриминговые системы. Т.е. вот мы обновили какой-то файл, и все автоматически пересобралось (но только то, что изменилось).

Может показаться, что существующие системы сборки именно так и работают, но нет. Если будет постоянный поток событий модификации данных, то они будут давать на выходе некорректный результат. Чтобы билд-системы работали корректно, нужна snapshot-изоляция уровня всего проекта. Ни пакетные билд-системы, ни обычные стриминговые системы такого уровня управления стейтом не предоставляют (они для таких сценариев не годятся).

Можно попробовать прикрутить какую-нибудь проворную СУБД с MVCC и snapshot isolation, но там есть много различных технических ограничений. На игрушечном уровне оно может и завестись, но at scale работать не будет. Оно совсем не для этих сценариев создавалось. И под них, как минимум, не оптимизируется.

Вот эту проблему я, в первую очередь, и решаю. Мемория умеет в персистентные структуры данных, а они предоставляют как раз то, что нужно. Там можно делать «пакетный стриминг», причем каждый пакет — это отдельный snapshot, и трансформер (компилятор, метапрограмма) будет видеть консистентное состояние всего мультимодельного хранилища на момент вызова. Соседние (по ветке времени) писатели никак не мешают. И, самое главное для всяких IDE-шек — всегда можно прочитать стейт на конкретный момент времени (имея snapshot id или commit id, как в git). Это очень сильно их упрощает. MVCC RDBMS с поддержкой SI нам именно этого не дадут, так как там доступ к истории теряется, как только транзакция завершена. Есть еще savepoints, но этот инструмент для другого сценария.

Я хочу сделать динамическую стримингово-пакетную модель всего проекта, включая промежуточные артефакты средствами Мемории, и экспортировать её клиентам через FUSE в виде псевдо-файловой системы. Под FUSE, но «над» Меморией будут соответствующие инструменты Clang, интегрированные в единую систему. Внешние тулзы, если таковые понадобятся, смогут просто читать и писать файлы с этой псевдо-ФС. Например, так можно вызывать GCC, если Clang по каким-то причинам не устраивает. Или тот же rustc, если надо.

Пока так. Дешево, сердито и функционально. Общаемся через файлики и/или пайпы. REST — это сильно потом.

а просто make-ом собирать уже не в моде, нужно всё переусложнять?

Ну, судя потому, что все Cmake-based уже собирают с помощью ninja, то да, не в моде.

Но, надо добавить, что всё, что я выше написал — это эксперимент: интерактивная система сборки, доступная по API.

ninja обычно заметно шустрее собирает.

gcj ?

По описанию выглядит как сборочная система «сверху вниз». Посмотри в сторону nix (который в nixos). Также в сторону сборочной системы redo, есть общая идея сборки «сверху вниз» ( https://redo.readthedocs.io/en/latest/ ), с простыми реализациями на bash.

Дешево, сердито и функционально.

По твоему описанию как раз наоборот - оверинжиниринг во все поля.

Если говорить конкретно про CMake, то это весьма своеобразная система, которая решает искусственно созданные проблемы. Это ведь не система сборки, а система генерации скриптов сборки для других систем.

Справедливое уточнение.

Насчёт последующих рассуждений: я пока нахожусь на этапе «слишком сложно, зачем оно такое нужно». Но попробую задуматься над этим ещё. (:

я пока нахожусь на этапе «слишком сложно, зачем оно такое нужно»

Это нормально. В таких вещах нужно давать прототип «на потрогать», к чему я и иду. Это сразу снимет много вопросов.

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

Что ты здесь имеешь в виду под «сверху-вниз»?

Посмотри в сторону nix (который в nixos).

Очень хорошая аналогия. Еще одна аналогия — это Immutable.js, React и архитектура Flux/Redux. Я тут не буду пускаться в подробности, как и почему оно работает, скажу только, что я в одном таком экспериментальном проекте участвовал, где заменял Immutable.js на Меморию. Фронтендщикам очень нравилось. Больше всего им нравились snapshots, когда ты видишь state на конкретный момент времени, и не надо париться, что в следующую секунду стейт на сервере поменяется. Гораздо проще делается частичная репликация стейта между бекендом и фронтендом. Фича функциональных (персистентных) структур данных.

Здесь же я имплементирую похожую архитектуру (DAG над ФСД), применительно к задаче сборки гетерогенного проекта, добавляя уровень событий над таким функциональным хранилищем и возможность работы со структурированными данными произвольного размера (но в рамках одной машины). Это всё можно обобщить на уровень пакетного менеджера OS (Nix) или даже всего десктопа. Но я эту задачу не решаю. У меня просто «стримингово-функциональный» бекенд системы сборки для С++.

По твоему описанию как раз наоборот - оверинжиниринг во все поля.

Это если смотреть на это дело как на «make на тяжелых наркотиках». Сам бы согласился, то тяжелее уже некуда. Тут цель — дать возможность работать фоновой аналитике за счет snapshot-семантики. Ну и за счет того, что Мемория оперирует произвольными структурированными контейнерами данных, а не блобами, можно надстраивать весьма сложную логику отслеживания того, что менялось в истории изменений. Это будет как «redo на стероидах».

Что ты здесь имеешь в виду под «сверху-вниз»?

Что такое «стримингово-функциональный»? Пока не будем касаться бекендов-фронтендов и упорядочивать концы палки, какой передный, а какой задний. :)

DAG

Этот термин используешь и не знаешь про «сверху-вниз»?

на уровень пакетного менеджера OS (Nix)

Вообще-то, nix - это не пакетный менеджер. Под ним понимают не только nix, но еще nixpkgs и прочую обвязку вокруг nix (для единственного убийственного приложения [killer app] - nixos). Из-за чего это всё выглядит как пакетный менеджер для ОС.

Что такое «стримингово-функциональный»?

Event driven computations над функционально-организованным хранилищем.

Этот термин используешь и не знаешь про «сверху-вниз»?

Я знаю, что такое top-down design, но что такое top-down build system — тут много неопределенности для меня.

Есть граф(G); направленный (D) - можно определить начало-конец, верх-низ, выше-ниже; ацикличный(A) - дает гарантии тразитивности такого определения. Если взять любую вершину, можно вытащить все поддерево нижележащих зависимостей - «сверху вниз».

Event driven computations над функционально-организованным хранилищем.

Вообще неперсекающиеся задачи.

Разве что, если что-то типа SAX-парсера такого «хранилища», тогда можно увидеть потоковость событий. Тяжелое наследие Java, когда xml - решение всех проблем?

Вообще неперсекающиеся задачи.

Ну так пересечем, где наша не пропадала))

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

Т.е., пришло событие изменения исходника (1). Запустился по DAG зависимостей процесс распространения обновлений [1]. Пришло событие изменения исходника (2), запустилась волна обновлений [2]. Если эти волны по какой-то причине перекроются во времени, то мы получим результат на выходе с неизвестным статусом корректности (невоспроизводимый билд).

Или другой сценарий. Есть вот, например, у нас аналитика, которая может долго лопатить исходники (теоремы там доказывать или еще что). И тут мы еще в фоне работаем, внося в эти исходники какие-то изменения. Чтобы аналитика могла работать в общем случае, ей надо видеть статичный срез данных на момент запуска. Это хорошо умеют batch-системы, но не умеют stream-системы. Пресистентные структуры данных позволяют сидеть на двух стульях, имея одновременно и снэпшот-изоляцию (batch), и потоковый характер обновлений (stream).

А SAX-парсер тут ни при чем)

Ты это рассказываешь пользователю nix{,pkgs,os}? Лучше про минусы расскажи.

Ты это рассказываешь пользователю nix{,pkgs,os}?

)))))))

Лучше про минусы расскажи.

Место. Нужно много места под все эти версии и возникающие в процессе работы промежуточные данные. CoW решает проблемы конкуррентности разменивая их на память.

Кроме того, Мемория сама по себе далеко не самая экономичная в этом плане. Там используются блоки размером 4K-1M, и каждое изменение — это, как минимум, несколько блоков.

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