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

Одно дело заблуждаться, другое дело — воинственно заблуждаться :-)

Какое пропихивание, такое и заблуждение :-)

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

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

Давай я объясню попроще.

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

Просто я UNIX да и Linux потом, всегда ассоциировал с си, в конце концов есть с++, стандарты и т.д. развивайте его в чем вопрос ?

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

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

Блин, я для кого метафору про говно сочинял?

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

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

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

Этот файл это обёртка вокруг openssl

Если это действительно так, предлагаю устроить над эм-икс суд чести.

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

И самое главное - это не придурь отдельного программиста ради какого-то супер-экзотического случая, а вполне стандартная практика, и даже термин есть - type erasure. И эта практика зафиксирована в той же стандартной либе (см. функцию qsort).

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

Никогда, слышите, никогда не извиняйтесь перед адептом Rust’а! Ему от извинений еретика не холодно и не жарко, а все нормальные люди себя чувствуют оплеванными, прочитав такое…

Я только первую страницу с комментариями осилил, большую часть не понял, но приложу винни_пух_из_лужи.jpeg…

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

Хелло ворлд на Расте под 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 достаточно легко. Оверхед очевиден с погрешностью до оптимизатора компилятора.

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

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

Я не знаю что надо такого написать, чтобы это не заметил cppcheck, gcc -fsanitize=undefined,address и valgrind.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цитируй.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Да.

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

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

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

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

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

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

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

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

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

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

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

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

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 строки

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

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

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

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

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

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

Вот есть компания А. У нее многомиллиардные обороты, но и платить ей приходится огромные налоги. В каком-то штате вводятся налоговые плослабления для определенного типа компаний, руководство решает переезжать. Компанию перегистрировать, «перевезти» сложно, власти штата, где ее штаб-квартира такое явно не одобрят, а генеральный прокурор штата всегда найдет повод завести какое дело… Выход: создать компанию Б и передать ей разработку «продукта». Формально это разные компание и поэтому наработки нельзя передать просто так, их можно продать за какую-то символическую сумму типа 1$, но антимонопольные службы сразу заподозрят уход от налогов, они проведут аудит, высчитают реальную стоимость «продукта», высчитают сумму неплаченных налогов, а потом ее умножат на 10, ведь сумма штрафа всегда на порядки будет больше чем ущерб… И вот тут на помощь приходит опенсорц. Объявляем продукт общественным достоянием, и теперь компания Б может его дальше разрабатывать… Ага, существованию опенсорца мы обязаны лишь англо-саксонской правовой системе… И этот пример еще объясняет почему в РФ или постсовке нигде это дело не приживется никогда (отсутствие антимонопольной борьбы как таковой + слово удалено по требованию роскомнадзора у нас скрепа, а борьба с ней - экстремизм). Никакой конспирологии нет. Есть только сурьезный бизнес, полностью подчиненный закону, а не хотелкам некогда пацанов в малиновых пиджаках

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

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

Код у nginx нельзя назвать верхом лаконичности, но производительность его весьма неплоха. Так что не надо грязи, пожалуйста.

А вот поделка на Rust, вдруг оказавшаяся на 70% эффективней кода, отточенного с точки зрения производительности годами, не вызывает ничего кроме сожаления как минимум в отношении их PR менеджеров.

Ну я не хотел грязи, просто вспомнилось почему то, и вроде народ жаловался на простыни PUSH и POP в нем. Очень давно, смутно помню.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Хм.

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

Пока в 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 — нет. Иначе сходство для тебя было бы очевидным.