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

за пару часов максимум.

прогресс, который мы заслужили

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

А можно подробнее, ссыль на дискас/переписку там? Интересно же)

Я так, мимокрокодил, но вроде как добились возможности сборки ядра шлангом, не? Это к тому, если шланг собирает, то и компилер может быть на LLVM…

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

Суть Раста не в написании 100% безопасного кода. Так можно писать в основном лишь хелловорлды. А в том, что у тебя есть ~100% понимание, где код безопасный, а где небезопасный (там где используется unsafe). И в том что ты получаешь это за минимальную цену в плане производительности (zero-cost abstractions). Разумеется, это в идеале. И это гарантируется языком и конпелятором, а не одними ключами конпелятора.

Печально, когда будет готово гугле как платиновый спонсор линукса вероятно привлечёт ещё конторы и просто начнёт проталкивать ЭТО недоразумение в ядро. А потом ваще как в нетБСД драйвера на lua писать. Хотя тут даже всё было бы хорошо Lua няшка и просто клей в этом случае. Разве что синтаксис дерьмовый.

Вот в этом и преимущество Раста: его компилятор проверяет корректность программы на том уровне, который в C/C++ просто отсутствует.

Вот отсюда мальца подробнее. Или Вы про то что на варнинги gcc некоторые люди плюют ?

Там где C/C++ перелопатит исходник, rustc попросит объяснить

Почему это звучит так ? Разве оно не долждно звучать как :

Там где C/C++ перелопатит исходник, RUST попросит объяснить

или

Там где gcc перелопатит исходник, rustc попросит объяснить

И вообще из всего ВАМИ сказано есть простой вывод, написали ли бы gcc2 и не фиг страдать.

Я уже писал выше и повторюсь, нет чтобы усовершенствовать то что есть и приводить к единообразию чтобы потом сосредоточиться на написании прикладных программа или системных, повышать их качество, изобретают очередной язык и с криками и хайпам оруть давай все существующее на ЭТО перепишем это типа КРУТО ! Время идет и так по кругу :(

Чем отличается хипстор-смузихлёб от программиста старой школы?

Звучит как : Зачем вы людей юзающих падонский язык хотите научить русскому(ну то что в школе припадают).

Я в своем проекте (персистентные структуры данных для внешней памяти) активно использую шаблонное метапрограммирование для генерации сложных B-tree-подобных структур по метаданным.

Пост интересный, но не видя результата генерации B-tree-подобной структуры трудно что-либо обсуждать.
В крайнем случае подкорректируйте для публикации код, который считаете приватным …
В листьях хранятся одинаковой структуры данные или разные?

… Если так задуматься - в штаны сутся и на форумах срутся, на улице теряются, ещё и памятью управлять как-то надо.

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

А в том, что у тебя есть ~100% понимание, где код безопасный, а где небезопасный (там где используется unsafe).

Вот-вот-вот, вот в этом-то и проблема, что люди считают, что unsafe отделяет безопасный код от небезопасного. Ничего подобного. Unsafe определяет границы зон действия различных систем правил языка. А UB из unsafe-блоков будет распространяться на всю программу. Или UB-эффект при пересеченни unsafe магически превратится в DB? Может быть повреждение содержимого памяти само как-то вылечится? Всё, что Unsafe-блоки нам дают, это облегчают работу UB-санитайзеру, которому нужно проверять «меньше» кода.

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

Пост интересный, но не видя результата генерации B-tree-подобной структуры трудно что-либо обсуждать.

Вот тут всё есть.

Если конкретно, то хочется уйти от этого к чему-то более сопровождаемому. Если коротко, то продвинутое TMP требует и структур данных, размечать которые списками типов слишком трудоемко. А обрабатывать их в виде тех же списков типов еще сложнее. Выход — описывать сложно-структурированные type traits в виде json-подобных документов, по которым уже генерить простые (для человека) TMP-фрагменты.

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

Спасибо!

Внимательно /почти/ посмотрел.
Вы спрашивали, что такое «сложные объекты».
Вот ссылка на исходник как раз демонстрирует один из такого рода объектов.
Можно было бы на порядок усложнить вашу b-tree подобную структуру …
Так вот API, которое разрабатываю умеет работать с объектами любой сложности /в memory и ныне разрабатываю API для файлов/.

Теперь вопрос по кодогенератору.
В коде у вас в коде все логично …

Ну и до кучи еще по ходу весь бойлерплейт генерить, который сейчас руками пишется

Каким образом?
Ведь b-tree подобные структуры /из других ваших постов/ могут весьма отличаться?

Интересный тред Релиз SQLite 3.36.0 Релиз SQLite 3.36.0

У меня для SQLite имеется отдельный проект для Visual Studio и код проекта является не одним файлом, а совокупностью файлов.
Супер удобно!

Хотел было в SQLite много фич добавить, а потом вот подумал?

Зачем это тебе нужно если API много перекрывает возможности SQLite?

Ныне вот объектно-ориентированную метадата базу данных разрабатываю.
Можно конечно и как обычную СУБД использовать, но много полезней для разработки GUI, reporting, метаданных для любого проекта /вместо текстовых конфиг/, разработки любых форматов данных /графических, мультимедия, … что угодно/.

И эшо …

В мире диванов, зелёного велюра и гитар В мире диванов, зелёного велюра и гитар

Тюремная камера?

КОШМАР

Да, но это не стандартный путь сборки ядра.

https://clangbuiltlinux.github.io/

в шапку включите на всякий случай : https://pvs-studio.com/ru/blog/posts/0733/

Весьма интересно https://www.sql.ru/forum/1335780-a/oop-i-modelirovanie-sistem ООП и моделирование систем

Посмотрел tree их проектов.
API все это умеет …

Кроме этого любое поле может иметь свойства /неограниченной сложности/.

То бишь при разработке алгоритмов можно производить анализ на предмет того - «Имеет ли поле такие то свойства?».
К примеру наличие алиасов поля для разных языков …

Весьма интересно https://www.sql.ru/forum/1335780-a/oop-i-modelirovanie-sistem ООП и моделирование систем

Кстати автор проекта умница, но «по традиции» на всех форумах

Вылить пять тонн помоев, как минимум

Кстати автор проекта умница, но «по традиции» на всех форумах

С github он ghjtrn после общения в форуме удалил …

У меня архив есть и смотрел исходники.

Ему как автору, конечно все просто, но при отсутствии документации и комментариев в исходниках, скорее всего ни кто его проект использовать не будет.

Вот отсюда мальца подробнее. Или Вы про то что на варнинги gcc некоторые люди плюют ?

Понятно, теоретик.

Ворнинги практически бесполезны. То, что конпелятор может подсказать, что возвращать из функции указатель на локальную переменную не стоит, это хорошо. Не менее хорошо если он подскажет, что в используется переменная, которая в некоторых ветках не инициализирована. Но в большой программе из множества модулей он ничего не поймёт. А даже если и с развитием техники он научится понимать, ну напишет он что-то типа «несоответствие практик обращения к переменной x» или, в лучшем случае, «либо поменяй вот это в функции X, либо поменяй то в функции Y». Поэтому C/C++, после выхода Раста превратились в тыкву. Всё, это только для мелких утилит или легаси. Ну или обвешивать новыми костылями от Майкрософта, GSL называется, и фактически превращать в кривой клон Раста, либо оставить C++ на почётной пенсии, вместе с трупом страуса, и пользоваться современными языками.

Там где C/C++ перелопатит исходник, RUST попросит объяснить

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

Я уже писал выше и повторюсь, нет чтобы усовершенствовать то что есть и приводить к единообразию

Зачем? Не нужно усовершенствовать «что есть», когда это что есть несовместимо с усовершенствованиями. У Страуструпа так C++ получился. Доусовершенствовался до языка, в котором 70% фич пользоваться не рекомендуется и при этом type* foo обозначает одновременно переданный по старым сишным стандартам структурный объект, место зарезервированное для возврата значения, массив элементов типа type и указатель на объект, реализующий интерфейс type. Чтоб использовать код на старых языках достаточно нормального FFI, не нужно их уродовать.

Поэтому C/C++, после выхода Раста превратились в тыкву.

оставить C++ на почётной пенсии, вместе с трупом страуса, и пользоваться современными языками.

Когда расскажешь об этом разработчикам раста? А то они до сих пор зависят от C++ и крутых спецов по С++ без которых не было бы раста?

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

Я думаю Zig с парой человек раньше перейдёт на независимость от LLVM, чем Rust со всеми своими фондами, потому что судя по комьюнити программистов в Rust нет…

Я думаю Zig с парой человек раньше перейдёт на независимость от LLVM, чем Rust со всеми своими фондами, потому что судя по комьюнити программистов в Rust нет…

Да, Zig интересный язык …
Хорошо если бы автор языка не начал высокоумничать и вносить в него всякую чушь …
Не помешали бы хорошие examples.
В репах то они есть, но нужны простые examples, которые помогут быстрее понять фичи и синтаксис.

Майкрософт плохого не посоветует!

Да, Zig интересный язык …

https://ziglang.org/download/#release-master
https://github.com/ziglang/zig/wiki/FAQ https://ziglang.org/documentation/master/

Мило. Помнится не так давно подобные ребята рассказывали про то, какой «негодный» этот С++, в ран тайме вся инфа о типах стирается и остаются лишь голые машинные инструкции, то ли дело какой-нибудь C#. Не придумываю, это было реальное кукареканье одного недопрограммиста. Видимо обидно, что весь его «высокоинтеллектуальный» говнокод превращался в набор mov/lea/jmp.

А теперь посмотрите-ка, натива захотелось. Только не ваше это решение, идете как стадо школьниц за модой (ваша фанатичность лишь подтверждает это, ни капли сомнений у адептов нет). И на Расте дело не закончится, 5-10 лет и будешь кукарекать по новой методичке. Если повезёт, то начнёшь что-то понимать на следующей итерации. Иначе как глупенькая школьница будешь раз за разом оказываться в какой-то бане с какими-то мужиками из MS, Google и их коллегами.

Шас спою

А с Zig так спокойненько
Среди верб, тополей да берез,
Все культурненько, все пристойненько,
И решен в нем мета программирования вопрос.

Желаю ВАМ каждый год учить новый разговорный язык. Причем не разговаривать нам нем, не писать книги и т.д. А именно так : Выучил и давай опять новый.

(не в обиду просто так быстрее дойдет … может быть)

Гугл решили угробить Linux ? Надеюсь, что Торвальдс проявит здравомыслие и пошлет их нах**.

Ворнинги практически бесполезны.

Совсем нет. Могу поделиться своим нетривиальным опытом. Меня попросили с помощью вот этого сделать прототип облачной дата-платформы с поддержкой сквозного версионирования данных. Модно это сейчас. В Мемории Git-подобная (персистентная) модель данных, только вместо файлов — произвольные дата-контейнеры. Близкий (но не полный) аналог — Immutable.js, который я Меморией и заменял в порядке эксперимента. В Мемории из коробки только in-memory store, зато на всю память. И с полноценными таблицами. Тогда как immutable.js может работать, ну, с десятками мегабайт json-подобных записей — максимум. Он не для этого (дата-платформы) делается.

Так вот, заменили «на ура» и давай это всё в облако пихать, т.е. нужно данные хранить в облачных БД, а не в RAM. Пришлось мне делать многопоточный блочный кэш в mmap, который блоки может временно хранить локально и переиспользовать. Чтобы был понятнее масштаб, то берем ZFS и приделываем к нему внешний блочный уровень, который может в семантику облачных хранилищ. Всё это на C++ (сама Мемория), Java (платформа) и JS (Web и унаследованная от прототипа часть). Там еще был шоукейс GraalVM, который смог все три технологии собрать воедино, и оно работало.

И представь что? Я написал этот кэширующий уровень за 3 месяца. Я обложился по максимуму санитайзерами (asan, tsan, ubsan) и тестами, выловил дедлоки и выход за пределы массивов. На это ушло еще три недели. И потом оно прото работало больше года. Без единого крэша, дедлока или повреждения данных.

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

Поэтому C/C++, после выхода Раста превратились в тыкву.

С под угрозой, да. А на С++ работает огромная накопленная качественная кодовая база, которую не будут переписывать на Rust. На это очень надеялась Java, что всё на неё перепишут, такую быструю и безопасную (всё истинная правда). Но не случилось. Вместо этого люди стали использовать Python поверх C++.

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

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

От БД нужно три вещи:

• Базовые структуры данных (btree, lsm-tree, просто линейные файлы, или всё это поверх другой БД делается)
• Модель конкурентного доступа (MVCC или нет, транзакции или просто атомарность и т.п.)
• storage layer и гарантии дурабельности, им обеспечиваемые.

Хз в сём твоя проблема.

Rust, конечно, во многих отношениях лучше C++

Может быть и так.
Возьмем к примеру STL.
Конечно многие программисты ее используют и вообщем то она надежно работает.
Но, ограничение на оганичениях и ограничениями погоняет.
Поэтому то для 2 + 2 она вроде и ничего, но многим алгоритмам нужен не просто array, содержащий int, а элементы, которые имеют разные структуры, …
В результате для 2 + 2 все хорошо,

А на большее ты не рассчитывай  

Повторяться не буду на счет своего API … /в нем этих проблем нет/.

В rust имеются свои библиотеки, но и в чем то они и интересны и сравнивать их с C++ какой смысл?

Они братья

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

Что тут публиковать?
Были посты в которых говорил не однократно о том, что у меня в run-time подержаны #include.
Передаем функции путь к родительскому #include, остальные все зависимые от родительского на автомате парсятся и можем динамически работать с любой структурой …

Какая для этого публикация нужна?

Какая для этого публикация нужна?

Которую можно почитать и понять.

Были посты в которых говорил не однократно о том, что у меня в run-time подержаны #include.

Вообще то вы правы, что публикация нужна.
Надеюсь все же разработаю и опубликую rapid систему /конечно бесплатно/.

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

Которую можно почитать и понять.

Нет на это пока сил и времени.
В целом, разрабатывается OLE.
В run-time можно работать с любой сложности объектами и динамическим кодом.

Публикация конечно будет, но пока все все «на плите варится» …

Рановато еще.

Суть моих постов в том, чтобы обратить внимание разработчиков на то, что имеются множество задач, которые эффективнее и быстрее решаются с использованием метаданных + динамических объектов и динамического кода.
Конечно после окончания диалога с вами не буду повторять об этом много раз.
Скорее всего после разработки API предоставляющего возможность работы с объектными базами данных расскажу об оных.

И представь что? Я написал этот кэширующий уровень за 3 месяца. Я обложился по максимуму санитайзерами (asan, tsan, ubsan) и тестами, выловил дедлоки и выход за пределы массивов. На это ушло еще три недели. И потом оно прото работало больше года. Без единого крэша, дедлока или повреждения данных.

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

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

Ну, теоретически llvm можно переписать на Расте. Учитывая любовь растоманов к переписыванию всего, возможно это даже и произойдет, хотя, конечно, не к чему это. А вот без ассемблера вообще никак. Значит ли это, что ассемблер не устарел?

Я ждал другого продолжения. Как санитайзеры спасли.

Раскрой вопрос?)

Видимо из этого следовало что студенты могут писать без единого коммента, конечно, крутой и безопасный код, верно?

Из этого следовало, что «ворнинги» не бесполезны. Тулинг свое дело делает.

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

Rust в этом отношении тебе даст не сильно больше, чем С++. Семантика владения в Rust слишком низкоуровневая, чтобы легко читаться невовлеченным человеком. Еще одна «трясина Тьюринга». Вот есть аналогичный пример — дженерики Java, которые тоже полны по Тьюрингу, то есть на них потенциально можно выразить любые ограничения на типы. Но я за 15 лет их существования так и не осилил выражать на них что-то сложнее тривиальных вещей. И плотно их использующий Tinkerpop API для графов для меня за гранью понимания (нет, но разбираться не хочется).

Линейные типы — это хорошо, но формальные методы верификации либо сильно ограничивают выразительность языка, либо не масштабируемы. Им альтернатива — это вероятностная валидация, которую индустрия и применяет: те самые многоуровневые тесты, статические анализаторы, санитайзеры времени выполнения и метапрограммирование. «Ворнинги» работают. Просто они работают «не так», как формальные методы и «не тогда».

Значит ли это, что ассемблер не устарел?

Конечно. Знание ассемблера это очень важно. Как иначе репортить разработчикам компиляторов про плохую оптимизацию?

дженерики Java, которые тоже полны по Тьюрингу, то есть на них потенциально можно выразить любые ограничения на типы

Что, и завтипы можно? Сомневаюсь что-то.

Вот еще одна true story. Я в прошлом году заинтересовался темой аппаратной реализации структур данных и RISC-V. Купил себе FPGA-акселератор для «поиграть». Ну и начал вникать в процесс разработки цифровых схем. Так вот, там самая большая проблема — это валидация и верификация, и это занимает основное время разработки.

Туда, в цифровые схемы, сейчас активно проникают техники программной инженерии, такие как software construction. И вот уже SiFive продается (по слухам) Интелу за $2B.

Но и нам, «софтовикам», есть чему у «цифровиков» пойчиться. А именно масштабной валидации и верификации. Так вот, это процесс обширный и многоуровневый. И линейные типы Rust тут только один эпизод, ничего принципиально «в большом» не решающий. Перескакивать ради одних только линейных типов на совершенно новый язык и терять наработанную кодовую базу — это странное решение.

Новые проекты, не привязанные к существующей кодовой базе С++ — да. Это нормально. В ядро — тоже нормально. Но говорить, что Rust убил С++ — преждевременно))

Я хз. Пейпер с доказательством полноты был, я его видел. Искать лень))

А именно масштабной валидации и верификации.

Много раз писал об этом посты и не публиковал …

Много раз писал об этом посты и не публиковал …

Ну кто ж тебе виноват?)

Ну кто ж тебе виноват?)

Это к тому, что ваш пост мне «по душе» …

Да и по своим разработку говорю лишь о том, что считаю допустимым.
Да все так поступают …

Да и по своим разработку говорю лишь о том

Надо не только лишь говорить. А то собирать всё это из кусочков анонимных постов — это всё равно, что бодаться с борроу-чекером: разбираться почему «вот эта вот переменная ну никак не может быть проброшена воооон туда».