Вы видите копию треда, сохраненную 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Под него уже, между прочим, активно разрабатываются безопасные высокопроизводительные веб-фреймворки (https://github.com/iron/iron) и игровые движки (https://github.com/PistonDevelopers/piston)
#rust #nogc #memorysafety
>С/C++
Это два абсолютно разных языка
>всех устраивает
Нет. Точнее не полностью.
>А там, где не устраивает, то есть Go.
Третий абсолютно другой язык, не решающий проблем плюсов и привносящий кучу своих.
>Это два абсолютно разных языка
Кекнул со специалиста по ЯП. Я их вынес в отдельную группу, так как большинство задач, которые решает С одинаково хорошо решает С++, и наоборот.
>Нет. Точнее не полностью.
Всех все устраивает.
>Третий абсолютно другой язык, не решающий проблем плюсов и привносящий кучу своих.
Go решил все проблемы плюсов :)
>#rust #nogc #memorysafety
поссал на тебя
ОП, хуле с шапкой? Надо добавлять больше инфы!
Пользуюсь этой хуитой https://github.com/phildawes/racer для EMACS - зависимость есть.
Алсо, доебали петухи, которые никогда не писали многопоточных приложений, то тем не менее кукарекающие о няшной и тем более о крестопараше.
Алсо, доебали петухи, не читавшие о задачах раста и го, но тем не менее кукарекающие о "преимуществах/недостатках" суслика и раста.
racer кстати охуенно работает и под саблаймом, с ним и linter'ом даже иде никакой не нужно.
Зачем ты это говно сюда принёс?
А конкретней? Iter::map, например, будет работать так же быстро как и обход коллекции в цикле?
Да, будет.
Для начала дай определение стоимости абстракций.
А потом обоснование нулевой стоимости в случае руст.
>так как большинство задач, которые решает С одинаково хорошо решает С++, и наоборот.
Кекнул со специалиста по ЯП.
Давай, иди ядро линукса на С++ допиши.
>Всех все устраивает.
Кекнул со специалиста по ЯП.
Если тебе задали делать laba1.cpp, это не значит, что язык устраивает всех.
>Go
Хуйни не неси, у языков разные ниши.
Ты слишком обдвачевался.
И привнес комплексный синтаксис, в котором можно сломать ногу и обоссать себе ебало.
Не могу понять, в чем проблема написать linux kernel на С++. Его изначально писали на С просто потому что С++ торвальдсу не нравится.
>Хуйни не неси, у языков разные ниши.
Да, которые на 75% пересекаются, а там где не пересекаются, то выбор — явный С.
Да.
Илюш, ну не бомби
Увы, но раст на указанную версию никак не тянет, много всяких нужных вещей в unstable висит. Но, судя по гитхабу и опросам, этот язык, даже в сыром виде, вызывает интерес у людей, значит что-то да выйдет.
https://github.com/showcases/programming-languages
>>523936
Несколько месяцев назад была непонятной хуйней, дублирующей функционал sdl, поверх которого написана, и непонятно почему названая "движком". Сейчас появилась некоторая абстракция. Но до полноценного фреймворка ещё очень долго.
Всё работает на принципе: ты пишешь свою кирилоподелку на пистоне и куски кода коммитишь мейнтейнеру. Года через 2 что-то да выйдет.
Какого хуя все окружение через жопу? Надо установить конпелятор, сырцы отдельно, дебагер отдельно, gdb для дебагера отдельно. Нормальных IDE нет, только бородатая ебля с vim/emacs. Так и задумываешься, а может нахуй его, если со времен сипласплас ничего не изменилось?
Ну так язык молодой, все понемногу пилится, скоро и иде нормальные будут. А что за ебля с вимом/емаксом? Там вроде все просто и удобно выходит.
Ебля, да.
Более-менее редактор:
https://users.rust-lang.org/t/using-atom-to-work-with-rust-under-win32/2280?u=brakmic
Может ещё под VS запилят нормальное что-то. Полноценной подсветки не хватает.
https://github.com/PistonDevelopers/VisualRust
Лучше бы под идею плагин навернули.
но у свифта нет даже 20% возможностей раста, не говоря уже что раст со своим зеро-оверхедом и ручным управлением памятью на типах подходит для железок, в то время как свифтопараша со своим ARC годиться только формочки для гейфонских аппов клепать.
чому же твой раст такой медленный?
ну и про 20% ты обычный кукаретик
Самое главное из того, что у раста нет, из того что есть в swift - сферы применения, современная ide и деньги Apple.
"гейфон гейфон кококо", как же вы заебали со своей гомоэротикой, никто так много не кричит о пидорстве как те кто боятся ими стать потому что латентные
Айособлядям платят все меньше и меньше, кстати, не советую. А начиналось все так хорошо.
мимо-айособлядь[/i/
Отфильтровать не забудь. Алсо, проиграл с этих хипстеров.
> чому же твой раст такой медленный?
Где это он медленный?
http://benchmarksgame.alioth.debian.org/u64q/rust.html
> ну и про 20% ты обычный кукаретик
Нет, ты. У раста есть статический анализ, когда же у свифта есть ссылочная дрисня.
> Самое главное из того, что у раста нет, из того что есть в swift - сферы применения, современная ide и деньги Apple.
Ну вот свифт и будет популярен среди разработчиков под iOS и OS X, как сейчас там популярен ObjC. Раст в вашу нишу не лезет, так что можешь быть спокоен.
ну что ты несешь то
то что в ранее менее популярную тему вкатилось много новичков и куча быдла, ранее за копейки на фрилансе заказывавшее сайты, начало заказывать за копейки ios приложения, значит только то что значит
ну раст уже запустили на ios кстати.
да эти бенчмарки только для потроллить годятся
то что есть сырые указатели, так они и в свифте UnsafeMutablePointer<T>
iOS и OS X то понятно, но после опенсурса то оно полезет всюду
про ваш хваленый анализатор уважаю мнение вот этого человека:
Если отвлечься от вопроса компромисса скорости и безопасности, то по дизайну самого языка у меня тоже есть вопросы. В частности, касательно пяти типов указателей. С одной стороны, это неплохо, когда программист задумывается о том, где лежат переменные, в стеке или куче, и могут или не могут с ними одновременно работать несколько потоков. Но с другой, представьте, что вы пишите программу, и оказалось, что переменная должна жить не в стеке, а в куче. Вы переписываете все, чтобы использовался Box. Потому вы понимаете, что на самом деле нужен Rc или Arc. Снова переписываете. А потом еще раз переписываете на обычную переменную в стеке. Все это — без нормальной IDE под рукой. И регулярки не помогут. Ну или же просто получаете ужасы в стиле Vec<Rc<RefCell<Box<Trait>>>>, привет, Java! Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти Box, Arc и так далее автоматически. Но почему-то эта часть работы переложена на программиста. Намного удобнее было бы просто писать val (в третьем-то тысячелетии!), а там, где надо, явно указывать Box или Rc. Разработчики Rust в этом смысле запороли всю идею."
Часто приводится аргумент, что 90% времени выполняется только 10% кода (что, насколько я понимаю, чисто эмпирическое правило — быстро найти строгих исследований на эту тему не удалось). Следовательно, бОльшую часть программы можно написать на безопасном Rust, а 10% «горячего» кода — на его unsafe подмножестве, и медленность текущей реализации Rust на самом деле не представляет собой проблемы. Ок, но тогда получается, что Rust вообще не нужен, потому что я могу написать 90% кода на Go, а 10% на Си. Только искатели серебряных пуль и оторванные от реальности те-еретики будут использовать Rust исключительно из соображений, что 100% программы можно написать как бы на одном языке. Хотя в действительности это два диалекта одного языка, что не так уж сильно отличается от связки Java плюс Си или Go плюс Си.
"
ну раст уже запустили на ios кстати.
да эти бенчмарки только для потроллить годятся
то что есть сырые указатели, так они и в свифте UnsafeMutablePointer<T>
iOS и OS X то понятно, но после опенсурса то оно полезет всюду
про ваш хваленый анализатор уважаю мнение вот этого человека:
Если отвлечься от вопроса компромисса скорости и безопасности, то по дизайну самого языка у меня тоже есть вопросы. В частности, касательно пяти типов указателей. С одной стороны, это неплохо, когда программист задумывается о том, где лежат переменные, в стеке или куче, и могут или не могут с ними одновременно работать несколько потоков. Но с другой, представьте, что вы пишите программу, и оказалось, что переменная должна жить не в стеке, а в куче. Вы переписываете все, чтобы использовался Box. Потому вы понимаете, что на самом деле нужен Rc или Arc. Снова переписываете. А потом еще раз переписываете на обычную переменную в стеке. Все это — без нормальной IDE под рукой. И регулярки не помогут. Ну или же просто получаете ужасы в стиле Vec<Rc<RefCell<Box<Trait>>>>, привет, Java! Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти Box, Arc и так далее автоматически. Но почему-то эта часть работы переложена на программиста. Намного удобнее было бы просто писать val (в третьем-то тысячелетии!), а там, где надо, явно указывать Box или Rc. Разработчики Rust в этом смысле запороли всю идею."
Часто приводится аргумент, что 90% времени выполняется только 10% кода (что, насколько я понимаю, чисто эмпирическое правило — быстро найти строгих исследований на эту тему не удалось). Следовательно, бОльшую часть программы можно написать на безопасном Rust, а 10% «горячего» кода — на его unsafe подмножестве, и медленность текущей реализации Rust на самом деле не представляет собой проблемы. Ок, но тогда получается, что Rust вообще не нужен, потому что я могу написать 90% кода на Go, а 10% на Си. Только искатели серебряных пуль и оторванные от реальности те-еретики будут использовать Rust исключительно из соображений, что 100% программы можно написать как бы на одном языке. Хотя в действительности это два диалекта одного языка, что не так уж сильно отличается от связки Java плюс Си или Go плюс Си.
"
> UnsafeMutablePointer<T>
> Unsafe
Ну ты понял.
> и оказалось, что переменная должна жить не в стеке, а в куче
Лол.
> Вы переписываете все, чтобы использовался Box. Потому вы понимаете, что на самом деле нужен Rc или Arc. Снова переписываете.
Лол x2.
> А потом еще раз переписываете на обычную переменную в стеке.
Лол x3.
> Rc<RefCell<Box<Trait>>>
Rc<RefCell<Trait>> же. Да и псевдонимы для типов никто не отменял.
> он мог бы выводить все эти Box, Arc и так далее автоматически
Не мог бы. Точно так же, как другие языки вообще говоря не выводят, передавать ли по ссылке или по значению.
> и медленность текущей реализации Rust
...которой нет.
> Хотя в действительности это два диалекта одного языка
Хуита. Unsafe лишь позволяет делать некоторые вещи, которые нельзя сделать без него. И заметь, владение и заимствования компилятор отслеживает даже внутри блока unsafe.
В расте на уровне типов можно описывать протоколы межпотокового взаимодействия. Получается корректность межпроцессового взаимодействия проверяется в компайлтайме тайпчекером. В свифте такое есть?
К слову, посмотри вообще тесты-то.
Pidigits: Unsafe и вызыв из C-ной библиотеки того же кода, что и в C версии. В 3 раза больше кода.
В 3 других - в 2 раза медленее, к тому же в два раза больше кода.
При этом C/C++ анализаторы имеют ту же функциональность, просто поставляются отдельно.
Хотя с тем же regex-dna было вообще плохо, помню. И причиной была отсутствие нормальной regex библиотеки. Теперь допилили и нормально идёт.
> При этом C/C++ анализаторы имеют ту же функциональность, просто поставляются отдельно.
Они не только поставляются отдельно, они ещё и не являются частью семантики языка.
>Ну ты понял.
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust, где, цитирую:
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
> и оказалось, что переменная должна жить не в стеке, а в куче
> Лол
ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
остальные лолы туда же
>Rc<RefCell<Trait>> же. Да и псевдонимы для типов никто не отменял.
и нахуй такая хуйня то нужна?
я вот на днях такую функцию в крестах написал:
template <typename T_Tupple, typename T>
auto valuesProxying(T_Tupple&& storeTuple, T jval) -> decltype(
std::tuple_cat(storeTuple, std::make_tuple(getJVal(jval))))
{
return std::tuple_cat(storeTuple, std::make_tuple(getJVal(jval)));
}
и все ради того чтобы в это обернуть с сигнатурами Jni джава типы и классы и не пришлось бы темплейтопидорасить в вашей джаве, а писать в крестах с помощью нормального человеческого auto
>Не мог бы. Точно так же, как другие языки вообще говоря не выводят, передавать ли по ссылке или по значению.
Ты слышал про c++ 14?
>...которой нет.
которая есть если писать без
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
>Хуита. Unsafe лишь позволяет делать некоторые вещи, которые нельзя сделать без него. И заметь, владение и заимствования компилятор отслеживает даже внутри блока unsafe.
все что не Unsafe по скорости как джава
>Ну ты понял.
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust, где, цитирую:
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
> и оказалось, что переменная должна жить не в стеке, а в куче
> Лол
ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
остальные лолы туда же
>Rc<RefCell<Trait>> же. Да и псевдонимы для типов никто не отменял.
и нахуй такая хуйня то нужна?
я вот на днях такую функцию в крестах написал:
template <typename T_Tupple, typename T>
auto valuesProxying(T_Tupple&& storeTuple, T jval) -> decltype(
std::tuple_cat(storeTuple, std::make_tuple(getJVal(jval))))
{
return std::tuple_cat(storeTuple, std::make_tuple(getJVal(jval)));
}
и все ради того чтобы в это обернуть с сигнатурами Jni джава типы и классы и не пришлось бы темплейтопидорасить в вашей джаве, а писать в крестах с помощью нормального человеческого auto
>Не мог бы. Точно так же, как другие языки вообще говоря не выводят, передавать ли по ссылке или по значению.
Ты слышал про c++ 14?
>...которой нет.
которая есть если писать без
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
>Хуита. Unsafe лишь позволяет делать некоторые вещи, которые нельзя сделать без него. И заметь, владение и заимствования компилятор отслеживает даже внутри блока unsafe.
все что не Unsafe по скорости как джава
>>524389
а не это я про регекспы подумал
в крестах просто другие средства контроля
но если ты не с фриланса сюда пришел то должен быть привычен к автоматическому тестированию, а при нем можно и анализаторы запускать
с таким же успехом можешь склонить на гитхабе clang и впилить сторонние статистические анализаторы туда и заявить что ты придумал совершенно новый язык
Кстати,компилятор раста написан на окамле изначально был напоминаю, где как раз таки отличный такой вывод типов
> те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust
Только reverse-complement и вызовы GMP в pidigits.
> ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
Ну у вас-то в плюсах понимают семантику владения и заимствования? Или таки пытаются подобрать тип указателя наобум, из-за чего делают рефакторинг каждые 15 минут?
> и нахуй такая хуйня то нужна?
А в чём, собственно, проблема? Вывод типов есть, так что всякие `Rc<RefCell<Trait>>` ты увидишь только в сигнатурах функций.
> которая есть если писать без
Опять же, единственный бенчмарк, где действительно это используется — reverse-complement.
> все что не Unsafe по скорости как джава
Что ещё расскажешь?
Посмотрел тут эту презентацию.
Rust, конечно, называют смешанным языком программирования (пп, ооп, фп), но тут я прихуел. > 9000 вещей взяты из фп. И без фанатизма.
Функциональщики пытались нормальным посонам подложить такую заразу!
Язык имеет не самый низкий порог вхождения, единственное что вызывает интерес большинства (как и Go) – авторитет компаний, его разрабатывающий. Навесь на него ещё тысячу фич и получишь неосваеваемый язык. Зачем каждый язык превращать в точный клон другого?
HKT не просто «ещё одна фича», это важная часть системы типов, позволяющая строить мощные абстракции. Добавление их к языку как минимум позволит избавится от костылей вроде `try!` и допилить интерфейс коллекций (некоторые вещи не реализованы из-за отсутствия HKT: https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#lack-of-iterator-methods).
Нет, это вещь уровня генериков.
http://www.hydrocodedesign.com/2014/04/02/higher-kinded-types/
Вот он звездный час аутиста - вместо ответа на вопрос обозвать блохами. Ведь иначе нахуя он это ненужное говно читал.
Я читал тапл пять лет назад - и с тех пор полезность этой книги не увеличилась.
Ой какое смешное слово, держите меня семеро. Давайте еще раз посмеемся над пистоном, это же так забавно.
«Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти Box, Arc и так далее автоматически. Но почему-то эта часть работы переложена на программиста.»
Да, он в большинстве случаев он знает о времени жизни, когда нет – явно указываешь.
Но назначение этих 5 указателей несколько обширнее. В обучающих материалах можно найти следующее: https://doc.rust-lang.org/book/references-and-borrowing.html#the-rules (пикрелейтед)
Проблемы в Rust'е на текущий момент в том, что они поторопились и зарелизили пустой язык. Они сделали это из-за того что, грубо говоря, готового на момент выпуска достаточно для написания библиотек. Нападки хейтеров, мягко говоря, вызывают удивление на фоне того, что язык только недавно пошел в массы. Откуда в языке появятся тысячи волшебных библиотек, если он только появился? Откуда в языке появятся миллиарды программистов, если он только появился? Откуда будут триллионы вакансий для него, если он только появился (к слову, эти заметки писались в Апреле, а 1.0 вышел только в Мае)?
Unsafe не замедляет работу кода. Более того, unsafe на самом деле не совсем уж и unsafe – он определяет границы существования небезопасного кода.
Библиотеки ещё не готовы, компилятор ещё не оптимизирован до конца, естественно результаты синтетических тестов отличаются от результатов gcc c. Тут будет интересно сравнить Clang C с Rust.
Ради стабилизации языка и стандартной библиотеки. До 1.0 раст едва ли был пригоден к использованию из-за постоянных изменений.
Скорее всего не будет.
Толсто.
Да, только servo умеет ровно в 200 раз меньше, чем Gecko. Когда серво выйдет на масштабы геки, будет сосать так, что начнет ссать себе на ебало
Развивают замену C++, путем использования Rust'а в реальном проекте
И движок сделанный под современные реалии им не помешает.
"Тратятся"? Да там порядка 5 человек с мозиллы и коммьюнити. Какие ж это траты
Но ведь
> Когда серво выйдет на масштабы геки, будет сосать так, что начнет ссать себе на ебало
Не слушай того дегенерата, будет работать достаточно резво, оптимизацией они будут заниматься позже.
А теперь скажи мне, почему оно вообще станет работать резво? Это про Rust только пиздят какой он охуенный, на деле он сейчас медленнее крестов в пять-шесть раз на реальных задачах. Почему в 2015 году Go уже показывает хорошую производительность и поощрает программиста, а Rust сосет по всем сравнениям и орет про систему типов?
> Go уже показывает хорошую производительность
> Rust сосет по всем сравнениям
Илюш, ты ошибся тредом.
Так он врядли будет быстрее, но у раста удобные средства для параллелизации кода, в отличии от крестов.
- ускорили компиляцию
- поддержали линковку с MSVS-бинарниками
- запилили DST
http://blog.rust-lang.org/2015/08/06/Rust-1.2.html
> Unwinding support is not yet available (the process aborts on panic), but work is underway to land it.
Ну обещали же пофиксить :(
dynamically-sized type - это дженерик типа, размер которого при компиляции неизвестен.
например в Java нет DST, поэтому там можно делать дженерики только поверх ссылочных типов. то есть ты можешь сделать [code]List<String>[/code] или [code]List<BigInteger>[/code], но не можешь сделать [code]List<int[]>[/code] или [code]List<long>[/code]. Частично в Java эту проблему решили ссылочными типами-компаньонами примитивных (например у int есть ссылочный аналог Integer, у char - Character) и автобоксингом (при попытке положить в дженерик-контейнер примитивное значения - автоматически будет создан объект связанного ссылочного типа).
Связано это с тем, что дженерик-контейнер должен на стадии компиляции знать размер объектов, которые в этом контейнере будут лежать. В общем случае это довольно сложно сделать, проще если такие объекты всегда будут иметь один и тот же размер. В случае использования только ссылочных типов этот размер всегда константен для конкретной JVM на конкретной платформе.
В Rust эту проблему решили и теперь мы можем класть в дженерик-контейнер объект любого размера, а не только размера ссылки. То есть ты можешь положить туда и ссылку, и число и массив. Это экономит память и время для записи и чтения данных в контейнере. Это и называется "типы динамического размера" - потому что размер типа, который лежит в контейнере, может меняться.
разметка проебана, но суть, надесь, понятна.
$ cargo new hello_world --bin --vcs none
$ cargo build
$ cargo run
Все заебись, сбилдилось. Обрадовался.
Потом иду на http://ironframework.io/ и просто добавляю
[dependencies]
iron = "*"
Делаю
$ cargo build
и хуяк - ошибка, не может найти файл openssl/h<какое-то говно>.h
Додумался через env указать пусть к include папке либы - помогло. Скомпилилось. Но настроение уже испорчено.
Потом, сука, беру пример на главной странице http://ironframework.io/ и хуярю его в main.rt.
Делаю
$ cargo build
и пиздец
note: ld: cannot find -leay32
ld: cannot find -lssl32
error: aborting due to previous error
Could not compile
Заебись, сука. Я в бешенстве. Гугл нихуя путного не выдал. Кто-нибудь сталкивался с таким говном? Как указать пути раз и навсегда, чтобы не ебаться каждый раз? Дайте гайд нормальный.
Пиздец, тебе же русским языком написали - не хватает libeay32.a libssl32.a, наверняка они есть в папке с openssl-ем, нужно указать папку к ним через LIBRARY_PATH
Это значит, что можно делать что-то вроде
[i32; n] и n во время работы программы определяется? В документации такое описано, но в 1.1 не получалось.
>не хватает libeay32.a libssl32.a, наверняка они есть в папке с openssl-ем, нужно указать папку к ним через LIBRARY_PATH
Их там тоже нету (в mingw т.е.). Нашел тут http://indy.fulgan.com/SSL/
А вообще, пошел на хуй. Вопрос был в том как решить эту проблему (я и сам могу). Суть в том, что приходится заниматься такой не нужной еблей. (это еще мне повезло, что был предустановлен mingw).
*не в том
Еще раз, я пишу не только под windows, а кроссплатформенное приложение.
> потому что приложение все равно будет кроссплатформенным и надо будет билдить под виной в итоге
Кросс-компиляция же. А ты думал кто-то и правда ебётся под спермой со всеми этими цигвинами и прочей неюзабельной хуитой?
Понятно. Значит, Петухан Куриханыч такое же ненужное красноглазое поделие, как и Go. Наверно, и Swift такой же.
Почему-то любой C/C++/Pascal код с кроссплатформенными библиотеками нормально собирается под любой платформой (как минимум под Windows и Linux).
Как у тебя он будет собираться, если ты библиотеки не приложишь к нему, наркоман?
Go умеет в кросскомпиляцию, собираю статические бинарники для всего, что можно, через gox.
Одной командой оно мне на все платформы собрало и на гитхаба релиз сделало. Куда проще - я даже не знаю. В c/c++/pascal такое можно сделать, чтобы еще потом либы не нужно было таскать за собой?
С 1.5 стало еще проще, не надо собирать тулчейн.
Вопрос ненужности опущу, а то обзовут Илюшей.
Вот только твит от другого Илюши:
https://mobile.twitter.com/jamwt/status/629727590782099456
Нужно. Потом может узнаешь, когда закончу.
Чем они отличаются технически?
И ещё. Вот у меня в некой структуре хранится какая-та другая структура (допустим, таблица, а в ней ячейки). И мне нужно получить данные ячейки (не изменяя). Уместно использование clone? Как заимствовать, если данные большие? Имеется в виду, какой самый оптимальный вариант для программы?
> Вот есть такие трейты как clone и copy. Чем они отличаются технически?
`Clone` предоставляет метод `clone()`, когда же `Copy` — маркерный типаж, меняет семантику перемещения на семантику копирования.
Чтобы реализовать `Copy`, нужно сначала реализовать `Clone`.
> И мне нужно получить данные ячейки (не изменяя). Уместно использование clone?
Зачем? Почему бы просто не взять неизменяемую ссылку на эти данные?
Есть в /pr/ такой восторженный персонаж. Зайди в готред чтобы застать его в естественной среде обитания.
Возвращать &? Я такое реализовывал, но не знаю насколько это правильно. Просто в справочнике написано, что следует при любой возможности реализовывать clone. Опять же, абсурдно, может я неправильно контекст понял.
> Возвращать &? Я такое реализовывал, но не знаю насколько это правильно.
Да, просто возвращать &. Не вижу каких-либо проблем с этим.
> Просто в справочнике написано, что следует при любой возможности реализовывать clone.
Возможность копировать данные бывает крайне полезна, тем более, что есть derive. Но это не имеет отношения к тому, как ссылаться на данные.
let mut s = Something::new(); // мутабельно
let a = s.get_x(); // Возвращает ссылку -> s перестает быть мутабельной
s.set_x(10); // ошибка
Хотя, конечно, решается с помощью { let a = s.get_x(); }
http://cglab.ca/~abeinges/blah/too-many-lists/book/
Ещё не до конца готов, но пойдет.
Более-менее подробно описывает все указатели, неявные проблемы с освобождением памяти при использовании Box и подводные камни с указателями (определяемые компилятором, но которые могут быть непонятные для новичка).
признайся, ты ведь написал этот пост, просто чтобы поднять ненужный никому тред о расте :)
Прочитал уже?
Вот смотрю код Servo. В коде 690 упоминаний unsafe, но 90% из них - просто текст из какого-то копипастного документа в тестах, остальное - подключение C/C++ кода. Т.е. обходятся без unsafe при написании кода, а по той статье складывается впечатление, что нет.
Поясните за Phantom types. Что за муть? Для чего нужна?
> Поясните за Phantom types. Что за муть? Для чего нужна?
Тип, параметризованный другим типом, значения которого не используются. По сути, добавление к типу параметра, который проверяется только на этапе компиляции.
Вот с примерами:
http://blog.jakubarnold.cz/2014/07/08/using-phantom-types-for-extra-safety.html
http://blog.jakubarnold.cz/2014/07/10/using-phantom-types-in-haskell-for-extra-safety-part-2.html
> Тип, параметризованный другим типом, значения которого не используются. По сути, добавление к типу параметра, который проверяется только на этапе компиляции.
Ну это и в доках написано.
https://github.com/servo/servo/search?utf8=✓&q=PhantomData
Вот маркер добавляется в тип, но нигде никаких проверок нет.
По ссылкам на блог - концепция понятна, но не вижу связи в расте (ссылка выше).
Или вот здесь.
https://github.com/servo/tendril/blob/0de69e948fdcd3fdc1133f5370007512939cb15d/src/tendril.rs
Как делается проверка?
http://www.servoexperiments.com/
Планы на Раст в (к?) 2016 году:
- Добавить новый слой представления кода (между Rust и llvm), который называют MIR. Разработчиков не должно задеть, но даёт некоторые новые возможности (см. далее пометки MIR);
- Изменить принцип сборки кода: сейчас компилируется весь код при каждом запуске, планируется делать компиляцию только измененных частей (MIR);
- Добавить поддержку для IDE на уровне компилятора. На данный момент поддержка будет специализироваться на двух IDE (скорее всего Visual Rust и Rust DT), а дальше как будет;
- « Специализация »: возможность реализации нескольких вариаций для одного трейта/типа;
- Сделать borrow checker (как там с терминологией на могучем?) менее фашистким, в данный момент он запрещает в некоторых случаях, когда не должен (MIR);
- Ну ещё рассказали в очередной раз про возможности системы плагинов на ночном (типа макрос для приведения регулярок в машинный код во время компиляции или валидация SQL запроса опять же во время компиляции);
- Кросс-компиляция (сейчас возможна, но затруднена) простой командой типа cargo build --target=платформа;
- Cargo install, nuff said;
- Расширение функций компилятора добавлением фичи "trace hooks" (?) с целью более легкой интеграции с высокоуровневыми языками, имеющими сборщик мусора (подразумевается в первую очередь Javascript).
> Ну это и в доках написано.
Ну так в доках так же написано, зачем это нужно: http://doc.rust-lang.org/std/marker/struct.PhantomData.html
ХОТЕТ
школьник-кун
>Поясните за Phantom types. Что за муть? Для чего нужна?
Вот представь что тебе нужен структура UID, но чтобы для каждого родителького типа нужен свой тип UIDов, которые бы не пересекались между собой.
Но внутри UID у тебя просто u64, а тебе надо куда то слить параметр T. Для этого делается так:
struct UID<T>{
inner: u64,
type: PhantomData<T>
}
Второе поле будет нулевой длинны, но компилятор уже не будет ругаться что параметр T не использован.
О, вот теперь понятно, спасибо.
Консолечка, бггг.
Подойдёт любая. Проверь, чтобы папка, содержащая бинарник карго, была в PATH.
Блядь, долбоеб тупой, тебе скорее всего это не нужно.
ну я с помощью rust shell все сделал. просто не понял, что-как с командой строкой делать
Если родными тулзами от мс, то вполне ничего.
Также среди требований было:
Допиливание #[no_std] (для встраиваемых систем; практически готово);
Ускорение компилятора (ну это и так было одной из целей);
Кастомный panic (?).
И они тоже.
> http://doc.rust-lang.org/nightly/std/thread/fn.catch_panic.html
Няша, это совсем не для штатной обработки ошибок. Читай https://github.com/alexcrichton/rfcs/blob/stabilize-catch-panic/text/0000-stabilize-catch-panic.md
> Stabilizing catch_panic does little to change the tradeoffs around Result and panic that led to these conventions.
Это тот, что 2013 года? По-новее ничего нету?
А ничего не происходит пока. Тем более, воскресенье.
http://www.youtube.com/watch?v=7q9vIMXSTzc
Вот старая презентация Серво (янв. 15).
~32+ минута - показывают замеры рендеринга при разных условиях, собрал в первую картинку.
Ну и другая информация:
Количество разработчиков Servo: ~12;
Количество разработчиков Gecko: >50;
Servo будет встраиваться в Gecko.
Судя по пикрелейтед они таки дохуя уже реализовали. Если он и в самом деле будет работать так же быстро как и обещают будет вин.
https://github.com/servo/servo/search?utf8=%E2%9C%93&q=std%3A%3Asimd&type=Code
Судя по всему еще нет, видимо из-за нестабильного std::simd
Нет, не только. Скрипты там тоже есть, просто многое пока не работает.
Конкретно здесь не работает именно постинг, открыть форму и ввести пост/капчу таки можно.
http://huonw.github.io/blog/2015/08/simd-in-rust/
Вот, кстати, час назад выкатили. Как минимум ещё 3 месяца не будет в стабильной.
Илюш, уйди.
конечно же Раст.
и вообще, какого хуя вы подняли этот тонущий никому не нужный тред?! его вчера еще даже на третьей странице не было, heheuhe
Извини, что у нас нет местного Илюши, Илюши не нужны.
Очевидно же, что всё увлечены работой над языком, переписываться некогда.
https://github.com/kbknapp/clap-rs/blob/master/examples/17_yaml.rs
https://github.com/kbknapp/clap-rs/blob/master/examples/17_yaml.yml
Наверно это как-то не особо правильно, но мне такие вещи нравятся. Сам думал о подобном, но в другой области.
Опять же, реализовано макросом. Встает вопрос: какими костылями подобные вещи будут дорабатываться, чтобы вписать в IDE.
Тоже самое, что мэмори пул.
Почему ты пишешь в треде сгнившего говна о системном языке?
Потому не отсутствие GC тянет за собой все остальное. Или простенько и все течет, как в С, или так.
some_struct { f1: 3, f2: f1 + 1 }
>язык позиционируется как потенциальная замена си и крестам
>Rust хоть где-нибудь еще не превратился в кресты?
Ну хуй знает
А с отладкой там как? Сам пока с VisualRust сижу, только из-за более-менее удобного дебага.
Хех. Это я со стороны говорю, сам вообще в notepad++ калякаю. А дебажить пробовал через консолечку, но это уныло вообще.
Даже это поделие на джаве работает быстрее, чем "редактор" атом.
Небольшие изменения в стандартной библиотеке
Поддержка Windows XP
Всё.
В 1.4 обещается полная поддержка MSVC.
> В 1.4 обещается полная поддержка MSVC.
Ну они и слоу, я думал, что с 1.2 уже без проблем работает.
Там это ещё была негарантированная фича, не для продакшена.
Алсо, язык ни хера не системный, как тут пытаются утверждать, на нем даже двухсвязный список без unsafe не написать, следовательно на системном коде все его преимущества ВНЕЗАПНО разбиваются об unsafe,
и остается только убогий вырвиглазный синтаксис с шаблонным питушением.
На самом деле Rust - это загон для быдлокодеров, по типу пикрелейтед.
школьник-кун
Альфа Servo к концу года.
Параллельно пилят также подобие Chromium Embedded Framework с новым движком.
Не знаю, я от туда выпустился.
Погоняло старое прост.
Ну и в подтверждение прошлого поста (сравнивать аналогичные методы):
Двухсвязный список на Си:
https://github.com/shkolnick-kun/bugurtos/blob/master/kernel/item.h
https://github.com/shkolnick-kun/bugurtos/blob/master/kernel/item.c
И в Rust:
http://doc.rust-lang.org/src/collections/linked_list.rs.html
Ты конеш хуй с пальцем сравнил, но читабельность этой хуитки на расте хуже чем читабельность stl в c++.
Эта хуитка на Rust - часть стандартной библиотеки, насколько я понимаю.
И я сказал, что сравнивать только аналогичные методы, ибо на няшной нет смысла писать итератор, т.к. это просто inem->next / item->prev, а шаблонное питушение в данном случае ващпе не уместно, только жизнь усложняет, а реальных профитов - ноль.
Реализация интерфейса итератора дает бесконечное число профитов - контейнер могут использовать алгоритмы стандартной библиотеки.
Зависит от конкретной реализации библиотеки, так что не аргумент.
К слову, разрабы говорят, что современные компиляторы позволяют избавляться от проверки границ при оптимизации. Итераторы имеют к этому отношения?
Но Степанов считает, что ООП и шаблонное питушение в частности - говно:
https://www.google.ru/url?sa=t&source=web&rct=j&url=http://blogerator.ru/page/oop_why-objects-have-failed&ved=0CBgQFjAAahUKEwjN1PC88IrIAhXCqXIKHYGDB0Y&usg=AFQjCNHvL6snm8xxa9JES6zfzODgK6_AUw
> К слову, разрабы говорят, что современные компиляторы позволяют избавляться от проверки границ при оптимизации. Итераторы имеют к этому отношения?
Да.
>ООП - говно
Да.
>шаблонное питушение в частности
Бред. Он основоположник шаблонов и автор STL. Шаблоны - это анти-ООП, что видно даже по С++ в вопросах типа "наследование или шаблоны". См. http://www.stepanovpapers.com/EoP-StanfordEE380.pdf
> Чтобы вскрыть корни подобного «культа отдельно-взятой технологии», Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла «тихая революция». Молодые сторонники теории относительности, массово пришедшие в номенклатуру университетов, тогда постепенно захватили власть в области преподавания физики, навязав свою малоизвестную, но столь любимую интеллектуалами того времени теорию относительности уже широким массам физиков.
> На самом деле, в то время имелись как положительные эксперименты и опыты, подтверждающие существование эфира, так и отрицательные. Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики
> После чего эфир был незаслуженно «закрыт» и отправлен в отставку, и вот, уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра.
О, так он ещё и кефирщик?
Ага, именно поэтому он написал stl на с++, используя классы и т.п.
Даже в презентации он не проч побаловаться перегрузкой операторов.
такой-то хэйтер ооп!
Question:
I think STL and Generic Programming mark a definite departure from the common C++ programming style, which I find is almost completely derived from SmallTalk. Do you agree?
Answer:
Yes. STL is not object oriented. I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people. In a sense, I am unfair to AI: I learned a lot of stuff from the MIT AI Lab crowd, they have done some really fundamental work: Bill Gosper's Hakmem is one of the best things for a programmer to read. AI might not have had a serious foundation, but it produced Gosper and Stallman (Emacs), Moses (Macsyma) and Sussman (Scheme, together with Guy Steele). I find OOP technically unsound. It attempts to decompose the world in terms of interfaces that vary on a single type. To deal with the real problems you need multisorted algebras - families of interfaces that span multiple types. I find OOP philosophically unsound. It claims that everything is an object. Even if it is true it is not very interesting - saying that everything is an object is saying nothing at all. I find OOP methodologically wrong. It starts with classes. It is as if mathematicians would start with axioms. You do not start with axioms - you start with proofs. Only when you have found a bunch of related proofs, can you come up with axioms. You end with axioms. The same thing is true in programming: you have to start with interesting algorithms. Only when you understand them well, can you come up with an interface that will let them work.
Без ООП очень легко. Вместо наследования - статический полиморфизм (т.е. compile time duck typing), концепты (т.е. тайпклассы) и варианты (т.е. ADT). Посмотри язык Clay. Это С++ без ООП и другим синтаксисом. Очень легкий и мощный язык. И круды клепать было бы нормально, с такой-то compile-time рефлексией сделать ActiveRecord.
Ну ты и сам понимаешь, что по форме это тот же ООП, на манер пердона. И в js тоже ООП, хоть вместо классов и какая-то хрень. Да даже в перле, где объект - это hashtable.
Тогда и в Хаселле ООП, чего уж там. Только весь мир не считает это ООП, ты уж не обессудь.
Содержательно - конечно, не ООП. Но Степанов-то говорит - ООП хуйня, алгоритмы надо задрачивать. Что для академического олдскульного CS-ника, конечно, понятно, но основной потребитель же - крудошлёп, для него альтернатива ООП - visual basic.
Основной потребитель творчества Степанова - модерновый любитель плюсиков-трусиков, который это ООП на хую вертел. И что в Clay, что в Rust - ООП выпилено. В Visual Basic (даже 6), ООП, кстати, есть.
Ну тут ты прав, наверное, потребитель тоже небыдло.
потреблял творчество Степанова, когда тот ещё трудился в SGI. возненанавидел и темплейты, и трусики, обыдлился
Хуясе ты дядя.
Хуй знает чем тебе темплейты (человеческие, а не Александреску-стал и boost::MPL) не угодили. Вообще, конечно, код тех времен довольно уебищен, стандарта начали придерживаться позже. Синтаксис тоже не очень. Но, с другой стороны, Clay показывает, что сама идея - ничего так.
Изначально их вообще препроцессор разворачивал, поэтому до стандарта был тот ещё адок: sgi, hp, ms и гнутый stl были во многом несовместимы. Причём самым человеческим был ms stl, внезапно не перевариваемый gcc. Ну и как-то получилось, что можно всё некритичное пилить на пердоне, а где нужно побыстрее, пилить к пердону модули: эффективность просто на порядок выше.
Я привел часть. этой цитаты в переводе на русский.
Цитата вроде как относится к пост-stl времени.
Кстати, шаблоны, и перегрузка операторов - это ооп, вроде как, так что отрицать ооп и при этом юзать перегрузки, это те еще взаимоисключающие параграфы(примерно как у проф. Орлова с системным подходом, ЛОЛ)
>>547606
охуительные истории!
https://ru.m.wikipedia.org/wiki/Rust_(язык_программирования)
Ах извинити прафессар, куда нам убогим до Вас!!!
Ты хоть понимаешь, что если в языке разрешена перегрузка операторов, то тогда любая закорючка может означать все, что угодно, и результатом 1+1 может быть "Ты - хуй!!!"?
Перегрузки операций и это зло на равные с ООП и шаблонным питушением, ящитаю.
Так и вызов функции может означать что угодно. Написал add(1,1), а там - "ты - хуй". Я уже писал что я по поводу этого "в программе кишки торчат наружу" думаю в go-треде:
"Go сделан сишкой с GC. А у сишки единственное достоинство перед С++, на которое часто тут надрачивают, - это отсутствия заднего двора у кода. То, что ты видишь, то и будет исполняться. Никто не кинет эксепшен, никто его не замаскирует. Никто не перегрузит оператор. И функции тоже никто перегружать не будет.
Это дает возможность писать простые утилиты с кишками наружу. Мечта работодателя, программист превращается в винтик.
В общем, идея довольно неплохая для простых корпоративных unix-way утилит - дать говноязык с кодом, выглядящим как говно, который не дает выебываться.
Т.е. пока все делали мечту программистов, гугл сделал мечту корпораций."
>Кококо злые корпорации не дают самовыразиться
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
Ну иди и пиши на Go, интеллектуал.
>Ты хоть понимаешь, что если в языке разрешена перегрузка операторов, то тогда любая закорючка может означать все, что угодно, и результатом 1+1 может быть "Ты - хуй!!!"?
И как это связано с утверждением "перегрузка операторов - это ООП"?
Самый известный ООП язык, где перегрузку запретили под мотивацией "ко-ко-ко индусы запутаются" - это Java. Еще был такой - Delphi. ООП с перегрузкой никак не связаны, перегрузка - это просто синтаксический сахар.
>Ну, в няшной и крестах такая адд будет возвращать char *
И при чем тут перегрузка? http://ideone.com/BoS7bP
Есть, опрератор "+" - это часть языка, а функция add, - нет, соответственно ошибки проще искать в случае add, - нагрузка на механизмы памяти и внимания меньше.
Не понял вопроса.
https://doc.rust-lang.org/book/ffi.html
Вроде бы полностью совместим с C, но нужно делать обертку unsafe. С C++ пока проблемы из-за отсутствия наследования.
Перегруженное костылями убожество С++ до сих пор на плаву из-за совместимости со старым добрым перегруженным костылями убожеством С++. Поэтому все, что ты можешь сделать, - это добавить еще костылей в С++.
Дело не столько в наследовании, сколько в mangle, в конструкторах/деструкторах, шаблонах. Да какой к чёрту взаимодействие с крестами, если крестовые бинарики разных компиляторов часто не совместимы друг с другом. Единственный нормальный байндинг, когда либо написанный под что-то, был qt для питона, но им пришлось свой парсер быдлокрестов запилить, ага.
Можно и статически линковать, читай внимательнее. Ну а про "заюзать .h файлы": есть bindgen, но он полезен скорее для разраба обёртки, чем для её пользователя, ибо unsafe.
Как будто связывая хацкель с каким-нибудь питоном у тебя есть другие альтернативы.
Да я просто в ахуе немного. Позиционирование, лол, может еще про фокус-группы расскажешь? Какая разница, кто там что позиционирует. Совсем у крестохейтеров крыша едет уже.
Те проекты, которые используют кресты, их уже не вернуть, это да. Но есть ещё много всякого legacy C говна, перед которым часто встаёт вопрос переписать/дописать на чем-нибудь более стильном/молодёжном. Начать с дописывания всегда проще, а для этого нужна лучшая совместимость с Ц. Пусть и unsafe поначалу - сишникам не привыкать. Зато новые растомодули будут и safe, и собой хороши.
Раст - не го, на нём стартапы сильно не попишешь. Но нужно как-то вгрызаться в рынок.
А куда деваться? Тот же го сейчас юзают там, где ещё года 3 назад выбрали бы петон или джаву - если это не позиционирование, то что? Новые сферы применения вместе с новыми языками как-то сильно не нарождаются, всегда приходится кому-то из-под кого-то стул выпинывать.
Это называется FFI и оно есть в любом языке. Иначе как ты будешь с системой общаться? Биндинги с libc (да хоть kernel32.dll) и вперед.
Надо, чтобы в будущем
http://habrahabr.ru/post/174017/
Мы могли бы не удивиться новости вроде GCC 5.8 6.8 завершил миграцию на Rust
Ваше мнение очень важно для нас. Оставайтесь на связи.
Операционная система использует концепцию экзоядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами. Вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях, но пользователь при этом имеет наивысшие привилегии в системе.
http://www.opennet.ru/opennews/art.shtml?num=43105
Пацаны вообще ребята. Не взлетит, но опыт полезный, да и на подсмотреть сгодится.
> В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях
Microsoft Singularity
Phantom OS
Не об этом. И та ось не нужна, и эта не нужна. Просто само то, что языку без году неделя, а на нём уже джаст фо фан пишут операционки с гуем, о чём-то да говорит.
Говорит что ты, маня, ура-патриот.
Вот на расте уже операционка есть. Похуй что ничего нового в ней, и это говно без целей, аля "мине панравелся раст и йа напейсал операцеонку пачитав таненбаума". Ещё похуй что такое дерьмо можно хоть на го или питоне написать, заебись теперь заживём. СЛАВА РАСТУ!
Хейтеры такие хейтеры. Ну, покажи-ка нам операционку на го. Собственно, раст и задумывался как системный язык с многопоточностью без сегфолтов. Сам факт её создания, это пруф его пригодности для лоу-лвл программинга, пейсательства драйверов и такого прочего. Собственно, шкала языков для написания операционок, от пиздецкого непортабельного лоу лвла через портабельность с сегфолтами и утечками памяти к норм языку выглядит так:
голый асм -> Си -> раст
Мань, ты хоть иходники этого вашего редокса читал?
Там unsafe на unsafe и unsafe погоняет, местами встречаются комментарии типа
TODO: remove memory leak...
Что это значит ты понимаешь?
Повторяю для трудноообучаемых:
Rust - это не язык системного программирования.
Rust - это прикладной язык программирования,
это безопасный загон для быдлокодеров, в котором можно писать программки без сегфолтов, которые может быть будут работать быстрее, чем програмки на сисярпе и жаве.
Я поддерживаю идею загона для кодо-мартышек, но низкоуровнемый системный код лучше писать на C, просто потому, что при этом будет затрачено меньше человекочасов на разработку и отладнку.
https://github.com/redox-os/redox/blob/master/src/common/src/context.rs
Сотри строку 69, лалка.
>просто потому, что при этом будет затрачено меньше человекочасов на разработку и отладнку.
Ты бредящий луддит.
Это же llvm-язык, хули там может не работать?
>>555236
> Там unsafe на unsafe и unsafe погоняет, местами встречаются комментарии типа
> TODO: remove memory leak...
$ find ./ -name ".rs"|xargs grep -Rc "unsafe fn" |awk -F\: '{a=a+$2}END{print a}'
278
$ find ./ -name ".rs"|xargs grep -Rc " fn " |awk -F\: '{a=a+$2}END{print a}'
3889
$ find ./ -name "*.rs"|xargs grep -Rc "unsafe {" |awk -F\: '{a=a+$2}END{print a}'
596
3889 растофункций, из них 278 unsafe функций, 596 unsafe блоков. Сравни с цэ, где вообще всё unsafe.
>>555528
у чувака из Лозанны получилось
http://antoinealb.net/programming/2015/05/01/rust-on-arm-microcontroller.html
278+596=874
875/3889*100%=22,5%
То есть до 22,5% функций зашкварено...
Прикольная арифметика, чо!
22,5% unsafe, это в 4.5 раза более safe, чем C/C++. И это операционка, где без unsafe никак.
Есть ещё проект https://github.com/uutils/coreutils , там unsafe ещё вроде бы ещё больше:
coreutils$ find ./src/ -name ".rs"|xargs grep -Rc "unsafe {" |awk -F\: '{a=a+$2}END{print a}'
123
coreutils$ find ./src/ -name ".rs"|xargs grep -Rc "unsafe fn" |awk -F\: '{a=a+$2}END{print a}'
12
coreutils$ find ./src/ -name "*.rs"|xargs grep -Rc " fn " |awk -F\: '{a=a+$2}END{print a}'
264
однако где-то половина утил написана вообще без unsafe.
Спасибо, что-то я совсем затупил.
От себя добавлю найденный вчерашний коммит в trpl https://github.com/DanielKeep/rust/blob/702b6e552cc4fd5e20dff345e82327dc5a8eb613/src/doc/trpl/syntax-index.md может кому пригодится.
бамп
Ты сука, не говори, что он самый лучший, если это не так. Ты другие языки тестил? Вот и заткнись сука
У каждого ядра процессора есть некоторый контекст - содержимое регистров, счетчик инструкций, и т.д. Если нужно на одном ядре выполнять несколько задач, ОС не запаривается, и хранит контекст для каждого потока, и при переключении потоков сохраняет/загружает в регистры нужные значения для каждого потока. Для х86 с его неебическим набором регистров такое переключение занимает ощутимое время, которое впрочем можно значительно сократить, если сохранять только изменившиеся регистры. Шедуллер ОС этого сделать в принципе не может, зато на уровне компилятора-рантайма языка - это вполне выполнимая задача. Естественно, такие потоки будут не совместимы с остальным окружением, зато цена на переключение потока будет минимальна, и количество исполняемых потоков можно увеличивать на порядки, не думая о быстродействии.
Слышал от Фицпатрика, что в Go есть go-рутины, и их можно делать очень много. Получается, они также основаны на частичном сохранении контекста?
Да, принцип везде одинаковый.
Это не делает такую ось более безопасной, ибо ошибки в реализации алгоритмов один хрен не исключены, алсо 22% говнокода достаточно, чтобы скатаить безопасность в говно.
То есть применение rust в системном программировании не снимает с программиста обязанность формального доказательтва верности алгоритмов ядра и не гарантирует отсутствие ошибок, в том числе опасных.
Плюс постоянное надрачивание на ООП, и шаблонное питушение везде снижают эффективность программ.
Плюс вырвиглазный синтаксис.
Все это делает rust не нужным с системном программировании, ибо есть более годные инструменты.
Более правильный подход ниже:
Googl pragmatic bare metal rust
Могут быть разные реализации:
1. Процессы/потоки - сохранение всего контекста планировщиком ОС, у каждой задачи свой стек, медленно, жрет довольно много памяти, надо замарачиваться с синхронизацией, зато универсально, годится для Hard RT, иногда работает быстрее других реализаций;
2. Автоматы - пишем многозадачность руками, стек один, все происходит синхронно, в случае фиксированного числа задач годится для Hard RT.
3. Сопрограммы/протопотоки - фактически автоматы, но невооруженным глазом их не видно, пишем задачи в имепративном стиле, стек один, все по большей части синхронно, но иногда таки приходится заморачиваться с синхронизацей, в случае фиксированного числа задач годится для Hard RT.
>И это операционка, где без unsafe никак.
Бич плиз!
Зойчем использовать rust там, где без unsafe - никак?
И кстати, мартыханы в любом месте могут запилить unsafe блок или функцию, и, соответственно, заниматься говнокодерством на этом вашем "безопасном" rust.
Так что я вообще не понимаю, зачем там сделали unsafe, если он сводит на нет всю эту вашу #memorysafety #nogc...
> И кстати, мартыханы в любом месте могут запилить unsafe блок или функцию, и, соответственно, заниматься говнокодерством на этом вашем "безопасном" rust.
Добавление/изменение блоков unsafe можно детектить автоматически при ревью. И, соответственно, приложить большее вниманию к подобному говнокоду.
> Так что я вообще не понимаю, зачем там сделали unsafe, если он сводит на нет всю эту вашу #memorysafety #nogc...
А разгадка проста: небезопасный код следует всегда оборачивать безопасным API. Естественно, «ну я прост немношк опасного кода где попало» сводит безопасность раста на нет.
>Добавление/изменение блоков unsafe можно детектить автоматически при ревью. И, соответственно, приложить большее вниманию к подобному говнокоду.
И че?
>А разгадка проста: небезопасный код следует всегда оборачивать безопасным API. Естественно, «ну я прост немношк опасного кода где попало» сводит безопасность раста на нет.
Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
Хочу безопасный код - пишу с использованием библиотеки, не хочу - пишу говнокод как раньше...
Где преимущество раста, мань?
> Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
да ничего, собственно
> Хочу безопасный код - пишу с использованием библиотеки, не хочу - пишу говнокод как раньше...
пиши, хуй с тобой. Вот только кресты, это такая аморфная раздутая поебень, что библиотек этих может быть тысячи. Можешь использовать 993-ю либу, а можешь не использовать. Индус, который писал этот код до тебя, мог использовать 1231-ю либу, а мог не использовать. А безопасная реализация в расте - одна и включена по-дефолту.
Ещё на кресты попизжу. Всем они хороши - хошь, пиши, как на голом Цэ, хошь, функциональщиной балуйся, можно даже инкапсулировать. Дохуя возможностей - каждый выбирает, что ему по душе. В итоге имеем кучу неподдерживаемого говнокода, из-за того, что кучка долбоёбов пытается сделать швейцарский на базе скальпеля.
>Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
Объем работ помноженный на ебанутость и эзотеричность языка шаблонов плюс необходимость поддержки со стороны хотя бы стандартной библиотеки и минус целесообразность (кто ж захочет пердолиться с кривым набором костылей?)
>кто ж захочет пердолиться с кривым набором костылей?
Хотя плюсоебам не привыкать, у них весь язык такой.
В любом случае, если раст даже хотя бы на минимуме выстрелит, его ждет та же судьба. Для тех же людей разрабатывали.
Так раст писали матерые крестобляди. Ты обрати внимание, что на него бугуртят сишники и школьники.
Не спорю. Потому что проектировалось уже в наши дни, с опытом. Но это его не защитит от превращения со временем в C++ в плохом смысле.
> Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
То, что за пределами этой библиотеки безопасность вообще ничем не гарантируется?
Ну хуй знает. Думаю, до такой же степени запущенности дойти не должно, потому что язык с самых ранних альф обкатывался на практике.
О, адекват в треде!
>>558096
Ух ты, не знал, что написать класс-шаблон со встроенной блокировкой чтения/записи, класс-шаблон массива с контролем границ и еще несколько вспомогательных шаблонов это такой огромный объем работ, лол.
>>558178
мань, то, что за пределами растаможка тоже, да и в пределах...
>со встроенной блокировкой чтения/записи
Ты в рантайме блокировать чтение/запись собрался что ли? Совсем ебанутый? Или просто раста в глаза не видел?
Ну фиг знает, ОС 20 лет обкатывали на практике, до такой степени запущенности дойти не должно. :3
Обкатывали не разработчики, да и проект в разы больше => более медленная обратная связь.
> мань, то, что за пределами растаможка тоже, да и в пределах...
Ок, объясню попроще: да, ты можешь написать безопасные абстракции в С++. Но при этом ничто не гарантирует, что код, использующий эти абстракции, не является кривым небезопасным говном. Раст же гарантирует, что использующий безопасные примитивы код безопасен.
Совсем кратко: в расте опасный код инкапсулирован.
1. Раст запускается поверх небезопасного рантайма.
2. Даже если рантайм написан на раст, это не делает рантайм безопасным, и тем более не делает корректными алгоритмы работы такого рантайма. Во всяком случае до тех пор, пока нет формального доказательства корректности алгоритмов.
>>558198
Прикинь! Это делают уже несколько десятков лет!
https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%BD%D0%B8%D1%82%D0%BE%D1%80_(%D1%81%D0%B8%D0%BD%D1%85%D1%80%D0%BE%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F)
>Прикинь!
Удивил-удивил. Только какое это отношение имеет к расту?
Повторю вопрос: совсем ебанутый или просто раста в глаза не видел?
> Даже если рантайм написан на раст, это не делает рантайм безопасным, и тем более не делает корректными алгоритмы работы такого рантайма.
Само собой, полную гарантию может дать разве что код в зависимых типах, полностью покрытый доказательствами. Но практической стороны это не меняет: в С++ нет ничего, что могло бы предотвратить написание некорректно использующего память кода, когда же компилятор раста способен отсеять множество разновидностей некорректного кода.
Зачем пилить новый язык с вырвиглазным синтаксисом, если можно сделать либу для уже существующего, которым пользуются куча людей по всему миру, под который есть куча тулзов под совершенно разные архитектуры и ОС?
Создатели руста совсем ебанутые, или как?
Ясно @ Понятно
https://doc.rust-lang.org/stable/book/concurrency.html
мань, в расте именно мьютексы и используются, и что характерно, с проверками в рантайме, прикинь!
А разгадка проста: невозможно предсказать, когда какой поток попытается читать/писать переменную.
Ты документацию по своему любимому языку читал вообще?
Если б ты почитал что-нибудь ещё в дополнение к той странице, то выяснил бы, что на этом обеспечение безопасности не заканчивается и что немалую работу выполняет компилятор.
Ну реализуй. А то раскукарекался тут: можно да можно. Иди и сделай, потом покажешь.
http://habrahabr.ru/post/268849/
И опять же GC. Мог бы по крайней мере ATS предложить.
> а как мне получить копию первого элемента
http://doc.rust-lang.org/std/clone/trait.Clone.html
Спасибо. Я должен реализовать трейт copy для моего типа и вызывать list.front().unwrap().copy(), правильно?
*list.front().unwrap().clone()
> трейт copy
Не `Copy`, а `Clone`. И вызвать метод `.clone()`, соответственно.
`Copy` же используется для того, чтобы тип имел семантику копирования вместо семантики перемещения.
Да, и обрати внимание на `derive`: http://rustbyexample.com/trait/derive.html
О, опять пидоRustы повылазили. Сажи даунским выблядкам.
а) Использовать структуру как ключ - плохая идея.
б) Использовать Option в ключе - плохая идея.
в) А и б.
г) Просто нужно использовать другой хешер.
д) Оскорбить меня.
Пример с кодом http://pastebin.com/1CY7rgSs хоть здесь разница не так критична, но все равно замета.
Rust это такой прошлый год, думаю учить Плокс Плокс, за ним будущее, думаю Плокс Плокс будет актуален целых три месяца, потом надо будет перекатываться на Финксер, месяца на полтора его хватит, после чего надо будет все проекты переписать на Грувере, который протянет месяц до того как устареет.
Программирование эта крута, посоны.
Да ты тут, походу, самый продвинутый. Я тебе дам нубский
адвайс:
Попробуй сравнить скорость с
`struct S { a: u8, b: u8, c: u8, d: u8}` - если будет быстрее, то отрепорть баг о падении производительности при использовании Option в ключе. По сути это то же, как если бы ты добавил d: bool или d: u8 для индикации состояния c. Если падение будет тем же, значит ничего не поделать - `struct S { a: u8, b: u8, c: u8 }` легко представить как простой u32, а с пятой переменной нужен уже u64. Ещё можно такой хак - если c не занимает весь байт, попробуй заменить его на i8, т.е. `struct S { a: u8, b: u8, c: i8}`, отрицательные значения будут вместо None. Ну или напиши свой однобайтовый тип с подобным поведением.
Не получится, для реального межпотокового взаимодействия придется использовать Mutex<T>,
и делать захват/освобождение блокировки руками.
гонки возникают тогда, когда ты делаешь многопоточный доступ к данным, в этом случае рустерам приходится использовать мьютескы, так же, как и всем остальным.
В однопоточной программе все эти правила защищают только от одного - использования неинициализированных указателей/попыток доступа к освобожденной памяти.
> рустерам приходится использовать мьютескы
https://kgv.gitbooks.io/rust_book_ru/content/src/references-and-borrowing.html
фишка в том, что без них в расте никак. В сях/плюсах нет никаких гарантий, что индус, писавший код, не раздал один и тот же указатель под честное слово 8 потокам. В этом плане раст должен понравиться ынтерпрайзу - часть работы строгих манагеров и код-ревьюшников берёт на себя конпелятор.
А что тебе помешает в расте не объявлять мьютекс?
У тебя будет ровно одна ссылка с правом записи, правил не нарушены.
Вот только запись будет идти в одном потоке, а чтение в нескольких...
> А что тебе помешает в расте не объявлять мьютекс?
Компилятор. Да, он отслеживает не только заимствования.
См. типажи `Sync` и `Send`.
http://doc.rust-lang.org/std/marker/trait.Sync.html
http://doc.rust-lang.org/std/marker/trait.Send.html
Ты оказался прав, все дело в размере структуры используемой как ключ ну или в количестве значений для которых нужно найти хеш.
При сравнении `struct Without { field: u32, field2: u32 }` и struct With { field: Option<u32> } производительность одна и та же, `mem::size_of::<T>()` показывает что размер обеих структур 8 байт.
А по поводу решений что ты предложил, это понятно, просто хотелось чтобы все из коробки, да и заниматься таким рано - сами структуры могут измениться еще не раз.
[code]
let result = match hashmap.get(&key) {
Some(result) => result,
None => {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
},
};
[/code]
Тоесть если значение с таким ключом не найдено, то добавляем его и возвращаем. Что естественно не работает так как map уже захвачен для чтения match. Может есть какое-то общепринятое решение для таких ситуаций?
if let Some(r) = hashmap.get(&key) {
r
} else {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
}
Не работает?
Вообще, обещали починить такие случаи, если не ошибаюсь.
Не работает, говорит что не может захватить, так как предыдущий захват произведен здесь
>if let Some(r) = hashmap.get(&key) {
Вот так работает https://play.rust-lang.org/?gist=36dd730d40e401cfad39&version=stable
Без `map.contains_key()` не получилось обойтись.
Забавно, а как там учитывается, что не на всех архитектурах можно за один такт прочитать/запсиать указатель или еще какой-нибудь флоат?
Будете блокировки к каждому указателю присобачивать?
Указатель уж всяко на любой не совсем поехавшей - адрес же должен в регистр влазить, а регистр - атомарно записываться. А на совсем поехавших или раста нет, или тредов.
/Б/ратиш, раз уж языг претендует на нишу низкоуровневого системного,
то нужно озаботиться подобными вещами на этапе проектирования языка/конпелятора.
На таких архитектурах крутятся ОС, в т.ч. ОСРВ, а раста там нет...
Собственно его почти везде нет, только хуй86 и некоторые армы...
Ну довольно сложно вспомнить архитектуру, в которой есть и потоки, и неатомарная запись word (хотя бы aligned). Главное - там и для C придётся синхронизацию пердолить, так что раст тут никак не проигрывает.
> Будете блокировки к каждому указателю присобачивать?
Зачем к каждому? Только к тем, что указывают на изменяемые данные.
Для них синхронизацию везде запиливать придётся, не только в расте.
Ну так там указатели имеют тираж sync же,
То есть страстность придется обеспечивать однообразно для всех...
> Ну так там указатели имеют тираж sync же
Верно. Но менять указатель никто не позволяет (T: Send означает, что можно раздавать по тредам &T. Но ты не можешь создать &T, пока существует &mut T). Менять данные по указателю из нескольких тредов тоже нельзя: & &mut T пригоден только для чтения.
Так что все Sync-типы или с синхронизацией, или строго read-only.
Тогда будет оверхед на снихронизацтю...
Нет, я конечно не против того, что абизянки не смогут накосячить при всем желании, но для меня дико так бездумно расходовать процессорные так ты...
Если уж приделывать синхронизацию, то к более крупным объектам.
Ну и примитивов синхронизации побольше бы.
> Если уж приделывать синхронизацию, то к более крупным объектам.
Ничто не мешает приделать синхронизацию к более крупным объектам. Главное, чтобы она вообще была.
> Ну и примитивов синхронизации побольше бы.
Ну а здесь уже берётся unsafe и запиливается требуемый примитив.
Почитал тут немного форумов в интернетах. В большинстве случаев при сравнении Rust и Go люди делают выбор в пользу Rust несмотря на то, что он сыроват. В связи с чем у меня возникли вопросы:
1) Зачем их вообще сравнивать? Емнип, Rust изначально создавался как язык для высоконагруженных серверов, а Go - ЯП общего назначения. Веб на нём писать конечно удобно, однако это не сужает весь спектр его возможного применения
2) Почему таки люди выбирают Rust? Чем плох Goкроме очевидного отсутствия шаблонов?
1) Если проект может жить со сборищиком мусора, использовать язык без него - идиотизм.
2) Goвно можно использовать для примитивных предметных областей, на нем сложно строить абстракции или описывать сложные алгоритмы я не про числодробилки, которые все равно написаны на фортране и С, а про сложную бизнес-логику. Goвно - хороший инструмент с точки зрения менеджмента: любого дауна можно посадить писать код и он его напишет и результат будет даже читаемым. Собственно для этого он и придуман.
Выводы делай сам.
> 1) Зачем их вообще сравнивать
Их не то что бы сравнивают. Проблема в том, что они появились относительно недавно друг друга и оба созданы известными компаниями. В связи с чем у них имеется конкуренция за потенциальных пользователей, потому что им нужно преодолеть некий минимум чтобы реализовать свой потенциал и не провалиться.
> Rust изначально создавался как язык для высоконагруженных серверов, а Go - ЯП общего назначения.
Это ты специально реверс сделал?
Rust создавался как альтернатива C++.
Вот как раз-таки у Go основное применение – высоконагруженные серверы.
> 2) Почему таки люди выбирают Rust? Чем плох Go
Rust ещё, как ты сам сказал, сыроват. В продакшене, помимо мозиллы, используется только где-то 5-ю фирмами и пока ещё не соответствует их требованиям.
Go выбирают там, где он имеет преимущества перед его конкурентами. См. выше.
Остальное описал >>564962
К слову, по поводу умственных способностей. Не мизогинист, но программистов-женщин на языках типа Go (процедурных с минимум синтаксического сахара) намного больше, чем на языках типа C++. Ну хачкель само разумеющееся.
Программистов на го вообще просто больше, аналогично можно сравнить веб-макак и крестовиков.
Хачу-хачу, особенно cargo install. С моим интернетом сложна что-то каждый раз скачывать и проверять. Есть конечно различные способы указать файл, но это как-то плохо работает из-за прослойки в виде меня.
Как просто создать новый файлик в проекте, и юзать структуры и пр. из него? В доках про контейнеры и модули написано только про вынос всей хуиты в отдельную библиотеку вообще, либо это я пиздоглазый.
Тут через неделю должны 1.4 зарелизить.
Also:
https://github.com/killercup/cargo-edit
>>565104
Ну с этим первоначально ебешься.
Суть такова. Есть три команды:
¤ use – использовать заданный namespace в данном файле или блоке. Например: use std::env; – можешь использовать функции и структуры заданного namespace;
¤ extern – добавление уже готовой библиотеки библиотеки, про что ты говорил. Например: extern crate num; (если она не стандартная и ты хочешь качать из crates – нужно добавить в [dependencies] в файле cargo.toml
¤ mod – добавление заданного модуля. То что ты ищешь. С опытом определишься как оно работает;
Краткая суть последнего:
Вот у тебя есть стартовая точка проекта. lib.rs или main.rs. А есть остальные файлы. командой mod numbers; ты добавляешь в стартовый файл нужный тебе модуль, находящийся в текущей папке. Если у тебя модуль большой, ты можешь создать отдельную папку под него. Тогда тебе нужно создать файл mod.rs и в нем определить списки видимости исходников в этой папке–модуле.
Пример:
Корневая папка src содержит:
main.rs
module1.rs
module2.rs
module3/ (папка)
В папке module3 у тебя содержится:
mod.rs
module3a.rs
module3b.rs
module3c/ (папка)
В папке module3c у тебя содержится:
... (ну ты понел)
В main.rs добавляешь:
mod module1.rs;
mod module2.rs;
в module3/mod.rs добавляешь:
pub mod module3a;
pub mod module3b;
pub mod module3c;
В module3/module3c/mod.rs аналогично лежащие с ним модули
....
Можно определять несколько модулей в одном файле:
//------------------------------------------------
mod modulename { // модуль "modulename"
pub struct a { // публичная структура a
}
pub fn fna { // публичная функция
}
fn fnb { // приватная функция (доступная только для модуля modulename)
}
}
//------------------------------------------------
Собственно, так у тебя и происходит в конечном счёте с модулями автоматически, когда собираешь проект.
Если ты делаешь один файл – один модуль, то тебе не надо делать mod { ... }. Создаешь файл = создаешь модуль.
Если собираешься использовать какой-либо объект(например module3a): use module3::module3b; (отсчёт идёт с корневого модуля, где лежит main.rs!)
Есть также зарезервированные "пути":
self::; – текущий модуль (в текущей папке).
super::; – на один модуль выше (например, для module3b это будет module3, а не корневая, это важно)
Если у тебя есть некий модуль a1, в нем есть структура struct1, ты ей определил методы некоторые, но также создал функцию в этом модуле, но не в блоке реализации методов, т.е. просто отдельно у тебя в файле где-то лежит эта функция, то тебе для её использования нужно делать что-то типа: self::func1::...
Если ты собираешься использовать структуру Module3bStruct1 из module3b в module3a: super::module3b::Module3bStruct1;
Ключевой момент – mod нужно использовать для каждого модуля только один раз. В main.rs добавляешь всё с первого уровня. Т.е. module1, module2, module3, в module3/mod.rs добавляешь module3a, module3b, module3c и т.д.
Не забывай про приватность и публичность. Ты не можешь использовать в другом модуле методы, функцию, типаж или структуру если они не публичны.
Там есть ещё куча всяких нюансов, которые ты можешь дальше и сам определить.
Поправьте меня, если в чем-то не прав.
Тут через неделю должны 1.4 зарелизить.
Also:
https://github.com/killercup/cargo-edit
>>565104
Ну с этим первоначально ебешься.
Суть такова. Есть три команды:
¤ use – использовать заданный namespace в данном файле или блоке. Например: use std::env; – можешь использовать функции и структуры заданного namespace;
¤ extern – добавление уже готовой библиотеки библиотеки, про что ты говорил. Например: extern crate num; (если она не стандартная и ты хочешь качать из crates – нужно добавить в [dependencies] в файле cargo.toml
¤ mod – добавление заданного модуля. То что ты ищешь. С опытом определишься как оно работает;
Краткая суть последнего:
Вот у тебя есть стартовая точка проекта. lib.rs или main.rs. А есть остальные файлы. командой mod numbers; ты добавляешь в стартовый файл нужный тебе модуль, находящийся в текущей папке. Если у тебя модуль большой, ты можешь создать отдельную папку под него. Тогда тебе нужно создать файл mod.rs и в нем определить списки видимости исходников в этой папке–модуле.
Пример:
Корневая папка src содержит:
main.rs
module1.rs
module2.rs
module3/ (папка)
В папке module3 у тебя содержится:
mod.rs
module3a.rs
module3b.rs
module3c/ (папка)
В папке module3c у тебя содержится:
... (ну ты понел)
В main.rs добавляешь:
mod module1.rs;
mod module2.rs;
в module3/mod.rs добавляешь:
pub mod module3a;
pub mod module3b;
pub mod module3c;
В module3/module3c/mod.rs аналогично лежащие с ним модули
....
Можно определять несколько модулей в одном файле:
//------------------------------------------------
mod modulename { // модуль "modulename"
pub struct a { // публичная структура a
}
pub fn fna { // публичная функция
}
fn fnb { // приватная функция (доступная только для модуля modulename)
}
}
//------------------------------------------------
Собственно, так у тебя и происходит в конечном счёте с модулями автоматически, когда собираешь проект.
Если ты делаешь один файл – один модуль, то тебе не надо делать mod { ... }. Создаешь файл = создаешь модуль.
Если собираешься использовать какой-либо объект(например module3a): use module3::module3b; (отсчёт идёт с корневого модуля, где лежит main.rs!)
Есть также зарезервированные "пути":
self::; – текущий модуль (в текущей папке).
super::; – на один модуль выше (например, для module3b это будет module3, а не корневая, это важно)
Если у тебя есть некий модуль a1, в нем есть структура struct1, ты ей определил методы некоторые, но также создал функцию в этом модуле, но не в блоке реализации методов, т.е. просто отдельно у тебя в файле где-то лежит эта функция, то тебе для её использования нужно делать что-то типа: self::func1::...
Если ты собираешься использовать структуру Module3bStruct1 из module3b в module3a: super::module3b::Module3bStruct1;
Ключевой момент – mod нужно использовать для каждого модуля только один раз. В main.rs добавляешь всё с первого уровня. Т.е. module1, module2, module3, в module3/mod.rs добавляешь module3a, module3b, module3c и т.д.
Не забывай про приватность и публичность. Ты не можешь использовать в другом модуле методы, функцию, типаж или структуру если они не публичны.
Там есть ещё куча всяких нюансов, которые ты можешь дальше и сам определить.
Поправьте меня, если в чем-то не прав.
self::; – текущий модуль (в текущей папке).
В текущем файле конечно же. Хотя если это корневая папка, то текущей папке, да.
Выучить для начала ооп язык полегче.
В impl определяется функциональность для какой нибудь структуры (короче говоря это методы класса);
trait - интерфейсы/виртуальные классы в других языках. Короче http://kgv.github.io/rust_book_ru/src/traits.html ;
Генерики - шаблоны, используются как и трейты чтобы не плодить бойлерплейт через ctrl-c ctrl-v
http://kgv.github.io/rust_book_ru/src/generics.html
Вот тебе на примерах всё это:
http://rustbyexample.com/generics.html
http://rustbyexample.com/trait.html
>>565526
Генерики это оказалось просто некоторые штуки с типами. Я представлял себе это, как какая-то монструозная конструкция на каком-то C++/Java.
Impl тоже стал ясен. А вот с трейтом надо разобратся, зачем он такой.
Спасибо, аноны! От всей моей несуществующей души и маленького мозга спасибо!
*разобраться
https://github.com/nrc/rustfmt
Вот, кстати, на ночной cargo install уже есть. Т.е. в 1.5 версии вполне может появиться. Через 4 дня 1.4 выходит, посмотрим, переместится ли в бету.
[code]
fn content<T>(arg: T) {
println!("{:?}", arg);
}
fn main() {
content("text");
}
[/code]
Вывод на экран возможен не для любого типа. Надо указать, что принимаются только те типы, для которых реализован типаж `Debug`.
Вот так: https://play.rust-lang.org/?gist=ced7d2ebe90245dcd000&version=stable
Да, и загляни вот сюда: http://doc.rust-lang.org/std/fmt/index.html
[code]
fn content<T: std::fmt::Debug>(arg: T) {
println!("{:?}", arg);
}
[/code]
{:?} требует реализации трейта Debug выводимой структурой. Ты должен явно указать, что T является такой структурой, для которой реализован этот трейт. Есть два способа. Первый я выше описал, второй через where.
Debug предназначен для дебага. Если ты хочешь делать именно нормальный вывод, то нужно использовать трейт Display (std::fmt::Display). Им можно выводить вот так: println!("{}", arg);
> указателем
Это. Ссылка по сути и является контролируемым вариантом указателя.
> Нужно ли мне оборачивать в указатель сравнительно большие структуры данных для передачи?
Они уже так или иначе находятся за ним, так как лежат в куче, а не на стеке (если они действительно большие). Вообще, лучше просто сосредоточиться на владении.
>Есть ли графические библиотеки под Rust?
https://www.google.ru/search?client=opera&q=graohic+libraries+rust&sourceid=opera&ie=UTF-8&oe=UTF-8#newwindow=1&q=graphic+library+rust
>Можно сделать приложение под Android?
https://github.com/tomaka/android-rs-glue
Вообще всё можно сделать при желании.
>Можно сделать приложение дающее root-доступ?
Можно блядь. Хоть на питоне сделать можно. Только нахуя?
Дополню про ведроид - это одна из целевых платформ для серво https://github.com/servo/servo/wiki/Building-for-Android
Так что на все грабли там уже наступлено, ступай-конпеляй, не ссысь.
Если он задается такими вопросами, лучше не надо.
https://www.reddit.com/r/rust/comments/3pwa97/rust_and_mobile/
http://habrahabr.ru/post/269809/
Ну ок, ждем декабрь.
--------------------------
Нужно сдвинуть все элементы вектора на 1. Какой самый эффективный с точки зрения памяти и времени способ в Расте, не прибегая к unsafe?
let mut v = vec![4, 5, 0, 0, 2, 3];
shift(v, 1);
Там ничего сверхкруто не поменялось, 2.5 изменения и всё обратно совместимо, пиши спокойно на 1.3.
Вот постоянно:
либо
> вот если бы не гомосеки / code of conduct
, либо
> pointer graph
Хотя это, скорее всего, просто семены.
>#rust #nogc #memorysafety
Что-то меня у меня вызывает подозрение язык, презентация которого начинается с пиздабольства.
Причем здесь джава. Просто авторы Раста с ходу пиздят, да ещё и свою аудиторию за дураков держат. Может ли такой язык быть хорошим?
Ох ЛОЛ, макаки не успели начать кодить на расте и уже начинают беспредельничать!
Вот и цена всей вашей параше, питушки...
Да ты уже и выводы успел сделать
Да хуй бы с ней, с этой memory safety. Главное, что есть язык без GC и это не С++. Хотя бы не нужно учить, зачем нужен виртуальный деструктор.
struct Foo<'a> {
x: &'a i32,
}
Ииии... Чо? Зачем нужна данная хуитка? Какая область применения? В чём отличие от автоматического вывода лайфтайма конпалятором?
бампну без саги
> В чём отличие от автоматического вывода лайфтайма конпалятором?
В том, что у тебя может быть `Foo<'a>`, а может быть `Foo<'a, 'b>`.
http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust
Ну так там же предлагают сборщик мусора написать для той реализации кучи...
Так что с #nogc тоже фейл.
А еще та кокото питушок утверждает, что краши в программе делятся на “хорошие„ и ”плохие„ то есть юзеру типо не пофиг, от какого из них произошел отказ в обслуживании.
Такой-то манямирок, ЛОЛ.
Если программа упала, я её запустил и продолжил работать - это хороший краш. Если после падения я потерял последние лесять часов раобты - это плохой краш. По-моему, очевидно.
fn huffman_encode<InputAlphabet> (message :&Vec<InputAlphabet>)
where InputAlphabet: Hash+Eq {
let mut probabilities:HashMap<InputAlphabet,usize> = HashMap::new();
for el in message {
let counter = probabilities.entry(el).or_insert(0);
counter+=1;
}
}
[/code]
Скажите, что не так?
Не компилируется с ошибкой "cannot move out of borrowed content" в строке
let counter = probabilities.entry(*el).or_insert(0);
>>Короче, блядь,
>>Все заебись
>>хуяк
>>Додумался
>>Делаю
>>и пиздец
>>Заебись, сука
>>Дайте гайд нормальный.
Быдло, плиз.
Что там с сервой, растаны?
>Что именно они напиздели-то?
А то
> #nogc #memorysafety
Но nogc и memorysafety как бы подразумевает стратическое управление памятью. Но это, в общем случае, неразрешимая задача, с родни проблемы остановки. И вот тут я был бы готов предположить, что у растодаунов какое-то решение есть, которое работает достаточно часто, не всегда, но когда-то, в большинстве случаев, что позволяет им заявлять о #nogc #memorysafety. Но никаких пейперов я на их сайте не нашел, только рекламное говно, из чего сделал справедливый вывод, что растодавуны сиречь квованы онвльные.
> Но никаких пейперов я на их сайте не нашел
https://doc.rust-lang.org/book/academic-research.html
Каргокультисты от математики - самый жалкий тип программистишек. У них, типа, все по серьезному. Наука! Хотя на деле и математикам на них поебать, и среди программистов они за фриков.
>Каргокультисты от математики - самый жалкий тип программистишек
Да мне поебать на твое мнение. Пошел нахуй.
Зато мне на твое не поебать. Оно очень меня веселит. Такой типичный персонаж программерских борд - неудачник, прикидывающийся ученым.
>неудачник
А вот и дегенерат, которому общество внушило, что надо ДОБИВАТЬСЯ, а если ты не добился, то надо СТРАДАТЬ. И жизненный цикл хомячка состоит из погони за очередными материальными средствами для компенсации чувства собственной ничтожности и сравнения себя с другими. Особенно рвет пукан у такого говна от самодовольных битардов, которым похуй на все.
>Неудачник - исключительно в научном плане.
В рашке наука - это преподавание в вузе, осиливание уже созданных теория или дрочение диффуров в НИИ под водовку и картофан. Сравни хотя бы треды на math stackoverflow с тем, что считается наукой в рашке.
pro tip: про рашку даже намёка не было
И какой у тебя рейтинг на math stackoverflow?
> Самый известный ООП язык, где перегрузку запретили под мотивацией "ко-ко-ко индусы запутаются" - это Java. Еще был такой - Delphi.
Тут-то ты и обосрался.
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Operator_Overloading_(Delphi)
Я не зря написал - был. Что сейчас происходит с delphi - мне как-то поебать. А вот в 2001 году евангелисты делфи делали особый упор на то, какая перегрузка операторов страшная штука. Вот тебе отрывок из книги тех времен. Ты в 2001 родился хоть?
чувак хотел накостылить кучу прямо в safe и у него нихуя не вышло? Как я понимаю, пиздеть на это - это как пиздеть на хачкель за то, что в нём без монад файлик не прочитать.
Двачую, поясните.
Ну и что мы там видим? Region Based Memory Management в Циклоне и МЛ (даже не в Расте), причем работает она там не оче (поэтому в МЛ остались на мусоросборнике, а циклон не взлетел). И тут растоклованы такие заявляют: "Мы решили проблему с памятью!" Ну охуеть вообще. Дайте им премию Станиславского про многопоточность не читал, потому что подозреваю, что растоклоунада "мы решили проблему многопоточности" там уровня каких-нибудь акторов, либо подобной хуиты для школьниц
А, так это ты тот воннаби-ученый. Хуй сосешь?
> Ну и что мы там видим?
То, что видим. Раст — промышленный язык, а не исследовательский, т.е он не изобретает новые концепции, но оборачивает их в пригодную для использования форму.
И да, там не все статьи конкретно про циклон.
> Как можно завернуть в пригодную для использования форму нерабочую концепцию?
В случае раста она вполне рабочая (хотя да, не универсальна).
Про конкретные отличия между растом и циклоном я тебе не скажу, ищи сам.
>В случае раста она вполне рабочая (хотя да, не универсальна).
Ну так и надо четко обозначить случаи, когда она работает, а когда нет, а то какой-то хайп получается.
А то у тебя жопа подгорает. Нету и не будет никогда серебрянной пули, если ты пытаешься залезть рукой в анус - логично что он порвется и протечет.
Серебрянной пули нет, но важен сам подход людей, позиционирующих себя как специалистов. Если вместо профессионального подхода я вижу хайпохуету, у меня сразу возникает впечатление, что мне впаривают очередные "умные указатели" в новой обёртке.
Тебе никто ничего не впаривает, неуловимый Джо. Это ты тематические треды батхертами заливаешь.
Rust - это и есть best practises умных указателей с контролем на уровне компилятора. Mark'n'sweep GC там возможен, но вряд ли кто-то будет пилить, потому что задач нет. Если тебе нужен GC - возьми вместо раста что-то еще.
> Mark'n'sweep GC там возможен, но вряд ли кто-то будет пилить
Уже запилили: https://github.com/Manishearth/rust-gc
Но задачи у него очень специфические, вроде
> if one is writing an interpreter for a GCd language, having a GC in Rust would simplify things a lot
Я видел, но under construction грозится быть вечным. Потому что не нужно.
Языки без-GC - это отдельная порода языков, в которых за счет этой особенности сделана куча архитектурных решений. Например, замыкания - нельзя просто взять и эффективно захватить объект по ссылке, нужно придумывать кучу видов замыканий - с захватом по ссылке, значению, перемещению и т. д. и т. п. Неосиляторы при этом просто пиздят о том, что просто добавь GC и не еби мозг - но тогда весь этот и не нужен. И вот в язык, который сдизайнен, чтобы быть без GC, добавлять GC? Нахуя? Тот, кто берет язык без GC, ему (охуеть, да?), GC trade offs нахуй не нужны настолько, что он готов поебаться со сложной архитектурой, с указателями, замыканиями и т. п. Тот, кому нужен GC, зачем ему-то ебаться с дизайнерскими решениями, которые в GC-случае нужны? В общем, задач для GC в расте нетуть.
>Но задачи у него очень специфические, вроде
Его ж под браузер пилят, а в браузере есть javascript. Я встраивал V8 в один проект на заре появления ноды.жс, и там работа с GC - одна из ключевых заморочек. Но это не тот GC, который обычно имеется в виду.
> И вот в язык, который сдизайнен, чтобы быть без GC, добавлять GC? Нахуя?
А почему нет? Думаешь применения не найдут? Вот D наоброт проектировался как язык с GC, но сборщик мусора там его можно отлючить.
Вот D - очень хороший пример хуевого решения. Если в расте gc-указатель делается с помощью Gc<T> и виден на уровне системы типов, то в D - это просто вкл-выкл, причем выкл, расчитанный на GC, течь, включая стандартную библиотеку. А со включенным GC, D уже и luajit посасывать может. Потому что грамотно написанная динамика с JIT работает на уровне статического языка с GC. Ну и нахуй этот D нужен?
Таким же образом можно подключить сборщик мусора к С++ (как C++/CLI например), и писать код, который будет течь.
Ой зря ты так, я достаточно много на D писал и по быстродействию он почти не отстает от языков без GC (конечно если использовать адекватный компилятор вроде LDC). Алсо сравнивать его с Lua бесмысленно, ибо шаблоны, трейты, инлайн ассемблер и прочий функционал. Но насчет GC согласен, реализовано это все достаточно неудобно.
По быстродействию и джавы-сишарпы почти не отстают то языков без GC. x2-x4 - это так уж много, тормознутостью имеет смысл считать отставание в сотни и тысячи раз, как у питона и раби. Другое дело что в реалтайм приложениях некруто иметь хаотично запускающийся где-то посреди симуляции сборщик, заметное пользователю время вычищающий плотно засранную промежуточными результатами расчётного цикла кучу.
Ты устарел. JIT-компиляция с выводом типов делает преимущество статических языков с GC призрачным.
А вот и нет, у рустеров в том треде другие критерии...
А в чем проблема написать GC под задачу?
Ой, а зачем языку с best practises умных указателей и контролем на уровне компилятора CG? Неужели умные указатели таки сосут и в итоге приходится велосипедить мусоросборник?
Да сосут, сосут, съеби нахуй из треда.
> Ой, а зачем языку с best practises умных указателей и контролем на уровне компилятора CG?
Всё очень просто:
> Designing a GC was a wonderful experience!
Так-то кроме сервы GC ничто не использует.
Нет, суть в том, что некие хуи предложили запилить "безопасные" двухсвязные списки за счет использования вместо указателей индексы в массиве итемов.
Я хотел сделать то же самое аналогичным образом, когда буду писать свое первое ядро ОСРВ на русте, но меня опередили, ЛОЛ.
ВНЕЗАПНО, такие списки оказались НЕБЕЗОПАСНЫМИ, та как использование индекса вместо указателя - просто прием для наебки компилятора, он не делает подобные списки безопасными вообще!
Такой прием дает возможность написать "безопасную" кучу с выходами за границы массивов, утечками памяти, использованием "освобожденной" памяти и "неинициализированных указателей".
То есть в этом вашем расте есть как минимум один способ написать падающий говнокод в обход правил "безопасости" и без единого использования unsafe.
А потом начались разборки, какой краш считать "хорошим" и "плохим", так же было предложение написать к такой реализации кучи GC, раз у сама куча - говно...
Так что, господа рустеры, проследуйте на парашу со своим небезопасным говноязыком.
У меня видение мира такое, и оно основано на работе с языками Clay и Julia, а также крестовыми шаблонами, успехами V8, LuaJIT и PyPy. Оно заключается в том, что будущее GC-языков - это динамика с JIT выводом типов и опциональными типами для статического доказательства корректности там, где это нужно. Шаблонные функции в таком случае не нужны - потому что достаточно обыкновенных, которые работают со всеми типами. Т.е., грубо говоря, у тебя ВСЕ функции имеют вид template<A,B,C> void yoba(A a, B b, C c); и пишется это вот так: yoba(a,b,c). При этом заранее это не компилируется (как в C++ и Clay), а делается прямо в рантайме (как в V8 и прочих).
Т.е. нужен, грубо говоря, С++/Rust для системных дел (принципиально без GC) и такой язык - для всех остальных дел. А D, C#, Java и прочая статика с GC не нужны, потому что перформанса они не добавляют, а система типов у них на уровне С++ или хуже.
Может там еще и на ноль делить можно?
Да мог бы и не подписываться, и так ясно, как у тебя бомбит от крестов. Rust делали крестобляди для крестоблядей, вам, сишникам, не понять вообще.
Ты можешь сколько угодно себя убежать, как прекрасно все это мудоебство с типами и джитами, но самыми популярными все равно останутся те языки, которые ты считаешь ненужными.
> ВНЕЗАПНО, такие списки оказались НЕБЕЗОПАСНЫМИ, та как использование индекса вместо указателя - просто прием для наебки компилятора, он не делает подобные списки безопасными вообще!
На самом деле, memory safety строго выполняется, просто тот код эмулирует небезопасную кучу.
Но эмуляцию можно сделать абсолютно на любом языке вне зависимости от его безопасности.
Единственная проблема раста здесь — недостаточно мощная система типов, провоцирующая написание подобных костылей.
Я об этом думал еще несколько лет назад. За это время набрала популярность нода, pypy развился, luajit бодро бегает, я поработал в проекте с groovy, которых сдох, но своим @compilestatic в этом же стиле. Все идет в том тренде, о котором я думал. То, что Java будет жить вечно на уровне легаси, я как бы не сомневаюсь). Но я вообще не вижу разницы в скорости разработки между С++ и Java, поэтому и не пытаюсь.
Счетчик ссылок?
Будут, с Rc.
Это, конечно, красивые сказки, но я из более-менее успешных реализаций знаю только v8 и luajit, и это большая заслуга разработчиков, сколько они там внутри всего натюнили и накрутили эвристически.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=v8
Но я не призываю использовать какие-нибудь джавы-сишарпы для перформанса. Я считаю, если перформанс реально важен (то есть реалтайм, все дела) - ручная память и цпп, если не так уж важен - динамические скрипты. Но при этом я думаю, что джавосишарпы таки действительно посередине между скриптами и байтоёбством как по перформансу, так и по производительности разработки, просто не люблю полумеры.
> я вообще не вижу разницы в скорости разработки между С++ и Java
Это очень странно, такое обычно бывает если человек не писал как минимум на одном из этих языков. Управлять руками памятью - это весьма заметные дополнительные усилия и время. А думать о том, как это делать лучше и правильнее, продумывая архитектуру приложения - это вообще надолго.
>>572230
Принципиальное отличие в том, что ты с этой эмулированной кучей вообще никак не можешь уйти во всякие там сегфолты, или, тем более, реально пиздануть чужую память. Все ошибки, которые могут возникнуть - внутриязыковые и контролируемые.
> Управлять руками памятью - это весьма заметные дополнительные усилия и время.
Меня реально бесит только upward funarg problem, но оно уже лечится через move. А так, хуй знает. Когда приложение уже зрелое, вообще похуй, ну следишь за владением, ну и следишь. Зато шаблоны есть. С нуля на крестах довольно неприятно, потому что постоянно нужно перизобретать мир - все эти pretty printer'ы и прочее говно. Но в целом, я бы не сказал, что "если бы не перформанс, я бы за С++ не брался, а писал бы на божественном C#". Хороший С++ проект приятнее. А ничего революционно удобного, типа repl, эти языки не предлагают.
Мне не бомбит ни от крестов, ни от руста, ни от лишпа с хачкелем.
Мне не нравятся упоротые евангелисты.
А в русте они не менее упоротые чем золотце и лавсанчик.
Если бы местные питушки не приперлись в имбед-тред, и не начали форсить свою парашу и толстить, я бы не обратил на вас внимание.
Сами виноваты, короч.
Какие серьезные аргументы. Портфель собрал?
Вот твой первый задокументированный батхерт итт: >>547251
>Алсо, язык ни хера не системный, как тут пытаются утверждать, на нем даже двухсвязный список без unsafe не написать, следовательно на системном коде все его преимущества ВНЕЗАПНО разбиваются об unsafe,
>и остается только убогий вырвиглазный синтаксис с шаблонным питушением.
Батхерт тут очевиден, потому что ты занимаешься грязной подменой понятий. Я даже описывать не буду.
Проблема в том, что ты сишник. Первый момент - тебе бомбит от крестов ("шаблонное петушение"). Я понимаю, что лучше гордо пердолисться через #define, но тем не менее. В расте нет шаблонов, там тайпклассы, как в хачкеле. Второй момент, у него и с unsafe куча преимуществ. Это и лямбды, или тайпклассы, и паттерн-матчинг, и макросы, . Но ты почему-то взъелся именно на safe/unsafe, в котором серебряной пули никто не обещал. Пиши базовые контейнеры и аллокаторы с unsafe, в чем проблема. Никакой проблемы нет. Никто не обещал, что будет легко. И никто не обещал, что сишникам (т.е. дну неосиляторства) будет легко.
Также, ищу библиотеку для кроссплатформенной реализации демона(daemon). Есть rust-daemon, но там лишь для windows и linux.
Да ты заебал уже, окончательно заебал. Ты понимаешь, что ты уже всех заебал? За один ебаный день, блядь.
Не стукай
А конкретнее? Обьясните ребенку с Синдромом Дауна.
Дженериков джавы и сишарпа хватает для основных вещей типа полиморфных контейнеров, асинко-промизов, и ко/контравариантности этого всего, и прелесть в том, что в коде всё просто и понятно, классо-ориентированное ооп на этих языках предполагает определённую культуру оформления кода, и она оказывается одновременно очень выразительной, и поразительно простой и униформной. На С++ можно встретить что угодно и как угодно, а тамошние шаблоны являются смесью параметрического полиморфизма и макросов, потому позволяют делать кучу всяких трюков в духе "template <typename Base> class Yoba : public Base { ... }", через которые выражаются вещи, которые тянут на отдельные парадигмы. Если не собираешься писать свою личную парадигму, зачем все эти лиспохаскелизмы? Каждая такая программа на С++ - это свой новый надязык, философию которого нужно понять и принять. Ну и ещё всё что использует шаблоны - надо хуярить в хидерах, перекомпилировать мир каждый раз, разбираться в нечитабельных ошибках на много страниц, и так далее.
>Я понимаю, что лучше гордо пердолисться через #define, но тем не менее.
Не нужно, есть более подходящие паттерны проектирования
>Но ты почему-то взъелся именно на safe/unsafe, в котором серебряной пули никто не обещал.
>#rust #nogc #memorysafety
Ну ты понел, да?
>Никто не обещал, что будет легко.
Ваши же евангелисты и ообещали, что не надо "заморачиваться с отслеживанием времени жизни переменных, конпелятор все равно лучше отследит", и много чего еще.
>сишникам (т.е. дну неосиляторства)
Ойвей, осиляторы закукарекали!
Я предпочитаю выбирать инструмент под задачу, а не упарываться всякими каргокультами (за годы сидения в кодаче, я слышал столько базвордов, что все уже не упомню, не осилю, ЛОЛ).
> В расте нет шаблонов, там тайпклассы, как в хачкеле.
И чем это отличается на низком уровне от шаблонного питушения? Точно так же под каждый тип будет генериться своя реализация методов, во всяком случае так написано вашими же евангелистами-википидорами.
Нет. Это кресты с безопасным загоном для быдлокодеров, правда в загоне есть дыры но это уже другой вопрос...
Я в 2001 уже твою мамку шпилил. Тебе как раз 14 лет должно быть, получается.
Кстати в Википедии написано нейтрально, и область применения обозначена как язык "для написания больших клиент-серверных приложений, работающих в сети Интернет."
С такой областью применения я как раз согласен.
шкорльник-кун
>Goвно - хороший инструмент с точки зрения менеджмента: любого дауна можно посадить писать код и он его напишет и результат будет даже читаемым. Собственно для этого он и придуман.
Великолепно! Это именно то, что нужно!
И вот почему: вогуг любого продукта есть группы заинтересованных лиц, в случае софта это: программисты, пользователи, QA и сопровожденцы, менеджмент.
Программисты заинтересованы в бабле им нужен инструмент, который позволяет писать программы с минимальной нагрузкой на механизмы внимания и памяти
Пользователи заинтересованы в стабильной программе, которая подходит для области, в которой используется, а еще им нужно быстрое решение технических проблем.
QA заинтересованы в возможности быстро решать проблемы пользователей, иначе их выебут.
Сопровожденцы - тоже программисты, но они не писали а только сопровождают поделие, им нужно быстро искать и править баги, а для этого (сюрприз!) нужно чтобы изучение исходников программы как можно меньше нагружало механизмы внимания и памяти.
Менеджмент - этим пидорасам нужно одно - снижение издержек на стадиях разработки, внедрения, сопровождения. А для этого, нужно использовать инструменты разработки, которые позволят программистам быстро писать, а сопровожденцам быстро читать и править, то есть нужен простой язык на котором полюбасу получаются читаемые программы, причем быстро и с персоналом низкой квалификации.
Соответствено менеджмент тоже заинтересован в низкой нагрузке на мозги программистов и спровожденцев.
В гугле все правильно сделали.
Диван0, залогиньтесь.
Но ведь Go менее простой, читабельный, и продуктивный, чем JavaScript, Python, Ruby.
> v8 сосут так же
Не так же, намного меньше:
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=v8
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=python3
Их перформанс очень даже хорош для высокоуровневого кодинга.
А вот go один хуй не годится для реалтайма из-за сборщика, так что его область - та же, что у js, питона, жабы, сишарпа и тд.
>А вот go один хуй не годится для реалтайма из-за сборщика, так что его область - та же, что у js, питона, жабы, сишарпа и тд.
Раст тоже не годится для реалтайма из-за динамичекой аллокации памяти и каскадного освобождения. Если мы говорим про тот реалтайм, которому мусоросборник мешает. Правда реалтайм в /pr/ - это как секс у подростков. Всё о нём говорят, но никто не занимается.
Кто-то заставляет писать с unsafe? В redox unsafe используется только для библиотек (для чего и предназначен), servo написан практически на чистом safe (unsafe в тестах используют зачем-то).
Я в реалтайм включаю любые приложения с непрерывной симуляцией, например игры. А rust даже и просто тормозной, потому что тупо плохо компилирует, а какой он неудобный, и насколько шизофреничные там сигнатуры - это вообще отдельная песня.
>>572402
2 господина теоретика, будьте добры посетить какую нибудь трансляцию на твиче с 100к человек (редко, но бывает во время всяких турниров) и посмотреть как работает чатик. Стоп зе ворлд сука. Или сходите в какой нибудь cloudflare, и рассказать как хуёво с гц в реалтайме, когда на дворе 2015 год. По логике второго антоши - весь риалтайм-кококо-хуйлоад можно пейсать вообще только на си, когда где-то в далёком яндексе поиск на перле работает.
Мусоропровод в 2015 не везде такой топорный как в жаве.
Лол, в вебпараше реалтайма нет вообще. Ты не путай с ХАЙЛОАДОМ. В реалтайм симуляции надо просчитывать всю хуйню 60кадров в секунду, и чтобы это всё было плавно и с одинаковой скоростью - чуть где какой гц - и сразу подёргивания и подлагивания. В чяте вообще не может быть такой хуйни, потому что дискретная природа информации.
Ну так игры и на языках с мусоросборником никто писать не мешает. Про тормоза мусоросборников и GC-паузы в полсекунды кукарекают больше всего те, кто не писал на языках с мусоросборниками.
>>572410
Еще раз - теоретики - это те, кто кукарекает про то, как мусоросборник реалтайму мешает. Теоретики они именно потому, что ни с тем ни с другим не программировали, но мнение имеют.
А я обожаю писать двусвязные списки. Каждый день я сажусь за компьютер и начинаю писать свою особую реализацию двусвязного списка. Ведь чем же ещё погромист должен заниматься, кроме как создания домашнего велосипеда?
Самому не смешно?
Но лучше беспрувного кукаретика, которому в маняфантазиях мусоросборники игоры писать мешают.
Долбоёбушка, ты не понимаешь, что раз там даже двусвязный список нельзя без unsafe сделать, то ни о каких более сложных структурах данных и речи быть не может?
> Ну так игры и на языках с мусоросборником никто писать не мешает
Будет что-то в духе: http://stackoverflow.com/a/2484301/1203558
То есть более низкоуровнево, чем на С++ с его zero-cost abstractions.
И не надо рассказывать, что это просто джава плохая, она охуенно быстрая, и сборщик там быстрый, один из лучших.
Это проблемы не языка с мусоросборником, а джавы, в которой нельзя сделать нормальные абстракции для работы со структурой массивов как с массивом объектов. И очень медленных устройств, про которые написано в исходном вопросе.
>Я предпочитаю выбирать инструмент под задачу, а не упарываться всякими каргокультами (за годы сидения в кодаче, я слышал столько базвордов, что все уже не упомню, не осилю, ЛОЛ).
Основной твой каргокульт - это крестохейтерство. Растохетерство идет следом, потому что раст - это кресты, как если бы их разработали в 2010, без обратной совместимости с сишкой и крестами образца 1991 года.
>И чем это отличается на низком уровне от шаблонного питушения?
Всем. Шаблоны диспатчатся только при компиляции, если тебе нужен полиморфизм в динамике, в С++ у тебя выбор - ООП на VMT. Отсюда при разработке вознимает дилемма - шаблоны, или все-таки ООП. Это все равно лучше сишки, где предел мечтаний - это касты void*, но тем не менее.
А тайпклассы универсальны, если типы известны во время компиляции, используется статический диспатч, если неизвестны - динамический. При этом, в отличие от ООП, каждый трейт в динамике тащит за собой 2 указателя - на структуру данных и на VMT (в ООП структура данных содержит внутри себя указатель на VMT), и за счет этого ты получаешь всю мощь тайпклассов.
А тебе на это похуй, потому что зачем думать о таком, есть же крестохейтерство, произнес 10 раз подряд "шаблонное петушение" и полегчало, хули там, ведь шаблоны - для петухов, от них объем кода на килобайты растет.
И, кстати, в Говне++ те же самые проблемы и те же самые пути решения:
Там в main-loop тоже уже никто ничего не аллоцирует, всё в основном создаётся заранее.
Не. Ты - хуже пидораса. У тебя мысли ходят по кругу и ты из года в год пишешь одно и то же. Перенесись на пару лет вперед, ты будешь нести ту же самую желчь.
Какой сочный ad-hominem, аж течет.
Преаллокация и пулинг всякий - это нормально. Ненормально именно то, что в небайтоёбских языках нельзя оперировать этими вещами как-либо высокоуровневее, чем массивами примитивов (int, byte и тд). Самый очевидный и повсеместный плюс - что в С++ не будет боксинга при array-of-structures. Но даже если хочется уйти в SSE по-хардкору, можно написать свои стековые дескриптороабстракции для structure-of-arrays.
>>572448
> если тебе нужен полиморфизм в динамике, в С++ у тебя выбор - ООП на VMT
С разморозкой: http://www.boost.org/doc/libs/1_55_0/doc/html/boost_typeerasure.html )))
Охуенная логика, давай ещё. Если есть выбор между условных 95% безопасного кода (при этом 5% ограничиваются одной-тремя последовательностями строчек) и 0% при прочих равных условиях, ты будешь писать на голых 0%?
Ты еще про свитчи мне расскажи. Я говорю о средствах языка, а не неюзабельном пердолинге шаблонов.
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
Проблема в том, что этот код не будет безопасным, в тредике уже есть пример небезопасного кода без unsafe.
Все так, но после определенного порога объёма кода или сложности предметной области снижение нагрузки на механизмы внимания и памяти достигается путем повышения уровня абстракции, а в Go с этим неочень.
Кроме того, код написанный в излише императивном стиле, часто сложен для понимания, поэтому даже в Effective Java призывают ограничивать мутабельность например. Но это конечно не только Go касается.
Я вообще недавно писал пост о применимости языков, но тот тред вроде уже смыло.
>>572230
Ты же подменяешь понятия, челик. Ты можешь написать просто a/b без проверки b на неравенство 0 посреди кода, и что, компилятор должен тебя уберечь от этого? Это наверное возможно, но тебе в языки с зависимыми типами тогда, и там во многих случаях во всех не тривиальных, как я понимаю ты сам должен будешь доказывать компилятору что код корректный.
>То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
Говорить. Если писать, то они тоже друг друга поймут. Одна из причин, почему китайцы не уходят от иероглифов.
>Ненормально именно то, что в небайтоёбских языках нельзя оперировать этими вещами как-либо высокоуровневее
Блядь, да я про то и пишу, что это - проблемы джавы, а не мусоросборника. Хуёвый, невыразительный язык, в том же Хаскелле это делается вполне сносно. И еще я хочу сказать, что отсутсвие мусоросборника эти проблемы не решает. Они есть, они реальны, они объективны в любом языке, и способы их решения везде примерно одинаковы. Мой коллега написал физический движок и игрульку на нём для фана. На С++. И да, пул объектов, преаллокации, хуё-моё, на С++ он это всё выразил. Аллоцировал бы в main-loop, была бы та же хуйня, что и в языке с GC, он мне так и сказал, поэтому и изъябывался. Писал бы на джаве... ну, в принципе, я работал в UBS, там был Market Order Bus (шина сообщений для обработки ордеров, примерно с теми же требованиями), джава, zero GC. Работает, но выглядит как говно. То, что оно как говно выглядит, исключительно проблемы языка (а не GC), а то, что оно работает - доказательство того, что и в небайтоёбских языках всё это решается, причем теми же методами, что и в байтоёбских. Просто надо брать правильный небайтоёбский язык, а не джаву.
Охуенная логика. Есть выбор между структурами с циклическими ссылками, которые через смартпоинтеры не выражаются, и структурами без циклических ссылок. Ну ладно, мудак, допустим циклические ссылки не нужны (щастье-то какое, как бы можно было бы оптимизировать мусоросборники без таковых), ты DAG в расте опишешь без unsafe? DAG, братюня, там нет циклических ссылок, чисто DAG. Или он тоже не нужен?
> в том же Хаскелле это делается вполне сносно
Лолблядь, в хаскеле работать с десятью слоями IO, ST, IOURef и линз - это нихуя не сносно и хуже любого петушения байтомассивов на жабке.
> отсутсвие мусоросборника эти проблемы не решает
Отсутствие мусоросборника гарантирует, что ты его использовать не будешь, а такая гарантия обязательна, ну и накладывает определённые требования к средствам выражения абстракций в языке. Я не знаю ни одного языка без мусоросборника, который бы не позволял делать анбоксед массивы структур и локальные структуры вне кучи.
В том же С# есть value-типы и по идее их массивы будут даже незабоксены в большинстве случаев, но там вся стандартная библиотека, все коллекции - всё вычищается обязательно через GC, потому движок для симуляции на нём писать смысла мало. Зато игровую логику скриптовать, как в Юнити каком-нибудь, где ядро на C++, а скрипты - на C#/JS/Python - это пожалуйста.
>Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
Что характерно, все настоящие раелтайм-бляди предпочитают статическое выделение памяти на этапе конпеляции. Это такой паттерн, можно сказать. Поэтому любой реалтайм-бляди очевидно, что Rust - ни чуть не в большей степени реалтайм, чем язык с мусоросборником.
>Не понимают. А какие бывают?
Ну в реалтайме других и не бывает. Потому что они уже слишком непредсказуемые. Ты - редкое исключение, которе живёт в реалтайм-мирке. Этот мирок очень-очень ограничен, там очень мало типов данных и очень мало алгоритмов. Это - нормально. Но когда кто-то начинает приплетать реалтайм к языку программирования общего назначения, с динамической аллокацией, тьюринг-полному наконец, хочется послать этого хуесоса нахуй, закономерно.
>Лолблядь, в хаскеле работать с десятью слоями IO, ST, IOURef и линз - это нихуя не сносно и хуже любого петушения байтомассивов на жабке.
Ты тот хуесос, который писал структуры с полями IORef? Просто иди нахуй, ты языка не знаешь.
Схуяли им там быть, если он 2д аркадкой любой игровой пека положил бы нахуй?
> Ну ладно, мудак, допустим циклические ссылки не нужны
Когда споришь сам с собой, можешь за других додумывать всё что угодно. Тебе говорят не про то, что НЕ НУЖНО, а про то, что нет необходимости всё подряд описывать на небезопасном языке. А описываемое на небезопасном можно ограничивать и оно лучше отслеживается, чем в чисто небезопасных языках.
Так-то даже в языках со сборкой мусора в некоторых случаях без ручного освобождения не обходится, из-за они НЕ НУЖНЫ?
https://github.com/mitchmindtree/daggy
>>572535
Ну они в документации и презентациях говорят о подобных случаях.
>No unsafe blocks anywhere
ГОТОВ ДЛЯ ТРИПЛ А ГЕЙМДЕВА в 1993 году
Инфа хоть и старая, но ничего не изменилось с тех времен, си/кресто -параша никуда же не делась, и хоть они и кукарекают о том что все отлично и ничего не течет, но мы то знаем.
>>572681 (OP)
Точно, забыл стереть у себя этот и перепутал, спасибо.
Вы видите копию треда, сохраненную 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.