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

Да, разумеется.

Google rate for Pukhsia

Кого вообще колышит с чем там гугл извращается.

Не будет счастья. Потому что в любом случае при использовании арифметических команд разных процессоров может быть разное поведение при переполнении.

Не поделитесь какими-то необычными поведениями у некоторых процессоров?

Так то защиты уже есть все, и проверки тоже, в С, для этого не нужен Rust.

Раст не только этим хорошо, у него ещё человеческие тулзы для разработки и возможно писать generic структуры данных БЕЗ ЧЕРТОВЫХ МАКРОСОВ КОТОРЫЕ РАЗВОРАЧИВАЮТСЯ В ДРУГИЕ МАКРОСЫ О ДА ДЕТКА ДАВАЙ-КА ОБМАЖЕМСЯ ЕЩЁ МАКРОСАМИ. И строки нормальные. И async есть хороший. Я люблю libev, но Rust лучше.

Компилируешь с -fsanitize=bounds и всё, все индексы у массивов проверяются.

У выделенных на стеке. Если ты используешь их в той же функции.

Компилируешь с -fstack-protector и во все функции вводятся проверки, что стек не переполнится.

Нет, не все.

и почти единственный который имеет множество реализаций?

а торвальдс где-то утверждал что Linux _должен_ следовать стандарту и указал версию этого стандарта?

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

Назови уже хоть какую-нибудь.

из трёх нижеперечисленных пунктов ты можешь одновременно выбрать не более чем два:

• кроссплатформенность
• производительность
• отсутствие UB

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

• x64 (инструкция cvttsd2si): если исходное значение double выходит на границы целого типа, то возвращается значение 0x8000000000000000
• arm64 (инструкции fcvtzs, fcvtzu): если исходное значение double выходит на границы целого типа, то возвращается крайнее (мин/макс) значение из допустимого диапазона, наиболее близкое к исходному

поэтому когда ты пытаешься сконвертировать одной инструкцией процессора число -1.0 в тип uint64, то на x64 ты получишь 0x8000000000000000, а на arm64 - 0
если потребовать одновременно кроссплатформенность (на разных процессорах результат операции должен быть одним и тем же числом) и отсутствие UB (результат операции должен быть чётко определён и описан в документации), то придётся платить потерей производительности - на какой-то из архитектур операцию придётся реализовывать не одной инструкцией процессора, а несколькими

автор LuaJIT, когда писал расширение Lua 5.1 с 64-битными целыми числами, посмотрел на это безобразие и сказал: «от кроссплатформенности уйти не получится, производительностью жертвовать не хочу, поэтому вот вам UB, ну а чо, раз сишники терпят наличие UB в своём языке, то и вы терпите»

такова жизнь: написание компиляторов - это постоянный поиск компромиссов между несовместимыми целями, и перфекционистам здесь делать нечего

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

там, где сишники получают remote code execution, раст просто расплачивается производительностью

Починил.

Просто вся эта возьня с микрооптимизациями не стоит того вреда, что приносят свободная адресация и UB. Если у тебя есть проблема с производительностью во время конвертации из double в int64, то ответ как бы простой – не конвертируй так часто, йопт.

Кстати да..

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

вся эта возьня с микрооптимизациями

ты не понял. UB - это не возня, а наоборот, избавление от возни с документированием ЯП и от усложнения реализации языка.
UB - это простой и эффективный способ быть ближе к железу.

Если у тебя есть проблема с производительностью во время конвертации из double в int64

производительность - это бог, которому молятся до сих пор
и вряд ли когда-нибудь перестанут молиться

если тебя производительность не волнует - то не отвлекайся на дискуссии про низкоуровневые языки, а продолжай душить питона ))) или на чём ты там пишешь?

питон\жабоскрипт

И обосраться, потому что динамика.

Да, производительность и кроссплатформенность,взаимоисключающие понятия. Нельзя использовать приемущества той или иной платформы при кроссплатформенности ПО, отсюда и производительность софта страдает. Причем это касается не только ПО, но и ОС (базовой).

БЕЗ ЧЕРТОВЫХ МАКРОСОВ

Rust? Без макросов? Куда они делись?

И строки нормальные.

Какие из двух? Как насчёт получение символа по номеру позиции или среза? Нормальные, говоришь?

яп, позиционирующийся как системный

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

ты не понял. UB - это не возня, а наоборот, избавление от возни с документированием ЯП и от усложнения реализации языка.

Почему в Rust смогли не делать UB и не усложнять язык?

UB - это простой и эффективный способ получить remote code execution.

Починил.

производительность - это бог, которому молятся до сих пор и вряд ли когда-нибудь перестанут молиться

Ну разницы в бенчмарках между Rust и C ничтожна. И часто в пользу Rust.

если тебя производительность не волнует - то не отвлекайся на дискуссии про низкоуровневые языки, а продолжай душить питона ))) или на чём ты там пишешь?

Сейчас я снова пишу в ядре на C по работе. Но в userspace на C я писать больше не буду, потому что Rust эквивалетно быстр, но при этом шанс обосраться на пустом месте сильно меньше.

Rust? Без макросов? Куда они делись?

Во-первых, макросы в Rust != макросы в C. Во-вторых, generic’и в расте заменяют типичное использование макросов в C (посмотри в queue.h чтобы понять, о чем я говорю).

Например,

Modula2/2+/3 позиционируются именно как системные яп.

Если у тебя есть проблема с производительностью во время конвертации из double в int64, то ответ как бы простой – не конвертируй так часто, йопт.

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

А со строками что?

а если компилятор сообщает еще какую-то дополнительную инфу, то девелопер должен отвесить разрабам

Пару лещей.

Почему в Rust смогли не делать UB

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

и не усложнять язык?

ну, это уже перебор.

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

Но почему-то постоянно наступают, лол.

Но почему-то постоянно наступают

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

Не единственный. У C# и Ada тоже несколько реализаций.

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

Наверное потому, что никому не нужен perl на avr.

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

Ты с Фортраном путаешь.

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

Внезапно нет.

Null-terminated строки без явной проверки границ, на которых налажать еще проще, чем на стековых массивах, потому что стек протектор и канарейки у конца массивов тебя не спасут.

ты не понял. UB - это не возня, а наоборот, избавление от возни с документированием ЯП и от усложнения реализации языка.

Забавно, что ты упомянул сложность реализации языка. Потому что кодовая база clang как минимум не проигрывает по размеру кода rustc. Было бы интересно выделить только C из clang, но мне кажется, там всё равно дофига выйдет.

я просил ссылку на то, где C позиционируется как системный яп

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

В расте нормальные utf8 строки, лол.

А где я говорил про Си?

Твой «нормальный лол» индексацию и срезы нормально не умеет. Они их даже нормально сделать не смогли.

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

вот это о чем было?

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

Внезапно нет.

например?

Наверное потому, что никому не нужен perl на avr.

зелен виноград (с)

И индексация, и срезы есть.

Хороший аргумент.

индексация … есть.

fn main() {
    let s1 = String::from("hello");
    let h = s1[0];
    println!("{}", h);
}

Это уже работает?

let dog = "忠犬ハチ公";
let hachi = &dog[0..2];

Не так выразился. Но суть в том, что если яп позиционируется как для системного программирования так и общего назначения получаются какие-то качели с компромиссами. Поэтому, я и привел пример с семейством языков Modula. И мне вот совсем непонятно, почему не используют Modula3 в системном программировании и в создании ОС, ведь он был создан специально для этого. Почему используют языки общего назначения для этой цели. В чем смысл таких костылей по сути?

Хороший аргумент.

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

была бы возможность - втащили бы. но нет. интересно почему. версии есть? ну, кроме конспирологических.

Эм… Но есть Rust. Гн удовлетворяет всему сказанному. И он нужен очень много кому.

Мне вот это понравилось

You should use ranges to create string slices with caution, because doing so can crash your program.

Почему-то в медленном питоне подобных проблем нет.

Ну тот же Rust. Работает везде где есть таргет в llvm.

Что такое «системное программирование» в данном контексте?

Базовая ОС в контексте ядро, микроядро + обвязка, драйвера, базовые утилиты.

Да:

let dog = "忠犬ハチ公";
let i = dog.char_indices().nth(2).unwrap().0; // Since we are dealing with UTF-8 check for errors
let hachi = &dog[0..i];