Rust 1.7

Как-то не возникает проблем с памятью

Начинает надоедать говорить очевидные вещи. Проблемы с памятью могут проявляться как угодно или не проявляться вообще, пока определенные входные данные не поступят. Как можно быть уверенным, что проблем с памятью нет, если язык не гарантирует этого?

Непонятная ошибка в модуле, пропавшая после рефакторинга. Что это было? Баг модуля или повреждение структур данных, вызванное неверной работой с памятью в совершенно другом модуле?

Логические ошибки вызывают предсказуемые последствия. последствия ошибок работы с памятью зависят от слишком многих факторов, поэтому намного сложнее соотнести их с конкретным багом. Естественно, приятнее думать, что ты совершаешь только логические ошибки, хотя язык не защищает ни от тех ни от других.

Может поспорим на $1000, что в амазоновском коде в течение 2-х лет будут найдены эксплойты, связанные с ошибками работы с памятью? По крайней мере будет ясно, насколько вы уверены в непогрешимости команды программистов амазона и контрибьюторов.

Мнение двухдневного регистранта-анонимуса - верх авторитета.

Как можно быть уверенным, что проблем с памятью нет, если язык не гарантирует этого?

Знать воинские уставы правила проектирования и руководствоваться ими в повседневной жизни.

Непонятная ошибка в модуле, пропавшая после

Должны пропадать только по одной причине: установлена и устранена причина.

До того, как причина установлена изменения в код не вносятся.

рефакторинга.

не нужен.

Баг модуля или повреждение структур данных, вызванное неверной работой с памятью в совершенно другом модуле?

Устанавливается в тестами модулей и интеграционным тестированием.

Логические ошибки вызывают предсказуемые последствия.

Не всегда, ой не всегда!

Естественно, приятнее думать, что ты совершаешь только логические ошибки, хотя язык не защищает ни от тех ни от других.

Кому приятнее, тот пусть думает.

Как можно быть уверенным, что проблем с памятью нет, если язык не гарантирует этого?

Знать правила проектирования и руководствоваться ими в повседневной жизни.

Ты. Это. Серьезно?

Знать правила проектирования и руководствоваться ими в повседневной жизни.

Как это поможет с

std::copy( v1.begin(), v2.end(), v2.begin() );

или чем-то более сложным.

Баг модуля или повреждение структур данных, вызванное неверной работой с памятью в совершенно другом модуле?

Устанавливается в тестами модулей и интеграционным тестированием.

Fuzzy-тестирование не от хорошей жизни появилось. У людей как-то плохо с подбором тест-кейсов. В интеграционном тестировании fuzzing тоже можно применять, но эффективность значительно ниже из-за большей размерности входных данных.

Да, С++ вполне можно применять, с проверкой статическими анализаторами, директивным отрезанием особенно окаменелого наследия С и С++98, и прочими мерами предосторожности, особенно в модели распространения ПО «as is» с отказом от ответственности. Но иногда хочется и надежности.

Естественно, приятнее думать, что ты совершаешь только логические ошибки, хотя язык не защищает ни от тех ни от других.

Кому приятнее, тот пусть думает.

AddressSanitizer, CheckPointer или SoftBound применяли, чтобы знать, а не думать?

рефакторинга.

не нужен.

Встретить супермена большая редкость. Приятно познакомиться. Значит структуру программы определяете на этапе проектирования с учетом всех будущих изменений в ТЗ. Про use-after-free, iterator invalidation, data races, dangling pointers, buffer overflows даже и не вспоминаете за ненадобностью. Перепишите уж тогда наконец OpenSSL.

Ладно. Толку от этого спора никакого. Последнее слово за вами.

Да.

Любые отступления от них приводят к косякам, яркий пример - моя быдлокод-клоунада в этом ИТТ треде.

Как можно быть уверенным, что проблем с памятью нет, если язык не гарантирует этого?

Знать правила проектирования и руководствоваться ими в повседневной жизни.

Ты. Это. Серьезно?

Да.
Любые отступления от них приводят к косякам, яркий пример - моя быдлокод-клоунада в этом ИТТ треде.

Ты понимаешь, что _нельзя_ рассчитывать на то, что люди будут соблюдать правила?

Как это поможет с

Поможет правильная реализация std::copy, не?

AddressSanitizer, CheckPointer, SoftBound

Есть не везде. То, что runtime, тормозит.

Встретить супермена большая редкость.

Их там нет!(с)

MISRA С и прочие стандарты для кого придумали?

Про use-after-free, iterator invalidation, data races, dangling pointers, buffer overflows даже и не вспоминаете за ненадобностью.

В рантайме - почти нет (переполнения стека иногда случаются), до этого - постоянно имею в виду.

Последнее слово за вами.

Ура! Я последний запостил.

Ну, как показывает пример Раста, их таки можно заставить :) Методы, конечно, адовы, но прецедент создан ;)

Ну, как показывает пример Раста, их таки можно заставить :)

Есть небольшая такая разница - в случае Rust правила соблюдает компилятор, а не люди.

Rust является системным языком программирования

какая система на нем написана ?

какая система на нем написана ?

Почитай определение системного программирования - системы не обязательно писать на языке системного программирования.

Но если речь об ОС, то Redox и Reenix. Если о прочем системном софте: https://www.reddit.com/r/programming/comments/3w8dgn/announcing_rust_15/cxucr...

не нужен.

Почему?

Но иногда хочется и надежности.

Смотря что понимать под надежностью. Программа на Java, которая на старте выжрала всю память, убила этим самым остальные процессы (с помощью OOM-killer), подвесила систему и запорола данные - надежная? Программа на Rust, которая в середине процесса конвертирования данных вылетела с паникой, - надежная? Программа на Python, которая отказывается сохранить твой проект из-за ошибки в коде - надежная? Скрипт на bash, который случайно удалил рекурсивно все файлы на разделе (и история знает такие примеры) - надежный? Конечно, ошибки при работе с памятью очень неприятны и своим поведением и последствиями, но надежность это совокупность отсутствия всех ошибок. И тут помогут либо дисциплина и тестирование, либо ничего.

Но если речь об ОС, то Redox и Reenix

никогда о них не слышал так что вряд ли кому-то они нужны

Если о прочем системном софте:

какие-то костылечки наколенные, опять же кому они нужны кроме узкого круга ржавых ананистов ?

никогда о них не слышал

Да ты вообще не производишь впечатления знающего или грамотного человека.

какие-то костылечки наколенные, опять же кому они нужны кроме узкого круга ржавых ананистов ?

Зайди в Dropbox и расскажи им, что на самом деле им нужно и не нужно.

И тут помогут либо дисциплина и тестирование, либо ничего.

Ну вот Rust и обеспечивает часть дисциплины. Что не так?

Есть небольшая такая разница - в случае Rust правила соблюдает компилятор, а не люди.

Нет, в случае Rust правила соблюдают люди, а компилятор карает человеков за несоблюдение правил.

Да ты вообще не производишь впечатления знающего или грамотного человека.

ты тоже - покажи хоть один сервер/десктоп/смартфон/планшет который продается с этими ОС

Зайди в Dropbox и расскажи им, что на самом деле им нужно и ненужно

пусть напишут офисный софт или CAD-систему - может посмотрю, а так - кому нужен этот ссаный Dropbox

Да ты вообще не производишь впечатления знающего или грамотного человека.

ты тоже

Мне очень важно твое мнение.

пусть напишут офисный софт или CAD-систему - может посмотрю

Им тоже очень важно твое мнение.

Почему?

https://refactoring.guru/ru/catalog

Мне очень важно твое мнение.
Им тоже очень важно твое мнение.

т.е. факты налицо - пустая болтовня и наколенные поделки для самоудовлетворения (мастурбация).

т.е. факты налицо - пустая болтовня и наколенные поделки для самоудовлетворения (мастурбация).

Dropbox зарабатывает деньги. А вот ты да, пытаешься получить самоудовлетворение, унижая результаты чужого труда.

Можешь не отвечать, флуд на этом заканчиваем.

Dropbox зарабатывает деньги

он и без Rust их зарабатыал

флуд на этом заканчиваем

это было вообще-то для тебя

www.linux.org.ru/add_comment.jsp?topic=12393941&replyto=12410091

но ты продолжай - не останавливайся, популярный ресурс без клоунов не популярен

Ну вот Rust и обеспечивает часть дисциплины. Что не так?

Все так, я это только приветствую. Единственное, что мне не нравится сам Rust, тут я согласен с Александреску:

Safe, deterministic memory reclamation is a hard problem, but is not the only problem or even the most important problem in a program. Therefore Rust ends up expending a disproportionately large language design real estate on this one matter.

Потому пока пробую Swift, который во многом пересекается в Rust, но ИМХО больше, лучше и проще.

Александреску, ИМХО, ошибается или сознательно передргивает здесь. Rust не сильно заботится о memory reclamation (ЕМНИП, есть известные способы спровоцировать утечку), он заботится о memory safety, но об этом заботится ни разу не disproportionally.

Покажи хоть один сервер/десктоп/смартфон/планшет который продается с FreeBSD.

Покажи хоть один сервер/десктоп/смартфон/планшет который продается с FreeRTOS

Вообще не понимаю всех воплей на счет того, что якобы Rust помешан на memory safety и то, что это превращает жизнь программиста в ад борьбы против компилятора. Типичные неосиляторы.

Rust не сильно заботится о memory reclamation

Он вообще мало о чем заботится. Вот я тупой пользователь, ничего не знаю про Swift, но практически сходу могу написать:

class Node { 
    var key: Int
    var left: Node? 
    var right: Node?
    
    init(value: Int) {
        key = value
    }
}

let n = Node(value: 100)
n.left.key = 1

Это похоже на то, что я писал раньше на уютненьких Java/C++/PHP. Это ругнется на n.left и заставит добавить проверку. Это не вылетит в сегфолт, если я тупо добавлю !, чтоб забить на проверку. Это не выглядит как говно. А если я попробую это же написать на Rust?

Вообще не понимаю всех воплей на счет того, что якобы Rust помешан на memory safety и то, что это превращает жизнь программиста в ад борьбы против компилятора. Типичные неосиляторы.

Я написал код выше, приведи аналог на Rust.

Rust не сильно заботится о memory reclamation

Он вообще мало о чем заботится

Если Rust не заботится о том, что важно тебе - ты знаешь, где взять PHP^WSwift.

Это не выглядит как говно.

А по-моему, именно так оно и выглядит.

Это похоже на то, что я писал раньше на уютненьких Java/C++/PHP

Не знаком с PHP, но на Си++ и Java это не похоже. Откуда взялось значение n.left.key?

А если я попробую это же написать на Rust?

(пожимая плечами) Попробуй - узнаешь.

Если Rust не заботится о том, что важно тебе - ты знаешь, где взять PHP^WSwift.

Ну да, всего-лишь опциональные значения, да кому они нужны в Rust?! Их никогда же там не используют.

А по-моему, именно так оно и выглядит.

Нет, так выглядит аналог на Rust:

struct Tree<'a> {
    l: Option<&'a Tree<'a>>,
    r: Option<&'a Tree<'a>>,
    i: i32
}

Плюс добавить impl с теми же закорючками.

Не знаком с PHP, но на Си++ и Java это не похоже. Откуда взялось значение n.left.key?

Значит ты не знаком и с Java и С++. Там доступ к публичным членам класса так же делается через ".".

Нет, так выглядит аналог на Rust:

Или даже так:

struct Node<'a> {
    val: &'a str,
    l: Option<Box<Node<'a>>>,
    r: Option<Box<Node<'a>>>,
}

Не знаком с PHP, но на Си++ и Java это не похоже. Откуда взялось значение n.left.key?

Значит ты не знаком и с Java и С++.

Доо.

Не знаком с PHP, но на Си++ и Java это не похоже. Откуда взялось значение n.left.key?

Там доступ к публичным членам класса так же делается через ".".

Ты не понял вопроса. Я не спрашивал, что такое «n.left.key», я спрашивал, откуда взялось значение Node, на которое указывает left, и полю которого ты присвоил значение.

Повторяйте эту мантру три раза в день и C++ будет обходить вас стороной.

Вам не нравиться C++ - не пишите на нем. Какие проблемы? Зачем ныть на форуме?

я спрашивал, откуда взялось значение Node, на которое указывает left, и полю которого ты присвоил значение.

class Node { 
    var key: Int
    var left: Node? 
    var right: Node?
    
    init(value: Int = 0 ) {
        key = value
    }
}

let n = Node()
n.left = Node()
print( n.left!.key )

Опять же просто и интуитивно.

Ага, это вылетит в непонятную ошибку компилятора.

-target x86_64-apple-macosx10.9 -enable-objc-interop -sdk /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -O -module-name main -- -o /var/folders/mq/sxspn0v179z03ljffqzb7vk00000gn/T/./run-swift.rMkQ8HSY 
./run-swift: line 18: 87599 Illegal instruction: 4  gtimeout -k $TIMEOUT_KILL_AFTER $TIMEOUT_DURATION $SWIFT_COMPILER -target $TARGET -sdk $SDK $OPTIMIZATION_LEVEL $INPUT_FILE -o $OUTPUT_FILE

./run-swift: line 18: 87788 Segmentation fault: 11  gtimeout -k $TIMEOUT_KILL_AFTER $TIMEOUT_DURATION $SWIFT_COMPILER -target $TARGET -sdk $SDK $OPTIMIZATION_LEVEL $INPUT_FILE -o $OUTPUT_FILE

Опять же просто и интуитивно.

А, то есть ты запостил неправильный код... говоришь, он у тебя не падал?

struct Node {
    key: i32,
    left: Option<Box<Node>>,
    right: Option<Box<Node>>
}
impl Node {
    fn init(value: i32) -> Node {
        Node {
            key: value,
            left: None,
            right: None
        }
    }
}

fn main() {
    let n = Node::init(100);
    // n.left.key = 1;
}

Но если хотим аналогичное по производительности, то обмазываемся кучей и атомарными счетчиками:

use std::sync::Arc;
struct Node {
    key: Arc<Box<i32>>,
    left: Option<Arc<Box<Node>>>,
    right: Option<Arc<Box<Node>>>
}
impl Node {
    fn init(value: i32) -> Node {
        Node {
            key: Arc::new(Box::new(value)),
            left: None,
            right: None
        }
    }
}

fn main() {
    let n = Arc::new(Box::new(Node::init(100)));
    // n.left.key = 1;
}

Ага, это вылетит в непонятную ошибку компилятора.

Я не знаю как у тебя это получилось, но:

 error: value of optional type 'Node?' not unwrapped; did you mean to use '!' or '?'?
n.left.key = 1
  ^

Но если хотим аналогичное по производительности, то обмазываемся кучей и атомарными счетчиками:

Думаю, оно будет медленнее.

Но если хотим аналогичное по производительности, то обмазываемся кучей и атомарными счетчиками:

И тут вопрос к tailgunner, если код на Swift для тебя выглядит как говно, то что можно сказать про этот код на Rust? Все норм, так и надо?

А, то есть ты запостил неправильный код... говоришь, он у тебя не падал?

«Это ругнется на n.left и заставит добавить проверку» - просто кто-то не прочитал описание к нему.

Для сравнения ошибки rust'ового компилятора.

<anon>:18:5: 18:15 error: attempted access of field `key` on type `core::option::Option<Box<Node>>`, but no field with that name was found
<anon>:18     n.left.key = 1;
              ^~~~~~~~~~
error: aborting due to previous error

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', ../src/libcore/option.rs:330

<anon>:18:14: 18:15 error: mismatched types:
 expected `core::option::Option<Box<Node>>`,
    found `_`
(expected enum `core::option::Option`,
    found integral variable) [E0308]
<anon>:18     n.left = 1;
                       ^

что можно сказать про этот код на Rust? Все норм, так и надо?

Для начала, я не уверен, что это вообще нужно было писать, чтобы посоревноваться со Swift - Box всяко будет быстрее, потому что ему не нужен refcounting. Ну и я бы вообще не выписывал все эти вложенные шаблоны:

type OptBox<T> = Option<Box<T>>;

struct Node {
    key: i32,
    left: OptBox<Node>,
    right: OptBox<Node>,
}

аналогично и с Arc.

Просто ты сравниваешь с Swift курильщика:

 error: value of optional type 'Node?' not unwrapped; did you mean to use '!' or '?'?
n.left.key = 1
  ^

Error running code: 
fatal error: unexpectedly found nil while unwrapping an Optional value
[/code

«Это ругнется на n.left и заставит добавить проверку» - просто кто-то не прочитал описание к нему.

Ну и? Добавишь проверку - он у тебя не упадет?

Ну и? Добавишь проверку - он у тебя не упадет?

Тут поведение аналогично Rust. Или мы разворачиваем с альтернативным значением, или сразу вылетаем с паникой, что значения то и нет (unwrap в Rust).

А если я попробую это же написать на Rust?

Примерно то же и получится.

play.rust-lang.org http://is.gd/HPzqqz