Продемонстрирована возможность разработки частей Linux на Rust

Вот с чем вы боретесь? С тем, что memcpy нельзя использовать как bcopy? И как rust побеждает эту ужасную болезнь?

В Rust это приведёт к ошибке компиляции.

Серьезно?

ага, еще и заодно лечит от опущения матки

У кого что болит, тот о том и говорит.

Женщины прекрасны! И думать о них - немного прикоснуться к прекрасному.

он даёт возможность разыменовывать сырой указатель, вызвать unsafe функцию, и изменить статическую переменную.

Что в свою очередь позволяет нарушать гарантии языка. Но формально ты прав, да.

Rust нестабильный by design.

Это что за бред?

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

у руста свое особенное уличное арифметическое переполнение?

Ты рассуждал про обработку переполнения в Rust, но эти рассуждения не верны, т. к. в Rust переполнение — это ошибка времени исполнения. Для типичного поведения из С/С++/etc есть методы wrapping_OPERATION. Если бы ты хоть немного почитал Rust Book, то я уверен, что у тебя была бы более конструктивная критика.

std::u8::MAX + 1; // ошибка в debug runtime, но в release её не будет, из-за соображений скорости исполнения
// проверки можно форсировать флагом для компилятора -Z force-overflow-checks=on

std::u8::MAX.wrapping_add(1); // == 0

Серьезно?

Да. Из-за системы владения Rust не позволит взять константную и изменяемую ссылки на один объект одновременно.

play

Женщины прекрасны! И думать о них - немного прикоснуться к прекрасному.

Не спорю, но всему есть своё место и время.

владения

Поправочка, заимствования.

Да, знаю, ещё я забыл сделать src мутабельной.

play

Если бы ты хоть немного почитал Rust Book

Я начал читать, а потом выяснилось, что пишут вторую редакцию и рекомендуют начинать с нее.. Но она еще не дописана.. И вообще что здесь происходит. Завис, короче

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

Язык неплохой, но кто вообще в двадцать-семьнадцатом создает язык без поддержки JSX на уровне синтаксиса. Не взлетит

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

Фто? Исходников компилятора нет в публичном доступе. А компилятор есть. Кто кому врет?

Читай вторую, она почти готова

погоди, тут же выше кто-то писал(мне лень искать) что koi-8 используется потому что компилятор ругается в кои-8 а менять было невозможно.

только не говорите мне что у них были сорцы но они не смогли в iconv

Троллейбус из буханки же?

погоди, тут же выше кто-то писал(мне лень искать) что koi-8 используется потому что компилятор ругается в кои-8 а менять было невозможно.

МЦСТ отдал чувакам цомпилятор, тулчейн и базовые пакеты. Они наворотили вокруг этого дистрибутив. Решили оставить koi8-r.

только не говорите мне что у них были сорцы но они не смогли в iconv

У мейнтейнеров дистрибутива не было сырцов lcc, да. Что мешало им сделать sh-скрипт, который stdout и stderr прогоняет через iconv, лично мне не очень понятно. Маны тем же образом можно было прогнать через iconv и схоронить отдельно. Работы на пять минут, йопт.

а я уж было подумал что сорцов не было у разрабов эльбруса.

а я уж было подумал что сорцов не было у разрабов эльбруса.

Это было бы совсем странно.

ну в мою бытность там вполне себе сделали компилятор х86->итаник. и что удивительно - у них тоже «два кластера, блаблабла».

Да. Из-за системы владения Rust не позволит взять константную и изменяемую ссылки на один объект одновременно.

Ты несколько передергиваешь. Вообще речь была о memcpy и bcopy. Там это проконтролировать невозможно. Чтобы два раза не вставать: в расте массивы с контролируемыми границами только когда требуется или всегда?

А за тотальной безопасностью идите в языки с GC, где подобные вещи вообще не сделать никак

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

Да и что это за фукция main, которая ничего не возвращает? Каким образом это должно работать в ядре или с ядром?

У тебя совсем мозг закостенел или как? Серьёзно не можешь представить как это может работать?

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

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

Вообще речь была о memcpy и bcopy. Там это проконтролировать невозможно.

Вот, смотри, у нас есть функция:

fn copy(src: &[u8], dest: &mut [u8]) { /* impls */ }

Она копирует содержимое одного среза в другой. Rust гарантирует, что невозможно одновременно создать const и mut ссылки на один объект. Указатели используются только в unsafe, по-этому в безопасном режиме нет никаких ошибок связанных с указателями.

Ты не можешь сделать так:

let mut data = ...;
copy(&data, &mut data);

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

Если тебе надо копировать перекрывающиеся области памяти, то это будет только в рамках среза, Rust по другому тебе это сделать не даст.

fn copy_in_slice(dest: &mut [u8], from: usize, to: usize, len: usize) { /* impls */ }

Конечно, можно включить крутого сишника и написать unsafe (aka memmove, bcopy). Rust этого не запрещает, см. std::ptr::copy. В этом случае ты и те кто пользуется твоей функцией должны быть предельно внимательны. Суть unsafe в том, что когда ты его видишь, то ты должен включать крутого сишника и читать документацию, вне unsafe можешь сосредоточиться на решаемой задаче.

unsafe fn copy_overlaps(src: *const u8, dest: *mut u8, len: usize) { /* impls */ }

Чтобы два раза не вставать: в расте массивы с контролируемыми границами только когда требуется или всегда?

Всегда. Размер может быть известен во время компиляции, это [TYPE; COUNT] (массив) или во время исполнения, это &[TYPE] (срез). Срез по сути пара из указателя и размера области.

struct RawSlice {
    data: *const u8,
    len: usize,
}

в расте массивы с контролируемыми границами только когда требуется или всегда

в дебаге всгда, в релизе отключаются

в дебаге всгда, в релизе отключаются

Пример в студию!

Всегда они там есть. И в релизе и в дебаге. Но если оптимизатор сильно не насиловать (как тут https://play.rust-lang.org/?gist=8573e34a3bfece2dced474e39f78619a&version... ), то он неплохо их выкидывает. Ну и всегда есть get_unchecked().

Ты неправильно ссылки даешь, надо так:

https://godbolt.org/g/iMcgE2

И видно что black box помешал убрать проверки

А если один black box убрать то проверки пропадут:

https://godbolt.org/g/2ElTE6

Тогда уж так: https://godbolt.org/g/J7ckUd , чтобы всё вместе

debuginfo лучше выключать, толку от раскраски никакого, плюс оно еще frame pointer добавляет.

и что-то переписать на нём

Дело именно в языке. Rust из коробки поддерживает многопоточность и управление памятью без возни с указателями, что, теоретически, должно решить «классические» проблемы языков с new/dispose, где часто происходит разыменование пустого указателя или выход за границы. Тут подобные вещи всплывают ещё на этапе компиляции.

Но всё-таки это не формальная верификация и АНБ дальше сможет совать бэкдоры.

А ещё бэкдор можно засунуть в спецификацию, на соответствие которой верифицируют, и в железо, и в Coq.

SystemD не просто так включают почти везде.

Ну да, усилия редхета по его проталкиванию не проходят даром.

но по сравнению с инит-скриптами это прогресс.

Да по сравнению с инит-скриптами и upstart - прогресс. Вот только переход на systemd предполагает не только усовершенствование инит-системы, а также замены системы логгирования, входа в систему и пр. на всякие непотребства. В итоге модульная ОС потихоньку превращается в монолит. А это уже деградация.

Ну выход за границы массива на этапе компиляции никак не проверить.

Эта несчастная проверка хотя бы 2% от рантайма съедает на чем-то новее первого Атлона?

Утверждение оратора выше - некорректно. Не более.

руст - язык для компилятора, а не для людей

D тонуть не собирается.

Потому что он уже на дне?

Не для котов, люди вполне довольны

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

И то, там в большинстве modified Harvard с общей памятью как у von Neumann, но раздельными шинами данных и инструкций (и раздельными кэшами, когда они есть).

Не для котов, люди вполне довольны

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

Синтаксис действительно убогий. Они хотели сделать похожим на плюсы.

Ну не под паскаль же косить, энивей.
Сиподобный синтаксис убор by design, но он привычен

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

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

Т.е. раст язык не для промышленного использования

Раст — язык не для веба. (не того веба, о котором сейчас говорят в 99% случаев)

<sarcasm>
PHP, JS, GO: прыгая жопой по клавиатуре можно писать боевой код
C, C++: код, написанный жопой, скомпилируется, но отлаживать придется руками, долго
Rust: код можно писать только руками, но, если он скомпилировался, он работает
</sarcasm>

Rust: код можно писать только руками

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

для раста нужны люди со светлой головой и прямыми руками

Сочту за комплемент, но это скорее про сишников, работающих с критическими элементами инфаструктуры: программисты kernel-space, middleware итд. Там действительно единственный инструмент (не очень надежный и требующий перепроверять себя много раз) — это твоя голова, нужна дисциплина, правильный менеджмент и хороший QA.

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

Возможно ли такое написать на твоем любимом D?

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

Да, конечно, можно. Как на продвинутом Си. Но если не упарываться и писать нормально, с использованием стандартных библиотек, то нельзя.

Точнее, сам *полезный* код компактен и на куче тоже ничего не выделяет. Но компилятор обвяжет его массой другого кода, для интроспекции, для проверок и т.п.

В этом легко убедиться, вставив нижеследующий тупой код (постарался сохранить почти буквальное соответствие с твоим, с очевидной глупостью в d-шном аналоге) в https://explore.dgnu.org/ (с опциями компилятора -O3 -frelease, чтобы не разбираться в «мусоре»), или в https://d.godbolt.org/# с соответствующими опциями для нужного компилятора.

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

import std.stdio;
import std.string;
import std.conv;
import std.typecons;

struct Data {
    string v1;
    ushort v2;
};

alias Ok = Tuple!(bool, "ok", string, "what");

Ok fun(ref Data result, string s) {

bool rc = true;
Ok ok ;

    auto lines = s.lineSplitter(); // память НЕ выделяет, возвращает ЛЕНИВЫЙ диапазон

    foreach(walk; lines) {
	
	auto ss = walk.strip();
	
	if (rc) {
	    if (empty(ss)) {
		
		ok.ok = false; ok.what =  "no value1";
		return ok;
		
	} else {
	    rc = false;
	    result.v1 = ss;
	}
	}
	else {
	    try {
	    result.v2 = parse!short(ss);
	    break;
	    }
	    catch(Throwable e) {
		ok.what = "can not convert value2";
		ok.ok = (rc =  true);
	    }
	}
    }
ok.ok = rc;
return ok;

}


unittest {
    
	Data data;
	assert (false == fun(data, "  Hello, World !  \n  42").ok);
	assert(data.v1 == "Hello, World !" );
	assert(data.v2 == 42);
}

Мейерс с тобой не согласится :)

Возможно, я только Мейера знаю, но там дела еще хуже чем у D :(

p.s сам то язык мне очень нравится, но в итоге неудочной политики распространения популярен не стал.

Rust: код можно писать только руками

Сочту за комплемент, но это скорее про сишников, работающих с критическими элементами инфаструктуры

Тебе надо бы определиться.

Касаемо сишников, еще раз коротко: достаточно организационно-дисциплинарных мер. Проблемы начинаются с появлением креативных творцов, запиливающих в OpenSSL возможность возобновления сессии после разрыва соединения (просто подавляющему большинству это нахрен не нужно, но самое ужасное - это большинство и не подозревало об этой возможности), в баше - переменными экспортировать функции (да 95% даже и не подозревало, что так можно).

О rust'е. Возможно, мы просто злобные ретрограды и злопыхатели. Должны быть выкатаны рабочие продукты на rust'е, крайне желательно - оригинальные. Будет успех - мы,хейтеры, умоемся кровавой юшкой, посыпем голову пеплом и все такое. Но пока начало жизни у rust'а чрезвычайно болезненное. Вероятнее всего - умрет дитя.

И да, по поводу веб-кодеров. То, что они делают в те сроки, достойно самого величайшего восхищения и глубокого уважения.