LINUX.ORG.RU

История изменений

Исправление forCe, (текущая версия) :

Отсутствие исключений уже существенный минус. Это все еще стандарт по обработке ошибок в отрасли. В Си их нет, да. Но это скорее проблема, чем преимущество, хотя и оправдано отсутствием платы в рантайме. Но у rust'а рантайм все-равно на уровне крестов, как я понимаю. Или я ошибаюсь?

Отсутствие прямой поддержки ОО-моделирования, которое так же по-прежнему является стандартом в отрасли. Разбивать все на интерфейсную часть и реализацию не слишком удобно, да и читается такой разрозненный код хуже, чем код цельного класса. И самое интересное, что этот отказ от «классического» ООП непонятно чем мотивирован. Тут даже вопрос производительности не задействован.

Дженерики слабее шаблонов, а на макросах код писать сложнее, чем на шаблонах. А если кресты таки обзаведутся концептами, текущее преимущество rust по указания ограничений испарится.

Синтаксис таки вызывает недоумение. И у достаточно большого числа людей. Лайфтаймы в явном виде - издевательство над программистом, их должен выводить компилятор самостоятельно, по крайней мере в подавляющем числе случаев. Код читать и правда тяжело. Нет разделения управления памятью, управлением временем жизни и непосредственной логикой программы. Даже в С++ довольно просто замести под ковер все низкоуровневые ошметки, выставив наружу относительно приличный интерфейс. Тут с этим сложнее.

Хотя по факту мне не хватает опыта работы с Rust...

Но тут какое дело... Когда я после проекта на крестах, работаю с Python, например, или Scala, то это практически отдых на фоне C++. Когда же я пытаюсь использовать Rust, то... Мне даже хочется вернуться на кресты. Это как-то нездорово. Неприятно, когда приходится себя заставлять что-то изучать(не совсем верное слово, новых концепций в Rust для меня нет). Пока надеюсь, что дело во мне.

Опять же, на работе имею возможность использовать Rust и навязать его другим, но совесть не позволяет. Пока даже сам себе не могу доказать хоть какую-то пользу от него. Удивительно, но для Go задачу можно спокойно найти и аргументировано обосновать его применения...

Исходная версия forCe, :

Отсутствие исключений уже существенный минус. Это все еще стандарт по обработке ошибок в отрасли. В Си их нет, да. Но это скорее проблема, чем преимущество, хотя и оправдано отсутствием платы в рантайме. Но у rust'а рантайм все-равно на уровне крестов, как я понимаю. Или я ошибаюсь?

Отсутствие прямой поддержки ОО-моделирования, которое так же по-прежнему является стандартом в отрасли. Разбивать все на интерфейсную часть и реализацию не слишком удобно, да и читается такой разрозненный код хуже, чем код цельного класса. И самое интересное, что этот отказ от «классического» ООП непонятно чем мотивирован. Тут даже вопрос производительности не задействован.

Дженерики слабее шаблонов, а на макросах код писать сложнее, чем на шаблонах. А если кресты таки обзаведутся концептами, текущее преимущество rust по указания ограничений испариться.

Синтаксис таки вызывает недоумение и у достаточно большого числа людей. Лайфтаймы в явном виде - издевательство над программистом, их должен выводить компилятор самостоятельно, по крайней мере в подавляющем числе случаев. Код читать и правда тяжело. Нет разделения управления памятью, управлением временем жизни и непосредственной логикой программы. Даже в С++ довольно просто замести под ковер все низкоуровневые ошметки, выставив наружу относительно приличный интерфейс. Тут с этим сложнее.

Хотя по факту мне не хватает опыта работы с Rust...

Но тут какое дело... Когда я после проекта на крестах, работаю с Python, например, или Scala, то это практически отдых на фоне C++. Когда же я пытаюсь использовать Rust, то... Мне даже хочется вернуться на кресты. Это как-то нездорово. Неприятно, когда приходится себя заставлять что-то изучать. Пока надеюсь, что дело во мне.

Опять же, на работе имею возможность использовать Rust и навязать его другим, но совесть не позволяет. Пока даже сам себе не могу доказать хоть какую-то пользу от него. Даже для Go задачу можно спокойно найти и аргументировано обосновать его применения...