Ещё в Rust много контейнеров, которые названы "дефолтными" словами, никак не описывающими их назначение. Обычно мне такие слова linter подчёркивает в других языках, как плохие. Например, Box. Из-за этого сильно страдает выразительность языка, как мне кажется.
А можно подробнее? Box назван именно так, потому что то, что он содержит — это "упакованный" (boxed) объект.
Например, "unwrap" и его вариации, встречающиеся постоянно
Использование unwrap не допустимо в конечном коде приложения, иногда его можно использовать, когда точно обработка ошибки не требуется, но это бывает крайне редко.
Лично мне больше нравятся fn, pub и impl, чем function, public и implementation. Писать короче и чтение кода они никак не затрудняют, наоборот, код становится сильно компактнее и яснее.
Ваш комментарий — просто урок, почему не нужно делать далеко идущих выводов, до конца не разобравшись в исходных посылках.
Canonical — коммерческая компания, которая участвует в общем движении СПО как активный потребитель. То есть, она участвует в разработке и дорабатывает СПО-продукты под свои нужды, как и другие компании и отдельные люди в этом движении. Canonical нужно, чтобы их дистрибутив имел "товарный вид", потому что она занимается его коммерциализацией (производных на его базе продуктов). Так что вы имеете удобства Ubuntu не потому, что сообщество вдруг озаботилось потребностями пассивных потребителей, а потому, что используя Ubuntu вы прямо или косвенно делаете деньги для Canonical.
Прочие и так уже пользовались Виндой, речь про удаленную работу. Но даже если бы мне ее купили, я бы все равно работать не стал по остальным указанным причинам.
А вы хотите, чтобы вам все априори на блюдичке приподнесли? За какие такие заслуги?
Становитесь активным пользователем и добивайтесь того, чтобы нужные вам улучшения были реализованы, принимайте участие. Вот для таких пользователей Linux и должен становиться дружелюбнее прежде всего. Не хотите участвовать? Тогда довольствуйтесь тем, что уже есть, что было создано другими и решило проблемы других. Либо откажитесь от использования.
А какая, собственно, разница? Почему на уровне модуля — можно, а на уровне библиотеки — нельзя?
Потому что в библиотеке могут быть десятки и сотни модулей, а протекание unsafe за пределы своего модуля на уровень библиотеки делает их также потенциально небезопасными.
К тому же со временем ваш pub(crate) вполне может превратиться в pub или появится публичная функция в другом модуле, которая будет оборачивать небезопасную функцию, а так как она не помечена unsafe и определена далеко в другом модуле, то такое отследить будет гораздо сложнее.
Все-таки программа — это не просто поток текста, это структурированный текст. Поэтому грамотное использование спецсимволов может сильно улучшить восприятие программы в целом, соотношение ее составных частей.
Нечитаемое месиво получается только тогда, когда собственные идентификаторы программист начинает делать однобуквенными, тогда их просто труднее отделить от операций и кусков синтаксиса самого языка и все сливается в одном потоке коротких символов. Другая крайность: писать ключевые слова и операции длинными словами, как и пользовательские имена — опять же получится трудночитаемое месиво.
Ну вот я пишу в прод на Rust, и, на самом деле, никаких дополнительных преимуществ Rust или его недостатков прод не вскрыл в сравнении с тем, что было уже понятно на фазе изучения языка и разработки хобби-проектов.
То есть писать-то особо и не о чем, кроме как повторять то, что уже было сказано десятки раз.
Вы путаете непривычность синтаксиса с неудобством. Для тех, кто программирует на Rust — синтаксис вполне хороший, это только для новичков он выглядит страшно, потому что непривычен. Да, с синтаксисом есть и проблемы, которые в новых версиях языка пытаются решать, но они совсем не в тех местах, которые вы указали.
А можно подробнее?
Boxназван именно так, потому что то, что он содержит — это "упакованный" (boxed) объект.Использование
unwrapне допустимо в конечном коде приложения, иногда его можно использовать, когда точно обработка ошибки не требуется, но это бывает крайне редко.Лично мне больше нравятся
fn,pubиimpl, чемfunction,publicиimplementation. Писать короче и чтение кода они никак не затрудняют, наоборот, код становится сильно компактнее и яснее.Проблема будет решена, когда реализуют делегаты хоть в каком-нибудь виде. Например, в таком:
https://github.com/elahn/rfcs/blob/delegation2018/text/0000-delegation.md
Ваш комментарий — просто урок, почему не нужно делать далеко идущих выводов, до конца не разобравшись в исходных посылках.
Canonical — коммерческая компания, которая участвует в общем движении СПО как активный потребитель. То есть, она участвует в разработке и дорабатывает СПО-продукты под свои нужды, как и другие компании и отдельные люди в этом движении. Canonical нужно, чтобы их дистрибутив имел "товарный вид", потому что она занимается его коммерциализацией (производных на его базе продуктов). Так что вы имеете удобства Ubuntu не потому, что сообщество вдруг озаботилось потребностями пассивных потребителей, а потому, что используя Ubuntu вы прямо или косвенно делаете деньги для Canonical.
Чем локальнее, тем лучше. Не представляю себе ситуацию, когда требуется протекание unsafe за пределы модуля, причем в безопасном (!) интерфейсе.
Для своих задач я обычно использую DOT:
https://ru.wikipedia.org/wiki/DOT_(%D1%8F%D0%B7%D1%8B%D0%BA)
Кто-то не любит where-блоки, хорошим стилем это трудно назвать. Лучше так:
Требования MIT никак не ограничивают имущественные права, также как и PD, так что в экономическом смысле — обе равноправны.
А теперь добавьте несколько дополнительных узлов, которые требуют перестройки связей, и преимущество GUI-подхода уже не так очевидно...
В случае текстовой разметки вы также могли бы воспользоваться множеством уже готовых шаблонов, просто поменяв имена, например.
Вот это — действительно проблема, которую нужно решать: экономить время и силы пользователей при участии в разработке и отладке.
Прочие и так уже пользовались Виндой, речь про удаленную работу. Но даже если бы мне ее купили, я бы все равно работать не стал по остальным указанным причинам.
А вы хотите, чтобы вам все априори на блюдичке приподнесли? За какие такие заслуги?
Становитесь активным пользователем и добивайтесь того, чтобы нужные вам улучшения были реализованы, принимайте участие. Вот для таких пользователей Linux и должен становиться дружелюбнее прежде всего. Не хотите участвовать? Тогда довольствуйтесь тем, что уже есть, что было создано другими и решило проблемы других. Либо откажитесь от использования.
Потому что в библиотеке могут быть десятки и сотни модулей, а протекание unsafe за пределы своего модуля на уровень библиотеки делает их также потенциально небезопасными.
К тому же со временем ваш
pub(crate)вполне может превратиться вpubили появится публичная функция в другом модуле, которая будет оборачивать небезопасную функцию, а так как она не помечена unsafe и определена далеко в другом модуле, то такое отследить будет гораздо сложнее.Все-таки программа — это не просто поток текста, это структурированный текст. Поэтому грамотное использование спецсимволов может сильно улучшить восприятие программы в целом, соотношение ее составных частей.
Нечитаемое месиво получается только тогда, когда собственные идентификаторы программист начинает делать однобуквенными, тогда их просто труднее отделить от операций и кусков синтаксиса самого языка и все сливается в одном потоке коротких символов. Другая крайность: писать ключевые слова и операции длинными словами, как и пользовательские имена — опять же получится трудночитаемое месиво.
Есть предложение по использованию unsafe для полей, что решит данную проблему:
https://github.com/reem/rfcs/blob/unsafe-fields/active/0000-unsafe-fields.md
https://github.com/rust-lang/rfcs/issues/381
Но пока это не внедрено — да, потенциально придется анализировать весь модуль при модификации чего-то с unsafe.
От некоторых ошибок Rust гарантированно спасает. Например, вариативный анализ должен быть всегда полным.
Ну вот я пишу в прод на Rust, и, на самом деле, никаких дополнительных преимуществ Rust или его недостатков прод не вскрыл в сравнении с тем, что было уже понятно на фазе изучения языка и разработки хобби-проектов.
То есть писать-то особо и не о чем, кроме как повторять то, что уже было сказано десятки раз.
Когда у вас ключевые слова короткие и удачно подобраны спец. символы, а пользовательские идентификаторы и имена длинные — код читается легче.
Вы путаете непривычность синтаксиса с неудобством. Для тех, кто программирует на Rust — синтаксис вполне хороший, это только для новичков он выглядит страшно, потому что непривычен. Да, с синтаксисом есть и проблемы, которые в новых версиях языка пытаются решать, но они совсем не в тех местах, которые вы указали.