Cloudflare выпустила первый публичный релиз Pingora v0.1.0

Ну и конечно всем фанатиками Rust читать https://veresov.pro/rustmustdie/ перед обсуждением.

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

Вот тут давно разобрали вранье про рантайм. Комментарии тоже доставляют. Что характерно, автор rustmustdie стыдливо спрятал английский эквивалент статьи, а он раньше был по ссылке rustmustdie.com

Ну только посмеяться можно.

Хелло ворлд на Расте под Linux x86_64 целиком

#![feature(no_core)]
#![feature(lang_items)]
#![no_core]
#![no_main]
#![feature(naked_functions)]
#![feature(decl_macro)]
#![feature(rustc_attrs)]
#![feature(intrinsics)]

// Нужно компилятору
#[lang = "sized"]
pub trait Sized {}

#[lang = "copy"]
pub trait Copy {}

impl Copy for i64 {} // Говорим компилятору, что объект этого типа можно копировать байт за байтом
impl Copy for usize {}

#[rustc_builtin_macro]
pub macro asm("assembly template", $(operands,)* $(options($(option),*))?) {
  /* compiler built-in */
}

extern "rust-intrinsic" {
  // Чтобы компилятор знал, что есть некоторый код, которого не достичь.
  // Например, весь код после exit()
  pub fn unreachable() -> !;
}

#[no_mangle]
#[naked]
unsafe extern "C" fn _start() {
  // Стырено из книги А.В. Столярова.
  // А, простите, там код под 32 бита, в книге 2021 года.
  // Значит, не стырено.
  asm!(
    "mov rdi, [rsp]", // argc
    "mov rax, rsp",
    "add rax, 8",
    "mov rsi, rax", // argv
    "call _start_main",
    options(noreturn),
  )
}

#[no_mangle]
extern "C" fn _start_main(argc: usize, argv: *const *const u8) -> ! {
  let status = main(argc, argv);
  exit(status);
}

#[no_mangle]
fn main(_argc: usize, _argv: *const *const u8) -> i64 {
  let string = b"Hello, world!\n" as *const _ as *const u8;
  write(1, string, 14);
  return 0;
}

#[inline(never)]
#[no_mangle]
// ! - это never type, компилятор понимает, что функция никогда не возвращается
fn exit(status: i64) -> ! {
  unsafe {
    syscall1(60, status);
    unreachable()
  }
}

#[inline(never)]
#[no_mangle]
fn write(fd: i64, data: *const u8, len: i64) -> i64 {
  unsafe { syscall3(1, fd, data as i64, len) }
}

#[inline(always)]
unsafe fn syscall1(n: i64, a1: i64) -> i64 {
  let ret: i64;
  asm!(
    "syscall",
    in("rax") n,
    in("rdi") a1,
    lateout("rax") ret,
  );
  ret
}

#[inline(always)]
unsafe fn syscall3(n: i64, a1: i64, a2: i64, a3: i64) -> i64 {
  let ret: i64;
  asm!(
    "syscall",
    in("rax") n,
    in("rdi") a1,
    in("rsi") a2,
    in("rdx") a3,
    lateout("rax") ret,
  );
  ret
}

Заметьте, код с ассемблерными вставками. Смешно, что ПРОСТО на ассемблере код будет в разы короче (а также меньше и быстрее).

format ELF executable 3
entry start

segment readable executable

start:
  mov rax, 1        ; write(
  mov rdi, 1        ;   STDOUT_FILENO,
  mov rsi, msg      ;   "Hello, world!\n",
  mov rdx, msglen   ;   sizeof("Hello, world!\n")
  syscall           ; );

  mov rax, 60       ; exit(
  mov rdi, 0        ;   EXIT_SUCCESS
  syscall           ; );

segment readable writeable
  msg db "Hello, world!", 10
  msglen: $ - msg

При этом код на Rust, естественно, содержит unsafe.

А чтобы написать аналогичный код на Си (без libc) нужно буквально несколько строк:

#include <unistd.h>

main ()
{
  write(1, "hello\n", 6);
}

И вы на полном серьезе считаете, что в Rust не нулевой runtime? Чтобы его получить, нужно написать буквально больше, чем на голом асме. В Си можно писать с нулевым runtime достаточно легко. Оверхед очевиден с погрешностью до оптимизатора компилятора.

Зуб даёшь, что в твоём примере на С нулевой рантайм?

Если ты такой любитель писать без stdlib, кто тебе мешает всю эту ерунду, которую ты там выписал, засунуть в отдельную библиотеку так же, как ты ненавязчиво используешь libgcc или где там стартап лежит, а также реализацию write из libc.

Или претензия в том, что авторы Rust не поддержали такой странный юз-кейс из коробки? Но он ведь действительно странный. Никакой разумной причины писать без рантайма обычные приложения не существует кроме желания изучить подробней реализацию языка.

Это претензия к бреду в статье. Rust — максимально уродливый высокоуровневый язык программирования, ничего общего с «нулевой ценой абстракции» (как заявляется в его рекламной политике) не имеющий. Писать системный софт на нем невозможно (нафиг нужен язык, на котором писать сложнее, чем на ассемблере?). Писать прикладной софт на нем тоже невозможно, потому что большую часть времени нужно будет не писать программу, а разруливать ругань компилятора. И со скоростью у него все плохо. Даже если писать «как на си», то он будет медленнее и порой значительнее. (И почему бы тогда просто не писать на Си?) Обращаю внимание, что даже не оптимизирующие компиляторы C обгонят высокоуровневый код на Rust.

ничего общего с «нулевой ценой абстракции» (как заявляется в его рекламной политике) не имеющий

Бенчмарк, подтверждающий это, покажешь?

Писать системный софт на нем невозможно

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

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

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

И со скоростью у него все плохо. Даже если писать «как на си», то он будет медленнее и порой значительнее.

Бенчмарки в студию, или 4.2

Бенчмарк, подтверждающий это, покажешь?
Бенчмарки в студию, или 4.2

Смотри статью.

В-третьих, на расте даже прошивки контроллеров уже пишут. Похоже, что люди, использующие раст, не знают, что это невозможно.

Ты противоречишь сам себе:

Это все совершенно неважно.

Это в итоге важно или нет?

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

Вы, можно подумать, специалист в системном программировании. Про производительность и говорить не приходится. А вся «безопасность» строится на блоках unsafe. Впрочем, программа может упасть и без unsafe. Например, переполнение стека никак не предполагается обрабатываться. Можешь запустить rustc подав ему файл, содержащий, например, 400000 (5000 строк по 80 символов) открывающихся круглых скобок. Он упадет с ненулевым кодом возврата. Проверку глубины рекурсии не сделали, а «магия Rust» не сработала... Вот тебе и «безопасность». А если писать на Си с средствами статического анализа кода, отладчиком и санитайзерами, то ошибок уж точно будет не больше (а может и меньше).

Во-первых, он уже в ядре и на нем пишутся модули.

Во-первых ядро сложно назвать системным софтом, но да ладно. Во-вторых Linux уж точно не показатель. Главному Фину башлают корпорация добра Гугль и Мелкомягкие, а он добавляет что им надо. И это не только с Rust, это почти во всем. Нужно быть слепым, чтобы этого не видеть. В-третьих нормального софта пока никто и не видел. Wrapper'ов понавешали, разговоров поразводили, но ничего действительно полезного не написали. Более того, бОльшая часть хорошего системного софта написана 30+ лет назад.

Смотри статью.

Статья врёт, как мы уже выяснили. Неси адекватные бенчмарки.

Ты противоречишь сам себе

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

Вы, можно подумать, специалист в системном программировании.

Да.

Про производительность и говорить не приходится.

А ты поговори. Давай бенчмарк.

А вся «безопасность» строится на блоках unsafe.

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

Вот тебе и «безопасность».

Не от всего можно защититься. Но даже наличие частичной защиты - лучше, чем ее полное отсутствие.

программа может упасть

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

Нужно быть слепым, чтобы этого не видеть.

Зато хейтерки офигеть какие прозревшие.

Более того, бОльшая часть хорошего системного софта написана 30+ лет назад.

Ппц фантазии.

так с любым языком, надо просто руку набить

Или морду — его разработчикам...

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

Увы тут я с вами не согласен. Как сказал у нас один конструктор - если ты прекрасно владеешь CAD системой и делаешь сложные чертежи то мы можешь думать что ты конструктор но на самом деле это может быть не так.

В программирование точно такая же фигня, ты можешь прекрасно овладеть ЯП и ИДЕ и т.д. писать большие проги но ты можешь быть просто кодер а не программист. Ты просто тупо кодируешь «по учебнику» и все.

Некоторые могут возразить, типа это уже не программист а архитектор или еще кто, это не важно, главное понять смысл а как назовешь это уже не сильно важно.

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

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

Ну во первых не нужно бездумно жонглировать.

А во вторых я понимаю слова «думать над архитектурой» это найти место куда воткнуть очередной unsafe ? Или Вы про то как обмануть компилятор ?

Ты читаешь, на что отвечаешь? Речь о сях.

Rust — максимально уродливый высокоуровневый язык программирования

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

ничего общего с «нулевой ценой абстракции» (как заявляется в его рекламной политике) не имеющий

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

Писать системный софт на нем невозможно

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

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

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

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

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

И со скоростью у него все плохо. Даже если писать «как на си», то он будет медленнее и порой значительнее. (И почему бы тогда просто не писать на Си?) Обращаю внимание, что даже не оптимизирующие компиляторы C обгонят высокоуровневый код на Rust.

Любой язык будет медленней и порой значительнее, чем С. Зачем писать на Rust - на этот вопрос каждый сам отвечает. Я вот тоже пишу на C, т.к. производитель микроконтроллера, который я использую, даёт библиотеки для С, а времени разбираться с библиотеками от энтузиастов у меня нет. С - хороший язык для своей ниши, у которого за плечами больше 50 лет практического применения, создания оптимизирующих компиляторов, десятки тысяч написанных по нему книг, миллионы программистов, которые его знают. Но это не значит, что прогресс на нём остановился. У Rust есть ряд преимуществ перед С, про которые писать в тысячный раз я уж точно не буду. Не всегда эти преимущества перевешивают преимущества C в конкретно выбранном проекте. Но иногда - перевешивают.

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

И что же println! выдает такое, что никогда не сравнится с printf или даже std::ostream (std::cout) из C++ с STL?

Почему эта «нулевая абстракция» весит не 200 байт (а именно примерно столько получится в машинном коде, абстракция же бесплатная), а фиг знает сколько?

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

Я не понимаю зачем эта свистопляска с владением, если есть RAII. Это отличное решение, которое замечательно показало себя в языке C++. Объект просто лежит на стеке, а когда исполнение выходит из скоупа гарантируется разрушение всех объектов, которые были созданы в обратном порядке.

Т.е.:

void
f ()
{
  A obj_1;
  B obj_2;
  if ( obj_1.get_some () > 10)
  {
    D obj_4;
  }
  return;
  C obj_3;
}

Очень простое и предсказуемое поведение. Зачем городить бред с владением как в Rust?

И что же println! выдает такое, что никогда не сравнится с printf или даже std::ostream (std::cout) из C++ с STL?

Почему эта «нулевая абстракция» весит не 200 байт (а именно примерно столько получится в машинном коде, абстракция же бесплатная), а фиг знает сколько?

Я ничего не понял. При чём тут println! и нулевая абстракция? Кто тебе обещал, что у println! будет нулевая абстракция? О каких 200 байтах речь? Нужна нулевая абстракция - дёргай сисколл. У println! есть своя цена, вполне определённая.

Я не понимаю зачем эта свистопляска с владением, если есть RAII. Это отличное решение, которое замечательно показало себя в языке C++. Объект просто лежит на стеке, а когда исполнение выходит из скоупа гарантируется разрушение всех объектов, которые были созданы в обратном порядке.

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

Единственная альтернатива это GC. Но там уже совсем другая цена за удобство.

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

У println! есть своя цена, вполне определённая.

Из всех утюгов: «У нас такой замечательный компилятор, все абстракции бесплатные!» Что и критикуется Вересовым. Очевидно, что это ложь. Но кто-то оспаривает и говорит, что статья Вересова ложь.

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

Как правильно заметили, баги с этим не связаны. Есть куча мест, где могут возникнуть проблемы, но RAII работает нормально (не считая утечки при выбрасывании из конструктора исключения без использования умных указателей).

Когда в коде 3 переменные удержать в голове их еще реально. Когда их в одной области видимости много — программирование превращается в попытку отследить что во что передается.

И совершенно не понятно как передавать одни и те же объекты по указателю в разные функции. Писать unsafe?

все абстракции бесплатные

Ну это очевидная чушь. Как могут быть все абстракции бесплатные. Ты вызываешь функцию. Естественно она не бесплатная. Её код добавляется в исполняемый файл, при вызове она тратит некоторое время на работу.

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

Как правильно заметили, баги с этим не связаны. Есть куча мест, где могут возникнуть проблемы, но RAII работает нормально (не считая утечки при выбрасывании из конструктора исключения без использования умных указателей).

Когда в начале функции объект создаётся, а в конце удаляется - это вообще самый примитивный и простой способ управления жизнью объекта. Для этого никакое RAII не надо, достаточно goto и совсем немного самоконтроля. Любой сишник покажет, если надо.

В реальных программах часто этого недостаточно. Объект создаётся в одном месте, а удаляется в другом. Самый простой пример - функция, считывающая строку с клавиатуры. Строка может быть произвольного размера, поэтому функция выделяет память под строку, и возвращает эту выделенную память тому, кто вызывал эту функцию. И тот, кто вызывал эту функцию, уже должен удалить эту выделенную память. Или отдать её ещё кому-то. И вот тут уже начинаются сложности. В С это будет что-то из разряда комментариев над функцией - мол не забудьте сделать free на возвращаемую строку. В С++ это уже куча машинерии - всякие там конструкторы копирования, move и тп. И хотя в теории на С++ можно писать лаконичный и корректный код, если в объектах всё это реализовано, на практике возможны баги, компилятор тут не проверит всё. В Rust компилятор проверит.

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

Когда в коде 3 переменные удержать в голове их еще реально. Когда их в одной области видимости много — программирование превращается в попытку отследить что во что передается.

И совершенно не понятно как передавать одни и те же объекты по указателю в разные функции. Писать unsafe?

Я бы советовал эти вопросы задавать в профильном разделе, если интересно разобраться.

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

Они отключаются.

Когда в начале функции объект создаётся, а в конце удаляется - это вообще самый примитивный и простой способ управления жизнью объекта. Для этого никакое RAII не надо, достаточно goto и совсем немного самоконтроля. Любой сишник покажет, если надо.

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

В реальных программах часто этого недостаточно. Объект создаётся в одном месте, а удаляется в другом. Самый простой пример - функция, считывающая строку с клавиатуры. Строка может быть произвольного размера, поэтому функция выделяет память под строку, и возвращает эту выделенную память тому, кто вызывал эту функцию. И тот, кто вызывал эту функцию, уже должен удалить эту выделенную память. Или отдать её ещё кому-то. И вот тут уже начинаются сложности. В С это будет что-то из разряда комментариев над функцией - мол не забудьте сделать free на возвращаемую строку. В С++ это уже куча машинерии - всякие там конструкторы копирования, move и тп. И хотя в теории на С++ можно писать лаконичный и корректный код, если в объектах всё это реализовано, на практике возможны баги, компилятор тут не проверит всё. В Rust компилятор проверит.

Есть разные подходы. Можно просто сделать return строки и современный компилятор (это года с 2000, примерно) сам оптимизирует как надо. Можно сделать явное перемещение. А можно просто получить в качестве параметра указатель (ссылку) на тот объект, в который надо записывать. И не надо городить велосипед.

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

Можно просто сделать return строки

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

Можно сделать явное перемещение

Для этого надо выделить память куда-то, куда ты перемещаешь.

А можно просто получить в качестве параметра указатель

… и размер объекта, и проверять, поместится ли.

Всё можно, и всё равно это упирается в конвенции и необходмость ручной обработки и проверки.

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

Поможет. Читай про RVO и NRVO.

Для этого надо выделить память куда-то, куда ты перемещаешь.

Не нужно. Семантика перемещения просто пробрасывает указатели в другой объект на уже выделенную память.

… и размер объекта, и проверять, поместится ли.

Это делается на другом уровне абстракции. Об этом надо думать тому, кто пишет класс строки. Пользователю класса строки об этом думать не надо.

Поможет. Читай про RVO и NRVO

Мы вроде как про си говорили, а ты плюсы зачем-то приплел. В отношение сей все мои замечания остаются справедливы.

Другие возражения будут?

Речь идёт о C++ начиная с RAII. Читай внимательнее.

Читай внимательнее.

Меня совершенно не волнует, что ты зачем-то увел разговор в сторону плюсов. Изначально речь шла о си, я о нем и продолжаю.

Итак, повторяю вопрос. В отношение сей будут другие возражения?

И нет, в Си тоже пишутся отдельные функции для всего этого 1 раз для всего проекта.

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

UPD: Думай, а я пока посплю.

Меня совершенно не волнует, что ты зачем-то увел разговор в сторону плюсов. Изначально речь шла о си, я о нем и продолжаю.

Стоп, что значит Си ? Пока в Rust не завезли классы все было более нормально, это приход классов все усложнил. Так что по отношению к Rust это все таки с и с++ вместе но ни как не отдельно.

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

Ты опять нюхаешь клей? В Rust классов нет.

Прикольно, почитал, оказывается обычные class были в rust давно, потом их убрали. Хм. Они что решили посмотреть что то умное у Go ? Хм. Интересно что ни читал изменения языка по мере роста.

Не нравится слово class можете его опустить и заменить его на ОО язык и не-ОО.

P.S. Еще почитал https://doc.rust-lang.ru/book/ch17-01-what-is-oo.html, не ну точно они все сперли с Go. Хм кому как а лично для меня это + к Rust.

Ты считаешь Rust объектно-ориентированным языком? Потому как отсутствие ООП — очень распространённая претензия к Rust от сторонников C++ и им сочуствующих.

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

А что там может быть размыто то ? Обычная фигня: наследование, полиформизм, инкапсу… есть или нет. Хз как это можно размыть, неважно как это реализовано.

P.S. Еще почитал https://doc.rust-lang.ru/book/ch17-01-what-is-oo.html, не ну точно они все сперли с Go. Хм кому как а лично для меня это + к Rust.

Скорее с Haskell, те же traits — это type classess на минималках.

Мне это очень напомнило структуры и интерфейсы в Go. С Haskell не знаком.

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

И нет, в Си тоже пишутся отдельные функции для всего этого 1 раз для всего проекта.

Человек может что-то забыть, компилятор про деструкторы сам думает.

Надо же, понимание, что компилятор - друг человека, есть. Осталось понять, что в расте компилятор ловит больше ошибок, чем в си или цпп.

А есть зеркало cargo.io или чего там, в России ? И вообще насколько просто написать сложную программу на Rust без интернета ?

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

Хм.

Те я ставлю какой нибудь -devel- и cargo его подхватит ?

Я не понимаю зачем эта свистопляска с владением, если есть RAII

когда исполнение выходит из скоупа гарантируется разрушение всех объектов

Очень простое и предсказуемое поведение. Зачем городить бред с владением как в Rust?

RAII хорошо работает только в простых случаях. Если, например, где-то сохраняется указатель на объект, то можно легко получить use after free:

struct A {
    int some;
    int get_some() {
        return this->some;
    }
};

struct B {
    A* a;
};

void s(B& b, A& a) {
    b.a = &a;
}

void f(B& b) {
    A a;
    a.some = 42;
    s(b, a); // сохраняем указатель на локальную переменную
}

int main() {
    B b;
    f(b);
    if (b.a->get_some() > 10) // используем указатель на уже освобожденную локальную переменную
        return 0;
    else
        return 1;
}

gcc 13.2 флагами -Wall -Wextra -Wpedantic не выводит никаких предупреждений

RAII хорошо работает только в простых случаях.

Везде он нормально работает.

Если, например, где-то сохраняется указатель на объект, то можно легко получить use after free:

Очевидно. Но зачем так делать? Можно написать код, который что-то делит на 0. Но вопрос тот же — зачем так делать?

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

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

Разработчики компилятора gcc чайники? Вот же именно это: Cloudflare выпустила первый публичный релиз Pingora v0.1.0 (комментарий)

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

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

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

В С++ узнать допустимо ли передавать в функцию объект на стеке можно из документации, просмотрев вручную ее код или при помощи стороннего анализатора кода.

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

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

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

Хм. Наверное я слишком старый для оценки красоты и лаконичности.

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

И потом, суть статьи в том, что автор rustmustdie и его недогуру не разбираются в расте, чтобы делать какие-то заявления о нем. Буквально не знают, но мнение имеют. В статье как раз разбирается это вранье. Можно разобрать и остальные выдумки, но слишком много усилий надо потратить.

аналогичный код на Си

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

Цитируй.

На rust писать - лечиться нужно

На rust писать - лечиться нужно

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

В треде просто парад неучей.

По существу есть что возразить, или только чувственные возгласы будут?

И вы на полном серьезе считаете, что в Rust не нулевой runtime?

Дело не в Runtime, а в GC. Сборщик мусора запускается и отчищает память на это тратится время. Если обходиться без сборщика мусора то люди забывают отчищать память и трятят время на отладку.

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

Опять-таки. Давным-давно придуман RAII и «умные указатели». Кстати, что забавно в Rust есть «умный указатель» и называется он box. Вот только проблема, в том, что вместо передачи параметров по указателю (ссылке) используются дурацкая семантика перемещения.

Грубо говоря, как будто в C++ каждый аргумент кастуется к перемещающей ссылке («rvalue reference» в «С++11») по умолчанию. Бред ведь?

А когда говоришь, что нельзя (ЭЛЕМЕНТАРНО!) передать один объект в две функции, тебе говорят «тут надо над архитектурой думать» = изобретать костыли.

Дорогие растофанатики, понимаете, примерно 100% ЭВМ в наше время — машины с Фон Неймана с аппаратной поддержкой стека (а в некоторых случаях даже нескольких стеков), которые спроектированы таким образом, чтобы было легко работать со стековыми фреймами. Вы же придумали какую-то чушь, которая не вяжется с ЖЕЛЕЗОМ. Идиоматическая сущность языка просто не предполагает, что Rust будет исполнятся на типичной вычислительной технике. Да, язык конечно работает, но чтобы использовать возможности ЖЕЛЕЗА он весьма не очевидными преобразованиями приводит «магический» код к коду для стековой машины, и делает это, естественно, коряво. Более того, у всех нормальных программистов это такой мешанины просто взрывается мозг. (Я почти уверен, что если спросить у вас как та или иная сущность Rust будет выглядеть в машинном коде вы даже близко не сможете это представить)

всех нормальных программистов это такой мешанины просто взрывается мозг

Вы смешиваете разные уровни. На 2024 год есть огромный пласт высокоуровнего программирования, где не думаю о низкоуровневом программировании. Это не значит, что код не оптимиируют и не отлаживают, но делают это с другой степенью детализации.

Скорее вы говорите о программировании микроконтроллеров, чем о программировании сервисов, приложений и утилит.

Вы говорите о канальном уровне, когда разработка идет на транспортном уровне и выше (если говорить в системе OSI).

Скорее вы говорите о программировании микроконтроллеров, чем о программировании сервисов, приложений и утилит.

Под современные контроллеры вполне можно писать на расте. Нафигачил околожелезных ансейфов, и вперед.

Чего уж там, уже даже есть микропитон для контроллеров.

Под современные контроллеры вполне можно писать на расте. Нафигачил околожелезных ансейфов, и вперед.

А нафига тогда rust? Навоз на грядки можно на тракторе развозить с прицепом - а можно в поршкаен в салон насыпать и вилами оттуда разбрасывать. И тыкаить потом соседям фермерам - во вы лохи, на тракторе говно возите а я на каене могу.

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

Микропитон кстати да - тоже из того же места ноги растут. Наплодили питонщиков на волне моды - куда их девтать то теперь? А вот сделаем им микропитон - пускай чайники какие нибудь программируют.

Смысл то какой?

Вот, читай.

Жму руку.

«Синтаксический сахар над Ассемблером» - это коротко и точно.

Мерси.

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

Я вон ставил солярку начала девяностых, так там в банальном шелле нет ничего, что сейчас считается за само собой разумеющееся. Автодополнения бинарника по табу нет, перемещения курсора по CLI нет, цветов в ls нет, хотя терминал-то все это позволяет. Пакетный менеджер дубовый и примитивный, без проверки зависимостей. О репозиториях вообще молчу.

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

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

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

Еще тоже вот интересные люди собрались, утверждают, мол диды на сях писали - и ничего, нормально всё было.

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

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

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

Тут скорее ваш типаж всплывает. Этакий юнош со взором горящим похватавший всего модного и уверенный что вот он то сейчас перевернет мир. Роговые очки, напомаженная бороденка, смузик, самокатик. Главно чтобы вот выпендриться. Подходит технология к задаче, не пожходит - главное чтобы было модно молодежно необычно. Натянем трусы через голову не отрываясь от соломинки со смузи.

Помнится в РФ начинали проект Ё-мобиля с бюджетом от Прохорова. Изначально была идея создать что-то вроде мерседесовского (ныне мерседесовского - а изначально тоже молодежного стратапа) смарт. Который таки взлетел. Но нашим же хипстеркам все казалост не так. Авто - ну нет, нам нужен гибрид. Но не такой как у всех - аккумултяор - это же у всех, неее - мы сделаем СУПЕРКОНДЕНСАТОР. Гибрид - взять обычный ДВС? Свой разработать классический (с оглядкой на готовые образцы) или лицензировать или вообще там купить у кого-то - не, это не модно и не круто. МЫ забомбим абсолютно новый мегапуперсуперротор которого ни у кого не было - вот мы на бумажке нарисовали смотрите какой красивый. И где сейчас Ё-мобиль ? Ну понятно что все это модномолодежнохипстерное не могло поехать нигде кроме как в компьютерной анимашке - и это было понятно любому опытному инженеру который не считал выше своего достоинства опуститься до железа и ручки попачкать. Но зато как красиво и складно эта компашка идиотов умела петь собловьями и разводить инвесторов на бабло. Увы - чего не отнять от смузихлебов - так это умения завернуть какашку в бумажку, впарить ее и свалить с баблом пока фантик не развернули.

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

Тут скорее ваш типаж всплывает.

Дальше пошли уже ваши фантазии, которые вы почему-то считаете приличным опубликовывать.

Вы думаете ваш много-обзацевый поток сознания читают?

Вы думаете ваш много-обзацевый поток сознания читают?

Ну вы же прочитали (с) Капитан Джек Воробей

Ну вы же прочитали (с) Капитан Джек Воробей

Ага. По диагонали.

Аплодирую.

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

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

Но как технология - да, если у вас есть некий фреймворк на расте который что-то делает, и вы прикручиваете к нему некий код на сишечке-крестах-асме и этот оптимизированный код занимается свои делом, фреймворк - своим. Кажется где-то я это видел. Лис так написан. Работает, норм. Но причем тут контроллеры не ясно. Если конечно не объявить контроллером железяку по мощности способную потягаться с не самым плохим компом даже и ничего. И есть такие контроллеры в принципе - но я всеже имел в виду нечто более привычное, там где и с памятью не разгуляешься и так вот забыть что-то очистить и не заметить сложновато.

ну почитал

Ты ничего не понял. Перечитывай снова. Обрати внимание на упоминание размера unsafe и верификацию.

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

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

Так чтобы примерно понятно было на примере баз данных. Был отчет написанный таким вот быдлокодером который не знал и не желал знать как там работает этот низкий уровень. Он был художником выского уровня с виртуозным владением SQL и его обвязки - и весь отчет он завенрул в один селект по шикарному (по его мнению) join. Дебилушка возносил себя до небес -ай да я как я красиво сделал - смотрите, это же по сути одна строчка кода. Ай да я молодец. Только работало то что написал молодец примерно часов 60. На хорошем серверном железе своего времени. Пришлось молодца выгнать нахрен и за ним самому переписать. Вернее сначала переписать потом выгнать. Переписанный код был переписан с учетом размера таблиц и структуры индексов и отрабатывал за 5 минут. 5 минут - вместо 60 часов. А почему выгнать - да потому что молодец вместо того чтобы признать что надо учиться стал лить вот это фуфло быдляцкое -в 200* каком уж не помню году есть пласт программирования где не надо думать о том что там низкоуровневого - надо виртуозно знать свой ЯЗЫК и писать на нем КРАСИВО.

Это так в копилку заказчиков и манангеров и разного code reviwеров - как увидите такого «я не думаю о низкоуровневом программировании это ниже моей мегаквалификации» - лучше что вы можете сделать для своего проекта это поставить гения в коленно-локтевую и смачным пинком оправить в полет подальше. Ибо разгребать потом конюшни насранного такими гениями - гораздо дороже чем убрать срулей сразу. И даже слонопасов на курсе молодого *(нужный язык подставить) всетаки обучают основам того как этот код будет обрабатываться на реальной железяке.

Но пока жив батька Линус говнокодерство

Когда программист древности писал программу,

Ваши тексты больше похожи на Былинно-Фентезийный эпос чем на рассуждение о языках программирования.

я не думаю о низкоуровневом программировании это ниже моей мегаквалификации

1. Вы прециплись к опечатке.
2. Вы дописываете удобные вам домыслы.

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

Туда же можно приписать всех потомков Lisp (включая JS), а так же Haskell.

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

Так и ссылки тоже есть и другие умные указатели, и семантика копирования есть, и гораздо удобнее когда семантика перемещения by design, а не как в плюсах, по этой семантике вообще-то реальный мир работает

А когда говоришь, что нельзя (ЭЛЕМЕНТАРНО!) передать один объект в две функции,

почему нельзя, да кто ж тебе мешает?

тебе говорят «тут надо над архитектурой думать» = изобретать костыли.

ну так надо же, сколько можно говнокод c глобалками плодить

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

а чё с регистрами случилось? или тоже «нельзя» как и выше?

которая не вяжется с ЖЕЛЕЗОМ

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

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

Вот только при переписывании утилиток почему-то стабильно обгоняет сишечку по всем параметрам

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