Да, оно самое. В целом, полезная штука, скоро уже вроде как должны стабилизировать. С учётом недавней стабилизации GAT'ов, это несколько облегчит асинк в расте (хотя наверное не на много), с которым работать довольно больно. Позволит использовать async трэйты без костылей в виде сторонних крейтов, и, возможно, уйдёт необходимость везде обмазываться Pin'ами и Box'ами.
И хотя, всё это существует уже довольно давно в nightly-версии компилятора, многие всё равно сидят на stable-версии по многим причинам, и очень этого ждут.
Вам серьёзно неочевидно что существование двух ссылок может быть валидно?
Мистер Борров никогда и не запрещал иметь несколько алиас-ссылок в один момент времени )
Если хотите изменять один объект из нескольких мест, то вам в любом случае придётся убедиться в безопасности своих намерений, хоть в расте, хоть в плюсах, хоть где. В расте берёте подходящий iterior-mutability и через него получаете доступ на изменение в сколь угодном количестве мест. Для вас как пользователя этого API — всё в safe подмножестве, включать голову даже не нужно, никаких опасных вещей по недосмотру сделать не выйдет. Ну мечта же!
Может вы ещё весь unsafe код в расте считаете не существующим?
Какая разница сколько там unsafe кода? Главное что можно самому оставаться в safe окружении и спокойно писать код.
Все эти претензии — вообще несерьёзно. В расте есть реальные проблемы, например отсутствие TAIT и подобных штук. Но никто из хэйтеров раста про это почему-то не упоминает, видимо просто не успевают с этим столкнуться в процессе изучения языка. Но зато уже идёт набрасывать на форуме о том что раст не нужен, ведь "там unsafe и уникальные ссылки нельзя шарить!!!".
Сборка Rust проектов и правда очень долгая, но только если компилировать проект первый раз. Далее включается инкрементальная сборка, и по сути затык во времени идёт только на этапе линковки. Но и для этого есть решение — использовать линковщик mold вместо стандартного (подменяется одной строчкой в конфиге cargo). И вжух — проблема времени компиляции уходит в принципе!
Разница в стоимости между RPi и аналогами моделей других производителей (Orange, Banana и др.) не покрывает расходов на решение скрытых проблем и прочих всплывающих нюансов в решении конкурентов. Raspberry очень распространена: если есть какая-то задача, которую хочется решить на arm-одноплатнике, то с бОльшей вероятностью для Raspberry уже всё будет готово. Наткнулись на какую-то проблему — решение нагуглится спустя пару минут. Это очень выручает.
В случае с Orange, например, даже сам производитель на некоторые модели не может допилить полноценную поддержку своего железа в своих дистрибутивах linux, чего уж говорить о софте сторонних разработчиков: тот же steam-link в линуксе будет работать только на Raspberry.
Есть мини-пк безвентиляторные, искать по "fanless mini pc" на алике. Они полностью бесшумные, радиатор — это собственно сам корпус, весь алюминиевый. У меня с года 2018 подобный есть, на нём запущен ESXi и внутри всякое, включая pfSense, видеонаблюдение и NAS.
Выигрыш виден, но Ivy Bridge — довольно старая архитектура (~10 лет), поэтому полагаю что на более современных процессорах разница между target-cpu=native\generic будет ещё больше.
Ещё я решил посмотреть, что будет если вместо target-cpu=native попробовать включить оптимизации с упором на компактность бинарника, а не производительность. Получилось следующее: скорость работы снижается существенно, а вот размер — не очень.
Много кто вначале своего пути изучения раста плюётся от синтаксиса. Однако практика показывает, что уже спустя месяц неторопливого изучения языка, все эти претензии куда-то магически улетучиваются )) Мне кажется это в основном потому что синтаксис на самом деле не слишком отличается, просто визуальная составляющая обматывает.
Нет смысла делать ещё один язык с таким же синтаксисом, когда можно этот самый синтаксис чуть-чуть изменить и получить взамен огромный выигрыш в удобстве использования языка. К сожалению, это удобство не сразу становится очевидным.
Игра, в которой нужно на примитивном ассемблере рисовать картинки на дисплее. Хотя, это скорее не развлекающая игра, а обучающая: хорошо и довольно точно показывает как на самом деле ЦП выполняет инструкции. Да и в целом наглядно показывается что такое инструкции и память.
Не хватает обработки случая, когда устройство продолжительное время на зарядке потребляет в единицу времени энергии больше, чем получает. Такое ведь в теории может быть. Допустим, устройство питается от солнечных панелей, и возникает необходимость в течении часа что-то усердно считать. Но вот незадача — погода испортилась и тучки набежали :( Я конечно понимаю, что мк и «считать» это странная связка, но…
Смартфоны кстати умеют о таком режиме «зарядки» предупреждать: у меня показывает такую уведомляшку если включить GPS, интернет с картами и дисплей на 100% яркости (зарядное устройство в авто плохое). Но тут понятно, как говорилось в статье — обработка намного сложнее, да ещё и отдельным контроллером.
Ограничения в буквах только у винды, а задачу с торрентами вполне можно и на чём-то другом сделать, даже проще будет. Да и в случае винды — монтирование диска в папку можно сделать, тогда буквы и не потребуются.
А что они скажут? Если хоть что-то вякнут — тут же словят помои в лицо от всего SJW сообщества, даже от тех, кто вчера ничего не знал о Rust, но уже сегодня в своей фейсбучной ленте увидел пост: «пасматрити, опять меньшинства принижают!!! да сколько же можно терпеть, уволить этих негодяев сроочна!!!». Собственно, я думаю это одна из причин, почему модераторы не стали ничего пояснять (говорить прямым текстом). Скорее всего себе дороже: непонятно как ситуация повернётся, и можно очень легко влететь в blacklistы топовых IT американских компаний.
Однако здесь модераторы — это не просто люди, которые занимаются условным поддержанием чистоты в issue и мониторингом за соблюдение CoC. Они тоже разработчики, и очень сильные. Они пишут различные важные компоненты и инструменты для раста.
Как вариант можно UI делать на Rust'овом druid. Оно конечно ещё очень сырое, но какие-то поделки делать уже можно, особенно если брать прямо `master` ветку, а не последний доступный релиз `0.7.0` ). Виджеты есть, события есть, данные отдельно. Из плохого — отсутствие документации, хотя это немножко компенсируется хорошими примерами прямо в репозитории. Как пример использования этого «toolkit»а рекламируют Spotify-клиент Psst
Но естественно это будет посложнее чем на электроне стряпать, особенно вначале. И для production оно очевидно (пока что) не подходит.
По-моему, учитывая что в декабре (то есть через месяц с хвостиком) у AngularJS будет прекращена поддержка, рассматривать в каком-либо ключе этот фрэймворк странно, не говоря уже о мыслях его изучить или начать пилить на нём новый проект. И дело не в том, что он «старый» и не «хайповый», а именно в поддержке. Браузеры обновятся, что-то поломается и всё, приехали. С потенциальными уязвимостями то же самое.
Да, оно самое. В целом, полезная штука, скоро уже вроде как должны стабилизировать. С учётом недавней стабилизации GAT'ов, это несколько облегчит асинк в расте (хотя наверное не на много), с которым работать довольно больно. Позволит использовать async трэйты без костылей в виде сторонних крейтов, и, возможно, уйдёт необходимость везде обмазываться Pin'ами и Box'ами.
И хотя, всё это существует уже довольно давно в nightly-версии компилятора, многие всё равно сидят на stable-версии по многим причинам, и очень этого ждут.
Мистер Борров никогда и не запрещал иметь несколько алиас-ссылок в один момент времени )
Если хотите изменять один объект из нескольких мест, то вам в любом случае придётся убедиться в безопасности своих намерений, хоть в расте, хоть в плюсах, хоть где. В расте берёте подходящий iterior-mutability и через него получаете доступ на изменение в сколь угодном количестве мест. Для вас как пользователя этого API — всё в safe подмножестве, включать голову даже не нужно, никаких опасных вещей по недосмотру сделать не выйдет. Ну мечта же!
Какая разница сколько там unsafe кода? Главное что можно самому оставаться в safe окружении и спокойно писать код.
Все эти претензии — вообще несерьёзно. В расте есть реальные проблемы, например отсутствие TAIT и подобных штук. Но никто из хэйтеров раста про это почему-то не упоминает, видимо просто не успевают с этим столкнуться в процессе изучения языка. Но зато уже идёт набрасывать на форуме о том что раст не нужен, ведь "там unsafe и уникальные ссылки нельзя шарить!!!".
Гитхаб же вроде должен давать выбрать вообще любой форк при оформлении ПР, разве нет в выпадающем списке?
Сборка Rust проектов и правда очень долгая, но только если компилировать проект первый раз. Далее включается инкрементальная сборка, и по сути затык во времени идёт только на этапе линковки. Но и для этого есть решение — использовать линковщик mold вместо стандартного (подменяется одной строчкой в конфиге cargo). И вжух — проблема времени компиляции уходит в принципе!
Разница в стоимости между RPi и аналогами моделей других производителей (Orange, Banana и др.) не покрывает расходов на решение скрытых проблем и прочих всплывающих нюансов в решении конкурентов. Raspberry очень распространена: если есть какая-то задача, которую хочется решить на arm-одноплатнике, то с бОльшей вероятностью для Raspberry уже всё будет готово. Наткнулись на какую-то проблему — решение нагуглится спустя пару минут. Это очень выручает.
В случае с Orange, например, даже сам производитель на некоторые модели не может допилить полноценную поддержку своего железа в своих дистрибутивах linux, чего уж говорить о софте сторонних разработчиков: тот же steam-link в линуксе будет работать только на Raspberry.
Ишим — Бердюжье, ха-ха, это легенда а не дорога!
Впрочем, на ютубе ищутся видосы от недавного времени где эту дорогу уже не узнать.
Есть мини-пк безвентиляторные, искать по "fanless mini pc" на алике. Они полностью бесшумные, радиатор — это собственно сам корпус, весь алюминиевый. У меня с года 2018 подобный есть, на нём запущен ESXi и внутри всякое, включая pfSense, видеонаблюдение и NAS.
Взял похожий процессор
i5-3470@3.2(как я понял, у автораi5-3570@3.4).597,728,631597,728,631690,607,734Выигрыш виден, но Ivy Bridge — довольно старая архитектура (~10 лет), поэтому полагаю что на более современных процессорах разница между
target-cpu=native\genericбудет ещё больше.Ещё я решил посмотреть, что будет если вместо
target-cpu=nativeпопробовать включить оптимизации с упором на компактность бинарника, а не производительность. Получилось следующее: скорость работы снижается существенно, а вот размер — не очень.143,389,733(2635K)143,410,296(2665K)597,728,631(2692K)Результаты размера без strip.
Нет смысла делать ещё один язык с таким же синтаксисом, когда можно этот самый синтаксис чуть-чуть изменить и получить взамен огромный выигрыш в удобстве использования языка. К сожалению, это удобство не сразу становится очевидным.
Игра, в которой нужно на примитивном ассемблере рисовать картинки на дисплее. Хотя, это скорее не развлекающая игра, а обучающая: хорошо и довольно точно показывает как на самом деле ЦП выполняет инструкции. Да и в целом наглядно показывается что такое инструкции и память.
Наоборот, де-факто токио всех победил, это сейчас стандарт.
Смартфоны кстати умеют о таком режиме «зарядки» предупреждать: у меня показывает такую уведомляшку если включить GPS, интернет с картами и дисплей на 100% яркости (зарядное устройство в авто плохое). Но тут понятно, как говорилось в статье — обработка намного сложнее, да ещё и отдельным контроллером.
В целом, он рассказывает на конкретном примере что идёт не так с одним из членов Core Team.
Но естественно это будет посложнее чем на электроне стряпать, особенно вначале. И для production оно очевидно (пока что) не подходит.