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

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

miri

Разве miri есть смысл на safe-коде гонять?

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

Не очень понял о каких расширениях речь, но чем это принципиально отличается от использования проприетарных библиотек?

Опять же как заставить покупать раму, цпу и прочее ? В результате имеем приложения на жс и расте …

Вот только гугл и майкрософт (которые типа продвигают раст) своё железо не делают. И замедлять винду и андоид им нет резона.

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

Да ладно? Ты из криокамеры вылез что ли? Возьмём в качестве точки отсчёта сишку, так любимую местными «староверами»: С++, джава, C#, скала, котлин, свифт, Go и т.д. Плодят языки ещё как (и правильно делают).

Если мне приведут техническое док-во чем Раст лучше/безопаснее С++ я пойму зачем нужен Раст.

Не, не поймёшь.

Разве miri есть смысл на safe-коде гонять?

use std::collections::VecDeque;
fn main() {
    println!("{:?}", VecDeque::<u32>::new().iter());
}

safe код, баг найден miri: https://github.com/rust-lang/rust/issues/53566

Любопытно, спасибо.

Хотя всё-таки проблема там была в том, что ансейв протекал через типа safe абстракцию. Но в целом аргумент честный: кривой ансейф может быть и в std, так что «параноикам» есть смысл использовать мири.

Раст не дотягивает до C++ по фичам.

Я так понимаю, что чтобы «дотянуть по фичам» надо реализовать дословно все плюсовые возможности и ещё сверху отсыпать?

Я так понимаю, что чтобы «дотянуть по фичам» надо реализовать дословно все плюсовые возможности и ещё сверху отсыпать?

HKT, числовые обобщенные числовые параметры (их толком нет еще), метапрограммирование уровня типов повыразительнее (трясина Тьюринга та еще). Процедурные макросы не заменяют метапрограммирования уровня типов, а просто добавляют синтаксического сахара сверху того, что есть. А линейные типы, как выше показал fsb4000, можно и в С++ иметь.

А llvm?

Clang вместе с llvm компилируется.

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

Так-то оно в обе стороны работает: пусть процедурные макросы не заменят метапрограммирование уровня типов, но какое-то вещи на макросах наоборот делаются много удобнее.

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

Есть такая проблема. Я позже отпишусь о том, что я буду в рамках Jenny Platform делать, чтобы улучшить ситуацию.

Я согласен. Я говорил в том смысле, что вот говорят плюсовикам, чтобы переходили на Rust. Но на Rust переходить — это от многого привычного отказываться. Да еще, к тому же, терять наработанную кодовую базу. В активе Rust будут процедурные макросы и UB-free зоны, но и всё, по сути.

но чем это принципиально отличается от использования проприетарных библиотек?

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

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

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

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

Ну и всё-таки: о каких расширениях речь в контексте раста?

Вот хотим мы использовать библиотеку или некое

А если речь не о библиотеке, а о готовом достаточно сложном софте, который устанавливает отнюдь не программист, а простой админ или вообще человек без навыков программирования софта?

Честно говоря, стало ещё менее понятно. На софт будет лицензия, так ведь? Вот от этого и отталкиваемся. Ну а если случайный человек устанавливает непонятно что не вникая, то это его проблемы.

На софт будет лицензия, так ведь?

А что толку в сколь угодно свободной лицензии если по факту приходится выбирать из двух альтернатив: купить проприетарное расширение компилятора или переписывать софт полностью завязанный на это проприетарное расширение?

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

Но всё-таки: можно узнать о каких таких расширениях мы вообще говорим?

Так, сначала про пакетный менеджер «из коробки».

Дело в том, что, в отличие от Java/JS/Python/etc, понятие пакета в С++ очень сильно зависит от окружения. Даже в рамках одного дистрибутива нам нужны две сборки библиотек — собранные с отладкой и собранные с оптимизациями. А еще бывает нужно иметь разные варианты одного и того же артефакта, собранные с разными ключами (например, с исключениями и без них). Т.е. в С++ нужен не пакетный менеджер в обычном понимании этого слова, а менеджер окружения. На мой взгляд, вполне себе неплохим таким менеджером является Vcpkg. Он минималистичен и неинтрузивен, и далеко не всегда удобен, так как предполагает модель «одно приложение — одно окружение». Так как оружение может быть большим (десятки гигабайт), то может оказаться так, что места на диске не напасешься. Но, в остальном, всё довольно таки удобно и кроссплатформенно. И отдельный сервер-репозитарий для артефактов не нужен.

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

Теперь про перспективы.

У Clang внутри очень много интересного. Они постепенно движутся в направлении полноценной интегрированной дата-платформы, делая модульный компилятор.

• У них есть формат AST-файла, который пригоден для высокопроизводительной аналитики. Скажу сразу, что там есть еще что и куда улучшать, но и то, что есть уже достаочно для старта.
• У них есть неплохая такая полноценная кодовая модель уровня проекта с поддержкой графа зависимостей. И эта модель отвязана от хранилища, т.е. у них там свой аналог VFS, и весь проект целиком можно, например, положить в пригодную для этого БД и накрутить сверху автоматизацию, интерактивность (поддержка IDE) и распределнность (облако).
• У них есть хорошо интегрированный со всем этим стеком отладчик, поддерживающий динамическую компиляцию выражений.

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

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

Что пока что недостает Clang, чтобы стать дата-платформой, так это сособная база данных. И у меня тут есть экспериментальный проект. Там уже есть полноценные метафункции, и квотинг (т.е. метафункции могут делать кодогенерацию, не связываясь с AST), но еще нет API к ним. Потом я подо всё это положу Меморию для модели проекта.

Так что, работа идет)

Даже в рамках одного дистрибутива нам нужны две сборки библиотек — собранные с отладкой и собранные с оптимизациями.

Эта пролема (и последующие перечисленные) решается тем, что пакетный менеджер не бинарями оперирует, а исходниками. Разве нет?

И замедлять винду и андоид им нет резона.

А как же wintel?

В активе Rust будут процедурные макросы и UB-free зоны, но и всё, по сути.

Не все, еще как минимум null safe и алгебраические типы данных.

Это не проблема Си. Это проблема кривого железа и вендоров-говноделов. Окаменевший, в буквальном смысле калл – все устройства.

для её компиляции необходимо купить это проприетарное расширение.

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

Эта пролема (и последующие перечисленные) решается тем, что пакетный менеджер не бинарями оперирует, а исходниками. Разве нет?

Само сосбой, но это несколько размывает понятие пакета, потому что это теперь «пакет + среда». И, да, нужно всё собирать на локальной машине под свою локальную среду. Т.е. разработчику нужна весьма и весьма борзая машина с большим диском. Дешевый лептоп за $500 не пойдет. А это, например, основная рабочая машинка для js-ников. На маках, в основном, пижоны сидят.

Не все, еще как минимум null safe и алгебраические типы данных.

Да, если считать «из коробки». Годный аргумент, пойдет.

про платные макросы для раста у нас даже слухов еще не было.

А были слухи про платные библиотеки для Rust? Рынка там, по-моему, еще совсем нет. Будет рынок, будут и платные макросы.

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

Т.е. разработчику нужна весьма и весьма борзая машина с большим диском.

Раст такое никак не меньше чем C++ любит.

Раст такое никак не меньше чем C++ любит.

Я про «пакетный менеджер в составе языка», что бы это не значило. Для компилируемых языков с условной компиляцией нежен не пакетный менеджер, а менеджер среды и это уже другое. Там, скорее всего и опыт использования другой будет (не такое вертикально-интерированное решение как тот же Maven для Java).

Ну а cargo растовский чем не такой «менеджер среды»?

Я не к тому, что cargo плох или хорош. Я к тому, что то, что бы мы хотели видеть в С++, мы еще, в целом, не определеились. Частные решения (типа Vcpkg) пока устраивают. Перейдем полноценно на модули, там посмотрим.

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

Я вообще про разговорный язык. Т.е. Это типа круто писать книги на разных языках и общаться.

Типа плохо будет если будет всего 2-3 яп и программеры будут сосредоточены на написании прог а не на изучении очередного яп.

Я вообще про разговорный язык

Там тоже общий язык меняется была латынь, французский, сейчас английский, а через 50 лет возможно и китайский.

Типа плохо будет если будет всего 2-3 яп и программеры будут сосредоточены на написании прог а не на изучении очередного яп

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

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

А как же wintel?

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

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

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

Еще интересный момент в том, что у С++ сейчас сильно плывет область применения. Появляется гетерогенность, IoT, новые типы оборудования и взаимодействия. Compute-интенсивные задачи раньше были эксклюзивно уделом HPC, а сейчас уже просто мобильные (!) приложения.

И, да, нужно всё собирать на локальной машине под свою локальную среду.

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

Дешевый лептоп за $500 не пойдет. А это, например, основная рабочая машинка для js-ников.

Тут я не в теме, но разве этим самым js-никам нужно тяжёлое окружение? Мы ведь о С++ говорили.

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

Не понимаю аналогию. То есть, при так же как при повышении цены на бензин растёт цена на хлеб, так и при удорожании железа дорожает… софт?

Ну и в изначальном утверждении было именно «как заставить покупать раму, цпу и прочее». Так зачем же гуглу заставлять это делать? Если условный андроид 20 будет работать в два раза быстрее, то это будет здорово в плане конкуренции с айфоном. А уж потратить эти ресурсы писатели приложений найдут как.

Ну да, но зависимости собираются один раз - можно и потерпеть.

Цена вопроса — дисковое пространство. Собрать boost - 3GB, собрать LLVM в статике, как по дефолту, — 40GB. Оно так немного вроде бы, но раз-дава и место кончилось. У меня 4TB Samsung 960 EVO SATA, чтобы про место не думать. И R9 5950X, чтобы про время не думать. Clang собирается за 8 минут в статике и с оптимизациями. Работать можно нормально. Но это и не лэптоп, вот в чем дело.

Тут я не в теме, но разве этим самым js-никам нужно тяжёлое окружение?

У них свои представления о тяжести, и таки у них тоже окружения, и они тоже «тяжелые». Ажно 500МБ скриптов проект может тянуть из репы. На сайт это всё, разумеется, не попадет. Но зачем-то тянется.

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

Я про это много думаю, как будет выглядеть «пакетный менеджер» для С++. И там получается всё сильно другое, чем то, с чем мы имеем дело в Java и JS. Тут, скорее всего, будет просто навороченная система сборки и управления артефактами. И база данных под этим соответствующая. Это всё — данные, и ими надо управлять соответственно.

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

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

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

Пакеты с метапрограммированием будут будут гибко подстраиваться под окружение. Такое уже делают в Rocket Chip SoC generator. Там есть высокоуровневый протокол, называемый diplomacy, через который генераторы договариваются между собой, какой им всем вместе код генерить, чтобы он был совместим.

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

Типа плохо будет если будет всего 2-3 яп и программеры будут сосредоточены на написании прог а не на изучении очередного яп.

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

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

поэтому и кажется переусложнением

Это нормально, что кажется. И нормально, что не требовалось. Моя работа за деньги сиииильно проще того, о чем я тут вещаю с высокой колокольни :) Зато в собственных хобби-проектах я не оганичен в воображении.

Фишка в том, что как только ты начинаешь работать с кодом, как с данными, так сразу нужно продвинутое метапрограммирование во всём. Software-defined network/storage/radio etc, infrastructure as a code etc... С какого-то момента этот по началу скриптинг быстро становится программированием в большом и ему самому нужны платформы, пакетные менеджеры и интеграция с инструментами разработки. И тут напрашивается логичный шаг, чтобы вот эти сейчас пока что разрозненные индивидуальные инструменты вертикально интегрировать в пайплайн разработки. Вот это даст огромный выигрыш в её скорости и удобстве.

Вот, например, есть language server со своим протоколом, и он позволяет IDE-шкам делать универсальный автокомплит для различных языков. Почему бы не пойти дальше, и не сделать полностью интегрированный бекенд, доступный по RESTful-подобному API? который бы брал на себя задачи управления кодом и ресурсами проекта, версионирования, сборки, отладки и вот это всё, что доступно за кнопочками в IDE. И вот с этим бекендом могут уже интегироваться не только IDE (которые при этом сильно упрощаются), но и другие автоматизированные пайплайны.

Фишка в том, что в Clang для этого уже многое в хорошей степени готовности. Там задача в том, как эти разрозненные инструменты объединить общей моделью данных.

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

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

А ветер бывает от того что деревья колышутся.