The OpenNET Project / Index page

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

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

"Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от opennews (??) on 04-Фев-17, 11:25 
Представлен (https://blog.rust-lang.org/2017/02/02/Rust-1.15.html) релиз языка программирования Rust 1.15 (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).


В состав нового выпуска принято  1443 изменения от 137 разработчиков. Основные новшества (https://github.com/rust-lang/rust/blob/stable/RELEASES.md#ve...):


-  В процедурных макросах (https://doc.rust-lang.org/book/procedural-macros.html) обеспечена возможность создания произвольных обработчиков (https://github.com/rust-lang/rfcs/blob/master/text/1681-macr...) на базе механизма "derive". Если ранее через "derive" предоставлялся типовой набор обработчиков, таких как отладочный вывод значений и сериализация/десериализация, то теперь можно создавать собственные обработчики, например, для упрощения построения запросов через ORM Diesel (http://diesel.rs/) или применения произвольных схем сериализации через фремворк Serde (https://serde.rs/);
-  По умолчанию задействована новая система сборки, полностью переписанная на языке Rust. Начиная с Rust 1.17 поддержку сборки на основе  Makefile планируется полностью удалить, что предоставит возможность задействования в компиляторе пакетов с crates.io по аналогии с другими проектами на языке Rust;

-  Реализован третий уровень (https://forge.rust-lang.org/platform-support.html) поддержки для архитектур i686-unknown-openbsd, MSP430 и ARMv5TE;

-  Продолжена работа по оптимизации скорости работы компилятора;

-  В операторе where  реализована возможность указания свойства "?Sized", например "struct Foo where T: ?Sized {f: T,}";
-  Переписана реализация алгоритма сортировки slice::sort, которая стало существенно быстрее;
-  Проведена оптимизация производительности методов chars().count(), chars().last() и char_indices().last();
-   В пакетном менеджере Cargo обеспечен вывод предупреждения, в случае наличия в корне пакета файла build.rs, но отсутствия аннотации 'build = "build.rs"'. В команду "cargo test" добавлен флаг "--all";

-  В разряд стабильных переведена новая порция функций и методов.


Напомним, что язык 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/02/02/Rust-1.15.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=45981

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

Оглавление

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


1. "Доступен язык программирования Rust 1.15"  –24 +/
Сообщение от Я (??) on 04-Фев-17, 11:25 
"высокого параллелизма выполнения заданий"
ага фирефокс так и блещет параллелизмом
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

2. "Доступен язык программирования Rust 1.15"  +16 +/
Сообщение от Аноним (??) on 04-Фев-17, 11:29 
а причем тут лиса? В ней на rust пока только один модуль...
А серво на этапе разработки.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

52. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от th3m3 (ok) on 05-Фев-17, 14:26 
Откуда вы такие лезите? В Firefox, это нормально завезут - только к концу года.
Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

72. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Вареник on 08-Фев-17, 19:13 
И его придется запускать в "одноядерном" контейнере, чтобы не вешал всю систему.
Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

4. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Аноним (??) on 04-Фев-17, 12:03 
>ага фирефокс так и блещет параллелизмом

так в firefox на rust пока только картинки обрабатывать
планируют, на rust написан servo, его и оценивайте.

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

12. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Аноним (??) on 04-Фев-17, 15:32 
Если даже у Рэймонда от раста батхёрт:

In practice, I found Rust painful to the point of unusability. The learning curve was far worse than I expected; it took me those four days of struggling with inadequate documentation to write 67 lines of wrapper code for the server.

Even things that should be dirt-simple, like string concatenation, are unreasonably difficult. The language demands a huge amount of fussy, obscure ritual before you can get anything done.

Значит язык ещё очень сырой и не скоро будет готов для продакшена.

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

24. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Аноним (??) on 04-Фев-17, 18:34 
Если даже — а кто он вообще такой-то?  Какой-то человек, который всю жизнь писал на си, и удивляется что ему приходится что-то учить чтобы писать на языке с другой парадигмой. Писал бы хоть когда-то на каком нибудь ATS/Clean или хотя бы окамле — и боли бы не было.
Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

25. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Comdiv (ok) on 04-Фев-17, 18:57 
>Значит язык ещё очень сырой и не скоро будет готов для продакшена.

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

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

62. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Аноним (??) on 05-Фев-17, 22:46 
> struct Foo‹T›where T: ?Sized {f: T,}

Этот синтаксис заставляет меня плакать... Ржавчина решила отобрать пальму самого неудачного синтаксиса у плюсов?

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

71. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от all_glory_to_the_hypnotoad (ok) on 08-Фев-17, 03:26 
У плюсов синтаксис так себе, он далеко не неудачный. Неудачный синтаксис у perl, ruby, ну и с rust жесть выходит.
Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

73. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Вареник on 08-Фев-17, 19:17 
>>Значит язык ещё очень сырой и не скоро будет готов для продакшена.
> Он сложный не потому что сырой, а потому, что такова его природа.
> Поэтому он не станет проще после стабилизации его библиотек и улучшения
> документации.

Кому оно надо, если для мозгое...ва уже есть шаблоны в С++ и мегатонны кода?

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

32. "Доступен язык программирования Rust 1.15"  +4 +/
Сообщение от Ordu email(ok) on 04-Фев-17, 20:38 
> Если даже у Рэймонда от раста батхёрт

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

> Even things that should be dirt-simple, like string concatenation, are unreasonably difficult.

Ага. Это он ещё не пробовал реализовать какой-нибудь список. Интересно, что он сказал бы, когда, потратив дня два, он бы справился с операцией insert и, утерев со лба пот, задумался бы о том, как можно реализовать remove.

Во всём это баттхёрте C/C++ программистов, меня особенно развлекает их святая убеждённость в том, что они лучше всех знают, какие вещи должны быть dirt-simple. Ну, а как иначе? Они ведь C/C++, элита программистов, они просто боги программирования и ручного управления памятью. Как они могут не знать этого? Но при чтении простыней текста, порождённых баттхёртом, у меня складывается впечатление, что они не от великого знания пришли к выводам о том, что должно быть простым, а гораздо более прямолинейно: простым должно быть то, что просто в C/C++. Забывая при этом, что rust не C/C++ и не ставит перед собою цели быть похожим на них (чего не скрывает, и о чём прямо сходу заявляет своим синтаксисом -- объявления типов переменных/функций явно слизаны с pascal, только что слова function/procedure заменили на краткое fn), но пытается сделать сложные вещи, потенциально приводящие к негативным нелокальным последствиям, сложными локально, на уровне грамматики.

> The language demands a huge amount of fussy, obscure ritual before you can get anything done.

Да-да, именно такие заявления меня и наводят на мысль о том, что такие личности пытаясь написать что-то на расте, не понимают, что делают. Не понимают зачем они делают то, что делают. Поэтому все эти телодвижения превращаются для них в загадочный, неприятный и сложный ритуал.
Ну, реально. Зачем rust заставляет нас засовывать элементы создаваемого нами списка в Rc, если в сишечке и без этого работает? Но если мы глянем в гайдлайны для написания ядерного кода linux, там почему-то тоже настоятельно рекомендуется использовать ref_count для элементов списков. Странное совпадение, да?
Наводит на еретическую мысль, что язык без gc -- кусок шита. Хотя нет, о чём это я...
Что список уродская структура, которой не место в репертуаре грамотного программиста. Опять что-то не то...
Что rust абсолютно прав в своих притязаниях, и конечно же, надо упаковывать элементы списка в Rc.

С другой стороны, если честно, я не очень понимаю, о чём говорит Рэймонд. Не вижу больших проблем конкатенировать строки. Я вот специально заглянул в официальную книжку по расту, и там действительно есть пример:
let mut s = "Hello".to_string(); // mut s: String
println!("{}", s);

s.push_str(", world.");
println!("{}", s);

Может он под строками понимает слайсы &str? Это похоже на правду -- похоже на того рода глупость, которую можно ожидать от C программиста, который четыре дня поигрался с rust'ом. Ну и да, слайсы сложнее конкатенировать, вероятно, ещё и ужасный unsafe придётся использовать.
Но если бы Рэймод был бы не только писателем, но и читателем, он бы прочитал в той же книге о том, что если хочется работать с mutable строками, то следует использовать String, а не &str. String инкапсулирует в себе все эти сложности и небезопасности, выставляя наружу полностью safe API. И прежде чем погружаться в изучение этих сложностей и небезопасностей, стоит хотя бы примерно освоить rust на задачках попроще. Но ЧСВ не позволяет -- если уж брать какую-нибудь учебную задачу для освоения языка, так надо сразу irc-сервер, да ещё и со всеми возможными сложностями и небезопасностями, вплоть до конкатенирования строк на стеке, контролируя каждую сгенерённую rust'ом машинную инструкцию. Честолюбивый план, но не для всех. Некоторым не дано с ним справиться. И не все готовы с этим смириться.

> Значит язык ещё очень сырой и не скоро будет готов для продакшена.

Если я угадал с тем, на какие грабли наступил Рэймонд, то сырой не язык, а Рэймонд.

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

39. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от freehck email(ok) on 04-Фев-17, 22:54 
> Не вижу больших проблем конкатенировать строки

Я даже получше примеры нашёл.

let hello = "Hello ".to_string();
let world = "world!";
let hello_world = hello + world;

let hello = "Hello ".to_string();
let world = "world!".to_string();
let hello_world = hello + &world;

Интересно, что его так смутило? Всё равно ведь в C придётся в куче выделить память для результата конкатенации.

> Если я угадал с тем, на какие грабли наступил Рэймонд, то сырой не язык, а Рэймонд.

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

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

45. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Ordu email(ok) on 05-Фев-17, 01:08 
> Интересно, что его так смутило? Всё равно ведь в C придётся в куче выделить память для результата конкатенации.

Оглядываясь на себя -- я тоже занимался этим онанизмом в rust'е -- я предполагаю, что это способ освоения языка. Берём и отказываемся пользоваться стандартной библиотекой, чтобы не отвлекаться на неё, и спокойно себе пописывать вещи, которые насквозь известны и понятны. Это работает, как правило, но не в rust'е. В rust'е подобное тоже имеет смысл, но в качестве следующего этапа. Когда базовые вещи освоены, когда освоены основные вещи из std, вот тогда можно взять и почитать rustonomicon. И научиться писать String, Vec, LinkedList и прочие вещи ручками.

> Я бы не стал так поспешно крестить человека.

Простите, вспылил.

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

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

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

65. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Аноним (??) on 06-Фев-17, 12:55 
>Всё равно ведь в C придётся в куче выделить память для результата конкатенации.

В крестах не обязательно, когда есть SSO у std::*string

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

40. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Буратино on 04-Фев-17, 23:17 
>при чтении простыней текста, порождённых баттхёртом

Простыню полную бугурта накатал здесь именно ты.

>Это он ещё не пробовал реализовать какой-нибудь список. Интересно, что он сказал бы, когда, потратив дня два, он бы справился с операцией insert и, утерев со лба пот, задумался бы о том, как можно реализовать remove

А уж подобный язык будет предметом бесконечных насмешек со стороны более успешных и простых в освоении Яв, Сишарпов, Пыхов и всевозможных *-скриптов.

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

41. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Ordu email(ok) on 05-Фев-17, 00:07 
>>при чтении простыней текста, порождённых баттхёртом
> Простыню полную бугурта накатал здесь именно ты.

И что с того? От этого баттхёрт C/C++ программистов перестаёт быть баттхёртом?

>>Это он ещё не пробовал реализовать какой-нибудь список. Интересно, что он сказал бы, когда, потратив дня два, он бы справился с операцией insert и, утерев со лба пот, задумался бы о том, как можно реализовать remove
> А уж подобный язык будет предметом бесконечных насмешек со стороны более успешных
> и простых в освоении Яв, Сишарпов, Пыхов и всевозможных *-скриптов.

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

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

42. "Доступен язык программирования Rust 1.15"  –5 +/
Сообщение от skybon (ok) on 05-Фев-17, 00:47 
PHP ещё ладно, но у остальных Golang выгрызть ничего не сможет. Golang - это DSL для написания http-бэкендов и различных докер-сервисов. А всё потому что где заканчивается стандартная библиотечка начинаются жуткие ad hoc костыли из-за скудности языка.
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

49. "Доступен язык программирования Rust 1.15"  +/
Сообщение от vstakhov email(ok) on 05-Фев-17, 02:28 
Его возмущение объяснимо: он думал, что все проблемы C раст решит автоматически, а вышло не так - везде заход солнца вручную (RC и рефаунты) и вышивание (та же семантика borrow). Вот только в расте об этом косяке скажет сам компилятор, а в C - в лучше случае статический анализатор. Хотя в данном случае я не знаю, что лучше: параноидальность раста или heartbleed от статического анализатора.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

53. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Crazy Alex (ok) on 05-Фев-17, 16:15 
Ну мне вот тоже непонятно, зачем этот to_string() - о константе компилятор знает абсолютно всё, намерение программиста также абсолютно прозрачно - зачем этот мусор? push_str - там более маразм какой-то. От джавы нахватались, что ли? Нет, чтобы оператор конкатенации сделать. Не, привыкнуть ко всем можно - но зачем делать заведомо неудобные конструкции? Отдельно реализованные строки и слайсы - это вообще какая-то совершенно непонятная избыточность.

P.S. Доки на Rust не читал, так, глянул по ключевым словам.

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

57. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от angra (ok) on 05-Фев-17, 17:29 
Добавить символ к строке - push(), добавить &str - push_str().
Из &str - from(), из utf8 vec - from_utf8(), из Box<str> - into_string()

И после этого пых ругают за бардак с наименованием функций.

Но больше всего порадовало, что операция + позволяет сделать конкатенацию string и &str, но не позволяет двух string, нужно для второго string сделать преобразование в &str. И они удивляются, чего это конкатенация вызывает вопросы у людей знакомых с другими ЯП.


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

58. "Доступен язык программирования Rust 1.15"  +/
Сообщение от 1111 (??) on 05-Фев-17, 18:22 
Потому что в Раст это сделано правильно с учётом логики владения, чего в других языках нет.
Ответить | Правка | ^ к родителю #57 | Наверх | Cообщить модератору

59. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Crazy Alex (ok) on 05-Фев-17, 18:27 
А, ясно. В борьбе "теоретической правильности" и практического удобства всегда побежадет удобство, так что ждём - или прогнутся, или не взлетит.
Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

64. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Ordu email(ok) on 05-Фев-17, 23:22 
> Добавить символ к строке - push(), добавить &str - push_str().
> Из &str - from(), из utf8 vec - from_utf8(), из Box<str> -
> into_string()
> из utf8 vec

Перегрузки функций нет в стиле C++ нет. И я отмечу, что вектор -- не utf8. Это программист может надеятся или даже верить, что вектор содержит utf8, но стандартная библиотека не верит и возвращает Result<String, какой-то-там-еггог>.

> из Box<str>

Box<str> -- это почти String, и into_string "скушает" Box<str>. into_string -- это суицидальный метод Box<str>, в том смысле что lifetime бокса закончится, и любое последующее обращение к нему приведёт к ошибке компиляции. Это именно into_string. Тут сложнее придумать более удачное название.

> И после этого пых ругают за бардак с наименованием функций.
> Но больше всего порадовало, что операция + позволяет сделать конкатенацию string и
> &str, но не позволяет двух string, нужно для второго string сделать
> преобразование в &str. И они удивляются, чего это конкатенация вызывает вопросы
> у людей знакомых с другими ЯП.

В rust нет перегрузки методов. Поэтому либо + будет складывать string и string, либо string и str. Первое иногда будет требовать создания String и копирования слайса в кучу, только для того, чтобы вызвать метод. Второе удачнее, потому что получить из string &str можно оператором &, с примерно нулём накладных расходов в рантайме:

s1 += &s2.

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

66. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Crazy Alex (ok) on 06-Фев-17, 16:35 
Все эти обоснования выглядят как "денег нет, но вы держитесь". Об удобстве программиста там подумать явно поленились.

Нет перегрузки методов? Ок, пользовательской нет. А что, нельзя было для встроенных типов сделать исключение? Вектор - не utf8? Ну ок, при конкатенации со строкой верифицируй и вывали ошибку, если там таки то, что в utf-8 не лезет. Из бокса что ни вытащи - он помрёт, насколько я понимаю - то есть когда с ним работаешь всё равно эту особенность надо держать в уме - так тчо нет никаких причин давать отдельное имя. Ну и феерическое "xxx".to_string - это вообще бред какой-то.

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

63. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Ordu email(ok) on 05-Фев-17, 23:01 
> Ну мне вот тоже непонятно, зачем этот to_string() - о константе компилятор
> знает абсолютно всё, намерение программиста также абсолютно прозрачно - зачем этот
> мусор?

Во-первых, не прозрачно. s имеет тип auto, и если не использовать to_string(), то туда будет положен именно слайс, статический и immutable. То есть, как минимум, придётся явно указывать тип для s. Во-вторых, неявные преобразования типов -- это ни-ни. В этом отношении раст даже немного вымораживает, нужно явно указывать преобразования, например, из single-float в double-float. Но в случае со строками я не вижу большой беды. Метод to_string создаёт новый объект, он выделяет память из кучи и копирует туда содержимое слайса. Идея сделать это неявным мне, честно говоря, не нравится нисколько.

>  push_str - там более маразм какой-то. От джавы нахватались, что
> ли? Нет, чтобы оператор конкатенации сделать.

Можно и при помощи оператора:

s += ", world";

>  Не, привыкнуть ко всем можно - но зачем делать заведомо неудобные конструкции?
> Отдельно реализованные строки и слайсы - это вообще какая-то совершенно непонятная
> избыточность.

Слайс -- это не строка, это что-то типа сишного массива, они фиксированного размера. &str -- это, грубо говоря, чисто синтаксическая обёртка вокруг &[u8] (указатель на массив из u8, unsigned char'ов, длина которого неизвестна в compile-time). И эта синтаксическая обёртка по-сути нужна только потому, что &str состоит из элементов переменного размера. &str даёт грядку методов для разруливания этого. Если бы rust использовал бы константного размера символы, то никто бы даже не заморочился бы создавать &char, все бы использовали непосредственно &[u8], &[u16] или &[u32], в зависимости от конкретного выбранного кодирования символов.

String же -- это обёртка над указателем на str, который располагается в куче. String заведует lifetime'ом этого str, динамически выделяет/перевыделяет/освобождает память.

Вся эта ситуация, на самом деле, напоминает C++, где есть char[], и есть std::string.

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

67. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от Crazy Alex (ok) on 06-Фев-17, 16:47 
"let mut s" - это похоже на желание получить что-то иммутабельное? Написал mut - получи изменяемую копию неизменяемого объекта. Запрет на очевидные неявные преобразования типа - это не "немного вымораживает", это идиотизм.

Чем String от slice отличается я понимаю. Я не понимаю панического страха перед неявными (но, разумеется, описанными в спецификации и совпадающими с ожиданиями программиста) преобразованиями типов, выделениями памяти и прочими исключениями, направленными на то, чтобы код легко писался и читался. В разумных количествах это только на пользу (а неразумные, вроде перла - тоже многим нравятся, хе-хе). В плюсах, кстати, в этом смысле сделано совершенно ожидаемо - std::string s "xxx" будет работать так же хорошо, как и std::string s = "x"; x = "y"; x += "xxx" и прочее. Не хуже всё это дело работает и в D, где строки иммутабельные.


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

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

69. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Ordu email(ok) on 06-Фев-17, 23:14 
> Все эти обоснования выглядят как "денег нет, но вы держитесь". Об удобстве программиста там подумать явно поленились.

Все перечисленные "неудобства" -- это просто "мне хотелось придраться, я придрался". Метод into_* в расте попадается не только в box'е, и глупо было бы делать исключения для box'а.

> "let mut s" - это похоже на желание получить что-то иммутабельное? Написал
> mut - получи изменяемую копию неизменяемого объекта.

Да. Чтобы не вваливаться в совсем уж академическую функциональщину привнесли возможность изменять объекты, но при этом всячески подталкивают кодеров работать с immutable объектами.

> Запрет на очевидные неявные
> преобразования типа - это не "немного вымораживает", это идиотизм.

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

> Чем String от slice отличается я понимаю. Я не понимаю панического страха
> перед неявными (но, разумеется, описанными в спецификации и совпадающими с ожиданиями
> программиста) преобразованиями типов, выделениями памяти и прочими исключениями,
> направленными  на то, чтобы код легко писался и читался.

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

Разработчики раста никогда не отказываются рассмотреть вопросы удобства, и они всегда готовы посыпать раст ещё одним слоем синтаксического сахара. Они делают это регулярно. Просто ваши "неудобства" сводятся к тому, что "а вот в C++/D/Java/(подставьте любой другой язык) сделано иначе". Rust -- не C++/D/Java/..., rust -- это rust.
У раста есть проблемы, но они гораздо интереснее, чем неудобства связанные с необходимостью использовать & перед строкой, при вызове оператора +. Например, его borrow-checker довольно туп, и иногда запрещает делать вполне невинные вещи. Скажем, там не работает такая конструкция:
v.push(v.len());
Не работает потому, что раст, компилируя это, пытается создать одновременно в пределах одного lifetime'а два указателя на v, один из которых mutable. Но это один из фундаментальных запретов языка -- либо один mutable указатель, либо много immutable, третьего не дано -- и поэтому программисту приходится делать подобные вещи создавая временные переменные.
И это реально ненужное неудобство.
Но https://internals.rust-lang.org/t/accepting-nested-method-ca...
Вкратце суть: разрабы не хотят подпирать этот кейс ad hoc костылём, и пытаются решить более широкий класс проблем (который в свою очередь подкласс проблемы добавления интеллекта borrow-checker'у), но такие вещи надо очень аккуратно выпиливать лобзиком.

Кстати, я отмечу, это имеет и свои недостатки: чем более сложное поведение будет демонстрировать borrow-checker, тем сложнее ньюфагу будет понять как он работает. То есть, с одной стороны ньюфаг будет реже спотыкаться об острые углы borrow-checker'а, но когда он будет входить с ним в конфликт, то происходить это будет исключительно на более сложных волосатых кейсах, где понять в чём собственно проблема будет существенно сложнее.

> Не хуже всё это дело работает и в D, где
> строки иммутабельные.

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

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

Запиливать в язык перегрузку операторов ради нескольких случаев осмысленного применения, типа векторов да строк -- это глупость. Да, я знаю, любовно и прельстиво работать с векторами/матрицами, когда есть перегрузка операторов. Но раст идёт на компромисс и позволяет это. Он позволяет перегрузку операторов, которая не требует перегрузки функций. Я не знаю ни одного примера кода, который бы становился сильно более сложным из-за отказа использовать перегрузку операторов в пользу подхода rust'а. Но при этом несложно придумать примеры кода, где перегруженность кода перегрузкой операторов или неявными преобразованиями типов потребует для написания грамотного и безбажного кода конкретного вникания в те API которые он использует. Опеннет очень любит развлекаться над php/js, где неявное преобразование строки к целому постоянно порождает баги. И избежать таких багов можно только одним путём -- запретив слишком вольно обращаться с типами. Потому что идея "набрать высокограмотных и высококвалифицированных программистов" не работает. Она может работать некоторое время, но первый же дедлайн, когда программисту придётся писать код в стрессовых условиях и быстро, привнесёт в код десяток багов основанных на неявных преобразованиях типов или на том, что не та версия перегруженной функции была вызвана.

Кроме того, ты в курсе, что сегодня SICP не в моде и вообще выпал из трендов? Если нет, то почитай объяснения Sussman'а (одного из авторов SICP), почему это так, что изменилось в технологиях, что записало SICP в список устаревших текстов, и почему Сассман прекратил читать курс SICP в MIT по собственной инициативе 20 (прописью: ДВАДЦАТЬ) лет назад: http://www.posteriorscience.net/?p=206
Сегодня программист использует API путём метода научного^W инженерного тыка. Потому что сегодня очень много этих API и знать в деталях все невозможно. Но чтобы это работало, надо чтобы API не содержал бы всяких неявностей, которые можно найти и запомнить лишь внимательно и многократно скуривая документацию. Либо с матюгами отлаживать программу, которая опять не работает. Надо чтобы изменения API не приводили бы к тому, что код начинает работать неправильно -- должно быть иначе: либо он продолжает работать так как работал, либо он перестаёт компилироваться. Неявные преобразования типов и перегрузка функций делает это не то чтобы невозможным, но потребует от разработчиков API постоянно рассматривать все возможные use case'ы, которые они нечаянно могут сломать, если добавят в API ещё один тип или ещё одну перегруженную функцию.

Rust решает эти проблемы самым надёжным путём: он их не создаёт. Одна из причин, почему я верю в то, что rust займёт со временем достойное место среди языков программирования -- это как раз то, что он на совершенно новом уровне решает проблемы, описанные Сассманом. Я уже кидал где-то здесь ссылку на: https://onesignal.com/blog/rust-at-onesignal/ , где автор расписывает как это работает при практическом применении раста для реальных задач:
> Being able to encode constraints of your application in the type system makes it possible to
> refactor, modify, or replace large swaths of code with confidence. The type system is our
> ultimate "move quickly and don't break things" secret weapon.

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

__________
Оу, кстати. В качестве оффтопа. Я как-то разглядывал sparse -- это библиотечка за авторством Торвальдса созданная для парсинга C. Она была задумана для каких-то там случаев работы с ядерным кодом, но она достаточно продвинута для того, чтобы позволить Торвальдсу в качестве демонстрации использования этой библиотечки написать компилятор C в asm. Я не знаю, используется ли эта библиотечка сейчас, но не в этом суть. Суть в том, что та sparse использует подход очень схожий с rust'овым. Только в C имплементации. Там везде используется что-то типа struct substring, которая фактически прямой аналог растового слайса -- это указатель куда-то в недра другой строки с указанием длины подстроки. И на этом подходе Торвальдс получил очень чистый, простой и понятный код, который легко перекидывает слайсы в функции, создаёт на их базе новые слайсы, возвращает их из функций, и все передачи происходят по значению, и нет необходимости дёргать malloc на каждый пунктуационный токен во входном потоке. Почитай сорцы sparse на досуге -- их чтение реально доставляет удовольствие, -- это позволит тебе понять плюсы подхода раста к работе со строками не вникая в сам раст. Только раст, в отличие от C, занимается отслеживанием lifetime'ов и избавляет от риска столкнуться с инстансом substring/slice, содержащим dangling pointer.
Кстати вот ссылка: https://sparse.wiki.kernel.org/index.php/Main_Page

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

13. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Анончик email on 04-Фев-17, 15:50 
>архитектур i686-unknown-openbsd

А что это такое? Опечатка или что-то, чего я не знаю?

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

14. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Parsee (ok) on 04-Фев-17, 16:10 
Это CHOST https://wiki.gentoo.org/wiki/CHOST
>ARCH - Specifies the CPU architecture.
>VENDOR - Specifies the hardware platform or vendor.
>OS - Specifies the operating system.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

15. "Доступен язык программирования Rust 1.15"  +2 +/
Сообщение от Аноним84701 (ok) on 04-Фев-17, 16:20 
> Это CHOST https://wiki.gentoo.org/wiki/CHOST

Это, скорее всего, все же "target-triplet", а не что-то генту-специфичное  ;)
https://gcc.gnu.org/install/specific.html
https://clang.llvm.org/docs/CrossCompilation.html
> The basic option is to define the target architecture. For that, use -target <triple>.

http://wiki.osdev.org/Target_Triplet
> Target triplets have this simple structure:
> machine-vendor-operatingsystem

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

16. "Доступен язык программирования Rust 1.15"  –3 +/
Сообщение от Аноним (??) on 04-Фев-17, 16:31 
>По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики.

Вот исправленный вариант текста, который должен был быть в тексте новости:

>По структуре язык Rust напоминает C++, но существенно отличается производительностью, причём не в лучшую сторону.

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

26. "Доступен язык программирования Rust 1.15"  –4 +/
Сообщение от Comdiv (ok) on 04-Фев-17, 19:07 
>По структуре язык Rust напоминает C++, но существенно отличается производительностью, причём не в лучшую сторону.

Вообще-то С++ оказывается довольно медленным, когда дело касается его относительно безопасных абстракций. Сравните, к примеру, скорость работы метода array.at, в котором есть проверка границ и стандартное обращение к массиву в Rust тоже с проверкой.

Серьёзная скорость С++ достигается, когда на нём программируют на Си-подмножестве.

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

29. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Аноним (??) on 04-Фев-17, 19:49 
И что же там так тормозит-то? Вот эта проверка — https://github.com/llvm-mirror/libcxx/blob/master/include/ve... , что там быстрее сделать можно было-то?

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

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

31. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от Comdiv (ok) on 04-Фев-17, 20:19 
> И что же там так тормозит-то? Вот эта проверка — https://github.com/llvm-mirror/libcxx/blob/master/include/ve...
> , что там быстрее сделать можно было-то?

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

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

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


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

35. "Доступен язык программирования Rust 1.15"  +/
Сообщение от anonymous (??) on 04-Фев-17, 22:06 
> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?

Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?

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

37. "Доступен язык программирования Rust 1.15"  –2 +/
Сообщение от Comdiv (ok) on 04-Фев-17, 22:21 
>> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?
> Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?

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

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

54. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok) on 05-Фев-17, 16:22 
"Магия" стандартной бибилиотеки, а тем более элементов языка вроде dynamic_cast отлично оптимизируется для соответствующих случаев. Может вы, конечно, пользуетесь каким-то печальным компилятором или оптимизации не включаете...

Как пример - оптимизация memmove в gcc - вполне себе библиотечные функции напрочь выносятся с заменой на оптимизированный машинный код.

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

56. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Comdiv (ok) on 05-Фев-17, 17:08 
dynamic cast не оптимизируется для тех случаев, в которых это нужно. Он либо вообще будет убран, поскольку тип заранее известен, но тогда он и не нужен, либо будет медленным, так как нужно учитывать множественное наследование. Не рассуждайте вообще, проверяйте. Я проверял, используя оптимизацию -O3 -flto https://github.com/ComdivByZero/test-ext-oop-insert-sort-eff...

> Как пример - оптимизация memmove в gcc - вполне себе библиотечные функции
> напрочь выносятся с заменой на оптимизированный машинный код.

Нет. Gcc давно трактует эту функцию как встроенную, то есть, поддерживаемую на уровне языка, а не библиотеки. Проведите эксперимент, объявите свою функцию memmove с другими параметрами, и посмотрите, что выдаст компилятор.

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

60. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok) on 05-Фев-17, 18:32 
Так и я ж о том, что трактует, как встроенную, хотф формально - это часть библиотеки. А что до наследования - компилятор знает всё дерево наследования, в том числе - было ли там множественное. Так что теоретически - никаких проблем. А на практике - dynamic_cast - это фича для крайних случаев и в общем случае не рекомендованная к применению. Соответственно, профита от его оптимизации - 0 целых 0 десятых.
Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

61. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Comdiv (ok) on 05-Фев-17, 19:07 
Но приведённый метод .at() он не тракует как встроенный. Ведь речь шла именно о неэффективности С++ абстракций по сравнению с Си. Поэтому мне и странно было слышать аргумент об эффективности абстракций Си для доказательства эффективности абстракци С++, хотя я сразу написал, что С++ достигает высокой производительности, когда на нём пишут на Си-подмножестве.

> на практике - dynamic_cast это фича для крайних случаев... профита от его оптимизации - 0

Зависит от задач. Я частенько использую его аналоги в других языках(сам С++ использую мало). Если в задаче есть необходимость в хранилище _разнородных_ элементов, то dynamic_cast - это гарантия целостности памяти, из-за невозможности приведения от обобщенного типа, которым оперирует хранилище к расширенному, которым оперирует пользователь хранилища.

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

68. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Crazy Alex (ok) on 06-Фев-17, 16:55 
В других языках есть свои best practices. Для плюсов оптимизация dynamic_cast не принциипальна.

Что до at() - надо посмотреть. По идее компилятор там ничего чудить не должен, рядовой же метод. Может, что-то с исключениями связанное.

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

70. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Comdiv (ok) on 06-Фев-17, 23:45 
> Для плюсов оптимизация dynamic_cast не принциипальна.

Как и автоматический контроль целостности памяти. Я и писал, что С++ оказывается довольно медленным, когда дело доходит до его относительно безопасных абстракций.

> Что до at() - надо посмотреть. По идее компилятор там ничего чудить
> не должен, рядовой же метод. Может, что-то с исключениями связанное.

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

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

36. "Доступен язык программирования Rust 1.15"  –3 +/
Сообщение от skybon (ok) on 04-Фев-17, 22:17 
Язык не может быть медленным - медленными бывают только реализации. И да, у референсной реализации Rust со скоростью всё в порядке.
Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору
Часть нити удалена модератором

48. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Led (ok) on 05-Фев-17, 02:26 
> Жопа не может быть медленной

Можешь, можешь.

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

50. "Доступен язык программирования Rust 1.15"  –1 +/
Сообщение от Аноним (??) on 05-Фев-17, 02:48 
>> Жопа не может быть медленной
> Можешь, можешь.

А вот и в каждой бочке затычок объявился.


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

55. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Crazy Alex (ok) on 05-Фев-17, 16:23 
Ну вон на питон в соседней новости глянь.
Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

27. "Доступен язык программирования Rust 1.15"  +1 +/
Сообщение от Аноним (??) on 04-Фев-17, 19:40 
>struct Foo where T: ?Sized {f: T,}

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

struct Foo<T> where T: ?Sized {f: T,}

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

51. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Аноним (??) on 05-Фев-17, 04:53 
Сразу  после того, как в расте починят одиночную кавычку в синтаксисе.
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

74. "Доступен язык программирования Rust 1.15"  +/
Сообщение от Аноним (??) on 09-Фев-17, 20:01 
В недавнем интервью Slava Akhmechet, создатель RethinkDB, сказал, что ему нравится этот язык. Правда разработка RethinkDB на нём не ведётся.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

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

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


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