Обновить

Комментарии 14

Не серчайте, но озадачивает идея статьи. Rust - язык с довольно уникальным способом обращения с памятью. В то же время Go использует максимально широко распространённый способ (с небольшими нюансами). Если цель была показать чем интересен и хорош Rust, это лучше было писать "Rust vs All" (подразумевая все прочие языки с автоматическим управлением памятью или как это лучше сказать). А так если придёт почитать человек с бэкграундом в Java или C++ то по этой статье он вынужден будет 60% времени погружаться в детали организации памяти в Go и пытаться понять нужны ему эти детали или нет.

А так написано в достаточно технически подробно, конечно.

Я пишу на Go и эта статья вышла после того, как для себя разбирался как работает Rust.

Показать что раст лучше или хуже цели у меня не было.

Тут нет каких то тяжёлых деталей, я никого не вынуждаю никуда погружаться. Статья обзорная, на хабр я ее закинул ради интереса, так как изначально писал ее не для хабра. Ожидаемо, учитывая ру комьюнити, не зашло :)

Не знаю с чего вы решили, что при выделении слайса arr := make([]byte, 100) сама память выделится отложено. Можно написать функцию, которая в цикле генерирует мусор, типа

func trash() {
  for i := 0; i < 10000; i++ {
    _ = make([]byte, 100)
  }
}

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

Вы там что то про ИИ писали, до того как отредактировали - так вот ИИ я не пользуюсь, хватает своего опыта.

А в целом спасибо за замечание, пример к описанию того, как работает ленивое выделение - некорректный, поправлю.

Вероятно вы перепутали добавление элемента через append.

Честно, тоже показалось, что текст написан GPT. В первую очередь потому что очень многие детали, что про Go, что про Rust, что про программы в целом, написаны неверно или с очень большими допущениями.

fn main() {
    let r;
    {
        let x = 5;
        r = &x; // ошибка: x живет меньше, чем r
    }
    println!("{}", r);
}

Походу вы не поняли Rust, ошибка будет на попытке распечатать r

Запустите и проверьте сами.

Ошибка будет при компиляции, программа не соберётся и запускать будет нечего.

Убрал строчку с макросом и нормально скомпилировались, намекает что есть неиспользуемое, но бинарничек дал

Да вообще что тут обсуждать если r иммутубельная, а вы про время жизни...

Вот попробуйте

fn main() {
    let mut r;
    {
        let x = 5;
        r = &x; // ошибка: x живет меньше, чем r
    }
    r = &7;
    println!("{r}");
}

Собирается за силу душу, не смотря на вашу ошибку, эту строчку не тронул, таким приемом вполне можно пользоваться, чтобы ограничить тип r ссылкой на что-то

"Да вообще что тут обсуждать если r иммутубельная, а вы про время жизни..." - время жизни вроде проверяется раньше, чем мутабельность? Т.е. сначала "разберитесь со временем жизни", а потом с "иммутабельностью"?

Тоже ощущение, что без ИИ не обошлось в написании

Возможно я ошибаюсь, но, насколько помню, Go на стеке размещает не только примитивные типы. Структура тоже может быть на стеке, если не возвращать указатель на созданную внутри функции структуру.

А стэк go ещё и не лежит на стэке thread а вполне себе обитает в heap. Хотя по результатам прочтения статьи может показаться что это одни и те же стэки.

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации