LINUX.ORG.RU

Вышел новый релиз языка программирования Rust 0.8

 ,


0

9

Вышел новый релиз системного и прикладного языка программирования общего назначения Rust 0.8.

В основном были доработаны/изменены стандартная библиотека и рантайм языка, в меньшей степени синтаксис.

Кратко из изменений в этом релизе:

  • изменения в синтаксисе for цикла — с применением итераторов.
  • новый метод форматирования format! (заменит fmt! в будущем)
  • изменения в FFI: теперь вызов foreign функции может быть прямым, без дополнительной обертки/оверхеда, при использовании специальной аннотации.
  • изменения в cast naming conventions.
  • новый рантайм языка и планировщик задач были переписаны с C++ на Rust: теперь Rust почти полностью написан на самом себе.
  • новый рантайм улучшил новую I/O подсистему std::rt::io реализующую: TCP, UDP, файлы, таймеры и процессы.

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

https://github.com/mozilla/rust/wiki/Doc-detailed-release-notes

http://www.rust-lang.org/

★★

а по теме - слава Марку, что есть ppa, будем напосмотреть поближе, что это за rust

wota ★★ ()

Чем он лучше того чего он лучше? Хотя бы вкратце. Есть что-нибудь написанное на нем, кроме него?

Suntechnic ★★★★★ ()

хм, подправил стандартный пример:

fn main() {
    let nums = [0, 1, 2, 3];
    let noms = ["Tim", "Eston", "Aaron", "Ben"];

    for &num in nums.iter() {
        do spawn {
            let msg = fmt!("%s says hello from a lightweight thread!",
                           noms[num]);
            println(msg);
        }
    }
}

два раза подряд запустил:

~$ ./1
Tim says hello from a lightweight thread!
Eston says hello from a lightweight thread!
Aaron says hello from a lightweight thread!
Ben says hello from a lightweight thread!
~$ ./1
Eston says hello from a lightweight thread!Tim says hello from a lightweight thread!
Aaron says hello from a lightweight thread!

Ben says hello from a lightweight thread!

кто в теме - что это было во второй раз, и как этого избежать?

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

Очевидно один из потоков был вытеснен до окончания println (до того, как напечатался \n), а потом пробудился и напечатал таки свой \n.

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

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

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

исправлено с помощью print + '\n', но все равно странновато, такое логичнее было б ожидать от плюсов, например, чем от их заменителя

wota ★★ ()
Последнее исправление: wota (всего исправлений: 1)

новый рантайм языка и планировщик задач были переписаны с C++ на Rust: теперь Rust почти полностью написан на самом себе

Отлично.

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

все равно странновато

Чем странновато? Ожидаемое поведение параллельной программы.

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

Чем странновато? Ожидаемое поведение параллельной программы.

да нет, ты ж не ожидаешь, что оно тебе кашу из символов выведет? и очевидно println не смог нормально добавить '\n' к выводимой строке, чтоб они вывелись вместе

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

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

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

ты ж не ожидаешь, что оно тебе кашу из символов выведет?

Я ожидаю. Если ты _не_ ожидаешь - почему? Это параллельная программа, использующая общий ресурс без видимой синхронизации доступа.

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

Это пример того, как выглядит программа, а не того, как выводится текст.

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

Я ожидаю. Если ты _не_ ожидаешь - почему? Это параллельная программа, использующая общий ресурс без видимой синхронизации доступа.

потому-что никому не нужна случайная «каша» в stdout и всем нужен нормальный вывод строк, это просто и логично, и современные ЯП должны сами решать такие задачи

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

первый же пример нам показывает грабли

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

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

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

т.е. вам таки нужна каша в stdout - расскажите зачем вам такая многопоточность?

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

ну и да - в данном случае они таки лочат, сюрприз

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

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

Что-то не вижу, где они что-то лочат.

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

Что-то не вижу, где они что-то лочат.

потому-что на каждый println две операции записи - строка + '\n', и каждая лочит другие треды

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

То есть ты предполагаешь невидимый лок где-то в библиотеке вывода, хотя наблюдаемое поведение программы этому противоречит %)

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

То есть ты предполагаешь невидимый лок где-то в библиотеке вывода

этот лок не в rust

хотя наблюдаемое поведение программы этому противоречит %)

наоборот - полностью доказывает, есть строка и '\n', все выводится правильно, не мешая другим тредам, но по отдельности

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

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

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

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

т.е. вы хотите все делать руками? ну ок, каждый делает как хочет

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

Лок происходит в системном вызове. Шедулер зелёных тредов не может передать исполнение следующему пока в этом не отработает системный вызов. Видимо в println их два что и позволяет вызовам из других тредов вклиниться между.

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

Шедулер зелёных тредов

А нативные треды в расте есть?..

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

То есть ты предполагаешь невидимый лок где-то в библиотеке вывода

этот лок не в rust

А где? Насколько я понимаю, у них свой stdio.

наблюдаемое поведение программы этому противоречит %)

наоборот - полностью доказывает

okay.jpg

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

Лок происходит в системном вызове. [...] Видимо в println их два

...и они не прикрыты локом. Это и называется «нет синхронизации доступа».

Шедулер зелёных тредов

AFAIK, там M:N, так что всё сложнее.

tailgunner ★★★★★ ()

Ненужность еще шевелится? Скорее закапывайте, вонять начнет!

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

Лок происходит в системном вызове.

Помню, в молодости я читал, что write(2) совершенно не обязан пейсать весь буффер в файл, а может сделать частичную запись и потом вернуться. Какой же это лок?

anonymous ()

Кто-нибудь мне объяснит, чем оно лучше того же Go или D?

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

Э-э-эй! Если ты имеешь голос в мозилла ресёч, то зачем озвучивать его здесь? Если не имеешь, то зачем сотрясать воздух? Странные вы, аноны.

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

Кто-нибудь мне объяснит, чем орангутанг лучше макаки?

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

Кто-нибудь мне объяснит, чем орангутанг лучше макаки?

Так и запишем: зоопарку ЯП быть.

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

Гдето на буржуйском ресурсе читал что Go єто новая Java. А Rust єто замена С/С++. Ну о D.все и так должньі бьіть вкурсе

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

В rust есть ADT (и pattern-matching по ним) и generics, а в Go их нет. Ну и несколько типов указателей.

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

А нативные треды в расте есть?..

Параллелизация без нативных нитей невозможна, так что есть: «The runtime scheduler maps tasks to a certain number of operating-system threads. By default, the scheduler chooses the number of threads based on the number of concurrent physical CPUs detected at startup».

tailgunner ★★★★★ ()

новый рантайм языка и планировщик задач были переписаны с C++ на Rust: теперь Rust почти полностью написан на самом себе.

Теперь Rust из убогонького недоязычка превратился в серьёзный язык для приложений. Ждём первую стабильную версию!

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

Ты напиши там куда-нибудь. В багзиллу или что-то подобное.
Мне тоже странно, что println может выводить \n отдельно от строки.
Возможно, это бага.

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

Go - тормоз и неумеха. Если кого и мог бы заменить, то Java. Но не заменит, ибо платформа. Для некоторых задач может и Python заменить.

D - такой же С++, только с боку. А в каком-то смысле даже более укурен(см. шаблоны те же). Rust же пытается быть самостоятельным языком. Но при этом обладает всеми возможностями для того, чтобы не оставить для С++ места. Только уж для совсем извращенных задач. Я надеюсь, что С++ рано или поздно полностью заменит С. А сам, в свою очередь, будет подвинут Rust'ом.

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

Возможно, это бага.

По крайней мере раньше вроде такого не было.

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

По крайней мере раньше вроде такого не было.

А ты сколько раз проверял? У меня на моем i7 2600K такое вылезло где-то на сотый раз.

unt1tled ★★★★ ()

Concurrency lightweight tasks with message passing, no shared memory

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

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

Что-то как-то, мне кажется, что из-за одного этого пункта не тянет на «убийцу плюсов».

Мне кажется, у тебя узкое представление о том, что такое shared memory.

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

Ну, просто мне, не подумав, кажется, что один и тот же код будет работать быстрее с «классическим» подходом к параллелизму, потоки с общей памятью, мутексы и так далее (хотя он и сложнее и гораздо более ошибкоопаснее). Если они хотят полностью завоевать нишу C++, то на их языке должно быть возможно написать всё, что можно на C++, без оверхеда.

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

А может быть на самом деле всем пофиг на оверхед, потому что он будет всё равно не заметен (особенно, если сравнивать с языками, в которых оверхед неизбежен), тогда он тоже может вытяснить C++.

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

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

Никому не нужно «всё».

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

Ну, если закопать плюсы, то весь текущий плюсовый код, очевидно, надо будет на чём-то переписывать.

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

если закопать плюсы, то весь текущий плюсовый код, очевидно, надо будет на чём-то переписывать.

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.