Странно, что такая ваша программа компилировалась, потому что подобный код не работает уже давно (и я, если честно, вообще не помню чтобы так вообще когда-то было). Можете, пожалуйста, показать, какой именно документацией рекомендуется писать use и mod для одного и того же модуля?
Как мне кажется, довольно логично, что вам не нужно делать use на модуле, который объявляется непосредственно в этом же месте. Если вы сделаете rustc --pretty=expanded crate_root.rs, то компилятор вам выдаст представление всей единицы компиляции со всеми модулями, так как он его видит. В этом представлении очень хорошо видно, как модули вкладываются друг в друга.
но порог входа страшно высокий для понимания средств библиотек, помогающих справиться с жесткостью borrow checker'а, на уровне, достаточном для написания серьезного проекта.
На самом деле не такой уж и высокий. Достаточно уяснить для себя базовые принципы, на которых работает borrow checker (это те самое владение данными, заимствования и семантика перемещения). После некоторого количества практики вы уже интуитивно станете понимать, как писать код так, чтобы borrow checker не ругался, и борьба с компилятором плавно сойдёт на нет. У меня это заняло меньше полугода очень нерегулярного программирования в свободное время.
И с модулями в недавнем обновлении опять что-то намутили, все руки не дойдут исправить мой проект, чтобы компилировался.
Вы, вероятно, имеете в виду enum'ы? Да, пока что ломающие изменения довольно часты, но вскоре всё изменится :)
то есть риск, что после стабилизации нужно будет многое проверять на корректность работы или переписывать с учетом новых реалий.
Это не так. Если вы начнёте писать сейчас, то вы, так или иначе, будете следовать за nightly-сборками. Но первая стабильная версия, по сути, ответвится от nightly-сборки (предварительно пройдя через статус беты), поэтому, поскольку вы следуете за nightly-сборками, вы сможете совершенно безболезненно перейти на стабильную версию и больше не переписывать свой проект из-за ломающих изменений, потому что их не будет.
Насколько я понимаю, предполагается, что работать это будет именно так. Я думаю, что сложность здесь зависит от срока поддержки соответствующей версии языка. Вероятно, этот момент вскоре раскроют подробнее.
Насколько я знаю, такого, чтобы половина команды была за одно решение, половина за другое, и так, чтобы намертво — ещё не было. Как правило, члены команды убеждают друг друга в своей правоте.
Формального процесса именно принятия решения, когда кто прав, насколько я в курсе, нет. Наиболее формальная процедура в принципе об инновациях — это RFC. Насчёт конкретно енумов, вот, можете сами посмотреть обсуждение. Я думаю, core team просто бы не поняли, если бы они это отклонили без достаточно весомых причин (а таких в обсуждении не нашлось) :)
Безусловно, личности есть. Rust разрабатывается всем сообществом, но под управлением т.н. core team, группы разработчиков из Mozilla. Они как раз и ответственны за дизайн языка, принятие в него новых фич и т.д. Эта серия постов пишется как раз членами core team.
Процесс принятия крупномасштабных изменений, как правило, заключается в предварительном обсуждении через процесс RFC. Принятие решений по RFC и прочее обсуждение происходит на еженедельных митингах (где присутствует как core team, так и наиболее активные члены сообщества). В целом, процесс разработки очень демократичный и действительно учитывает мнение сообщества. Например, недавнее предложение о scoped enums не очень одобрялось core team, но благодаря массивной поддержке сообщества его приняли.
Просто ZeroMQ — это не MQ, несмотря на его название. Это просто слой абстракций над сокетами, применяемый там, где сокеты — это слишком низкоуровнево, а полноценные очереди сообщений и аналогичные системы — уже overkill. Их некорректно сравнивать, это совершенно разные инструменты.
Всё очень просто, на самом деле. Сферы деятельности, особенно те, которым обучают в университете, требуют, как правило, только «мозгов», но не требуют особого физического развития. Здесь важна только степень умственного развития и вообще желание этот самый ум развивать. В этом никакой принципиальной разницы между полами нет. А спорт — это как раз та область, где физическое развитие важно. И тут уже нельзя спорить, что биологически большинство мужчин лучше приспособлено к физическим нагрузкам, чем большинство женщин. Ну просто так человек эволюционировал, что мужчины как охотники были именно что быстрее, выше и сильнее. Безусловно, обратные ситуации есть всегда, и среди женщин в «тяжёлых» видах спорта много добившихся серьёзных результатов, и среди мужчин полно тех, кто отжаться пять раз не может (стыдно признаться, но я почти что из таких), но в целом биологическую приспособленность/неприспособленность отрицать глупо и даже опасно — это не стереотип, это объективный факт.
Если на восстанавливаемом диске установлена вторая операционная система семейства Windows, то утилиту восстановления нужно запускать из под неё. Это ограничение связано с политиками Windows.
и
Windows-утилита работает только с файловой системой NTFS, поддерживаются только тома MBR и GPT.
? А если у меня в дуалбуте линукс и винда, то что делать? Естественно, линуксячьи диски все в ext4/btrfs.
Rust позиционируется в качестве замены C/C++ — это низкоуровневые библиотеки, embedded, игры. Однако Rust предоставляет достаточно абстракций, чтобы залезть и в нишу Go — это высокопроизводительный бэкенд. Например, уже сейчас есть несколько легковесных веб-фреймворков.
Взаимодействие с кодом на C в Rust близко к идеальному (имхо). Проблемы там есть, насколько я помню, только в районе юнионов. С C++ сложнее, но тут уже особенности самого C++ и его всевозможным vendor-specific ABI.
Фича со скретчфайлами очень классная. А возможно ли сделать что-то подобное для скальных Worksheet'ов? Сейчас очень напрягает необходимость их сохранять в виде файла (особенно когда проект управляется VCS), когда хочется всего лишь попробовать пару команд. Было бы очень удобно, если бы можно было просто запустить worksheet со всем classpath'ом проекта.
Всё просто — для раббита и аналогичных MQ вам нужно запускать отдельный демон, вероятно, даже на отдельной машине. Соответственно, там в комплекте есть куча возможностей, как вы уже заметили. Но это ещё одно звено в вашем приложении.
ZeroMQ же (и nanomsg, и другие последователи) — это «сокеты на стероидах», тонкий слой абстракции поверх BSD-сокетов. Дополнительные (сверх обычных сокетов) возможности там довольно низкоуровневые, но для ZeroMQ не требуется дополнительных программ. Вся функциональность линкуется в виде библиотеки (довольно маленькой, кстати) в вашу программу.
Пример, зачем оно в принципе нужно. Есть такая среда, IPython, которая, помимо всего прочего, предоставляет возможность создания красивых фронтендов к ней, типа веб-приложения в браузере. Общение между BE и FE ведётся с помощью ZMQ. Настоящий брокер сообщений, как можно себе представить, был бы здесь просто overkill'ом.
Как мне кажется, довольно логично, что вам не нужно делать use на модуле, который объявляется непосредственно в этом же месте. Если вы сделаете
rustc --pretty=expanded crate_root.rs, то компилятор вам выдаст представление всей единицы компиляции со всеми модулями, так как он его видит. В этом представлении очень хорошо видно, как модули вкладываются друг в друга.На самом деле не такой уж и высокий. Достаточно уяснить для себя базовые принципы, на которых работает borrow checker (это те самое владение данными, заимствования и семантика перемещения). После некоторого количества практики вы уже интуитивно станете понимать, как писать код так, чтобы borrow checker не ругался, и борьба с компилятором плавно сойдёт на нет. У меня это заняло меньше полугода очень нерегулярного программирования в свободное время.
Вы, вероятно, имеете в виду enum'ы? Да, пока что ломающие изменения довольно часты, но вскоре всё изменится :)
Это не так. Если вы начнёте писать сейчас, то вы, так или иначе, будете следовать за nightly-сборками. Но первая стабильная версия, по сути, ответвится от nightly-сборки (предварительно пройдя через статус беты), поэтому, поскольку вы следуете за nightly-сборками, вы сможете совершенно безболезненно перейти на стабильную версию и больше не переписывать свой проект из-за ломающих изменений, потому что их не будет.
Но как же я рад, что пишу сейчас на Scala!
Формального процесса именно принятия решения, когда кто прав, насколько я в курсе, нет. Наиболее формальная процедура в принципе об инновациях — это RFC. Насчёт конкретно енумов, вот, можете сами посмотреть обсуждение. Я думаю, core team просто бы не поняли, если бы они это отклонили без достаточно весомых причин (а таких в обсуждении не нашлось) :)
Процесс принятия крупномасштабных изменений, как правило, заключается в предварительном обсуждении через процесс RFC. Принятие решений по RFC и прочее обсуждение происходит на еженедельных митингах (где присутствует как core team, так и наиболее активные члены сообщества). В целом, процесс разработки очень демократичный и действительно учитывает мнение сообщества. Например, недавнее предложение о scoped enums не очень одобрялось core team, но благодаря массивной поддержке сообщества его приняли.
Купил его после того, как сломался приёмник вот этого:
Лучше него (Logitech Cordless TrackMan Optical) я никогда ничего не встречал. К сожалению, его уже не делают :(
и
? А если у меня в дуалбуте линукс и винда, то что делать? Естественно, линуксячьи диски все в ext4/btrfs.
Взаимодействие с кодом на C в Rust близко к идеальному (имхо). Проблемы там есть, насколько я помню, только в районе юнионов. С C++ сложнее, но тут уже особенности самого C++ и его всевозможным vendor-specific ABI.
Фича со скретчфайлами очень классная. А возможно ли сделать что-то подобное для скальных Worksheet'ов? Сейчас очень напрягает необходимость их сохранять в виде файла (особенно когда проект управляется VCS), когда хочется всего лишь попробовать пару команд. Было бы очень удобно, если бы можно было просто запустить worksheet со всем classpath'ом проекта.
ZeroMQ же (и nanomsg, и другие последователи) — это «сокеты на стероидах», тонкий слой абстракции поверх BSD-сокетов. Дополнительные (сверх обычных сокетов) возможности там довольно низкоуровневые, но для ZeroMQ не требуется дополнительных программ. Вся функциональность линкуется в виде библиотеки (довольно маленькой, кстати) в вашу программу.
Пример, зачем оно в принципе нужно. Есть такая среда, IPython, которая, помимо всего прочего, предоставляет возможность создания красивых фронтендов к ней, типа веб-приложения в браузере. Общение между BE и FE ведётся с помощью ZMQ. Настоящий брокер сообщений, как можно себе представить, был бы здесь просто overkill'ом.