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

набор инструкций проца как бы не меняется в зависимости от ЯП

Ты уже перестал пользоваться языком SQL?

Что же за язычок это такой, чтобы после 15 лет его разработки — risum teneātis, amīci! — его надо насильно проталкивать.

Извини меня за такую реакцию. Но кидать в одну кучу Rust и JS - это какая-то дичь, ничем не подкреплённая. Особенно глупо звучит «Опять же как заставить покупать раму, цпу и прочее ?», учитывая что Rust даже в AVR можно с некоторым усилием скомпилировать.

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

Устарело уже. Или как выразились бы некоторые присутствующие: «Методичку почини». Теперь есть GhostCell, на котором можно двусвязный список.

его надо насильно проталкивать

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

Почему ? Даже хранимые процедуры на пистоне юзаю …

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

х-к х-к и в продакшен, на С так не выйдет.

Чего-чего? Как это выглядит? Программисты на С стоят грудью: «Ни фига, я ещё не все рейс-кондишны и UB вычистил! Код в продакшн не пойдёт»?

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

на С так не выйдет

Еще как выходит.

Теперь есть GhostCell, на котором можно двусвязный список

ансейф на ансейфе ансейфом погоняет, впрочем ничего нового

ансейф на ансейфе ансейфом погоняет, впрочем ничего нового

Не читал, но осуждаю. Ничего нового. Этот GhostCell идёт вместе с доказательством корректности.

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

Болван, предоставить безопасный интерфейс к доказано-корректному коду возможно не в любом языке.

Хорошая новость. Больше Rust - меньше багов. Хотя я надеюсь, что фуксию перепишут на Rust и вопрос ядра ОС будет закрыт раз и навсегда.

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

В безопасном подмножестве Rust почти нет UB, а в С++ даже толком нет списка этого самого UB. UBSanitizer решает (не всё), но это инструмент не языка, а конкретного компилятора. Задача отслеживания UB ложится на плечи программистов. Rust будет лучше С++ в этом отношении, предполагая, что unsafe-код UB-корректен. Последнее достижимо, если такого кода немного и он тривиален. В противном случае Rust будет не сильно лучше С++, так как UB может распространяться далеко за пределы unsafe-блоков. мой личный опыт — минимизировать количество и сложность unsafe-кода не так-то просто, но тут уже предположили, что это, скорее всего, из-за отсутствия у меня скиллов.

Our soundness proof is done within RustBelt, a machine-checked proof of safety for a significant subset of Rust

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

К настоящим доказательствам корректности кода эта хрень не имеет никакого отношения.

фуксию перепишут на Rust и вопрос ядра ОС будет закрыт раз и навсегда

Rust (был) недостаточно стабилен для того, чтобы предоставлять стабильный ABI. Можно было обойти через ReprC, но решили (пока) не связываться.

К настоящим доказательствам корректности кода эта хрень не имеет никакого отношения.

Гы. Классика. И опровергнуть нечего. Кроме как послать подальше.

Устарело уже. Или как выразились бы некоторые присутствующие: «Методичку почини». Теперь есть GhostCell, на котором можно двусвязный список.

https://crates.io/crates/ghost-cell

Опять крейт от васяна :(

Так же как нельзя даже строку вывести со своим форматом задающимся в рантайме, нужен крейт от васяна :(

https://crates.io/crates/runtime-fmt

let s = "hello {}";
println!(s, "world");

error: format argument must be a string literal
 --> <source>:4:14
  |
4 |     println!(s, "world");

я ещё не все рейс-кондишны и UB вычистил!

драйвер хоть один уже написал или пукать зашёл?

С unsafe двухсвязный список можно было делать сразу. И просто доказывать корректность unsafe-блоков внешними средствами. Доказал — отлично. Не доказал — ну, извини. Ошибся — нам всем ПЦ.

Так же как нельзя даже строку вывести со своим форматом задающимся в рантайме, нужен крейт от васяна :(

Да, это не то что это грёбаный Ц, бывает напишешь printf, и делаешь 23 раза ЮБ. 1600 строк божественного растокода, там ещё и зависимости какие-то. Всё нужно отревьюить, ведь безопасность превыше всего, но мне это только за рдость, ведь так я перенимаю передовые практики от ведущих дошколят потягивая прохладный, банановый смузи. А самое главное - абсолютно никакого оверхеда, раст умеет крейт_от_васяна оптимизацию, там буквально останется один mov в итоге.

вместо того чтобы родить нужную либу на С++

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

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

На нем уже мегатонны кода написали, а кому-то фичь не достает …

Да, вариантов UB в ржавом в сотни раз меньше

На С тоже, это вообще ортогонально: количество фич и количество написанного кода. И почему «фичь» с мягким знаком, зачем он там нужен?

Ну как бы, ООП, числовые обобщенные параметры, HKT. С другой стороны — макросы и лайфтаймы.

При чем тут варианты UB, это вообще не фича. В расте нет variadic templates, киллер-фичи C++, начиная с C++11. Поэтому растовские шаблоны - кастраты.

И почему «фичь» с мягким знаком, зачем он там нужен?

Sorry, конечно …

Ну как бы, ООП,

Конечно, без ООП и 2 + 2 не вычислишь …
Вообще то он крайне редко и нужен то.
То, что ООП-нутые его всюду стараются использовать, так это от того, что они ООП-нутые …

числовые обобщенные параметры

Это в расте недавно стабилизировали.

Поэтому растовские шаблоны - кастраты.

Ну они такими и задуманы, вместо плюсовых убершаблонов там макросы. Ну и растовсая система типов скорее не в сторону с++ шаблонов будет развиватся а в сторону хаскелевских hkt.

Там стабилизировали минимальное подмножество. Лучше, чем вообще ничего, но до юзабельности еще далеко.

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

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

для тех у кого проблемы при работе с memory

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

Ну они такими и задуманы, вместо плюсовых убершаблонов там макросы.

Плохо задуманы. Метапрограммирование уровня AST не заменяет метапрограммирование уровня типов. Метапрограммирование уровня типов в Rust хорошо если вообще дотягивает до С++98.

Посмотри, какую часть кода занимает мономорфизатор в clang и представь, что вот это вот всё придется делать макросами. В добрый путь! То, что в 21 веке решели не делать числовые обобщенные параметры, да еще так, что потом, когда общественность убедила в их необходимости, пять лет их внедряли и так толком еще и не внедрили — это что-то, а не дизайн. Rust — язык очень опиньонутый. Но для опиньонутых языков он слишком медленно движется вперед.

Сейчас, он, конечно, дозрел до практического использования. И вакансии по нему встречаются. И job security уже какая-никая есть. И задачи имеются, и инфраструктура. И код уже какой-никакой понаписали. Так что, кого унаследованная кодовая база С++ не удерживает, можно и на Rust перебираться. А кто на С++ сидит ровно, лучше инструменты метапрограммирования развивать. Я вот сейчас кастомный кодогенератор/мономорфизатор на основе бибилиотек Clang приделываю.

Сколько суток после этого будет компилироваться ядро?

Если так задуматься - в штаны сутся,

Дополню

И на форумах срутся

Я вот сейчас кастомный кодогенератор/мономорфизатор на основе бибилиотек Clang приделываю.

А поподробней?

Есть надежда, что gccrs будет пошустрее того, что сейчас имеем.

А вообще, не думаю, что будет проблема со временем компиляции.

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

Microsoft этот язык программирования одобрила.
Все

.

Я в своем проекте (персистентные структуры данных для внешней памяти) активно использую шаблонное метапрограммирование для генерации сложных B-tree-подобных структур по метаданным. Ну и уперся в то, что оно не масштабируемое. Трясина Тьюринга by design. Основная проблема с шабонами в том, что их очень трудно отлаживать. Поэтому, чуть что нетривиальное, и трудозатраты на написание такого кода уходят в космос.

Сейчас я делаю кодогенератор, где TMP будет частично заменено питоновским кодом, которому будет дан доступ в компилятор, чтобы можно «вручную» инстанцировать шаблоны, проверять выполнение предикатов и вот это вот все остальное, что умеет Boost Hana, но только в обычном процедурном стиле, с верификацией и отладкой.

Выглядеть это будет примерно так:

template <typename Key>
class [[clang::annotate(R"(
    @CtrTF = {
        "generator": "set_ctr_generator.py"
    }
)")]]
CtrTFMeta<Set<Key>> {};

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

На будущее в планах внедрить расширение clang — оператор metacall(), который будет вызывать произвольные функции во время копиляции. Оно будет использоваться вместо python. прототип уже есть.

В тот-то и идея, что если у С++ починить видимый обычному прогеру тулинг, которой у нас застрял на уровне 80-х, то С++ будет не сильно хуже Rust в плане программирования в большом. Да, линейных типов не будет. Да, всё еще будет много UB. Порешаем в будущем.

Если так задуматься - в штаны сутся

Я этим занимался только до того как пошел в школу.

Владимир

Если так задуматься - в штаны сутся

Я этим занимался только до того как пошел в школу. Там отучили …

Владимир

Ну а чо, денег дохера, можно и растаманов в ядро допустить.

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

Бро, у тебя логика в обратную сторону работает. Во-первых, возражая на мой коммент ты фактически повторил его: «корректно написанная программа на C/C++ аналогична программе на Rust». Я именно это и написал.

Во-вторых, ты используешь «можно так же написать» как какое-то достоинство. Знаешь язык, на котором «можно так же написать» как на вообще любом языке? Это ассемблер. «Можно так же написать» - это просто указание на достаточную низкоуровневость языка. Качество ЯВУ определяется не столько тем, что на нём можно написать, сколько тем, какую работу можно переложить на компилятор. Вот в этом и преимущество Раста: его компилятор проверяет корректность программы на том уровне, который в C/C++ просто отсутствует. И собственно за это его и хейтят. Там где C/C++ перелопатит исходник, rustc попросит объяснить ему некоторые подробности о том, как должен функционировать код. Хороший добросовестный программист на C/C++ эту работу и так делает, он описывает это в комментариях и/или документации, для него переход на Rust, ну кроме нового синтаксиса, означает только что вместо описания на естественном языке он пользуется формальной нотацией. А Раст, в благодарнось за это, проследит, что если кто-то поменяет правила работы с ресурсами, то он и обновит описание и исправит существующие обращения. Страдают от Раста только ленивые рукожопы, которые не хотят описывать это.

Немного подожгу пукан луддитам:

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

Ты еще добавь к делу, что оно к вечеру, может быть, и скомпилироваться-то еще и не успеет)

Хипсторы Golang выбирают, а не Rust.

На чём? На хламе из середины нулевых - может и вовсе не скомпилироваться. На железе последних лет пяти - за пару часов максимум.