#meme

r/rustjerk: не в бровь, а в глаз

#prog #rust #rustlib
https://crates.io/crates/scopeguard — и defer из Go ненужен

Ну, строго говоря, поведение всё же отличается: код в defer в Go вызывается при выходе из функции, а в этой библиотеке в конце области видимости. Но я бы сказал, что последнее более полезно

Не особо и интересный. Возможно, это я чего-то недопонял, но безопасность в основном строится на рантайм-проверках, отключаемых в релизных билдах. Ну и потом, в 2k20 году делать язык с null — крайне сомнительная идея.

#gamedev

Очередная грустная история о том, как слабый менеджмент убивает видеоигры.

"This account of Anthem’s development, based on interviews with 19 people who either worked on the game or adjacent to it (all of whom were granted anonymity because they were not authorized to talk about Anthem’s development), is a story of indecision and mismanagement. It’s a story of technical failings, as EA’s Frostbite engine continued to make life miserable for many of BioWare’s developers, and understaffed departments struggled to serve their team’s needs. It’s a story of two studios, one in Edmonton, Alberta, Canada and another in Austin, Texas, that grew resentful toward one another thanks to a tense, lopsided relationship. It’s a story of a video game that was in development for nearly seven years but didn’t enter production until the final 18 months, thanks to big narrative reboots, major design overhauls, and a leadership team said to be unable to provide a consistent vision and unwilling to listen to feedback."

https://kotaku.com/how-biowares-anthem-went-wrong-1833731964

Собственно, один из бывших сотрудников BioWare, работавших над игрой, основал консалтинговую компанию, помогающую бороться с переработками. К сожалению, эта компания, по всей видимости, больше не работает: последний пост в блоге был 3 года назад :(

(напоминаю, у блога есть чат @decltype_chat_ptr_t, где вы можете всё это обсудить)

#prog #haskell #cpp #article
Товарищ мёртвопищ опять вызывает бурления широких народных хабромасс.
Haskell быстрее C++!
Python медленнее PHP!
Одна и та же оптимизация приводит к противоположным результатам в GCC и Clang!

...Реализация на других языках программирования (включая Rust) тоже имеется, так что есть шанс сравнить производительность.
https://habr.com/ru/post/483864/

Когда-то я написал на Rust программу, которая переводила числа в строку прописью (т. е. 123 -> "сто двадцать три"). Написал и решил написать статью о том, как написать подобную программу.

Это было год назад.

Статья всё ещё не готова.

#prog
Идея не нова, но убедительную реализацию сделать сложно

художник @harryh___h экспериментирует с рендером, который выглядит так, будто листья нарисованы от руки. сделано в Unity

#prog #article
Отличная статья, показывающая новый способ тестирования, вскрывающий ошибки...
А заодно хорошо показывающая, насколько мы далеки от написания по-настоящему корректно работающего софта

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

The core idea of this approach is to automatically generate queries for which we ensure that they fetch a specific, randomly selected row, called the pivot row. If the DBMS fails to fetch the pivot row, the likely cause is a bug in the DBMS. We tested our approach on three widely-used and mature DBMS, namely SQLite, MySQL, and PostgreSQL. In total, we reported 123 bugs in these DBMS, 99 of which have been fixed or verified, demonstrating that the approach is highly effective and general.

https://arxiv.org/abs/2001.04174

#prog #rust #моё
В конце этой заметки я сказал, что планирую расширить код до поддержки impl BorrowMut<VecDeque<T>>. Теперь я понимаю, что это несколько неосмотрительно: код в unsafe полагается на то, что адрес, по которому лежат данные, не меняется. В случае impl BorrowMut такой гарантии уже нет. Для доказательства того, что подобный вариант является unsound, предположим, что MutPair уже реализовал подобный функционал (это изменение я, с вашего позволения, опущу, потому что это чисто механическое изменение кода) и рассмотрим следующий тип:

#[derive(Default)]
struct DeqWrapper<T> {
inner: VecDeque<T>,
}

Для него можно написать следующие реализации Borrow и BorrowMut:

impl<T> Borrow<VecDeque<T>> for DeqWrapper<T> {
fn borrow(&self) -> &VecDeque<T> {
&self.inner
}
}

impl<T> BorrowMut<VecDeque<T>> for DeqWrapper<T> {
fn borrow_mut(&mut self) -> &mut VecDeque<T> {
self.inner.clear();
&mut self.inner
}
}

Да, это отвратительно, да, так никто (я надеюсь) не пишет. Но принципиально нас ничего от этого не ограждает. Хочу отметить, что код выше не содержит unsafe.

Теперь попытаемся использовать данный тип:

let wrapper = DeqWrapper::<i32>::default();
wrapper.inner.push_back(0);
wrapper.inner.push_back(1);
let mut mut_pair = MutPair::new(wrapper).unwrap(); // (1)
let _ = mut_pair.get(); // (2)

Что тут происходит? В (1) мы делаем внутри MutPair::new проверку длины дека. Так как при этом мы используем .borrow(), DeqWrapper даёт ссылку на поле inner, длина которого как раз достаточна, поэтому MutPair возвращает Ok и .unwrap() не паникует. В (2) мы вызываем .borrow_mut(), из дека удаляется данные, MutPair::get использует get_mut, предполагая, что данные есть, и — вуаля! — мы получаем ссылку на неинициализированные данные! Что является UB в Rust.

Хочу особо отметить, что мы получили UB, не написав (как пользователь) unsafe-код и не вызвав unsafe-код напрямую, поэтому наш код unsound.

В чём же проблема? Наш код слепо доверял реализации BorrowMut, чего делать не стоит (unsafe не должен доверять safe).

Каковы решения? Лично я вижу такие:
1) Объявить методы MutPair как unsafe. В принципе, вариант, но это немного лишает смысла эту абстракцию.
2) Оставить код как есть. Вполне рабочий вариант, но не исключено, что для кого-то это окажется недостаточно гибким.
3) Обобщить код относительно sealed-трейта и включить в него только доверенные реализации (для VecDeque<T> и &mut VecDeque<T>). Тоже рабочий вариант (если я таки буду публиковать этот код на crates.io, то, вероятно, так и поступил бы), но это выглядит несколько избыточным решением + страдает эргономика: пользователю теперь надо импортировать нужный трейт, который он(а) не может реализовать.
99) Требовать от типов реализовать трейт, который не только даёт мутабельную ссылку на VecDeque, но и требует доказательство вменяемости такой реализации. К сожалению, этот вариант сильно превосходит текущие возможности Rust и навряд ли когда-то будет осуществлён.