Panic! At the 0xC0D3

Panic! At the 0xC0D3

А поделиться я ей решил, потому что ее суть напомнила мне об одной мысли из какого-то древнего доклада, который я не могу откопать теперь( Если верить моей памяти, то суть его была в том, что чуваку досталась какая-то легаси кодовая база с кучей багосов, и…

По началу это может показаться странным. "Да никто так не делает", "это какой-то оверинжиниринг". Но по факту - это тот же uint, но ufloat, а первый используют повсеместно, чем этот тип хуже?
И на самом деле, нет, это используют, но больше в функциональных языках: вспомнить NonEmptyList из статьи из хаскеля.
"Но мой набор легаси библиотек не умеет с этим работать!" - возможно. Но это не мешает писать новые библиотеки в таком стиле.
И тут как раз хочется вернуться к Rust: в стандартной библиотеке с давних времен есть "стандартные" решения подобных проблем: Option; Result; Box (unique_ptr), который не может быть null - ровно по этой причине. И из-за того, что это было все (долгое?) время с языком, все библиотеки активно это используют

Есть ли перформанс оверхед от этого? It depends
Например, в случае uf32, вы наоборот можете выиграть в перформансе, не проверяя на отрицательные числа в каждой функции.
"Но я могу просто не проверять, и перенести это на плечи разработчика": да, но либо вам итак нужно будет проверять это (если это ввод от пользователя), и тогда разницы нет, будете вы проверять это в конструкторе, или внутри обработчика; либо вы на 100% уверены, что все ок, и тогда можно воспользоваться unsafe (который буквально показывает, что это небезопасно)
В случае NonEmptyList (NonEmptyVec) перформанс действительно может(!) быть хуже, потому что последовательная память, кеши и все такое.
Но это довольно простые примеры.
В реальности, зачастую это намного более сложные типы, которые показывают какие-то сложные инварианты. Самый банальный пример: парсить json в структуру, и использовать ее везде, вместо использования абстрактного json::Value, который бы пришлось валидировать в каждом месте (да да я смотрю на тебя python)

Но в итоге, использовать библиотеки, написанные в type driver design намного намного приятнее и проще. Одни флешбеки с numpy функций после курса МО, в которых нужно заглянуть в документацию, чтобы увидеть value: int/float/array/list/object/ndarray, передать туда какой-нибудь pandas.Series и получить ошибкой в рантайме спустя 10 минут вычислений, потому что "а этого нет в списке извините", заставляют вздрогнуть.
Вместо этого вам часто даже не нужна документация! Вы пишете foo(bar), и либо оно скомпилировалось и скорее всего работает, либо нет. Помните слова "компилируется - значит работает" про Rust, да? :)

P. S. хотел кратко написать мысли по статье, проиграл
P. P. S. статью то все равно прочитайте!

👍5

www.tgoop.com/paniccode/19

515 viewsLev, edited  Feb 6, 2023 at 21:40

По началу это может показаться странным. "Да никто так не делает", "это какой-то оверинжиниринг". Но по факту - это тот же uint, но ufloat, а первый используют повсеместно, чем этот тип хуже?
И на самом деле, нет, это используют, но больше в функциональных языках: вспомнить NonEmptyList из статьи из хаскеля.
"Но мой набор легаси библиотек не умеет с этим работать!" - возможно. Но это не мешает писать новые библиотеки в таком стиле.
И тут как раз хочется вернуться к Rust: в стандартной библиотеке с давних времен есть "стандартные" решения подобных проблем: Option; Result; Box (unique_ptr), который не может быть null - ровно по этой причине. И из-за того, что это было все (долгое?) время с языком, все библиотеки активно это используют

Есть ли перформанс оверхед от этого? It depends
Например, в случае uf32, вы наоборот можете выиграть в перформансе, не проверяя на отрицательные числа в каждой функции.
"Но я могу просто не проверять, и перенести это на плечи разработчика": да, но либо вам итак нужно будет проверять это (если это ввод от пользователя), и тогда разницы нет, будете вы проверять это в конструкторе, или внутри обработчика; либо вы на 100% уверены, что все ок, и тогда можно воспользоваться unsafe (который буквально показывает, что это небезопасно)
В случае NonEmptyList (NonEmptyVec) перформанс действительно может(!) быть хуже, потому что последовательная память, кеши и все такое.
Но это довольно простые примеры.
В реальности, зачастую это намного более сложные типы, которые показывают какие-то сложные инварианты. Самый банальный пример: парсить json в структуру, и использовать ее везде, вместо использования абстрактного json::Value, который бы пришлось валидировать в каждом месте (да да я смотрю на тебя python)

Но в итоге, использовать библиотеки, написанные в type driver design намного намного приятнее и проще. Одни флешбеки с numpy функций после курса МО, в которых нужно заглянуть в документацию, чтобы увидеть value: int/float/array/list/object/ndarray, передать туда какой-нибудь pandas.Series и получить ошибкой в рантайме спустя 10 минут вычислений, потому что "а этого нет в списке извините", заставляют вздрогнуть.
Вместо этого вам часто даже не нужна документация! Вы пишете foo(bar), и либо оно скомпилировалось и скорее всего работает, либо нет. Помните слова "компилируется - значит работает" про Rust, да? :)

P. S. хотел кратко написать мысли по статье, проиграл
P. P. S. статью то все равно прочитайте!

BY Panic! At the 0xC0D3