Вышел Rust 1.23

Но это же серебряная пуля от всех ошибок работы с памятью

Серьезно?

Правда, тут нужно вставить куда-то слово «непреднамеренных»

Начинаешь понимать.

В LLVM защиту завезли, когда-нибудь и в ветку LLVM, которой Rust пользуется, бэкпортируют.

Точнее половину защиты.

С индукцией у меня больших проблем нет.

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

Чем он лучше чистого Си?

Если чо, то сахара и ООП в системном программировании не нужны.

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

Опять?

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180101/513630.html

Защита от загрязнения кэша предсказателя переходов.

хотел вот это дописать:

meltdown - аппаратный баг, т.е. процессор не очень-то и спрашивает какой код ему выполнять спекулятивно а какой - нет. Исключения - fences и зависимости по данным. Может, ещё что есть из подобного. Но это не фиксит проблему без драматичной деградации перформанса и никак не защищает от зловредно написанного кода.

а ссылку почитаю - интересно. спасибо.

Если чо, то сахара и ООП в системном программировании не нужны.

Нужны, не нужны... они используются.

Да, там защита от половины Spectre. Перепутал.

нет исключений

А ещё там нет наследования, сборки мусора и динамической типизации. Убожество
upd. ещё конструкторов нет

1) тем, что там типы нормальной разрядности есть, а не int, который херпойми какого формата (1-completet, 2-complement, sign bit на выбор) и разрядности.

2) наличием юникода и строк, а не херпойми чего в «базовой кодировке» то ли времени компиляции то ли времени выполнения

3) отсутствием кода, который херпойми как работает и когда не работает при наличии 1 и 2 в меню.

это из самого важного.

забыл ещё этот эпик: 4) отсутствием undefined behaviour на арифметических и поразрядных операциях над целочисленными операндами.

Нужна утилита которая возьмёт бинарь после всех llvm оптимизаций, найдет все места откуда может сработать паника и выдаст список файлов и строк используя debug инфу.

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

Неоднозначная вещь.

1) Я всегда против int. Но плюсом раста это не назвать - в сях есть uint8_t, int16_t, int32_t и прочие в <types.h>

Нет, нельзя, потому что ты сам не знаешь есть у тебя паника тут или нет.

Формат внутреннего представления эти uint8_t всё так же зависит от реализации + пункт 4) + реализация не обязана предоставлять эти типы (и тогда будет ошибка компиляции). В общем - если что-то и держится, то на честном благородном слове, соплях и синей изоленте.

Но можно писать под одну платформу и не думать обо всех этих проблемах. Что подавляющее большинство и делает (осознанно или по простоте душевной)

реализация не обязана предоставлять эти типы

в C99 и C11 присутствие (u)int{8,16,32,64,max,ptr}_t обязательно

который херпойми какого формата

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

Нет, нельзя, потому что ты сам не знаешь есть у тебя паника тут или нет.

Почему мы можем знать, что тут у нас unsafe код, но не можем знать, может ли здесь быть выброшена паника?

Радость то какая!

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

Херню несёшь. Все функции, могущие вызывать панику, известны на этапе компиляции.

что ты сам не знаешь есть у тебя паника тут или нет.

Ты знаешь, что автор кода считает ее возможной. Этого достаточно.

И что это даёт? Давай посмотрим на более тут всем знакомую Java. Error и его наследник OutOfMemoryError - это аналог паники. Мы можем сказать, что все места, где происходит попытка алоцировать память, могут вызвать OutOfMemoryError. Но большой пользы от этого знания нет, потому что обязательный перехват OutOfMemoryError превратит жизнь программиста в ад.

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

Error и его наследник OutOfMemoryError - это аналог паники

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

Примерно как «rustc теперь учитывает подтипы при проверке согласованности типов у левого операнда бинарных операций.»

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

Это уже подробности реализации. Java бежит на виртуальной машине и поэтому может перехватить что угодно, кроме краха самой виртуальной машины (аналог проблем с железом).

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

1) кто тебе сказал что формата машины?
2) ты знаешь на какой машине твой код будет выполняться?

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

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

int8_t int16_t int32_t int64_t, signed integer type with width of exactly 8, 16, 32 and 64 bits respectively with no padding bits and using 2's complement for negative values (provided only if the implementation directly supports the type).

ну или парируй цитатой из стандарта C. Я не вижу где оно обязательно. Да и это самая мелкая из глобальных проблем этого «кроссплатформенного ассемблера»

сигнатура функции, в которой это происходит должна отражать возможность возврата ошибки.

Это выглядит аналогом checked exceptions в Java, которыми обязывают помечать бросающие их методы - ключевым словом throws и списком всех возможных, в этих методах, checked exceptions. Но в Rust, на сколько я понимаю, ошибка в Result может быть лишь одного типа, тоесть это аналог throws лишь с одном исключением?

А паника - это, видимо, аналог unchecked exceptions в Java?

Error и его наследник OutOfMemoryError - это аналог паники

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

Это уже подробности реализации. Java бежит на виртуальной машине и поэтому может перехватить что угодно, кроме краха самой виртуальной машины (аналог проблем с железом).

Ты сам-то понял, зачем это сказал?

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

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

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

в Rust, на сколько я понимаю, ошибка в Result может быть лишь одного типа

Это, конечно, не так.

Как хорошо, что в федоре Rust использует системный LLVM!

аналог

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

Ты сам-то понял, зачем это сказал?

А ты понял что я сказал?

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

Что за чушь? Любой вызов функции, кроме разве что inline функции, как минимум алоцирует память на стеке.

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

Если ты говоришь о памяти в куче, то объясни практический смысл этого твоего желания?

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

В каком месты ты увидел одержимость? Это всего лишь пример.

Это, конечно, не так.

А как? Вот определение Result:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

Как ты можешь засунуть более одного типа в E?

E может тоже быть enum

Если ты говоришь о памяти в куче, то объясни практический смысл этого твоего желания?

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

Что за чушь? Любой вызов функции, кроме разве что inline функции, как минимум алоцирует память на стеке.

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

E может тоже быть enum

Хм... Получается какое-то ветвящееся определение error. Я правильно понял?

смысл в том, что выделение памяти в куче - операция медленная
стек быстрый

Обсуждение шло не о скорости, а о панике.

термин аллокация - это про кучу, не про стек

С чего ты взял, что только про кучу?
https://en.wikipedia.org/wiki/Stack-based_memory_allocation
То, что ты говоришь относится к динамической аллокации. Вот динамическая аллокация действительно только в куче. Но память может закончиться и в куче и в стеке.

Хм... Получается какое-то ветвящееся определение error. Я правильно понял?

хз. в примере выше тип ToolchainError - как раз enum, посмотри еще раз. там два типа ошибки внутри. а failure'овский Error, походу, объединяет в себе все типы ошибок, реализующие соответствующий трейт.

Обсуждение шло не о скорости, а о панике.

если куча кончается - это нехватка ОЗУ. если стек кончается - это ошибка проектирования

в примере выше тип ToolchainError - как раз enum, посмотри еще раз. там два типа ошибки внутри.

Да я понял тебя и по предыдущему сообщению. По моему этот механизм затрудняет пробрасывание ошибок наверх. Например в Java я могу просто добавить ещё одно исключение в список throws. А тут придётся расширять этот enum? А если для разных функций моего impl у меня разные списки ошибок, то для каждой из них придётся городить отдельный enum?

а failure'овский Error, походу, объединяет в себе все типы ошибок, реализующие соответствующий трейт

Тоесть он решает описаное выше неудобство?

если куча кончается - это нехватка ОЗУ. если стек кончается - это ошибка проектирования

Куча может кончиться и из-за ошибки проектирования. Банальная утечка памяти, например.

а раст, он как будто для старпёров-учителей программирования

Очень смешной бред, спасибо.

А в чём суть возражения? Не было пожилого учителя программирования, который говорил, что нужно спроектировать сверху донизу перед тем как начать реализацию? Или в Расте неожиданно появились GC, исключения и возможность протащить через стек вызовов дополнительные данные, если не тупо добавив их в существующий объект, как позволяет js, то хотя бы через потомка одного из параметров и dynamic cast вглубине? Свидетели хипстоты как-то забывают, что хипстеры любят динамическую типизацию и ООП, а раст позволяет меньше вольностей чем даже чистый C.

Хипстер хипстоту не видит издалека.
Вот тебе и не видно.

Тоесть он решает описаное выше неудобство?

да. не без своих недостатков, правда.

Куча может кончиться и из-за ошибки проектирования

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

Ааа, нашёл флаг -C prefer-dynamic в документации. Не знал, что такое есть.

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

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

странно, но с ним Лиса-57 не собирается

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

А в Rust есть деструкторы? Я ещё только знакомлюсь с этим языком, но вроде не встречал никаких деструкторов. Вот в Java их точно нет. Общее свойство языков с автоматическим управлением памяти?

Есть типаж (трейт) Drop https://doc.rust-lang.org/nightly/std/ops/trait.Drop.html

Если тип реализует этот трейт, то Drop::drop(&mut self) вызывается при выходе значения из области видимости.