LINUX.ORG.RU

Вышел Rust 1.0 Beta

 ,


2

7

3 апреля 2015 года, в полном соответствии с планом, вышла бета-версия Rust 1.0. Язык и большая часть стандартной библиотеки окончательно стабилизированы, до финального релиза возможны только минимальные изменения в API.

Некоторые изменения со времени альфа-версии, вышедшей 9 января:

Полный список изменений.

Так же разработчики отмечают рост экосистемы языка. Репозиторий crates.io недавно преодолел отметку в 1 миллион загрузок и содержит более 1700 модулей, готовых для использования. В данный момент идет работа по обновлению устаревших модулей до бета-версии. Большая часть документации (The Book, Rust By Example, The Rust Reference, API reference) приведена в соответствии с вышедшей бета-версией.

Окончательный релиз Rust 1.0 запланирован на 16 мая, разработчики потратят оставшиеся до релиза 6 недель на тестирование, исправление ошибок и обновление документации.

>>> Подробности

anonymous

Проверено: maxcom ()

Ответ на: комментарий от xio4

Многопоточная компиляция поддерживается?

Мне всегда было интересно — зачем это нужно? В больших проектах файлов много, несложно одновременно компилировать N файлов по числу ядер.

Legioner ★★★★★
()
Ответ на: комментарий от dizza

Ну вот хотя бы в список хочу элементы запихивать. Это что, каждый элемент будет box-ится выделением памяти в хипе? Это же ппц.

В расте вроде куча используется не чаще, чем в каком-нибудь C. Сдаётся мне, ты что-то путаешь.

Legioner ★★★★★
()
Ответ на: комментарий от anonymous

в частности vec - как std::vector в С++ - это просто массив значений.

Все на векторе не напишешь.

Очевидно, более сложные коллекции активно выделяют память для своих внутренних структур, но это необходимый минимум

Вот и я говорю - тормозит.

Там да, для каждой вставки объект выделяется в куче, и контейнер хранит ссылку на Object, неявно приводя его к нужному типу.

Кукаретик, не знающий как работает JVM, детектед. Память в хипе выделяется сразу в количестве Xms, создание нового обьекта в жабе, это просто bump pointer-a, в этом боьшом предвыделенном пуле.

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от Legioner

В серьезных приложениях на Си таки юзается активно, посмотри хотя бы код какой-нибудь СУБД. Но там есть штуки типа apache memory pool, всякие аллокаторы и так далее.

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от dizza

Вот и я говорю - тормозит.

По сравнению с чем? Ржавчина в этом плане аналогична си\плюсам.

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

ozkriff
()
Ответ на: комментарий от ozkriff

По сравнению с чем? Ржавчина в этом плане аналогична си\плюсам.

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру. Ржавчина в этом плане пока дно, а не аналог. Вон, есть продвижения в этом направлении: https://doc.rust-lang.org/arena/, это супер, но факт в том, что Rust еще пилить и пилить.

dizza ★★★★★
()
Ответ на: комментарий от dizza

В серьезных приложениях на Си таки юзается активно, посмотри хотя бы код какой-нибудь СУБД. Но там есть штуки типа apache memory pool, всякие аллокаторы и так далее.

Как мне кажется, те пулы используются не столько ради скорости, сколько ради того, чтобы не следить за освобождением памяти. Могу ошибаться, конечно. Есть где-нибудь сравнение производительности обычного malloc-а и пулового? Я понимаю, что разница будет, но какая?

Legioner ★★★★★
()
Ответ на: комментарий от dizza

Вот и я говорю - тормозит.

Не понял, ты знаешь какие-то другие альтернативы? Может быть ты знаешь, как написать hash-map или b-tree без аллокаций?

Память в хипе выделяется...

Лол, какое мне дело, какие костыли придумали в JVM, лишь бы не делать нормальные генерики. Суть-то не меняется - вместо значений в структурах хранятся указатели на кучу, а значит каждое обращение требует минимум двух разыменовываний, а каждая вставка - аллкокации, пусть и дешевой. Но мне больше интересно, зачем ты продолжаешь проецировать свои жаба-комплексы на раст. В расте, в отличие от жабы, есть полноценные генерики и можно выделить нетривиальный объект на стеке, так что от «аллокации на каждый чих» он гораздо дальше.

anonymous
()
Ответ на: комментарий от Legioner

Пул и для того и для того + еще с фрагментацией позволяет бороться. Бенчмарков под рукой нет, но разница большая.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Ну вот хотя бы в список хочу элементы запихивать. Это что, каждый элемент будет box-ится выделением памяти в хипе? Это же ппц.

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

tailgunner ★★★★★
()
Ответ на: комментарий от zenden

С++ сам себя убъет возрастающей сложностью.

Страуструпп рекомендует использовать только часть С++ которую вы освоили.

grim ★★☆☆
()

День скучных новостей?

kas501 ★★★
()
Ответ на: комментарий от anonymous

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

Твои кукарекания про «нормальные женерики» просто смешны, так как ты не знаешь про такую оптимизацию, как Escape Analysys. Высокопроизводительный сервер сейчас - это или C/C++ c кастомными аллокаторами, или JVM c pointer bump-ом.

dizza ★★★★★
()
Ответ на: комментарий от dizza

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру. Ржавчина в этом плане пока дно, а не аналог.

Пруф будет?

tailgunner ★★★★★
()
Ответ на: комментарий от dizza

В минусы пула можно записать неоптимальное использование памяти. Пока обработка запроса не закончится — память не будет освобождена и другие части приложения не смогут её переиспользовать.

В принципе в расте никто не мешает сделать пулы и вроде ты сам приводил ссылку на какую то библиотеку. Я её не использовал, но может это оно? Разве что стандартная библиотека будет память брать из кучи, понятия заменяемых аллокаторов там вроде нет. Думаю для критичных мест можно изобрести велосипед.

Legioner ★★★★★
()
Ответ на: комментарий от loz

Ну и получится у тебя С++, с текущей памятью, двойным удалением, нул поинтерами, buffer overflow и т.п.. Для этого Rust и пишут, чтобы без GC, но и не C++.

anonymous
()
Ответ на: комментарий от tailgunner

Узлы списка будут выделяться на хипе, но оно всегда так для списка.

В том то и дело не всегда. В С++ можно свой аллокатор впиндюрить, в JVM, как я уже говорил, вся доступная память - memory pool.

dizza ★★★★★
()
Ответ на: комментарий от tailgunner

Это просто опыт с прошлой работы. У нас чуваки писали кусок на С++, в итоге запуск в прод показал, что наивное использование malloc дает больше тормозов, чем использование жабы. Но они в итоге наколдовали с аллокатрами, и полетело. Пруфы я думаю найти можно, но лень.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Узлы списка будут выделяться на хипе, но оно всегда так для списка.

В том то и дело не всегда. В С++ можно свой аллокатор впиндюрить

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

в JVM, как я уже говорил, вся доступная память - memory pool.

И в результате Java жрет память в три горла.

нас чуваки писали кусок на С++, в итоге запуск в прод показал, что наивное использование malloc дает больше тормозов, чем использование жабы.

Слишком туманно.

Но они в итоге наколдовали с аллокатрами, и полетело

Ну так колдовство есть и в Rust. Уже сейчас.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от Legioner

Угу, продвижения есть, просто заметно, что у Раста нет хардкорного продакшна и с такими продвинутыми штуками пока плоховат то. Пока.

dizza ★★★★★
()
Ответ на: комментарий от tailgunner

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

Ну дык да, все в твоих руках.

И в результате Java жрет память в три горла.

Верно, но обьекты создаются быстро, это факт. Поэтому меня и удручает, что в Расте пока все вяло с этим, до продакшна далеко. Но потенциал хороший.

dizza ★★★★★
()
Ответ на: комментарий от dizza

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

Ну дык да, все в твоих руках.

Стандартный ответ на все вопросы о Си++ %)

Поэтому меня и удручает, что в Расте пока все вяло с этим

Да блин. Тебе уже несколько раз указали на Arena.

до продакшна далеко

Это у кого как. В reddit периодически пишут о продакшене на Rust.

tailgunner ★★★★★
()
Ответ на: комментарий от dizza

Escape Analysys

Какая связь между подделкой под генерики через type erasure и способностью компилятора иногда заменять аллокацию в куче аллокацией на стеке?

anonymous
()
Ответ на: комментарий от anonymous

Такая, что эта оптимизации помогает справиться с недостатками дженериков. Ты хоть понимаешь почему дженерики такие какие они есть? Это сделано для совместимости со старым кодом, ну да, кукаретики не думают про совместимость. JVM - это куча trad off, которые необходимо было сделать в силу обстоятельств, и это жизнь.

dizza ★★★★★
()
Ответ на: комментарий от tailgunner

Да блин. Тебе уже несколько раз указали на Arena.

Так это все пока детсад ведь, не? Как например заставить готовый список создавать элементы в арене? Это же тока для своего кода, как я понял.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Такая, что эта оптимизации помогает справиться с недостатками дженериков.

Я прочитал википедию и не понял, как эта оптимизация поможет справиться с недостатками дженериков. Конкретно, если я хочу создать вектор/список значений, типа std::vector<int>, как эта оптимизация поможет мне избежать списка указателей на значения в куче?

Ты хоть понимаешь почему дженерики такие какие они есть?

Да, я читал, я понимаю мотивацию разработчиков, наверно они были правы. Но это не отменяет того факта, что генерики в Java - тормозная подделка под настоящий параметрический полиморфизм а-ля Haskell или .NET 2.0, и что они-то как раз и провоцирую «аллокацию на каждый чих», под которую потом приходится затачивать ВМ.

anonymous
()
Ответ на: комментарий от dizza

Да блин. Тебе уже несколько раз указали на Arena.

Так это все пока детсад ведь, не?

Детсад - это капризничать «хочу создавать узлы списка в пуле, а иначе не готов для продакшена».

Это же тока для своего кода, как я понял.

Ну дык да, все в твоих руках.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Детсад - это капризничать «хочу создавать узлы списка в пуле, а иначе не готов для продакшена».

Вообще-то не детсад. Детсад - это кидаться на все новое и модное с вытаращенными глазами.

dizza ★★★★★
()
Ответ на: комментарий от shty

Offheap быстро только в очень специфичных случаях, когда затраты на гц больше затрат на offheap хранение.

dizza ★★★★★
()
Ответ на: комментарий от dizza

Offheap быстро только в очень специфичных случаях,

зато часто

когда затраты на гц больше затрат на offheap хранение.

offheap хранение не про ресурсы, а про то, что оно потенциально небезопасно и правильно и безбажно его написать сложно

и хватит уже килограммы с километрами сравнивать

shty ★★★★★
()
Ответ на: комментарий от dizza

Детсад - это кидаться на все новое и модное с вытаращенными глазами.

Кидаться с вытаращенными глазами - глупо, и неважно, на новое или на старое. Но если под «новым и модным» ты подразумеваешь Rust, то я не вижу как минимум моды на него.

tailgunner ★★★★★
()
Ответ на: комментарий от ozkriff

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

Но для этого уже есть Haskell, OCaml, SML и куча других более идиоматичных языков.

buddhist ★★★★★
()
Ответ на: комментарий от buddhist

Да, но это все языки с неотрезаемым GC, а Rust пишется для задач, в которых GC крайне нежелателен.

anonymous
()
Ответ на: комментарий от buddhist

уже есть Haskell, OCaml, SML

Но ведь Хаскель - игрушка академиков, Окамль - придворный язык Jane Street Capital, SML вообще сиротка бездомный.

tailgunner ★★★★★
()
Ответ на: рустомакросы от Hertz

У меня задымился парсер.

Ну да, синтаксис несколько страшный. Но мне что-то кажется, что читать навороченные растовые макросы будет проще, чем «шаблонное метапрограммирование» на С++.

DarkEld3r ★★★★★
()
Ответ на: комментарий от anonymous

Очередной высер. Вакансии по Rust уже есть, зайди на сайт Мозиллы и убедись.

Safort
()
Ответ на: комментарий от tailgunner

SML вообще сиротка бездомный

После пересадки почки Харпер им сильно озаботился :)

buddhist ★★★★★
()
Ответ на: комментарий от Hertz

Его, судя по всему, пока освоишь - просрёшь все полимеры.

Это всё-таки макросы, их по идее, не так часто писать приходится. Да и тот же С++ ничего такого вообще не предлагает. Сишные макросы - не то.

В остальном у меня никаких сложностей с языком не было. Ну это после С++.

DarkEld3r ★★★★★
()
Ответ на: комментарий от iamweasel

Недавно предполагаемой датой выхода значилось Mar 31.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от dizza

И box-ов этих в реальном коде дохрена, взять хотя бы коллекции.

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

hateyoufeel ★★★★★
()
Ответ на: комментарий от dizza

По сравнению с кодом на Си/С++, в котором юзается кастомный аллокатор, к примеру.

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

DarkEld3r ★★★★★
()
Ответ на: комментарий от hateyoufeel

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

dizza ★★★★★
()
Последнее исправление: dizza (всего исправлений: 1)
Ответ на: комментарий от DarkEld3r

На С++ стоит только хардкорные проекты писать вроде СУБД и high frequency trading и там аллокаторы - это обыденность, а не редкость. Rust метит туда же.

dizza ★★★★★
()
Ответ на: комментарий от grim

Страуструпп рекомендует использовать только часть С++ которую вы освоили

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

MyTrooName ★★★★★
()
Ответ на: комментарий от dizza

в JVM, как я уже говорил, вся доступная память - memory pool

внезапно, внутри твоего пула тоже нужно аллоцировать блоки

MyTrooName ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.