Этого треда уже нет.
Это копия, сохраненная 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
11 Кб, 571x292
Почему нет треда по самому лучшему и интересному языку последних лет? Неужели никто не хочет обсудить?
Под него уже, между прочим, активно разрабатываются безопасные высокопроизводительные веб-фреймворки (https://github.com/iron/iron) и игровые движки (https://github.com/PistonDevelopers/piston)
#rust #nogc #memorysafety
Под него уже, между прочим, активно разрабатываются безопасные высокопроизводительные веб-фреймворки (https://github.com/iron/iron) и игровые движки (https://github.com/PistonDevelopers/piston)
#rust #nogc #memorysafety
Потому, что прошлый утонул.
Зачем нужен Rust если в действительности всех устраивает С/C++? А там, где не устраивает, то есть Go.
>С/C++
Это два абсолютно разных языка
>всех устраивает
Нет. Точнее не полностью.
>А там, где не устраивает, то есть Go.
Третий абсолютно другой язык, не решающий проблем плюсов и привносящий кучу своих.
>>523849
Кекнул со специалиста по ЯП. Я их вынес в отдельную группу, так как большинство задач, которые решает С одинаково хорошо решает С++, и наоборот.
Всех все устраивает.
Go решил все проблемы плюсов :)
>Это два абсолютно разных языка
Кекнул со специалиста по ЯП. Я их вынес в отдельную группу, так как большинство задач, которые решает С одинаково хорошо решает С++, и наоборот.
>Нет. Точнее не полностью.
Всех все устраивает.
>Третий абсолютно другой язык, не решающий проблем плюсов и привносящий кучу своих.
Go решил все проблемы плюсов :)
>#rust #nogc #memorysafety
поссал на тебя
>>523816 (OP)
ОП, хуле с шапкой? Надо добавлять больше инфы!
Пользуюсь этой хуитой https://github.com/phildawes/racer для EMACS - зависимость есть.
Алсо, доебали петухи, которые никогда не писали многопоточных приложений, то тем не менее кукарекающие о няшной и тем более о крестопараше.
Алсо, доебали петухи, не читавшие о задачах раста и го, но тем не менее кукарекающие о "преимуществах/недостатках" суслика и раста.
ОП, хуле с шапкой? Надо добавлять больше инфы!
Пользуюсь этой хуитой https://github.com/phildawes/racer для EMACS - зависимость есть.
Алсо, доебали петухи, которые никогда не писали многопоточных приложений, то тем не менее кукарекающие о няшной и тем более о крестопараше.
Алсо, доебали петухи, не читавшие о задачах раста и го, но тем не менее кукарекающие о "преимуществах/недостатках" суслика и раста.
>>523870
racer кстати охуенно работает и под саблаймом, с ним и linter'ом даже иде никакой не нужно.
racer кстати охуенно работает и под саблаймом, с ним и linter'ом даже иде никакой не нужно.
>>523881
Зачем ты это говно сюда принёс?
Зачем ты это говно сюда принёс?
>>523908
А конкретней? Iter::map, например, будет работать так же быстро как и обход коллекции в цикле?
А конкретней? Iter::map, например, будет работать так же быстро как и обход коллекции в цикле?
>>523910
Да, будет.
Да, будет.
>>523908
Для начала дай определение стоимости абстракций.
А потом обоснование нулевой стоимости в случае руст.
Для начала дай определение стоимости абстракций.
А потом обоснование нулевой стоимости в случае руст.
>>523852
Кекнул со специалиста по ЯП.
Давай, иди ядро линукса на С++ допиши.
>так как большинство задач, которые решает С одинаково хорошо решает С++, и наоборот.
Кекнул со специалиста по ЯП.
Давай, иди ядро линукса на С++ допиши.
>>523852
Кекнул со специалиста по ЯП.
Если тебе задали делать laba1.cpp, это не значит, что язык устраивает всех.
Хуйни не неси, у языков разные ниши.
>Всех все устраивает.
Кекнул со специалиста по ЯП.
Если тебе задали делать laba1.cpp, это не значит, что язык устраивает всех.
>Go
Хуйни не неси, у языков разные ниши.
130 Кб, 650x449
>>523940
Ты слишком обдвачевался.
Ты слишком обдвачевался.
>>523862
И привнес комплексный синтаксис, в котором можно сломать ногу и обоссать себе ебало.
И привнес комплексный синтаксис, в котором можно сломать ногу и обоссать себе ебало.
>>523928
Не могу понять, в чем проблема написать linux kernel на С++. Его изначально писали на С просто потому что С++ торвальдсу не нравится.
Не могу понять, в чем проблема написать linux kernel на С++. Его изначально писали на С просто потому что С++ торвальдсу не нравится.
>>523930
Да, которые на 75% пересекаются, а там где не пересекаются, то выбор — явный С.
>Хуйни не неси, у языков разные ниши.
Да, которые на 75% пересекаются, а там где не пересекаются, то выбор — явный С.
>>524103
Да.
Да.
>>524086
Илюш, ну не бомби
Илюш, ну не бомби
1061 Кб, 3000x2250
>>523816 (OP)
Увы, но раст на указанную версию никак не тянет, много всяких нужных вещей в unstable висит. Но, судя по гитхабу и опросам, этот язык, даже в сыром виде, вызывает интерес у людей, значит что-то да выйдет.
https://github.com/showcases/programming-languages
>>523936
Несколько месяцев назад была непонятной хуйней, дублирующей функционал sdl, поверх которого написана, и непонятно почему названая "движком". Сейчас появилась некоторая абстракция. Но до полноценного фреймворка ещё очень долго.
Всё работает на принципе: ты пишешь свою кирилоподелку на пистоне и куски кода коммитишь мейнтейнеру. Года через 2 что-то да выйдет.
Увы, но раст на указанную версию никак не тянет, много всяких нужных вещей в unstable висит. Но, судя по гитхабу и опросам, этот язык, даже в сыром виде, вызывает интерес у людей, значит что-то да выйдет.
https://github.com/showcases/programming-languages
>>523936
Несколько месяцев назад была непонятной хуйней, дублирующей функционал sdl, поверх которого написана, и непонятно почему названая "движком". Сейчас появилась некоторая абстракция. Но до полноценного фреймворка ещё очень долго.
Всё работает на принципе: ты пишешь свою кирилоподелку на пистоне и куски кода коммитишь мейнтейнеру. Года через 2 что-то да выйдет.
Растаманы, поясните ньюфагу.
Какого хуя все окружение через жопу? Надо установить конпелятор, сырцы отдельно, дебагер отдельно, gdb для дебагера отдельно. Нормальных IDE нет, только бородатая ебля с vim/emacs. Так и задумываешься, а может нахуй его, если со времен сипласплас ничего не изменилось?
Какого хуя все окружение через жопу? Надо установить конпелятор, сырцы отдельно, дебагер отдельно, gdb для дебагера отдельно. Нормальных IDE нет, только бородатая ебля с vim/emacs. Так и задумываешься, а может нахуй его, если со времен сипласплас ничего не изменилось?
>>524179
Ну так язык молодой, все понемногу пилится, скоро и иде нормальные будут. А что за ебля с вимом/емаксом? Там вроде все просто и удобно выходит.
Ну так язык молодой, все понемногу пилится, скоро и иде нормальные будут. А что за ебля с вимом/емаксом? Там вроде все просто и удобно выходит.
>>524179
Ебля, да.
Более-менее редактор:
https://users.rust-lang.org/t/using-atom-to-work-with-rust-under-win32/2280?u=brakmic
Может ещё под VS запилят нормальное что-то. Полноценной подсветки не хватает.
https://github.com/PistonDevelopers/VisualRust
Ебля, да.
Более-менее редактор:
https://users.rust-lang.org/t/using-atom-to-work-with-rust-under-win32/2280?u=brakmic
Может ещё под VS запилят нормальное что-то. Полноценной подсветки не хватает.
https://github.com/PistonDevelopers/VisualRust
>>524213
Лучше бы под идею плагин навернули.
Лучше бы под идею плагин навернули.
>>524309
но у свифта нет даже 20% возможностей раста, не говоря уже что раст со своим зеро-оверхедом и ручным управлением памятью на типах подходит для железок, в то время как свифтопараша со своим ARC годиться только формочки для гейфонских аппов клепать.
но у свифта нет даже 20% возможностей раста, не говоря уже что раст со своим зеро-оверхедом и ручным управлением памятью на типах подходит для железок, в то время как свифтопараша со своим ARC годиться только формочки для гейфонских аппов клепать.
13 Кб, 512x320
>>524316
чому же твой раст такой медленный?
ну и про 20% ты обычный кукаретик
Самое главное из того, что у раста нет, из того что есть в swift - сферы применения, современная ide и деньги Apple.
"гейфон гейфон кококо", как же вы заебали со своей гомоэротикой, никто так много не кричит о пидорстве как те кто боятся ими стать потому что латентные
чому же твой раст такой медленный?
ну и про 20% ты обычный кукаретик
Самое главное из того, что у раста нет, из того что есть в swift - сферы применения, современная ide и деньги Apple.
"гейфон гейфон кококо", как же вы заебали со своей гомоэротикой, никто так много не кричит о пидорстве как те кто боятся ими стать потому что латентные
28 Кб, 429x295
вот кстати то, чего у раста не будет никогда, а у свифта есть за год
>>524331
Айособлядям платят все меньше и меньше, кстати, не советую. А начиналось все так хорошо.
мимо-айособлядь[/i/
Айособлядям платят все меньше и меньше, кстати, не советую. А начиналось все так хорошо.
мимо-айособлядь[/i/
24 Кб, 702x321
>>524331
Отфильтровать не забудь. Алсо, проиграл с этих хипстеров.
Отфильтровать не забудь. Алсо, проиграл с этих хипстеров.
>>524323
Где это он медленный?
http://benchmarksgame.alioth.debian.org/u64q/rust.html
Нет, ты. У раста есть статический анализ, когда же у свифта есть ссылочная дрисня.
Ну вот свифт и будет популярен среди разработчиков под iOS и OS X, как сейчас там популярен ObjC. Раст в вашу нишу не лезет, так что можешь быть спокоен.
> чому же твой раст такой медленный?
Где это он медленный?
http://benchmarksgame.alioth.debian.org/u64q/rust.html
> ну и про 20% ты обычный кукаретик
Нет, ты. У раста есть статический анализ, когда же у свифта есть ссылочная дрисня.
> Самое главное из того, что у раста нет, из того что есть в swift - сферы применения, современная ide и деньги Apple.
Ну вот свифт и будет популярен среди разработчиков под iOS и OS X, как сейчас там популярен ObjC. Раст в вашу нишу не лезет, так что можешь быть спокоен.
>>524333
ну что ты несешь то
то что в ранее менее популярную тему вкатилось много новичков и куча быдла, ранее за копейки на фрилансе заказывавшее сайты, начало заказывать за копейки ios приложения, значит только то что значит
ну что ты несешь то
то что в ранее менее популярную тему вкатилось много новичков и куча быдла, ранее за копейки на фрилансе заказывавшее сайты, начало заказывать за копейки ios приложения, значит только то что значит
>>524335
ну раст уже запустили на 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 плюс Си.
"
>>524335
ну раст уже запустили на 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 плюс Си.
"
>>524344
Ну ты понял.
Лол.
Лол x2.
Лол x3.
Rc<RefCell<Trait>> же. Да и псевдонимы для типов никто не отменял.
Не мог бы. Точно так же, как другие языки вообще говоря не выводят, передавать ли по ссылке или по значению.
...которой нет.
Хуита. Unsafe лишь позволяет делать некоторые вещи, которые нельзя сделать без него. И заметь, владение и заимствования компилятор отслеживает даже внутри блока unsafe.
> UnsafeMutablePointer<T>
> Unsafe
Ну ты понял.
> и оказалось, что переменная должна жить не в стеке, а в куче
Лол.
> Вы переписываете все, чтобы использовался Box. Потому вы понимаете, что на самом деле нужен Rc или Arc. Снова переписываете.
Лол x2.
> А потом еще раз переписываете на обычную переменную в стеке.
Лол x3.
> Rc<RefCell<Box<Trait>>>
Rc<RefCell<Trait>> же. Да и псевдонимы для типов никто не отменял.
> он мог бы выводить все эти Box, Arc и так далее автоматически
Не мог бы. Точно так же, как другие языки вообще говоря не выводят, передавать ли по ссылке или по значению.
> и медленность текущей реализации Rust
...которой нет.
> Хотя в действительности это два диалекта одного языка
Хуита. Unsafe лишь позволяет делать некоторые вещи, которые нельзя сделать без него. И заметь, владение и заимствования компилятор отслеживает даже внутри блока unsafe.
25 Кб, 409x288
>>524323
В расте на уровне типов можно описывать протоколы межпотокового взаимодействия. Получается корректность межпроцессового взаимодействия проверяется в компайлтайме тайпчекером. В свифте такое есть?
В расте на уровне типов можно описывать протоколы межпотокового взаимодействия. Получается корректность межпроцессового взаимодействия проверяется в компайлтайме тайпчекером. В свифте такое есть?
>>524335
К слову, посмотри вообще тесты-то.
Pidigits: Unsafe и вызыв из C-ной библиотеки того же кода, что и в C версии. В 3 раза больше кода.
В 3 других - в 2 раза медленее, к тому же в два раза больше кода.
При этом C/C++ анализаторы имеют ту же функциональность, просто поставляются отдельно.
Хотя с тем же regex-dna было вообще плохо, помню. И причиной была отсутствие нормальной regex библиотеки. Теперь допилили и нормально идёт.
К слову, посмотри вообще тесты-то.
Pidigits: Unsafe и вызыв из C-ной библиотеки того же кода, что и в C версии. В 3 раза больше кода.
В 3 других - в 2 раза медленее, к тому же в два раза больше кода.
При этом C/C++ анализаторы имеют ту же функциональность, просто поставляются отдельно.
Хотя с тем же regex-dna было вообще плохо, помню. И причиной была отсутствие нормальной regex библиотеки. Теперь допилили и нормально идёт.
>>524386
Они не только поставляются отдельно, они ещё и не являются частью семантики языка.
> При этом C/C++ анализаторы имеют ту же функциональность, просто поставляются отдельно.
Они не только поставляются отдельно, они ещё и не являются частью семантики языка.
>>524358
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust, где, цитирую:
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
остальные лолы туда же
и нахуй такая хуйня то нужна?
я вот на днях такую функцию в крестах написал:
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 по скорости как джава
>Ну ты понял.
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ 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 по скорости как джава
>>524358
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust, где, цитирую:
Сырые указатели (const T)
Указатели без гарантии безопасности. Настоятельно не рекомендуется их использовать.
ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
остальные лолы туда же
и нахуй такая хуйня то нужна?
я вот на днях такую функцию в крестах написал:
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 по скорости как джава
>Ну ты понял.
тут ты и кекнул
те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ 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 по скорости как джава
>>524412
>>524389
а не это я про регекспы подумал
в крестах просто другие средства контроля
но если ты не с фриланса сюда пришел то должен быть привычен к автоматическому тестированию, а при нем можно и анализаторы запускать
с таким же успехом можешь склонить на гитхабе clang и впилить сторонние статистические анализаторы туда и заявить что ты придумал совершенно новый язык
Кстати,компилятор раста написан на окамле изначально был напоминаю, где как раз таки отличный такой вывод типов
>>524389
а не это я про регекспы подумал
в крестах просто другие средства контроля
но если ты не с фриланса сюда пришел то должен быть привычен к автоматическому тестированию, а при нем можно и анализаторы запускать
с таким же успехом можешь склонить на гитхабе clang и впилить сторонние статистические анализаторы туда и заявить что ты придумал совершенно новый язык
Кстати,компилятор раста написан на окамле изначально был напоминаю, где как раз таки отличный такой вывод типов
>>524411
Только reverse-complement и вызовы GMP в pidigits.
Ну у вас-то в плюсах понимают семантику владения и заимствования? Или таки пытаются подобрать тип указателя наобум, из-за чего делают рефакторинг каждые 15 минут?
А в чём, собственно, проблема? Вывод типов есть, так что всякие `Rc<RefCell<Trait>>` ты увидишь только в сигнатурах функций.
Опять же, единственный бенчмарк, где действительно это используется — reverse-complement.
Что ещё расскажешь?
> те бенчмарки в сравнении с чистым Си которые ты скидывал написаны на НЕБЕЗОПАСНОМ Rust
Только reverse-complement и вызовы GMP в pidigits.
> ты вообще с каких будешь то? Обычно растом опытные c++ ники интересуются
Ну у вас-то в плюсах понимают семантику владения и заимствования? Или таки пытаются подобрать тип указателя наобум, из-за чего делают рефакторинг каждые 15 минут?
> и нахуй такая хуйня то нужна?
А в чём, собственно, проблема? Вывод типов есть, так что всякие `Rc<RefCell<Trait>>` ты увидишь только в сигнатурах функций.
> которая есть если писать без
Опять же, единственный бенчмарк, где действительно это используется — reverse-complement.
> все что не Unsafe по скорости как джава
Что ещё расскажешь?
http://www.slideshare.net/ScottWlaschin/fp-patterns-buildstufflt
Посмотрел тут эту презентацию.
Rust, конечно, называют смешанным языком программирования (пп, ооп, фп), но тут я прихуел. > 9000 вещей взяты из фп. И без фанатизма.
Посмотрел тут эту презентацию.
Rust, конечно, называют смешанным языком программирования (пп, ооп, фп), но тут я прихуел. > 9000 вещей взяты из фп. И без фанатизма.
>>524496
Функциональщики пытались нормальным посонам подложить такую заразу!
Функциональщики пытались нормальным посонам подложить такую заразу!
>>524537
Язык имеет не самый низкий порог вхождения, единственное что вызывает интерес большинства (как и Go) – авторитет компаний, его разрабатывающий. Навесь на него ещё тысячу фич и получишь неосваеваемый язык. Зачем каждый язык превращать в точный клон другого?
Язык имеет не самый низкий порог вхождения, единственное что вызывает интерес большинства (как и Go) – авторитет компаний, его разрабатывающий. Навесь на него ещё тысячу фич и получишь неосваеваемый язык. Зачем каждый язык превращать в точный клон другого?
>>524553
HKT не просто «ещё одна фича», это важная часть системы типов, позволяющая строить мощные абстракции. Добавление их к языку как минимум позволит избавится от костылей вроде `try!` и допилить интерфейс коллекций (некоторые вещи не реализованы из-за отсутствия HKT: https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#lack-of-iterator-methods).
HKT не просто «ещё одна фича», это важная часть системы типов, позволяющая строить мощные абстракции. Добавление их к языку как минимум позволит избавится от костылей вроде `try!` и допилить интерфейс коллекций (некоторые вещи не реализованы из-за отсутствия HKT: https://github.com/rust-lang/rfcs/blob/master/text/0235-collections-conventions.md#lack-of-iterator-methods).
>>524601
Нет, это вещь уровня генериков.
http://www.hydrocodedesign.com/2014/04/02/higher-kinded-types/
Нет, это вещь уровня генериков.
http://www.hydrocodedesign.com/2014/04/02/higher-kinded-types/
>>524662
Вот он звездный час аутиста - вместо ответа на вопрос обозвать блохами. Ведь иначе нахуя он это ненужное говно читал.
Я читал тапл пять лет назад - и с тех пор полезность этой книги не увеличилась.
Вот он звездный час аутиста - вместо ответа на вопрос обозвать блохами. Ведь иначе нахуя он это ненужное говно читал.
Я читал тапл пять лет назад - и с тех пор полезность этой книги не увеличилась.
>>525008
Ой какое смешное слово, держите меня семеро. Давайте еще раз посмеемся над пистоном, это же так забавно.
Ой какое смешное слово, держите меня семеро. Давайте еще раз посмеемся над пистоном, это же так забавно.
87 Кб, 785x586
>>524344
«Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти 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.
«Но что самое печальное, компилятор уже знает о времени жизни всех переменных, он мог бы выводить все эти 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.
>>525152
Ради стабилизации языка и стандартной библиотеки. До 1.0 раст едва ли был пригоден к использованию из-за постоянных изменений.
Ради стабилизации языка и стандартной библиотеки. До 1.0 раст едва ли был пригоден к использованию из-за постоянных изменений.
>>525287
Скорее всего не будет.
Скорее всего не будет.
That feel when no gc
>>525798
Толсто.
Толсто.
>>526312
Да, только servo умеет ровно в 200 раз меньше, чем Gecko. Когда серво выйдет на масштабы геки, будет сосать так, что начнет ссать себе на ебало
Да, только servo умеет ровно в 200 раз меньше, чем Gecko. Когда серво выйдет на масштабы геки, будет сосать так, что начнет ссать себе на ебало
>>526506
Развивают замену C++, путем использования Rust'а в реальном проекте
И движок сделанный под современные реалии им не помешает.
"Тратятся"? Да там порядка 5 человек с мозиллы и коммьюнити. Какие ж это траты
Развивают замену C++, путем использования Rust'а в реальном проекте
И движок сделанный под современные реалии им не помешает.
"Тратятся"? Да там порядка 5 человек с мозиллы и коммьюнити. Какие ж это траты
>>526673
Но ведь
Но ведь
> Когда серво выйдет на масштабы геки, будет сосать так, что начнет ссать себе на ебало
>>526677
Не слушай того дегенерата, будет работать достаточно резво, оптимизацией они будут заниматься позже.
Не слушай того дегенерата, будет работать достаточно резво, оптимизацией они будут заниматься позже.
>>526720
А теперь скажи мне, почему оно вообще станет работать резво? Это про Rust только пиздят какой он охуенный, на деле он сейчас медленнее крестов в пять-шесть раз на реальных задачах. Почему в 2015 году Go уже показывает хорошую производительность и поощрает программиста, а Rust сосет по всем сравнениям и орет про систему типов?
А теперь скажи мне, почему оно вообще станет работать резво? Это про Rust только пиздят какой он охуенный, на деле он сейчас медленнее крестов в пять-шесть раз на реальных задачах. Почему в 2015 году Go уже показывает хорошую производительность и поощрает программиста, а Rust сосет по всем сравнениям и орет про систему типов?
>>526771
Илюш, ты ошибся тредом.
> Go уже показывает хорошую производительность
> Rust сосет по всем сравнениям
Илюш, ты ошибся тредом.
>>526876
Так он врядли будет быстрее, но у раста удобные средства для параллелизации кода, в отличии от крестов.
Так он врядли будет быстрее, но у раста удобные средства для параллелизации кода, в отличии от крестов.
Rust 1.2 вышел
- ускорили компиляцию
- поддержали линковку с MSVS-бинарниками
- запилили DST
http://blog.rust-lang.org/2015/08/06/Rust-1.2.html
- ускорили компиляцию
- поддержали линковку с MSVS-бинарниками
- запилили DST
http://blog.rust-lang.org/2015/08/06/Rust-1.2.html
>>526975
Ну обещали же пофиксить :(
> Unwinding support is not yet available (the process aborts on panic), but work is underway to land it.
Ну обещали же пофиксить :(
>>527005
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 эту проблему решили и теперь мы можем класть в дженерик-контейнер объект любого размера, а не только размера ссылки. То есть ты можешь положить туда и ссылку, и число и массив. Это экономит память и время для записи и чтения данных в контейнере. Это и называется "типы динамического размера" - потому что размер типа, который лежит в контейнере, может меняться.
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 эту проблему решили и теперь мы можем класть в дженерик-контейнер объект любого размера, а не только размера ссылки. То есть ты можешь положить туда и ссылку, и число и массив. Это экономит память и время для записи и чтения данных в контейнере. Это и называется "типы динамического размера" - потому что размер типа, который лежит в контейнере, может меняться.
>>527033
разметка проебана, но суть, надесь, понятна.
разметка проебана, но суть, надесь, понятна.
Короче, блядь, решил попробовать ваш этот раст. Под виндой (потому что приложение все равно будет кроссплатформенным и надо будет билдить под виной в итоге). Запустил
$ 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
Заебись, сука. Я в бешенстве. Гугл нихуя путного не выдал. Кто-нибудь сталкивался с таким говном? Как указать пути раз и навсегда, чтобы не ебаться каждый раз? Дайте гайд нормальный.
$ 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
Заебись, сука. Я в бешенстве. Гугл нихуя путного не выдал. Кто-нибудь сталкивался с таким говном? Как указать пути раз и навсегда, чтобы не ебаться каждый раз? Дайте гайд нормальный.
>>527162
Пиздец, тебе же русским языком написали - не хватает libeay32.a libssl32.a, наверняка они есть в папке с openssl-ем, нужно указать папку к ним через LIBRARY_PATH
Пиздец, тебе же русским языком написали - не хватает libeay32.a libssl32.a, наверняка они есть в папке с openssl-ем, нужно указать папку к ним через LIBRARY_PATH
>>527033
Это значит, что можно делать что-то вроде
[i32; n] и n во время работы программы определяется? В документации такое описано, но в 1.1 не получалось.
Это значит, что можно делать что-то вроде
[i32; n] и n во время работы программы определяется? В документации такое описано, но в 1.1 не получалось.
>>527172
Их там тоже нету (в mingw т.е.). Нашел тут http://indy.fulgan.com/SSL/
А вообще, пошел на хуй. Вопрос был в том как решить эту проблему (я и сам могу). Суть в том, что приходится заниматься такой не нужной еблей. (это еще мне повезло, что был предустановлен mingw).
>не хватает libeay32.a libssl32.a, наверняка они есть в папке с openssl-ем, нужно указать папку к ним через LIBRARY_PATH
Их там тоже нету (в mingw т.е.). Нашел тут http://indy.fulgan.com/SSL/
А вообще, пошел на хуй. Вопрос был в том как решить эту проблему (я и сам могу). Суть в том, что приходится заниматься такой не нужной еблей. (это еще мне повезло, что был предустановлен mingw).
>>527190
*не в том
*не в том
>>527193
Еще раз, я пишу не только под windows, а кроссплатформенное приложение.
Еще раз, я пишу не только под windows, а кроссплатформенное приложение.
>>527194
Кросс-компиляция же. А ты думал кто-то и правда ебётся под спермой со всеми этими цигвинами и прочей неюзабельной хуитой?
> потому что приложение все равно будет кроссплатформенным и надо будет билдить под виной в итоге
Кросс-компиляция же. А ты думал кто-то и правда ебётся под спермой со всеми этими цигвинами и прочей неюзабельной хуитой?
>>527162
Понятно. Значит, Петухан Куриханыч такое же ненужное красноглазое поделие, как и Go. Наверно, и Swift такой же.
Почему-то любой C/C++/Pascal код с кроссплатформенными библиотеками нормально собирается под любой платформой (как минимум под Windows и Linux).
Понятно. Значит, Петухан Куриханыч такое же ненужное красноглазое поделие, как и Go. Наверно, и Swift такой же.
Почему-то любой C/C++/Pascal код с кроссплатформенными библиотеками нормально собирается под любой платформой (как минимум под Windows и Linux).
>>527346
Как у тебя он будет собираться, если ты библиотеки не приложишь к нему, наркоман?
Как у тебя он будет собираться, если ты библиотеки не приложишь к нему, наркоман?
>>527346
Go умеет в кросскомпиляцию, собираю статические бинарники для всего, что можно, через gox.
Одной командой оно мне на все платформы собрало и на гитхаба релиз сделало. Куда проще - я даже не знаю. В c/c++/pascal такое можно сделать, чтобы еще потом либы не нужно было таскать за собой?
С 1.5 стало еще проще, не надо собирать тулчейн.
Вопрос ненужности опущу, а то обзовут Илюшей.
Вот только твит от другого Илюши:
https://mobile.twitter.com/jamwt/status/629727590782099456
Go умеет в кросскомпиляцию, собираю статические бинарники для всего, что можно, через gox.
Одной командой оно мне на все платформы собрало и на гитхаба релиз сделало. Куда проще - я даже не знаю. В c/c++/pascal такое можно сделать, чтобы еще потом либы не нужно было таскать за собой?
С 1.5 стало еще проще, не надо собирать тулчейн.
Вопрос ненужности опущу, а то обзовут Илюшей.
Вот только твит от другого Илюши:
https://mobile.twitter.com/jamwt/status/629727590782099456
>>527349
Нужно. Потом может узнаешь, когда закончу.
Нужно. Потом может узнаешь, когда закончу.
Вот есть такие трейты как clone и copy.
Чем они отличаются технически?
И ещё. Вот у меня в некой структуре хранится какая-та другая структура (допустим, таблица, а в ней ячейки). И мне нужно получить данные ячейки (не изменяя). Уместно использование clone? Как заимствовать, если данные большие? Имеется в виду, какой самый оптимальный вариант для программы?
Чем они отличаются технически?
И ещё. Вот у меня в некой структуре хранится какая-та другая структура (допустим, таблица, а в ней ячейки). И мне нужно получить данные ячейки (не изменяя). Уместно использование clone? Как заимствовать, если данные большие? Имеется в виду, какой самый оптимальный вариант для программы?
>>527675
`Clone` предоставляет метод `clone()`, когда же `Copy` — маркерный типаж, меняет семантику перемещения на семантику копирования.
Чтобы реализовать `Copy`, нужно сначала реализовать `Clone`.
Зачем? Почему бы просто не взять неизменяемую ссылку на эти данные?
> Вот есть такие трейты как clone и copy. Чем они отличаются технически?
`Clone` предоставляет метод `clone()`, когда же `Copy` — маркерный типаж, меняет семантику перемещения на семантику копирования.
Чтобы реализовать `Copy`, нужно сначала реализовать `Clone`.
> И мне нужно получить данные ячейки (не изменяя). Уместно использование clone?
Зачем? Почему бы просто не взять неизменяемую ссылку на эти данные?
>>527688
Есть в /pr/ такой восторженный персонаж. Зайди в готред чтобы застать его в естественной среде обитания.
Есть в /pr/ такой восторженный персонаж. Зайди в готред чтобы застать его в естественной среде обитания.
>>527681
Возвращать &? Я такое реализовывал, но не знаю насколько это правильно. Просто в справочнике написано, что следует при любой возможности реализовывать clone. Опять же, абсурдно, может я неправильно контекст понял.
Возвращать &? Я такое реализовывал, но не знаю насколько это правильно. Просто в справочнике написано, что следует при любой возможности реализовывать clone. Опять же, абсурдно, может я неправильно контекст понял.
>>527764
Да, просто возвращать &. Не вижу каких-либо проблем с этим.
Возможность копировать данные бывает крайне полезна, тем более, что есть derive. Но это не имеет отношения к тому, как ссылаться на данные.
> Возвращать &? Я такое реализовывал, но не знаю насколько это правильно.
Да, просто возвращать &. Не вижу каких-либо проблем с этим.
> Просто в справочнике написано, что следует при любой возможности реализовывать clone.
Возможность копировать данные бывает крайне полезна, тем более, что есть derive. Но это не имеет отношения к тому, как ссылаться на данные.
>>527822
let mut s = Something::new(); // мутабельно
let a = s.get_x(); // Возвращает ссылку -> s перестает быть мутабельной
s.set_x(10); // ошибка
Хотя, конечно, решается с помощью { let a = s.get_x(); }
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 и подводные камни с указателями (определяемые компилятором, но которые могут быть непонятные для новичка).
http://cglab.ca/~abeinges/blah/too-many-lists/book/
Ещё не до конца готов, но пойдет.
Более-менее подробно описывает все указатели, неявные проблемы с освобождением памяти при использовании Box и подводные камни с указателями (определяемые компилятором, но которые могут быть непонятные для новичка).
>>529253
признайся, ты ведь написал этот пост, просто чтобы поднять ненужный никому тред о расте :)
признайся, ты ведь написал этот пост, просто чтобы поднять ненужный никому тред о расте :)
>>529253>>529775
Прочитал уже?
Вот смотрю код Servo. В коде 690 упоминаний unsafe, но 90% из них - просто текст из какого-то копипастного документа в тестах, остальное - подключение C/C++ кода. Т.е. обходятся без unsafe при написании кода, а по той статье складывается впечатление, что нет.
Поясните за Phantom types. Что за муть? Для чего нужна?
Прочитал уже?
Вот смотрю код Servo. В коде 690 упоминаний unsafe, но 90% из них - просто текст из какого-то копипастного документа в тестах, остальное - подключение C/C++ кода. Т.е. обходятся без unsafe при написании кода, а по той статье складывается впечатление, что нет.
Поясните за Phantom types. Что за муть? Для чего нужна?
>>529848
Тип, параметризованный другим типом, значения которого не используются. По сути, добавление к типу параметра, который проверяется только на этапе компиляции.
Вот с примерами:
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
> Поясните за 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
Бамп лучшему языку этого года!
48 Кб, 1200x800
>>529923
Ну это и в доках написано.
https://github.com/servo/servo/search?utf8=✓&q=PhantomData
Вот маркер добавляется в тип, но нигде никаких проверок нет.
По ссылкам на блог - концепция понятна, но не вижу связи в расте (ссылка выше).
Или вот здесь.
https://github.com/servo/tendril/blob/0de69e948fdcd3fdc1133f5370007512939cb15d/src/tendril.rs
Как делается проверка?
http://www.servoexperiments.com/
> Тип, параметризованный другим типом, значения которого не используются. По сути, добавление к типу параметра, который проверяется только на этапе компиляции.
Ну это и в доках написано.
https://github.com/servo/servo/search?utf8=✓&q=PhantomData
Вот маркер добавляется в тип, но нигде никаких проверок нет.
По ссылкам на блог - концепция понятна, но не вижу связи в расте (ссылка выше).
Или вот здесь.
https://github.com/servo/tendril/blob/0de69e948fdcd3fdc1133f5370007512939cb15d/src/tendril.rs
Как делается проверка?
http://www.servoexperiments.com/
56 Кб, 1000x1000
Свежая выжимка из блога:
Планы на Раст в (к?) 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).
Планы на Раст в (к?) 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).
>>530300
Ну так в доках так же написано, зачем это нужно: http://doc.rust-lang.org/std/marker/struct.PhantomData.html
> Ну это и в доках написано.
Ну так в доках так же написано, зачем это нужно: http://doc.rust-lang.org/std/marker/struct.PhantomData.html
>>530355
ХОТЕТ
ХОТЕТ
Ну и шумно этот Ваш Русь. Сплошное шаблонное питушение! Нахуй так жить!
школьник-кун
школьник-кун
>>529848
Вот представь что тебе нужен структура UID, но чтобы для каждого родителького типа нужен свой тип UIDов, которые бы не пересекались между собой.
Но внутри UID у тебя просто u64, а тебе надо куда то слить параметр T. Для этого делается так:
struct UID<T>{
inner: u64,
type: PhantomData<T>
}
Второе поле будет нулевой длинны, но компилятор уже не будет ругаться что параметр T не использован.
>Поясните за Phantom types. Что за муть? Для чего нужна?
Вот представь что тебе нужен структура UID, но чтобы для каждого родителького типа нужен свой тип UIDов, которые бы не пересекались между собой.
Но внутри UID у тебя просто u64, а тебе надо куда то слить параметр T. Для этого делается так:
struct UID<T>{
inner: u64,
type: PhantomData<T>
}
Второе поле будет нулевой длинны, но компилятор уже не будет ругаться что параметр T не использован.
>>530423
О, вот теперь понятно, спасибо.
О, вот теперь понятно, спасибо.
>>530923
Консолечка, бггг.
Подойдёт любая. Проверь, чтобы папка, содержащая бинарник карго, была в PATH.
Консолечка, бггг.
Подойдёт любая. Проверь, чтобы папка, содержащая бинарник карго, была в PATH.
>>531068
Блядь, долбоеб тупой, тебе скорее всего это не нужно.
Блядь, долбоеб тупой, тебе скорее всего это не нужно.
281 Кб, 1079x530
Интересно сколько тут ржавообразных следит за проектом / обучается / пишет что-то.
>>531104
ну я с помощью rust shell все сделал. просто не понял, что-как с командой строкой делать
ну я с помощью rust shell все сделал. просто не понял, что-как с командой строкой делать
>>531484
Если родными тулзами от мс, то вполне ничего.
Если родными тулзами от мс, то вполне ничего.
Разработчики Раста кричали, что try-catch НИНУЖИН и вообще устарелая концепция, ебашьте try!()try!()try!()try!()try!(), но в Июле была встреча разработчиков с первыми компаниями, внедряющими раст в продакшн и у всех было требование допилить нормальный перехват ошибок. И уже сейчас он практически готов ( http://doc.rust-lang.org/nightly/std/thread/fn.catch_panic.html );
Также среди требований было:
Допиливание #[no_std] (для встраиваемых систем; практически готово);
Ускорение компилятора (ну это и так было одной из целей);
Кастомный panic (?).
Также среди требований было:
Допиливание #[no_std] (для встраиваемых систем; практически готово);
Ускорение компилятора (ну это и так было одной из целей);
Кастомный panic (?).
>>533058
И они тоже.
И они тоже.
>>533000
Няша, это совсем не для штатной обработки ошибок. Читай https://github.com/alexcrichton/rfcs/blob/stabilize-catch-panic/text/0000-stabilize-catch-panic.md
> 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.
>>532085
Это тот, что 2013 года? По-новее ничего нету?
Это тот, что 2013 года? По-новее ничего нету?
675 Кб, 2408x1316
86 Кб, 717x230
>>534223
А ничего не происходит пока. Тем более, воскресенье.
http://www.youtube.com/watch?v=7q9vIMXSTzc
Вот старая презентация Серво (янв. 15).
~32+ минута - показывают замеры рендеринга при разных условиях, собрал в первую картинку.
Ну и другая информация:
Количество разработчиков Servo: ~12;
Количество разработчиков Gecko: >50;
Servo будет встраиваться в Gecko.
А ничего не происходит пока. Тем более, воскресенье.
http://www.youtube.com/watch?v=7q9vIMXSTzc
Вот старая презентация Серво (янв. 15).
~32+ минута - показывают замеры рендеринга при разных условиях, собрал в первую картинку.
Ну и другая информация:
Количество разработчиков Servo: ~12;
Количество разработчиков Gecko: >50;
Servo будет встраиваться в Gecko.
150 Кб, 766x396
>>534254
Судя по пикрелейтед они таки дохуя уже реализовали. Если он и в самом деле будет работать так же быстро как и обещают будет вин.
Судя по пикрелейтед они таки дохуя уже реализовали. Если он и в самом деле будет работать так же быстро как и обещают будет вин.
>>534258
https://github.com/servo/servo/search?utf8=%E2%9C%93&q=std%3A%3Asimd&type=Code
Судя по всему еще нет, видимо из-за нестабильного std::simd
https://github.com/servo/servo/search?utf8=%E2%9C%93&q=std%3A%3Asimd&type=Code
Судя по всему еще нет, видимо из-за нестабильного std::simd
>>534439
Нет, не только. Скрипты там тоже есть, просто многое пока не работает.
Конкретно здесь не работает именно постинг, открыть форму и ввести пост/капчу таки можно.
Нет, не только. Скрипты там тоже есть, просто многое пока не работает.
Конкретно здесь не работает именно постинг, открыть форму и ввести пост/капчу таки можно.
>>534263
http://huonw.github.io/blog/2015/08/simd-in-rust/
Вот, кстати, час назад выкатили. Как минимум ещё 3 месяца не будет в стабильной.
http://huonw.github.io/blog/2015/08/simd-in-rust/
Вот, кстати, час назад выкатили. Как минимум ещё 3 месяца не будет в стабильной.
>>536974
Илюш, уйди.
Илюш, уйди.
>>536974
конечно же Раст.
конечно же Раст.
>>537219
и вообще, какого хуя вы подняли этот тонущий никому не нужный тред?! его вчера еще даже на третьей странице не было, heheuhe
и вообще, какого хуя вы подняли этот тонущий никому не нужный тред?! его вчера еще даже на третьей странице не было, heheuhe
>>537333
Извини, что у нас нет местного Илюши, Илюши не нужны.
Очевидно же, что всё увлечены работой над языком, переписываться некогда.
Извини, что у нас нет местного Илюши, Илюши не нужны.
Очевидно же, что всё увлечены работой над языком, переписываться некогда.
25 Кб, 300x225
В clap добавили генерацию из yaml файлов.
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.
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.
>>539128
Тоже самое, что мэмори пул.
Тоже самое, что мэмори пул.
>>540081
Почему ты пишешь в треде сгнившего говна о системном языке?
Почему ты пишешь в треде сгнившего говна о системном языке?
>>540081
Потому не отсутствие GC тянет за собой все остальное. Или простенько и все течет, как в С, или так.
Потому не отсутствие GC тянет за собой все остальное. Или простенько и все течет, как в С, или так.
Тут гугл и фейсбук для никому ненужному языку выкатили поддержку для своих систем сборки Bazel и Buck.
Почему в вашем охуенном языке нельзя сделать вот так при инициализации структур?
some_struct { f1: 3, f2: f1 + 1 }
some_struct { f1: 3, f2: f1 + 1 }
Так что, насколько существенный профит использования двух видов строк? Они где-нибудь поясняли?
>>543104
Ну хуй знает
>язык позиционируется как потенциальная замена си и крестам
>Rust хоть где-нибудь еще не превратился в кресты?
Ну хуй знает
>>543774
А с отладкой там как? Сам пока с VisualRust сижу, только из-за более-менее удобного дебага.
А с отладкой там как? Сам пока с VisualRust сижу, только из-за более-менее удобного дебага.
>>543821
Хех. Это я со стороны говорю, сам вообще в notepad++ калякаю. А дебажить пробовал через консолечку, но это уныло вообще.
Хех. Это я со стороны говорю, сам вообще в notepad++ калякаю. А дебажить пробовал через консолечку, но это уныло вообще.
>>543916
Даже это поделие на джаве работает быстрее, чем "редактор" атом.
Даже это поделие на джаве работает быстрее, чем "редактор" атом.
1.3 Вышел.
Небольшие изменения в стандартной библиотеке
Поддержка Windows XP
Всё.
В 1.4 обещается полная поддержка MSVC.
Небольшие изменения в стандартной библиотеке
Поддержка Windows XP
Всё.
В 1.4 обещается полная поддержка MSVC.
>>544966
Ну они и слоу, я думал, что с 1.2 уже без проблем работает.
> В 1.4 обещается полная поддержка MSVC.
Ну они и слоу, я думал, что с 1.2 уже без проблем работает.
>>544979
Там это ещё была негарантированная фича, не для продакшена.
Там это ещё была негарантированная фича, не для продакшена.
95 Кб, 800x517
Долго думал, что мне напоминает ОП-пик, и вот нашел!
Алсо, язык ни хера не системный, как тут пытаются утверждать, на нем даже двухсвязный список без unsafe не написать, следовательно на системном коде все его преимущества ВНЕЗАПНО разбиваются об unsafe,
и остается только убогий вырвиглазный синтаксис с шаблонным питушением.
На самом деле Rust - это загон для быдлокодеров, по типу пикрелейтед.
школьник-кун
Алсо, язык ни хера не системный, как тут пытаются утверждать, на нем даже двухсвязный список без unsafe не написать, следовательно на системном коде все его преимущества ВНЕЗАПНО разбиваются об unsafe,
и остается только убогий вырвиглазный синтаксис с шаблонным питушением.
На самом деле Rust - это загон для быдлокодеров, по типу пикрелейтед.
школьник-кун
http://blog.servo.org/2015/09/21/twis-34/
Альфа Servo к концу года.
Параллельно пилят также подобие Chromium Embedded Framework с новым движком.
Альфа Servo к концу года.
Параллельно пилят также подобие Chromium Embedded Framework с новым движком.
104 Кб, 1278x914
>>547371
Не знаю, я от туда выпустился.
Погоняло старое прост.
Ну и в подтверждение прошлого поста (сравнивать аналогичные методы):
Двухсвязный список на Си:
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
Не знаю, я от туда выпустился.
Погоняло старое прост.
Ну и в подтверждение прошлого поста (сравнивать аналогичные методы):
Двухсвязный список на Си:
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
>>547383
Ты конеш хуй с пальцем сравнил, но читабельность этой хуитки на расте хуже чем читабельность stl в c++.
Ты конеш хуй с пальцем сравнил, но читабельность этой хуитки на расте хуже чем читабельность stl в c++.
>>547395
Эта хуитка на Rust - часть стандартной библиотеки, насколько я понимаю.
И я сказал, что сравнивать только аналогичные методы, ибо на няшной нет смысла писать итератор, т.к. это просто inem->next / item->prev, а шаблонное питушение в данном случае ващпе не уместно, только жизнь усложняет, а реальных профитов - ноль.
Эта хуитка на Rust - часть стандартной библиотеки, насколько я понимаю.
И я сказал, что сравнивать только аналогичные методы, ибо на няшной нет смысла писать итератор, т.к. это просто inem->next / item->prev, а шаблонное питушение в данном случае ващпе не уместно, только жизнь усложняет, а реальных профитов - ноль.
>>547400
Реализация интерфейса итератора дает бесконечное число профитов - контейнер могут использовать алгоритмы стандартной библиотеки.
Реализация интерфейса итератора дает бесконечное число профитов - контейнер могут использовать алгоритмы стандартной библиотеки.
>>547414
Зависит от конкретной реализации библиотеки, так что не аргумент.
Зависит от конкретной реализации библиотеки, так что не аргумент.
>>547414
К слову, разрабы говорят, что современные компиляторы позволяют избавляться от проверки границ при оптимизации. Итераторы имеют к этому отношения?
К слову, разрабы говорят, что современные компиляторы позволяют избавляться от проверки границ при оптимизации. Итераторы имеют к этому отношения?
67 Кб, 604x439
>>547429
Но Степанов считает, что ООП и шаблонное питушение в частности - говно:
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
Но Степанов считает, что ООП и шаблонное питушение в частности - говно:
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
>>547445
Да.
> К слову, разрабы говорят, что современные компиляторы позволяют избавляться от проверки границ при оптимизации. Итераторы имеют к этому отношения?
Да.
>>547457
Да.
Бред. Он основоположник шаблонов и автор STL. Шаблоны - это анти-ООП, что видно даже по С++ в вопросах типа "наследование или шаблоны". См. http://www.stepanovpapers.com/EoP-StanfordEE380.pdf
>ООП - говно
Да.
>шаблонное питушение в частности
Бред. Он основоположник шаблонов и автор STL. Шаблоны - это анти-ООП, что видно даже по С++ в вопросах типа "наследование или шаблоны". См. http://www.stepanovpapers.com/EoP-StanfordEE380.pdf
>>547457
О, так он ещё и кефирщик?
> Чтобы вскрыть корни подобного «культа отдельно-взятой технологии», Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла «тихая революция». Молодые сторонники теории относительности, массово пришедшие в номенклатуру университетов, тогда постепенно захватили власть в области преподавания физики, навязав свою малоизвестную, но столь любимую интеллектуалами того времени теорию относительности уже широким массам физиков.
> На самом деле, в то время имелись как положительные эксперименты и опыты, подтверждающие существование эфира, так и отрицательные. Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики
> После чего эфир был незаслуженно «закрыт» и отправлен в отставку, и вот, уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра.
О, так он ещё и кефирщик?
38 Кб, 584x643
>>547485
Ага, именно поэтому он написал stl на с++, используя классы и т.п.
Даже в презентации он не проч побаловаться перегрузкой операторов.
такой-то хэйтер ооп!
Ага, именно поэтому он написал stl на с++, используя классы и т.п.
Даже в презентации он не проч побаловаться перегрузкой операторов.
такой-то хэйтер ооп!
>>547554
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.
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.
>>547583
Без ООП очень легко. Вместо наследования - статический полиморфизм (т.е. compile time duck typing), концепты (т.е. тайпклассы) и варианты (т.е. ADT). Посмотри язык Clay. Это С++ без ООП и другим синтаксисом. Очень легкий и мощный язык. И круды клепать было бы нормально, с такой-то compile-time рефлексией сделать ActiveRecord.
Без ООП очень легко. Вместо наследования - статический полиморфизм (т.е. compile time duck typing), концепты (т.е. тайпклассы) и варианты (т.е. ADT). Посмотри язык Clay. Это С++ без ООП и другим синтаксисом. Очень легкий и мощный язык. И круды клепать было бы нормально, с такой-то compile-time рефлексией сделать ActiveRecord.
>>547586
Ну ты и сам понимаешь, что по форме это тот же ООП, на манер пердона. И в js тоже ООП, хоть вместо классов и какая-то хрень. Да даже в перле, где объект - это hashtable.
Ну ты и сам понимаешь, что по форме это тот же ООП, на манер пердона. И в js тоже ООП, хоть вместо классов и какая-то хрень. Да даже в перле, где объект - это hashtable.
>>547592
Тогда и в Хаселле ООП, чего уж там. Только весь мир не считает это ООП, ты уж не обессудь.
Тогда и в Хаселле ООП, чего уж там. Только весь мир не считает это ООП, ты уж не обессудь.
>>547598
Содержательно - конечно, не ООП. Но Степанов-то говорит - ООП хуйня, алгоритмы надо задрачивать. Что для академического олдскульного CS-ника, конечно, понятно, но основной потребитель же - крудошлёп, для него альтернатива ООП - visual basic.
Содержательно - конечно, не ООП. Но Степанов-то говорит - ООП хуйня, алгоритмы надо задрачивать. Что для академического олдскульного CS-ника, конечно, понятно, но основной потребитель же - крудошлёп, для него альтернатива ООП - visual basic.
>>547601
Основной потребитель творчества Степанова - модерновый любитель плюсиков-трусиков, который это ООП на хую вертел. И что в Clay, что в Rust - ООП выпилено. В Visual Basic (даже 6), ООП, кстати, есть.
Основной потребитель творчества Степанова - модерновый любитель плюсиков-трусиков, который это ООП на хую вертел. И что в Clay, что в Rust - ООП выпилено. В Visual Basic (даже 6), ООП, кстати, есть.
>>547606
Ну тут ты прав, наверное, потребитель тоже небыдло.
потреблял творчество Степанова, когда тот ещё трудился в SGI. возненанавидел и темплейты, и трусики, обыдлился
Ну тут ты прав, наверное, потребитель тоже небыдло.
потреблял творчество Степанова, когда тот ещё трудился в SGI. возненанавидел и темплейты, и трусики, обыдлился
>>547616
Хуясе ты дядя.
Хуй знает чем тебе темплейты (человеческие, а не Александреску-стал и boost::MPL) не угодили. Вообще, конечно, код тех времен довольно уебищен, стандарта начали придерживаться позже. Синтаксис тоже не очень. Но, с другой стороны, Clay показывает, что сама идея - ничего так.
Хуясе ты дядя.
Хуй знает чем тебе темплейты (человеческие, а не Александреску-стал и boost::MPL) не угодили. Вообще, конечно, код тех времен довольно уебищен, стандарта начали придерживаться позже. Синтаксис тоже не очень. Но, с другой стороны, Clay показывает, что сама идея - ничего так.
>>547622
Изначально их вообще препроцессор разворачивал, поэтому до стандарта был тот ещё адок: sgi, hp, ms и гнутый stl были во многом несовместимы. Причём самым человеческим был ms stl, внезапно не перевариваемый gcc. Ну и как-то получилось, что можно всё некритичное пилить на пердоне, а где нужно побыстрее, пилить к пердону модули: эффективность просто на порядок выше.
Изначально их вообще препроцессор разворачивал, поэтому до стандарта был тот ещё адок: sgi, hp, ms и гнутый stl были во многом несовместимы. Причём самым человеческим был ms stl, внезапно не перевариваемый gcc. Ну и как-то получилось, что можно всё некритичное пилить на пердоне, а где нужно побыстрее, пилить к пердону модули: эффективность просто на порядок выше.
56 Кб, 800x674
>>547581
Я привел часть. этой цитаты в переводе на русский.
Цитата вроде как относится к пост-stl времени.
Кстати, шаблоны, и перегрузка операторов - это ооп, вроде как, так что отрицать ооп и при этом юзать перегрузки, это те еще взаимоисключающие параграфы(примерно как у проф. Орлова с системным подходом, ЛОЛ)
>>547606
охуительные истории!
https://ru.m.wikipedia.org/wiki/Rust_(язык_программирования)
Я привел часть. этой цитаты в переводе на русский.
Цитата вроде как относится к пост-stl времени.
Кстати, шаблоны, и перегрузка операторов - это ооп, вроде как, так что отрицать ооп и при этом юзать перегрузки, это те еще взаимоисключающие параграфы(примерно как у проф. Орлова с системным подходом, ЛОЛ)
>>547606
охуительные истории!
https://ru.m.wikipedia.org/wiki/Rust_(язык_программирования)
51 Кб, 600x374
>>547834
Ах извинити прафессар, куда нам убогим до Вас!!!
Ты хоть понимаешь, что если в языке разрешена перегрузка операторов, то тогда любая закорючка может означать все, что угодно, и результатом 1+1 может быть "Ты - хуй!!!"?
Перегрузки операций и это зло на равные с ООП и шаблонным питушением, ящитаю.
Ах извинити прафессар, куда нам убогим до Вас!!!
Ты хоть понимаешь, что если в языке разрешена перегрузка операторов, то тогда любая закорючка может означать все, что угодно, и результатом 1+1 может быть "Ты - хуй!!!"?
Перегрузки операций и это зло на равные с ООП и шаблонным питушением, ящитаю.
>>547837
Так и вызов функции может означать что угодно. Написал add(1,1), а там - "ты - хуй". Я уже писал что я по поводу этого "в программе кишки торчат наружу" думаю в go-треде:
"Go сделан сишкой с GC. А у сишки единственное достоинство перед С++, на которое часто тут надрачивают, - это отсутствия заднего двора у кода. То, что ты видишь, то и будет исполняться. Никто не кинет эксепшен, никто его не замаскирует. Никто не перегрузит оператор. И функции тоже никто перегружать не будет.
Это дает возможность писать простые утилиты с кишками наружу. Мечта работодателя, программист превращается в винтик.
В общем, идея довольно неплохая для простых корпоративных unix-way утилит - дать говноязык с кодом, выглядящим как говно, который не дает выебываться.
Т.е. пока все делали мечту программистов, гугл сделал мечту корпораций."
Так и вызов функции может означать что угодно. Написал add(1,1), а там - "ты - хуй". Я уже писал что я по поводу этого "в программе кишки торчат наружу" думаю в go-треде:
"Go сделан сишкой с GC. А у сишки единственное достоинство перед С++, на которое часто тут надрачивают, - это отсутствия заднего двора у кода. То, что ты видишь, то и будет исполняться. Никто не кинет эксепшен, никто его не замаскирует. Никто не перегрузит оператор. И функции тоже никто перегружать не будет.
Это дает возможность писать простые утилиты с кишками наружу. Мечта работодателя, программист превращается в винтик.
В общем, идея довольно неплохая для простых корпоративных unix-way утилит - дать говноязык с кодом, выглядящим как говно, который не дает выебываться.
Т.е. пока все делали мечту программистов, гугл сделал мечту корпораций."
>>547840
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
>Кококо злые корпорации не дают самовыразиться
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
>>547848
Ну иди и пиши на Go, интеллектуал.
Ну иди и пиши на Go, интеллектуал.
>>547837
И как это связано с утверждением "перегрузка операторов - это ООП"?
>Ты хоть понимаешь, что если в языке разрешена перегрузка операторов, то тогда любая закорючка может означать все, что угодно, и результатом 1+1 может быть "Ты - хуй!!!"?
И как это связано с утверждением "перегрузка операторов - это ООП"?
>>547954
Самый известный ООП язык, где перегрузку запретили под мотивацией "ко-ко-ко индусы запутаются" - это Java. Еще был такой - Delphi. ООП с перегрузкой никак не связаны, перегрузка - это просто синтаксический сахар.
Самый известный ООП язык, где перегрузку запретили под мотивацией "ко-ко-ко индусы запутаются" - это Java. Еще был такой - Delphi. ООП с перегрузкой никак не связаны, перегрузка - это просто синтаксический сахар.
>>547976
И при чем тут перегрузка? http://ideone.com/BoS7bP
>Ну, в няшной и крестах такая адд будет возвращать char *
И при чем тут перегрузка? http://ideone.com/BoS7bP
Зато вот это http://ideone.com/mR7Y2K нормально откомпилируется и тут у тебя почему-то вопросов не возникнет. Хули, перегрузки же нет.
403 Кб, 1280x2270
>>548213
Есть, опрератор "+" - это часть языка, а функция add, - нет, соответственно ошибки проще искать в случае add, - нагрузка на механизмы памяти и внимания меньше.
Есть, опрератор "+" - это часть языка, а функция add, - нет, соответственно ошибки проще искать в случае add, - нагрузка на механизмы памяти и внимания меньше.
Бампецкий, заодно вопрос. Как известно одна из немногих причин, почему перегруженное костылями убожество С++ до сих пор на плаву - это совместимость со старым добрым Си. Так вот - можно ли подобное сделать для раста? Запилить статическую линковку с сишными .а/.о файлами, а то и вовсе extern C впилить - было бы заебца. Какому-нибудь старому проекту, типа ядра линупса, например, было бы проще мигрировать на нормальный язык (слышал, какие-то индусы пилили форк ядра на С++, но по причине убогости крестов не взлетело).
>>554463
Не понял вопроса.
https://doc.rust-lang.org/book/ffi.html
Вроде бы полностью совместим с C, но нужно делать обертку unsafe. С C++ пока проблемы из-за отсутствия наследования.
Не понял вопроса.
https://doc.rust-lang.org/book/ffi.html
Вроде бы полностью совместим с C, но нужно делать обертку unsafe. С C++ пока проблемы из-за отсутствия наследования.
Это динамическая линковка. А так вот, чтобы взять проект на голом Ц и дописывать его уже на расте - с этим сложности. Да и динамическая линковка больно нетривиальна, проще нужно. Те же .h файлы напрямую заюзать, например.
>>554463
Перегруженное костылями убожество С++ до сих пор на плаву из-за совместимости со старым добрым перегруженным костылями убожеством С++. Поэтому все, что ты можешь сделать, - это добавить еще костылей в С++.
Перегруженное костылями убожество С++ до сих пор на плаву из-за совместимости со старым добрым перегруженным костылями убожеством С++. Поэтому все, что ты можешь сделать, - это добавить еще костылей в С++.
>>554470
Дело не столько в наследовании, сколько в mangle, в конструкторах/деструкторах, шаблонах. Да какой к чёрту взаимодействие с крестами, если крестовые бинарики разных компиляторов часто не совместимы друг с другом. Единственный нормальный байндинг, когда либо написанный под что-то, был qt для питона, но им пришлось свой парсер быдлокрестов запилить, ага.
Дело не столько в наследовании, сколько в mangle, в конструкторах/деструкторах, шаблонах. Да какой к чёрту взаимодействие с крестами, если крестовые бинарики разных компиляторов часто не совместимы друг с другом. Единственный нормальный байндинг, когда либо написанный под что-то, был qt для питона, но им пришлось свой парсер быдлокрестов запилить, ага.
>>554484
Можно и статически линковать, читай внимательнее. Ну а про "заюзать .h файлы": есть bindgen, но он полезен скорее для разраба обёртки, чем для её пользователя, ибо unsafe.
Можно и статически линковать, читай внимательнее. Ну а про "заюзать .h файлы": есть bindgen, но он полезен скорее для разраба обёртки, чем для её пользователя, ибо unsafe.
>>554757
Как будто связывая хацкель с каким-нибудь питоном у тебя есть другие альтернативы.
Как будто связывая хацкель с каким-нибудь питоном у тебя есть другие альтернативы.
>>554778
Да я просто в ахуе немного. Позиционирование, лол, может еще про фокус-группы расскажешь? Какая разница, кто там что позиционирует. Совсем у крестохейтеров крыша едет уже.
Да я просто в ахуе немного. Позиционирование, лол, может еще про фокус-группы расскажешь? Какая разница, кто там что позиционирует. Совсем у крестохейтеров крыша едет уже.
>>554586
Те проекты, которые используют кресты, их уже не вернуть, это да. Но есть ещё много всякого legacy C говна, перед которым часто встаёт вопрос переписать/дописать на чем-нибудь более стильном/молодёжном. Начать с дописывания всегда проще, а для этого нужна лучшая совместимость с Ц. Пусть и unsafe поначалу - сишникам не привыкать. Зато новые растомодули будут и safe, и собой хороши.
Раст - не го, на нём стартапы сильно не попишешь. Но нужно как-то вгрызаться в рынок.
Те проекты, которые используют кресты, их уже не вернуть, это да. Но есть ещё много всякого legacy C говна, перед которым часто встаёт вопрос переписать/дописать на чем-нибудь более стильном/молодёжном. Начать с дописывания всегда проще, а для этого нужна лучшая совместимость с Ц. Пусть и unsafe поначалу - сишникам не привыкать. Зато новые растомодули будут и safe, и собой хороши.
Раст - не го, на нём стартапы сильно не попишешь. Но нужно как-то вгрызаться в рынок.
>>554786
А куда деваться? Тот же го сейчас юзают там, где ещё года 3 назад выбрали бы петон или джаву - если это не позиционирование, то что? Новые сферы применения вместе с новыми языками как-то сильно не нарождаются, всегда приходится кому-то из-под кого-то стул выпинывать.
А куда деваться? Тот же го сейчас юзают там, где ещё года 3 назад выбрали бы петон или джаву - если это не позиционирование, то что? Новые сферы применения вместе с новыми языками как-то сильно не нарождаются, всегда приходится кому-то из-под кого-то стул выпинывать.
>>554814
Это называется FFI и оно есть в любом языке. Иначе как ты будешь с системой общаться? Биндинги с libc (да хоть kernel32.dll) и вперед.
Это называется FFI и оно есть в любом языке. Иначе как ты будешь с системой общаться? Биндинги с libc (да хоть kernel32.dll) и вперед.
>>554817
Надо, чтобы в будущем
http://habrahabr.ru/post/174017/
Мы могли бы не удивиться новости вроде GCC 5.8 6.8 завершил миграцию на Rust
Надо, чтобы в будущем
http://habrahabr.ru/post/174017/
Мы могли бы не удивиться новости вроде GCC 5.8 6.8 завершил миграцию на Rust
>>554864
Ваше мнение очень важно для нас. Оставайтесь на связи.
Ваше мнение очень важно для нас. Оставайтесь на связи.
Представлена операционная система Redox, написанная на языке Rust
Операционная система использует концепцию экзоядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами. Вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях, но пользователь при этом имеет наивысшие привилегии в системе.
http://www.opennet.ru/opennews/art.shtml?num=43105
Пацаны вообще ребята. Не взлетит, но опыт полезный, да и на подсмотреть сгодится.
Операционная система использует концепцию экзоядра, при котором на уровне ядра обеспечивается только взаимодействие между процессами и управление ресурсами. Вся остальная функциональность вынесена в библиотеки, которые могут использоваться как ядром, так и пользовательскими приложениями. В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях, но пользователь при этом имеет наивысшие привилегии в системе.
http://www.opennet.ru/opennews/art.shtml?num=43105
Пацаны вообще ребята. Не взлетит, но опыт полезный, да и на подсмотреть сгодится.
>>555124
Microsoft Singularity
Phantom OS
> В Redox применён необычный подход к безопасности - все драйверы и программы выполняются только в изолированных sandbox-окружениях
Microsoft Singularity
Phantom OS
>>555160
Не об этом. И та ось не нужна, и эта не нужна. Просто само то, что языку без году неделя, а на нём уже джаст фо фан пишут операционки с гуем, о чём-то да говорит.
Не об этом. И та ось не нужна, и эта не нужна. Просто само то, что языку без году неделя, а на нём уже джаст фо фан пишут операционки с гуем, о чём-то да говорит.
>>555166
Говорит что ты, маня, ура-патриот.
Вот на расте уже операционка есть. Похуй что ничего нового в ней, и это говно без целей, аля "мине панравелся раст и йа напейсал операцеонку пачитав таненбаума". Ещё похуй что такое дерьмо можно хоть на го или питоне написать, заебись теперь заживём. СЛАВА РАСТУ!
Говорит что ты, маня, ура-патриот.
Вот на расте уже операционка есть. Похуй что ничего нового в ней, и это говно без целей, аля "мине панравелся раст и йа напейсал операцеонку пачитав таненбаума". Ещё похуй что такое дерьмо можно хоть на го или питоне написать, заебись теперь заживём. СЛАВА РАСТУ!
>>555213
Хейтеры такие хейтеры. Ну, покажи-ка нам операционку на го. Собственно, раст и задумывался как системный язык с многопоточностью без сегфолтов. Сам факт её создания, это пруф его пригодности для лоу-лвл программинга, пейсательства драйверов и такого прочего. Собственно, шкала языков для написания операционок, от пиздецкого непортабельного лоу лвла через портабельность с сегфолтами и утечками памяти к норм языку выглядит так:
голый асм -> Си -> раст
Хейтеры такие хейтеры. Ну, покажи-ка нам операционку на го. Собственно, раст и задумывался как системный язык с многопоточностью без сегфолтов. Сам факт её создания, это пруф его пригодности для лоу-лвл программинга, пейсательства драйверов и такого прочего. Собственно, шкала языков для написания операционок, от пиздецкого непортабельного лоу лвла через портабельность с сегфолтами и утечками памяти к норм языку выглядит так:
голый асм -> Си -> раст
63 Кб, 604x453
>>555222
Мань, ты хоть иходники этого вашего редокса читал?
Там unsafe на unsafe и unsafe погоняет, местами встречаются комментарии типа
TODO: remove memory leak...
Что это значит ты понимаешь?
Повторяю для трудноообучаемых:
Rust - это не язык системного программирования.
Rust - это прикладной язык программирования,
это безопасный загон для быдлокодеров, в котором можно писать программки без сегфолтов, которые может быть будут работать быстрее, чем програмки на сисярпе и жаве.
Я поддерживаю идею загона для кодо-мартышек, но низкоуровнемый системный код лучше писать на C, просто потому, что при этом будет затрачено меньше человекочасов на разработку и отладнку.
Мань, ты хоть иходники этого вашего редокса читал?
Там unsafe на unsafe и unsafe погоняет, местами встречаются комментарии типа
TODO: remove memory leak...
Что это значит ты понимаешь?
Повторяю для трудноообучаемых:
Rust - это не язык системного программирования.
Rust - это прикладной язык программирования,
это безопасный загон для быдлокодеров, в котором можно писать программки без сегфолтов, которые может быть будут работать быстрее, чем програмки на сисярпе и жаве.
Я поддерживаю идею загона для кодо-мартышек, но низкоуровнемый системный код лучше писать на C, просто потому, что при этом будет затрачено меньше человекочасов на разработку и отладнку.
103 Кб, 599x527
>>555222
https://github.com/redox-os/redox/blob/master/src/common/src/context.rs
Сотри строку 69, лалка.
https://github.com/redox-os/redox/blob/master/src/common/src/context.rs
Сотри строку 69, лалка.
>>555235
Ты бредящий луддит.
>просто потому, что при этом будет затрачено меньше человекочасов на разработку и отладнку.
Ты бредящий луддит.
3 Кб, 605x85
Посоны, помогите, пожалуйста. Читаю rust book про trait-objects и там есть пикрелейтед. До этого в каком-то разделе вскользь упонминалось что делает "*" но теперь найти не могу.
18 Кб, 512x512
Блеать, какой же это системный язык/убийца цэ++, если cross-compilation для arm до сих пор без танцев не работает. Думал заюзать для эмбедщины, но такие вот дела
>>555528
Это же llvm-язык, хули там может не работать?
Это же llvm-язык, хули там может не работать?
>>555235
>>555236
$ 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
>>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
51 Кб, 600x374
>>555623
278+596=874
875/3889*100%=22,5%
То есть до 22,5% функций зашкварено...
Прикольная арифметика, чо!
278+596=874
875/3889*100%=22,5%
То есть до 22,5% функций зашкварено...
Прикольная арифметика, чо!
>>555719
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.
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.
>>555667
Спасибо, что-то я совсем затупил.
От себя добавлю найденный вчерашний коммит в trpl https://github.com/DanielKeep/rust/blob/702b6e552cc4fd5e20dff345e82327dc5a8eb613/src/doc/trpl/syntax-index.md может кому пригодится.
Спасибо, что-то я совсем затупил.
От себя добавлю найденный вчерашний коммит в trpl https://github.com/DanielKeep/rust/blob/702b6e552cc4fd5e20dff345e82327dc5a8eb613/src/doc/trpl/syntax-index.md может кому пригодится.
>>523816 (OP)
бамп
бамп
Поведуйте, что за зелёные потоки, которые так хотели реализовать, но в итоге отказались?
>>523816 (OP)
Ты сука, не говори, что он самый лучший, если это не так. Ты другие языки тестил? Вот и заткнись сука
Ты сука, не говори, что он самый лучший, если это не так. Ты другие языки тестил? Вот и заткнись сука
>>557187
У каждого ядра процессора есть некоторый контекст - содержимое регистров, счетчик инструкций, и т.д. Если нужно на одном ядре выполнять несколько задач, ОС не запаривается, и хранит контекст для каждого потока, и при переключении потоков сохраняет/загружает в регистры нужные значения для каждого потока. Для х86 с его неебическим набором регистров такое переключение занимает ощутимое время, которое впрочем можно значительно сократить, если сохранять только изменившиеся регистры. Шедуллер ОС этого сделать в принципе не может, зато на уровне компилятора-рантайма языка - это вполне выполнимая задача. Естественно, такие потоки будут не совместимы с остальным окружением, зато цена на переключение потока будет минимальна, и количество исполняемых потоков можно увеличивать на порядки, не думая о быстродействии.
У каждого ядра процессора есть некоторый контекст - содержимое регистров, счетчик инструкций, и т.д. Если нужно на одном ядре выполнять несколько задач, ОС не запаривается, и хранит контекст для каждого потока, и при переключении потоков сохраняет/загружает в регистры нужные значения для каждого потока. Для х86 с его неебическим набором регистров такое переключение занимает ощутимое время, которое впрочем можно значительно сократить, если сохранять только изменившиеся регистры. Шедуллер ОС этого сделать в принципе не может, зато на уровне компилятора-рантайма языка - это вполне выполнимая задача. Естественно, такие потоки будут не совместимы с остальным окружением, зато цена на переключение потока будет минимальна, и количество исполняемых потоков можно увеличивать на порядки, не думая о быстродействии.
>>557193
Слышал от Фицпатрика, что в Go есть go-рутины, и их можно делать очень много. Получается, они также основаны на частичном сохранении контекста?
Слышал от Фицпатрика, что в Go есть go-рутины, и их можно делать очень много. Получается, они также основаны на частичном сохранении контекста?
>>557201
Да, принцип везде одинаковый.
Да, принцип везде одинаковый.
>>555727
Это не делает такую ось более безопасной, ибо ошибки в реализации алгоритмов один хрен не исключены, алсо 22% говнокода достаточно, чтобы скатаить безопасность в говно.
То есть применение rust в системном программировании не снимает с программиста обязанность формального доказательтва верности алгоритмов ядра и не гарантирует отсутствие ошибок, в том числе опасных.
Плюс постоянное надрачивание на ООП, и шаблонное питушение везде снижают эффективность программ.
Плюс вырвиглазный синтаксис.
Все это делает rust не нужным с системном программировании, ибо есть более годные инструменты.
Более правильный подход ниже:
Googl pragmatic bare metal rust
Это не делает такую ось более безопасной, ибо ошибки в реализации алгоритмов один хрен не исключены, алсо 22% говнокода достаточно, чтобы скатаить безопасность в говно.
То есть применение rust в системном программировании не снимает с программиста обязанность формального доказательтва верности алгоритмов ядра и не гарантирует отсутствие ошибок, в том числе опасных.
Плюс постоянное надрачивание на ООП, и шаблонное питушение везде снижают эффективность программ.
Плюс вырвиглазный синтаксис.
Все это делает rust не нужным с системном программировании, ибо есть более годные инструменты.
Более правильный подход ниже:
Googl pragmatic bare metal rust
>>557201
Могут быть разные реализации:
1. Процессы/потоки - сохранение всего контекста планировщиком ОС, у каждой задачи свой стек, медленно, жрет довольно много памяти, надо замарачиваться с синхронизацией, зато универсально, годится для Hard RT, иногда работает быстрее других реализаций;
2. Автоматы - пишем многозадачность руками, стек один, все происходит синхронно, в случае фиксированного числа задач годится для Hard RT.
3. Сопрограммы/протопотоки - фактически автоматы, но невооруженным глазом их не видно, пишем задачи в имепративном стиле, стек один, все по большей части синхронно, но иногда таки приходится заморачиваться с синхронизацей, в случае фиксированного числа задач годится для Hard RT.
Могут быть разные реализации:
1. Процессы/потоки - сохранение всего контекста планировщиком ОС, у каждой задачи свой стек, медленно, жрет довольно много памяти, надо замарачиваться с синхронизацией, зато универсально, годится для Hard RT, иногда работает быстрее других реализаций;
2. Автоматы - пишем многозадачность руками, стек один, все происходит синхронно, в случае фиксированного числа задач годится для Hard RT.
3. Сопрограммы/протопотоки - фактически автоматы, но невооруженным глазом их не видно, пишем задачи в имепративном стиле, стек один, все по большей части синхронно, но иногда таки приходится заморачиваться с синхронизацей, в случае фиксированного числа задач годится для Hard RT.
90 Кб, 640x492
>>555727
Бич плиз!
Зойчем использовать rust там, где без unsafe - никак?
И кстати, мартыханы в любом месте могут запилить unsafe блок или функцию, и, соответственно, заниматься говнокодерством на этом вашем "безопасном" rust.
Так что я вообще не понимаю, зачем там сделали unsafe, если он сводит на нет всю эту вашу #memorysafety #nogc...
>И это операционка, где без unsafe никак.
Бич плиз!
Зойчем использовать rust там, где без unsafe - никак?
И кстати, мартыханы в любом месте могут запилить unsafe блок или функцию, и, соответственно, заниматься говнокодерством на этом вашем "безопасном" rust.
Так что я вообще не понимаю, зачем там сделали unsafe, если он сводит на нет всю эту вашу #memorysafety #nogc...
>>557541
Добавление/изменение блоков unsafe можно детектить автоматически при ревью. И, соответственно, приложить большее вниманию к подобному говнокоду.
А разгадка проста: небезопасный код следует всегда оборачивать безопасным API. Естественно, «ну я прост немношк опасного кода где попало» сводит безопасность раста на нет.
> И кстати, мартыханы в любом месте могут запилить unsafe блок или функцию, и, соответственно, заниматься говнокодерством на этом вашем "безопасном" rust.
Добавление/изменение блоков unsafe можно детектить автоматически при ревью. И, соответственно, приложить большее вниманию к подобному говнокоду.
> Так что я вообще не понимаю, зачем там сделали unsafe, если он сводит на нет всю эту вашу #memorysafety #nogc...
А разгадка проста: небезопасный код следует всегда оборачивать безопасным API. Естественно, «ну я прост немношк опасного кода где попало» сводит безопасность раста на нет.
>>557567
И че?
Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
Хочу безопасный код - пишу с использованием библиотеки, не хочу - пишу говнокод как раньше...
Где преимущество раста, мань?
>Добавление/изменение блоков unsafe можно детектить автоматически при ревью. И, соответственно, приложить большее вниманию к подобному говнокоду.
И че?
>А разгадка проста: небезопасный код следует всегда оборачивать безопасным API. Естественно, «ну я прост немношк опасного кода где попало» сводит безопасность раста на нет.
Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
Хочу безопасный код - пишу с использованием библиотеки, не хочу - пишу говнокод как раньше...
Где преимущество раста, мань?
>>557572
да ничего, собственно
пиши, хуй с тобой. Вот только кресты, это такая аморфная раздутая поебень, что библиотек этих может быть тысячи. Можешь использовать 993-ю либу, а можешь не использовать. Индус, который писал этот код до тебя, мог использовать 1231-ю либу, а мог не использовать. А безопасная реализация в расте - одна и включена по-дефолту.
Ещё на кресты попизжу. Всем они хороши - хошь, пиши, как на голом Цэ, хошь, функциональщиной балуйся, можно даже инкапсулировать. Дохуя возможностей - каждый выбирает, что ему по душе. В итоге имеем кучу неподдерживаемого говнокода, из-за того, что кучка долбоёбов пытается сделать швейцарский на базе скальпеля.
> Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
да ничего, собственно
> Хочу безопасный код - пишу с использованием библиотеки, не хочу - пишу говнокод как раньше...
пиши, хуй с тобой. Вот только кресты, это такая аморфная раздутая поебень, что библиотек этих может быть тысячи. Можешь использовать 993-ю либу, а можешь не использовать. Индус, который писал этот код до тебя, мог использовать 1231-ю либу, а мог не использовать. А безопасная реализация в расте - одна и включена по-дефолту.
Ещё на кресты попизжу. Всем они хороши - хошь, пиши, как на голом Цэ, хошь, функциональщиной балуйся, можно даже инкапсулировать. Дохуя возможностей - каждый выбирает, что ему по душе. В итоге имеем кучу неподдерживаемого говнокода, из-за того, что кучка долбоёбов пытается сделать швейцарский на базе скальпеля.
>>557572
Объем работ помноженный на ебанутость и эзотеричность языка шаблонов плюс необходимость поддержки со стороны хотя бы стандартной библиотеки и минус целесообразность (кто ж захочет пердолиться с кривым набором костылей?)
>Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
Объем работ помноженный на ебанутость и эзотеричность языка шаблонов плюс необходимость поддержки со стороны хотя бы стандартной библиотеки и минус целесообразность (кто ж захочет пердолиться с кривым набором костылей?)
>>558096
Хотя плюсоебам не привыкать, у них весь язык такой.
>кто ж захочет пердолиться с кривым набором костылей?
Хотя плюсоебам не привыкать, у них весь язык такой.
184 Кб, 745x789
>>558098
В любом случае, если раст даже хотя бы на минимуме выстрелит, его ждет та же судьба. Для тех же людей разрабатывали.
В любом случае, если раст даже хотя бы на минимуме выстрелит, его ждет та же судьба. Для тех же людей разрабатывали.
>>558141
Так раст писали матерые крестобляди. Ты обрати внимание, что на него бугуртят сишники и школьники.
Так раст писали матерые крестобляди. Ты обрати внимание, что на него бугуртят сишники и школьники.
1106 Кб, 1920x1080
>>558141
Не спорю. Потому что проектировалось уже в наши дни, с опытом. Но это его не защитит от превращения со временем в C++ в плохом смысле.
Не спорю. Потому что проектировалось уже в наши дни, с опытом. Но это его не защитит от превращения со временем в C++ в плохом смысле.
>>557572
То, что за пределами этой библиотеки безопасность вообще ничем не гарантируется?
> Мань, а что мешает сделать библиотеку с шаблонами для безопасного обращения с данными на тех же крестах !
То, что за пределами этой библиотеки безопасность вообще ничем не гарантируется?
>>558158
Ну хуй знает. Думаю, до такой же степени запущенности дойти не должно, потому что язык с самых ранних альф обкатывался на практике.
Ну хуй знает. Думаю, до такой же степени запущенности дойти не должно, потому что язык с самых ранних альф обкатывался на практике.
>>558076
О, адекват в треде!
>>558096
Ух ты, не знал, что написать класс-шаблон со встроенной блокировкой чтения/записи, класс-шаблон массива с контролем границ и еще несколько вспомогательных шаблонов это такой огромный объем работ, лол.
>>558178
мань, то, что за пределами растаможка тоже, да и в пределах...
О, адекват в треде!
>>558096
Ух ты, не знал, что написать класс-шаблон со встроенной блокировкой чтения/записи, класс-шаблон массива с контролем границ и еще несколько вспомогательных шаблонов это такой огромный объем работ, лол.
>>558178
мань, то, что за пределами растаможка тоже, да и в пределах...
>>558194
Ты в рантайме блокировать чтение/запись собрался что ли? Совсем ебанутый? Или просто раста в глаза не видел?
>со встроенной блокировкой чтения/записи
Ты в рантайме блокировать чтение/запись собрался что ли? Совсем ебанутый? Или просто раста в глаза не видел?
31 Кб, 382x203
84 Кб, 1024x576
19 Кб, 224x223
555 Кб, 1000x607
>>558181
Ну фиг знает, ОС 20 лет обкатывали на практике, до такой степени запущенности дойти не должно. :3
Ну фиг знает, ОС 20 лет обкатывали на практике, до такой степени запущенности дойти не должно. :3
>>558200
Обкатывали не разработчики, да и проект в разы больше => более медленная обратная связь.
Обкатывали не разработчики, да и проект в разы больше => более медленная обратная связь.
>>558194
Ок, объясню попроще: да, ты можешь написать безопасные абстракции в С++. Но при этом ничто не гарантирует, что код, использующий эти абстракции, не является кривым небезопасным говном. Раст же гарантирует, что использующий безопасные примитивы код безопасен.
Совсем кратко: в расте опасный код инкапсулирован.
> мань, то, что за пределами растаможка тоже, да и в пределах...
Ок, объясню попроще: да, ты можешь написать безопасные абстракции в С++. Но при этом ничто не гарантирует, что код, использующий эти абстракции, не является кривым небезопасным говном. Раст же гарантирует, что использующий безопасные примитивы код безопасен.
Совсем кратко: в расте опасный код инкапсулирован.
106 Кб, 700x452
>>558210
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)
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)
>>558263
Удивил-удивил. Только какое это отношение имеет к расту?
Повторю вопрос: совсем ебанутый или просто раста в глаза не видел?
>Прикинь!
Удивил-удивил. Только какое это отношение имеет к расту?
Повторю вопрос: совсем ебанутый или просто раста в глаза не видел?
>>558263
Само собой, полную гарантию может дать разве что код в зависимых типах, полностью покрытый доказательствами. Но практической стороны это не меняет: в С++ нет ничего, что могло бы предотвратить написание некорректно использующего память кода, когда же компилятор раста способен отсеять множество разновидностей некорректного кода.
> Даже если рантайм написан на раст, это не делает рантайм безопасным, и тем более не делает корректными алгоритмы работы такого рантайма.
Само собой, полную гарантию может дать разве что код в зависимых типах, полностью покрытый доказательствами. Но практической стороны это не меняет: в С++ нет ничего, что могло бы предотвратить написание некорректно использующего память кода, когда же компилятор раста способен отсеять множество разновидностей некорректного кода.
>>558379
Зачем пилить новый язык с вырвиглазным синтаксисом, если можно сделать либу для уже существующего, которым пользуются куча людей по всему миру, под который есть куча тулзов под совершенно разные архитектуры и ОС?
Создатели руста совсем ебанутые, или как?
Зачем пилить новый язык с вырвиглазным синтаксисом, если можно сделать либу для уже существующего, которым пользуются куча людей по всему миру, под который есть куча тулзов под совершенно разные архитектуры и ОС?
Создатели руста совсем ебанутые, или как?
>>558411
Ясно @ Понятно
Ясно @ Понятно
>>558483
https://doc.rust-lang.org/stable/book/concurrency.html
мань, в расте именно мьютексы и используются, и что характерно, с проверками в рантайме, прикинь!
А разгадка проста: невозможно предсказать, когда какой поток попытается читать/писать переменную.
Ты документацию по своему любимому языку читал вообще?
https://doc.rust-lang.org/stable/book/concurrency.html
мань, в расте именно мьютексы и используются, и что характерно, с проверками в рантайме, прикинь!
А разгадка проста: невозможно предсказать, когда какой поток попытается читать/писать переменную.
Ты документацию по своему любимому языку читал вообще?
>>558495
Если б ты почитал что-нибудь ещё в дополнение к той странице, то выяснил бы, что на этом обеспечение безопасности не заканчивается и что немалую работу выполняет компилятор.
Если б ты почитал что-нибудь ещё в дополнение к той странице, то выяснил бы, что на этом обеспечение безопасности не заканчивается и что немалую работу выполняет компилятор.
>>558502
Ну реализуй. А то раскукарекался тут: можно да можно. Иди и сделай, потом покажешь.
Ну реализуй. А то раскукарекался тут: можно да можно. Иди и сделай, потом покажешь.
Октябрьский индекс TIOBE обновил положение Rust в «пищевой цепочке». Язык занял почётное 49-е место войдя в 50-ку популярных языков потеснив Closure. Для сравнения в 50-ку не попадают весьма интересные: Common Lisp, Julia, Go.
http://habrahabr.ru/post/268849/
http://habrahabr.ru/post/268849/
>>558988
И опять же GC. Мог бы по крайней мере ATS предложить.
И опять же GC. Мог бы по крайней мере ATS предложить.
Есть один std::collections::LinkedList у него есть fn front(&self) -> Option<&T> который возвращает ссылку на первый элемент, а как мне получить копию первого элемента?
>>559208
http://doc.rust-lang.org/std/clone/trait.Clone.html
> а как мне получить копию первого элемента
http://doc.rust-lang.org/std/clone/trait.Clone.html
>>559232
Спасибо. Я должен реализовать трейт copy для моего типа и вызывать list.front().unwrap().copy(), правильно?
Спасибо. Я должен реализовать трейт copy для моего типа и вызывать list.front().unwrap().copy(), правильно?
>>559244
*list.front().unwrap().clone()
*list.front().unwrap().clone()
>>559244
Не `Copy`, а `Clone`. И вызвать метод `.clone()`, соответственно.
`Copy` же используется для того, чтобы тип имел семантику копирования вместо семантики перемещения.
Да, и обрати внимание на `derive`: http://rustbyexample.com/trait/derive.html
> трейт copy
Не `Copy`, а `Clone`. И вызвать метод `.clone()`, соответственно.
`Copy` же используется для того, чтобы тип имел семантику копирования вместо семантики перемещения.
Да, и обрати внимание на `derive`: http://rustbyexample.com/trait/derive.html
>>523816 (OP)
О, опять пидоRustы повылазили. Сажи даунским выблядкам.
О, опять пидоRustы повылазили. Сажи даунским выблядкам.
Писал я себе программку игоря и использовал `struct S { a: u8, b: u8, c: u8 }` как ключ для HashMap, и все было замечательно пока я не изменил структуру на `struct S { a: u8, b: u8, c: Option<u8> }` и производительность упала почти на 20%, так как HasMap используется довольно активно. Так вот, поясните мне по хардкору какой из вариантов правильный:
а) Использовать структуру как ключ - плохая идея.
б) Использовать Option в ключе - плохая идея.
в) А и б.
г) Просто нужно использовать другой хешер.
д) Оскорбить меня.
Пример с кодом http://pastebin.com/1CY7rgSs хоть здесь разница не так критична, но все равно замета.
а) Использовать структуру как ключ - плохая идея.
б) Использовать Option в ключе - плохая идея.
в) А и б.
г) Просто нужно использовать другой хешер.
д) Оскорбить меня.
Пример с кодом http://pastebin.com/1CY7rgSs хоть здесь разница не так критична, но все равно замета.
>>523816 (OP)
Rust это такой прошлый год, думаю учить Плокс Плокс, за ним будущее, думаю Плокс Плокс будет актуален целых три месяца, потом надо будет перекатываться на Финксер, месяца на полтора его хватит, после чего надо будет все проекты переписать на Грувере, который протянет месяц до того как устареет.
Программирование эта крута, посоны.
Rust это такой прошлый год, думаю учить Плокс Плокс, за ним будущее, думаю Плокс Плокс будет актуален целых три месяца, потом надо будет перекатываться на Финксер, месяца на полтора его хватит, после чего надо будет все проекты переписать на Грувере, который протянет месяц до того как устареет.
Программирование эта крута, посоны.
>>561165
Да ты тут, походу, самый продвинутый. Я тебе дам нубский
адвайс:
Попробуй сравнить скорость с
`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. Ну или напиши свой однобайтовый тип с подобным поведением.
Да ты тут, походу, самый продвинутый. Я тебе дам нубский
адвайс:
Попробуй сравнить скорость с
`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. Ну или напиши свой однобайтовый тип с подобным поведением.
>>524372
Не получится, для реального межпотокового взаимодействия придется использовать Mutex<T>,
и делать захват/освобождение блокировки руками.
Не получится, для реального межпотокового взаимодействия придется использовать Mutex<T>,
и делать захват/освобождение блокировки руками.
>>525118
гонки возникают тогда, когда ты делаешь многопоточный доступ к данным, в этом случае рустерам приходится использовать мьютескы, так же, как и всем остальным.
В однопоточной программе все эти правила защищают только от одного - использования неинициализированных указателей/попыток доступа к освобожденной памяти.
гонки возникают тогда, когда ты делаешь многопоточный доступ к данным, в этом случае рустерам приходится использовать мьютескы, так же, как и всем остальным.
В однопоточной программе все эти правила защищают только от одного - использования неинициализированных указателей/попыток доступа к освобожденной памяти.
>>561228
https://kgv.gitbooks.io/rust_book_ru/content/src/references-and-borrowing.html
фишка в том, что без них в расте никак. В сях/плюсах нет никаких гарантий, что индус, писавший код, не раздал один и тот же указатель под честное слово 8 потокам. В этом плане раст должен понравиться ынтерпрайзу - часть работы строгих манагеров и код-ревьюшников берёт на себя конпелятор.
> рустерам приходится использовать мьютескы
https://kgv.gitbooks.io/rust_book_ru/content/src/references-and-borrowing.html
фишка в том, что без них в расте никак. В сях/плюсах нет никаких гарантий, что индус, писавший код, не раздал один и тот же указатель под честное слово 8 потокам. В этом плане раст должен понравиться ынтерпрайзу - часть работы строгих манагеров и код-ревьюшников берёт на себя конпелятор.
>>561257
А что тебе помешает в расте не объявлять мьютекс?
У тебя будет ровно одна ссылка с правом записи, правил не нарушены.
Вот только запись будет идти в одном потоке, а чтение в нескольких...
А что тебе помешает в расте не объявлять мьютекс?
У тебя будет ровно одна ссылка с правом записи, правил не нарушены.
Вот только запись будет идти в одном потоке, а чтение в нескольких...
>>561292
Компилятор. Да, он отслеживает не только заимствования.
См. типажи `Sync` и `Send`.
http://doc.rust-lang.org/std/marker/trait.Sync.html
http://doc.rust-lang.org/std/marker/trait.Send.html
> А что тебе помешает в расте не объявлять мьютекс?
Компилятор. Да, он отслеживает не только заимствования.
См. типажи `Sync` и `Send`.
http://doc.rust-lang.org/std/marker/trait.Sync.html
http://doc.rust-lang.org/std/marker/trait.Send.html
>>561210
Ты оказался прав, все дело в размере структуры используемой как ключ ну или в количестве значений для которых нужно найти хеш.
При сравнении `struct Without { field: u32, field2: u32 }` и struct With { field: Option<u32> } производительность одна и та же, `mem::size_of::<T>()` показывает что размер обеих структур 8 байт.
А по поводу решений что ты предложил, это понятно, просто хотелось чтобы все из коробки, да и заниматься таким рано - сами структуры могут измениться еще не раз.
Ты оказался прав, все дело в размере структуры используемой как ключ ну или в количестве значений для которых нужно найти хеш.
При сравнении `struct Without { field: u32, field2: u32 }` и struct With { field: Option<u32> } производительность одна и та же, `mem::size_of::<T>()` показывает что размер обеих структур 8 байт.
А по поводу решений что ты предложил, это понятно, просто хотелось чтобы все из коробки, да и заниматься таким рано - сами структуры могут измениться еще не раз.
А вот у меня тоже вопрос связанный с хешмап. При попытке взять из него значение он возвращает option и логично было бы сделать что-то наподобие
[code]
let result = match hashmap.get(&key) {
Some(result) => result,
None => {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
},
};
[/code]
Тоесть если значение с таким ключом не найдено, то добавляем его и возвращаем. Что естественно не работает так как map уже захвачен для чтения match. Может есть какое-то общепринятое решение для таких ситуаций?
[code]
let result = match hashmap.get(&key) {
Some(result) => result,
None => {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
},
};
[/code]
Тоесть если значение с таким ключом не найдено, то добавляем его и возвращаем. Что естественно не работает так как map уже захвачен для чтения match. Может есть какое-то общепринятое решение для таких ситуаций?
>>561818
if let Some(r) = hashmap.get(&key) {
r
} else {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
}
Не работает?
Вообще, обещали починить такие случаи, если не ошибаюсь.
if let Some(r) = hashmap.get(&key) {
r
} else {
hashmap.insert(key, value);
hashmap.get(&key).unwrap()
}
Не работает?
Вообще, обещали починить такие случаи, если не ошибаюсь.
>>561872
Не работает, говорит что не может захватить, так как предыдущий захват произведен здесь
Не работает, говорит что не может захватить, так как предыдущий захват произведен здесь
>if let Some(r) = hashmap.get(&key) {
>>561872
Вот так работает https://play.rust-lang.org/?gist=36dd730d40e401cfad39&version=stable
Без `map.contains_key()` не получилось обойтись.
Вот так работает https://play.rust-lang.org/?gist=36dd730d40e401cfad39&version=stable
Без `map.contains_key()` не получилось обойтись.
32 Кб, 604x209
>>561334
Забавно, а как там учитывается, что не на всех архитектурах можно за один такт прочитать/запсиать указатель или еще какой-нибудь флоат?
Будете блокировки к каждому указателю присобачивать?
Забавно, а как там учитывается, что не на всех архитектурах можно за один такт прочитать/запсиать указатель или еще какой-нибудь флоат?
Будете блокировки к каждому указателю присобачивать?
>>561984
Указатель уж всяко на любой не совсем поехавшей - адрес же должен в регистр влазить, а регистр - атомарно записываться. А на совсем поехавших или раста нет, или тредов.
Указатель уж всяко на любой не совсем поехавшей - адрес же должен в регистр влазить, а регистр - атомарно записываться. А на совсем поехавших или раста нет, или тредов.
>>563425
/Б/ратиш, раз уж языг претендует на нишу низкоуровневого системного,
то нужно озаботиться подобными вещами на этапе проектирования языка/конпелятора.
На таких архитектурах крутятся ОС, в т.ч. ОСРВ, а раста там нет...
Собственно его почти везде нет, только хуй86 и некоторые армы...
/Б/ратиш, раз уж языг претендует на нишу низкоуровневого системного,
то нужно озаботиться подобными вещами на этапе проектирования языка/конпелятора.
На таких архитектурах крутятся ОС, в т.ч. ОСРВ, а раста там нет...
Собственно его почти везде нет, только хуй86 и некоторые армы...
>>563718
Ну довольно сложно вспомнить архитектуру, в которой есть и потоки, и неатомарная запись word (хотя бы aligned). Главное - там и для C придётся синхронизацию пердолить, так что раст тут никак не проигрывает.
Ну довольно сложно вспомнить архитектуру, в которой есть и потоки, и неатомарная запись word (хотя бы aligned). Главное - там и для C придётся синхронизацию пердолить, так что раст тут никак не проигрывает.
>>561984
Зачем к каждому? Только к тем, что указывают на изменяемые данные.
Для них синхронизацию везде запиливать придётся, не только в расте.
> Будете блокировки к каждому указателю присобачивать?
Зачем к каждому? Только к тем, что указывают на изменяемые данные.
Для них синхронизацию везде запиливать придётся, не только в расте.
>>563808
Ну так там указатели имеют тираж sync же,
То есть страстность придется обеспечивать однообразно для всех...
Ну так там указатели имеют тираж sync же,
То есть страстность придется обеспечивать однообразно для всех...
>>563812
Верно. Но менять указатель никто не позволяет (T: Send означает, что можно раздавать по тредам &T. Но ты не можешь создать &T, пока существует &mut T). Менять данные по указателю из нескольких тредов тоже нельзя: & &mut T пригоден только для чтения.
Так что все Sync-типы или с синхронизацией, или строго read-only.
> Ну так там указатели имеют тираж sync же
Верно. Но менять указатель никто не позволяет (T: Send означает, что можно раздавать по тредам &T. Но ты не можешь создать &T, пока существует &mut T). Менять данные по указателю из нескольких тредов тоже нельзя: & &mut T пригоден только для чтения.
Так что все Sync-типы или с синхронизацией, или строго read-only.
>>563912
Тогда будет оверхед на снихронизацтю...
Нет, я конечно не против того, что абизянки не смогут накосячить при всем желании, но для меня дико так бездумно расходовать процессорные так ты...
Если уж приделывать синхронизацию, то к более крупным объектам.
Ну и примитивов синхронизации побольше бы.
Тогда будет оверхед на снихронизацтю...
Нет, я конечно не против того, что абизянки не смогут накосячить при всем желании, но для меня дико так бездумно расходовать процессорные так ты...
Если уж приделывать синхронизацию, то к более крупным объектам.
Ну и примитивов синхронизации побольше бы.
>>563923
Ничто не мешает приделать синхронизацию к более крупным объектам. Главное, чтобы она вообще была.
Ну а здесь уже берётся unsafe и запиливается требуемый примитив.
> Если уж приделывать синхронизацию, то к более крупным объектам.
Ничто не мешает приделать синхронизацию к более крупным объектам. Главное, чтобы она вообще была.
> Ну и примитивов синхронизации побольше бы.
Ну а здесь уже берётся unsafe и запиливается требуемый примитив.
Сразу говорю, что хочу не развести срач, а получить чёткий объективный ответ.
Почитал тут немного форумов в интернетах. В большинстве случаев при сравнении Rust и Go люди делают выбор в пользу Rust несмотря на то, что он сыроват. В связи с чем у меня возникли вопросы:
1) Зачем их вообще сравнивать? Емнип, Rust изначально создавался как язык для высоконагруженных серверов, а Go - ЯП общего назначения. Веб на нём писать конечно удобно, однако это не сужает весь спектр его возможного применения
2) Почему таки люди выбирают Rust? Чем плох Goкроме очевидного отсутствия шаблонов?
Почитал тут немного форумов в интернетах. В большинстве случаев при сравнении Rust и Go люди делают выбор в пользу Rust несмотря на то, что он сыроват. В связи с чем у меня возникли вопросы:
1) Зачем их вообще сравнивать? Емнип, Rust изначально создавался как язык для высоконагруженных серверов, а Go - ЯП общего назначения. Веб на нём писать конечно удобно, однако это не сужает весь спектр его возможного применения
2) Почему таки люди выбирают Rust? Чем плох Goкроме очевидного отсутствия шаблонов?
>>564939
1) Если проект может жить со сборищиком мусора, использовать язык без него - идиотизм.
2) Goвно можно использовать для примитивных предметных областей, на нем сложно строить абстракции или описывать сложные алгоритмы я не про числодробилки, которые все равно написаны на фортране и С, а про сложную бизнес-логику. Goвно - хороший инструмент с точки зрения менеджмента: любого дауна можно посадить писать код и он его напишет и результат будет даже читаемым. Собственно для этого он и придуман.
Выводы делай сам.
1) Если проект может жить со сборищиком мусора, использовать язык без него - идиотизм.
2) Goвно можно использовать для примитивных предметных областей, на нем сложно строить абстракции или описывать сложные алгоритмы я не про числодробилки, которые все равно написаны на фортране и С, а про сложную бизнес-логику. Goвно - хороший инструмент с точки зрения менеджмента: любого дауна можно посадить писать код и он его напишет и результат будет даже читаемым. Собственно для этого он и придуман.
Выводы делай сам.
>>564939
Их не то что бы сравнивают. Проблема в том, что они появились относительно недавно друг друга и оба созданы известными компаниями. В связи с чем у них имеется конкуренция за потенциальных пользователей, потому что им нужно преодолеть некий минимум чтобы реализовать свой потенциал и не провалиться.
Это ты специально реверс сделал?
Rust создавался как альтернатива C++.
Вот как раз-таки у Go основное применение – высоконагруженные серверы.
Rust ещё, как ты сам сказал, сыроват. В продакшене, помимо мозиллы, используется только где-то 5-ю фирмами и пока ещё не соответствует их требованиям.
Go выбирают там, где он имеет преимущества перед его конкурентами. См. выше.
Остальное описал >>564962
К слову, по поводу умственных способностей. Не мизогинист, но программистов-женщин на языках типа Go (процедурных с минимум синтаксического сахара) намного больше, чем на языках типа C++. Ну хачкель само разумеющееся.
> 1) Зачем их вообще сравнивать
Их не то что бы сравнивают. Проблема в том, что они появились относительно недавно друг друга и оба созданы известными компаниями. В связи с чем у них имеется конкуренция за потенциальных пользователей, потому что им нужно преодолеть некий минимум чтобы реализовать свой потенциал и не провалиться.
> Rust изначально создавался как язык для высоконагруженных серверов, а Go - ЯП общего назначения.
Это ты специально реверс сделал?
Rust создавался как альтернатива C++.
Вот как раз-таки у Go основное применение – высоконагруженные серверы.
> 2) Почему таки люди выбирают Rust? Чем плох Go
Rust ещё, как ты сам сказал, сыроват. В продакшене, помимо мозиллы, используется только где-то 5-ю фирмами и пока ещё не соответствует их требованиям.
Go выбирают там, где он имеет преимущества перед его конкурентами. См. выше.
Остальное описал >>564962
К слову, по поводу умственных способностей. Не мизогинист, но программистов-женщин на языках типа Go (процедурных с минимум синтаксического сахара) намного больше, чем на языках типа C++. Ну хачкель само разумеющееся.
56 Кб, 599x501
>>564964
Программистов на го вообще просто больше, аналогично можно сравнить веб-макак и крестовиков.
Программистов на го вообще просто больше, аналогично можно сравнить веб-макак и крестовиков.
>>530355
Хачу-хачу, особенно cargo install. С моим интернетом сложна что-то каждый раз скачывать и проверять. Есть конечно различные способы указать файл, но это как-то плохо работает из-за прослойки в виде меня.
Хачу-хачу, особенно cargo install. С моим интернетом сложна что-то каждый раз скачывать и проверять. Есть конечно различные способы указать файл, но это как-то плохо работает из-за прослойки в виде меня.
Ребят. Очень даунский вопрос.
Как просто создать новый файлик в проекте, и юзать структуры и пр. из него? В доках про контейнеры и модули написано только про вынос всей хуиты в отдельную библиотеку вообще, либо это я пиздоглазый.
Как просто создать новый файлик в проекте, и юзать структуры и пр. из него? В доках про контейнеры и модули написано только про вынос всей хуиты в отдельную библиотеку вообще, либо это я пиздоглазый.
38 Кб, 500x550
>>565064
Тут через неделю должны 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 и т.д.
Не забывай про приватность и публичность. Ты не можешь использовать в другом модуле методы, функцию, типаж или структуру если они не публичны.
Там есть ещё куча всяких нюансов, которые ты можешь дальше и сам определить.
Поправьте меня, если в чем-то не прав.
38 Кб, 500x550
>>565064
Тут через неделю должны 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 и т.д.
Не забывай про приватность и публичность. Ты не можешь использовать в другом модуле методы, функцию, типаж или структуру если они не публичны.
Там есть ещё куча всяких нюансов, которые ты можешь дальше и сам определить.
Поправьте меня, если в чем-то не прав.
>>565257
self::; – текущий модуль (в текущей папке).
В текущем файле конечно же. Хотя если это корневая папка, то текущей папке, да.
self::; – текущий модуль (в текущей папке).
В текущем файле конечно же. Хотя если это корневая папка, то текущей папке, да.
Я даун и не понимаю сути трейтов/impl/генериков там всяких. Как понять?
>>565433
Выучить для начала ооп язык полегче.
В 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
Выучить для начала ооп язык полегче.
В 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
>>565433
Вот тебе на примерах всё это:
http://rustbyexample.com/generics.html
http://rustbyexample.com/trait.html
Вот тебе на примерах всё это:
http://rustbyexample.com/generics.html
http://rustbyexample.com/trait.html
>>565446
>>565526
Генерики это оказалось просто некоторые штуки с типами. Я представлял себе это, как какая-то монструозная конструкция на каком-то C++/Java.
Impl тоже стал ясен. А вот с трейтом надо разобратся, зачем он такой.
Спасибо, аноны! От всей моей несуществующей души и маленького мозга спасибо!
>>565526
Генерики это оказалось просто некоторые штуки с типами. Я представлял себе это, как какая-то монструозная конструкция на каком-то C++/Java.
Impl тоже стал ясен. А вот с трейтом надо разобратся, зачем он такой.
Спасибо, аноны! От всей моей несуществующей души и маленького мозга спасибо!
Фикс
*разобраться
*разобраться
>>565064
https://github.com/nrc/rustfmt
Вот, кстати, на ночной cargo install уже есть. Т.е. в 1.5 версии вполне может появиться. Через 4 дня 1.4 выходит, посмотрим, переместится ли в бету.
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]
[code]
fn content<T>(arg: T) {
println!("{:?}", arg);
}
fn main() {
content("text");
}
[/code]
>>565700
Вывод на экран возможен не для любого типа. Надо указать, что принимаются только те типы, для которых реализован типаж `Debug`.
Вот так: https://play.rust-lang.org/?gist=ced7d2ebe90245dcd000&version=stable
Да, и загляни вот сюда: http://doc.rust-lang.org/std/fmt/index.html
Вывод на экран возможен не для любого типа. Надо указать, что принимаются только те типы, для которых реализован типаж `Debug`.
Вот так: https://play.rust-lang.org/?gist=ced7d2ebe90245dcd000&version=stable
Да, и загляни вот сюда: http://doc.rust-lang.org/std/fmt/index.html
1807 Кб, Webm
>>565700
[code]
fn content<T: std::fmt::Debug>(arg: T) {
println!("{:?}", arg);
}
[/code]
{:?} требует реализации трейта Debug выводимой структурой. Ты должен явно указать, что T является такой структурой, для которой реализован этот трейт. Есть два способа. Первый я выше описал, второй через where.
Debug предназначен для дебага. Если ты хочешь делать именно нормальный вывод, то нужно использовать трейт Display (std::fmt::Display). Им можно выводить вот так: println!("{}", arg);
[code]
fn content<T: std::fmt::Debug>(arg: T) {
println!("{:?}", arg);
}
[/code]
{:?} требует реализации трейта Debug выводимой структурой. Ты должен явно указать, что T является такой структурой, для которой реализован этот трейт. Есть два способа. Первый я выше описал, второй через where.
Debug предназначен для дебага. Если ты хочешь делать именно нормальный вывод, то нужно использовать трейт Display (std::fmt::Display). Им можно выводить вот так: println!("{}", arg);
А можете пояснить про reference, которая &? Не про владение, а про то как передаются данные через &, копированием значения, указателем или еще как. Нужно ли мне оборачивать в указатель сравнительно большие структуры данных для передачи?
>>565854
Это. Ссылка по сути и является контролируемым вариантом указателя.
Они уже так или иначе находятся за ним, так как лежат в куче, а не на стеке (если они действительно большие). Вообще, лучше просто сосредоточиться на владении.
> указателем
Это. Ссылка по сути и является контролируемым вариантом указателя.
> Нужно ли мне оборачивать в указатель сравнительно большие структуры данных для передачи?
Они уже так или иначе находятся за ним, так как лежат в куче, а не на стеке (если они действительно большие). Вообще, лучше просто сосредоточиться на владении.
Есть ли графические библиотеки под Rust? Можно сделать приложение под Android? Можно сделать приложение дающее root-доступ?
>>566190
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
https://github.com/tomaka/android-rs-glue
Вообще всё можно сделать при желании.
Можно блядь. Хоть на питоне сделать можно. Только нахуя?
>Есть ли графические библиотеки под 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-доступ?
Можно блядь. Хоть на питоне сделать можно. Только нахуя?
>>566190
Дополню про ведроид - это одна из целевых платформ для серво https://github.com/servo/servo/wiki/Building-for-Android
Так что на все грабли там уже наступлено, ступай-конпеляй, не ссысь.
Дополню про ведроид - это одна из целевых платформ для серво https://github.com/servo/servo/wiki/Building-for-Android
Так что на все грабли там уже наступлено, ступай-конпеляй, не ссысь.
>>566706
Если он задается такими вопросами, лучше не надо.
https://www.reddit.com/r/rust/comments/3pwa97/rust_and_mobile/
Если он задается такими вопросами, лучше не надо.
https://www.reddit.com/r/rust/comments/3pwa97/rust_and_mobile/
Решил скомпилить Rust. Что за хрень оно качает в конце, какой-то snapshot? Как узнать прямую ссылку и скачать самому?
Вышел Rust 1.4
http://habrahabr.ru/post/269809/
http://habrahabr.ru/post/269809/
>>568854
Ну ок, ждем декабрь.
--------------------------
Нужно сдвинуть все элементы вектора на 1. Какой самый эффективный с точки зрения памяти и времени способ в Расте, не прибегая к unsafe?
let mut v = vec![4, 5, 0, 0, 2, 3];
shift(v, 1);
Ну ок, ждем декабрь.
--------------------------
Нужно сдвинуть все элементы вектора на 1. Какой самый эффективный с точки зрения памяти и времени способ в Расте, не прибегая к unsafe?
let mut v = vec![4, 5, 0, 0, 2, 3];
shift(v, 1);
У меня медленный интернет, качать долго. На днях скачал себе 1.3, а тут уже и 1.4 Новый проект делать на 1.5 уже тогда?
>>569083
Там ничего сверхкруто не поменялось, 2.5 изменения и всё обратно совместимо, пиши спокойно на 1.3.
Там ничего сверхкруто не поменялось, 2.5 изменения и всё обратно совместимо, пиши спокойно на 1.3.
А что за история с unsafe graph про которую на 4chan'е каждый раз при упоминании Rust'а ссылаются?
Вот постоянно:
либо
, либо
Хотя это, скорее всего, просто семены.
Вот постоянно:
либо
> вот если бы не гомосеки / code of conduct
, либо
> pointer graph
Хотя это, скорее всего, просто семены.
>>523816 (OP)
Что-то меня у меня вызывает подозрение язык, презентация которого начинается с пиздабольства.
>#rust #nogc #memorysafety
Что-то меня у меня вызывает подозрение язык, презентация которого начинается с пиздабольства.
>>569881
Причем здесь джава. Просто авторы Раста с ходу пиздят, да ещё и свою аудиторию за дураков держат. Может ли такой язык быть хорошим?
Причем здесь джава. Просто авторы Раста с ходу пиздят, да ещё и свою аудиторию за дураков держат. Может ли такой язык быть хорошим?
https://users.rust-lang.org/t/manually-implementing-a-heap-to-overcome-safety-rules-considered-harmful/398
Ох ЛОЛ, макаки не успели начать кодить на расте и уже начинают беспредельничать!
Вот и цена всей вашей параше, питушки...
Ох ЛОЛ, макаки не успели начать кодить на расте и уже начинают беспредельничать!
Вот и цена всей вашей параше, питушки...
>>570336
Да ты уже и выводы успел сделать
Да ты уже и выводы успел сделать
>>570336
Да хуй бы с ней, с этой memory safety. Главное, что есть язык без GC и это не С++. Хотя бы не нужно учить, зачем нужен виртуальный деструктор.
Да хуй бы с ней, с этой memory safety. Главное, что есть язык без GC и это не С++. Хотя бы не нужно учить, зачем нужен виртуальный деструктор.
Поясните за лайфтаймы. Допустим, есть структура:
struct Foo<'a> {
x: &'a i32,
}
Ииии... Чо? Зачем нужна данная хуитка? Какая область применения? В чём отличие от автоматического вывода лайфтайма конпалятором?
struct Foo<'a> {
x: &'a i32,
}
Ииии... Чо? Зачем нужна данная хуитка? Какая область применения? В чём отличие от автоматического вывода лайфтайма конпалятором?
>>571379
бампну без саги
бампну без саги
>>571379
В том, что у тебя может быть `Foo<'a>`, а может быть `Foo<'a, 'b>`.
http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust
> В чём отличие от автоматического вывода лайфтайма конпалятором?
В том, что у тебя может быть `Foo<'a>`, а может быть `Foo<'a, 'b>`.
http://stackoverflow.com/questions/31609137/why-are-explicit-lifetimes-needed-in-rust
>>571368
Ну так там же предлагают сборщик мусора написать для той реализации кучи...
Так что с #nogc тоже фейл.
А еще та кокото питушок утверждает, что краши в программе делятся на “хорошие„ и ”плохие„ то есть юзеру типо не пофиг, от какого из них произошел отказ в обслуживании.
Такой-то манямирок, ЛОЛ.
Ну так там же предлагают сборщик мусора написать для той реализации кучи...
Так что с #nogc тоже фейл.
А еще та кокото питушок утверждает, что краши в программе делятся на “хорошие„ и ”плохие„ то есть юзеру типо не пофиг, от какого из них произошел отказ в обслуживании.
Такой-то манямирок, ЛОЛ.
>>571410
Если программа упала, я её запустил и продолжил работать - это хороший краш. Если после падения я потерял последние лесять часов раобты - это плохой краш. По-моему, очевидно.
Если программа упала, я её запустил и продолжил работать - это хороший краш. Если после падения я потерял последние лесять часов раобты - это плохой краш. По-моему, очевидно.
[code lang="rust"]
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);
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);
>>527162
Быдло, плиз.
>>Короче, блядь,
>>Все заебись
>>хуяк
>>Додумался
>>Делаю
>>и пиздец
>>Заебись, сука
>>Дайте гайд нормальный.
Быдло, плиз.
>>523816 (OP)
Что там с сервой, растаны?
Что там с сервой, растаны?
>>569890
А то
Но nogc и memorysafety как бы подразумевает стратическое управление памятью. Но это, в общем случае, неразрешимая задача, с родни проблемы остановки. И вот тут я был бы готов предположить, что у растодаунов какое-то решение есть, которое работает достаточно часто, не всегда, но когда-то, в большинстве случаев, что позволяет им заявлять о #nogc #memorysafety. Но никаких пейперов я на их сайте не нашел, только рекламное говно, из чего сделал справедливый вывод, что растодавуны сиречь квованы онвльные.
>Что именно они напиздели-то?
А то
> #nogc #memorysafety
Но nogc и memorysafety как бы подразумевает стратическое управление памятью. Но это, в общем случае, неразрешимая задача, с родни проблемы остановки. И вот тут я был бы готов предположить, что у растодаунов какое-то решение есть, которое работает достаточно часто, не всегда, но когда-то, в большинстве случаев, что позволяет им заявлять о #nogc #memorysafety. Но никаких пейперов я на их сайте не нашел, только рекламное говно, из чего сделал справедливый вывод, что растодавуны сиречь квованы онвльные.
>>571836
https://doc.rust-lang.org/book/academic-research.html
> Но никаких пейперов я на их сайте не нашел
https://doc.rust-lang.org/book/academic-research.html
>>571836
Каргокультисты от математики - самый жалкий тип программистишек. У них, типа, все по серьезному. Наука! Хотя на деле и математикам на них поебать, и среди программистов они за фриков.
Каргокультисты от математики - самый жалкий тип программистишек. У них, типа, все по серьезному. Наука! Хотя на деле и математикам на них поебать, и среди программистов они за фриков.
>>571840
Да мне поебать на твое мнение. Пошел нахуй.
>Каргокультисты от математики - самый жалкий тип программистишек
Да мне поебать на твое мнение. Пошел нахуй.
>>571846
Зато мне на твое не поебать. Оно очень меня веселит. Такой типичный персонаж программерских борд - неудачник, прикидывающийся ученым.
Зато мне на твое не поебать. Оно очень меня веселит. Такой типичный персонаж программерских борд - неудачник, прикидывающийся ученым.
>>571852
А вот и дегенерат, которому общество внушило, что надо ДОБИВАТЬСЯ, а если ты не добился, то надо СТРАДАТЬ. И жизненный цикл хомячка состоит из погони за очередными материальными средствами для компенсации чувства собственной ничтожности и сравнения себя с другими. Особенно рвет пукан у такого говна от самодовольных битардов, которым похуй на все.
>неудачник
А вот и дегенерат, которому общество внушило, что надо ДОБИВАТЬСЯ, а если ты не добился, то надо СТРАДАТЬ. И жизненный цикл хомячка состоит из погони за очередными материальными средствами для компенсации чувства собственной ничтожности и сравнения себя с другими. Особенно рвет пукан у такого говна от самодовольных битардов, которым похуй на все.
>>571863
В рашке наука - это преподавание в вузе, осиливание уже созданных теория или дрочение диффуров в НИИ под водовку и картофан. Сравни хотя бы треды на math stackoverflow с тем, что считается наукой в рашке.
>Неудачник - исключительно в научном плане.
В рашке наука - это преподавание в вузе, осиливание уже созданных теория или дрочение диффуров в НИИ под водовку и картофан. Сравни хотя бы треды на math stackoverflow с тем, что считается наукой в рашке.
В самом деле, типичнейший экземпляр.
pro tip: про рашку даже намёка не было
pro tip: про рашку даже намёка не было
>>571864
И какой у тебя рейтинг на math stackoverflow?
И какой у тебя рейтинг на math stackoverflow?
>>547967
Тут-то ты и обосрался.
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Operator_Overloading_(Delphi)
> Самый известный ООП язык, где перегрузку запретили под мотивацией "ко-ко-ко индусы запутаются" - это Java. Еще был такой - Delphi.
Тут-то ты и обосрался.
http://docwiki.embarcadero.com/RADStudio/Seattle/en/Operator_Overloading_(Delphi)
226 Кб, 1144x860
>>571968
Я не зря написал - был. Что сейчас происходит с delphi - мне как-то поебать. А вот в 2001 году евангелисты делфи делали особый упор на то, какая перегрузка операторов страшная штука. Вот тебе отрывок из книги тех времен. Ты в 2001 родился хоть?
Я не зря написал - был. Что сейчас происходит с delphi - мне как-то поебать. А вот в 2001 году евангелисты делфи делали особый упор на то, какая перегрузка операторов страшная штука. Вот тебе отрывок из книги тех времен. Ты в 2001 родился хоть?
Бля, нихуя не понял. https://users.rust-lang.org/t/manually-implementing-a-heap-to-overcome-safety-rules-considered-harmful/398
чувак хотел накостылить кучу прямо в safe и у него нихуя не вышло? Как я понимаю, пиздеть на это - это как пиздеть на хачкель за то, что в нём без монад файлик не прочитать.
чувак хотел накостылить кучу прямо в safe и у него нихуя не вышло? Как я понимаю, пиздеть на это - это как пиздеть на хачкель за то, что в нём без монад файлик не прочитать.
>>572104
Двачую, поясните.
Двачую, поясните.
>>571839
Ну и что мы там видим? Region Based Memory Management в Циклоне и МЛ (даже не в Расте), причем работает она там не оче (поэтому в МЛ остались на мусоросборнике, а циклон не взлетел). И тут растоклованы такие заявляют: "Мы решили проблему с памятью!" Ну охуеть вообще. Дайте им премию Станиславского про многопоточность не читал, потому что подозреваю, что растоклоунада "мы решили проблему многопоточности" там уровня каких-нибудь акторов, либо подобной хуиты для школьниц
Ну и что мы там видим? Region Based Memory Management в Циклоне и МЛ (даже не в Расте), причем работает она там не оче (поэтому в МЛ остались на мусоросборнике, а циклон не взлетел). И тут растоклованы такие заявляют: "Мы решили проблему с памятью!" Ну охуеть вообще. Дайте им премию Станиславского про многопоточность не читал, потому что подозреваю, что растоклоунада "мы решили проблему многопоточности" там уровня каких-нибудь акторов, либо подобной хуиты для школьниц
>>572120
А, так это ты тот воннаби-ученый. Хуй сосешь?
А, так это ты тот воннаби-ученый. Хуй сосешь?
>>572120
То, что видим. Раст — промышленный язык, а не исследовательский, т.е он не изобретает новые концепции, но оборачивает их в пригодную для использования форму.
И да, там не все статьи конкретно про циклон.
> Ну и что мы там видим?
То, что видим. Раст — промышленный язык, а не исследовательский, т.е он не изобретает новые концепции, но оборачивает их в пригодную для использования форму.
И да, там не все статьи конкретно про циклон.
>>572133
В случае раста она вполне рабочая (хотя да, не универсальна).
Про конкретные отличия между растом и циклоном я тебе не скажу, ищи сам.
> Как можно завернуть в пригодную для использования форму нерабочую концепцию?
В случае раста она вполне рабочая (хотя да, не универсальна).
Про конкретные отличия между растом и циклоном я тебе не скажу, ищи сам.
12 Кб, 801x227
>>572138
Ну так и надо четко обозначить случаи, когда она работает, а когда нет, а то какой-то хайп получается.
>В случае раста она вполне рабочая (хотя да, не универсальна).
Ну так и надо четко обозначить случаи, когда она работает, а когда нет, а то какой-то хайп получается.
>>572144
А то у тебя жопа подгорает. Нету и не будет никогда серебрянной пули, если ты пытаешься залезть рукой в анус - логично что он порвется и протечет.
А то у тебя жопа подгорает. Нету и не будет никогда серебрянной пули, если ты пытаешься залезть рукой в анус - логично что он порвется и протечет.
>>572149
Серебрянной пули нет, но важен сам подход людей, позиционирующих себя как специалистов. Если вместо профессионального подхода я вижу хайпохуету, у меня сразу возникает впечатление, что мне впаривают очередные "умные указатели" в новой обёртке.
Серебрянной пули нет, но важен сам подход людей, позиционирующих себя как специалистов. Если вместо профессионального подхода я вижу хайпохуету, у меня сразу возникает впечатление, что мне впаривают очередные "умные указатели" в новой обёртке.
>>572157
Тебе никто ничего не впаривает, неуловимый Джо. Это ты тематические треды батхертами заливаешь.
Rust - это и есть best practises умных указателей с контролем на уровне компилятора. Mark'n'sweep GC там возможен, но вряд ли кто-то будет пилить, потому что задач нет. Если тебе нужен GC - возьми вместо раста что-то еще.
Тебе никто ничего не впаривает, неуловимый Джо. Это ты тематические треды батхертами заливаешь.
Rust - это и есть best practises умных указателей с контролем на уровне компилятора. Mark'n'sweep GC там возможен, но вряд ли кто-то будет пилить, потому что задач нет. Если тебе нужен GC - возьми вместо раста что-то еще.
>>572165
Уже запилили: https://github.com/Manishearth/rust-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
>>572169
Я видел, но under construction грозится быть вечным. Потому что не нужно.
Языки без-GC - это отдельная порода языков, в которых за счет этой особенности сделана куча архитектурных решений. Например, замыкания - нельзя просто взять и эффективно захватить объект по ссылке, нужно придумывать кучу видов замыканий - с захватом по ссылке, значению, перемещению и т. д. и т. п. Неосиляторы при этом просто пиздят о том, что просто добавь GC и не еби мозг - но тогда весь этот и не нужен. И вот в язык, который сдизайнен, чтобы быть без GC, добавлять GC? Нахуя? Тот, кто берет язык без GC, ему (охуеть, да?), GC trade offs нахуй не нужны настолько, что он готов поебаться со сложной архитектурой, с указателями, замыканиями и т. п. Тот, кому нужен GC, зачем ему-то ебаться с дизайнерскими решениями, которые в GC-случае нужны? В общем, задач для GC в расте нетуть.
Его ж под браузер пилят, а в браузере есть javascript. Я встраивал V8 в один проект на заре появления ноды.жс, и там работа с GC - одна из ключевых заморочек. Но это не тот GC, который обычно имеется в виду.
Я видел, но under construction грозится быть вечным. Потому что не нужно.
Языки без-GC - это отдельная порода языков, в которых за счет этой особенности сделана куча архитектурных решений. Например, замыкания - нельзя просто взять и эффективно захватить объект по ссылке, нужно придумывать кучу видов замыканий - с захватом по ссылке, значению, перемещению и т. д. и т. п. Неосиляторы при этом просто пиздят о том, что просто добавь GC и не еби мозг - но тогда весь этот и не нужен. И вот в язык, который сдизайнен, чтобы быть без GC, добавлять GC? Нахуя? Тот, кто берет язык без GC, ему (охуеть, да?), GC trade offs нахуй не нужны настолько, что он готов поебаться со сложной архитектурой, с указателями, замыканиями и т. п. Тот, кому нужен GC, зачем ему-то ебаться с дизайнерскими решениями, которые в GC-случае нужны? В общем, задач для GC в расте нетуть.
>Но задачи у него очень специфические, вроде
Его ж под браузер пилят, а в браузере есть javascript. Я встраивал V8 в один проект на заре появления ноды.жс, и там работа с GC - одна из ключевых заморочек. Но это не тот GC, который обычно имеется в виду.
>>572182
А почему нет? Думаешь применения не найдут? Вот D наоброт проектировался как язык с GC, но сборщик мусора там его можно отлючить.
> И вот в язык, который сдизайнен, чтобы быть без GC, добавлять GC? Нахуя?
А почему нет? Думаешь применения не найдут? Вот D наоброт проектировался как язык с GC, но сборщик мусора там его можно отлючить.
>>572186
Вот D - очень хороший пример хуевого решения. Если в расте gc-указатель делается с помощью Gc<T> и виден на уровне системы типов, то в D - это просто вкл-выкл, причем выкл, расчитанный на GC, течь, включая стандартную библиотеку. А со включенным GC, D уже и luajit посасывать может. Потому что грамотно написанная динамика с JIT работает на уровне статического языка с GC. Ну и нахуй этот D нужен?
Таким же образом можно подключить сборщик мусора к С++ (как C++/CLI например), и писать код, который будет течь.
Вот D - очень хороший пример хуевого решения. Если в расте gc-указатель делается с помощью Gc<T> и виден на уровне системы типов, то в D - это просто вкл-выкл, причем выкл, расчитанный на GC, течь, включая стандартную библиотеку. А со включенным GC, D уже и luajit посасывать может. Потому что грамотно написанная динамика с JIT работает на уровне статического языка с GC. Ну и нахуй этот D нужен?
Таким же образом можно подключить сборщик мусора к С++ (как C++/CLI например), и писать код, который будет течь.
>>572194
Ой зря ты так, я достаточно много на D писал и по быстродействию он почти не отстает от языков без GC (конечно если использовать адекватный компилятор вроде LDC). Алсо сравнивать его с Lua бесмысленно, ибо шаблоны, трейты, инлайн ассемблер и прочий функционал. Но насчет GC согласен, реализовано это все достаточно неудобно.
Ой зря ты так, я достаточно много на D писал и по быстродействию он почти не отстает от языков без GC (конечно если использовать адекватный компилятор вроде LDC). Алсо сравнивать его с Lua бесмысленно, ибо шаблоны, трейты, инлайн ассемблер и прочий функционал. Но насчет GC согласен, реализовано это все достаточно неудобно.
>>572198
По быстродействию и джавы-сишарпы почти не отстают то языков без GC. x2-x4 - это так уж много, тормознутостью имеет смысл считать отставание в сотни и тысячи раз, как у питона и раби. Другое дело что в реалтайм приложениях некруто иметь хаотично запускающийся где-то посреди симуляции сборщик, заметное пользователю время вычищающий плотно засранную промежуточными результатами расчётного цикла кучу.
По быстродействию и джавы-сишарпы почти не отстают то языков без GC. x2-x4 - это так уж много, тормознутостью имеет смысл считать отставание в сотни и тысячи раз, как у питона и раби. Другое дело что в реалтайм приложениях некруто иметь хаотично запускающийся где-то посреди симуляции сборщик, заметное пользователю время вычищающий плотно засранную промежуточными результатами расчётного цикла кучу.
>>572203
Ты устарел. JIT-компиляция с выводом типов делает преимущество статических языков с GC призрачным.
Ты устарел. JIT-компиляция с выводом типов делает преимущество статических языков с GC призрачным.
>>571583
А вот и нет, у рустеров в том треде другие критерии...
А вот и нет, у рустеров в том треде другие критерии...
>>571410
А в чем проблема написать GC под задачу?
А в чем проблема написать GC под задачу?
>>572169
Ой, а зачем языку с best practises умных указателей и контролем на уровне компилятора CG? Неужели умные указатели таки сосут и в итоге приходится велосипедить мусоросборник?
Ой, а зачем языку с best practises умных указателей и контролем на уровне компилятора CG? Неужели умные указатели таки сосут и в итоге приходится велосипедить мусоросборник?
>>572223
Да сосут, сосут, съеби нахуй из треда.
Да сосут, сосут, съеби нахуй из треда.
>>572223
Всё очень просто:
Так-то кроме сервы GC ничто не использует.
> Ой, а зачем языку с best practises умных указателей и контролем на уровне компилятора CG?
Всё очень просто:
> Designing a GC was a wonderful experience!
Так-то кроме сервы GC ничто не использует.
>>572104
Нет, суть в том, что некие хуи предложили запилить "безопасные" двухсвязные списки за счет использования вместо указателей индексы в массиве итемов.
Я хотел сделать то же самое аналогичным образом, когда буду писать свое первое ядро ОСРВ на русте, но меня опередили, ЛОЛ.
ВНЕЗАПНО, такие списки оказались НЕБЕЗОПАСНЫМИ, та как использование индекса вместо указателя - просто прием для наебки компилятора, он не делает подобные списки безопасными вообще!
Такой прием дает возможность написать "безопасную" кучу с выходами за границы массивов, утечками памяти, использованием "освобожденной" памяти и "неинициализированных указателей".
То есть в этом вашем расте есть как минимум один способ написать падающий говнокод в обход правил "безопасости" и без единого использования unsafe.
А потом начались разборки, какой краш считать "хорошим" и "плохим", так же было предложение написать к такой реализации кучи GC, раз у сама куча - говно...
Так что, господа рустеры, проследуйте на парашу со своим небезопасным говноязыком.
Нет, суть в том, что некие хуи предложили запилить "безопасные" двухсвязные списки за счет использования вместо указателей индексы в массиве итемов.
Я хотел сделать то же самое аналогичным образом, когда буду писать свое первое ядро ОСРВ на русте, но меня опередили, ЛОЛ.
ВНЕЗАПНО, такие списки оказались НЕБЕЗОПАСНЫМИ, та как использование индекса вместо указателя - просто прием для наебки компилятора, он не делает подобные списки безопасными вообще!
Такой прием дает возможность написать "безопасную" кучу с выходами за границы массивов, утечками памяти, использованием "освобожденной" памяти и "неинициализированных указателей".
То есть в этом вашем расте есть как минимум один способ написать падающий говнокод в обход правил "безопасости" и без единого использования unsafe.
А потом начались разборки, какой краш считать "хорошим" и "плохим", так же было предложение написать к такой реализации кучи GC, раз у сама куча - говно...
Так что, господа рустеры, проследуйте на парашу со своим небезопасным говноязыком.
42 Кб, 971x207
>>572198
У меня видение мира такое, и оно основано на работе с языками 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 не нужны, потому что перформанса они не добавляют, а система типов у них на уровне С++ или хуже.
У меня видение мира такое, и оно основано на работе с языками 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 не нужны, потому что перформанса они не добавляют, а система типов у них на уровне С++ или хуже.
>>572230
Может там еще и на ноль делить можно?
Может там еще и на ноль делить можно?
>>572234
Да мог бы и не подписываться, и так ясно, как у тебя бомбит от крестов. Rust делали крестобляди для крестоблядей, вам, сишникам, не понять вообще.
Да мог бы и не подписываться, и так ясно, как у тебя бомбит от крестов. Rust делали крестобляди для крестоблядей, вам, сишникам, не понять вообще.
>>572232
Ты можешь сколько угодно себя убежать, как прекрасно все это мудоебство с типами и джитами, но самыми популярными все равно останутся те языки, которые ты считаешь ненужными.
Ты можешь сколько угодно себя убежать, как прекрасно все это мудоебство с типами и джитами, но самыми популярными все равно останутся те языки, которые ты считаешь ненужными.
>>572230
На самом деле, memory safety строго выполняется, просто тот код эмулирует небезопасную кучу.
Но эмуляцию можно сделать абсолютно на любом языке вне зависимости от его безопасности.
Единственная проблема раста здесь — недостаточно мощная система типов, провоцирующая написание подобных костылей.
> ВНЕЗАПНО, такие списки оказались НЕБЕЗОПАСНЫМИ, та как использование индекса вместо указателя - просто прием для наебки компилятора, он не делает подобные списки безопасными вообще!
На самом деле, memory safety строго выполняется, просто тот код эмулирует небезопасную кучу.
Но эмуляцию можно сделать абсолютно на любом языке вне зависимости от его безопасности.
Единственная проблема раста здесь — недостаточно мощная система типов, провоцирующая написание подобных костылей.
>>572237
Я об этом думал еще несколько лет назад. За это время набрала популярность нода, pypy развился, luajit бодро бегает, я поработал в проекте с groovy, которых сдох, но своим @compilestatic в этом же стиле. Все идет в том тренде, о котором я думал. То, что Java будет жить вечно на уровне легаси, я как бы не сомневаюсь). Но я вообще не вижу разницы в скорости разработки между С++ и Java, поэтому и не пытаюсь.
Я об этом думал еще несколько лет назад. За это время набрала популярность нода, pypy развился, luajit бодро бегает, я поработал в проекте с groovy, которых сдох, но своим @compilestatic в этом же стиле. Все идет в том тренде, о котором я думал. То, что Java будет жить вечно на уровне легаси, я как бы не сомневаюсь). Но я вообще не вижу разницы в скорости разработки между С++ и Java, поэтому и не пытаюсь.
>>572246
Счетчик ссылок?
Счетчик ссылок?
>>572246
Будут, с Rc.
Будут, с Rc.
Поясните мне за тулчейны, в чем разница между GCC и MSVC тулчейнами? Компилятор вроде бы один, на выходе вроде как везде обычный екзешник выходит в любом случае, так в чем же разница? Объясните дауну вроде меня, пожалуйста.
>>572212
Это, конечно, красивые сказки, но я из более-менее успешных реализаций знаю только v8 и luajit, и это большая заслуга разработчиков, сколько они там внутри всего натюнили и накрутили эвристически.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=v8
Но я не призываю использовать какие-нибудь джавы-сишарпы для перформанса. Я считаю, если перформанс реально важен (то есть реалтайм, все дела) - ручная память и цпп, если не так уж важен - динамические скрипты. Но при этом я думаю, что джавосишарпы таки действительно посередине между скриптами и байтоёбством как по перформансу, так и по производительности разработки, просто не люблю полумеры.
Это очень странно, такое обычно бывает если человек не писал как минимум на одном из этих языков. Управлять руками памятью - это весьма заметные дополнительные усилия и время. А думать о том, как это делать лучше и правильнее, продумывая архитектуру приложения - это вообще надолго.
>>572230
Принципиальное отличие в том, что ты с этой эмулированной кучей вообще никак не можешь уйти во всякие там сегфолты, или, тем более, реально пиздануть чужую память. Все ошибки, которые могут возникнуть - внутриязыковые и контролируемые.
Это, конечно, красивые сказки, но я из более-менее успешных реализаций знаю только v8 и luajit, и это большая заслуга разработчиков, сколько они там внутри всего натюнили и накрутили эвристически.
http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=v8
Но я не призываю использовать какие-нибудь джавы-сишарпы для перформанса. Я считаю, если перформанс реально важен (то есть реалтайм, все дела) - ручная память и цпп, если не так уж важен - динамические скрипты. Но при этом я думаю, что джавосишарпы таки действительно посередине между скриптами и байтоёбством как по перформансу, так и по производительности разработки, просто не люблю полумеры.
> я вообще не вижу разницы в скорости разработки между С++ и Java
Это очень странно, такое обычно бывает если человек не писал как минимум на одном из этих языков. Управлять руками памятью - это весьма заметные дополнительные усилия и время. А думать о том, как это делать лучше и правильнее, продумывая архитектуру приложения - это вообще надолго.
>>572230
Принципиальное отличие в том, что ты с этой эмулированной кучей вообще никак не можешь уйти во всякие там сегфолты, или, тем более, реально пиздануть чужую память. Все ошибки, которые могут возникнуть - внутриязыковые и контролируемые.
>>572257
Меня реально бесит только upward funarg problem, но оно уже лечится через move. А так, хуй знает. Когда приложение уже зрелое, вообще похуй, ну следишь за владением, ну и следишь. Зато шаблоны есть. С нуля на крестах довольно неприятно, потому что постоянно нужно перизобретать мир - все эти pretty printer'ы и прочее говно. Но в целом, я бы не сказал, что "если бы не перформанс, я бы за С++ не брался, а писал бы на божественном C#". Хороший С++ проект приятнее. А ничего революционно удобного, типа repl, эти языки не предлагают.
> Управлять руками памятью - это весьма заметные дополнительные усилия и время.
Меня реально бесит только upward funarg problem, но оно уже лечится через move. А так, хуй знает. Когда приложение уже зрелое, вообще похуй, ну следишь за владением, ну и следишь. Зато шаблоны есть. С нуля на крестах довольно неприятно, потому что постоянно нужно перизобретать мир - все эти pretty printer'ы и прочее говно. Но в целом, я бы не сказал, что "если бы не перформанс, я бы за С++ не брался, а писал бы на божественном C#". Хороший С++ проект приятнее. А ничего революционно удобного, типа repl, эти языки не предлагают.
>>572235
Мне не бомбит ни от крестов, ни от руста, ни от лишпа с хачкелем.
Мне не нравятся упоротые евангелисты.
А в русте они не менее упоротые чем золотце и лавсанчик.
Если бы местные питушки не приперлись в имбед-тред, и не начали форсить свою парашу и толстить, я бы не обратил на вас внимание.
Сами виноваты, короч.
Мне не бомбит ни от крестов, ни от руста, ни от лишпа с хачкелем.
Мне не нравятся упоротые евангелисты.
А в русте они не менее упоротые чем золотце и лавсанчик.
Если бы местные питушки не приперлись в имбед-тред, и не начали форсить свою парашу и толстить, я бы не обратил на вас внимание.
Сами виноваты, короч.
>>572279
Какие серьезные аргументы. Портфель собрал?
Какие серьезные аргументы. Портфель собрал?
>>572277
Вот твой первый задокументированный батхерт итт: >>547251
Батхерт тут очевиден, потому что ты занимаешься грязной подменой понятий. Я даже описывать не буду.
Проблема в том, что ты сишник. Первый момент - тебе бомбит от крестов ("шаблонное петушение"). Я понимаю, что лучше гордо пердолисться через #define, но тем не менее. В расте нет шаблонов, там тайпклассы, как в хачкеле. Второй момент, у него и с unsafe куча преимуществ. Это и лямбды, или тайпклассы, и паттерн-матчинг, и макросы, . Но ты почему-то взъелся именно на safe/unsafe, в котором серебряной пули никто не обещал. Пиши базовые контейнеры и аллокаторы с unsafe, в чем проблема. Никакой проблемы нет. Никто не обещал, что будет легко. И никто не обещал, что сишникам (т.е. дну неосиляторства) будет легко.
Вот твой первый задокументированный батхерт итт: >>547251
>Алсо, язык ни хера не системный, как тут пытаются утверждать, на нем даже двухсвязный список без unsafe не написать, следовательно на системном коде все его преимущества ВНЕЗАПНО разбиваются об unsafe,
>и остается только убогий вырвиглазный синтаксис с шаблонным питушением.
Батхерт тут очевиден, потому что ты занимаешься грязной подменой понятий. Я даже описывать не буду.
Проблема в том, что ты сишник. Первый момент - тебе бомбит от крестов ("шаблонное петушение"). Я понимаю, что лучше гордо пердолисться через #define, но тем не менее. В расте нет шаблонов, там тайпклассы, как в хачкеле. Второй момент, у него и с unsafe куча преимуществ. Это и лямбды, или тайпклассы, и паттерн-матчинг, и макросы, . Но ты почему-то взъелся именно на safe/unsafe, в котором серебряной пули никто не обещал. Пиши базовые контейнеры и аллокаторы с unsafe, в чем проблема. Никакой проблемы нет. Никто не обещал, что будет легко. И никто не обещал, что сишникам (т.е. дну неосиляторства) будет легко.
Пишу сложную сетевую штуковину на Rust и надо написать функции inet6_aton/inet6_ntoa. Может кто-то понимает, как оно работает? Есть код на C, но там все слишком сложна.
Также, ищу библиотеку для кроссплатформенной реализации демона(daemon). Есть rust-daemon, но там лишь для windows и linux.
Также, ищу библиотеку для кроссплатформенной реализации демона(daemon). Есть rust-daemon, но там лишь для windows и linux.
Пришла пора расставить точки над Растом. Раст - это сишка с умными указателями. В сишке с типами и умными указателями нет ничего плохого, но это вовсе не то, за что растодети его выдают. Когда в Расте нужно реализовать двусвязный спиок, растодети начинают писать unsafe. Ну а что вы хотели от умных указателей?
>>572294
Да ты заебал уже, окончательно заебал. Ты понимаешь, что ты уже всех заебал? За один ебаный день, блядь.
Да ты заебал уже, окончательно заебал. Ты понимаешь, что ты уже всех заебал? За один ебаный день, блядь.
>>572298
Не стукай
Не стукай
>>572295
А конкретнее? Обьясните ребенку с Синдромом Дауна.
А конкретнее? Обьясните ребенку с Синдромом Дауна.
>>572275
Дженериков джавы и сишарпа хватает для основных вещей типа полиморфных контейнеров, асинко-промизов, и ко/контравариантности этого всего, и прелесть в том, что в коде всё просто и понятно, классо-ориентированное ооп на этих языках предполагает определённую культуру оформления кода, и она оказывается одновременно очень выразительной, и поразительно простой и униформной. На С++ можно встретить что угодно и как угодно, а тамошние шаблоны являются смесью параметрического полиморфизма и макросов, потому позволяют делать кучу всяких трюков в духе "template <typename Base> class Yoba : public Base { ... }", через которые выражаются вещи, которые тянут на отдельные парадигмы. Если не собираешься писать свою личную парадигму, зачем все эти лиспохаскелизмы? Каждая такая программа на С++ - это свой новый надязык, философию которого нужно понять и принять. Ну и ещё всё что использует шаблоны - надо хуярить в хидерах, перекомпилировать мир каждый раз, разбираться в нечитабельных ошибках на много страниц, и так далее.
Дженериков джавы и сишарпа хватает для основных вещей типа полиморфных контейнеров, асинко-промизов, и ко/контравариантности этого всего, и прелесть в том, что в коде всё просто и понятно, классо-ориентированное ооп на этих языках предполагает определённую культуру оформления кода, и она оказывается одновременно очень выразительной, и поразительно простой и униформной. На С++ можно встретить что угодно и как угодно, а тамошние шаблоны являются смесью параметрического полиморфизма и макросов, потому позволяют делать кучу всяких трюков в духе "template <typename Base> class Yoba : public Base { ... }", через которые выражаются вещи, которые тянут на отдельные парадигмы. Если не собираешься писать свою личную парадигму, зачем все эти лиспохаскелизмы? Каждая такая программа на С++ - это свой новый надязык, философию которого нужно понять и принять. Ну и ещё всё что использует шаблоны - надо хуярить в хидерах, перекомпилировать мир каждый раз, разбираться в нечитабельных ошибках на много страниц, и так далее.
>>572289
Не нужно, есть более подходящие паттерны проектирования
Ну ты понел, да?
Ваши же евангелисты и ообещали, что не надо "заморачиваться с отслеживанием времени жизни переменных, конпелятор все равно лучше отследит", и много чего еще.
Ойвей, осиляторы закукарекали!
Я предпочитаю выбирать инструмент под задачу, а не упарываться всякими каргокультами (за годы сидения в кодаче, я слышал столько базвордов, что все уже не упомню, не осилю, ЛОЛ).
>Я понимаю, что лучше гордо пердолисться через #define, но тем не менее.
Не нужно, есть более подходящие паттерны проектирования
>Но ты почему-то взъелся именно на safe/unsafe, в котором серебряной пули никто не обещал.
>#rust #nogc #memorysafety
Ну ты понел, да?
>Никто не обещал, что будет легко.
Ваши же евангелисты и ообещали, что не надо "заморачиваться с отслеживанием времени жизни переменных, конпелятор все равно лучше отследит", и много чего еще.
>сишникам (т.е. дну неосиляторства)
Ойвей, осиляторы закукарекали!
Я предпочитаю выбирать инструмент под задачу, а не упарываться всякими каргокультами (за годы сидения в кодаче, я слышал столько базвордов, что все уже не упомню, не осилю, ЛОЛ).
>>572289
И чем это отличается на низком уровне от шаблонного питушения? Точно так же под каждый тип будет генериться своя реализация методов, во всяком случае так написано вашими же евангелистами-википидорами.
> В расте нет шаблонов, там тайпклассы, как в хачкеле.
И чем это отличается на низком уровне от шаблонного питушения? Точно так же под каждый тип будет генериться своя реализация методов, во всяком случае так написано вашими же евангелистами-википидорами.
>>572294
Нет. Это кресты с безопасным загоном для быдлокодеров, правда в загоне есть дыры но это уже другой вопрос...
Нет. Это кресты с безопасным загоном для быдлокодеров, правда в загоне есть дыры но это уже другой вопрос...
>>571978
Я в 2001 уже твою мамку шпилил. Тебе как раз 14 лет должно быть, получается.
Я в 2001 уже твою мамку шпилил. Тебе как раз 14 лет должно быть, получается.
>>572331
Кстати в Википедии написано нейтрально, и область применения обозначена как язык "для написания больших клиент-серверных приложений, работающих в сети Интернет."
С такой областью применения я как раз согласен.
шкорльник-кун
Кстати в Википедии написано нейтрально, и область применения обозначена как язык "для написания больших клиент-серверных приложений, работающих в сети Интернет."
С такой областью применения я как раз согласен.
шкорльник-кун
>>564962
Великолепно! Это именно то, что нужно!
И вот почему: вогуг любого продукта есть группы заинтересованных лиц, в случае софта это: программисты, пользователи, QA и сопровожденцы, менеджмент.
Программисты заинтересованы в бабле им нужен инструмент, который позволяет писать программы с минимальной нагрузкой на механизмы внимания и памяти
Пользователи заинтересованы в стабильной программе, которая подходит для области, в которой используется, а еще им нужно быстрое решение технических проблем.
QA заинтересованы в возможности быстро решать проблемы пользователей, иначе их выебут.
Сопровожденцы - тоже программисты, но они не писали а только сопровождают поделие, им нужно быстро искать и править баги, а для этого (сюрприз!) нужно чтобы изучение исходников программы как можно меньше нагружало механизмы внимания и памяти.
Менеджмент - этим пидорасам нужно одно - снижение издержек на стадиях разработки, внедрения, сопровождения. А для этого, нужно использовать инструменты разработки, которые позволят программистам быстро писать, а сопровожденцам быстро читать и править, то есть нужен простой язык на котором полюбасу получаются читаемые программы, причем быстро и с персоналом низкой квалификации.
Соответствено менеджмент тоже заинтересован в низкой нагрузке на мозги программистов и спровожденцев.
В гугле все правильно сделали.
>Goвно - хороший инструмент с точки зрения менеджмента: любого дауна можно посадить писать код и он его напишет и результат будет даже читаемым. Собственно для этого он и придуман.
Великолепно! Это именно то, что нужно!
И вот почему: вогуг любого продукта есть группы заинтересованных лиц, в случае софта это: программисты, пользователи, QA и сопровожденцы, менеджмент.
Программисты заинтересованы в бабле им нужен инструмент, который позволяет писать программы с минимальной нагрузкой на механизмы внимания и памяти
Пользователи заинтересованы в стабильной программе, которая подходит для области, в которой используется, а еще им нужно быстрое решение технических проблем.
QA заинтересованы в возможности быстро решать проблемы пользователей, иначе их выебут.
Сопровожденцы - тоже программисты, но они не писали а только сопровождают поделие, им нужно быстро искать и править баги, а для этого (сюрприз!) нужно чтобы изучение исходников программы как можно меньше нагружало механизмы внимания и памяти.
Менеджмент - этим пидорасам нужно одно - снижение издержек на стадиях разработки, внедрения, сопровождения. А для этого, нужно использовать инструменты разработки, которые позволят программистам быстро писать, а сопровожденцам быстро читать и править, то есть нужен простой язык на котором полюбасу получаются читаемые программы, причем быстро и с персоналом низкой квалификации.
Соответствено менеджмент тоже заинтересован в низкой нагрузке на мозги программистов и спровожденцев.
В гугле все правильно сделали.
>>572369
Диван0, залогиньтесь.
Диван0, залогиньтесь.
>>572369
Но ведь Go менее простой, читабельный, и продуктивный, чем JavaScript, Python, Ruby.
Но ведь Go менее простой, читабельный, и продуктивный, чем JavaScript, Python, Ruby.
>>572385
Не так же, намного меньше:
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, питона, жабы, сишарпа и тд.
> 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, питона, жабы, сишарпа и тд.
>>572398
Раст тоже не годится для реалтайма из-за динамичекой аллокации памяти и каскадного освобождения. Если мы говорим про тот реалтайм, которому мусоросборник мешает. Правда реалтайм в /pr/ - это как секс у подростков. Всё о нём говорят, но никто не занимается.
>А вот go один хуй не годится для реалтайма из-за сборщика, так что его область - та же, что у js, питона, жабы, сишарпа и тд.
Раст тоже не годится для реалтайма из-за динамичекой аллокации памяти и каскадного освобождения. Если мы говорим про тот реалтайм, которому мусоросборник мешает. Правда реалтайм в /pr/ - это как секс у подростков. Всё о нём говорят, но никто не занимается.
>>572328
Кто-то заставляет писать с unsafe? В redox unsafe используется только для библиотек (для чего и предназначен), servo написан практически на чистом safe (unsafe в тестах используют зачем-то).
Кто-то заставляет писать с unsafe? В redox unsafe используется только для библиотек (для чего и предназначен), servo написан практически на чистом safe (unsafe в тестах используют зачем-то).
>>572402
Я в реалтайм включаю любые приложения с непрерывной симуляцией, например игры. А rust даже и просто тормозной, потому что тупо плохо компилирует, а какой он неудобный, и насколько шизофреничные там сигнатуры - это вообще отдельная песня.
Я в реалтайм включаю любые приложения с непрерывной симуляцией, например игры. А rust даже и просто тормозной, потому что тупо плохо компилирует, а какой он неудобный, и насколько шизофреничные там сигнатуры - это вообще отдельная песня.
>>572398
>>572402
2 господина теоретика, будьте добры посетить какую нибудь трансляцию на твиче с 100к человек (редко, но бывает во время всяких турниров) и посмотреть как работает чатик. Стоп зе ворлд сука. Или сходите в какой нибудь cloudflare, и рассказать как хуёво с гц в реалтайме, когда на дворе 2015 год. По логике второго антоши - весь риалтайм-кококо-хуйлоад можно пейсать вообще только на си, когда где-то в далёком яндексе поиск на перле работает.
Мусоропровод в 2015 не везде такой топорный как в жаве.
>>572402
2 господина теоретика, будьте добры посетить какую нибудь трансляцию на твиче с 100к человек (редко, но бывает во время всяких турниров) и посмотреть как работает чатик. Стоп зе ворлд сука. Или сходите в какой нибудь cloudflare, и рассказать как хуёво с гц в реалтайме, когда на дворе 2015 год. По логике второго антоши - весь риалтайм-кококо-хуйлоад можно пейсать вообще только на си, когда где-то в далёком яндексе поиск на перле работает.
Мусоропровод в 2015 не везде такой топорный как в жаве.
>>572410
Лол, в вебпараше реалтайма нет вообще. Ты не путай с ХАЙЛОАДОМ. В реалтайм симуляции надо просчитывать всю хуйню 60кадров в секунду, и чтобы это всё было плавно и с одинаковой скоростью - чуть где какой гц - и сразу подёргивания и подлагивания. В чяте вообще не может быть такой хуйни, потому что дискретная природа информации.
Лол, в вебпараше реалтайма нет вообще. Ты не путай с ХАЙЛОАДОМ. В реалтайм симуляции надо просчитывать всю хуйню 60кадров в секунду, и чтобы это всё было плавно и с одинаковой скоростью - чуть где какой гц - и сразу подёргивания и подлагивания. В чяте вообще не может быть такой хуйни, потому что дискретная природа информации.
>>572409
Ну так игры и на языках с мусоросборником никто писать не мешает. Про тормоза мусоросборников и GC-паузы в полсекунды кукарекают больше всего те, кто не писал на языках с мусоросборниками.
>>572410
Еще раз - теоретики - это те, кто кукарекает про то, как мусоросборник реалтайму мешает. Теоретики они именно потому, что ни с тем ни с другим не программировали, но мнение имеют.
Ну так игры и на языках с мусоросборником никто писать не мешает. Про тормоза мусоросборников и GC-паузы в полсекунды кукарекают больше всего те, кто не писал на языках с мусоросборниками.
>>572410
Еще раз - теоретики - это те, кто кукарекает про то, как мусоросборник реалтайму мешает. Теоретики они именно потому, что ни с тем ни с другим не программировали, но мнение имеют.
>>572294
А я обожаю писать двусвязные списки. Каждый день я сажусь за компьютер и начинаю писать свою особую реализацию двусвязного списка. Ведь чем же ещё погромист должен заниматься, кроме как создания домашнего велосипеда?
Самому не смешно?
А я обожаю писать двусвязные списки. Каждый день я сажусь за компьютер и начинаю писать свою особую реализацию двусвязного списка. Ведь чем же ещё погромист должен заниматься, кроме как создания домашнего велосипеда?
Самому не смешно?
>>572425
Но лучше беспрувного кукаретика, которому в маняфантазиях мусоросборники игоры писать мешают.
Но лучше беспрувного кукаретика, которому в маняфантазиях мусоросборники игоры писать мешают.
>>572431
Долбоёбушка, ты не понимаешь, что раз там даже двусвязный список нельзя без unsafe сделать, то ни о каких более сложных структурах данных и речи быть не может?
Долбоёбушка, ты не понимаешь, что раз там даже двусвязный список нельзя без unsafe сделать, то ни о каких более сложных структурах данных и речи быть не может?
>>572423
Будет что-то в духе: http://stackoverflow.com/a/2484301/1203558
То есть более низкоуровнево, чем на С++ с его zero-cost abstractions.
И не надо рассказывать, что это просто джава плохая, она охуенно быстрая, и сборщик там быстрый, один из лучших.
> Ну так игры и на языках с мусоросборником никто писать не мешает
Будет что-то в духе: http://stackoverflow.com/a/2484301/1203558
То есть более низкоуровнево, чем на С++ с его zero-cost abstractions.
И не надо рассказывать, что это просто джава плохая, она охуенно быстрая, и сборщик там быстрый, один из лучших.
>>572435
Это проблемы не языка с мусоросборником, а джавы, в которой нельзя сделать нормальные абстракции для работы со структурой массивов как с массивом объектов. И очень медленных устройств, про которые написано в исходном вопросе.
Это проблемы не языка с мусоросборником, а джавы, в которой нельзя сделать нормальные абстракции для работы со структурой массивов как с массивом объектов. И очень медленных устройств, про которые написано в исходном вопросе.
>>572328
Основной твой каргокульт - это крестохейтерство. Растохетерство идет следом, потому что раст - это кресты, как если бы их разработали в 2010, без обратной совместимости с сишкой и крестами образца 1991 года.
Всем. Шаблоны диспатчатся только при компиляции, если тебе нужен полиморфизм в динамике, в С++ у тебя выбор - ООП на VMT. Отсюда при разработке вознимает дилемма - шаблоны, или все-таки ООП. Это все равно лучше сишки, где предел мечтаний - это касты void*, но тем не менее.
А тайпклассы универсальны, если типы известны во время компиляции, используется статический диспатч, если неизвестны - динамический. При этом, в отличие от ООП, каждый трейт в динамике тащит за собой 2 указателя - на структуру данных и на VMT (в ООП структура данных содержит внутри себя указатель на VMT), и за счет этого ты получаешь всю мощь тайпклассов.
А тебе на это похуй, потому что зачем думать о таком, есть же крестохейтерство, произнес 10 раз подряд "шаблонное петушение" и полегчало, хули там, ведь шаблоны - для петухов, от них объем кода на килобайты растет.
>Я предпочитаю выбирать инструмент под задачу, а не упарываться всякими каргокультами (за годы сидения в кодаче, я слышал столько базвордов, что все уже не упомню, не осилю, ЛОЛ).
Основной твой каргокульт - это крестохейтерство. Растохетерство идет следом, потому что раст - это кресты, как если бы их разработали в 2010, без обратной совместимости с сишкой и крестами образца 1991 года.
>И чем это отличается на низком уровне от шаблонного питушения?
Всем. Шаблоны диспатчатся только при компиляции, если тебе нужен полиморфизм в динамике, в С++ у тебя выбор - ООП на VMT. Отсюда при разработке вознимает дилемма - шаблоны, или все-таки ООП. Это все равно лучше сишки, где предел мечтаний - это касты void*, но тем не менее.
А тайпклассы универсальны, если типы известны во время компиляции, используется статический диспатч, если неизвестны - динамический. При этом, в отличие от ООП, каждый трейт в динамике тащит за собой 2 указателя - на структуру данных и на VMT (в ООП структура данных содержит внутри себя указатель на VMT), и за счет этого ты получаешь всю мощь тайпклассов.
А тебе на это похуй, потому что зачем думать о таком, есть же крестохейтерство, произнес 10 раз подряд "шаблонное петушение" и полегчало, хули там, ведь шаблоны - для петухов, от них объем кода на килобайты растет.
>>572441
И, кстати, в Говне++ те же самые проблемы и те же самые пути решения:
Там в main-loop тоже уже никто ничего не аллоцирует, всё в основном создаётся заранее.
И, кстати, в Говне++ те же самые проблемы и те же самые пути решения:
Там в main-loop тоже уже никто ничего не аллоцирует, всё в основном создаётся заранее.
>>572433
Не. Ты - хуже пидораса. У тебя мысли ходят по кругу и ты из года в год пишешь одно и то же. Перенесись на пару лет вперед, ты будешь нести ту же самую желчь.
Не. Ты - хуже пидораса. У тебя мысли ходят по кругу и ты из года в год пишешь одно и то же. Перенесись на пару лет вперед, ты будешь нести ту же самую желчь.
>>572456
Какой сочный ad-hominem, аж течет.
Какой сочный ad-hominem, аж течет.
>>572450
Преаллокация и пулинг всякий - это нормально. Ненормально именно то, что в небайтоёбских языках нельзя оперировать этими вещами как-либо высокоуровневее, чем массивами примитивов (int, byte и тд). Самый очевидный и повсеместный плюс - что в С++ не будет боксинга при array-of-structures. Но даже если хочется уйти в SSE по-хардкору, можно написать свои стековые дескриптороабстракции для structure-of-arrays.
>>572448
С разморозкой: http://www.boost.org/doc/libs/1_55_0/doc/html/boost_typeerasure.html )))
Преаллокация и пулинг всякий - это нормально. Ненормально именно то, что в небайтоёбских языках нельзя оперировать этими вещами как-либо высокоуровневее, чем массивами примитивов (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 )))
>>572434
Охуенная логика, давай ещё. Если есть выбор между условных 95% безопасного кода (при этом 5% ограничиваются одной-тремя последовательностями строчек) и 0% при прочих равных условиях, ты будешь писать на голых 0%?
Охуенная логика, давай ещё. Если есть выбор между условных 95% безопасного кода (при этом 5% ограничиваются одной-тремя последовательностями строчек) и 0% при прочих равных условиях, ты будешь писать на голых 0%?
>>572475
Ты еще про свитчи мне расскажи. Я говорю о средствах языка, а не неюзабельном пердолинге шаблонов.
Ты еще про свитчи мне расскажи. Я говорю о средствах языка, а не неюзабельном пердолинге шаблонов.
1621 Кб, 1280x720
>>572402
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
1621 Кб, 1280x720
>>572402
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
В крайнем случае динам аллокатор со сложностью о(1).
>>572434
Не понимают.
А какие бывают? У меня сложнее дерева приоритетных двухсвязных списков сходу ничего на ум не приходит...
>>572448
У нем я нет ненависти к крестам, это все равно, что ненавидеть космос...
Однако я считаю, что как инструмент они имеют ряд недостатков...
Главный из которых то, что кресты - комбайн, если сравнивать между собой языки, то Си - это английский(24буквы), а ЦПП - это китайский(2000+ иероглифов).
То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
ООП - плохой выбор, потому, что при использовании этого подхода сначала делается иерархия классов, а потом все остальное, соответственно при изменении требований вся иерархия может полететь в низшую, все придется переписывать.
Мне больше нравится компонентно-ориентированный подход.
Шаблоны - плохой выбор, потому, что экзешник будет расти , как на дрожжах без прироста производительности, то есть, это пустая трата ресурсов, которые ограничены.
А еще в случае шаблона будут сгенерированы все методы для каждой реализации...
В няшной - только те, которые сам захочу (это если делать с дефайнами). При этом я еще могу сэкономить память без потери производительности.
Надо, сделаю таблицу виртуальных методов, ООП тут ни при чем.
Короче есть гигабайты и гигагерцы - юзай кресты, А для моих задач лучше подходит Си, ибо упрощает управление ограниченными ресурсами как людей, так и девайсов.
>>572484
Проблема в том, что этот код не будет безопасным, в тредике уже есть пример небезопасного кода без unsafe.
Проблема в том, что этот код не будет безопасным, в тредике уже есть пример небезопасного кода без unsafe.
>>572369
Все так, но после определенного порога объёма кода или сложности предметной области снижение нагрузки на механизмы внимания и памяти достигается путем повышения уровня абстракции, а в Go с этим неочень.
Кроме того, код написанный в излише императивном стиле, часто сложен для понимания, поэтому даже в Effective Java призывают ограничивать мутабельность например. Но это конечно не только Go касается.
Я вообще недавно писал пост о применимости языков, но тот тред вроде уже смыло.
>>572230
Ты же подменяешь понятия, челик. Ты можешь написать просто a/b без проверки b на неравенство 0 посреди кода, и что, компилятор должен тебя уберечь от этого? Это наверное возможно, но тебе в языки с зависимыми типами тогда, и там во многих случаях во всех не тривиальных, как я понимаю ты сам должен будешь доказывать компилятору что код корректный.
Все так, но после определенного порога объёма кода или сложности предметной области снижение нагрузки на механизмы внимания и памяти достигается путем повышения уровня абстракции, а в Go с этим неочень.
Кроме того, код написанный в излише императивном стиле, часто сложен для понимания, поэтому даже в Effective Java призывают ограничивать мутабельность например. Но это конечно не только Go касается.
Я вообще недавно писал пост о применимости языков, но тот тред вроде уже смыло.
>>572230
Ты же подменяешь понятия, челик. Ты можешь написать просто a/b без проверки b на неравенство 0 посреди кода, и что, компилятор должен тебя уберечь от этого? Это наверное возможно, но тебе в языки с зависимыми типами тогда, и там во многих случаях во всех не тривиальных, как я понимаю ты сам должен будешь доказывать компилятору что код корректный.
>>572531
Говорить. Если писать, то они тоже друг друга поймут. Одна из причин, почему китайцы не уходят от иероглифов.
>То есть те, кто пишут на английском, друг друга поймут практически всегда, в то время как люди из разных провинций Китая могут писать на непересекающихся подмножествах языка с соответствующим результатом.
Говорить. Если писать, то они тоже друг друга поймут. Одна из причин, почему китайцы не уходят от иероглифов.
>>572475
Блядь, да я про то и пишу, что это - проблемы джавы, а не мусоросборника. Хуёвый, невыразительный язык, в том же Хаскелле это делается вполне сносно. И еще я хочу сказать, что отсутсвие мусоросборника эти проблемы не решает. Они есть, они реальны, они объективны в любом языке, и способы их решения везде примерно одинаковы. Мой коллега написал физический движок и игрульку на нём для фана. На С++. И да, пул объектов, преаллокации, хуё-моё, на С++ он это всё выразил. Аллоцировал бы в main-loop, была бы та же хуйня, что и в языке с GC, он мне так и сказал, поэтому и изъябывался. Писал бы на джаве... ну, в принципе, я работал в UBS, там был Market Order Bus (шина сообщений для обработки ордеров, примерно с теми же требованиями), джава, zero GC. Работает, но выглядит как говно. То, что оно как говно выглядит, исключительно проблемы языка (а не GC), а то, что оно работает - доказательство того, что и в небайтоёбских языках всё это решается, причем теми же методами, что и в байтоёбских. Просто надо брать правильный небайтоёбский язык, а не джаву.
>Ненормально именно то, что в небайтоёбских языках нельзя оперировать этими вещами как-либо высокоуровневее
Блядь, да я про то и пишу, что это - проблемы джавы, а не мусоросборника. Хуёвый, невыразительный язык, в том же Хаскелле это делается вполне сносно. И еще я хочу сказать, что отсутсвие мусоросборника эти проблемы не решает. Они есть, они реальны, они объективны в любом языке, и способы их решения везде примерно одинаковы. Мой коллега написал физический движок и игрульку на нём для фана. На С++. И да, пул объектов, преаллокации, хуё-моё, на С++ он это всё выразил. Аллоцировал бы в main-loop, была бы та же хуйня, что и в языке с GC, он мне так и сказал, поэтому и изъябывался. Писал бы на джаве... ну, в принципе, я работал в UBS, там был Market Order Bus (шина сообщений для обработки ордеров, примерно с теми же требованиями), джава, zero GC. Работает, но выглядит как говно. То, что оно как говно выглядит, исключительно проблемы языка (а не GC), а то, что оно работает - доказательство того, что и в небайтоёбских языках всё это решается, причем теми же методами, что и в байтоёбских. Просто надо брать правильный небайтоёбский язык, а не джаву.
>>572484
Охуенная логика. Есть выбор между структурами с циклическими ссылками, которые через смартпоинтеры не выражаются, и структурами без циклических ссылок. Ну ладно, мудак, допустим циклические ссылки не нужны (щастье-то какое, как бы можно было бы оптимизировать мусоросборники без таковых), ты DAG в расте опишешь без unsafe? DAG, братюня, там нет циклических ссылок, чисто DAG. Или он тоже не нужен?
Охуенная логика. Есть выбор между структурами с циклическими ссылками, которые через смартпоинтеры не выражаются, и структурами без циклических ссылок. Ну ладно, мудак, допустим циклические ссылки не нужны (щастье-то какое, как бы можно было бы оптимизировать мусоросборники без таковых), ты DAG в расте опишешь без unsafe? DAG, братюня, там нет циклических ссылок, чисто DAG. Или он тоже не нужен?
>>572589
Лолблядь, в хаскеле работать с десятью слоями IO, ST, IOURef и линз - это нихуя не сносно и хуже любого петушения байтомассивов на жабке.
Отсутствие мусоросборника гарантирует, что ты его использовать не будешь, а такая гарантия обязательна, ну и накладывает определённые требования к средствам выражения абстракций в языке. Я не знаю ни одного языка без мусоросборника, который бы не позволял делать анбоксед массивы структур и локальные структуры вне кучи.
В том же С# есть value-типы и по идее их массивы будут даже незабоксены в большинстве случаев, но там вся стандартная библиотека, все коллекции - всё вычищается обязательно через GC, потому движок для симуляции на нём писать смысла мало. Зато игровую логику скриптовать, как в Юнити каком-нибудь, где ядро на C++, а скрипты - на C#/JS/Python - это пожалуйста.
> в том же Хаскелле это делается вполне сносно
Лолблядь, в хаскеле работать с десятью слоями IO, ST, IOURef и линз - это нихуя не сносно и хуже любого петушения байтомассивов на жабке.
> отсутсвие мусоросборника эти проблемы не решает
Отсутствие мусоросборника гарантирует, что ты его использовать не будешь, а такая гарантия обязательна, ну и накладывает определённые требования к средствам выражения абстракций в языке. Я не знаю ни одного языка без мусоросборника, который бы не позволял делать анбоксед массивы структур и локальные структуры вне кучи.
В том же С# есть value-типы и по идее их массивы будут даже незабоксены в большинстве случаев, но там вся стандартная библиотека, все коллекции - всё вычищается обязательно через GC, потому движок для симуляции на нём писать смысла мало. Зато игровую логику скриптовать, как в Юнити каком-нибудь, где ядро на C++, а скрипты - на C#/JS/Python - это пожалуйста.
>>572531
Что характерно, все настоящие раелтайм-бляди предпочитают статическое выделение памяти на этапе конпеляции. Это такой паттерн, можно сказать. Поэтому любой реалтайм-бляди очевидно, что Rust - ни чуть не в большей степени реалтайм, чем язык с мусоросборником.
Ну в реалтайме других и не бывает. Потому что они уже слишком непредсказуемые. Ты - редкое исключение, которе живёт в реалтайм-мирке. Этот мирок очень-очень ограничен, там очень мало типов данных и очень мало алгоритмов. Это - нормально. Но когда кто-то начинает приплетать реалтайм к языку программирования общего назначения, с динамической аллокацией, тьюринг-полному наконец, хочется послать этого хуесоса нахуй, закономерно.
>Я им занимаюсь, и предпочитаю статическое выделение памяти, ибо гобально-надежно.
Что характерно, все настоящие раелтайм-бляди предпочитают статическое выделение памяти на этапе конпеляции. Это такой паттерн, можно сказать. Поэтому любой реалтайм-бляди очевидно, что Rust - ни чуть не в большей степени реалтайм, чем язык с мусоросборником.
>Не понимают. А какие бывают?
Ну в реалтайме других и не бывает. Потому что они уже слишком непредсказуемые. Ты - редкое исключение, которе живёт в реалтайм-мирке. Этот мирок очень-очень ограничен, там очень мало типов данных и очень мало алгоритмов. Это - нормально. Но когда кто-то начинает приплетать реалтайм к языку программирования общего назначения, с динамической аллокацией, тьюринг-полному наконец, хочется послать этого хуесоса нахуй, закономерно.
>>572596
Ты тот хуесос, который писал структуры с полями IORef? Просто иди нахуй, ты языка не знаешь.
>Лолблядь, в хаскеле работать с десятью слоями IO, ST, IOURef и линз - это нихуя не сносно и хуже любого петушения байтомассивов на жабке.
Ты тот хуесос, который писал структуры с полями IORef? Просто иди нахуй, ты языка не знаешь.
>>572757
Схуяли им там быть, если он 2д аркадкой любой игровой пека положил бы нахуй?
Схуяли им там быть, если он 2д аркадкой любой игровой пека положил бы нахуй?
1106 Кб, 1920x1080
>>572592
Когда споришь сам с собой, можешь за других додумывать всё что угодно. Тебе говорят не про то, что НЕ НУЖНО, а про то, что нет необходимости всё подряд описывать на небезопасном языке. А описываемое на небезопасном можно ограничивать и оно лучше отслеживается, чем в чисто небезопасных языках.
Так-то даже в языках со сборкой мусора в некоторых случаях без ручного освобождения не обходится, из-за они НЕ НУЖНЫ?
https://github.com/mitchmindtree/daggy
>>572535
Ну они в документации и презентациях говорят о подобных случаях.
> Ну ладно, мудак, допустим циклические ссылки не нужны
Когда споришь сам с собой, можешь за других додумывать всё что угодно. Тебе говорят не про то, что НЕ НУЖНО, а про то, что нет необходимости всё подряд описывать на небезопасном языке. А описываемое на небезопасном можно ограничивать и оно лучше отслеживается, чем в чисто небезопасных языках.
Так-то даже в языках со сборкой мусора в некоторых случаях без ручного освобождения не обходится, из-за они НЕ НУЖНЫ?
https://github.com/mitchmindtree/daggy
>>572535
Ну они в документации и презентациях говорят о подобных случаях.
https://github.com/cristicbz/rust-doom
ГОТОВ ДЛЯ ТРИПЛ А ГЕЙМДЕВА в 1993 году
>No unsafe blocks anywhere
ГОТОВ ДЛЯ ТРИПЛ А ГЕЙМДЕВА в 1993 году
>>574086
Инфа хоть и старая, но ничего не изменилось с тех времен, си/кресто -параша никуда же не делась, и хоть они и кукарекают о том что все отлично и ничего не течет, но мы то знаем.
Инфа хоть и старая, но ничего не изменилось с тех времен, си/кресто -параша никуда же не делась, и хоть они и кукарекают о том что все отлично и ничего не течет, но мы то знаем.
Лол, сидим тут в мертвом треде, а новый почти два дня назад запилили, ОП даже не потрудился о перекате написать.
>>572681 (OP)
>>572681 (OP)
>>574143
Точно, забыл стереть у себя этот и перепутал, спасибо.
Точно, забыл стереть у себя этот и перепутал, спасибо.
Тред утонул или удален.
Это копия, сохраненная 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 26 ноября 2015 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.