Мифы про читаемость С кода уже устарели. Читать код - это не только понимать что делает данная строка или функция, но и что НЕ делает. И в примитивной системе типов С, выразить второе практически не возможно. Читая код на Раст, за редким исключением, сигнатуры функций и типов, благодаря сильной системы типов точно и однозначно говорят программисту как это использовать, кто чем владеет, потоко-безопасно ли это, какие ошибки возвращает и т.п. В этом и есть сила Раста - в системе типов и гарантиях.
Python это второй по значимости/используемости(после С++) язык в индустрии кинопроизводства и геймдева.
Во всех студиях мира львиная доля пайплайна написана на удаве и все крупные dcc ( digital content creation ) такие как Maya, Houdini, Nuke, Katana, Blender и другие имеют интегрированный Python интерпретатор. Да медленный, да динамический(со всеми вытекающими) но отлично подходит для автоматизации и в качестве «клея» между элементами пайплайна.
Так что даже если он будет вытеснен из бэкенда (а он будет), в производстве медиа-контента он прочно засел навсегда.
будет паника, которая может закрашить всю программу. Это не только ужасно с точки зрения пользователя, но также не помогает в понимании и отладке прпроблемы.
Для пользователя может и да, но найти причину такого краша с RUST_BACKTRACE=1 секундное дело. И конечно же grep unsafe|unwrap|except
это может маскировать ошибки, скрывать баги, делать ваш код менее читабельным, приводить к непредсказуемому поведению и снижению производительности
Маскировать ошибки и баги? Вы о чём? Объясните пожалуйста как паника "скрывает" баги? Что непредсказуемого в панике? Почему снижается производитель? (пример с unwrap() в hot loop не берём)
Ошибки нужно обрабатывать, это верно, но то что вы написали в статье не соответствует действительности.
Упоминание двусвязных списков в Rust уже не смешно, Вы случаем не преподаватель информатики из ВУЗа? Нафиг они не нужны в 99% задач, а когда нужны, можно взять библиотеку или написать на сырых указателях.
Практически всё что вы перечислили - это просто результат того что 30 лет не было достойных альтернатив, а задачи нужно было решать. Конечно за столько времени чего только не напишут.
А в чём их умность тогда? Они не достаточно умные чтобы не обнуляться или перестать быть валидными после std::move.
Всё что они делают в С++ это RAII но не гарантируют безопасной работы с указателями (но всё же лучше чем сырые указатели конечно)
Указатели в С++ тоже могут стать не валидными (dangling references)
Потому что бесплатный.
А ещё там написано
To date, there have been zero memory safety vulnerabilities discovered in Android's Rust code.
Неплохо так для 1.5 млн строк кода?
Мифы про читаемость С кода уже устарели. Читать код - это не только понимать что делает данная строка или функция, но и что НЕ делает. И в примитивной системе типов С, выразить второе практически не возможно. Читая код на Раст, за редким исключением, сигнатуры функций и типов, благодаря сильной системы типов точно и однозначно говорят программисту как это использовать, кто чем владеет, потоко-безопасно ли это, какие ошибки возвращает и т.п. В этом и есть сила Раста - в системе типов и гарантиях.
Python это второй по значимости/используемости(после С++) язык в индустрии кинопроизводства и геймдева.
Во всех студиях мира львиная доля пайплайна написана на удаве и все крупные dcc ( digital content creation ) такие как Maya, Houdini, Nuke, Katana, Blender и другие имеют интегрированный Python интерпретатор. Да медленный, да динамический(со всеми вытекающими) но отлично подходит для автоматизации и в качестве «клея» между элементами пайплайна.
Так что даже если он будет вытеснен из бэкенда (а он будет), в производстве медиа-контента он прочно засел навсегда.
Для пользователя может и да, но найти причину такого краша с RUST_BACKTRACE=1 секундное дело. И конечно же grep unsafe|unwrap|except
Маскировать ошибки и баги? Вы о чём? Объясните пожалуйста как паника "скрывает" баги? Что непредсказуемого в панике? Почему снижается производитель? (пример с unwrap() в hot loop не берём)
Ошибки нужно обрабатывать, это верно, но то что вы написали в статье не соответствует действительности.
Упоминание двусвязных списков в Rust уже не смешно, Вы случаем не преподаватель информатики из ВУЗа? Нафиг они не нужны в 99% задач, а когда нужны, можно взять библиотеку или написать на сырых указателях.
Практически всё что вы перечислили - это просто результат того что 30 лет не было достойных альтернатив, а задачи нужно было решать. Конечно за столько времени чего только не напишут.