The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Релиз языка программирования Rust 1.20"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Релиз языка программирования Rust 1.20"  +/
Сообщение от opennews (??) on 01-Сен-17, 12:41 
Доступен (https://blog.rust-lang.org/2017/08/31/Rust-1.20.html) релиз языка программирования Rust 1.20 (http://www.rust-lang.org), развиваемого проектом Mozilla, обеспечивающего автоматическое управление памятью и предоставляющего средства для высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime. Параллельно с Rust совместно с компанией Samsung развивается экспериментальный браузерный движок Servo (https://www.opennet.ru/opennews/art.shtml?num=44712), написанный (https://github.com/servo/servo/) на языке Rust и отличающийся поддержкой многопоточного рендеринга web-страниц и распараллеливанием операций с DOM (Document Object Model).  На Rust также разрабатывается (https://www.opennet.ru/opennews/art.shtml?num=46459) операционная система Redox (https://www.redox-os.org/), использующая концепцию экзоядра и продвигающая принцип "все есть URL".

В подготовке нового выпуска приняли участие 118 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/master/RELEASES.md):


-  В дополнение к ранее доступной поддержке ассоциированных функций (функции, привязанные непосредственно к типу) в новом выпуске реализована возможность создавать ассоциированные константы (https://github.com/rust-lang/rfcs/blob/master/text/0195-asso...). Например, в примере ниже константа ID  прикреплена к типу Struct:


   struct Struct;
   impl Struct {
       const ID: u32 = 0;
   }
   fn main() {
       println!("the ID of Struct is: {}", Struct::ID);
   }

Ассоциированные константы также могут быть использованы с типажами (https://ru.wikipedia.org/wiki/%D0%A2%D0%...(%D0%B0%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%82%D0%BD%D1%8B%D0%B9_%D1%82%D0%B8%D0%BF)) (traits) и перечислениями (enum), при этом для типажей допускается определение ассоциированных констант без непосредственного присвоения значения (значение может быть присвоено во время привязки типажа):


   trait Trait {
       const ID: u32;
   }
   struct Struct;

   imp Trait for Struct {
       const ID: u32 = 5;
   }
   fn main() {
       println!("{}", Struct::ID);
   }

-  В разряд стабильных переведена новая порция (https://github.com/rust-lang/rust/blob/master/RELEASES.md)  функций и методов, в том числе CString::as_c_str, Chain::get_ref,
    Take::get_ref, f32/64::from_bits, f32/64::to_bits,     slice::sort_unstable_*, str::as_bytes_mut, str::get_mut,    str::get_* и т.п.

-  В макросе "unimplemented!" обеспечена возможность определения сообщений, информирующих что именно пока не реализовано;

-  Поддержка Unicode обновлена до версии спецификации 10.0.0;

-  Реализация функций min и max для типов с плавающей запятой переписана на языке Rust и больше не связана с cmath;

-  Обеспечена дополнительная защита от атаки Stack Сlash (https://www.opennet.ru/opennews/art.shtml?num=46724), в результате которой содержимое переполненной кучи может оказаться в области стека или, наоборот, стек может переписать область кучи;

-  В стандартной библиотеке представлены новые функции нестабильной сортировки: slice::sort_unstable_by_key, slice::sort_unstable_by и slice::sort_unstable, которые отличаются от стабильных тем, что работают быстрее, но не гарантируют сохранение порядка следования элементов в группе;

-  Существенно увеличена (https://github.com/rust-lang/rust/pull/42533) скорость (до 29 раз) раскрытия макроподстановок в процессе работы компилятора rustc;
-  В пакетном менеджере Cargo хранение параметров аутентификации к crates.io перенесено из общего файла с настройками ~/.cargo/config, который часто доступен на чтение всем пользователям, в специальный файл  ~/.cargo/credentials;

-  В Cargo обеспечена сборка бинарных файлов main.rs, размещённых в подкаталогах src/bin, например, на базе src/bin/server/main.rs и src/bin/client/main.rs  будут сгенерированы исполняемые файлы target/debug/server и target/debug/client;

-  Добавлена возможность указания версии устанавливаемого исполняемого файла при указании опции "--vers" в "cargo install";

-  Добавлена новая целевая сборочная платформа wasm32-experimental-emscripten, позволяющая организовать сборку в псевдокод WebAssembly  при помощи бэкенда на базе LLVM.

Напомним, что язык Rust сфокусирован на безопасной работе с памятью и обеспечении высокого параллелизма выполнения заданий. При этом Rust обходится без использования сборщика мусора или runtime, что делает возможным создания на Rust библиотек, которые могут выступать в роли прозрачной замены библиотекам для языка Си. Для распространения библиотек на языке  Rust, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo (http://blog.rust-lang.org/2014/11/20/Cargo.html), позволяющий получить нужные для программы библиотеки  в один клик. Для размещения библиотек введён в строй репозиторий crates.io (https://crates.io/).

По структуре язык  Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики. Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Rust поддерживает смесь императивных, процедурных и объектно-ориентированных методов с такими парадигмами, как функциональное программирование, обобщённое программирование и метапрограммирование, в статических и динамических стилях.

URL: https://blog.rust-lang.org/2017/08/31/Rust-1.20.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=47113

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения по теме [Сортировка по времени | RSS]


1. "Релиз языка программирования Rust 1.20"  –20 +/
Сообщение от Аноним (??) on 01-Сен-17, 12:41 
чего только не придумают, лишь бы не писать на си-89.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

10. "Релиз языка программирования Rust 1.20"  +9 +/
Сообщение от A.Stahl (ok) on 01-Сен-17, 13:38 
89?
Ты точно знаешь как выглядит код на С89? Даже во времена борландовского турбо-си все смеялись над С89.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

28. "Релиз языка программирования Rust 1.20"  +3 +/
Сообщение от dq0s4y71 (ok) on 01-Сен-17, 16:39 
Ты сам, похоже, не знаешь, как выглядит код на С89. На нём, вообще-то, чуть менее чем полностью ядро написано. А смеялись вы, наверное, над K&R C. Ну и к слову, Турбо си появился когда никакого С89 ещё в помине не было.
Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

33. "Релиз языка программирования Rust 1.20"  +6 +/
Сообщение от Ordu email(ok) on 01-Сен-17, 17:41 
> На нём, вообще-то, чуть менее чем полностью ядро написано.

Это в том смысле, что если попытаться его скомпилировать с --std=c99, то компилятор будет ругаться менее чем на 5% строк? С тем же успехом можно для любой C'шной программы и любого C'шного стандарта начиная с K&R, сказать, что эта программа написана чуть менее чем полностью в рамках выбранного стандарта.

В ядре, мы видим, например, множество inline функций, мы видим, например, активное использование членов структур с неопределённым размером, то есть что-то в стиле:
    struct dynarr {
        size_t size;
        uint8_t data[];
    }

Ядро активно использует фичи C99, и поэтому не надо натягивать сову на глобус и заявлять, что оно "чуть менее чем полностью написано на C89".

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

38. "Релиз языка программирования Rust 1.20"  +/
Сообщение от dq0s4y71 (ok) on 01-Сен-17, 18:32 
> Это в том смысле, что если попытаться его скомпилировать с --std=c99, то
> компилятор будет ругаться менее чем на 5% строк? С тем же
> успехом можно для любой C'шной программы и любого C'шного стандарта начиная
> с K&R, сказать, что эта программа написана чуть менее чем полностью
> в рамках выбранного стандарта.

Чот не понял. Если взять любой стандарт и написать в нём программу, то она будет написана в этом стандарте чуть менее чем полностью, не вопрос :) Или ты хочешь сказать, что каждый предыдущий стандарт является подмножеством следующего?

> В ядре, мы видим, например, множество inline функций, мы видим, например, активное
> использование членов структур с неопределённым размером, то есть что-то в стиле:
>     struct dynarr {
>         size_t size;
>         uint8_t data[];
>     }

Тогда это расширения GNU были. -std=gnu89 называется.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

43. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Ordu email(ok) on 01-Сен-17, 19:10 
>> Это в том смысле, что если попытаться его скомпилировать с --std=c99, то
>> компилятор будет ругаться менее чем на 5% строк? С тем же
>> успехом можно для любой C'шной программы и любого C'шного стандарта начиная
>> с K&R, сказать, что эта программа написана чуть менее чем полностью
>> в рамках выбранного стандарта.
> Чот не понял. Если взять любой стандарт и написать в нём программу,
> то она будет написана в этом стандарте чуть менее чем полностью,
> не вопрос :) Или ты хочешь сказать, что каждый предыдущий стандарт
> является подмножеством следующего?

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

>> В ядре, мы видим, например, множество inline функций, мы видим, например, активное
>> использование членов структур с неопределённым размером, то есть что-то в стиле:
>>     struct dynarr {
>>         size_t size;
>>         uint8_t data[];
>>     }
> Тогда это расширения GNU были. -std=gnu89 называется.

Так мы говорим о C89 или о GNU89? Мне казалось, что о первом, не?

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

51. "Релиз языка программирования Rust 1.20"  +/
Сообщение от dq0s4y71 (ok) on 01-Сен-17, 19:38 
> Я хочу сказать, что фраза "чуть менее чем полностью" по отношению к
> стандарту звучит очень неопределённо. Я предложил выше один из способов формализовать
> и проверить, и заявляю, что этот способ любую программу на C
> сможет отнести к любому стандарту. Это не значит, что твои слова
> бессмысленны вообще, но они бессмысленн без уточнения, что именно ты имеешь
> в виду под "чуть менее чем полностью".

Ну ок, неудачно выразился. Я чо хотел сказать. Там чел выше пишет, типа, ты не знаешь, как С89 выглядит. А он выглядит как подавляющее большинство сишного кода, в т.ч. ядро. Редко когда С99 или K&R в исходниках встречаются.

> Так мы говорим о C89 или о GNU89? Мне казалось, что о
> первом, не?

Так GNU89 и есть C89 + расширения ГНУ. Эти расширения потом в стандарт перешли.

Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

58. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Ordu email(ok) on 01-Сен-17, 20:27 
>> Я хочу сказать, что фраза "чуть менее чем полностью" по отношению к
>> стандарту звучит очень неопределённо. Я предложил выше один из способов формализовать
>> и проверить, и заявляю, что этот способ любую программу на C
>> сможет отнести к любому стандарту. Это не значит, что твои слова
>> бессмысленны вообще, но они бессмысленн без уточнения, что именно ты имеешь
>> в виду под "чуть менее чем полностью".
> Ну ок, неудачно выразился. Я чо хотел сказать. Там чел выше пишет,
> типа, ты не знаешь, как С89 выглядит. А он выглядит как
> подавляющее большинство сишного кода, в т.ч. ядро. Редко когда С99 или
> K&R в исходниках встречаются.

В ядре постоянно. Ты полистай хидеры. Не, ну ты прикинь, как писать на C без inline функций? Макросами их оформлять? Так и делали. Загляни в документацию к ncurses, где про 9 функций из 10 написано, что они могут быть макросами. Альтернатива -- писать вручную каждый раз.

Где-то в ядре я видел функцию типа memcpy, что ли, которая заточена на размеры областей памяти до 32 и константное значение для размера, и которая вся из себя inline, что сделано с мыслью о том, что компилятор заинлайнит код, развернёт циклы, и оптимизирует прочь параметр размера массива. В C++ такие штуки делаются через темплиты с целочисленным параметром, в C99 только вот таким вот образом, с надеждой на то, что пользователь этой функции будет понимать, что аргумент size должен быть вычислим на этапе компиляции, в C89 это сделать можно разве что заморочным макросом. То есть в C89 никто в здравом уме не будет заниматься такими оптимизациями, либо вручную скопирует, либо вызовет библиотечную универсальную реализацию memcpy.
Это разные стили написания программ, это разные стили проектирования API.

>> Так мы говорим о C89 или о GNU89? Мне казалось, что о
>> первом, не?
> Так GNU89 и есть C89 + расширения ГНУ. Эти расширения потом в
> стандарт перешли.

C89+расширения ГНУ -- это уже не C89. Это можно называть соответствием стандарту gnu89, можно называть соответствием c89+gnu-extensions, но называть это соответствием c89, значит, натягивать сову на глобус.

Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

68. "Релиз языка программирования Rust 1.20"  +/
Сообщение от dq0s4y71 (??) on 01-Сен-17, 22:03 
> Не, ну ты прикинь, как писать на C без inline функций? Макросами их оформлять? Так и делали.

Я не делал. Те С89-компиляторы, которыми я пользовался, всегда поддерживали какие-нибудь расширения, и там был inline в каком-нибудь виде, __inline или там #pragma inline...

> C89+расширения ГНУ -- это уже не C89. Это можно называть соответствием стандарту gnu89, можно называть соответствием c89+gnu-extensions, но называть это соответствием c89, значит, натягивать сову на глобус.

Ради бога. Я о том, что все видели, как выглядит С89, но не все об этом знают.

Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

77. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Ordu email(ok) on 01-Сен-17, 22:38 
Угу. После чего мы заглядываем в код ncurses и видим как выглядит код на c89. Без использования десятка макросов даже функцию объявить невозможно.
Ответить | Правка | ^ к родителю #68 | Наверх | Cообщить модератору

87. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Аноним (??) on 02-Сен-17, 13:07 
Это ж до чего же гoвнокод там, раз уж такие проблемы.
Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

89. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от лютый жабист__ on 02-Сен-17, 16:37 
dq0s4y71, я вижу, ты гуру не только в жабке, но и в сях 8)))
Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

91. "Релиз языка программирования Rust 1.20"  +3 +/
Сообщение от Аноним (??) on 02-Сен-17, 16:46 
> dq0s4y71, я вижу, ты гуру не только в жабке, но и в сях 8)))

Указателем, маллоком, фри и интринсиком, заклинаю:
изыди, зелененький!


Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

49. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Аноним (??) on 01-Сен-17, 19:34 
> Ядро активно использует фичи C99

Ядро использует gnu89/gnu90 без всяких "активно"/"пассивно".

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

52. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Ordu email(ok) on 01-Сен-17, 20:14 
>> Ядро активно использует фичи C99
> Ядро использует gnu89/gnu90 без всяких "активно"/"пассивно".

Ага. То есть ядро не написано в рамках стандарта C89, так?

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

34. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от anonimbl on 01-Сен-17, 17:44 
Очевидно, что он не знает. Это же просто клоун, который срет в комментах под каждым постом.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

45. "Релиз языка программирования Rust 1.20"  +/
Сообщение от НяшМяш (ok) on 01-Сен-17, 19:21 
Хотя казалось бы, уже вроде 1 сентября...
Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

61. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Аноним (??) on 01-Сен-17, 20:58 
>> как выглядит код на С89. На нём, вообще-то, чуть менее чем полностью ядро написано

В ядре почти каждый драйвер использует инициализацию полей структур по-умолчанию, что появилось только в 99

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

23. "Релиз языка программирования Rust 1.20"  +6 +/
Сообщение от Крутой аноним on 01-Сен-17, 15:20 
> чего только не придумают, лишь бы не писать на си-89.

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

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

63. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 21:02 
> чего только не придумают, лишь бы не писать на си-89.

Особенно, говоря о С89, современные разработчики "любят" декларировать все переменные сразу после начала функции... как в Паскале....

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

3. "Релиз языка программирования Rust 1.20"  –11 +/
Сообщение от Аноним (??) on 01-Сен-17, 12:53 
> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем

Зато создаёт проблемы с производительностью.

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

6. "Релиз языка программирования Rust 1.20"  +7 +/
Сообщение от Аноним (??) on 01-Сен-17, 13:07 
>> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем
> Зато создаёт проблемы с производительностью.

Что-то не сильно видно: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...
Кстати, растовское "автоматическое" управление памятью немного не то, что под этим понимают в других ЯП.


Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "Релиз языка программирования Rust 1.20"  –6 +/
Сообщение от Аноним (??) on 01-Сен-17, 13:46 
По этой ссылке нет никаких тестов с управлением памятью.
Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

15. "Релиз языка программирования Rust 1.20"  +5 +/
Сообщение от Аноним (??) on 01-Сен-17, 14:38 
> По этой ссылке нет никаких тестов с управлением памятью.

Т.е. вы туда не ходили?
Да и, как я понимаю, ничего конкретного насчет "создавания проблем с производительностью" мы не увидим?

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

64. "Релиз языка программирования Rust 1.20"  –2 +/
Сообщение от Аноним (??) on 01-Сен-17, 21:23 
> Что-то не сильно видно

А вы поближе к монитору подсядьте.

На одном тесте ржавый потребляет на 20% меньше памяти, чем C++, ещё на одном примерно столько же, ещё на четырёх на 50-80% больше, и ещё на 5 тестах - в 2-20 раз больше. При этом работает сравнимое время (кроме теста, где выигрывает 20%, - там и работает в 6 раз быстрее).

Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

67. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 21:57 
>>>> Автоматическое управление памятью избавляет разработчика
>>> Зато создаёт проблемы с производительностью.
>> Что-то не сильно видно
> А вы поближе к монитору подсядьте.
> На одном тесте ржавый потребляет на 20% меньше памяти,
> кроме теста, где выигрывает 20%, - там и работает в 6 раз быстрее
> где выигрывает 20%, - там и работает в 6 раз быстрее

Вы бы тоже подсели и прочитали внимательно, на что решили отвечать.
Производительность и потребление памяти - разные вещи (только не надо начинать про взаимосвязь и трейдоффы, конкретно тут ее, в идеальном случае, не должно быть).
А уж
> где выигрывает 20%, - там и работает в 6 раз быстрее

противоречит чуть более чем полностью гордому заявлению того самого анонимуса.

Ответить | Правка | ^ к родителю #64 | Наверх | Cообщить модератору

70. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 22:11 
> Производительность и потребление памяти - разные вещи

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

Ответить | Правка | ^ к родителю #67 | Наверх | Cообщить модератору

16. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Илья (??) on 01-Сен-17, 14:43 
Как? Это же не GC или подсчет ссылок.
Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

24. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Крутой аноним on 01-Сен-17, 15:21 
>> Автоматическое управление памятью избавляет разработчика от манипулирования указателями и защищает от проблем
> Зато создаёт проблемы с производительностью.

И какие проблемы? Это ведь не GC.

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

41. "Релиз языка программирования Rust 1.20"  –3 +/
Сообщение от Аноним (??) on 01-Сен-17, 18:59 
Подсчёт ссылок в рантайме.
Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

47. "Релиз языка программирования Rust 1.20"  +4 +/
Сообщение от Аноним (??) on 01-Сен-17, 19:23 
> Подсчёт ссылок в рантайме.

Вот! Экспертный тезка зрит в самый корень! Заморочки с временем жизни, владениями и прочим - для отвода глаз и накручивания ЧСВ, а на самом деле унутрях там неонка^W ссылки в рантайме считают! И как его только на ардуинах или в качестве ядра ОС использовать заставляют?

Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

59. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от 123 (??) on 01-Сен-17, 20:47 
>>Заморочки с временем жизни, владениями и прочим

Зачем, если есть тупо область видимости и нет глобальных указателей? Счетчик ссылок на пару порядков  быстрее CG.  

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

71. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Ordu email(ok) on 01-Сен-17, 22:13 
> Счетчик ссылок на пару порядков  быстрее CG.

Неа. Во-первых, даже полностью статическое управление памятью не на порядки быстрее сборщика мусора. Наверное можно создать искусственную ситуацию, когда разница будет достигать порядка, но достичь этой ситуации в реальном проекте со сборщиком будет не так просто. Особенно если избегать её. При этом довольно сложно сравнивать сборщик мусора со статическим управлением памятью, потому что тут всё сильно-сильно зависит от того, чем именно программа занимается и как она это делает. Но тем не менее, ждать что сборка мусора замедлит программу хотя бы на порядок -- это ждать слишком многого. Я удивлюсь, если она замедлит хотя бы в два раза.

Во-вторых, счётчик ссылок -- это существенно не бесплатная абстракция: элементарная передача указателя из одного места в другое требует разадресации указателя и кеш-промахов для того чтобы изменить значение счётчика ссылок. Это может дать такие пенальти к производительности, что счётчик ссылок покажется раем.

Лет двадцать назад счётчики ссылок выглядели очень неплохо. Но все эти двадцать лет память по скорости отставала от процессоров всё дальше и дальше. И скорость процессора и частота памяти растут экспоненциально, но там в основании экспоненты стоят разные значения. Поэтому разница в скорости тоже растёт экспоненциально по времени. Я -- увы -- ссылку найти не могу с красивыми графиками и пояснениями, но ты можешь попробовать поверить мне на слово.

Сегодня речь идёт о том, что все структуры данных, типа списков, деревьев, и прочие способы размазывания данных ровным слоем по куче -- это не вариант для производительной программы. Скажем, лет десять назад народ ещё радостно прыгал, при словах "красно-чёрное дерево", и втирал что это гораздо лучше хеш-таблички. Сегодня фонтаны восхищения иссякли -- нужен быстрый ассоциативный массив? значит хеш-табличка, всё остальное имеет разве что академическое значение в рамках курса "история структур данных XX века". Хотя может для программирования микроконтроллеров эти знания ещё могут пригодиться.

Динамический массив оказывается быстрее списка даже несмотря на стоимость операции insert, просто потому что он меньше греет кеш. То есть если размер массива увеличивать в бесконечность, то с определённой точки начиная список окажется быстрее, но если массив влезает в килобайт, то он будет быстрее списка на операции insert. Особенно если перелопатить алгоритмы и постараться избегать insert/remove произвольных позиций, например, заменяя это чем-нибудь типа swap_remove или позволяя массиву иметь "дыры" и иногда дефрагментируя его. Зато список будет невыносимо медленнее массива при итерации по элементам.

Сборщик мусора тоже занимается тем, что "трогает" всю память доступную по указателям, засирая таким образом кеши, но он это делает несколько иначе. Даже ещё интереснее, сборщик мусора может работать на разных алгоритмах и эти разные алгоритмы могут быть более или менее удачны для разных ситуаций. Даже более того, он может менять стратегию в рантайме, скажем, затачиваясь на меньшие latency в программе, когда есть свободное ядро для сборщика мусора, и на максимальный throughput, когда программа отжирает 100% процессорного времени, сглаживая таким образом пиковые нагрузки. Кроме того, работа сборщика мусора может уменьшать количество кеш-промахов в основном коде программы. Это уменьшение может происходить уже за счёт того, что память менее фрагментирована, но если сборщик мусора написан с мыслью о том, чтобы снижать количество кеш-промахов, то он не просто дефрагментирует память, он может из списка сделать массив, в том смысле, что для программы список будет именно списком, но в памяти элементы будут лежать последовательно, прямо как в массиве.

Короче, если зачем-то нужны счётчики ссылок и без них никак, то лучше подумать о языке с GC, нежели писать на C, C++, Rust и тому подобных языках.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

73. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 22:18 
Как расписал, прям можно подумать, что сборщик мусора — это альтернатива подсчёту ссылок.
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

82. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Ordu email(ok) on 02-Сен-17, 00:08 
> Как расписал, прям можно подумать, что сборщик мусора — это альтернатива подсчёту
> ссылок.
> можно подумать

Не можно, а нужно. Не обязательно выбирать именно эту альтернативу, но подумать нужно. Потому что если ты отказываешься от сборки мусора не подумав, то это нельзя называть выбором, это скорее предопределённость.

Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

117. "Релиз языка программирования Rust 1.20"  –2 +/
Сообщение от Аноним (??) on 07-Сен-17, 09:37 
Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти уже совсем нет, а вот очень прям сейчас надо. Сборщик мусора порождает тормоза в любой непредсказуемый момент времени для тяжелых приложений.
Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

118. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Аноним (??) on 07-Сен-17, 16:10 
> Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти
> уже совсем нет, а вот очень прям сейчас надо.

А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?
> Сборщик мусора порождает тормоза в любой непредсказуемый момент

Еще один недоклоун, мнящий себя тонким знатоком и ценителем?


Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

120. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Аноним (??) on 08-Сен-17, 08:17 
> А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?

в том то и дело, что память есть

> Еще один недоклоун, мнящий себя тонким знатоком и ценителем?

Высоконагруженное на java когда-либо писали?

Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

121. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 08-Сен-17, 17:42 
>>> освободит пару гигов когда памяти уже совсем нет
>> А в ручную, когда кончилась память, ты делаешь волевым усилимем free(random)?
> в том то и дело, что память есть

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

>> Еще один недоклоун, мнящий себя тонким знатоком и ценителем?
> Высоконагруженное на java когда-либо писали?

Еще раз, для ценителей - алгоритмов GC вагон и маленькая тележка. Копирующий, у которого могут быть проблемы с освобождением блоков при нехватке памяти и которому требуется приостановить "мир" - только один из них.
Причем, часть таких проблем может вылезать и в ручном аллокаторе. Их разновидностей тоже более 1 будет.

Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

119. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Ordu email(ok) on 07-Сен-17, 18:30 
> Ну давай расскажи как быстро сборщик мусора освободит пару гигов когда памяти
> уже совсем нет, а вот очень прям сейчас надо.

Если у тебя кончилась память, то тебе уже ничто не поможет. Ни сборщик мусора, ни его отсутствие. Причём обсуждая абстрактную программу нельзя даже сказать, когда быстрее кончится память -- в случае со сборщиком мусора или без него. Отсутствие сборщика мусора может сильно фрагментировать память, и кончаться тем, что половина 16 гигов памяти свободна, но невозможно выделить килобайт последовательной памяти.

> Сборщик мусора порождает тормоза в любой непредсказуемый момент времени для
> тяжелых приложений.

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

Кроме того, что в твоём понимании "тяжёлое приложение"? Это то, которые активно работает с кучей, выделяя и освобождая, при этом выделяет куски памяти очень разных размеров (различающихся на несколько порядков) и куски памяти очень разной продолжительности жизни (опять же с разницей в несколько порядков)? Такой программе, даже если ей очень хочется real-time'а, я бы очень порекомендовал задуматься о том, как бы так адаптировать сборку мусора и использовать её. Иначе придётся покупать оперативки на порядок больше, чем будет пиковая сумма размеров объектов. Статическое управление памятью дефрагментирует кучу -- есть техники, которые позволяют снизить фрагментацию, но -- хыхы, -- чем навороченнее эти техники, тем дороже будет вызов free. Причём непредсказуемо дороже, то есть не удастся заранее предсказать сколько по времени будет выполняться free.

Ответить | Правка | ^ к родителю #117 | Наверх | Cообщить модератору

72. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 01-Сен-17, 22:16 
>>>Заморочки с временем жизни, владениями и прочим
> Зачем, если есть тупо область видимости и нет глобальных указателей?

Затем, что оперируя только областями видимости трудно будет передавать ссылочки на данные, а копирование для не примитивных типов будет заметным оверхедом.
Ну а совсем без передачи данных туда-сюда, в не совсем сферическом софте, будет несколько сложновато.

> Счетчик ссылок на пару порядков  быстрее CG.

Вообще-то, в общем случае - наоборот. Счетчик легче сделать, поведение предсказуемее, но зато есть постоянный оверхед на инкремент/декремент, что очень заметно на CPU-bound задачах.

Только вот в сабже основная фишка в том, что ни GC, ни счетчик по умолчанию не исользуется.
Можно угорать или возмущаться синтаксисом, отсутствием поддержки каких либо фич или кучей хипстоты, решивших, что это новая серебрянная пуля и нужно все переписать, но главное достижение раста уже есть - показать, что современный компилятор при некоторых ограничениях ЯП может вполне взять на себя отслеживание времени жизни и "кто сейчас владеет доступом на запись к этому куску данных" и все еще позволяет писать вполне реальный софт.


Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

74. "Релиз языка программирования Rust 1.20"  –2 +/
Сообщение от Аноним (??) on 01-Сен-17, 22:20 
>> Счетчик ссылок на пару порядков  быстрее CG.
> Вообще-то, в общем случае - наоборот. Счетчик легче сделать, поведение предсказуемее, но
> зато есть постоянный оверхед на инкремент/декремент, что очень заметно на CPU-bound
> задачах.

Ты как себе представляешь GC, работающий без подсчёта ссылок, умник? Откуда он будет узнавать, что мусор, а что — нет?

Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

75. "Релиз языка программирования Rust 1.20"  +5 +/
Сообщение от Аноним (??) on 01-Сен-17, 22:26 
> Ты как себе представляешь GC, работающий без подсчёта ссылок, умник? Откуда он
> будет узнавать, что мусор, а что — нет?

Яснопонятно ...
Я то думал, сегодня количество знатоков на опеннете поубавится, а оно вот как вышло.

Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

81. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Ordu email(ok) on 02-Сен-17, 00:04 
Ты б хотя бы википедию почитал сначала о том, что такое сборщик мусора, какие они бывают, и как они работают, прежде чем таким агрессивным тоном задавать вопросы.
Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

80. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от КО on 01-Сен-17, 23:03 
1. Подсчет ссылок - один из вариантов GC :)
2. Хорош на тестах a la helloworld, но в реальности коллекция недостатков типа:
   a) фрагментация памяти;
   b) операции со ссылками только через инвалидацию кеша (или иные методы синхронизации) - или прощай многозадачность;
   с) непредсказуемость времени выполнения операции (простенькое удаление ссылки может обернуться каскадом удалений);
   d) циклические ссылки сами не обнуляются.

Но идеальной системы, пока никто не придумал.

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

96. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 02-Сен-17, 21:33 
https://kgv.gitbooks.io/rust_book_ru/content/src/custom-allo...
Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

90. "Релиз языка программирования Rust 1.20"  –2 +/
Сообщение от лютый жабист__ on 02-Сен-17, 16:41 
> Зачем, если есть тупо область видимости и нет глобальных указателей? Счетчик ссылок
> на пару порядков  быстрее CG.

Экспертик ты мой сердешный, ничего, что GC по большей части работает в отдельных от основной программы потоках? :)

Кстати, счетчик ссылок дефрагментацию памяти делает? :)

Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

92. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 02-Сен-17, 16:53 
> Экспертик ты мой сердешный, ничего, что GC по большей части работает в
> отдельных от основной программы потоках? :)

Жабиный GC != единственная альтенратива счетчику.
> Кстати, счетчик ссылок дефрагментацию памяти делает? :)

А это-то причем? Как сделаешь, так и будет - можешь хоть маллок/фри обернуть, хоть еще что-то сваять. Естественно, с компактирующим GC оно в шарообразных бенчах и рядом не стояло, но в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается, да и нюансики у копирующих GC тоже есть.

Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

102. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от лютый жабист__ on 04-Сен-17, 07:08 
>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается

Щито?!

Создала прожка 1000 объектов по мегабайту. Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест прожка у могучего прогера, который "я жи осилил NEW и DELETE, а GC для лузеров".

Ответить | Правка | ^ к родителю #92 | Наверх | Cообщить модератору

104. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 04-Сен-17, 15:49 
>>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается
> Щито?!
> Создала прожка 1000 объектов по мегабайту.

Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?
> Потом каждый второй удалила.
> Потом надо
> создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест прожка
> у могучего прогера, который "я жи осилил NEW и DELETE, а
> GC для лузеров".

Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

107. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Очередной аноним on 05-Сен-17, 09:49 
> Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?

Блин, ну откуда такие люди берутся. Вроде бы всё очевидно. Даже кэпуочевидности стыдно такое разжёвывать:
А откуда ты ЗАРАНЕЕ знаешь что именно на 1000 мегабайт будет через пол-дня работы программы?  Или что всегда будут выделяться куски строго по одному мегабайту или кратно одному мегабайту? Ты экстрасенс? Прожка их создала не в один момент на старте, а в процессе работы как результат реакции на поступающие извне данные (недетерминированно поступающие). Ты не знаешь сколько именно там выделится памяти в процессе работы, например, из-за того, что не знаешь сколько клиентских запросов придет в твой сервис и каков размер данных тебе будет приходить с каждым запросом. Системы с менеджерами памяти без упаковывающих/перемещающих ранее выделенные области памяти механизмов вынуждены тащить кучки пулов памяти для разных по размеру данных, чтобы уменьшить фрагментацию, но и это не решает полностью проблему.

Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

111. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 05-Сен-17, 17:28 
>>> Создала прожка 1000 объектов по мегабайту. Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту. Расскажи сколько ОЗУ съест
>> Т.е. не общим куском на 1000 мегабайт, т.е. аж целы1 ГБ, а именно по мегабайту?
> Блин, ну откуда такие люди берутся. Вроде бы всё очевидно. Даже кэпуочевидности
> стыдно такое разжёвывать:
> А откуда ты ЗАРАНЕЕ знаешь что именно на 1000 мегабайт будет через
> пол-дня работы программы?  

Вам не угодишь.
У вас там случаем, не шиза? Или вы не помните, что сами же спрашивали? Или мне нужно было ткнуть вас носиком в сферо-вакуумность вашего же вопроса, на что я наверняка получил бы "так и скажи, что не осилил отверить!"?
> вынуждены тащить кучки пулов памяти для разных по размеру данных, чтобы уменьшить фрагментацию

Да ну, правда? А теперь почитайте, на что вы отвечали
>> в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается

и расскажите нам уже, причем тут ваши нелепые "срывы покровов".

Ответить | Правка | ^ к родителю #107 | Наверх | Cообщить модератору

105. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 04-Сен-17, 16:04 
>>в реальной жизни в 64 битном адресном пространстве дефрагментация пока вообще не ощущается
> Щито?!
> Создала прожка 1000 объектов по мегабайту.

Т.е. не общим куском на 1000 мегабайт, т.е. аж целый 1 ГБ, а именно по мегабайту?
> Потом каждый второй удалила. Потом надо создать 500 объектов по 1.1 мегабайту.

И в чем проблема? Как удалила, так и создала. Максимальный оверхед, помимо всяких мета-данных, зависит от аллокатора, но скорее всего будет +- размер страницы.
> Расскажи сколько ОЗУ съест прожка у могучего прогера,

Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное пространство и как оно взаимодействет с реальной "физической" памятью?
Хотя да, оно видно уже по ответу абсолютно не в тему.
Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы ноликами и к ним больше не обращались, то реальной памяти они займут 0 целых, 0 десятых (точнее, только метаинфа в ядре/аллокаторе).

> который "я жи осилил NEW и DELETE, а GC для лузеров".

А, так ты еще и не в курсе, что аллокаторы для аллокации больших кусков памяти обычно используют системные вызовы?


Ответить | Правка | ^ к родителю #102 | Наверх | Cообщить модератору

106. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от лютый жабист__ on 05-Сен-17, 05:36 
> Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное
> пространство и как оно взаимодействет с реальной "физической" памятью?
> Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а
> не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы
> ноликами и к ним больше не обращались, то реальной памяти они
> займут 0 целых, 0 десятых

Тут все школьники и запалились :) Во первых зааллокейтить все доступные 16TB можно легко и непринужденно за сутки активной работы прожки. Что потом, перезапускать сервис будешь? :)) Хотя очевидно, что это гогнокодинг, скорость работы с памятью будет очень несишная, а вы так любите рассуждать про скорость света 8))))) Дефрагментацию вы таки не делаете?

И напоследок, озвучь use case "проинициализованы ноликами и к ним больше не обращались", что твоя прожка делает, как называется? Наверное СферическиВакуумныйРазрывательЖабы? :)))

Ответить | Правка | ^ к родителю #105 | Наверх | Cообщить модератору

112. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 05-Сен-17, 17:44 
>> Т.е. ты, в лучших традицияж жабистов, не в курсе про виртуальную память/адресное
>> пространство и как оно взаимодействет с реальной "физической" памятью?
>> Приколись, если "объекты" (мы же о сишке и подобных, c зиро-кост-абстракциями, а
>> не о жабке с "5КБ рантайминфы на один пустой объект"?) проинициализованы
>> ноликами и к ним больше не обращались, то реальной памяти они
>> займут 0 целых, 0 десятых
> Тут все школьники и запалились :)
> Во первых зааллокейтить все доступные 16TB
> можно легко и непринужденно за сутки активной работы прожки.
> ... невнятный поток сознания

Класс! Сам что-то придумал, сам же опроверг, сам доволен!
А по теме что-то будет? Или хотя бы более связное, не подразумевающее у других наличия способности к мыслечтению? А то вначале сам же задал вопрос про "сколько ОЗУ будут занимать 1000 объектов", теперь вдруг уже 16 ТВ у него кем-то заалокейтены и только дефрагментация может спасти отца демократии ...

> Дефрагментацию вы таки не делаете?

Дефрагментацию ОЗУ делаем только сертифицированной утилитой, ага.
Марш читать "computer architecture for javaists".

Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

113. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от лютый жабист__ on 06-Сен-17, 05:54 
>"сколько ОЗУ будут занимать 1000 объектов"

Если твои прожки работают по 3 минуты и заключаются в "проинициализованы ноликами и к ним больше не обращались" и "создали 1000 объектов и поскорее выключились", то молодец, поздравляю, дефрагментация тебе не нужна. Можешь и дальше во всех ветках про раст, го и жабку квакать про мощь си.

Ответить | Правка | ^ к родителю #112 | Наверх | Cообщить модератору

114. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 06-Сен-17, 07:08 
>>"сколько ОЗУ будут занимать 1000 объектов"
> Если твои прожки работают по 3 минуты и заключаются в "проинициализованы ноликами
> и к ним больше не обращались" и "создали 1000 объектов и
> поскорее выключились", то молодец, поздравляю, дефрагментация тебе не нужна. Можешь и
> дальше во всех ветках про раст, го и жабку квакать про мощь си.

Т.е. Великий Дефрагментатор зафейлился на своем же примере и сказать ему хоть что-то осмысленное в тему нечего, но очень подгор^W хочется?
Почитал бы что ли, как работают современные аллокатры, что такое виртуальная память и как происходит взаимодействие с реальной ...


Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

115. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от лютый жабист__ on 06-Сен-17, 09:25 
https://en.wikipedia.org/wiki/Allocator_(C%2B%2B)

The default allocator uses operator new to allocate memory.[16] This is often implemented as a thin layer around the C heap allocation functions,[17] which are usually optimized for infrequent allocation of large memory blocks. This approach may work well with containers that mostly allocate large chunks of memory, like vector and deque.[15] However, for containers that require frequent allocations of small objects, such as map and list, using the default allocator is generally slow.[4][17] Other common problems with a malloc-based allocator include poor locality of reference,[4] and excessive memory fragmentation.

И дальше длинное описание как сделать крутой костыль, с буффером в котором хранить все не гигантские объекты. А то ой, сишечка тормозит.

Ответить | Правка | ^ к родителю #114 | Наверх | Cообщить модератору

116. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 06-Сен-17, 15:24 
> https://en.wikipedia.org/wiki/Allocator_(C%2B%2B)
> The default allocator uses operator new to allocate memory.[16]

Подразумевалось чтение и ПОНИМАНИЕ прочитанного.
> И дальше длинное описание как сделать крутой костыль, с буффером в котором хранить все не гигантские объекты

И то ли дело жабка, ведь там все работает с помощью магии!
А это наверное неправилная жабо-машина!
https://github.com/dmlloyd/openjdk/tree/e7f494fc8232d207b7c2...

Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

62. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Вареник on 01-Сен-17, 21:00 
> И как его только на ардуинах или в качестве ядра ОС использовать заставляют?

Заставляют??? Соболезнцую :)

Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

9. "Релиз языка программирования Rust 1.20"  +3 +/
Сообщение от Аноним (??) on 01-Сен-17, 13:33 
> увеличена скорость (до 29 раз)

Это, значит, так они его писали?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

29. "Релиз языка программирования Rust 1.20"  +5 +/
Сообщение от dq0s4y71 (ok) on 01-Сен-17, 16:45 
Нормально, чо. Make it Work, Make it Right, Make it Fast.
Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

46. "Релиз языка программирования Rust 1.20"  +/
Сообщение от НяшМяш (ok) on 01-Сен-17, 19:22 
Ну вообще-то это нормально - сначала писать, потом оптимизировать. Да и это на скорость компиляции влияет, а не на результирующий код, так что это неприятно, но не критично.
Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

17. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Аноним (??) on 01-Сен-17, 14:46 
Скажите, кто следит, оно по степени yпоротости уже перегнало кресты, или всё ещё только догоняет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Илья (??) on 01-Сен-17, 14:49 
Что для Вас является степенью упoротости? И что в таком случае "отстаёт"?
Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

20. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Аноним (??) on 01-Сен-17, 14:51 
Синтаксис через одно место
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

21. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Илья (??) on 01-Сен-17, 14:53 
А чем именно вам не нравится синтаксис rust ?
Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

30. "Релиз языка программирования Rust 1.20"  +/
Сообщение от dq0s4y71 (ok) on 01-Сен-17, 16:51 
6 операторов преобразования типа, например.
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

32. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Аноним (??) on 01-Сен-17, 17:28 
Степенью yпоротости для меня является избыточность возможностей (вроде тех же ассоциированных функций), создающая плодородную почву для написания совершенно нечитаемого кода. Отстаёт — в смысле туда уже запихали всё, что есть в C++, то есть примерно всё, что вообще встречается в разных языках программирования, или ещё не успели?
Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

35. "Релиз языка программирования Rust 1.20"  +5 +/
Сообщение от freehck email(ok) on 01-Сен-17, 17:58 
> Степенью yпоротости для меня является избыточность возможностей

Ну, ну... С такой логикой Вы скоро объявите Python вершиной эволюции языков программирования. :)

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

Вот на том же Perl пишут вполне удобочитаемые программы, не смотря на TIMTOWDI. Хотя почва для написания нечитаемого кода настолько необычайна плодородна, что даже был период, когда устраивали соревнования обфусцированного кода на Perl.

Важно то, что когда программист работает на языке с широкими возможностями, ему надо в обязательном порядке выработать стиль. И тогда с его кодом можно работать. А когда всё подряд без стиля и культуры в одну коробку запихивают, получается Boost. :)

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

57. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Аноним (??) on 01-Сен-17, 20:24 
Целиком и полностью согласен. Но Rust — это не Perl, это попытка переделать C++ «правильно». И сообщество его состоит преимущественно из плюсовиков.
Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

36. "Релиз языка программирования Rust 1.20"  +9 +/
Сообщение от Ordu email(ok) on 01-Сен-17, 18:07 
> Отстаёт — в смысле туда уже запихали всё, что есть в C++...

Нет конечно. За rust'ом стоит другая идеология. Страуструп пихал в C++ всё, что он смог в zero-cost абстракции завернуть, потому что не знал ещё, как люди будут писать программы на C++. Когда же rust зародился, уже было понятно, как надо писать программы на C++. Что, например, наследование не нужно, что try/catch/throw не самая удачная штука для обработки ошибок, что UB в стандарте -- это плохо, что функциональное программирование -- это хорошо и вполне юзабельно, если не впадать в крайности, что обратная совместимость синтаксиса с C -- это недостижимо, но привносит кучу проблем, что utf8 -- это стандарт для представления строк. C++ был поиском новых путей для программирования в ширину, rust -- это скорее поиск в глубину.

> то есть примерно всё, что вообще встречается в разных языках программирования, или ещё не успели?

Да ну. В C++ нет и половины того, что встречается в разных языках программирования. Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

42. "Релиз языка программирования Rust 1.20"  –3 +/
Сообщение от 123 (??) on 01-Сен-17, 19:04 
>> Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.

Ну как в каждом языке своё, а в c++ впихнули все и ввели еще режим совместимости, тк сверху вниз он не совместимы 90% компиляторов. Что уже говорить про разные реализации  компиляторы.  

Нормальное ООП и полиморфизм есть только в SmallTalk. В остальных ЯП идет скрещивание ужа с ежом.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

44. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Ordu email(ok) on 01-Сен-17, 19:18 
> Ну как в каждом языке своё, а в c++ впихнули все...

Повторюсь: не всё.

Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

55. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 20:21 
> Да ну. В C++ нет и половины того, что встречается в разных языках программирования. Глянь, например, на CLOS, чтобы проникнуться тем, что такое ООП. Глянь на Ocaml, чтобы понять, что такое полиморфные типы. Или на хаскель, чтобы понять, что делают с языком immutable данные, pure функциональность и РЕАЛЬНЫЙ полиморфизм.

Примерно это я и имел в иду: в C++ оно как бы есть, но толку от этого чуть больше нуля.

Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

65. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Ordu email(ok) on 01-Сен-17, 21:30 
Да, вероятно. Я не понимал как надо писать на C++, до тех пор пока не разобрался с Rust'ом. В C++ действительно очень много чего намешано и неясно, как именно всё это можно сочетать, без прочтения правильных гайдов, но какие из них правильные априорно непонятно.
Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

25. "Релиз языка программирования Rust 1.20"  +2 +/
Сообщение от Крутой аноним on 01-Сен-17, 15:29 
> Скажите, кто следит, оно по степени yпоротости уже перегнало кресты, или всё
> ещё только догоняет?

Т.к. C++ стартовал намного раньше не думаю что его возможно догнать.
Например о "move" авторы Rust думали с самого начала, поэтому там нет
такого сумасшествия как 4 спецальных функций чтобы экземпляры твоего типа
передавались туда сюда (имеется ввиду copy/move constructor и copy/move operator=).

Также авторы Rust знали заранее к чему может привести простой функционал
замены "А" на "Б" в руках неокрепших умов, поэтому все применения макросов
помечены восклицательным знаком.

В общем думаю еще лет 10-20 не то что не догонит, но и близко не будет по сложности синтаксиса.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

26. "Релиз языка программирования Rust 1.20"  +3 +/
Сообщение от anon2314 email on 01-Сен-17, 15:54 
бобит то как, чувствуют, чувствуют люди, что скоро Раст подвинет старичков из системного программирования, насиженного места.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

27. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 16:28 
Это вряд ли. Rust это очередная игрушка попиарится.
Не более.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

37. "Релиз языка программирования Rust 1.20"  +/
Сообщение от anonimbl on 01-Сен-17, 18:23 
> Это вряд ли. Rust это очередная игрушка попиарится.
> Не более.

На которой, меж тем, пишутся вполне себе серьезные вещи уже.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

39. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 18:33 
Это просто попытка привлечь внимание, а не серьезные вещи.
Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

56. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Вареник on 01-Сен-17, 20:24 
>> Это вряд ли. Rust это очередная игрушка попиарится.
>> Не более.
> На которой, меж тем, пишутся вполне себе серьезные вещи уже.

Эти "серьезные вещи" из целого одного браузера -начали падать в разы чаще и вчистую сливают конкурентам аудиторию.

Какая здесь роль именно хруста и сообщества восторженной школоты вокруг него - сказать сложно, но это было предсказуемо.

Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

76. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Аноним (??) on 01-Сен-17, 22:26 
>>> Это вряд ли. Rust это очередная игрушка попиарится.
>>> Не более.
>> На которой, меж тем, пишутся вполне себе серьезные вещи уже.
> Эти "серьезные вещи" из целого одного браузера

https://www.opennet.ru/opennews/art.shtml?num=46805
Это, конечно, далеко не браузерный движок, зато сама контора посолидней мозиллы.

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

108. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Firefoxus on 05-Сен-17, 12:13 
>Эти "серьезные вещи" из целого одного браузера -начали падать в разы чаще и вчистую сливают конкурентам аудиторию.

Это в ваших влажных хромоюзеровских фантазиях чтоли?
А ничего, что на Rust в Firefox пока ещё ничего нет в проде? Firefox Nightly — не прод, если что. Он как раз для того и создан, чтобы всякие баги отлавливали желающие новизны, которые ну явно Nightly ставили не ради «стабильности».

Между прочим я всегда «стабильной» версией пользовался. И только с выходом Firefox Nightly 57 (Mark 57) я его поставил. Именно ради того, чтобы не иметь хоть и редкие падения, которые вызваны этим легаси-глюкодромом под названием XUL. Так и случилось — у меня ни разу Nightly не упал, не заглючил, не затормозил даже.

Что же касается Quantum CSS (aka Stylo), который является пока единственной частью Servo на Rust портированный в Firefox Nightly 57 (в Nightly, Карл! не в прод 55) — так это единственное, к чему у меня нет нареканий сейчас. Остальные части движка, которые не связаны с парсингом и обработкой CSS, всё так же чутка уступают Blink (у меня есть на чём это проверять).

Хотя… в чём-то вы правы. Ведь с выпуском Nightly 57 как и я очень многие на него перешли… так сказать, «слились» из пользователей «стабильного» Firefox, по крайней мере до выхода в ноябре Firefox 57 😉

Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

79. "Релиз языка программирования Rust 1.20"  +/
Сообщение от freehck email(ok) on 01-Сен-17, 22:52 
> скоро Раст подвинет старичков из системного программирования

Ну нет, это вряд ли. :)

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

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

85. "Релиз языка программирования Rust 1.20"  +7 +/
Сообщение от Аноним (??) on 02-Сен-17, 09:36 
Скажу по секрету - как раз таки "старички", у которых кроме основного рабочего ЯП (того же C или жабы) пары ЯП "для разной мелочёвки" (например, awk - иногда груду текстового навоза перелопатить) есть ещё в анамнезе десяток ЯП, от тикля до эрланга, которые ему пришлось изучить для ковыряния чужогого кода - так вот именно такие "старички" быстрее освоят новый язык (если понадобится), чем свежевыпущенная с курсов макака, признающая только один ЯП - тот единственный, которому её научили.
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

94. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от pripolz email on 02-Сен-17, 17:54 
Пока одни учат бесконечные япы, другие растут как профессионалы в своём направлении. К примеру, можно OpenGL освоить хорошенько, на это несколько лет нужно.
Яп - это просто инструмент, который мало чего решает. А времени у нас не так уж много в этой жизни.
Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

95. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от Led (ok) on 02-Сен-17, 18:58 
> А времени у нас не так уж много в этой жизни.

Естественно. Уроки учить...

Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

31. "Релиз языка программирования Rust 1.20"  +4 +/
Сообщение от Какаянахренразница (ok) on 01-Сен-17, 17:24 
> [...] обеспечивающего автоматическое управление памятью и предоставляющего
> средства для высокого параллелизма выполнения заданий
> ...
> Напомним, что язык Rust сфокусирован на безопасной работе с памятью и
> обеспечении высокого параллелизма выполнения заданий. [...]

Спасибо за напоминание, но не слишком ли часто?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

40. "Релиз языка программирования Rust 1.20"  –2 +/
Сообщение от Lolwat on 01-Сен-17, 18:38 
Ох уж эти змеи, как только не изовоються лишь бы не писать на С.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

48. "Релиз языка программирования Rust 1.20"  +/
Сообщение от НяшМяш (ok) on 01-Сен-17, 19:24 
А ну бегом написал движок для firefox-next.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

60. "Релиз языка программирования Rust 1.20"  +/
Сообщение от 123 (??) on 01-Сен-17, 20:53 
Заказчики заразы - требуют быстрее выпускать рабочие версии, не хотят ждать квартал, пока ищешь утечку в памяти, говорят php-шники и python-исты пишут гораздо быстрее и дешевле.
Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

66. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Аноним (??) on 01-Сен-17, 21:33 
> Заказчики заразы

... разные бывают.

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

Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

103. "Релиз языка программирования Rust 1.20"  –1 +/
Сообщение от r2d3 on 04-Сен-17, 12:16 
Смешно, когда код питониста работает быстрее, чем код сишника. Ибо тот байтики перекладывать научился, а программировать - нет. Серьёзно, я после ассоциативного массива на связном списке уже ничему не удивляюсь.
Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

53. "Релиз языка программирования Rust 1.20"  –5 +/
Сообщение от Вареник on 01-Сен-17, 20:19 
>> защищает от проблем
>> в один клик
>> избавляет разработчика от

Почему Firefix чем дальше, тем чаще крашится на ровном месте? На банальной закачке 500-мегового файла может упасть, сразу после открытия программы.

И почему я не удивлен? Видя восторг школоты по повобу "оно само безопасно" - почему я предполагал нечто подобное?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

54. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от Вареник on 01-Сен-17, 20:20 
>> Firefix

Очепятка по Фрейду :)

Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

69. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 22:05 
Наставил расширений небось. В ноябре они все отвалятся с приходом новой архитектуры запрещающей им глубоко внедряться в браузер.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

78. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 01-Сен-17, 22:46 
У меня, наверное, более сотни расширений. Да, я плагиновый маньяк. Не крешится.
Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

83. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Аноним (??) on 02-Сен-17, 00:57 
Зависит от самих расширений, а не от их количества. Сложно было догадаться? Иди ты думаешь в коде FF стоит if (ext_count < 100) do_crash()?
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

98. "Релиз языка программирования Rust 1.20"  +/
Сообщение от YetAnotherOnanym (ok) on 03-Сен-17, 10:55 
Наверное. ты - хозяин Оки "Моня"?
Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

86. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от fooBar on 02-Сен-17, 12:06 
Сейчас в фаерфоксе на RUST написаны движок стилей (CSS), и парсер метаданных (mp3/4,...)  "Закачка" файла к этим модулям на RUST не имеет никакого отношения
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

109. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Firefoxus on 05-Сен-17, 12:24 
Если быть точнее, то не «сейчас». А в ноябре. Сейчас же только в Nightly.
Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

110. "Релиз языка программирования Rust 1.20"  +/
Сообщение от Firefoxus on 05-Сен-17, 12:27 
На тому кренделю лишь бы слюной побрызгать 😂
Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

97. "Релиз языка программирования Rust 1.20"  +1 +/
Сообщение от VEG email(ok) on 02-Сен-17, 23:02 
Если используете 32-разрядную версию, попробуйте перейти на 64-разрядную.
Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

101. "Релиз языка программирования Rust 1.20"  –3 +/
Сообщение от pripolz on 03-Сен-17, 19:02 
я бы сказал, язык готов процентов на 30. К продаже. Adobe.
Хотя, это если у мазилы всё получится, нынче на этом рынке неплохая конкуренция.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру