Как с C# не знаю, но вот сравнение с Матлабом без использования специализированных матричных библиотек, вероятно, будет нечестным. Кроме того, в Расте умышленно используется достаточно маленькая стандартная библиотека, поэтому без использования внешних зависимостей вы далеко с ним не уйдёте. Благо подключение зависимостей и их использование в Расте это сущее удовольствие. Т.к. nalgebra (либо аналоги попроще) позволяет значительно сократить кол-во бойлерплейта, то называть данную зависимость лишней я бы не стал.
Про объявление структур советую внимательно подумать, их использование не только позволяет сокращать количество бойлерплейта как в моём примере, и тем самым сокращать вероятность ошибок (явные имена полей этому тоже способствуют), но и позволяет лучше и быстрее понимать код не только другим людям, но и вам после того как вы к нему вернётесь через какое-то время. Разумеется, тут нужно соблюдать меру, но лично мне разбираться в вашем коде было достаточно сложно.
Что меня забавляет в подобных "анализах", так это то, что никак не учитывается динамика стакана заявок, тем самым выкидывается почти вся информация об эластичности рынка. Для создания ауры наукообразности для домохозяек может и сойдёт, но никуда не годится для технического ресурса.
Фигасе "мелкие службы". Magic Pocket использующий Rust это по сути центральная компонента их хранилища. Конечно, его не полностью переписали с Go, но всё же. К сожалению, презентации где о переписывании рассказывалось более подробно более не доступны...
Потому что практика показывает, что проекты на Rust-е в целом получаются более надёжными чем на С/C++ (возьмите тот же блог-пост про http клиенты или про переписывание CSS движка лисы), что явно противоречит вашему утверждению об "отсутствии гарантий". Это не только заслуга языка, но и сложившейся экосистемы вокруг него, которые, на мой взгляд, не следует рассматривать в отрыве друг от друга.
Про libc я попытался использовать ad absurdum, дабы показать абсурдность вашего заявления про "если в стеке вызовов есть хоть 1 unsafe", ибо практика показывает, что можно строить более надёжные системы на формально менее надёжном фундаменте, но раз вы считаете это демагогией, продолжайте считать и далее. Дискутировать с вами далее у меня желания нет.
Ога, можно вспомнить ещё и об libc, который используется стандартной библиотекой Раста, и который, о ужас, написан на C. Подход "либо всё, либо ничего" на мой взгляд является весьма странным и непрактичным. Программирование это инженерная дисциплина в которой нужно выбирать между градациями множества переменных.
memory safety у Раста не сильно больше сейф, чем у C#, D, Java etc
Хех, учитывая что вы перечислили языки со сборщиком мусора, то здесь вы действительно правы (хотя имхо культура строгости и типобезопасности делает экосистему Раста в среднем более надёжной, чем в перечисленных языках, но это не свойство языка как такового). Если для ваших задач данных языков достаточно, то переходить на Раст вам действительно особой нужды нет.
Разумеется это не 100% защита, но большое количество проектов показывает, что гарантии Раста действительно серьёзно уменьшают количество memory safety багов по сравнению с C/C++ и серьёзные компании берут его на вооружение как раз из-за этого, а не из-за якобы пресловутого хайпа. Если из 70% ошибок компилятор позволяет предотвращать условные 95%, то на мой взгляд это является существенным достижением.
Я понимаю, что вы как фанат D, возможно и скептично относитесь к гарантиям Раста, но практика показывает несколько иные результаты.
Но признан багом и работы над его исправлением ведутся, хоть и медленно (вплоть до предложений полностью задеприкейтить as). В actix-е же большинство использований unsafe делалось без какого-либо анализа влияния на производительность и, если не ошибаюсь, во время первой уборки unsafe производительность не особо пострадала. Не говоря уже об отказе принимать патчи фиксящие эти баги.
Тогда соответствующие функции необходимо было помечать unsafe, тогда бы никто и слова не сказал. Но автор притворился что эти функции являются "безопасными" дабы сэкономить на написании unsafe блоков, тем самым нарушив контракт с пользователями библиотеки.
В issue-ях, насколько я помню, никто не говорил от имени всего сообщества, выражалось в первую очередь личное мнение. В этой дискуссии под "мнением сообщества" я подразумеваю обобщённую реакцию людей ратующих за важность исправления soundness багов, можно называть её "мнением части сообщества Rust", если вас это больше устроит.
Да, есть баги в библиотеках и компиляторе, которые нарушают эти гарантии. Но эти проблемы не замалчиваются и люди активно работают над их решением. Т.е. проблема не в том, что в actix'е были soundness баги, а в том, что автор не признавал их важность и отказывался работать над их исправлением.
Ответил выше. Этот свод правил относится только к очень малой доли кода и если эта доля написана верно (чего не было в случае actix'а), то для всего остального кода гарантии поддерживаются автоматически компилятором.
Гарантии даются языком при использовании безопасного подмножества языка. При использовании unsafe вы берёте сохранение гарантий на себя и должны обернуть этот код в безопасный интерфейс, который гарантирует инварианты языка.
Потому что unsafe это "необходимое зло" без которого не обойтись при написании низкоуровневых вещей и FFI. "Фишка" Раста в том, что если вы при написании unsafe код соблюли соответствующие требования, то это делает невозможным получение неопределённого поведения в коде который не использует unsafe.
Например, Vec активно использует unsafe под капотом, но как бы вы не использовали безопасное API вы не получите неопределённого поведения в скомпилированной программе из-за него. Таким образом, вместо того что бы следить за всем кодом как в C/C++, вам нужно следить и внимательно проверять только очень малую часть кода. Большая часть Раст проектов не использует напрямую unsafe вовсе и полагается на то, что зависимости ответственно подошли к использованию unsafe, поэтому нарушение этих гарантий и вызывает столь негативную реакцию.
Я же уже выше об этом написал… Да, никто никому не должен, в т.ч. и представители сообщества (многие из которых мейнтейнят свои open source проекты) не обязаны хорошо относиться к людям открыто плюющим на ценности поддерживаемые ими.
В каком-то смысле это является иммунной реакцией, что является необходимым элементом для здорового сообщества. Однако, конечно стоит внимательно следить дабы это не привело к аутоимунным эффектам.
Вы на Расте пишите? Как я понял нет. Проблема не в unsafe, проблема в том, что автор не желает понимать как его следует правильно использовать и по сути открывает широкую дверь для неопределённого поведения, тем самым подрывая те гарантии которые и являются киллер фичей Rust'а.
Представьте новости что сайт написанный на actix-е оказывается хакнут через уязвимость возникшую из-за неправильного использования unsafe, что привело к миллиардным убыткам. Это будет очень больным ударом по репутации языка позиционирующего себя как memory safe альтернативу C/C++.
Ну или более приземлённый пример, разработчик будет тратить своё время на отлавливание багов, которые должны были предотвращаться компилятором. Выше уже об этом уже написал человек пользовавшийся actix-ом.
Почитайте, например, вот этот блог-пост обсуждающий проблемы в actix-web для дополнительного контекста.
Так что это никакие не "розовые мечты", а вполне рациональные усилия по защите того что делает Rust ценным для разработчиков инвестирующих в его использование и развитие.
Потому что я сам ожидаю от Rust проектов соответствия центральным гарантиям языка и полагаюсь на это в своей работе. Без этих гарантий уж лучше использовать C/C++ для которых экосистема на данный момент значительно богаче. И хоть я лично и не участвовал в драме вокруг actix'а, для меня тот факт что мейнтейнер столь заметного проекта столь пофигистски относится к гарантиям языка стало чрезвычайно неприятным сюрпризом.
Вы всё время почему-то хотите найти виноватых. Я описываю альтернативную точку зрения, дабы те кто не знакомы с ситуацией могли лучше понять участвовавшие стороны.
Если бы автор написал "я устал, я ухожу" и передал бразды правления, то большинство бы отнеслось с пониманием. Но зачем было удалять репозитории в данной ситуации, кроме как для пущего драматического эффекта?
То есть у человека есть право, но пользоваться им он не имеет права?
Не перевирайте мои слова. Где я об этом писал?
Open source это общественное занятие. Вы с этим можете не соглашаться, но де-факто это так. Сообщество в данном контексте это группа людей разделяющие некоторые ценности и представления, в данном случае это люди ценящие гарантии Rust'а и ожидающие от проектов защиты этих гарантий и стремления к этому. И оно вполне себе существует. Автор выкладывал проект для использования сообществом. Поэтому когда выясняется что автор ни во что не ставит гарантии языка, то разумеется это вызывает негативную реакцию.
И не стоит заявлять что представители сообщества это сплошь лодыри, которые только и могут критиковать чужой труд. Нет, многие из его представителей активно работают над созданием экосистемы следующим ценностям сообщества, которой в т.ч. и пользуется actix. И активно участвуют в развитии чужих проектов.
Не хочешь в своём проекте соответствовать этим ценностям? Твоё право. Сразу позиционируй проект соответствующим образом, дабы у сообщества не было ложных ожиданий. Не хочешь вообще никак взаимодействовать с "токсичным" сообществом? Закрой возможность слать issue и PR. Ну или вообще не выкладывай свой проект в опенсурс. Если ты не хочешь признания от сообщества и его помощи в развитии проекта, то вполне себе хороший вариант.
Обратите внимание, что эта драма возникла только с actix, тогда как множество других проектов весьма успешно развиваются, даже имея в своём багаже soundness проблемы.
Как с C# не знаю, но вот сравнение с Матлабом без использования специализированных матричных библиотек, вероятно, будет нечестным. Кроме того, в Расте умышленно используется достаточно маленькая стандартная библиотека, поэтому без использования внешних зависимостей вы далеко с ним не уйдёте. Благо подключение зависимостей и их использование в Расте это сущее удовольствие. Т.к.
nalgebra(либо аналоги попроще) позволяет значительно сократить кол-во бойлерплейта, то называть данную зависимость лишней я бы не стал.Про объявление структур советую внимательно подумать, их использование не только позволяет сокращать количество бойлерплейта как в моём примере, и тем самым сокращать вероятность ошибок (явные имена полей этому тоже способствуют), но и позволяет лучше и быстрее понимать код не только другим людям, но и вам после того как вы к нему вернётесь через какое-то время. Разумеется, тут нужно соблюдать меру, но лично мне разбираться в вашем коде было достаточно сложно.
В расте есть массивы с фиксированным количеством элементов, т.е. более идиоматично было бы написать это, например, так:
Либо используя
nalgebraвообще переписать как:Что меня забавляет в подобных "анализах", так это то, что никак не учитывается динамика стакана заявок, тем самым выкидывается почти вся информация об эластичности рынка. Для создания ауры наукообразности для домохозяек может и сойдёт, но никуда не годится для технического ресурса.
Фигасе "мелкие службы". Magic Pocket использующий Rust это по сути центральная компонента их хранилища. Конечно, его не полностью переписали с Go, но всё же. К сожалению, презентации где о переписывании рассказывалось более подробно более не доступны...
Потому что практика показывает, что проекты на Rust-е в целом получаются более надёжными чем на С/C++ (возьмите тот же блог-пост про http клиенты или про переписывание CSS движка лисы), что явно противоречит вашему утверждению об "отсутствии гарантий". Это не только заслуга языка, но и сложившейся экосистемы вокруг него, которые, на мой взгляд, не следует рассматривать в отрыве друг от друга.
Про libc я попытался использовать ad absurdum, дабы показать абсурдность вашего заявления про "если в стеке вызовов есть хоть 1 unsafe", ибо практика показывает, что можно строить более надёжные системы на формально менее надёжном фундаменте, но раз вы считаете это демагогией, продолжайте считать и далее. Дискутировать с вами далее у меня желания нет.
Ога, можно вспомнить ещё и об
libc, который используется стандартной библиотекой Раста, и который, о ужас, написан на C. Подход "либо всё, либо ничего" на мой взгляд является весьма странным и непрактичным. Программирование это инженерная дисциплина в которой нужно выбирать между градациями множества переменных.Хех, учитывая что вы перечислили языки со сборщиком мусора, то здесь вы действительно правы (хотя имхо культура строгости и типобезопасности делает экосистему Раста в среднем более надёжной, чем в перечисленных языках, но это не свойство языка как такового). Если для ваших задач данных языков достаточно, то переходить на Раст вам действительно особой нужды нет.
Разумеется это не 100% защита, но большое количество проектов показывает, что гарантии Раста действительно серьёзно уменьшают количество memory safety багов по сравнению с C/C++ и серьёзные компании берут его на вооружение как раз из-за этого, а не из-за якобы пресловутого хайпа. Если из 70% ошибок компилятор позволяет предотвращать условные 95%, то на мой взгляд это является существенным достижением.
Я понимаю, что вы как фанат D, возможно и скептично относитесь к гарантиям Раста, но практика показывает несколько иные результаты.
Но признан багом и работы над его исправлением ведутся, хоть и медленно (вплоть до предложений полностью задеприкейтить
as). В actix-е же большинство использованийunsafeделалось без какого-либо анализа влияния на производительность и, если не ошибаюсь, во время первой уборкиunsafeпроизводительность не особо пострадала. Не говоря уже об отказе принимать патчи фиксящие эти баги.Тогда соответствующие функции необходимо было помечать
unsafe, тогда бы никто и слова не сказал. Но автор притворился что эти функции являются "безопасными" дабы сэкономить на написанииunsafeблоков, тем самым нарушив контракт с пользователями библиотеки.В issue-ях, насколько я помню, никто не говорил от имени всего сообщества, выражалось в первую очередь личное мнение. В этой дискуссии под "мнением сообщества" я подразумеваю обобщённую реакцию людей ратующих за важность исправления soundness багов, можно называть её "мнением части сообщества Rust", если вас это больше устроит.
Да, есть баги в библиотеках и компиляторе, которые нарушают эти гарантии. Но эти проблемы не замалчиваются и люди активно работают над их решением. Т.е. проблема не в том, что в actix'е были soundness баги, а в том, что автор не признавал их важность и отказывался работать над их исправлением.
Ответил выше. Этот свод правил относится только к очень малой доли кода и если эта доля написана верно (чего не было в случае actix'а), то для всего остального кода гарантии поддерживаются автоматически компилятором.
Гарантии даются языком при использовании безопасного подмножества языка. При использовании
unsafeвы берёте сохранение гарантий на себя и должны обернуть этот код в безопасный интерфейс, который гарантирует инварианты языка.В общем, прочитайте, например, TRPL: https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
Потому что
unsafeэто "необходимое зло" без которого не обойтись при написании низкоуровневых вещей и FFI. "Фишка" Раста в том, что если вы при написанииunsafeкод соблюли соответствующие требования, то это делает невозможным получение неопределённого поведения в коде который не используетunsafe.Например,
Vecактивно используетunsafeпод капотом, но как бы вы не использовали безопасное API вы не получите неопределённого поведения в скомпилированной программе из-за него. Таким образом, вместо того что бы следить за всем кодом как в C/C++, вам нужно следить и внимательно проверять только очень малую часть кода. Большая часть Раст проектов не использует напрямуюunsafeвовсе и полагается на то, что зависимости ответственно подошли к использованиюunsafe, поэтому нарушение этих гарантий и вызывает столь негативную реакцию.Я же уже выше об этом написал… Да, никто никому не должен, в т.ч. и представители сообщества (многие из которых мейнтейнят свои open source проекты) не обязаны хорошо относиться к людям открыто плюющим на ценности поддерживаемые ими.
В каком-то смысле это является иммунной реакцией, что является необходимым элементом для здорового сообщества. Однако, конечно стоит внимательно следить дабы это не привело к аутоимунным эффектам.
Вы на Расте пишите? Как я понял нет. Проблема не в
unsafe, проблема в том, что автор не желает понимать как его следует правильно использовать и по сути открывает широкую дверь для неопределённого поведения, тем самым подрывая те гарантии которые и являются киллер фичей Rust'а.Представьте новости что сайт написанный на actix-е оказывается хакнут через уязвимость возникшую из-за неправильного использования
unsafe, что привело к миллиардным убыткам. Это будет очень больным ударом по репутации языка позиционирующего себя как memory safe альтернативу C/C++.Ну или более приземлённый пример, разработчик будет тратить своё время на отлавливание багов, которые должны были предотвращаться компилятором. Выше уже об этом уже написал человек пользовавшийся actix-ом.
Почитайте, например, вот этот блог-пост обсуждающий проблемы в actix-web для дополнительного контекста.
Так что это никакие не "розовые мечты", а вполне рациональные усилия по защите того что делает Rust ценным для разработчиков инвестирующих в его использование и развитие.
Потому что я сам ожидаю от Rust проектов соответствия центральным гарантиям языка и полагаюсь на это в своей работе. Без этих гарантий уж лучше использовать C/C++ для которых экосистема на данный момент значительно богаче. И хоть я лично и не участвовал в драме вокруг actix'а, для меня тот факт что мейнтейнер столь заметного проекта столь пофигистски относится к гарантиям языка стало чрезвычайно неприятным сюрпризом.
https://github.com/RustCrypto
https://github.com/rust-random
Вы всё время почему-то хотите найти виноватых. Я описываю альтернативную точку зрения, дабы те кто не знакомы с ситуацией могли лучше понять участвовавшие стороны.
Если бы автор написал "я устал, я ухожу" и передал бразды правления, то большинство бы отнеслось с пониманием. Но зачем было удалять репозитории в данной ситуации, кроме как для пущего драматического эффекта?
Не перевирайте мои слова. Где я об этом писал?
Open source это общественное занятие. Вы с этим можете не соглашаться, но де-факто это так. Сообщество в данном контексте это группа людей разделяющие некоторые ценности и представления, в данном случае это люди ценящие гарантии Rust'а и ожидающие от проектов защиты этих гарантий и стремления к этому. И оно вполне себе существует. Автор выкладывал проект для использования сообществом. Поэтому когда выясняется что автор ни во что не ставит гарантии языка, то разумеется это вызывает негативную реакцию.
И не стоит заявлять что представители сообщества это сплошь лодыри, которые только и могут критиковать чужой труд. Нет, многие из его представителей активно работают над созданием экосистемы следующим ценностям сообщества, которой в т.ч. и пользуется actix. И активно участвуют в развитии чужих проектов.
Не хочешь в своём проекте соответствовать этим ценностям? Твоё право. Сразу позиционируй проект соответствующим образом, дабы у сообщества не было ложных ожиданий. Не хочешь вообще никак взаимодействовать с "токсичным" сообществом? Закрой возможность слать issue и PR. Ну или вообще не выкладывай свой проект в опенсурс. Если ты не хочешь признания от сообщества и его помощи в развитии проекта, то вполне себе хороший вариант.
Обратите внимание, что эта драма возникла только с actix, тогда как множество других проектов весьма успешно развиваются, даже имея в своём багаже soundness проблемы.