Ну, здесь всё-же начало слова и далее перетекает в гласную после "д". В украинском после гласной в середине слова будет "ї" — "Андроїд". А "йду" и "їду" — разные по смыслу слова, поэтому в любом случае нет выбора — только "и" и "й".
Вы мерками какого языка меряете и на каком его историческом этапе? )
Возьмите русский текст начала 20-го века — обнаружите столько странных и удивительных слов. Текст 300-400 летней давности Вы без перевода на современный язык чаще всего не сможете понять.
А что говорить про слова и словообразование почти тысячелетней давности от которых даже в письменности почти следов не осталось?
Потому что система — это одно, а пользовательские эксперименты — это другое.
Точно так же при разработке на других языках — что там у себя ставят разработчики — никак не влияет на работу системы в целом. А когда доставляется конечный продукт — он запаковывается по всем правилам.
В той же Gentoo ничто не мешает сосуществовать системно устанавливаемому rustc, которым собираются различные пакеты, и пользовательскому, устанавливаемому через rustup, в который пользователь может наустанавливать не нужных в системе компонентов, возможно весьма "экспериментальных", не говоря уже о том, что не тестировавшихся на совместимость.
То же касается и библиотек. Многие библиотеки доступны в комплекте дистрибутива, но зачастую они там совсем не той версии, что нужна разработчику и поддержка нескольких установленных версий — далеко не всегда имеется. Поэтому библиотеки тянутся в проект в обход пакетных менеджеров, и хорошо, если у языка есть свой пакетный менеджер для этого.
Отлично зайдёт для многих задач, но в какой-то момент можно внезапно споткнуться о GIL и будет очень обидно, поскольку по остальным параметрам всё очень классно, а решить задачу так же красиво, как на Python, на чём-то другом будет достаточно нетривиально.
Например, будет большая модель данных, часть обработки/доставки этих данных придётся сделать на уровне Python, поскольку низкоуровневые библиотеки, умеющие работать параллельно в несколько потоков, именно такую обработку сделать не могут, и придётся искать решение вопросов в духе "где взять больше памяти" и "как эффективно синхронизировать между процессами большие объёмы данных".
То, что человек совершает ошибки — вполне нормально.
Раст — язык с дополнительным контролем корректности программы.
Компилятор берёт на себя себя проверку декларируемых намерений и реального их выполнения. То есть, человек гараздо чаще сталкивается с ними не "когда-то потом", а непосредственно на этапе компиляции.
С помощью комплиятора и линтера постепенно вырабатывается навык писать сразу правильно и в соответствии с хорошим стилем. То, на что на самом деле в других языках уходят годы практики и что зависит от культуры написания кода в команде, если программисту повезло оказаться в хорошей команде.
Использовать Rust как дополнительный язык для ускорения узких мест — на самом деле тоже хорошее применение и важная ниша, в которой практически нет конкуренции. Да и глупо рассчитывать на то, что все разом забросят языки, изучению которых посвятили годы, и внезапно займутся переписыванием работающих проектов на новый язык с нуля (что может быть просто экономически нецелесообразно, даже когда язык действительно лучше по многим параметрам).
К комментарию выше я бы добавил, что есть два варианта: Вы заранее знаете всё множество операций, оно статично и не будет меняться по ходу дела (и тогда enum дёшево и надёжно решает задачу), либо Вы заранее не знаете, оно будет зависеть от пользователя Вашей библиотеки или ещё как-то динамически изменяться (тогда Ваш подход с трейт-объектами, хоть он и дороже, — лучше решает задачу).
К слову сказать, в Расте есть замыкания (которые "под сахаром" на самом деле тоже структуры).
Вот уж не обессудьте, но судя по комментариям к этой статье, подобное описание поведения значительно больше подходит к некоторым сторонникам С++. Безапелляционные заявления "С++ божественен, проблем вообще нет, их выдумали недоброжелатели, Rust/Swift/___(нужное вписать) — не нужен". Не это ли описанный выше фанатизм?
Наверно можно написать, но остаётся много открытых вопросов и компромисов. Например, если это фоновый процесс, то значит у нас есть какая-то задержка на использование памяти. Есть какие-то приоритеты исполнения, канал обмена данными с памятью тоже не резиновый и при большом числе ядер в системе может оказываться узким местом.
И главный вопрос в любом случае сведётся к цене, и ответ однозначно будет не "бесплатно". Но так же пока никуда не делись системы с одним ядром и с малым количеством памяти.
Но, если можно дешевле, а Rust показывает, что можно, то зачем платить больше? Но для этого поддержка такого уровня контроля должна быть на уровне языка и придётся чем-то жертвовать — например, дополнительно декларировать зависимости памяти в виде "времён жизни" (или ещё как-то). Многие, как оказалось, к этому не готовы, это "сложно", что при этом не мешает утверждать, что они способны всё то же самое удерживать в голове. Этот самообман, увы, мешает многим принять новую концепцию, которая вполне возможно прижилась бы и в других языках, несмотря на "тяжёлое наследие".
Народ минусует, но стесняется объяснить почему предложенное плохо.
"Фоновый поток" — это необохдимость синхронизации доступа к памяти в рантайме (что убивает саму идею большого числа ядер) и прочие неприятные вещи, вроде потери эффективности процессорных кешей. На этом фоне "инициализировать непосредственно перед использоавнием" выглядит сильно дешевле.
"Переписали" — всё же громко сказано, это был PoC операционной системы на Rust, сделанный с нуля и после этого уже несколько раз переписанный с пониманием "как делать не надо". Изначально Redox позиционировался как игрушечный проект и на вопрос "это замена Linux?" авторы давали определённый отрицательный ответ.
Если они используются для статического анализа, в чём смысл их проверять в рантайме? Если после статического анализа приходится проверять в рантайме, в чём смысл такого "статического" анализа?
Однако с обратной стороны звёздочки, можно уточнить, что реализация на итераторах с замыканиями часто оказывается даже немного быстрее, чем аналогичный код в императивном стиле.
После ООП языков с Rust достаточно тяжело. Привычные приёмы не работают, попытки писать в привычном стиле ведут к достаточно кривому и некрасивому коду. С Rust нужно переучиваться. Но, когда понимаешь, как здесь правильно писать, всё становится на порядок проще, код становится лаконичен, прекращается борьба с компилятором и вместо соперника он становится другом и на самом деле очень мощным инструментом, берущим на себя массу рутинной работы.
При наследовании трейтов не сохраняются реализации функций
На самом деле это не совсем так. Реализации, сделанные в трейтах — вполне наследуются, но это не то наследование к которому Вы могли привыкнуть в других языках.
Запись B: A, выглядит несомненно как наследование, но, несмотря на сходство — это не оно. Это декларация ограничения — типаж B может быть реализован только для тех типов, для которых реализован типаж A. Соответственно типаж B может расчитывать на методы типажа A, но он не находится в привилегированном положении наследника (и таких типажей может быть реализовано несколько для одного типа), он не переопределяет реализации из другого типажа, а при вызове без уточнения, какую реализацию мы желаем вызвать, компилятор закономерно удивится. Привычное интуитивное "наследование" здесь не работает, хотя вначале кажется — вот оно, и пытаешься строить наследование на типажах :-)
В качестве замены наследованию всё же предлагается другая фича — специализация, которая выглядит уже ближе по смыслу и местами она очень нужна. Однако она ещё не стабилизирована и это долгая история.
Добавлю к вышесказанному, что с одной стороны, элементы ООП всё же есть — со структурами можно работать как с объектами, типажи можно наследовать и даже есть типаж-объекты, но с другой стороны, отсутствие классов и наследования структур данных — это фича языка, введённая с целью избежать негативных практик ООП, в том числе чрезмерно разрастающихся иерархий классов, которые становится впоследствии дорого поддерживать и развивать. И на примере достаточно крупных проектов можно сказать, что это достаточно продуктивная модель.
Вообще, Rust — это очередной гибрид функционального и объектного подходов, с существенным перевесом в пользу функционального, но без возведения его в абсолют. Однако история о том, какой будет ООП сторона Rust, ещё не завершена, и соответствующие фичи и RFC потихоньку пилятся и эволюционируют.
Ну, здесь всё-же начало слова и далее перетекает в гласную после "д". В украинском после гласной в середине слова будет "ї" — "Андроїд". А "йду" и "їду" — разные по смыслу слова, поэтому в любом случае нет выбора — только "и" и "й".
Вы мерками какого языка меряете и на каком его историческом этапе? )
Возьмите русский текст начала 20-го века — обнаружите столько странных и удивительных слов. Текст 300-400 летней давности Вы без перевода на современный язык чаще всего не сможете понять.
А что говорить про слова и словообразование почти тысячелетней давности от которых даже в письменности почти следов не осталось?
Похожие требования — похожая инфраструктура.
Но ошибки — всё-равно не исключения ))
На один уровень наверх, а не "кто его знает куда" наверх.
С необходимостью на этом уровне тоже принять решение что делать с ошибкой.
Потому что система — это одно, а пользовательские эксперименты — это другое.
Точно так же при разработке на других языках — что там у себя ставят разработчики — никак не влияет на работу системы в целом. А когда доставляется конечный продукт — он запаковывается по всем правилам.
В той же Gentoo ничто не мешает сосуществовать системно устанавливаемому rustc, которым собираются различные пакеты, и пользовательскому, устанавливаемому через rustup, в который пользователь может наустанавливать не нужных в системе компонентов, возможно весьма "экспериментальных", не говоря уже о том, что не тестировавшихся на совместимость.
То же касается и библиотек. Многие библиотеки доступны в комплекте дистрибутива, но зачастую они там совсем не той версии, что нужна разработчику и поддержка нескольких установленных версий — далеко не всегда имеется. Поэтому библиотеки тянутся в проект в обход пакетных менеджеров, и хорошо, если у языка есть свой пакетный менеджер для этого.
Отлично зайдёт для многих задач, но в какой-то момент можно внезапно споткнуться о GIL и будет очень обидно, поскольку по остальным параметрам всё очень классно, а решить задачу так же красиво, как на Python, на чём-то другом будет достаточно нетривиально.
Например, будет большая модель данных, часть обработки/доставки этих данных придётся сделать на уровне Python, поскольку низкоуровневые библиотеки, умеющие работать параллельно в несколько потоков, именно такую обработку сделать не могут, и придётся искать решение вопросов в духе "где взять больше памяти" и "как эффективно синхронизировать между процессами большие объёмы данных".
То, что человек совершает ошибки — вполне нормально.
Раст — язык с дополнительным контролем корректности программы.
Компилятор берёт на себя себя проверку декларируемых намерений и реального их выполнения. То есть, человек гараздо чаще сталкивается с ними не "когда-то потом", а непосредственно на этапе компиляции.
С помощью комплиятора и линтера постепенно вырабатывается навык писать сразу правильно и в соответствии с хорошим стилем. То, на что на самом деле в других языках уходят годы практики и что зависит от культуры написания кода в команде, если программисту повезло оказаться в хорошей команде.
Использовать Rust как дополнительный язык для ускорения узких мест — на самом деле тоже хорошее применение и важная ниша, в которой практически нет конкуренции. Да и глупо рассчитывать на то, что все разом забросят языки, изучению которых посвятили годы, и внезапно займутся переписыванием работающих проектов на новый язык с нуля (что может быть просто экономически нецелесообразно, даже когда язык действительно лучше по многим параметрам).
К комментарию выше я бы добавил, что есть два варианта: Вы заранее знаете всё множество операций, оно статично и не будет меняться по ходу дела (и тогда enum дёшево и надёжно решает задачу), либо Вы заранее не знаете, оно будет зависеть от пользователя Вашей библиотеки или ещё как-то динамически изменяться (тогда Ваш подход с трейт-объектами, хоть он и дороже, — лучше решает задачу).
К слову сказать, в Расте есть замыкания (которые "под сахаром" на самом деле тоже структуры).
Вот уж не обессудьте, но судя по комментариям к этой статье, подобное описание поведения значительно больше подходит к некоторым сторонникам С++. Безапелляционные заявления "С++ божественен, проблем вообще нет, их выдумали недоброжелатели, Rust/Swift/___(нужное вписать) — не нужен". Не это ли описанный выше фанатизм?
Наверно можно написать, но остаётся много открытых вопросов и компромисов. Например, если это фоновый процесс, то значит у нас есть какая-то задержка на использование памяти. Есть какие-то приоритеты исполнения, канал обмена данными с памятью тоже не резиновый и при большом числе ядер в системе может оказываться узким местом.
И главный вопрос в любом случае сведётся к цене, и ответ однозначно будет не "бесплатно". Но так же пока никуда не делись системы с одним ядром и с малым количеством памяти.
Но, если можно дешевле, а Rust показывает, что можно, то зачем платить больше? Но для этого поддержка такого уровня контроля должна быть на уровне языка и придётся чем-то жертвовать — например, дополнительно декларировать зависимости памяти в виде "времён жизни" (или ещё как-то). Многие, как оказалось, к этому не готовы, это "сложно", что при этом не мешает утверждать, что они способны всё то же самое удерживать в голове. Этот самообман, увы, мешает многим принять новую концепцию, которая вполне возможно прижилась бы и в других языках, несмотря на "тяжёлое наследие".
Скорость можно бенчмаркать и однозначно утверждать, что здесь регрессия.
С безопасностью всё не так определённо, хотя инструменты тоже вроде бы есть.
Утечки памяти (и других ресурсов) — это немного другая проблема, не касающаяся memory safety как таковой.
Народ минусует, но стесняется объяснить почему предложенное плохо.
"Фоновый поток" — это необохдимость синхронизации доступа к памяти в рантайме (что убивает саму идею большого числа ядер) и прочие неприятные вещи, вроде потери эффективности процессорных кешей. На этом фоне "инициализировать непосредственно перед использоавнием" выглядит сильно дешевле.
"Переписали" — всё же громко сказано, это был PoC операционной системы на Rust, сделанный с нуля и после этого уже несколько раз переписанный с пониманием "как делать не надо". Изначально Redox позиционировался как игрушечный проект и на вопрос "это замена Linux?" авторы давали определённый отрицательный ответ.
«внезапный рост бинарника в несколько раз от того, что в очередной ночной сборке что-то поломали или поменяли — бывает»
… необходимо было повысить стабильность ....
«Звучит весомо, не значит ничего».
Кхм, какие-то взаимоисключающие параграфы™.
Вопрос как раз об этом, зачем нужен статанализ, результаты которого могут быть проигнорированы? Что этот статанализ вообще тогда даёт? :-)
Если они используются для статического анализа, в чём смысл их проверять в рантайме? Если после статического анализа приходится проверять в рантайме, в чём смысл такого "статического" анализа?
Однако с обратной стороны звёздочки, можно уточнить, что реализация на итераторах с замыканиями часто оказывается даже немного быстрее, чем аналогичный код в императивном стиле.
После ООП языков с Rust достаточно тяжело. Привычные приёмы не работают, попытки писать в привычном стиле ведут к достаточно кривому и некрасивому коду. С Rust нужно переучиваться. Но, когда понимаешь, как здесь правильно писать, всё становится на порядок проще, код становится лаконичен, прекращается борьба с компилятором и вместо соперника он становится другом и на самом деле очень мощным инструментом, берущим на себя массу рутинной работы.
На самом деле это не совсем так. Реализации, сделанные в трейтах — вполне наследуются, но это не то наследование к которому Вы могли привыкнуть в других языках.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2015&gist=f187e1d7dc3c6e9290c63558c25bd7d3
Запись
B: A, выглядит несомненно как наследование, но, несмотря на сходство — это не оно. Это декларация ограничения — типажBможет быть реализован только для тех типов, для которых реализован типажA. Соответственно типажBможет расчитывать на методы типажаA, но он не находится в привилегированном положении наследника (и таких типажей может быть реализовано несколько для одного типа), он не переопределяет реализации из другого типажа, а при вызове без уточнения, какую реализацию мы желаем вызвать, компилятор закономерно удивится. Привычное интуитивное "наследование" здесь не работает, хотя вначале кажется — вот оно, и пытаешься строить наследование на типажах :-)В качестве замены наследованию всё же предлагается другая фича — специализация, которая выглядит уже ближе по смыслу и местами она очень нужна. Однако она ещё не стабилизирована и это долгая история.
Добавлю к вышесказанному, что с одной стороны, элементы ООП всё же есть — со структурами можно работать как с объектами, типажи можно наследовать и даже есть типаж-объекты, но с другой стороны, отсутствие классов и наследования структур данных — это фича языка, введённая с целью избежать негативных практик ООП, в том числе чрезмерно разрастающихся иерархий классов, которые становится впоследствии дорого поддерживать и развивать. И на примере достаточно крупных проектов можно сказать, что это достаточно продуктивная модель.
Вообще, Rust — это очередной гибрид функционального и объектного подходов, с существенным перевесом в пользу функционального, но без возведения его в абсолют. Однако история о том, какой будет ООП сторона Rust, ещё не завершена, и соответствующие фичи и RFC потихоньку пилятся и эволюционируют.