LINUX.ORG.RU

Ответ на: комментарий от upcFrost

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

Harald ★★★★★
() автор топика
Ответ на: комментарий от Zhbert

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

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от upcFrost

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от Manhunt

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

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

no-such-file ★★★★★
()
Ответ на: комментарий от ox55ff

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

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

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

$ 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.

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

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

Manhunt ★★★★★
()

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

pechorin
()
Ответ на: комментарий от Archer73

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

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

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

fsb4000 ★★★★★
()
Ответ на: комментарий от Archer73

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от Archer73

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

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

fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от Zhbert

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

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

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

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 1)
Ответ на: комментарий от Archer73

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

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

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от BattleCoder

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

MOPKOBKA ★★★★
()
Ответ на: комментарий от fsb4000

«Fearless Concurrency» :)

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

Manhunt ★★★★★
()
Ответ на: комментарий от fsb4000

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

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

cvs-255 ★★★★★
()

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

grem ★★★★★
()
Ответ на: комментарий от cvs-255

Говорят всё работает в 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);
    }
}
fsb4000 ★★★★★
()
Последнее исправление: fsb4000 (всего исправлений: 1)
Ответ на: комментарий от Manhunt

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

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

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

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

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

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от Manhunt

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

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

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

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

alysnix ★★★
()
Ответ на: комментарий от Manhunt

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

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

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

cvs-255 ★★★★★
()
Последнее исправление: cvs-255 (всего исправлений: 2)
Ответ на: комментарий от cvs-255

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

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

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

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

alysnix ★★★
()
Ответ на: комментарий от cvs-255
Их изобрели чтобы программисты могли сконцентрироваться на задаче, а не следить за malloc-free

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

xperious ★★
()
Ответ на: комментарий от xperious

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

cvs-255 ★★★★★
()
Ответ на: комментарий от xperious

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

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

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

Manhunt ★★★★★
()
Ответ на: комментарий от alysnix

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

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

Manhunt ★★★★★
()
Последнее исправление: Manhunt (всего исправлений: 2)
Ответ на: комментарий от alysnix

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

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

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

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 2)
Ответ на: комментарий от Manhunt

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

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

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

alysnix ★★★
()
Ответ на: комментарий от Harald

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

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

umren ★★★★★
()
Последнее исправление: umren (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.