публично извиниться, в адрес Страуструпа, записать на видео!

Понравились эмодзи в коментах. А в имена переменных можно вставлять?

нужно!

В чем вообще фишка этого вашего раста?

Раст избавляет от типовых (для Си и C++) ошибок в работе с памятью, и при этом сравним с Си и C++ по скорости работы.

Ошибки при работе с памятью - это мажорный источник уязвимостей в современном ПО. Крупным компаниям уязвимости сильно мешают жить, и этим объясняется их заинтересованность во внедрении rust.

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

Ага, лайфтаймы подняли планку вырвиглазия на новый уровень

Крупным компаниям уязвимости сильно мешают жить

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

Вместо тысячи слов

Понравились эмодзи в коментах. А в имена переменных можно вставлять?

Добро пожаловать в новый дивный мир

$ cat c.c
int main()
{
   int успех🚀сишечки = 0;
   return успех🚀сишечки;
}

$ gcc c.c 

$ echo $?
0

$ gcc --version
gcc (SUSE Linux) 11.2.1 20210816 [revision 056e324ce46a7924b5cf10f61010cf9dd2ca10e9]
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

А ошибки гонки данных и состояния гонки они тоже победили?

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

Дадада, и так начхать, что тот же m$ дрочится со своим Security Development Lifecycle.

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

А ошибки гонки данных и состояния гонки они тоже победили?

Да. В rust запрещено иметь мутабельную ссылку в разных потоках.

Только через специальный тип Mutex

А ошибки гонки данных и состояния гонки они тоже победили?

В некоторой степени. Подробнее этот вопрос освещен в документации по rust, но готовой ссылки у меня под рукой нет, так что процитировать не могу.

Manhunt

Вот ссылка.

«Fearless Concurrency» :)

https://doc.rust-lang.org/book/ch16-00-concurrency.html

И если поток захвативший мьютекс упал (был убит), то все само разрулиться?

И если поток захвативший мьютекс упал (был убит), то все само разрулиться?

как упал? Если у тебя система упала, то тут раст не поможет. А так раст следит за временем жизни всего, так что да, всё само разрулится…

Lifecycle

Вот именно.

строгий компилятор, memory-safe без gc ?

карго, как часть стандартной поставки

вроде все, как видишь этого достаточно чтоб взлетело, конкурентов то нет

И если поток захвативший мьютекс упал (был убит), то все само разрулиться?

Если поток завершается вследствие «паники», то захваченные этим потоком мьютексы будут помечены как «отравленные» (poisoning). Потоки, которые в дальнейшем попробуют захватить «отравленный» мьютекс, либо получат ошибку вместо захвата мьютекса, либо у них случится «паника».

https://doc.rust-lang.org/nomicon/poisoning.html

Для этого у Java есть рефлексия и кодогенераторы.

Ну т.е. через очередной баг юникода можно хакнуть godbolt.org?

«Fearless Concurrency» :)

Угу, кавычки и смайлик тут более, чем уместны. Deadlock на rust делается легко и непринуждённо.

Да. В rust запрещено иметь мутабельную ссылку в разных потоках.

А что там в случае если ты пишешь код для микроконтроллера, и никаких «нормальных» потоков нет, а есть прерывания?

Куда в этом году из набора готовых пакетов делать Eclipse IDE для Rust?

Говорят всё работает в safe rust:

Вот hello world для Cortex-M

https://docs.rust-embedded.org/book/intro/index.html

#![deny(unsafe_code)]
#![no_main]
#![no_std]

use panic_halt as _;

use core::fmt::Write;

use cortex_m::peripheral::syst::SystClkSource;
use cortex_m_rt::{entry, exception};
use cortex_m_semihosting::{
    debug,
    hio::{self, HStdout},
};

#[entry]
fn main() -> ! {
    let p = cortex_m::Peripherals::take().unwrap();
    let mut syst = p.SYST;

    // configures the system timer to trigger a SysTick exception every second
    syst.set_clock_source(SystClkSource::Core);
    // this is configured for the LM3S6965 which has a default CPU clock of 12 MHz
    syst.set_reload(12_000_000);
    syst.clear_current();
    syst.enable_counter();
    syst.enable_interrupt();

    loop {}
}

#[exception]
fn SysTick() {
    static mut COUNT: u32 = 0;
    static mut STDOUT: Option<HStdout> = None;

    *COUNT += 1;

    // Lazy initialization
    if STDOUT.is_none() {
        *STDOUT = hio::hstdout().ok();
    }

    if let Some(hstdout) = STDOUT.as_mut() {
        write!(hstdout, "{}", *COUNT).ok();
    }

    // IMPORTANT omit this `if` block if running on real hardware or your
    // debugger will end in an inconsistent state
    if *COUNT == 9 {
        // This will terminate the QEMU process
        debug::exit(debug::EXIT_SUCCESS);
    }
}

фу какое вырвиглазие

Ошибки при работе с памятью - это мажорный источник уязвимостей в современном ПО. Крупным компаниям уязвимости сильно мешают жить, и этим объясняется их заинтересованность во внедрении rust.

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

нет никакого смысла ради этого изобретать целый язык.

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

Важно, что среди де-факто выявляемых уязвимостей, примерно 70% приходится на ошибки работы с памятью. Пруф: https://www.chromium.org/Home/chromium-security/memory-safety

при правильной культуре разработки они минимальны, а то их и нет вообще.

Чем докажешь?

нет никакого смысла ради этого изобретать целый язык.

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

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

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

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

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

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

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

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

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

Их изобрели чтобы программисты могли сконцентрироваться на задаче, а не следить за malloc-free

Их изобрели чтобы программисты могли сконцентрироваться на задаче, а не следить за malloc-free

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

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

но мы то говорим не о ней. а о русте.

Их изобрели чтобы программисты могли сконцентрироваться на задаче, а не следить за malloc-free

вообще если предметная область сложная и нетривиальная, проблемы с malloc/free эт вообще мелочь. ну или valgrind сложно освоить чтоли

если предметная область сложная, то malloc/free еще усложняет

Потому что это единственное, что волнует сишников

ну или valgrind сложно освоить чтоли

Если бы ты его освоил, то знал бы, что никаких гарантий насчет корректности работы с памятью он не даёт. Если valgrind ничего не нашел, это не значит, что в твоей программе не осталось ошибок работы с памятью.

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

Так значит, по твоему мнению, правильные программисты ничего никогда не путают и не забывают, и вообще пишут код без багов? :D

потому такое количество путаницы с указателями, при мизерном количестве остальных путаниц с порядком, статистически невероятно…

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

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

Жаль такой культуры нет и судя по всему она невозможна.

Значит нужен новый язык.

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

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

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

раз нету и невозможна, то и новый язык не поможет

Корпорации говорят, что помогает.

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