1.1, Я (??), 11:25, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –24 +/– |
"высокого параллелизма выполнения заданий"
ага фирефокс так и блещет параллелизмом
| |
|
2.2, Аноним (-), 11:29, 04/02/2017 [^] [^^] [^^^] [ответить]
| +16 +/– |
а причем тут лиса? В ней на rust пока только один модуль...
А серво на этапе разработки.
| |
2.52, th3m3 (ok), 14:26, 05/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Откуда вы такие лезите? В Firefox, это нормально завезут - только к концу года.
| |
|
3.72, Вареник (?), 19:13, 08/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
И его придется запускать в "одноядерном" контейнере, чтобы не вешал всю систему.
| |
|
|
1.4, Аноним (-), 12:03, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +2 +/– |
>ага фирефокс так и блещет параллелизмом
так в firefox на rust пока только картинки обрабатывать
планируют, на rust написан servo, его и оценивайте.
| |
1.12, Аноним (-), 15:32, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Если даже у Рэймонда от раста батхёрт:
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.
Значит язык ещё очень сырой и не скоро будет готов для продакшена.
| |
|
2.24, Аноним (-), 18:34, 04/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
Если даже — а кто он вообще такой-то? Какой-то человек, который всю жизнь писал на си, и удивляется что ему приходится что-то учить чтобы писать на языке с другой парадигмой. Писал бы хоть когда-то на каком нибудь ATS/Clean или хотя бы окамле — и боли бы не было.
| |
2.25, Comdiv (ok), 18:57, 04/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>Значит язык ещё очень сырой и не скоро будет готов для продакшена.
Он сложный не потому что сырой, а потому, что такова его природа. Поэтому он не станет проще после стабилизации его библиотек и улучшения документации.
| |
|
3.62, Аноним (-), 22:46, 05/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> struct Foo‹T›where T: ?Sized {f: T,}
Этот синтаксис заставляет меня плакать... Ржавчина решила отобрать пальму самого неудачного синтаксиса у плюсов?
| |
3.73, Вареник (?), 19:17, 08/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
>>Значит язык ещё очень сырой и не скоро будет готов для продакшена.
> Он сложный не потому что сырой, а потому, что такова его природа.
> Поэтому он не станет проще после стабилизации его библиотек и улучшения
> документации.
Кому оно надо, если для мозгое...ва уже есть шаблоны в С++ и мегатонны кода?
| |
|
2.32, Ordu (ok), 20:38, 04/02/2017 [^] [^^] [^^^] [ответить] | +4 +/– | Я чесслово лучше о нём думал Не знаю даже почему, но почему-то я думал, что он ... большой текст свёрнут, показать | |
|
3.39, freehck (ok), 22:54, 04/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Не вижу больших проблем конкатенировать строки
Я даже получше примеры нашёл.
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, причём, как это бывает, сделать ещё неделю назад. Попытался человек сходу въехать, причём будучи завеленным другой работой, и как-то туго пошло. Все мы люди, все бывает спотыаемся.
| |
|
4.45, Ordu (ok), 01:08, 05/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Интересно, что его так смутило? Всё равно ведь в C придётся в куче выделить память для результата конкатенации.
Оглядываясь на себя -- я тоже занимался этим онанизмом в rust'е -- я предполагаю, что это способ освоения языка. Берём и отказываемся пользоваться стандартной библиотекой, чтобы не отвлекаться на неё, и спокойно себе пописывать вещи, которые насквозь известны и понятны. Это работает, как правило, но не в rust'е. В rust'е подобное тоже имеет смысл, но в качестве следующего этапа. Когда базовые вещи освоены, когда освоены основные вещи из std, вот тогда можно взять и почитать rustonomicon. И научиться писать String, Vec, LinkedList и прочие вещи ручками.
> Я бы не стал так поспешно крестить человека.
Простите, вспылил.
> Возможно, ему надо было сделать обёртку для какого-то демона на Rust, причём, как это бывает, сделать ещё неделю назад. Попытался человек сходу въехать, причём будучи завеленным другой работой, и как-то туго пошло. Все мы люди, все бывает спотыаемся.
Но всё же, справедливости ради, отмечу, что дело было иначе. Рэймонд заявил, что он хочет переписать NTPsec на языке посовременнее, что он уже ознакомился с Go, теперь берётся за знакомство с Rust. И максимум через неделю появился этот его замечательный пост в блоге.
| |
4.65, Аноним (-), 12:55, 06/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
>Всё равно ведь в C придётся в куче выделить память для результата конкатенации.
В крестах не обязательно, когда есть SSO у std::*string
| |
|
3.40, Буратино (?), 23:17, 04/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
>при чтении простыней текста, порождённых баттхёртом
Простыню полную бугурта накатал здесь именно ты.
>Это он ещё не пробовал реализовать какой-нибудь список. Интересно, что он сказал бы, когда, потратив дня два, он бы справился с операцией insert и, утерев со лба пот, задумался бы о том, как можно реализовать remove
А уж подобный язык будет предметом бесконечных насмешек со стороны более успешных и простых в освоении Яв, Сишарпов, Пыхов и всевозможных *-скриптов.
| |
|
4.41, Ordu (ok), 00:07, 05/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
>>при чтении простыней текста, порождённых баттхёртом
> Простыню полную бугурта накатал здесь именно ты.
И что с того? От этого баттхёрт C/C++ программистов перестаёт быть баттхёртом?
>>Это он ещё не пробовал реализовать какой-нибудь список. Интересно, что он сказал бы, когда, потратив дня два, он бы справился с операцией insert и, утерев со лба пот, задумался бы о том, как можно реализовать remove
> А уж подобный язык будет предметом бесконечных насмешек со стороны более успешных
> и простых в освоении Яв, Сишарпов, Пыхов и всевозможных *-скриптов.
Я не видел ни одной насмешки. Только безграмотные замечания. Не, я сталкивался с критикой, которая была осмысленной, но она ещё менее походила на насмешку. Ну и да, всем этим явам, сишарпам, пыхам и прочим, следует не на раст оглядываться, а на го. Он, выгрызая себе нишу, будет двигать именно их.
| |
|
5.42, skybon (ok), 00:47, 05/02/2017 [^] [^^] [^^^] [ответить]
| –5 +/– |
PHP ещё ладно, но у остальных Golang выгрызть ничего не сможет. Golang - это DSL для написания http-бэкендов и различных докер-сервисов. А всё потому что где заканчивается стандартная библиотечка начинаются жуткие ad hoc костыли из-за скудности языка.
| |
|
|
3.49, vstakhov (ok), 02:28, 05/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Его возмущение объяснимо: он думал, что все проблемы C раст решит автоматически, а вышло не так - везде заход солнца вручную (RC и рефаунты) и вышивание (та же семантика borrow). Вот только в расте об этом косяке скажет сам компилятор, а в C - в лучше случае статический анализатор. Хотя в данном случае я не знаю, что лучше: параноидальность раста или heartbleed от статического анализатора.
| |
3.53, Crazy Alex (ok), 16:15, 05/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну мне вот тоже непонятно, зачем этот to_string() - о константе компилятор знает абсолютно всё, намерение программиста также абсолютно прозрачно - зачем этот мусор? push_str - там более маразм какой-то. От джавы нахватались, что ли? Нет, чтобы оператор конкатенации сделать. Не, привыкнуть ко всем можно - но зачем делать заведомо неудобные конструкции? Отдельно реализованные строки и слайсы - это вообще какая-то совершенно непонятная избыточность.
P.S. Доки на Rust не читал, так, глянул по ключевым словам.
| |
|
4.57, angra (ok), 17:29, 05/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
Добавить символ к строке - push(), добавить &str - push_str().
Из &str - from(), из utf8 vec - from_utf8(), из Box<str> - into_string()
И после этого пых ругают за бардак с наименованием функций.
Но больше всего порадовало, что операция + позволяет сделать конкатенацию string и &str, но не позволяет двух string, нужно для второго string сделать преобразование в &str. И они удивляются, чего это конкатенация вызывает вопросы у людей знакомых с другими ЯП.
| |
|
5.58, 1111 (??), 18:22, 05/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Потому что в Раст это сделано правильно с учётом логики владения, чего в других языках нет.
| |
|
6.59, Crazy Alex (ok), 18:27, 05/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
А, ясно. В борьбе "теоретической правильности" и практического удобства всегда побежадет удобство, так что ждём - или прогнутся, или не взлетит.
| |
|
5.64, Ordu (ok), 23:22, 05/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Добавить символ к строке - 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.
| |
|
6.66, Crazy Alex (ok), 16:35, 06/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Все эти обоснования выглядят как "денег нет, но вы держитесь". Об удобстве программиста там подумать явно поленились.
Нет перегрузки методов? Ок, пользовательской нет. А что, нельзя было для встроенных типов сделать исключение? Вектор - не utf8? Ну ок, при конкатенации со строкой верифицируй и вывали ошибку, если там таки то, что в utf-8 не лезет. Из бокса что ни вытащи - он помрёт, насколько я понимаю - то есть когда с ним работаешь всё равно эту особенность надо держать в уме - так тчо нет никаких причин давать отдельное имя. Ну и феерическое "xxx".to_string - это вообще бред какой-то.
| |
|
|
4.63, Ordu (ok), 23:01, 05/02/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Во-первых, не прозрачно s имеет тип auto, и если не использовать to_string , т... большой текст свёрнут, показать | |
|
5.67, Crazy Alex (ok), 16:47, 06/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
"let mut s" - это похоже на желание получить что-то иммутабельное? Написал mut - получи изменяемую копию неизменяемого объекта. Запрет на очевидные неявные преобразования типа - это не "немного вымораживает", это идиотизм.
Чем String от slice отличается я понимаю. Я не понимаю панического страха перед неявными (но, разумеется, описанными в спецификации и совпадающими с ожиданиями программиста) преобразованиями типов, выделениями памяти и прочими исключениями, направленными на то, чтобы код легко писался и читался. В разумных количествах это только на пользу (а неразумные, вроде перла - тоже многим нравятся, хе-хе). В плюсах, кстати, в этом смысле сделано совершенно ожидаемо - std::string s "xxx" будет работать так же хорошо, как и std::string s = "x"; x = "y"; x += "xxx" и прочее. Не хуже всё это дело работает и в D, где строки иммутабельные.
Ну и да, вот в таких случаях и становится понятно, зачем именно нужна перегрузка операторов.
| |
|
6.69, Ordu (ok), 23:14, 06/02/2017 [^] [^^] [^^^] [ответить] | +2 +/– | Все перечисленные неудобства -- это просто мне хотелось придраться, я придрал... большой текст свёрнут, показать | |
|
|
|
|
|
1.13, Анончик (?), 15:50, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>архитектур i686-unknown-openbsd
А что это такое? Опечатка или что-то, чего я не знаю?
| |
1.16, Аноним (-), 16:31, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
>По структуре язык Rust напоминает C++, но существенно отличается в некоторых деталях реализации синтаксиса и семантики.
Вот исправленный вариант текста, который должен был быть в тексте новости:
>По структуре язык Rust напоминает C++, но существенно отличается производительностью, причём не в лучшую сторону. | |
|
2.26, Comdiv (ok), 19:07, 04/02/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
>По структуре язык Rust напоминает C++, но существенно отличается производительностью, причём не в лучшую сторону.
Вообще-то С++ оказывается довольно медленным, когда дело касается его относительно безопасных абстракций. Сравните, к примеру, скорость работы метода array.at, в котором есть проверка границ и стандартное обращение к массиву в Rust тоже с проверкой.
Серьёзная скорость С++ достигается, когда на нём программируют на Си-подмножестве.
| |
|
|
4.31, Comdiv (ok), 20:19, 04/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
> И что же там так тормозит-то? Вот эта проверка — https://github.com/llvm-mirror/libcxx/blob/master/include/vector#L1512
> , что там быстрее сделать можно было-то?
Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык? Серьёзно? Просто сделайте простейший тест и посмотрите.
> Там тормоза начинаются только в небесплатных вещах вроде RTTI и виртуальных вызовов,
> которые и на си так же работать будут.
Отнюдь. В Си может быть использовано минимально необходимое воплощение, которое может быстрей работать. В С++ же, к примеру, dynamic_cast как ни крути будет медленно работать из-за поддержки множественного наследования. В данном случае не работает принцип, что не нужно платить, за то, что не используется.
| |
|
5.35, anonymous (??), 22:06, 04/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?
Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?
| |
|
6.37, Comdiv (ok), 22:21, 04/02/2017 [^] [^^] [^^^] [ответить]
| –2 +/– |
>> Вас удивляет, что небольшой, но всё же библиотечный метод уступает в скорости возможности, встроенной в язык?
> Т.е. включается магия, которая отсутствует в "библиотечнjv методе"?
Это приблизительно такая же "магия", как преобразование арифметических действий непосредственно в машинный код без вызова вспомогательных функций. При благоприятных условиях компилятор мог бы оптимизировать и библиотечный код, но на практике этого пока не происходит.
| |
|
7.54, Crazy Alex (ok), 16:22, 05/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
"Магия" стандартной бибилиотеки, а тем более элементов языка вроде dynamic_cast отлично оптимизируется для соответствующих случаев. Может вы, конечно, пользуетесь каким-то печальным компилятором или оптимизации не включаете...
Как пример - оптимизация memmove в gcc - вполне себе библиотечные функции напрочь выносятся с заменой на оптимизированный машинный код.
| |
|
8.56, Comdiv (ok), 17:08, 05/02/2017 [^] [^^] [^^^] [ответить] | +/– | dynamic cast не оптимизируется для тех случаев, в которых это нужно Он либо воо... текст свёрнут, показать | |
|
|
|
|
|
|
2.36, skybon (ok), 22:17, 04/02/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Язык не может быть медленным - медленными бывают только реализации. И да, у референсной реализации Rust со скоростью всё в порядке.
| |
|
|
Часть нити удалена модератором |
|
5.50, Аноним (-), 02:48, 05/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Жопа не может быть медленной
> Можешь, можешь.
А вот и в каждой бочке затычок объявился.
| |
|
|
|
|
1.27, Аноним (-), 19:40, 04/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
>struct Foo where T: ?Sized {f: T,}
opennet, почини уже разметку. Ну несолидно же такому популярному ресурсу не иметь хотя бы способа отображать код моноширинным шрифтом и жрать тэги внутри.
struct Foo<T> where T: ?Sized {f: T,}
| |
|
2.51, Аноним (-), 04:53, 05/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Сразу после того, как в расте починят одиночную кавычку в синтаксисе.
| |
|
1.74, Аноним (-), 20:01, 09/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
В недавнем интервью Slava Akhmechet, создатель RethinkDB, сказал, что ему нравится этот язык. Правда разработка RethinkDB на нём не ведётся.
| |
|