Комментарии 11
Хотя в целом статья любопытна, автор находится в некотором заблуждении насчёт совершенно нового класса.
Да даже не столько в заблуждении, сколько можно охарактеризовать это словом "зажрались". Вам дают базовые принципы, очень простые и легко формализуемые (это важно для компилятора), показывают, как всем этим пользоваться и какие плюсы вы получаете. А в ответ брюзжание "гамно, многабукв, непанятна". Да вашу ж за ногу!
Да, сложность обучения немного возросла.Не получится теперь всюду пихать указатели на указатели, не имея представления, какой указатель какие полномочия над объектом имеет. Ну так это не недостаток языка, а лень его изучения.
Проще говоря, компилятор Rust говорит нам, что до тех пор, пока lexeme доступна в этом блоке кода, он не позволит нам изменить self.state – другую часть парсера. Но это вообще бессмысленно!
По этой фразе сразу видно, что автор не разобрался с новой концепцией. Да, неочевидно (опять же, смотря для кого. Уверен, поработав с rust-ом достаточно времени такие вещи станут очевидными), но раз компилятору не нравится, значит, смысл есть. И ведь потом автор его находит.
Так что пост о непривычных для программиста на традиционных императивных языках особенностях, а никак не о "побочных эффектах".
Вы привели интересное сравнение в конце — а можете привести примеры не императивных языков в которых нужно следить за памятью а-ля rust?
Все программирование построено на том, что мы строим абстракции в терминах в которых легче рассуждать. Иногда при этом что-то теряется. В сравнении с C++, rust, конечно, намного лучше — проблема управления памяти есть в обоих языках, но rust ее намного лучше решает.
Но в сравнении с альтернативным решением проблемы управления памятью — gc, подход rust-а, будь он хоть прекрасно контролируемым, создает значительно большую нагрузку на мозг. Так что "традиционных императивных языках особенностях" стоит заменить на "языки с gc", к которым, например, относятся многие функциональные языки.
Все программирование построено на том, что мы строим абстракции в терминах в которых легче рассуждать. Иногда при этом что-то теряется. В сравнении с C++, rust, конечно, намного лучше — проблема управления памяти есть в обоих языках, но rust ее намного лучше решает.
Но в сравнении с альтернативным решением проблемы управления памятью — gc, подход rust-а, будь он хоть прекрасно контролируемым, создает значительно большую нагрузку на мозг. Так что "традиционных императивных языках особенностях" стоит заменить на "языки с gc", к которым, например, относятся многие функциональные языки.
GC не решает проблему управления ресурсами в общем случае, а только управление памятью. В той же Java слежение за открытыми файлами или, например, соединениями с БД создает огромную нагрузку на мозг, потому что нет никаких инструментов для гарантированного автоматического освобождения кроме finally.
Да и "утечку памяти" в языке с GC устроить не так сложно, например в стандартной библиотеке Java для этого есть замечательная функция File.deleteOnExit :)
Да и "утечку памяти" в языке с GC устроить не так сложно, например в стандартной библиотеке Java для этого есть замечательная функция File.deleteOnExit :)
Что-то я совсем не понимаю вашего комментария. Какое сравнение? Чего с чем? И где я что-то говорил про управление памятью?
Ну про память можно только из фразы
хоть как-то вывести, хотя я не имел ввиду именно память. С тем же успехом эту фразу можно применить файлу, сокету, соединению. к БД, да вообще к чему угодно, что можно закрыть, разрушить или провести другие необратимые действия, после которых пользоваться объектом нельзя. Понимание, через какую переменную (она же указатель в общем смысле — как указывающая на объект) мы можем делать такие опасные вещи здорово облегчает написание и сопровождение системы. И rust предлагает для этого отличную концепцию! Один владелец. Четко обозначенные границы полномочий — когда что можно делать, чтобы всем было безопасно. Настройка иерархии владения через время жизни — ссылаемся ли мы на объект, как холоп, или полностью подчиняем его своейзлой воле?
Наоборот, мне показалось, что многое делается намного легче, когда четко знаешь, кто за что отвечает. Другое дело, что разбирать синтаксис структур и методов порой тяжело. Особенно, если смотреть на уже готовый результат, а не идти к нему по шагам. Но что поделать. Такова цена zero-const абстракций и гибкости в одном лице.
GC тут совершенно не причем. В C/C++/Pascal проблем, описанных автором, не возникнет. Там даже в голову не придет, что метод consume_lexeme чем-то может быть опасен. А в rust это реальность. Конечно, в данном случае компилятор ошибается. Но компилятор не ИИ, он не может знать, что здесь все безопасно. У него жесткий набор правил. В этом случае было ложное срабатывание. Но знаете, в математической статистике существуют такие понятия, как ошибки первого и второго рада. Минимизируя одну неизбежно увеличиваем другую. Также и здесь — борясь с одним, вылезло другое, не совсем очевидное и желательное свойство, но это меньшее зло. К тому же, автор быстро нашел, как его обойти. А это и показывает живучесть концепции. В целом, сумма зол уменьшилась.
Тут можно еще провести аналогию с неизменяемыми переменными. Думаю, сейчас уже большинство понимает, что неизменяемость по умолчанию лучше, чем изменяемость. Все новые языки следуют этой концепции. Она банально проще. И для человека, и для компилятора.
GC, кстати, тоже всего лишь перераспределяет эту сумму зол, и я даже думаю, что также уменьшает ее. Писать проще, да, но это иллюзия. Когда встают проблемы с производительносью, то уже часто приходится всячески бороться с GC, чтобы он не начинал непредсказуемо влиять на программу — делать тонкий тюнинг, вставлять в код костыли и хаки, которые, к тому же, будут еще и на конкретный GC завязаны, скорее всего. Приятного мало.
Почему я сказал "традиционных императивных языках особенностях"? Потому что знаю только императивные, а у меня нет привычки рассуждать о том, о чем я не знаю. В большинстве случаев это выглядит глупо.
Ну про память можно только из фразы
Не получится теперь всюду пихать указатели на указатели, не имея представления, какой указатель какие полномочия над объектом имеет.
хоть как-то вывести, хотя я не имел ввиду именно память. С тем же успехом эту фразу можно применить файлу, сокету, соединению. к БД, да вообще к чему угодно, что можно закрыть, разрушить или провести другие необратимые действия, после которых пользоваться объектом нельзя. Понимание, через какую переменную (она же указатель в общем смысле — как указывающая на объект) мы можем делать такие опасные вещи здорово облегчает написание и сопровождение системы. И rust предлагает для этого отличную концепцию! Один владелец. Четко обозначенные границы полномочий — когда что можно делать, чтобы всем было безопасно. Настройка иерархии владения через время жизни — ссылаемся ли мы на объект, как холоп, или полностью подчиняем его своей
Но в сравнении с альтернативным решением проблемы управления памятью — gc, подход rust-а, будь он хоть прекрасно контролируемым, создает значительно большую нагрузку на мозг.
Наоборот, мне показалось, что многое делается намного легче, когда четко знаешь, кто за что отвечает. Другое дело, что разбирать синтаксис структур и методов порой тяжело. Особенно, если смотреть на уже готовый результат, а не идти к нему по шагам. Но что поделать. Такова цена zero-const абстракций и гибкости в одном лице.
GC тут совершенно не причем. В C/C++/Pascal проблем, описанных автором, не возникнет. Там даже в голову не придет, что метод consume_lexeme чем-то может быть опасен. А в rust это реальность. Конечно, в данном случае компилятор ошибается. Но компилятор не ИИ, он не может знать, что здесь все безопасно. У него жесткий набор правил. В этом случае было ложное срабатывание. Но знаете, в математической статистике существуют такие понятия, как ошибки первого и второго рада. Минимизируя одну неизбежно увеличиваем другую. Также и здесь — борясь с одним, вылезло другое, не совсем очевидное и желательное свойство, но это меньшее зло. К тому же, автор быстро нашел, как его обойти. А это и показывает живучесть концепции. В целом, сумма зол уменьшилась.
Тут можно еще провести аналогию с неизменяемыми переменными. Думаю, сейчас уже большинство понимает, что неизменяемость по умолчанию лучше, чем изменяемость. Все новые языки следуют этой концепции. Она банально проще. И для человека, и для компилятора.
GC, кстати, тоже всего лишь перераспределяет эту сумму зол, и я даже думаю, что также уменьшает ее. Писать проще, да, но это иллюзия. Когда встают проблемы с производительносью, то уже часто приходится всячески бороться с GC, чтобы он не начинал непредсказуемо влиять на программу — делать тонкий тюнинг, вставлять в код костыли и хаки, которые, к тому же, будут еще и на конкретный GC завязаны, скорее всего. Приятного мало.
Почему я сказал "традиционных императивных языках особенностях"? Потому что знаю только императивные, а у меня нет привычки рассуждать о том, о чем я не знаю. В большинстве случаев это выглядит глупо.
Избавится или снизить потребность в GC полезна. Такие попытки делались в Mercury. Еще была версия ML.
Пожалуйста, называйте Rust — Растом, а не Рустом, уж очень коробит.
Как по мне оф документация слегка хромает. После прочтения остается какая-то каша в голове. С одной стороны там пытаются объяснить все чуть ли не на пальцах, с другой стороны остается ощущение неполноты изложения. После прочтения Lifetimes, захотелось закрыть доку и больше не открывать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему владение/заимствование в Rust такое сложное?