Этого треда уже нет.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Rust — язык, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
https://www.rust-lang.org/
Обязательно для прочтения: https://doc.rust-lang.ru/book/
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Ресурсы на русском: https://rust-lang.ru/
Предыдущий тред: >>1880122 (OP) (OP)
https://www.rust-lang.org/
Обязательно для прочтения: https://doc.rust-lang.ru/book/
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Ресурсы на русском: https://rust-lang.ru/
Предыдущий тред: >>1880122 (OP) (OP)
>>017023
Все вакансии по крипте это кабанчиковый раж на максималках. Проработаешь максимум полгода пока кабанчик не разорится, но скорее всего заебут ещё на этапе собесов.
Все вакансии по крипте это кабанчиковый раж на максималках. Проработаешь максимум полгода пока кабанчик не разорится, но скорее всего заебут ещё на этапе собесов.
>>017147
Rust book
Rust book
>>017147
Абсолютно та же ситуация, вроде интересный язык, а читать трудно ну вообще. Может только поначалу так, хз
Абсолютно та же ситуация, вроде интересный язык, а читать трудно ну вообще. Может только поначалу так, хз
>>017148
хм, ну я вообще в мобилках варюсь последние 3 года. Посмотрел на раст, синтаксически похож на swift, только импрувнутый. Покопаю его и посмотрю по собесам. Хочется кабанчиком в норм блокчейн устроится, в near\ckb какой нибудь.
хм, ну я вообще в мобилках варюсь последние 3 года. Посмотрел на раст, синтаксически похож на swift, только импрувнутый. Покопаю его и посмотрю по собесам. Хочется кабанчиком в норм блокчейн устроится, в near\ckb какой нибудь.
Аноны, извиняюсь, что не поблагодарил в прошлый раз за ответы про дак тайпинг. Спасибо! В итоге понял, что общие интерфейсы к разным крейтам по-человечески сделать не получится, и лучше не выёбываться и писать для них trait/impl trait адаптеры в самом приложении.
Теперь более общий вопрос: а как у нас вообще принято проектировать приложения?
В плюсах я писал от общего к частному: есть корневой класс, создаваемый main-ом и живущий до самого выхода, в нём были классы на отдельные подсистемы, каждый из них имел обратную ссылку на объект корневого класса. Допустим, если методу гуя надо написать в лог, он через эту ссылку идёт и вызывает логгер. То есть, все зависимости вложенных классов хранятся в родительском.
В ржавом же получается, что я так сделать не могу? Если я положу в struct ссылку &mut на объект то пока она есть, никто другой им пользоваться не сможет. Что тогда делать - передавать все зависимости в аргументах методов? Склоняюсь к созданию временного дублирующего struct-a, в котором только нужные зависимости: методы пишутся к нему, а исходный объект передается по ссылке в методы. Но я как бы собой не очень горд за это - получилось не как хотелось, а как получилось.
Теперь более общий вопрос: а как у нас вообще принято проектировать приложения?
В плюсах я писал от общего к частному: есть корневой класс, создаваемый main-ом и живущий до самого выхода, в нём были классы на отдельные подсистемы, каждый из них имел обратную ссылку на объект корневого класса. Допустим, если методу гуя надо написать в лог, он через эту ссылку идёт и вызывает логгер. То есть, все зависимости вложенных классов хранятся в родительском.
В ржавом же получается, что я так сделать не могу? Если я положу в struct ссылку &mut на объект то пока она есть, никто другой им пользоваться не сможет. Что тогда делать - передавать все зависимости в аргументах методов? Склоняюсь к созданию временного дублирующего struct-a, в котором только нужные зависимости: методы пишутся к нему, а исходный объект передается по ссылке в методы. Но я как бы собой не очень горд за это - получилось не как хотелось, а как получилось.
>>018191
Извиняюсь, затупил. Не важно, куда писать методы, главный вопрос - зависимости каждому методу придется передавать заново?
Извиняюсь, затупил. Не важно, куда писать методы, главный вопрос - зависимости каждому методу придется передавать заново?
Аноны можно ли вкатится в раст не зная плюсов ? То есть это будет вкат сверху вниз из жса. Опасаюсь, что на расте книг хуй да нихуя, и это просто знакомство с синтаксисом для опытных прогеров на плюсах и джаве. Как раст с нуля идет ?
>>018946
нет, не надо. Вкатись лучше в плюсы, и если тебе не будет хватать их(или заебёт) тогда изучай раст. Ты если из ЖСа пойдешь в раст ты не поймешь фичей раста
нет, не надо. Вкатись лучше в плюсы, и если тебе не будет хватать их(или заебёт) тогда изучай раст. Ты если из ЖСа пойдешь в раст ты не поймешь фичей раста
>>018946
Вкатиться можно, но 1) это системный язык, придется изучать байтоёбство и 2) чтобы не вляпаться в ошибки плюсов, он заставляет сразу писать строгий и корректный код, поэтому после хуяк-хуяк будет культурный шок и жалобы. В принципе, плюсы тоже не нужны - их учить больше года, и если хочешь именно системное программирование, учи сишечку. Там уже решишь, стоит дальше развивать эту тему или нет.
Вкатиться можно, но 1) это системный язык, придется изучать байтоёбство и 2) чтобы не вляпаться в ошибки плюсов, он заставляет сразу писать строгий и корректный код, поэтому после хуяк-хуяк будет культурный шок и жалобы. В принципе, плюсы тоже не нужны - их учить больше года, и если хочешь именно системное программирование, учи сишечку. Там уже решишь, стоит дальше развивать эту тему или нет.
>>019689
Не нужно учить на будущее. когда нужно будет - пригодиться.
Раст сейчас стоит учить ради работки на крипте. Остальное предоставь низшим по развитию людям, имхо.
Лучше найди себе хобби, чем учить то, что находится за рамками твоей рабочей специальности (фронта)
Не нужно учить на будущее. когда нужно будет - пригодиться.
Раст сейчас стоит учить ради работки на крипте. Остальное предоставь низшим по развитию людям, имхо.
Лучше найди себе хобби, чем учить то, что находится за рамками твоей рабочей специальности (фронта)
>>022900
Проста
Проста
>>018201
Приведи пример. Пока что звучит все странно. Если это разделяемый объект то очевидно, нельзя мутабельную ссылку раздавать всем подряд. То, что в C++ можно - это не значит, что это правильно или так надо.
>Если я положу в struct ссылку &mut на объект то пока она есть, никто другой им пользоваться не сможет. Что тогда делать - передавать все зависимости в аргументах методов?
Приведи пример. Пока что звучит все странно. Если это разделяемый объект то очевидно, нельзя мутабельную ссылку раздавать всем подряд. То, что в C++ можно - это не значит, что это правильно или так надо.
>>017017 (OP)
Ржавые, я вот реально не понимаю вот это, объясните мне
С какого хуя избавившись от ошибок работы с памятью должна хоть сколько-нибудь вырасти надёжность конечного результата?
Первый пример. Берём огромный список проектов на гитхабе - awesome-rust. Начинаем открывать все подряд. И наблюдаем странную "надёжность" - в issue десятки активных багов. Примерно как в проектах с таким же количеством звёзд на крестах.
Или личный опыт. Берём рандомную либу с малым количеством звёзд или заброшенную больше года назад и получаем дикий пердолинг уровня крестов. Результат такой, что пиздец.
Я вот сразу вижу первый пиздеж:
Это наглый пиздёж. Фактически я вижу "надёжное программное обеспечение" только от реально прошаренных кодеров. Из-за высокой сложности языка получаем от "каждого" пиздец уровня крестов или даже хуже.
Возникают вопросы. Зачем это говно нужно? Работать? Так работу не найдёшь. Для себя? Опенсорс в жопе с кучей неподдерживаемого кода с 2018-1019 года, высокая сложность изучения, вечные баги от "каждых". Сомнительное удовольствие. Единственный профит видится для кучки прошаренных кодеров, чтоб остатки багов от дырявой памяти прикрыть.
Так вот объясните мне что за религия вокруг ржавой "надёжности", если по факту для вкатывальщика с какого-нибудь go получаем только сплошную боль и пердолинг, мало отличающийся от подобного в крестах, при этом имея надежность хуже самого go? Да даже с сишки на линуксе не вижу профитов перекатываться в раст.
Ржавые, я вот реально не понимаю вот это, объясните мне
> позволяющий каждому создавать надёжное программное обеспечение
С какого хуя избавившись от ошибок работы с памятью должна хоть сколько-нибудь вырасти надёжность конечного результата?
Первый пример. Берём огромный список проектов на гитхабе - awesome-rust. Начинаем открывать все подряд. И наблюдаем странную "надёжность" - в issue десятки активных багов. Примерно как в проектах с таким же количеством звёзд на крестах.
Или личный опыт. Берём рандомную либу с малым количеством звёзд или заброшенную больше года назад и получаем дикий пердолинг уровня крестов. Результат такой, что пиздец.
Я вот сразу вижу первый пиздеж:
> позволяющий каждому
Это наглый пиздёж. Фактически я вижу "надёжное программное обеспечение" только от реально прошаренных кодеров. Из-за высокой сложности языка получаем от "каждого" пиздец уровня крестов или даже хуже.
Возникают вопросы. Зачем это говно нужно? Работать? Так работу не найдёшь. Для себя? Опенсорс в жопе с кучей неподдерживаемого кода с 2018-1019 года, высокая сложность изучения, вечные баги от "каждых". Сомнительное удовольствие. Единственный профит видится для кучки прошаренных кодеров, чтоб остатки багов от дырявой памяти прикрыть.
Так вот объясните мне что за религия вокруг ржавой "надёжности", если по факту для вкатывальщика с какого-нибудь go получаем только сплошную боль и пердолинг, мало отличающийся от подобного в крестах, при этом имея надежность хуже самого go? Да даже с сишки на линуксе не вижу профитов перекатываться в раст.
>>026136
На расте блокчейн говно сейчас во всю пилят. Только ради этого и стоит выучить это говно.
А так ну хз, имхо новые языки не сильно нужны, потому что кроме как синтаксическим сахаром они ничем толком не отличаются от проверенных годами инструментов
На расте блокчейн говно сейчас во всю пилят. Только ради этого и стоит выучить это говно.
А так ну хз, имхо новые языки не сильно нужны, потому что кроме как синтаксическим сахаром они ничем толком не отличаются от проверенных годами инструментов
>>026221
Блокчеин рынок вообще жив еще ? какие перспективы у этого дерьма в ближайшие 5 лет ? Смотрел вакансии, в рф полторы штуки, остальные за бугром.
>блокчейн
Блокчеин рынок вообще жив еще ? какие перспективы у этого дерьма в ближайшие 5 лет ? Смотрел вакансии, в рф полторы штуки, остальные за бугром.
>>018191
Пока не завезут GAT [1] и TAIT [2] использовать трейты как аналог интерфейсов например из той же жавы будет очень хуёво.
Если приложение однопоточное, то для этого используется RefCell [2] или UnsafeCell [3], если многопоточное то мютекс. В таком случае можно передавать простую ссылку в дочерние классы и преобразовывать её для записи при необходимости.
В расте для этого используются синглтоны. Либо глобальный, либо в TLS (thread local storage): [4]. Запихивать в каждый класс свой логгер (как делают в некоторых яп) нет необходимости, потому что благодаря мощным макросам логгеру сразу передаётся в каком модуле/файле (и даже на какой строке) был вызван лог.
[1]: https://github.com/rust-lang/rust/issues/44265
[2]: https://github.com/rust-lang/rust/issues/63063
[2]: https://doc.rust-lang.org/std/cell/struct.RefCell.html
[3]: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html
[4]: https://docs.rs/tracing/0.1.26/tracing/#in-executables
> В итоге понял, что общие интерфейсы к разным крейтам по-человечески сделать не получится
Пока не завезут GAT [1] и TAIT [2] использовать трейты как аналог интерфейсов например из той же жавы будет очень хуёво.
> Если я положу в struct ссылку &mut на объект то пока она есть, никто другой им пользоваться не сможет.
Если приложение однопоточное, то для этого используется RefCell [2] или UnsafeCell [3], если многопоточное то мютекс. В таком случае можно передавать простую ссылку в дочерние классы и преобразовывать её для записи при необходимости.
> Допустим, если методу гуя надо написать в лог
В расте для этого используются синглтоны. Либо глобальный, либо в TLS (thread local storage): [4]. Запихивать в каждый класс свой логгер (как делают в некоторых яп) нет необходимости, потому что благодаря мощным макросам логгеру сразу передаётся в каком модуле/файле (и даже на какой строке) был вызван лог.
[1]: https://github.com/rust-lang/rust/issues/44265
[2]: https://github.com/rust-lang/rust/issues/63063
[2]: https://doc.rust-lang.org/std/cell/struct.RefCell.html
[3]: https://doc.rust-lang.org/std/cell/struct.UnsafeCell.html
[4]: https://docs.rs/tracing/0.1.26/tracing/#in-executables
>>026787
Проебался с нумерацией ссылок, лол.
Проебался с нумерацией ссылок, лол.
Дарова, аноны. Я хочу чтобы моя программа писала в файл,
хеш-сумма и потом имя файла. На данный момент пишет имя файла и затем хеш-сумма.
Код https://pastebin.com/VmecKmkS
хеш-сумма и потом имя файла. На данный момент пишет имя файла и затем хеш-сумма.
Код https://pastebin.com/VmecKmkS
>>027010
Нихера не вижу в каком месте ты что-то куда-то пишешь, (кроме ошибок симлинка), так что ты тупо не тот код скинул. Очевидно, что смотреть надо в том месте, в котором ты пишешь что-то в файл, а не алгоритмы твои ебаные.
Нихера не вижу в каком месте ты что-то куда-то пишешь, (кроме ошибок симлинка), так что ты тупо не тот код скинул. Очевидно, что смотреть надо в том месте, в котором ты пишешь что-то в файл, а не алгоритмы твои ебаные.
>>026520
Обфускатор на раст не нужен. Если ты знаешь раст, то тебе поебать на обфускатор, а если ты не знаешь раст, то ты в жизни не распарсишь какой-нибудь
unsafe fn bar<'a, 'b: 'a, T: 'a, U: 'b>(t: T) -> U { transmute(t) }
Обфускатор на раст не нужен. Если ты знаешь раст, то тебе поебать на обфускатор, а если ты не знаешь раст, то ты в жизни не распарсишь какой-нибудь
unsafe fn bar<'a, 'b: 'a, T: 'a, U: 'b>(t: T) -> U { transmute(t) }
>>017017 (OP)
Почему растом так активно увлекаются геи и трапы?
Почему растом так активно увлекаются геи и трапы?
>>027701
Может программирования не для тебя? Ты жалуешься на то, что строки в файл записываются в неправильном порядке. Но при этом даёшь код, который считывает файл и заполняет хэш-мапы. По идее ошибка будет в в коде, который непосредственно записывает в файл.
Может программирования не для тебя? Ты жалуешься на то, что строки в файл записываются в неправильном порядке. Но при этом даёшь код, который считывает файл и заполняет хэш-мапы. По идее ошибка будет в в коде, который непосредственно записывает в файл.
>>024367
Знаю про pyo3, плюс есть ещё rust-cpython, которые, вроде как, параллельно пилят.
Было интересно, писал ли модули для пайтона кто-нибудь.
Знаю про pyo3, плюс есть ещё rust-cpython, которые, вроде как, параллельно пилят.
Было интересно, писал ли модули для пайтона кто-нибудь.
>>026348
лол
лол
Недавно вкатился в растобляди по работе. Мой сервис в main.rs разросся до того состояния, что пора его дробить на сорцы поменьше. Но как? Папочка с mod.rs и требухой? Или как? В растбуке эта тема как-то объяснена уклончиво "ну у нас есть модели, можешь навертеть как душе угодно". А со вложенностью непонятно. Посмотрел разные проекты, везде всё по разному, не понятно, как лучше и правильнее.
мимо пишу на питохоне в основном
мимо пишу на питохоне в основном
218 Кб, 2180x1452>>029971
В расте (речь про 2018+ эдишн) есть два способа создать модули.
Первый - создать файл рядом с main.rs, например module1.rs. Теперь этот файл и будет модулем module1. В мейне ты его объявляешь как модуль, т.е. пишешь mod module1; а затем импортируешь оттуда что надо use module1::*;
Второй - создать каталог module1 и там внутри создать mod.rs, который и будет модулем с названием каталога. Как и в первом случае теперь в мейне надо объявить новый модуль mod module1; и можно оттуда импортировать что надо.
Вложенные модули делаются точно так же. Только есть один ньюанс - можно сам модуль объявлять как приватный (по-умолчанию) либо как публичный - pub mod inner_module; В случае публичного объявления тогда все кто используют внешний модуль будут иметь доступ и ко внутреннему.
Какой способ использовать - первый или второй решай сам. Некоторые считают, что первый способ более идиоматичный, но на самом деле это вкусовщина. Только не использую оба способа в одном проекте (выбери один) и всё будет нормально. Вот пикрил как пример. Модули с суффиксом _a созданы первым способом, с суффиксом _b - вторым.
В расте (речь про 2018+ эдишн) есть два способа создать модули.
Первый - создать файл рядом с main.rs, например module1.rs. Теперь этот файл и будет модулем module1. В мейне ты его объявляешь как модуль, т.е. пишешь mod module1; а затем импортируешь оттуда что надо use module1::*;
Второй - создать каталог module1 и там внутри создать mod.rs, который и будет модулем с названием каталога. Как и в первом случае теперь в мейне надо объявить новый модуль mod module1; и можно оттуда импортировать что надо.
Вложенные модули делаются точно так же. Только есть один ньюанс - можно сам модуль объявлять как приватный (по-умолчанию) либо как публичный - pub mod inner_module; В случае публичного объявления тогда все кто используют внешний модуль будут иметь доступ и ко внутреннему.
Какой способ использовать - первый или второй решай сам. Некоторые считают, что первый способ более идиоматичный, но на самом деле это вкусовщина. Только не использую оба способа в одном проекте (выбери один) и всё будет нормально. Вот пикрил как пример. Модули с суффиксом _a созданы первым способом, с суффиксом _b - вторым.
>>029985
Возьму первый способ, он проще выглядит на мой взгляд.
Если использовать первый вариант для вложенных модулей, то в случае если у меня такая структура:
- module1
-- module2
--- utils2.rs
-- utils.rs
- main.rs
То импорты вложенного будут такими:
mod module1;
use module1::module2;
use module1::utils;
?
Возьму первый способ, он проще выглядит на мой взгляд.
Если использовать первый вариант для вложенных модулей, то в случае если у меня такая структура:
- module1
-- module2
--- utils2.rs
-- utils.rs
- main.rs
То импорты вложенного будут такими:
mod module1;
use module1::module2;
use module1::utils;
?
>>029985
В любом случае, спасибо, хорошо объяснил
В любом случае, спасибо, хорошо объяснил
>>029995
Да. Только не забывай создавать сами файлы модулей module1.rs и module2.rs и там объявлять вложенные модули. Раст ориентируется по объявлениям модулей внутри файлов, а не по структуре файлов в проекте в отличии от других яп.
Да. Только не забывай создавать сами файлы модулей module1.rs и module2.rs и там объявлять вложенные модули. Раст ориентируется по объявлениям модулей внутри файлов, а не по структуре файлов в проекте в отличии от других яп.
>>017147
Так же херня. Сначало хелоу ворлд и все минималистично. А потом пиздец начинается какой то.
Так же херня. Сначало хелоу ворлд и все минималистично. А потом пиздец начинается какой то.
>>027354
про геев не знаю, но про трапов действительно смешно, нигде такой концентрации нет
про геев не знаю, но про трапов действительно смешно, нигде такой концентрации нет
>>031660
Помянем
Помянем
какие языки /rust/ будет изучать, когда выпилится достаточное количество мейтейнеров, чтобы разработка языка встала? итт хочу потыкать nim
>>031706
два цикория, не стал бы с раста начинать. если хочется делать что-то реальное почти сразу, можно голанг попробовать. но так си действительно поможет какие-то фундаментальные вещи ухватить.
>>031660
но если всё же решишь ржаветь@траповать — как можно быстрее заканчивай раст бук и ебашь реальные штуки®, пусть для себя, но чтобы ты понимал что тебе нужно и как это хотя бы примерно работает. из учебников такого рода в целом можно научиться примерно ничему. поэтому если интересует какая-то теория, лучше изучай алгоритмы всякие, а язык вообще значения не имеет, на любом сможешь в короткое время начать писать.
да, о знаниях. научись пользоваться линупсовой консолью, хотя бы в том же wsl если ты виндоёб. без этого будет плохо и страшно.
два цикория, не стал бы с раста начинать. если хочется делать что-то реальное почти сразу, можно голанг попробовать. но так си действительно поможет какие-то фундаментальные вещи ухватить.
>>031660
но если всё же решишь ржаветь@траповать — как можно быстрее заканчивай раст бук и ебашь реальные штуки®, пусть для себя, но чтобы ты понимал что тебе нужно и как это хотя бы примерно работает. из учебников такого рода в целом можно научиться примерно ничему. поэтому если интересует какая-то теория, лучше изучай алгоритмы всякие, а язык вообще значения не имеет, на любом сможешь в короткое время начать писать.
да, о знаниях. научись пользоваться линупсовой консолью, хотя бы в том же wsl если ты виндоёб. без этого будет плохо и страшно.
>>031713
Я уже Линуксоид, так что привык уже.
Я уже Линуксоид, так что привык уже.
Пару дней назад расту стукнуло 6 лет с момента выхода первой стабильной версии. Пока что на расте мало важного написано. Почему же так долго хайп держится?
>>033486
Потому что язык охуенный, очевидно. Ну и анализ алиасинга на уровне языка — слишком крутая киллер фича.
Потому что язык охуенный, очевидно. Ну и анализ алиасинга на уровне языка — слишком крутая киллер фича.
bump
Почему я бросил раст? Год назад начал его изучать, но столкнулся с проблемой отсутствия документации благодаря её слишком быстрому устареванию. Натыкаешься на какую-нибудь статью или ответ на стаковерфлоу, а примеры оттуда уже не работают. Думаю, расту нужно ещё лет 10 на стабилизацию, чтобы проблем с документацией не было.
>>034176
Это да, даже не сколько у фреймворков, а у самого языка.
Это да, даже не сколько у фреймворков, а у самого языка.
>>034176
Раст был бы збс, если бы не балдёжно-молодежная организация, которая его писала.
Раст был бы збс, если бы не балдёжно-молодежная организация, которая его писала.
>>034176
документация действительно пиздец говна, особенно какие-нибудь крейты, где чтобы получить ответ приходится идти в их гиттер или матрикс или, чё там ещё, дискорд какой-нибудь.
причём сгенерированный сайтик с доками может и быть, но только кроме того что ты и сам прекрасно знаешь из LSP, ничего больше там и нет
>>034592
есть ли выход?
документация действительно пиздец говна, особенно какие-нибудь крейты, где чтобы получить ответ приходится идти в их гиттер или матрикс или, чё там ещё, дискорд какой-нибудь.
причём сгенерированный сайтик с доками может и быть, но только кроме того что ты и сам прекрасно знаешь из LSP, ничего больше там и нет
>>034592
>язык пишется большой корпорацией FAANG типа
>на выходе хуйня
>язык пишется прогрессивными ФОСС женщинами (male)
>на выходе хуйня
есть ли выход?
Почему это https://rust-lang-nursery.github.io/rust-cookbook/web/clients/requests.html гамно не компилируется?
>>036701
error[E0432]: unresolved import `error_chain`
--> src/main.rs:1:5
|
1 | use error_chain::error_chain;
| ^^^^^^^^^^^ use of undeclared crate or module `error_chain`
error: cannot determine resolution for the macro `error_chain`
--> src/main.rs:4:1
|
4 | error_chain! {
| ^^^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports
error[E0433]: failed to resolve: could not find `blocking` in `reqwest`
--> src/main.rs:12:28
|
12 | let mut res = reqwest::blocking::get("http://httpbin.org/get")?;
| ^^^^^^^^ could not find `blocking` in `reqwest`
error[E0107]: this enum takes 2 type arguments but only 1 type argument was supplied
--> src/main.rs:11:14
|
11 | fn main() -> Result<()> {
| ^^^^^^ -- supplied 1 type argument
| |
| expected 2 type arguments
|
note: enum defined here, with 2 type parameters: `T`, `E`
help: add missing type argument
|
11 | fn main() -> Result<(), E> {
| ^^^
error: aborting due to 4 previous errors
Some errors have detailed explanations: E0107, E0432, E0433.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `test`
To learn more, run the command again with --verbose.
error[E0432]: unresolved import `error_chain`
--> src/main.rs:1:5
|
1 | use error_chain::error_chain;
| ^^^^^^^^^^^ use of undeclared crate or module `error_chain`
error: cannot determine resolution for the macro `error_chain`
--> src/main.rs:4:1
|
4 | error_chain! {
| ^^^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports
error[E0433]: failed to resolve: could not find `blocking` in `reqwest`
--> src/main.rs:12:28
|
12 | let mut res = reqwest::blocking::get("http://httpbin.org/get")?;
| ^^^^^^^^ could not find `blocking` in `reqwest`
error[E0107]: this enum takes 2 type arguments but only 1 type argument was supplied
--> src/main.rs:11:14
|
11 | fn main() -> Result<()> {
| ^^^^^^ -- supplied 1 type argument
| |
| expected 2 type arguments
|
note: enum defined here, with 2 type parameters: `T`, `E`
help: add missing type argument
|
11 | fn main() -> Result<(), E> {
| ^^^
error: aborting due to 4 previous errors
Some errors have detailed explanations: E0107, E0432, E0433.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `test`
To learn more, run the command again with --verbose.
>>036701
error[E0432]: unresolved import `error_chain`
--> src/main.rs:1:5
|
1 | use error_chain::error_chain;
| ^^^^^^^^^^^ use of undeclared crate or module `error_chain`
error: cannot determine resolution for the macro `error_chain`
--> src/main.rs:4:1
|
4 | error_chain! {
| ^^^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports
error[E0433]: failed to resolve: could not find `blocking` in `reqwest`
--> src/main.rs:12:28
|
12 | let mut res = reqwest::blocking::get("http://httpbin.org/get")?;
| ^^^^^^^^ could not find `blocking` in `reqwest`
error[E0107]: this enum takes 2 type arguments but only 1 type argument was supplied
--> src/main.rs:11:14
|
11 | fn main() -> Result<()> {
| ^^^^^^ -- supplied 1 type argument
| |
| expected 2 type arguments
|
note: enum defined here, with 2 type parameters: `T`, `E`
help: add missing type argument
|
11 | fn main() -> Result<(), E> {
| ^^^
error: aborting due to 4 previous errors
Some errors have detailed explanations: E0107, E0432, E0433.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `test`
To learn more, run the command again with --verbose.
error[E0432]: unresolved import `error_chain`
--> src/main.rs:1:5
|
1 | use error_chain::error_chain;
| ^^^^^^^^^^^ use of undeclared crate or module `error_chain`
error: cannot determine resolution for the macro `error_chain`
--> src/main.rs:4:1
|
4 | error_chain! {
| ^^^^^^^^^^^
|
= note: import resolution is stuck, try simplifying macro imports
error[E0433]: failed to resolve: could not find `blocking` in `reqwest`
--> src/main.rs:12:28
|
12 | let mut res = reqwest::blocking::get("http://httpbin.org/get")?;
| ^^^^^^^^ could not find `blocking` in `reqwest`
error[E0107]: this enum takes 2 type arguments but only 1 type argument was supplied
--> src/main.rs:11:14
|
11 | fn main() -> Result<()> {
| ^^^^^^ -- supplied 1 type argument
| |
| expected 2 type arguments
|
note: enum defined here, with 2 type parameters: `T`, `E`
help: add missing type argument
|
11 | fn main() -> Result<(), E> {
| ^^^
error: aborting due to 4 previous errors
Some errors have detailed explanations: E0107, E0432, E0433.
For more information about an error, try `rustc --explain E0107`.
error: could not compile `test`
To learn more, run the command again with --verbose.
Или вот https://rust-lang-nursery.github.io/rust-cookbook/web/clients/download.html
НАХУЯ делать примеры, если это говно не может скомпилироваться?
НАХУЯ делать примеры, если это говно не может скомпилироваться?
>async fn main() -> Result<()> {
> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `main` function is not allowed to be `async`
>>037137
Мозг включаешь, очевидно, в отличие от стонущей макаки.
Мозг включаешь, очевидно, в отличие от стонущей макаки.
>>038470
Чел...
Графические приложения можно делать на любом языке при наличии соответствующих библиотек.
https://www.areweguiyet.com/
Чел...
Графические приложения можно делать на любом языке при наличии соответствующих библиотек.
https://www.areweguiyet.com/
(Как же ржавенький спасают макросы, а! Напишите «Спасибо Дэйв Херман» в этот тред и вас возьмут на ржавую галеру уже завтра)
>>038966
Код-то покажи.
>>038966
Код-то покажи.
>>039117
Ну так процедурные макросы по сути это кодогенерация, встроенная в язык. Можно даже писать вместо растокода с++ код и компилировать его внутри макросов. https://github.com/mystor/rust-cpp
> Как же ржавенький спасают макросы, а!
Ну так процедурные макросы по сути это кодогенерация, встроенная в язык. Можно даже писать вместо растокода с++ код и компилировать его внутри макросов. https://github.com/mystor/rust-cpp
18 Кб, 390x155>>039117
Что показать? Вот же, ide мне в одном и том же хинте пишет, что тип не задан, и тут же ниже показывает выведенный тип.
Конкретно тут, res выведен правильно из возвращаемого типа функции, в конце я его как Ok(res) отдаю.
Ещё бывает наоборот, как на этом пике: анализатор пиздит на Moved Value, но всё прекрасно конпелируется.
Что показать? Вот же, ide мне в одном и том же хинте пишет, что тип не задан, и тут же ниже показывает выведенный тип.
Конкретно тут, res выведен правильно из возвращаемого типа функции, в конце я его как Ok(res) отдаю.
Ещё бывает наоборот, как на этом пике: анализатор пиздит на Moved Value, но всё прекрасно конпелируется.
>>036708
Оттуда примеры и не будут компилироваться, это же не golang. В 90% примеры даже из readme на гитхабе не работают. Я хз зачем так делают, возможно потому что раста-кодеры заднеприводные извращенцы, а может по другой какой-то причине.
>НАХУЯ делать примеры, если это говно не может скомпилироваться?
Оттуда примеры и не будут компилироваться, это же не golang. В 90% примеры даже из readme на гитхабе не работают. Я хз зачем так делают, возможно потому что раста-кодеры заднеприводные извращенцы, а может по другой какой-то причине.
>>039406 (Del)
Плюс токсичное русскоязычное комьюнити.
Плюс токсичное русскоязычное комьюнити.
>>038950
Так мне и в треде по Go говорили, но по факту ни одна из этих библиотек не работала. А без написания современных графических приложений, никто не будет воспринимать язык всерьёз.
Так мне и в треде по Go говорили, но по факту ни одна из этих библиотек не работала. А без написания современных графических приложений, никто не будет воспринимать язык всерьёз.
>>039408
Напиши библиотеку, напиши ось. Ты ещё и в плюсотреде срёшь?
Напиши библиотеку, напиши ось. Ты ещё и в плюсотреде срёшь?
>>039201
Так проблема не в компиляторе, а в артефактах прошлой подсветки. Иди в виме код пиши, там проблем таких нет, а если есть, они решаются простым :e
Так проблема не в компиляторе, а в артефактах прошлой подсветки. Иди в виме код пиши, там проблем таких нет, а если есть, они решаются простым :e
>>039632
use super::*
use super::*
>>039612
Нет, эта хуйня давно держится, прошло уже несколько переоткрытий иде и очисток кеша.
Нет, эта хуйня давно держится, прошло уже несколько переоткрытий иде и очисток кеша.
>>039632
Никак, потому что x не pub
Никак, потому что x не pub
>>039632
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=852cbe396882ec4c43402a2219e60a43
Есть два варианта, оба я там нарисовал.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=852cbe396882ec4c43402a2219e60a43
Есть два варианта, оба я там нарисовал.
>>039994
Ты каким плагином пользуешься? Давно обновлял?
Ты каким плагином пользуешься? Давно обновлял?
Хочу написать базу данных на расте, для практики. До этого никогда с таким не сталкивался, писал только энтерпрайз-парашу на джаве. Какие подводные?
>>040606
Что такое энтерпрайз?
Что такое энтерпрайз?
>>040606
Никаких, пиши
Максимум что может быть, жопа сгорит от семантики владения и компилятора в целом
Никаких, пиши
Максимум что может быть, жопа сгорит от семантики владения и компилятора в целом
>>040606
Не осилишь.
Не осилишь.
>>040957
После жавы жопа скорее сгорит от неполноценности трейтов. GAT и TAIT очень сильно не хватает когда используешь трейты как аналог интерфейсов из жавы.
После жавы жопа скорее сгорит от неполноценности трейтов. GAT и TAIT очень сильно не хватает когда используешь трейты как аналог интерфейсов из жавы.
Скомпилировал хелло ворлд, а бинарник получился 3,4Мбайта. Это нормально вообще?
>>041493
Это же очень много! На том же С++ получается 14-16кбайт всего с учетом стандартных библиотек.
Это же очень много! На том же С++ получается 14-16кбайт всего с учетом стандартных библиотек.
>>041680
Разве раст не линкует glibc динамически? Даже так выходит около 4МБ, после стрипа 1МБ.
Разве раст не линкует glibc динамически? Даже так выходит около 4МБ, после стрипа 1МБ.
>>041757
Нет, раст в отличие от сишки и крестов по дефолту всё статически линкует. Найди, где у крестов настройка статической линковки, а потом охуевай от реального размера бинарников.
Ах да, и не забудь про разницу размеров в дебаге и релизе.
Нет, раст в отличие от сишки и крестов по дефолту всё статически линкует. Найди, где у крестов настройка статической линковки, а потом охуевай от реального размера бинарников.
Ах да, и не забудь про разницу размеров в дебаге и релизе.
>>042140
https://redbeardlab.com/2019/05/07/rust-and-glibc-version/
Это тогда что?
Похожее написано здесь
https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html
В любом случае бинарник линкуется к сишной либе динамически.
Релизная версия может весить больше.
У меня размер получился в несколько раз меньше чем размер плюсового бинаря, но с жму тулчейном бинарь линковался динамически.
https://pastebin.com/6hid7kJ9
https://redbeardlab.com/2019/05/07/rust-and-glibc-version/
>The rust compiler dynamically link the executable against the glibc in the system
Это тогда что?
Похожее написано здесь
https://doc.rust-lang.org/edition-guide/rust-2018/platform-and-target-support/musl-support-for-fully-static-binaries.html
>However, if you use the standard library, it will dynamically link to the system's libc implementation
В любом случае бинарник линкуется к сишной либе динамически.
>Найди, где у крестов настройка статической линковки
>не забудь про разницу размеров в дебаге и релизе
Релизная версия может весить больше.
У меня размер получился в несколько раз меньше чем размер плюсового бинаря, но с жму тулчейном бинарь линковался динамически.
https://pastebin.com/6hid7kJ9
>>041230
Аноний, добавь в cargo.toml такое:
[profile.release]
lto = true
Получишь 1.2мб с отладочной информацией, 250кб без, и ощутимо возросшее время линковки. 12-14кб тоже можно, если откажешься от стандартной библиотеки и будешь работать через биндинги к libc. 4-8кб, если используешь системные вызовы напрямую (кстати, турбо паскаль от 1989 года под дос не мог без мэдскиллз делать бинарники меньше 7кб). По сравнению с крестами, код раздувается в основном за счёт всяких проверок - на переполнения, на выход за границы массива. И ещё ему приходится тащить с собой свою стандартную библиотеку, конечно.
Аноний, добавь в cargo.toml такое:
[profile.release]
lto = true
Получишь 1.2мб с отладочной информацией, 250кб без, и ощутимо возросшее время линковки. 12-14кб тоже можно, если откажешься от стандартной библиотеки и будешь работать через биндинги к libc. 4-8кб, если используешь системные вызовы напрямую (кстати, турбо паскаль от 1989 года под дос не мог без мэдскиллз делать бинарники меньше 7кб). По сравнению с крестами, код раздувается в основном за счёт всяких проверок - на переполнения, на выход за границы массива. И ещё ему приходится тащить с собой свою стандартную библиотеку, конечно.
>>041166
Расскажи, пожалуйста, что за GAT и TAIT, не гуглятся эти аббревиатуры. А жопа моя дымится сейчас от трудностей байтоёбства: чтобы банально прочитать слово из v: Vec<u8>, приходится делать from_le_bytes(v[i..i+3]).try_into().unwrap(), не говоря уже о битовых массивах, и я уже ностальгирую по сишечке. Мелочи типа того что i16(-1) as u32 даёт 0xffffffff тоже неприятно удиваляют. А борроу-чекер - да, хуй с ним, RefCell во все поля (буквально).
Расскажи, пожалуйста, что за GAT и TAIT, не гуглятся эти аббревиатуры. А жопа моя дымится сейчас от трудностей байтоёбства: чтобы банально прочитать слово из v: Vec<u8>, приходится делать from_le_bytes(v[i..i+3]).try_into().unwrap(), не говоря уже о битовых массивах, и я уже ностальгирую по сишечке. Мелочи типа того что i16(-1) as u32 даёт 0xffffffff тоже неприятно удиваляют. А борроу-чекер - да, хуй с ним, RefCell во все поля (буквально).
Хотел что-то спросить, потом глянул - а хуле тут спрашивать? Давайте лучше я вам советы подам.
1. Чекнуть по-быстрому и увидеть только ошибки, без километров ворнингов:
RUSTFLAGS=-Awarnings cargo check
2. Собрать с пересборкой std (может сильно сократить размер)
rustup override set nightly; cargo build -Z build-std --target x86_64-unknown-linux-gnu --release; rustup override set stable
3. Развернуть Option<Option<T>> в Option<T>: flatten()
4. Развернуть Option<E>, Option<T> в Option<(T,E)>: zip()
макака, чини разметку
1. Чекнуть по-быстрому и увидеть только ошибки, без километров ворнингов:
RUSTFLAGS=-Awarnings cargo check
2. Собрать с пересборкой std (может сильно сократить размер)
rustup override set nightly; cargo build -Z build-std --target x86_64-unknown-linux-gnu --release; rustup override set stable
3. Развернуть Option<Option<T>> в Option<T>: flatten()
4. Развернуть Option<E>, Option<T> в Option<(T,E)>: zip()
макака, чини разметку
>>043306
Если не используешь многопоток и связные списки с деревьями, то правила очень простые:
Если объект живёт дольше, чем функция, то можно передавать его по & куда угодно.
Если функция завершается и что-то возвращает, то не очкуй вернуть объект целиком. Никакого перемещения памяти не будет, будет та же передача по ссылке, только во владение
Если знаешь свой ендиан и число байт точно чётное, то можешь через ансейф преобразовать Vec<u8> в Vec<u16>
>RefCell во все поля
Если не используешь многопоток и связные списки с деревьями, то правила очень простые:
Если объект живёт дольше, чем функция, то можно передавать его по & куда угодно.
Если функция завершается и что-то возвращает, то не очкуй вернуть объект целиком. Никакого перемещения памяти не будет, будет та же передача по ссылке, только во владение
>from_le_bytes
Если знаешь свой ендиан и число байт точно чётное, то можешь через ансейф преобразовать Vec<u8> в Vec<u16>
>>043306
GAT - generic associated types - https://github.com/rust-lang/rust/issues/44265
TAIT - type alias impl trait - https://github.com/rust-lang/rust/issues/63063
Вот пример для чего они нужны, чтобы иммитировать интерфейсы в жаве. Допустим у тебя есть интерфейсы.
public interface i1 {}
public interface i2 {
i1 getI1();
}
и их имплементации
public class i1Impl implements i1 {}
public class i2Impl implements i2 {
@Override
public i1 getI1() {
return new i1Impl();
}
}
Обрати внимание, что в интерфейсе i2 возвращается интерфейс i1, а не конкретный тип. Это очень распространённая идиома в жаве - использовать конкретные типы по-минимуму и совать где только можно интерфейсы. Вот аналог этого кода в расте: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=33fa415859772b050b8a8800c15ef2d7 в данном случае конечно можно не использовать TAIT и просто написать type getI1Rv = i1Impl; но иногда так сделать невозможно (например если внутри вызывается функция, которая сама возвращает impl i1. GAT нужны для того чтобы можно было использовать генерики и лайфтаймы в определениях типов в интерфейсах. Вот пример выше с использованием GAT: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9740f54884bbf844039191d5003bc64a
Но как ты мог заметить, как GAT, так и TAIT в моих примерах используются как костыли и на самом деле нужны RPIT - return position impl trait внутри трейтов, чтобы тупо можно было написать fn getI1<'a, T: 'a>(&self) -> impl i1<'a, T>; внутри трейта, как это сейчас возможно в свободных функциях. Возможно позже добавят и такую возможность. Плюс это является необходимостью для использования асинхронных функций в трейтах.
Сейчас обычно эти ограничения обходят боксингом, т.е. последний пример выходит так: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e0cec01ee4401c81867c71bc17017a3a но так получается медленней и иногда потребляет больше памяти.
GAT - generic associated types - https://github.com/rust-lang/rust/issues/44265
TAIT - type alias impl trait - https://github.com/rust-lang/rust/issues/63063
Вот пример для чего они нужны, чтобы иммитировать интерфейсы в жаве. Допустим у тебя есть интерфейсы.
public interface i1 {}
public interface i2 {
i1 getI1();
}
и их имплементации
public class i1Impl implements i1 {}
public class i2Impl implements i2 {
@Override
public i1 getI1() {
return new i1Impl();
}
}
Обрати внимание, что в интерфейсе i2 возвращается интерфейс i1, а не конкретный тип. Это очень распространённая идиома в жаве - использовать конкретные типы по-минимуму и совать где только можно интерфейсы. Вот аналог этого кода в расте: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=33fa415859772b050b8a8800c15ef2d7 в данном случае конечно можно не использовать TAIT и просто написать type getI1Rv = i1Impl; но иногда так сделать невозможно (например если внутри вызывается функция, которая сама возвращает impl i1. GAT нужны для того чтобы можно было использовать генерики и лайфтаймы в определениях типов в интерфейсах. Вот пример выше с использованием GAT: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=9740f54884bbf844039191d5003bc64a
Но как ты мог заметить, как GAT, так и TAIT в моих примерах используются как костыли и на самом деле нужны RPIT - return position impl trait внутри трейтов, чтобы тупо можно было написать fn getI1<'a, T: 'a>(&self) -> impl i1<'a, T>; внутри трейта, как это сейчас возможно в свободных функциях. Возможно позже добавят и такую возможность. Плюс это является необходимостью для использования асинхронных функций в трейтах.
Сейчас обычно эти ограничения обходят боксингом, т.е. последний пример выходит так: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e0cec01ee4401c81867c71bc17017a3a но так получается медленней и иногда потребляет больше памяти.
>>043453
Да у меня практически классический пример: объект через интерфейс в виде трейта обращается к другому объекту. А трейт - вот уж случайность - оказывается родительским объектом. Всё.
Вот конкретно этот пример с изменением типа массивов - один из самых больших пиздецов языка. Сишечка во всём небезопасная, конечно, но в ней байтоёбство естественное. В Расте же это - как деревенская пьянь, показывающая акробатический трюк.
> Если не используешь многопоток и связные списки с деревьями, то правила очень простые
Да у меня практически классический пример: объект через интерфейс в виде трейта обращается к другому объекту. А трейт - вот уж случайность - оказывается родительским объектом. Всё.
> Если знаешь свой ендиан и число байт точно чётное, то можешь через ансейф преобразовать Vec<u8> в Vec<u16>
Вот конкретно этот пример с изменением типа массивов - один из самых больших пиздецов языка. Сишечка во всём небезопасная, конечно, но в ней байтоёбство естественное. В Расте же это - как деревенская пьянь, показывающая акробатический трюк.
>>043460
Спасибо за разъяснения. Не стыжусь признаться, что часть про лайфтаймы понимаю смутно, но заскринил и скурю, как сам начну писать обобщённый код.
Спасибо за разъяснения. Не стыжусь признаться, что часть про лайфтаймы понимаю смутно, но заскринил и скурю, как сам начну писать обобщённый код.
>>043967
Объект трейта, конечно. Извиняюсь.
Объект трейта, конечно. Извиняюсь.
>>043967
Ни хуя не понял, кто у тебя там к кому обращается. Дочерний объект зовёт метод родительского? Меняй архитектуру, если так. Используй каналы, асинхронность, ещё что-нибудь.
Крайне редко бывает, чтобы что-то подобное было вот ну прям необходимым, хотя в мире плюсов встречается сплошь и рядом. У тебя там, поди, коллбэк какой-нибудь?
Ни хуя не понял, кто у тебя там к кому обращается. Дочерний объект зовёт метод родительского? Меняй архитектуру, если так. Используй каналы, асинхронность, ещё что-нибудь.
Крайне редко бывает, чтобы что-то подобное было вот ну прям необходимым, хотя в мире плюсов встречается сплошь и рядом. У тебя там, поди, коллбэк какой-нибудь?
>>044113
Да, зовёт, чтобы получить нужное поле. Нет, всё збс, поле сделано как RefCell и не требует мутабельности родительского класса. Нужно это для более удобной организации кода: получение полей делается через dyn trait и им можно подставить или класс приложения, или класс тестраннера. Приложение импортирует все классы своих полей, классы полей - только классы соседей в месте с трейтами для их получения. Идиллия. Всё вместе это - зародыш движка игровой логики.
Да, зовёт, чтобы получить нужное поле. Нет, всё збс, поле сделано как RefCell и не требует мутабельности родительского класса. Нужно это для более удобной организации кода: получение полей делается через dyn trait и им можно подставить или класс приложения, или класс тестраннера. Приложение импортирует все классы своих полей, классы полей - только классы соседей в месте с трейтами для их получения. Идиллия. Всё вместе это - зародыш движка игровой логики.
>>044152
Нет, блять, просто нет, сука, давно умные люди придумали ECS, никто даже в крестах не пишет на ебаных классах твои ебаные игры.
Просто нет, блять, игры так не делаются.
Но если очень надо взять референс из внутренней структуры на внешнюю, то смотри std::rc::Weak или std::sync::Weak. Но тебе не надо, тебе надо просто научиться использовать правильные алгоритмы и правильно структурировать программы под задачу.
>Всё вместе это - зародыш движка игровой логики
Нет, блять, просто нет, сука, давно умные люди придумали ECS, никто даже в крестах не пишет на ебаных классах твои ебаные игры.
Просто нет, блять, игры так не делаются.
Но если очень надо взять референс из внутренней структуры на внешнюю, то смотри std::rc::Weak или std::sync::Weak. Но тебе не надо, тебе надо просто научиться использовать правильные алгоритмы и правильно структурировать программы под задачу.
Вот изучаю Rust и не могу понять: зачем они сделали все переменные константами? В чём смысл этого? Программа создаётся, чтобы преобразовывать данные, а значит переменные должны изменяться.
Такое ощущение, что разработчики руководствовались одноклеточной логикой с позиции каких-нибудь анализаторов кода: типа если большинство ошибок возникает из-за изменений переменной, то надо запретить изменять переменные.
Такое ощущение, что разработчики руководствовались одноклеточной логикой с позиции каких-нибудь анализаторов кода: типа если большинство ошибок возникает из-за изменений переменной, то надо запретить изменять переменные.
>>046207
Ты перепутал раст с хачкелем, у нас мутабельность есть, а вот алиасинга нет.
Ты перепутал раст с хачкелем, у нас мутабельность есть, а вот алиасинга нет.
>>046207
Пчел, концепция вредоносности мутабельности по умолчанию это уже признанный стандарт — найди хоть один новый язык кроме gовна, где это не так.
Пчел, концепция вредоносности мутабельности по умолчанию это уже признанный стандарт — найди хоть один новый язык кроме gовна, где это не так.
>>046207
Алсо, как иммутабельность по умолчанию тебе мешает преобразовывать данные?
Алсо, как иммутабельность по умолчанию тебе мешает преобразовывать данные?
>>047003
Она же платная. Там 30 дней только пробный период, а мне надо инструмент на длительный период.
Она же платная. Там 30 дней только пробный период, а мне надо инструмент на длительный период.
>>047035
Она 100 долларов в год стоит, ты серьёзно? Там даже можно не продлевать подписку если не хочешь, тогда ты сможешь её использовать, но без обновлений на новую версию.
Она 100 долларов в год стоит, ты серьёзно? Там даже можно не продлевать подписку если не хочешь, тогда ты сможешь её использовать, но без обновлений на новую версию.
>>047533
Отладчик тоже завезли. Не знаю, как в комьюнити версии, но в проф версии он точно есть.
Отладчик тоже завезли. Не знаю, как в комьюнити версии, но в проф версии он точно есть.
>>046935
вим
вим
Если со стеком, любому, кто программировал на Ассемблере, всё понятно, то вот реализация кучи остаётся загадкой. О куче идёт много разговоров, но лично мне до сих пор не понятно, каким таким магическим образом нам динамически выделяют любой по размеру кусок памяти, а потом его освобождают. При этом утверждается, что освобожденный кусок также можно использовать.
>>047672
Куча — это тупо массив битков, который аллокатором делится на нужные куски. Аллокатор в себе хранит данные о выделенных кусках, и когда ты освобождаешь аллокацию, аллокатор просто удаляет кусок из листа используемых, а когда выделяешь память, аллокатор ищет подходящий невыделенный кусок с помощью анализа уже выделенных кусков.
На самом деле там всё немного сложнее, конечно же, но основной принцип именно такой.
Куча — это тупо массив битков, который аллокатором делится на нужные куски. Аллокатор в себе хранит данные о выделенных кусках, и когда ты освобождаешь аллокацию, аллокатор просто удаляет кусок из листа используемых, а когда выделяешь память, аллокатор ищет подходящий невыделенный кусок с помощью анализа уже выделенных кусков.
На самом деле там всё немного сложнее, конечно же, но основной принцип именно такой.
>>047672
С точки зрения ОС ты просто вызываешь функцию аллокации памяти нужного размера и тебе даётся указатель на массив байтов, после чего вызываешь функцию деаллокации передавая ей указатель, который дала тебе функция аллокации. Но обычно апи ОС напрямую использует только аллокатор (потому что сама аллокация памяти - достаточно долгий процесс и лучше взять памяти побольше и потом постепенно использовать) - специальная библиотека, которая выделяет память для твоих объектов в куче. А там уже сколько памяти брать, как объекты внутри распределять - зависит от самого аллокатора (потому их так и дохуя и универсального как бы и нет).
> каким таким магическим образом нам динамически выделяют любой по размеру кусок памяти
С точки зрения ОС ты просто вызываешь функцию аллокации памяти нужного размера и тебе даётся указатель на массив байтов, после чего вызываешь функцию деаллокации передавая ей указатель, который дала тебе функция аллокации. Но обычно апи ОС напрямую использует только аллокатор (потому что сама аллокация памяти - достаточно долгий процесс и лучше взять памяти побольше и потом постепенно использовать) - специальная библиотека, которая выделяет память для твоих объектов в куче. А там уже сколько памяти брать, как объекты внутри распределять - зависит от самого аллокатора (потому их так и дохуя и универсального как бы и нет).
Если я написал программу, которая не выходит за границы массива и работает корректно, то почему я должен платить за дополнительные проверки на границы массива во время выполнения, которые снижают производительность?
>>047849
Ну вообще компилятор проверки и не суёт, если во время компиляции твёрдо и чётко видит, что за границы массива ничего не выходит. Однако видит не всегда.
Ну вообще компилятор проверки и не суёт, если во время компиляции твёрдо и чётко видит, что за границы массива ничего не выходит. Однако видит не всегда.
>>047849
Потому что ты не умеешь использовать итераторы, как вариант. Или потому что ты не смог убедить компилятор в ненужности проверок с помощью сейф кода.
Потому что ты не умеешь использовать итераторы, как вариант. Или потому что ты не смог убедить компилятор в ненужности проверок с помощью сейф кода.
>>048303
В vscode можно также запилить на кнопочку
Тока хзы как, мне вполне удобно в консоли все делать
В vscode можно также запилить на кнопочку
Тока хзы как, мне вполне удобно в консоли все делать
https://github.com/systemd/systemd/pull/19598
systemd - ключевой компонент всех популярных дистров линукса, и теперь туда пытается проползти раст, что его неминуемо обессмертит.
Раст идёт к успеху!
systemd - ключевой компонент всех популярных дистров линукса, и теперь туда пытается проползти раст, что его неминуемо обессмертит.
Раст идёт к успеху!
Суп, расты. Начал изучать работу с файлами, не могу вкурить как переписать кусок файла без создания нового и копирования в него со смещением. Можете помочь примером?
>>049716
fn main() -> io::Result<()> {
let mut f = File::open("foo.txt")?;
// move the cursor 42 bytes from the start of the file
f.seek(SeekFrom::Start(42))?;
Ok(())
}
Это прочитает 42 байта или начнёт читать с 42 байта? Я прочитал коммент на английском, но туповат немного.
>std::io::Seek
fn main() -> io::Result<()> {
let mut f = File::open("foo.txt")?;
// move the cursor 42 bytes from the start of the file
f.seek(SeekFrom::Start(42))?;
Ok(())
}
Это прочитает 42 байта или начнёт читать с 42 байта? Я прочитал коммент на английском, но туповат немного.
>>049725
Это передвинет курсор в файле на 42 байт со старта. Дальше жмёшь std::io::Read или std::io::Write, чтобы читать или писать начиная с 42 байта в файле.
Это передвинет курсор в файле на 42 байт со старта. Дальше жмёшь std::io::Read или std::io::Write, чтобы читать или писать начиная с 42 байта в файле.
>>050006
Тебе же надо было переписать кусок файла, нет?
Прочитать первые 42 байта — это элементарнейшая херня, делается через
let buf = &mut [0_u8; 42];
let r = std::io::Read::read(reader, buf)?;
Правда в файле может быть меньше 42 байтов, так что по хорошему надо ещё сделать так:
let bytes_read = &buf[..r];
Тебе же надо было переписать кусок файла, нет?
Прочитать первые 42 байта — это элементарнейшая херня, делается через
let buf = &mut [0_u8; 42];
let r = std::io::Read::read(reader, buf)?;
Правда в файле может быть меньше 42 байтов, так что по хорошему надо ещё сделать так:
let bytes_read = &buf[..r];
>>050251
Да, переписать. С чтением я понял, получилось с буфером нужного размера, спасибо.
И ещё вопрос, допустим у меня есть
Я могу как-то записать его в начало файла, но так, чтобы:
1) первые 42 байта заменились, то есть 43 байт стал 85-м
2) без копирования во временный файл
С временным файлом я разобрался, принцип тот же, что и выше - используя Seek::Start и дописать в нужный файл с OpenOptions::new().write(true).append(true)
>Тебе же надо было переписать кусок файла, нет?
Да, переписать. С чтением я понял, получилось с буфером нужного размера, спасибо.
И ещё вопрос, допустим у меня есть
> let buf2 = &mut [0_u8; 84];
Я могу как-то записать его в начало файла, но так, чтобы:
1) первые 42 байта заменились, то есть 43 байт стал 85-м
2) без копирования во временный файл
С временным файлом я разобрался, принцип тот же, что и выше - используя Seek::Start и дописать в нужный файл с OpenOptions::new().write(true).append(true)
В общем, я даже нашел либу для подобного, но хочу разобраться как оно работает.
>>050308
Нет, не можешь, разное же количество байтов. Вообще, в теории есть варианты, но проще всего именно записать в новый файл, а потом этим файлом заменить старый. Это и проще и надёжнее.
Нет, не можешь, разное же количество байтов. Вообще, в теории есть варианты, но проще всего именно записать в новый файл, а потом этим файлом заменить старый. Это и проще и надёжнее.
>>051726
Нет, не можешь, только перезаписать байты в начале файла. Думай о файле как о векторе: дописать в конец ты можешь, а вот чтобы дописать в начало, тебе сперва надо весь вектор сдвинуть.
Нет, не можешь, только перезаписать байты в начале файла. Думай о файле как о векторе: дописать в конец ты можешь, а вот чтобы дописать в начало, тебе сперва надо весь вектор сдвинуть.
>>051783
фон Нейман ебучий заруинил запись в начало файла
фон Нейман ебучий заруинил запись в начало файла
Вопрос тем, кто пишет на расте не системщину: почему вы не пишете на стабильном языке со сборщиком мусора? Чем вам go не угодил?
р
Аноны, тут ВБ ищет растовика - собираются внедрять цифровой ГУЛАГ на складах и пишут самопальную замену CEPH. Удалёнщики также вэлкам. Я особеседовал, но они меня, скорее всего на хуй пошлют. Попробуйте и вы.
Суть: сидят 2 задрота-экс-плюсовика и дрючат тебя на знание алгоритмов и списков в рот я это всё ебал. Говорю, да вот же, терминал торговый написал, приложение камеры поверх NDK - не, им это всё похуй, им алгоритмы давай. Может кто-то из вас найдёт с ними общий язык, я хз. Ещё спрашивали, какая у меня любимая книга, ну, я, короч, неправильно ответил, надо что-то по алгоритмам чтоб было.
Суть: сидят 2 задрота-экс-плюсовика и дрючат тебя на знание алгоритмов и списков в рот я это всё ебал. Говорю, да вот же, терминал торговый написал, приложение камеры поверх NDK - не, им это всё похуй, им алгоритмы давай. Может кто-то из вас найдёт с ними общий язык, я хз. Ещё спрашивали, какая у меня любимая книга, ну, я, короч, неправильно ответил, надо что-то по алгоритмам чтоб было.
>>056103
Медленно, тормозит, сам Го как язык лютая хуита. Мне больше котлин понравился как джава, только нормальный, но он работает на JVM, а она тоже медленная.
Медленно, тормозит, сам Го как язык лютая хуита. Мне больше котлин понравился как джава, только нормальный, но он работает на JVM, а она тоже медленная.
>>057815
Если сравнивать не на синтетических тестах, а на реальных задачах, то разница в скорости не заметна. Реально заметна на глаз только скорость компиляции - у go гораздо быстрее проекты собираются.
>Медленно
Если сравнивать не на синтетических тестах, а на реальных задачах, то разница в скорости не заметна. Реально заметна на глаз только скорость компиляции - у go гораздо быстрее проекты собираются.
>>058023
Орнул с вебмакаки.
Орнул с вебмакаки.
Уважаемые растоманы, как вы пришли к расту? Что вас побудило начать писать на нем? Допустим, почему я должен перейти с условных плюсов на ржавого? Стоит ли вкатываться?
>>058777
Заебал питон с его недотипизацией и тормозами.
Заебали си/плюсы с их ебучими сегфолтами в самых неожиданных местах, которые поди ещё поотлаживай.
А у раста ещё и карго есть, одна из самых, если не самая, система подтягивания зависимостей.
С другой стороны, если ты с плюсами на "ты", тебя в них прям вот всё устраивает, пишешь ты, аки святой Кармак, то может именно тебе и не надо. За растом будущее как раз ещё по той причине, что он удобен бизнесу - в реальном мире, где далеко не все прогеры кармаки, он позволяет отсечь плохой код (и, возможно, плохих кодеров) ещё на этапе компиляции.
Заебал питон с его недотипизацией и тормозами.
Заебали си/плюсы с их ебучими сегфолтами в самых неожиданных местах, которые поди ещё поотлаживай.
А у раста ещё и карго есть, одна из самых, если не самая, система подтягивания зависимостей.
С другой стороны, если ты с плюсами на "ты", тебя в них прям вот всё устраивает, пишешь ты, аки святой Кармак, то может именно тебе и не надо. За растом будущее как раз ещё по той причине, что он удобен бизнесу - в реальном мире, где далеко не все прогеры кармаки, он позволяет отсечь плохой код (и, возможно, плохих кодеров) ещё на этапе компиляции.
>>058023
Если "реальные задачи" в твоём понимании это отдать html страницу из кэша - то да, тут разницы не заметно. А если нужно делать что-то сложное при этом не умирать и не тормозить при очень большой нагрузке, тут твоё го уже не справляется.
Если "реальные задачи" в твоём понимании это отдать html страницу из кэша - то да, тут разницы не заметно. А если нужно делать что-то сложное при этом не умирать и не тормозить при очень большой нагрузке, тут твоё го уже не справляется.
>>058777
Начал принимать лоли-колёса и становиться настоящей девочкой.
Начал принимать лоли-колёса и становиться настоящей девочкой.
>>058777
Раньше писали на работе медиапроект на Си. Я чет по-рофлу решил глянуть на раст.
Так и началось.
В итоге весь проект переполз на раст. Написали бинды к ffmpeg'у\gstreamr'у. Сидим, кайфуем. Писать кодяру - быстрее, зависимости тянуть - просто, распиливать проект на сабмодули - просто, сегфолтов нет, перфоманс тот же самый.
В итоге, уже запилили стриминг-платформу и плеер без единого сегфолта, лол. Сейчас допиливаем метрики и апишку внешнюю.
Раньше писали на работе медиапроект на Си. Я чет по-рофлу решил глянуть на раст.
Так и началось.
В итоге весь проект переполз на раст. Написали бинды к ffmpeg'у\gstreamr'у. Сидим, кайфуем. Писать кодяру - быстрее, зависимости тянуть - просто, распиливать проект на сабмодули - просто, сегфолтов нет, перфоманс тот же самый.
В итоге, уже запилили стриминг-платформу и плеер без единого сегфолта, лол. Сейчас допиливаем метрики и апишку внешнюю.
>>063844
Да, возможно рановато ещё расту в ядро. Но эта проблема давно известна и потихоньку пилится
https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html
https://www.crowdstrike.com/blog/dealing-with-out-of-memory-conditions-in-rust/
https://github.com/rust-lang/rust/issues/48043
возможно сейчас, после линусового пендаля, будет пилиться активнее. Для обычных же приложений, вне ядра, вылет в случае нехватки памяти - ну это не самое страшное, что может случиться, раз уже ты столкнулся с этой самой нехваткой.
Да, возможно рановато ещё расту в ядро. Но эта проблема давно известна и потихоньку пилится
https://rust-lang.github.io/rfcs/2116-alloc-me-maybe.html
https://www.crowdstrike.com/blog/dealing-with-out-of-memory-conditions-in-rust/
https://github.com/rust-lang/rust/issues/48043
возможно сейчас, после линусового пендаля, будет пилиться активнее. Для обычных же приложений, вне ядра, вылет в случае нехватки памяти - ну это не самое страшное, что может случиться, раз уже ты столкнулся с этой самой нехваткой.
>>063947 (Del)
вода с претензией на сурьезность
вода с претензией на сурьезность
У вас https://crates.io/ через браузер palemoon тоже не работает? На зеленом фоне пишет "sorry...."
>>063954
Это паста, пчел.
Это паста, пчел.
Недавно вышла первая стабильная версия языка программирования crystal https://crystal-lang.org/
Синтаксис как у ruby, а скорость как у C.
Синтаксис как у ruby, а скорость как у C.
>>064866
Есть ещё https://github.com/microsoft/windows-rs
Там помимо винапи есть ещё и другие более современные апи.
Есть ещё https://github.com/microsoft/windows-rs
Там помимо винапи есть ещё и другие более современные апи.
>>065100
Не пизди, брейнфак охуительно нужен как эталон эзотерических ЯП. А crystal этот никому нахуй не нужен кроме рубидрочеров, которые со своим ООП могут пойти на хуй.
Не пизди, брейнфак охуительно нужен как эталон эзотерических ЯП. А crystal этот никому нахуй не нужен кроме рубидрочеров, которые со своим ООП могут пойти на хуй.
>>066128
Открой ишшуи в репе раста и загугли I-unsound. Но это вовсе не отменяет того, что раст намного безопаснее и удобнее крестов или сишки.
Открой ишшуи в репе раста и загугли I-unsound. Но это вовсе не отменяет того, что раст намного безопаснее и удобнее крестов или сишки.
41 Кб, 602x281Читаю книжку.
В 12 главе (где пишешь свой плохонький греп) предлагают написать юниттесты к функции, которая парсит аргументы командной строки.
В этой главе агрументы были сделаны в виде массива строк, соответсвенно, юниттест был лёгкий.
В следующей главе поменяли массив строк на итератор std::env::Args. Как теперь юниттест-то написать? Пробовал банальное
let cmd = vec![String::from("binary"), String::from("needle"), String::from("haystack"),] as std::env::Args;
Но это "non-primitive cast"
Как быть?
В 12 главе (где пишешь свой плохонький греп) предлагают написать юниттесты к функции, которая парсит аргументы командной строки.
>Feel free to write some tests for the functionality in the Config::new and run functions on your own.
В этой главе агрументы были сделаны в виде массива строк, соответсвенно, юниттест был лёгкий.
В следующей главе поменяли массив строк на итератор std::env::Args. Как теперь юниттест-то написать? Пробовал банальное
let cmd = vec![String::from("binary"), String::from("needle"), String::from("haystack"),] as std::env::Args;
Но это "non-primitive cast"
Как быть?
>>067766
В смысле?
А, виноват, не всё скопировал. Уже делал
vec![String::from("binary"), String::from("needle"), String::from("haystack"),].iter() и добавлять as std::env::Args тоже пробовал;
Потом даже переделал в let cmd = ["binary", "needle", "haystack"].iter().map(|s| s.to_string()); чтобы почище
Он уже был итератором, в общем. Проблема в том, что он не был std::env::Args. И никакого способа сконструировать руками std::env::Args я не нашёл.
В смысле?
А, виноват, не всё скопировал. Уже делал
vec![String::from("binary"), String::from("needle"), String::from("haystack"),].iter() и добавлять as std::env::Args тоже пробовал;
Потом даже переделал в let cmd = ["binary", "needle", "haystack"].iter().map(|s| s.to_string()); чтобы почище
Он уже был итератором, в общем. Проблема в том, что он не был std::env::Args. И никакого способа сконструировать руками std::env::Args я не нашёл.
12 Кб, 621x104>>068655
Да, таки сделал в итоге. Точнее, вынес в отдельную функцию
Config::parse(mut args: impl Iterator<Item = String>) -> Result<Config, &'static str>
а так и оставил как в примере в книжке
Config::new(args: std::env::Args)
она теперь просто вызывает более общую приватную. На неё юниттест и запускаю.
Да, таки сделал в итоге. Точнее, вынес в отдельную функцию
Config::parse(mut args: impl Iterator<Item = String>) -> Result<Config, &'static str>
а так и оставил как в примере в книжке
Config::new(args: std::env::Args)
она теперь просто вызывает более общую приватную. На неё юниттест и запускаю.
тут узнал что диабло2 есть на go https://github.com/OpenDiablo2/OpenDiablo2
а какие крутые игры есть на расте?
а какие крутые игры есть на расте?
>>071030
veloren же
veloren же
Допустим, я - миллиардер. Стоит ли вкладывать деньги в создание игрового движка на расте для ААА-игр? Как это окупится?
>>071094
И что выгоднее: продавать такой движок другим компаниям или организовать свою студию по производству игр, которая будет его эксклюзивно использовать, пользуясь всеми преимуществами раста?
И что выгоднее: продавать такой движок другим компаниям или организовать свою студию по производству игр, которая будет его эксклюзивно использовать, пользуясь всеми преимуществами раста?
>>071184
Для них достаточно того факта, что они будут покупать ААА-игры по меньшей цене благодаря расту.
Для них достаточно того факта, что они будут покупать ААА-игры по меньшей цене благодаря расту.
>>071492
Все, у кого:
а) Есть свои наработки;
б) Есть хотелки которые имея деньги легче реализовать инхаус, чем ждать что когда-то реализуют в унылэнджайне/хуюнити.
Все, у кого:
а) Есть свои наработки;
б) Есть хотелки которые имея деньги легче реализовать инхаус, чем ждать что когда-то реализуют в унылэнджайне/хуюнити.
>>071217
Так не бывает. Цена будет та же, чтобы твоя прибыль была больше. Геймер же в любом случае проигрывает, поэтому игры покупают только тупые лохи.
Так не бывает. Цена будет та же, чтобы твоя прибыль была больше. Геймер же в любом случае проигрывает, поэтому игры покупают только тупые лохи.
Всё чаще на ххсру натыкаюсь на вакансии, в которых нужен рист.
Хотя ещё год назад не было вообще ни одной
https://hh.ru/vacancy/45212753
Хотя ещё год назад не было вообще ни одной
https://hh.ru/vacancy/45212753
>>072389
клоуны. нахрен там раст, если все либы по cv это питовские интерфесы к плюсовым либам
клоуны. нахрен там раст, если все либы по cv это питовские интерфесы к плюсовым либам
>>072405
Yew давно уже есть, но он не перформит.
Yew давно уже есть, но он не перформит.
>>043303
Зато они запускались и без дос тупо загрузчиком.
> (кстати, турбо паскаль от 1989 года под дос не мог без мэдскиллз делать бинарники меньше 7кб).
Зато они запускались и без дос тупо загрузчиком.
>>041230
https://doc.rust-lang.org/1.7.0/book/no-stdlib.html
+
+
проследи, не линкуется ли какой нибудь libc и прочая хуйня, и получишь свой голый бинарь размером с твой хуй.
>#[no_std]
https://doc.rust-lang.org/1.7.0/book/no-stdlib.html
+
>[profile.release]
>lto = true
+
проследи, не линкуется ли какой нибудь libc и прочая хуйня, и получишь свой голый бинарь размером с твой хуй.
>>072426
Клоун как раз ты, раз полагаешься только на готовые библиотеки. Профи пишут под задачу оптимизированный код. Представь себе, нейронки и компьютерное зрение под силу написать даже в одиночку. Тем более, распознавание лиц не такая сложная задача.
Клоун как раз ты, раз полагаешься только на готовые библиотеки. Профи пишут под задачу оптимизированный код. Представь себе, нейронки и компьютерное зрение под силу написать даже в одиночку. Тем более, распознавание лиц не такая сложная задача.
>>073819
Чмо, твоя маня реализация CNN, которую действительно можно написать в соло за пару дней, будет сосать в производительности, возможностях, удобстве использования либам, которые пишутся, выилизываются и оптимизируются уже лет 10 на плюсах.
И никто в здравом уме не будет переписывать это на расте.
Чмо, твоя маня реализация CNN, которую действительно можно написать в соло за пару дней, будет сосать в производительности, возможностях, удобстве использования либам, которые пишутся, выилизываются и оптимизируются уже лет 10 на плюсах.
И никто в здравом уме не будет переписывать это на расте.
>>074150
1. Чел, ты видишь плюсы там где их нет.
2. Нейронки и прочее считают на кудах и опенцл, за редкими исключениями. Зачастую через удобные интерфейсы вроде тензорфлова.
3. Numpy это вначале фортран а затем сишная обёртка.
Так что выпей антиплюсин.
1. Чел, ты видишь плюсы там где их нет.
2. Нейронки и прочее считают на кудах и опенцл, за редкими исключениями. Зачастую через удобные интерфейсы вроде тензорфлова.
3. Numpy это вначале фортран а затем сишная обёртка.
Так что выпей антиплюсин.
>>074187
Ну иди теперь штаны стирай, засранец.
Ну иди теперь штаны стирай, засранец.
>>074150
Практика показывает обратное. Ты слишком возомнил себе, будто нейронки это что-то сверхсложное, но это не так.
Практика показывает обратное. Ты слишком возомнил себе, будто нейронки это что-то сверхсложное, но это не так.
Гугл спонсирует внедрение раста в ядро линукс https://www.memorysafety.org/blog/supporting-miguel-ojeda-rust-in-linux/
Если нанятый программист не подведет, то все драйвера для линукса будут писать на расте.
Если нанятый программист не подведет, то все драйвера для линукса будут писать на расте.
>>026136
Обычный тупой маркетинг, что ты так подорвался?
Обычный тупой маркетинг, что ты так подорвался?
>>017017 (OP)
Почему Rust ассоциируют с трапами? Много известных rust-кодеров трапы или в команде разработки самого языка много трпаов?
Почему Rust ассоциируют с трапами? Много известных rust-кодеров трапы или в команде разработки самого языка много трпаов?
>>074946
Была история, что на него несколько больших аэропортов свой внутренний софт переписали, отсюда и повелось.
Была история, что на него несколько больших аэропортов свой внутренний софт переписали, отсюда и повелось.
>>074946
Смотрел в прошлом году RustConf одним глазком - половина презентеров была трапчанские
Смотрел в прошлом году RustConf одним глазком - половина презентеров была трапчанские
>>074946
Чтобы тебя привлечь.
Чтобы тебя привлечь.
>>074946
Ну смотри, программирование как деятельность в целом – само по себе для девиантов, тех, кто вместо "человек - человек" предпочитает "человек - машина". У нас такие тесты были в школе, на определение будущего проф направления, ну и классы были тоже с "уклоном", я был типа в техническом. Так вот, Раст в этом плане - один из наиболее сложных ЯПов, соответственно, привлекает наиболее отклоняющихся от "нормы" индивидуумов.
Ну и второе - это их такая самореализация и самобичевание. Типа, смотрите, вот натуралы и прочие нормисы не могут прогать на этом нечитаемом говне, а мы смогли, смогли-и-и!
Ну и времени свободного у них видимо дохуя, на вечеринки и другие активности нормисов-то не зовут. Вот и сбиваются в кучки по интересам, а там как снежный ком и диаспоры за рубежом - свои тянут своих.
Ну смотри, программирование как деятельность в целом – само по себе для девиантов, тех, кто вместо "человек - человек" предпочитает "человек - машина". У нас такие тесты были в школе, на определение будущего проф направления, ну и классы были тоже с "уклоном", я был типа в техническом. Так вот, Раст в этом плане - один из наиболее сложных ЯПов, соответственно, привлекает наиболее отклоняющихся от "нормы" индивидуумов.
Ну и второе - это их такая самореализация и самобичевание. Типа, смотрите, вот натуралы и прочие нормисы не могут прогать на этом нечитаемом говне, а мы смогли, смогли-и-и!
Ну и времени свободного у них видимо дохуя, на вечеринки и другие активности нормисов-то не зовут. Вот и сбиваются в кучки по интересам, а там как снежный ком и диаспоры за рубежом - свои тянут своих.
>>075228
Ты смотрел cppcon? Там тоже есть трансы. один из https://github.com/TartanLLama
>>074946
>>075315
Привлечение меньшинств в разработку это буквально цель раста
https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html
>>075315
Согласно https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#feeling-welcome 92% это, скорее всего, обычные люди.
Ты смотрел cppcon? Там тоже есть трансы. один из https://github.com/TartanLLama
>>074946
>>075315
Привлечение меньшинств в разработку это буквально цель раста
https://blog.rust-lang.org/2017/06/27/Increasing-Rusts-Reach.html
>Some groups that are underrepresented in technology and in the Rust community that we would especially love insights from include women (cis & trans), nonbinary folks, people of color, non-native English speakers, people who learned programming later in life (older, or only in college, or at a bootcamp as part of a midlife career change), people with disabilities, or people who have different learning styles.
>>075315
>вот натуралы и прочие нормисы не могут прогать на этом нечитаемом говне
Согласно https://blog.rust-lang.org/2018/11/27/Rust-survey-2018.html#feeling-welcome 92% это, скорее всего, обычные люди.
>>075315
Легкотня по сравнению с задротской связкой cmake & autotools & с/c++
Все самые известные растоманы - это вебмакаки, перешедшие с умирающего ruby. Твои любимые трапы тоже оттуда перекатились.
>Раст
>один из наиболее сложных
Легкотня по сравнению с задротской связкой cmake & autotools & с/c++
Все самые известные растоманы - это вебмакаки, перешедшие с умирающего ruby. Твои любимые трапы тоже оттуда перекатились.
>>074946
Пидоры зохватили язык. Буквально. Сменили некоторые из должностей, начали визжать и кукарекать. Потом пропихивать себя же на различные посты. Потом уже все стали пидорами вокруг, в итоге язык уже год как пидераст.
>>075315
Только для трапов и пидоров.
Пидоры зохватили язык. Буквально. Сменили некоторые из должностей, начали визжать и кукарекать. Потом пропихивать себя же на различные посты. Потом уже все стали пидорами вокруг, в итоге язык уже год как пидераст.
>>075315
> Раст в этом плане - один из наиболее сложных ЯПов
Только для трапов и пидоров.
>>075763
Кстати, ruby тот ещё загон закрытый клуб.
Зачем это дерьмо использовали для написания нескольких крутых продуктов - мне непонятно. Наверное потому что в те годы питон не был настолько крут, а энтерпрайз языки были уже слишком унылы и не модны.
Кстати, ruby тот ещё загон закрытый клуб.
Зачем это дерьмо использовали для написания нескольких крутых продуктов - мне непонятно. Наверное потому что в те годы питон не был настолько крут, а энтерпрайз языки были уже слишком унылы и не модны.
>>063938
Кто ядру будет выделять память? Разве это не задача самого ядра менеджерить память?
Кто ядру будет выделять память? Разве это не задача самого ядра менеджерить память?
Если в программировании возникает много ошибок при работе с динамическим выделением памяти, то почему Раст не запрещает динамическое выделение памяти? Вот просто убрать это всё из языка и тогда программы станут надёжнее.
>>076049
Вот с эти проблем у раста нет. Там можно определить специальные функции (аллокатор) которые будут вызываться, если нужно немного памяти. Проблемы начинаются если памяти не хватает. Аллокатор в этом случае возвращает ошибку, но куча мест в стандартной библиотеке на эту ошибку реагирует паникой, а нужно просто передавать эту же ошибку коду выше. Сейчас самый большой перепил и идёт в этом направлении - добавить fallible-аналоги для всех infallible-функций и добавить какую-нибудь конфигурацию, при активации которой все infallible-функции будут недоступны.
Вот с эти проблем у раста нет. Там можно определить специальные функции (аллокатор) которые будут вызываться, если нужно немного памяти. Проблемы начинаются если памяти не хватает. Аллокатор в этом случае возвращает ошибку, но куча мест в стандартной библиотеке на эту ошибку реагирует паникой, а нужно просто передавать эту же ошибку коду выше. Сейчас самый большой перепил и идёт в этом направлении - добавить fallible-аналоги для всех infallible-функций и добавить какую-нибудь конфигурацию, при активации которой все infallible-функции будут недоступны.
Проблема всех новых языков как правило в том, что они замкнуты сами в себе. Можно бесконечно до хрипоты доказывать, что в любимом языке максимально эффективно перегоняются байтики, но всё это становится бесполезной математической задачей без возможностей ввода/вывода. Вот какой ввод/вывод имеется в Rust кроме консоли?
>>076452
Почему разработчики выкатывают свой язык, но не пишут к нему либы для ввода/вывода типа Qt?
Почему разработчики выкатывают свой язык, но не пишут к нему либы для ввода/вывода типа Qt?
>>076466
Потому что десктоп мертв?
Потому что десктоп мертв?
>>076466
А нафиг им это нужно? Они захотели сделать язык и компилятор и сделали. К слову, разработчики большинства других языков или компиляторов поступают точно так же. Думаешь авторы C++ или GCC написали Qt? Нет. К слову, для Rust куча библиотек для GUI есть. Ты видимо не искал или плохо искал.
А нафиг им это нужно? Они захотели сделать язык и компилятор и сделали. К слову, разработчики большинства других языков или компиляторов поступают точно так же. Думаешь авторы C++ или GCC написали Qt? Нет. К слову, для Rust куча библиотек для GUI есть. Ты видимо не искал или плохо искал.
>>073817
Динамическую линковку в школе ещё не проходили чтоле, м?
Ясен хуй, что без него мало что заработает, просто сейчас явно не то время, когда кто-то будет терпеть все анальные боли и версионированием и деплоем ради 2 мб на диске.
Динамическую линковку в школе ещё не проходили чтоле, м?
Ясен хуй, что без него мало что заработает, просто сейчас явно не то время, когда кто-то будет терпеть все анальные боли и версионированием и деплоем ради 2 мб на диске.
>>077116
Школьник ты. Во-первых, чтобы статически слинковать libc в расте надо знатно поебаться, он там по дефолту линкуется динамически. Во-вторых, hello-world в расте это что? 'println!("Hello, world!");'. Вот удачи тебе собрать это с no_std.
Школьник ты. Во-первых, чтобы статически слинковать libc в расте надо знатно поебаться, он там по дефолту линкуется динамически. Во-вторых, hello-world в расте это что? 'println!("Hello, world!");'. Вот удачи тебе собрать это с no_std.
>>017017 (OP)
Насколько RUST пидорский? Go пидорский настолько, что сует плашку фашистов BLM себе на офф сайт. У раста офф сайт без этого говна. Но и тут есть CoCk
We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
Короче хуйня ебаная. ЯП для соидевочек. Или стоит дать ему шанс? Хочу писать системный софт. C++ говно, C# не позволяет религия, JVM говно ебаное. Один выход Си, но Си это ебанутый друг, который вечно обдолбан чем-то и внезапно схватил твои яйца и любое неверное слово и ты нахуй их лишишься.
Какой язык вообще сегодня не пидорский\сжвшный\левацкий\etc? Самый хуйовый в этом плане JS, - куча куколдов на нем пишут. Python окуколдивается. Вы там ебанулись? Мне на асме писать, а?
Насколько RUST пидорский? Go пидорский настолько, что сует плашку фашистов BLM себе на офф сайт. У раста офф сайт без этого говна. Но и тут есть CoCk
We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
Please avoid using overtly sexual aliases or other nicknames that might detract from a friendly, safe and welcoming environment for all.
Короче хуйня ебаная. ЯП для соидевочек. Или стоит дать ему шанс? Хочу писать системный софт. C++ говно, C# не позволяет религия, JVM говно ебаное. Один выход Си, но Си это ебанутый друг, который вечно обдолбан чем-то и внезапно схватил твои яйца и любое неверное слово и ты нахуй их лишишься.
Какой язык вообще сегодня не пидорский\сжвшный\левацкий\etc? Самый хуйовый в этом плане JS, - куча куколдов на нем пишут. Python окуколдивается. Вы там ебанулись? Мне на асме писать, а?
>>077493
Чем более хайповый, тем более пидорский, потому что пидоры лезут где больше аудитория и орут громче всех. Очевидно же.
Чем более хайповый, тем более пидорский, потому что пидоры лезут где больше аудитория и орут громче всех. Очевидно же.
>>077495
Конечно. Поэтому я поначалу и решил, будто раст оплот чистоплотности и праведности. Но при чуть более глубоком ознакомлении понял, что был создан геями для геев, чтобы дать пососать таким же геям, но только из гугла
Конечно. Поэтому я поначалу и решил, будто раст оплот чистоплотности и праведности. Но при чуть более глубоком ознакомлении понял, что был создан геями для геев, чтобы дать пососать таким же геям, но только из гугла
>>077507
Пидорам не нравится, что в питоне есть слова master и slave
@
Угнетение ко ко ко
@
Левацкий скам, именуемый разработчиками прогибается
@
Теперь это parent и child
@
Твой говнософт теперь надо переделывать, чтобы он заработал
@
Странно, но у других разработчиков тоже дохуя что отваливается
Пидорам не нравится, что в питоне есть слова master и slave
@
Угнетение ко ко ко
@
Левацкий скам, именуемый разработчиками прогибается
@
Теперь это parent и child
@
Твой говнософт теперь надо переделывать, чтобы он заработал
@
Странно, но у других разработчиков тоже дохуя что отваливается
>>077596
А тебе неприятно, педераст?
А тебе неприятно, педераст?
>>077293
Hello world в расте (и любом языке) это программа, пишущая эту фразу любым доступным методом. Дёрнуть себя за хуй printf тебе никто не мешает.
>Во-вторых, hello-world в расте это что? 'println!("Hello, world!");'. Вот удачи тебе собрать это с no_std.
Hello world в расте (и любом языке) это программа, пишущая эту фразу любым доступным методом. Дёрнуть себя за хуй printf тебе никто не мешает.
>>077616
Опять ты в libc лезешь, она же тебя сожрет. Предложил бы хоть системный вызов для приличия дернуть.
>printf
Опять ты в libc лезешь, она же тебя сожрет. Предложил бы хоть системный вызов для приличия дернуть.
>>077616
Почему в стандартные библиотеки не добавляют функций типа: create_window() или putpixel(x,y,color)?
Почему в стандартные библиотеки не добавляют функций типа: create_window() или putpixel(x,y,color)?
>>077704
В те времена ещё не разработали графические интерфейсы пользователя и даже просто работа в консоли с живой ЭВМ - было супер-круто. Напомню, что до этого делали колоду перфокарт, которую считывал какой-нибудь простенький комп и формировал задание на магнитной ленте для большой ЭВМ. Затем бобина с магнитной лентой передавалась на эту ЭВМ, где происходила обработка пакета и формировался ответ. Сам ответ опять же печатался простенькой машиной на принтере.
В те времена ещё не разработали графические интерфейсы пользователя и даже просто работа в консоли с живой ЭВМ - было супер-круто. Напомню, что до этого делали колоду перфокарт, которую считывал какой-нибудь простенький комп и формировал задание на магнитной ленте для большой ЭВМ. Затем бобина с магнитной лентой передавалась на эту ЭВМ, где происходила обработка пакета и формировался ответ. Сам ответ опять же печатался простенькой машиной на принтере.
>>077710
Такого уговня ввод-вывод в стандартной библиотеке раста есть по println!() и io::stdin().
Такого уговня ввод-вывод в стандартной библиотеке раста есть по println!() и io::stdin().
>>077716
Сейчас же не 1970-е, все уже привыкли к графическим интерфейсам. И тут выходит новый язык, который опять предлагает старьё 50-летней давности. Я готов с этим мириться в старых языках, но новые надо разрабатывать под текущие нужны.
Сейчас же не 1970-е, все уже привыкли к графическим интерфейсам. И тут выходит новый язык, который опять предлагает старьё 50-летней давности. Я готов с этим мириться в старых языках, но новые надо разрабатывать под текущие нужны.
>>077720
Кто-то и срать, не снимая свитер, привык. Какое это отношение имеет к чему либо?
Разработчики С написали юникс. Точнее, они разработали С, чтобы написать юникс. Ввод-вывод уровня юникса в расте есть.
Разработчки Qt не написали С++, ввода-вывода уровня Qt в расте нет.
>все уже привыкли к графическим интерфейсам
Кто-то и срать, не снимая свитер, привык. Какое это отношение имеет к чему либо?
Разработчики С написали юникс. Точнее, они разработали С, чтобы написать юникс. Ввод-вывод уровня юникса в расте есть.
Разработчки Qt не написали С++, ввода-вывода уровня Qt в расте нет.
>>077733
Мне кажется, что создание графической библиотеки для Раста могла стать серьёзным конкурентным преимуществом. Многие С++ разработчики бросили бы своё мучение с Qt и прочими кривыми либами и перешли бы на Раст.
Мне кажется, что создание графической библиотеки для Раста могла стать серьёзным конкурентным преимуществом. Многие С++ разработчики бросили бы своё мучение с Qt и прочими кривыми либами и перешли бы на Раст.
>>077746
Конечно. Но это не обязанность создателей языка и компилятора (для си даже эти две задачи разделились 40 лет назад). У них своих дел полно. Если ты способен это сделать, то будешь крутым, уровня Qt Software.
>Мне кажется, что создание графической библиотеки для Раста могла стать серьёзным конкурентным преимуществом.
Конечно. Но это не обязанность создателей языка и компилятора (для си даже эти две задачи разделились 40 лет назад). У них своих дел полно. Если ты способен это сделать, то будешь крутым, уровня Qt Software.
>>077762
Ну биндинги для qt уже есть, причём от разраба самой qt, который уже делал другую версию биндингов на С++ - с использованием stateful-шаблонов вместо moc. Даже минимальная интеграция с асинхронным кодом есть: https://github.com/woboq/qmetaobject-rs
Ну биндинги для qt уже есть, причём от разраба самой qt, который уже делал другую версию биндингов на С++ - с использованием stateful-шаблонов вместо moc. Даже минимальная интеграция с асинхронным кодом есть: https://github.com/woboq/qmetaobject-rs
>>077859
Я так понял, он не про биндинги, а про нативную библиотеку, как Qt, только написанную на расте.
Я так понял, он не про биндинги, а про нативную библиотеку, как Qt, только написанную на расте.
>>077862
А, ну пытались пилить на webrender'е (который сам по себе слишком низкоуровневый, зато берёт на себя всю работу по рендерингу текста и прочей хуйни). Но оказалось на одном энтузиазме гуй-библиотеку не сделаешь и все подобные проекты сдувались.
А, ну пытались пилить на webrender'е (который сам по себе слишком низкоуровневый, зато берёт на себя всю работу по рендерингу текста и прочей хуйни). Но оказалось на одном энтузиазме гуй-библиотеку не сделаешь и все подобные проекты сдувались.
>>077934
Не напишешь. Либо будет неюзабельное говно, либо через полтора месяца сдуешься и закроешь проектик.
Не напишешь. Либо будет неюзабельное говно, либо через полтора месяца сдуешься и закроешь проектик.
Есть какое-то сложившееся мнение, что лучше делать в циклах
1. зарание задать изменяемую переменную и каждый раз её переиспользовать
2. на каждой итерации цикла делать новый let неизменяемой переменной и потом её дропать
Компилятор оптимизирует второе? Оно "безопаснее"? Пытался придумать пример и посмотреть в голдбольте, но фантазии не хватило.
итого
let mut a;
loop {a = ();}
или
loop {let a = ();}
1. зарание задать изменяемую переменную и каждый раз её переиспользовать
2. на каждой итерации цикла делать новый let неизменяемой переменной и потом её дропать
Компилятор оптимизирует второе? Оно "безопаснее"? Пытался придумать пример и посмотреть в голдбольте, но фантазии не хватило.
итого
let mut a;
loop {a = ();}
или
loop {let a = ();}
>>079680
Зависит от типа переменной. Лучше всего не использовать переменные вне цикла, а использовать читерский `Iterator::fold`
Зависит от типа переменной. Лучше всего не использовать переменные вне цикла, а использовать читерский `Iterator::fold`
>>079969
Тем же, чем так хорош Qt/boost, что их в каждый туториал по крестам пихают.
Тем же, чем так хорош Qt/boost, что их в каждый туториал по крестам пихают.
>>077493
1C
1C
R
>>080538
Структура, которую получаешь из внешнего источника.
Это, конечно, здорово, но я имел в виду применительно к эвент лупу, который на каждой итерации получает новый эвент.
>Зависит от типа переменной.
Структура, которую получаешь из внешнего источника.
>Лучше всего не использовать переменные вне цикла, а использовать читерский `Iterator::fold`
Это, конечно, здорово, но я имел в виду применительно к эвент лупу, который на каждой итерации получает новый эвент.
>>077493
zig
zig
>>077493
vlang, umka, sneklang
vlang, umka, sneklang
>>077622
Проход в вендорлок уже в хэловорде. Причём не просто вендорлок, а лок на наличии ОС. Ты просто предлагаешь насрать говнокодом чтобы подрочиться, или реально долбоёб?
>Предложил бы хоть системный вызов для приличия дернуть.
Проход в вендорлок уже в хэловорде. Причём не просто вендорлок, а лок на наличии ОС. Ты просто предлагаешь насрать говнокодом чтобы подрочиться, или реально долбоёб?
>>077639
Потому что:
а) Не каждый таргет имеет какие-то там окна и вообще графический интерфейс (или даже возможность что-то выводить на экран), лол.
б) Даже M$ это не осилила поддерживать на таком качестве, чтобы деплоить с языком, а не отдельно. Ты на кого надеешься? На попенсорс сообщество, которое 20+ лет не может сделать нихуя самостоятельно? Без кучи корпораций, как с линуксом/бсд/итд.
Потому что:
а) Не каждый таргет имеет какие-то там окна и вообще графический интерфейс (или даже возможность что-то выводить на экран), лол.
б) Даже M$ это не осилила поддерживать на таком качестве, чтобы деплоить с языком, а не отдельно. Ты на кого надеешься? На попенсорс сообщество, которое 20+ лет не может сделать нихуя самостоятельно? Без кучи корпораций, как с линуксом/бсд/итд.
>>081009
Вот это маневры, знатный же ты стрелочник, братишка. В твоем изначальном предложении вообще был лок на наличие libc, это абсолютно такой же лок на наличие ОС, да еще и на определенную ОС.
Вот это маневры, знатный же ты стрелочник, братишка. В твоем изначальном предложении вообще был лок на наличие libc, это абсолютно такой же лок на наличие ОС, да еще и на определенную ОС.
>>081094
Лол?
И на какую же?
Не знаю с чего ты решил что libc == glibc, но я, очевидно (по крайней мере для меня) говорю о подразумеваю что libc == POSIX C stdlib. Какой же у стандарта может быть вендорлок или зависимость от наличия системы — я хз.
>это абсолютно такой же лок на наличие ОС
Лол?
>да еще и на определенную ОС.
И на какую же?
Не знаю с чего ты решил что libc == glibc, но я, очевидно (по крайней мере для меня) говорю о подразумеваю что libc == POSIX C stdlib. Какой же у стандарта может быть вендорлок или зависимость от наличия системы — я хз.
>>081150
Опережая школьные пуки о том, что гугол выдаёт первее, бомбану документацией:
https://man7.org/linux/man-pages/man7/libc.7.html
и там же рассказ про кучу реализаций libc в линуксе.
Разрабы фуксии в гугле тоже не считают что libc == glibc.
Пропозал LLVMного прожекта, пишут что хотят сделать libc которая по возможности будет работать поверх системных libc. Кек. Как бы подразумевая, что она не одна, внезапно нахуй.
Опережая школьные пуки о том, что гугол выдаёт первее, бомбану документацией:
https://man7.org/linux/man-pages/man7/libc.7.html
>The term "libc" is commonly used as a shorthand for the "standard
>C library", a library of standard functions that can be used by
>all C programs (and sometimes by programs in other languages).
>Because of some history (see below), use of the term "libc" to
>refer to the standard C library is somewhat ambiguous on Linux
и там же рассказ про кучу реализаций libc в линуксе.
>https://fuchsia.googlesource.com/docs/+/refs/heads/sandbox/jschein/default/libc.md
>On Posix-y systems, programs link against a library (either dynamically or statically) called libc. This library provides the functions defined by the C standard, as well as the runtime environment for C programs.
Разрабы фуксии в гугле тоже не считают что libc == glibc.
Пропозал LLVMного прожекта, пишут что хотят сделать libc которая по возможности будет работать поверх системных libc. Кек. Как бы подразумевая, что она не одна, внезапно нахуй.
>>081163
это пропозал отдельной группы индусов в гугле трехлетней давности, которые внятно не смогли объяснить зачем это нужно, закоммитили три коммита и сдохли
мимо крокодил
>Пропозал LLVMного прожекта, пишут что хотят сделать libc которая по возможности будет работать поверх системных libc. Кек. Как бы подразумевая, что она не одна, внезапно нахуй.
это пропозал отдельной группы индусов в гугле трехлетней давности, которые внятно не смогли объяснить зачем это нужно, закоммитили три коммита и сдохли
мимо крокодил
>>081357
Я могу за них это сделать — чтобы выбить новые лычки и больше бабулеса от гугла, пропихнув новый проект. И работай они где нибудь в M$ — у них всё бы вышло, кекус.
>группы индусов в гугле
>которые внятно не смогли объяснить зачем это нужно
Я могу за них это сделать — чтобы выбить новые лычки и больше бабулеса от гугла, пропихнув новый проект. И работай они где нибудь в M$ — у них всё бы вышло, кекус.
Поч такой странный синтаксис с шаблонными функциями
Зачем фун::<тип>(), а не фун<тип>()
я дурачек, не ругайте только
Зачем фун::<тип>(), а не фун<тип>()
я дурачек, не ругайте только
>>083035
Чтобы упростить работу парсера. Без :: знак < сходу невозможно отличить от операции меньше (которая обозначается так же - <). Если бы :: не было, приходилось бы каждый раз при встрече < идти назад и смотреть что оно означает - тип функции или операцию сравнения. Пока решили парсер подобным не переусложнять, хотя предложения и были.
Чтобы упростить работу парсера. Без :: знак < сходу невозможно отличить от операции меньше (которая обозначается так же - <). Если бы :: не было, приходилось бы каждый раз при встрече < идти назад и смотреть что оно означает - тип функции или операцию сравнения. Пока решили парсер подобным не переусложнять, хотя предложения и были.
>>083055
А разве нельзя просто увидеть что после знака меньше идёт идентификатор типа, а не переменная
А разве нельзя просто увидеть что после знака меньше идёт идентификатор типа, а не переменная
>>083104
Ты их сходу никак не отличишь. Это либо надо иметь список всех переменных/типов (который составляется уже после парсинга), либо идти назад и смотреть каким образом всё это используется.
Ты их сходу никак не отличишь. Это либо надо иметь список всех переменных/типов (который составляется уже после парсинга), либо идти назад и смотреть каким образом всё это используется.
Есть структура, которая парсится из жсона с помощью serde.
struct Foo {
hash: String,
//other fields
}
Мне надо её сложить в два хэшмапа, один из которых это HashMap<String, Foo>, где в качестве ключа будет выступать хэш, который лежит в этой структуре. Когда я пытаюсь положить её в мапу, то появляется ошибка
Что логично. Но как эту ошибку обойти, не клонируя строку (что можно сделать, но хотелось бы понять как сделать правильно по раст-вей). Хэш не будет изменяться во время работы программы, но поля структуры будут. Можно ли указать хэш как &'static str? Что в таком случае делать с serde, сможет ли он десериализовать файл?
Второй хэшмап будет выглядеть вот так: HashMap<String, Vec<Foo>>. Отсюда данные могут быть только ридонли, так что логичнее сделать сигнатуру такой: HashMap<String, Vec<&Foo>>, да?
struct Foo {
hash: String,
//other fields
}
Мне надо её сложить в два хэшмапа, один из которых это HashMap<String, Foo>, где в качестве ключа будет выступать хэш, который лежит в этой структуре. Когда я пытаюсь положить её в мапу, то появляется ошибка
> map.insert(i.hash, i)
> ^ value used here after partial move
Что логично. Но как эту ошибку обойти, не клонируя строку (что можно сделать, но хотелось бы понять как сделать правильно по раст-вей). Хэш не будет изменяться во время работы программы, но поля структуры будут. Можно ли указать хэш как &'static str? Что в таком случае делать с serde, сможет ли он десериализовать файл?
Второй хэшмап будет выглядеть вот так: HashMap<String, Vec<Foo>>. Отсюда данные могут быть только ридонли, так что логичнее сделать сигнатуру такой: HashMap<String, Vec<&Foo>>, да?
>>083332
Лучше сделай наоборот. Ключ храни в хэшмапе, а в специальной структуре ссылку на ключ. Например так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5839778fb91f42615b11351789a41a76 Иначе без ансейфа (либо уродливых умных указателей) никак не сделать.
Проблема HashMap<?, Foo> в том, что Foo там внутри хранится как значение, а значит хэшмапа может перемещать его по памяти как захочет делая неверными все ссылки на внутренности и на саму Foo. Это значит, что надо Foo хранить где-нибудь отдельно в памяти, а в хэшмапу засовывать ссылку, например HashMap<?, Rc<RefCell<Foo>>> (если приложение многопоточное, то нужно использовать другую хэшмапу, из стандартной библиотеки она может работать только в одном потоке). В любом другом случае (например если захочешь избавиться от Rc/RefCell ради перформанса) придётся использовать ансейф.
Проблема в том, что хоть они и ридонли, но как я понял с первой хэшмапы изменять-то их можно. А значит состояние гонки всё равно возникнуть может. Для предотвращения этого и нужен RefCell. Rc/Arc нужен, чтобы память очистилась после удаления данных из обоих хэшмапов.
Лучше сделай наоборот. Ключ храни в хэшмапе, а в специальной структуре ссылку на ключ. Например так: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=5839778fb91f42615b11351789a41a76 Иначе без ансейфа (либо уродливых умных указателей) никак не сделать.
> Второй хэшмап
Проблема HashMap<?, Foo> в том, что Foo там внутри хранится как значение, а значит хэшмапа может перемещать его по памяти как захочет делая неверными все ссылки на внутренности и на саму Foo. Это значит, что надо Foo хранить где-нибудь отдельно в памяти, а в хэшмапу засовывать ссылку, например HashMap<?, Rc<RefCell<Foo>>> (если приложение многопоточное, то нужно использовать другую хэшмапу, из стандартной библиотеки она может работать только в одном потоке). В любом другом случае (например если захочешь избавиться от Rc/RefCell ради перформанса) придётся использовать ансейф.
> Отсюда данные могут быть только ридонли
Проблема в том, что хоть они и ридонли, но как я понял с первой хэшмапы изменять-то их можно. А значит состояние гонки всё равно возникнуть может. Для предотвращения этого и нужен RefCell. Rc/Arc нужен, чтобы память очистилась после удаления данных из обоих хэшмапов.
Привет. Есть ли плюсы у языка rust в геймдеве? Я имею в виду смогут ли допустить люди читерить в шутере написаном на расте?
>>083332
Либо клонируешь строку, либо хранишь строку как `(A)Rc<str>` и опять-таки клонируешь, либо вообще не хранишь hash в Foo, а тупо имеешь некую структуру Bar, которая имеет все поля Foo кроме хэша, и при засовывании в хашмапу разбираешь Foo на хэш и Bar.
>>083466
Смогут, почему нет. Проблема читерства в играх вовсе не в том, что там хартблиды везде, а в другом. Например, wallhack в шутерах работает не потому, что у тебя данные о позиции противников случайно протекли на машину игрока, а потому что ты не можешь их не протечь, иначе у тебя будут ебейшие лаги в игре.
Либо клонируешь строку, либо хранишь строку как `(A)Rc<str>` и опять-таки клонируешь, либо вообще не хранишь hash в Foo, а тупо имеешь некую структуру Bar, которая имеет все поля Foo кроме хэша, и при засовывании в хашмапу разбираешь Foo на хэш и Bar.
>>083466
Смогут, почему нет. Проблема читерства в играх вовсе не в том, что там хартблиды везде, а в другом. Например, wallhack в шутерах работает не потому, что у тебя данные о позиции противников случайно протекли на машину игрока, а потому что ты не можешь их не протечь, иначе у тебя будут ебейшие лаги в игре.
>>083472
То есть допусти если бы та же кс го была бы на расте, то читеров бы это не остонавило? Тип память игры более защищена и пакеты тоже.
То есть допусти если бы та же кс го была бы на расте, то читеров бы это не остонавило? Тип память игры более защищена и пакеты тоже.
>>083475
В каком месте они более защищены? Когда данные попали на кудахтер игрока, он может их прочесть. Я же говорю, что проблема читерства в играх — это вовсе не проблема хартблидов.
В каком месте они более защищены? Когда данные попали на кудахтер игрока, он может их прочесть. Я же говорю, что проблема читерства в играх — это вовсе не проблема хартблидов.
>>083475
Нет, чел, не остановило бы как уже сказал чел выше.
А вот если бы вальв было бы не похуй, они активно развивали античит и систему репортов, а потом активно ебали бы за это (+ если бы их игори были бы платными, а не как сейчас — хуяришь новый акк за 2 минуты и продолжаешь) — тогда этих пидорасов было бы меньше.
Реально раст в геймдеве может помочь разве что в разработке бэкэндов и сетевых частей игр — для всех игр тех же вальв каждые полгода-год появляются новый софт, позволяющий с помощью этих самых хартблидов, как анон выше назвал уязвимости, от которых спасает раст, крашить нахуй сервера и ддосить других игроков.
Нет, чел, не остановило бы как уже сказал чел выше.
А вот если бы вальв было бы не похуй, они активно развивали античит и систему репортов, а потом активно ебали бы за это (+ если бы их игори были бы платными, а не как сейчас — хуяришь новый акк за 2 минуты и продолжаешь) — тогда этих пидорасов было бы меньше.
Реально раст в геймдеве может помочь разве что в разработке бэкэндов и сетевых частей игр — для всех игр тех же вальв каждые полгода-год появляются новый софт, позволяющий с помощью этих самых хартблидов, как анон выше назвал уязвимости, от которых спасает раст, крашить нахуй сервера и ддосить других игроков.
60 Кб, 512x512Мотаюсь от Го к Расту и обратно, оба нравятся, но хочу писать только на одном, не могу определиться. Моя цель хорошо освоить один язык и юзать его для повседневных задач. Раст осень ноавится, но сложный. Раст и Го вообще очень похожи, go fmt/rustc fmt, cargo install / go install и друг у дружка пиздят фичи.
Вопрос. Наступит ли момент, когда зорошо выучив Раст, я буду на нем задачи решать также быстро как на Го? Или псоле Раста всегда как после войны возвращаешься?
Вопрос. Наступит ли момент, когда зорошо выучив Раст, я буду на нем задачи решать также быстро как на Го? Или псоле Раста всегда как после войны возвращаешься?
>>083888
Не знаю. Я вот взял одну библиотеку, 3 дня корячился, сделал четверть фичи, которую я хотел, половину руками дописывал.
Взял другую библиотеку, за 2 часа повторил ту же четверть фичи, к концу второго для сделал всё, что хотел. Получается, как повезёт с библиотеками?
Не знаю. Я вот взял одну библиотеку, 3 дня корячился, сделал четверть фичи, которую я хотел, половину руками дописывал.
Взял другую библиотеку, за 2 часа повторил ту же четверть фичи, к концу второго для сделал всё, что хотел. Получается, как повезёт с библиотеками?
>>083888
Хуй знает, джва года писал на goВНЕ. Полтора года назад пересел на раст.
Раст кажется куда более адекватным, чем ГОвно даже для прототипирования. Единственная боль - это асинхронная среда, если ты делаешь что-то больше, чем круд-сервачок и сырость либ.
От всего остального просто кайфую. Говно вспоминаю, как страшный сон.
Хуй знает, джва года писал на goВНЕ. Полтора года назад пересел на раст.
Раст кажется куда более адекватным, чем ГОвно даже для прототипирования. Единственная боль - это асинхронная среда, если ты делаешь что-то больше, чем круд-сервачок и сырость либ.
От всего остального просто кайфую. Говно вспоминаю, как страшный сон.
>>084104
Спасибо! Соглашусь с асинхроностью. Но знаешь, я возненавидил async/await ещё когда бота для дискорда писал своей стримерке любимой на питоне, мозг взрывается.
Спасибо! Соглашусь с асинхроностью. Но знаешь, я возненавидил async/await ещё когда бота для дискорда писал своей стримерке любимой на питоне, мозг взрывается.
>>084104
А что с КПД и продуктивностью? Я вот из usb-модема LTE сделал перенаправление СМСок себе в телегу, быстреьнко на Го код нахуячил раз-раз и готово за вечерок.
Раст вообще в повседневных задачах как он?
А что с КПД и продуктивностью? Я вот из usb-модема LTE сделал перенаправление СМСок себе в телегу, быстреьнко на Го код нахуячил раз-раз и готово за вечерок.
Раст вообще в повседневных задачах как он?
Допустим, хочу тянуть .m3u8-плейлист с твича прямой трансляции и вручную без streamlinkа чанки парсить через for/loop и сохранять на диск аппендить в файл. + возможность записи не 1-го стрима, а 2, 3 хоть 10 стримов одновременно.
Что выбрать лучше, Го или Раст для такой задачи и почему?
Что выбрать лучше, Го или Раст для такой задачи и почему?
>>084123
Что знаешь, то и бери. Это элементарная задача же: возьми здесь, положи сюда. До 200 штук можно не задумываясь использовать треды ос, никакого взамодействия между ними в твоей схеме нет.
Что знаешь, то и бери. Это элементарная задача же: возьми здесь, положи сюда. До 200 штук можно не задумываясь использовать треды ос, никакого взамодействия между ними в твоей схеме нет.
Правда что если используется Arc/Rc, RefCell и прочие хаки компилятора, то программа где-то спроектирована неправильно?
>>084216
??
??
>>084204
1. Нет, но иногда таки да (но чаще таки нет).
2. Это не хаки, это типы. Например, если тебе надо раскидать строку по разным структурам, и ты не знаешь, какая из строк раньше умрёт, то ты не убиваешь память кудахтера 100500 клонами String, ты берёшь Rc<str> и хранишь строку в одном месте, а указатели на строку хранишь в разных местах. Arc вообще охуительно полезен, тут даже рассказывать не буду, если ты не понимаешь, то GC тебе пухом.
3. RefCell может быть полезен в некоторых однопоточных асинхронных пиздецах, так что тут тоже мимо.
1. Нет, но иногда таки да (но чаще таки нет).
2. Это не хаки, это типы. Например, если тебе надо раскидать строку по разным структурам, и ты не знаешь, какая из строк раньше умрёт, то ты не убиваешь память кудахтера 100500 клонами String, ты берёшь Rc<str> и хранишь строку в одном месте, а указатели на строку хранишь в разных местах. Arc вообще охуительно полезен, тут даже рассказывать не буду, если ты не понимаешь, то GC тебе пухом.
3. RefCell может быть полезен в некоторых однопоточных асинхронных пиздецах, так что тут тоже мимо.
>>084667
Я хз, почему у тебя мозг сходу рвётся от такого.
Я хз, почему у тебя мозг сходу рвётся от такого.
29 Кб, 696x530Ёба, как сделать, чтобы все таски завершились, а потом уже прога завершалась? Прога заверашется сразу не дождавшись tokio::spawn
ПЕДЕ Rust
>>085878
Спасибо!, я заюзал tokio::join!
Спасибо!, я заюзал tokio::join!
Как добавить трейт ограничения на трейт? Допустим делаю трейт PlusOne (не важно, что он делает конкретно). Хочу в нём сделать дефолтную функцию, которая делает self + 1; Раст мне запрещает со словами error[E0369]: cannot add `{integer}` to `&Self`. Пытался добавлять std::ops::Add (и + std::marker::Sized, который ему требуется), но ошибку это не меняет.
Текст примера для копирования, форматирует вам пусть fmt:
fn main() {
let x: u16 = 3;
trait PlusOne: std::ops::Add + std::marker::Sized {
fn add_one(&self) -> bool where Self: std::marker::Sized {
self + 1;
true
}
}
impl PlusOne for u16 {}
}
Текст примера для копирования, форматирует вам пусть fmt:
fn main() {
let x: u16 = 3;
trait PlusOne: std::ops::Add + std::marker::Sized {
fn add_one(&self) -> bool where Self: std::marker::Sized {
self + 1;
true
}
}
impl PlusOne for u16 {}
}
20 Кб, 352x276>>087852
Естественно, если делать это в конкретной имплементации, например, impl PlusOne for u16, то всё срабатывает даже без ограничителей.
Естественно, если делать это в конкретной имплементации, например, impl PlusOne for u16, то всё срабатывает даже без ограничителей.
>>087852
https://docs.rs/funty/1.2.0/funty/
fn add_one(self) -> Self
where Self: funty::IsInteger,
{ self + Self::try_from(1_u8).unwrap() }
https://docs.rs/funty/1.2.0/funty/
fn add_one(self) -> Self
where Self: funty::IsInteger,
{ self + Self::try_from(1_u8).unwrap() }
glium всё?
>Glium is no longer actively developed by its original author. That said, PRs are still welcome and maintenance is continued by the surrounding community.
>>088659
Тебя ссылка в этом сообщении на пост из 2016 не смутила?
Тебя ссылка в этом сообщении на пост из 2016 не смутила?
Есть трейт:
pub trait Foo {
fn bar();
}
Я хочу возвращать из bar() Result<(), Err>. Но мне неизвестно, каков будет тип ошибки, это должна решить реализация трейта. Как это лучше сделать? Передавать ошибку дженериком?
pub trait Foo<TError: Error> {
fn bar() -> Result<(), TError>;
}
На мой взгляд это выглядит немного всрато, или мне кажется?
сука абу сделай уже блок кода в разметке, пидорас
pub trait Foo {
fn bar();
}
Я хочу возвращать из bar() Result<(), Err>. Но мне неизвестно, каков будет тип ошибки, это должна решить реализация трейта. Как это лучше сделать? Передавать ошибку дженериком?
pub trait Foo<TError: Error> {
fn bar() -> Result<(), TError>;
}
На мой взгляд это выглядит немного всрато, или мне кажется?
сука абу сделай уже блок кода в разметке, пидорас
>>090090
upd: А может это вообще хуёвый дизайн, и лучше сделать как-то так:
pub enum FooError {
Err1,
Err2
}
pub trait Foo {
fn bar() -> Result<(), FooError>
}
И пусть все реализации реализуют Into<FooError> для своих ошибок?
upd: А может это вообще хуёвый дизайн, и лучше сделать как-то так:
pub enum FooError {
Err1,
Err2
}
pub trait Foo {
fn bar() -> Result<(), FooError>
}
И пусть все реализации реализуют Into<FooError> для своих ошибок?
>>090090
Можно зафигачить box<dyn error>
Можно зафигачить box<dyn error>
Аноны, а не кажется ли вам, что нас где-то цинично наебали?
Ржавый обещает безопасное системное программирование, но безопасное оно с ним только в самом узком смысле - как защита от хакеров. Надёжным код от этого не становится - выход за границу массива на этапе компиляции никак не отслеживается, поэтому софт на Ржавом падает с таким же грохотом, что и софт на Си или на Джаве.
Хуже того, ради этой безопасности тратится время на всякие проверки и счетчики ссылок, а структуры данных с неясной борроу-чекеру семантикой владения превращаются в кромешный пиздец, как в примере с двусвязным списком, в котором изнихуя появляется unsafe дрочены или rc с refcell точены. То, что на Си пишет первокурсник, на Расте требует матёрого аксакала.
И даже если игнорировать танцы с борроу-чекером, сам язык, как бы это сказать, не фонтан. Элементарная задача - поменять порядок байт в числе при помощи шаблонной функции - выносит мозг похлеще разработки видеокодеков. Серьезно, стандартные функции from/to_be_bytes в шаблоне не используешь никак, т.к. они часть конкретных типов, а не единого трейта. Попытка же сделать transmute из числа в массив и обратно выявит маленькую проблемку в том, что число элементов в массиве нельзя задать через константный метод. Готовое же решение вгоняет в депрессию - как замена 8 сишных однострочных функций предлагается ебический крейт byteorder, где примерно то же делается в 4, блять, тысячи строк.
Может, я имею очень специфический опыт Ржавого, но у меня остается впечатление, что для системного софта язык этот медленный и сложный, а для прикладного в нём слишком много заморочек, мешающих просто писать код. Кмк, лучше бы чем оптимизировать вообще всё, сделали бы, как в Свифте, управление памятью через счётчик ссылок, а для чувствительных участков кода оставили возможность управления памятью вручную. А сейчас получается, что Ржавый позволяет удобно писать только то, в чём и на Крестах обосраться сложно, а то, что и так сложное, делается пиздец сложным и медленным.
В общем, реальность оказалась грустнее ожиданий.
Ржавый обещает безопасное системное программирование, но безопасное оно с ним только в самом узком смысле - как защита от хакеров. Надёжным код от этого не становится - выход за границу массива на этапе компиляции никак не отслеживается, поэтому софт на Ржавом падает с таким же грохотом, что и софт на Си или на Джаве.
Хуже того, ради этой безопасности тратится время на всякие проверки и счетчики ссылок, а структуры данных с неясной борроу-чекеру семантикой владения превращаются в кромешный пиздец, как в примере с двусвязным списком, в котором изнихуя появляется unsafe дрочены или rc с refcell точены. То, что на Си пишет первокурсник, на Расте требует матёрого аксакала.
И даже если игнорировать танцы с борроу-чекером, сам язык, как бы это сказать, не фонтан. Элементарная задача - поменять порядок байт в числе при помощи шаблонной функции - выносит мозг похлеще разработки видеокодеков. Серьезно, стандартные функции from/to_be_bytes в шаблоне не используешь никак, т.к. они часть конкретных типов, а не единого трейта. Попытка же сделать transmute из числа в массив и обратно выявит маленькую проблемку в том, что число элементов в массиве нельзя задать через константный метод. Готовое же решение вгоняет в депрессию - как замена 8 сишных однострочных функций предлагается ебический крейт byteorder, где примерно то же делается в 4, блять, тысячи строк.
Может, я имею очень специфический опыт Ржавого, но у меня остается впечатление, что для системного софта язык этот медленный и сложный, а для прикладного в нём слишком много заморочек, мешающих просто писать код. Кмк, лучше бы чем оптимизировать вообще всё, сделали бы, как в Свифте, управление памятью через счётчик ссылок, а для чувствительных участков кода оставили возможность управления памятью вручную. А сейчас получается, что Ржавый позволяет удобно писать только то, в чём и на Крестах обосраться сложно, а то, что и так сложное, делается пиздец сложным и медленным.
В общем, реальность оказалась грустнее ожиданий.
Аноны, а не кажется ли вам, что нас где-то цинично наебали?
Ржавый обещает безопасное системное программирование, но безопасное оно с ним только в самом узком смысле - как защита от хакеров. Надёжным код от этого не становится - выход за границу массива на этапе компиляции никак не отслеживается, поэтому софт на Ржавом падает с таким же грохотом, что и софт на Си или на Джаве.
Хуже того, ради этой безопасности тратится время на всякие проверки и счетчики ссылок, а структуры данных с неясной борроу-чекеру семантикой владения превращаются в кромешный пиздец, как в примере с двусвязным списком, в котором изнихуя появляется unsafe дрочены или rc с refcell точены. То, что на Си пишет первокурсник, на Расте требует матёрого аксакала.
И даже если игнорировать танцы с борроу-чекером, сам язык, как бы это сказать, не фонтан. Элементарная задача - поменять порядок байт в числе при помощи шаблонной функции - выносит мозг похлеще разработки видеокодеков. Серьезно, стандартные функции from/to_be_bytes в шаблоне не используешь никак, т.к. они часть конкретных типов, а не единого трейта. Попытка же сделать transmute из числа в массив и обратно выявит маленькую проблемку в том, что число элементов в массиве нельзя задать через константный метод. Готовое же решение вгоняет в депрессию - как замена 8 сишных однострочных функций предлагается ебический крейт byteorder, где примерно то же делается в 4, блять, тысячи строк.
Может, я имею очень специфический опыт Ржавого, но у меня остается впечатление, что для системного софта язык этот медленный и сложный, а для прикладного в нём слишком много заморочек, мешающих просто писать код. Кмк, лучше бы чем оптимизировать вообще всё, сделали бы, как в Свифте, управление памятью через счётчик ссылок, а для чувствительных участков кода оставили возможность управления памятью вручную. А сейчас получается, что Ржавый позволяет удобно писать только то, в чём и на Крестах обосраться сложно, а то, что и так сложное, делается пиздец сложным и медленным.
В общем, реальность оказалась грустнее ожиданий.
Ржавый обещает безопасное системное программирование, но безопасное оно с ним только в самом узком смысле - как защита от хакеров. Надёжным код от этого не становится - выход за границу массива на этапе компиляции никак не отслеживается, поэтому софт на Ржавом падает с таким же грохотом, что и софт на Си или на Джаве.
Хуже того, ради этой безопасности тратится время на всякие проверки и счетчики ссылок, а структуры данных с неясной борроу-чекеру семантикой владения превращаются в кромешный пиздец, как в примере с двусвязным списком, в котором изнихуя появляется unsafe дрочены или rc с refcell точены. То, что на Си пишет первокурсник, на Расте требует матёрого аксакала.
И даже если игнорировать танцы с борроу-чекером, сам язык, как бы это сказать, не фонтан. Элементарная задача - поменять порядок байт в числе при помощи шаблонной функции - выносит мозг похлеще разработки видеокодеков. Серьезно, стандартные функции from/to_be_bytes в шаблоне не используешь никак, т.к. они часть конкретных типов, а не единого трейта. Попытка же сделать transmute из числа в массив и обратно выявит маленькую проблемку в том, что число элементов в массиве нельзя задать через константный метод. Готовое же решение вгоняет в депрессию - как замена 8 сишных однострочных функций предлагается ебический крейт byteorder, где примерно то же делается в 4, блять, тысячи строк.
Может, я имею очень специфический опыт Ржавого, но у меня остается впечатление, что для системного софта язык этот медленный и сложный, а для прикладного в нём слишком много заморочек, мешающих просто писать код. Кмк, лучше бы чем оптимизировать вообще всё, сделали бы, как в Свифте, управление памятью через счётчик ссылок, а для чувствительных участков кода оставили возможность управления памятью вручную. А сейчас получается, что Ржавый позволяет удобно писать только то, в чём и на Крестах обосраться сложно, а то, что и так сложное, делается пиздец сложным и медленным.
В общем, реальность оказалась грустнее ожиданий.
>>090181
На си/си++ по-умолчанию софт как раз не падает а успешно пишет/читает за пределы буфера. В жаве вроде тоже проверяет.
Вот это да, самый большой недостаток. Особенно на фоне всяких жав, где делают наоборот - загоняют как можно большее количество методов в интерфейсы и конкретные объекты используют по-минимуму.
Можно свой трейт сделать. Что-то вроде https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ccf7c21a835443deb53faf281534c2d0
Возможно есть готовые крейты, где все эти функции уже определены, но написать свой довольно тривиально, а с помощью макросов очень просто определить его для всех нужных типов.
С недавних пор можно. Смотри мой пример выше.
> софт на Ржавом падает с таким же грохотом, что и софт на Си или на Джаве.
На си/си++ по-умолчанию софт как раз не падает а успешно пишет/читает за пределы буфера. В жаве вроде тоже проверяет.
> они часть конкретных типов, а не единого трейта
Вот это да, самый большой недостаток. Особенно на фоне всяких жав, где делают наоборот - загоняют как можно большее количество методов в интерфейсы и конкретные объекты используют по-минимуму.
> стандартные функции from/to_be_bytes в шаблоне не используешь никак, т.к. они часть конкретных типов, а не единого трейта
Можно свой трейт сделать. Что-то вроде https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=ccf7c21a835443deb53faf281534c2d0
Возможно есть готовые крейты, где все эти функции уже определены, но написать свой довольно тривиально, а с помощью макросов очень просто определить его для всех нужных типов.
> число элементов в массиве нельзя задать через константный метод
С недавних пор можно. Смотри мой пример выше.
>>090232
Чего там сложного-то? Рекурсивные макросы - вообще тема. Можно например скобочные арифметические операции делать: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=51219e921547e4acb3713399b7f154fe
Каждые круглые скобки () прибавляют единицу, квадратные [] - отнимают. (((3))) равно 6. Жалко только наружные скобки внутри макросов неразличимы и они могут быть любыми.
Чего там сложного-то? Рекурсивные макросы - вообще тема. Можно например скобочные арифметические операции делать: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=51219e921547e4acb3713399b7f154fe
Каждые круглые скобки () прибавляют единицу, квадратные [] - отнимают. (((3))) равно 6. Жалко только наружные скобки внутри макросов неразличимы и они могут быть любыми.
>>090232
А вообще вот гайд по макросам в коде: https://danielkeep.github.io/tlborm/book/mbe-macro-rules.html
Там вообще всё просто.
А вообще вот гайд по макросам в коде: https://danielkeep.github.io/tlborm/book/mbe-macro-rules.html
Там вообще всё просто.
>>090090
Бля, вы тут все ёбнулись. Именно для того чтобы имплементация определяла тип, сделали ассоциированные типы для трейтов.
Иди и посмотри как сделан std::convert::TryFrom или std::str::FromStr, а потом делай по образу и подобию.
Бля, вы тут все ёбнулись. Именно для того чтобы имплементация определяла тип, сделали ассоциированные типы для трейтов.
Иди и посмотри как сделан std::convert::TryFrom или std::str::FromStr, а потом делай по образу и подобию.
Такой вопрос, я на джаве пишу давно, надоело, хотя и платят норм. Хочу в нативщину. Думаю, либо плюсы вспоминать (10 лет на них не писал). Либо раст учить. Ясно-понятно что раст модный-молодежный-безопасный. Но интересен мне не сам язык, а проекты, которые я смогу делать на нем. На плюсах все еще много крутых вещей пишется (rocksdb, clickhouse, половина яндекса на них). Как думаете, реально проекты в нормальных компаниях на расте будут в ближайшие годы? Не крипто-муть, и не чисто новость "в гугл фуксии теперь можно писать на раст". А чтобы был массовый найм, как есть со всеми мейнстрим языками сейчас.
>>090191
В Си - не падает, да, но в современном Си++ всё же обычно пишут так, чтобы на такое не напороться, используя ту же самую проверку границ или просто обход элементов, а не индексов. Когда же используется что-то типа for, проверку границ можно сделать вручную.
И тут всплывает недостаток Раста: если границы массива или слайса не определены на этапе компиляции, то они будут проверятся для каждого элемента, а не все скопом. Пишешь горячий метод? Тут не только unsafe нужен, тут ещё инкапсуляцию придется нарушить, т.к. из уже написанного метода проверку границ не выкинешь.
Спасибо за пример макро, очень толково. Но смотри, сколько бы геморроя можно было бы избежать, если бы бы:
a) трейты можно было специализировать выбором из типов (условно: fn from_le<T: u8 | u16 | u32 | u64>(val: T) { return val.from_le(); } или
б) трейты поддерживали бы утиную типизацию (fn from_le<T>(val: T) { return val.from_le(); }
Сейчас утиную типизацию поддерживают макро, но они оставляют лазейку - если через интерфейс доступны необработанные данные, их можно случайно вытащить, забыв вызвать макро.
Тут, кмк, проглядывает философия Раста: его авторы уже решили за меня, как должна быть устроена моя программа, и если я не вписываюсь в их мир розовых пони, то мой код обязательно должен превратиться в говно. На примере того же unsafe: язык обеспечивает некоторые гарантии, но они постепенно испаряются с каждым unsafe, и в крупном проекте их могут быть тысячи.
Нет, я имею ввиду, через метод, вычислимый во время компиляции. Я пробовал что-то типа std::mem::transmute::<[u8; std::mem::size_of::<T>()], T>. В Си++ я часто сталкивался с тем, что особо заумную конструкцию из шаблонов невозможно было дописать из-за маленького нюанса языка, но шаблоны в Расте в сравнении с Си++ - это как арифметика против матана, и всё равно я упираюсь в непринципиальные ограничения.
Попробую сформулировать: Раст пиарится как современный системный язык, но по фичам он застыл между Go и Си++03, если не ниже, и писать на нём приходится самый тупой код. Я даже могу представить себе впечатления шарписта, который придёт писать на Расте. Это как перейти с Си++ обратно на Си - каждый раз проверяешь, не вырос ли клоунский колпак на голове от постоянного заката солнца вручную.
> На си/си++ по-умолчанию софт как раз не падает
В Си - не падает, да, но в современном Си++ всё же обычно пишут так, чтобы на такое не напороться, используя ту же самую проверку границ или просто обход элементов, а не индексов. Когда же используется что-то типа for, проверку границ можно сделать вручную.
И тут всплывает недостаток Раста: если границы массива или слайса не определены на этапе компиляции, то они будут проверятся для каждого элемента, а не все скопом. Пишешь горячий метод? Тут не только unsafe нужен, тут ещё инкапсуляцию придется нарушить, т.к. из уже написанного метода проверку границ не выкинешь.
> Особенно на фоне всяких жав, где делают наоборот - загоняют как можно большее количество методов в интерфейсы и конкретные объекты используют по-минимуму.
> с помощью макросов очень просто определить его для всех нужных типов
Спасибо за пример макро, очень толково. Но смотри, сколько бы геморроя можно было бы избежать, если бы бы:
a) трейты можно было специализировать выбором из типов (условно: fn from_le<T: u8 | u16 | u32 | u64>(val: T) { return val.from_le(); } или
б) трейты поддерживали бы утиную типизацию (fn from_le<T>(val: T) { return val.from_le(); }
Сейчас утиную типизацию поддерживают макро, но они оставляют лазейку - если через интерфейс доступны необработанные данные, их можно случайно вытащить, забыв вызвать макро.
Тут, кмк, проглядывает философия Раста: его авторы уже решили за меня, как должна быть устроена моя программа, и если я не вписываюсь в их мир розовых пони, то мой код обязательно должен превратиться в говно. На примере того же unsafe: язык обеспечивает некоторые гарантии, но они постепенно испаряются с каждым unsafe, и в крупном проекте их могут быть тысячи.
> С недавних пор можно. Смотри мой пример выше.
Нет, я имею ввиду, через метод, вычислимый во время компиляции. Я пробовал что-то типа std::mem::transmute::<[u8; std::mem::size_of::<T>()], T>. В Си++ я часто сталкивался с тем, что особо заумную конструкцию из шаблонов невозможно было дописать из-за маленького нюанса языка, но шаблоны в Расте в сравнении с Си++ - это как арифметика против матана, и всё равно я упираюсь в непринципиальные ограничения.
Попробую сформулировать: Раст пиарится как современный системный язык, но по фичам он застыл между Go и Си++03, если не ниже, и писать на нём приходится самый тупой код. Я даже могу представить себе впечатления шарписта, который придёт писать на Расте. Это как перейти с Си++ обратно на Си - каждый раз проверяешь, не вырос ли клоунский колпак на голове от постоянного заката солнца вручную.
>>090191
В Си - не падает, да, но в современном Си++ всё же обычно пишут так, чтобы на такое не напороться, используя ту же самую проверку границ или просто обход элементов, а не индексов. Когда же используется что-то типа for, проверку границ можно сделать вручную.
И тут всплывает недостаток Раста: если границы массива или слайса не определены на этапе компиляции, то они будут проверятся для каждого элемента, а не все скопом. Пишешь горячий метод? Тут не только unsafe нужен, тут ещё инкапсуляцию придется нарушить, т.к. из уже написанного метода проверку границ не выкинешь.
Спасибо за пример макро, очень толково. Но смотри, сколько бы геморроя можно было бы избежать, если бы бы:
a) трейты можно было специализировать выбором из типов (условно: fn from_le<T: u8 | u16 | u32 | u64>(val: T) { return val.from_le(); } или
б) трейты поддерживали бы утиную типизацию (fn from_le<T>(val: T) { return val.from_le(); }
Сейчас утиную типизацию поддерживают макро, но они оставляют лазейку - если через интерфейс доступны необработанные данные, их можно случайно вытащить, забыв вызвать макро.
Тут, кмк, проглядывает философия Раста: его авторы уже решили за меня, как должна быть устроена моя программа, и если я не вписываюсь в их мир розовых пони, то мой код обязательно должен превратиться в говно. На примере того же unsafe: язык обеспечивает некоторые гарантии, но они постепенно испаряются с каждым unsafe, и в крупном проекте их могут быть тысячи.
Нет, я имею ввиду, через метод, вычислимый во время компиляции. Я пробовал что-то типа std::mem::transmute::<[u8; std::mem::size_of::<T>()], T>. В Си++ я часто сталкивался с тем, что особо заумную конструкцию из шаблонов невозможно было дописать из-за маленького нюанса языка, но шаблоны в Расте в сравнении с Си++ - это как арифметика против матана, и всё равно я упираюсь в непринципиальные ограничения.
Попробую сформулировать: Раст пиарится как современный системный язык, но по фичам он застыл между Go и Си++03, если не ниже, и писать на нём приходится самый тупой код. Я даже могу представить себе впечатления шарписта, который придёт писать на Расте. Это как перейти с Си++ обратно на Си - каждый раз проверяешь, не вырос ли клоунский колпак на голове от постоянного заката солнца вручную.
> На си/си++ по-умолчанию софт как раз не падает
В Си - не падает, да, но в современном Си++ всё же обычно пишут так, чтобы на такое не напороться, используя ту же самую проверку границ или просто обход элементов, а не индексов. Когда же используется что-то типа for, проверку границ можно сделать вручную.
И тут всплывает недостаток Раста: если границы массива или слайса не определены на этапе компиляции, то они будут проверятся для каждого элемента, а не все скопом. Пишешь горячий метод? Тут не только unsafe нужен, тут ещё инкапсуляцию придется нарушить, т.к. из уже написанного метода проверку границ не выкинешь.
> Особенно на фоне всяких жав, где делают наоборот - загоняют как можно большее количество методов в интерфейсы и конкретные объекты используют по-минимуму.
> с помощью макросов очень просто определить его для всех нужных типов
Спасибо за пример макро, очень толково. Но смотри, сколько бы геморроя можно было бы избежать, если бы бы:
a) трейты можно было специализировать выбором из типов (условно: fn from_le<T: u8 | u16 | u32 | u64>(val: T) { return val.from_le(); } или
б) трейты поддерживали бы утиную типизацию (fn from_le<T>(val: T) { return val.from_le(); }
Сейчас утиную типизацию поддерживают макро, но они оставляют лазейку - если через интерфейс доступны необработанные данные, их можно случайно вытащить, забыв вызвать макро.
Тут, кмк, проглядывает философия Раста: его авторы уже решили за меня, как должна быть устроена моя программа, и если я не вписываюсь в их мир розовых пони, то мой код обязательно должен превратиться в говно. На примере того же unsafe: язык обеспечивает некоторые гарантии, но они постепенно испаряются с каждым unsafe, и в крупном проекте их могут быть тысячи.
> С недавних пор можно. Смотри мой пример выше.
Нет, я имею ввиду, через метод, вычислимый во время компиляции. Я пробовал что-то типа std::mem::transmute::<[u8; std::mem::size_of::<T>()], T>. В Си++ я часто сталкивался с тем, что особо заумную конструкцию из шаблонов невозможно было дописать из-за маленького нюанса языка, но шаблоны в Расте в сравнении с Си++ - это как арифметика против матана, и всё равно я упираюсь в непринципиальные ограничения.
Попробую сформулировать: Раст пиарится как современный системный язык, но по фичам он застыл между Go и Си++03, если не ниже, и писать на нём приходится самый тупой код. Я даже могу представить себе впечатления шарписта, который придёт писать на Расте. Это как перейти с Си++ обратно на Си - каждый раз проверяешь, не вырос ли клоунский колпак на голове от постоянного заката солнца вручную.
>>090385
Кмк, ждать этого не стоит. Нативное программирование сейчас почти умерло - выгоднее нагнать студентов на очередной веб-стартап, чем писать под десктоп с неясными перспективами. Ты ведь и сам, наверное, брезгуешь искать новый софт в Windows Store? При этом код на Расте пишется медленнее чем даже на Си++, а из последнего все компании ещё в 90-е сбежали на более дешевую в разработке Яву. Перспектив, кроме как в написании микросервисов, библиотек, или в хардкорном системном программировании, я не вижу.
> Как думаете, реально проекты в нормальных компаниях на расте будут в ближайшие годы? Не крипто-муть, и не чисто новость "в гугл фуксии теперь можно писать на раст". А чтобы был массовый найм, как есть со всеми мейнстрим языками сейчас
Кмк, ждать этого не стоит. Нативное программирование сейчас почти умерло - выгоднее нагнать студентов на очередной веб-стартап, чем писать под десктоп с неясными перспективами. Ты ведь и сам, наверное, брезгуешь искать новый софт в Windows Store? При этом код на Расте пишется медленнее чем даже на Си++, а из последнего все компании ещё в 90-е сбежали на более дешевую в разработке Яву. Перспектив, кроме как в написании микросервисов, библиотек, или в хардкорном системном программировании, я не вижу.
>>090232
Просто думай о макросах, как об обобщении функций: если функция в аргументах принимает только выражения, то макро может принять и тип, и имя, и вообще что угодно.
Просто думай о макросах, как об обобщении функций: если функция в аргументах принимает только выражения, то макро может принять и тип, и имя, и вообще что угодно.
>>090389
assert!(idx <= v.len());
while i < idx {
println!("{}", v); // тут без проверки, если что
i *= i;
}
Та же самая херня, что и в крестах, только если ты забудешь assert поставить, у тебя не нога оторвётся, а программа просто медленнее работать будет.
Уже сделано: https://docs.rs/funty/1.2.0/funty/trait.IsInteger.html#tymethod.from_le
Но конкретно из байтов нельзя так сделать, потому что массивы с разными размерами в расте — это разные типы. Изволь писать всякие
fn try_from_le_bytes(s: &[u8]) -> Result<Self, ()>
если конкретно трейтами хочешь, а не макросами.
В расте нет шаблонов, ебись с процедурными макросами, если хочешь похожую с шаблонами функциональность.
>то они будут проверятся для каждого элемента, а не все скопом
assert!(idx <= v.len());
while i < idx {
println!("{}", v); // тут без проверки, если что
i *= i;
}
Та же самая херня, что и в крестах, только если ты забудешь assert поставить, у тебя не нога оторвётся, а программа просто медленнее работать будет.
>сколько бы геморроя можно было бы избежать, если бы бы:
>a) трейты можно было специализировать выбором из типов (условно: fn from_le
Уже сделано: https://docs.rs/funty/1.2.0/funty/trait.IsInteger.html#tymethod.from_le
Но конкретно из байтов нельзя так сделать, потому что массивы с разными размерами в расте — это разные типы. Изволь писать всякие
fn try_from_le_bytes(s: &[u8]) -> Result<Self, ()>
если конкретно трейтами хочешь, а не макросами.
>но шаблоны в Расте
В расте нет шаблонов, ебись с процедурными макросами, если хочешь похожую с шаблонами функциональность.
>>090410
Блядский двач опять сожрал скобки
>println!("{}", *v.index(i)); // тут без проверки, если что
Блядский двач опять сожрал скобки
>>090274
Точно, спасибо, анон. Кодить поздно ночью - вредно, забываешь про очевидные вещи.
Точно, спасибо, анон. Кодить поздно ночью - вредно, забываешь про очевидные вещи.
>>090404
У джавы микросервис-проекты активно откусывает голэнг в данный момент.
У джавы микросервис-проекты активно откусывает голэнг в данный момент.
>>090410
Так это вырожденный пример - v.len() эквивалентен пробитию абстракции нижележащего хранилища. Если взять не vec, а какую-нибудь deque, то ты так легко не отделаешься.
Ну да, сделано через impl для трейта. Анон выше привел аналогичную реализацию. В byteorder сделано также. Но это адов пиздец - вместо одного обобщенного метода писать эту ебанину с макросами для каждого конкретного случая. Вместо утиной типизации с опциональным указанием конкретных трейтов имеем обязаловку. Блядь, по мнению авторов, если я напишу просто fn add<T>(a: T, b: T) -> T { a + b } без указания трейтов, Луна ебанётся на землю, или что?
Ну, формально, их нет нигде кроме Си++ и, может Nemerle? :)
> Та же самая херня, что и в крестах, только если ты забудешь assert поставить, у тебя не нога оторвётся, а программа просто медленнее работать будет.
Так это вырожденный пример - v.len() эквивалентен пробитию абстракции нижележащего хранилища. Если взять не vec, а какую-нибудь deque, то ты так легко не отделаешься.
> Уже сделано
Ну да, сделано через impl для трейта. Анон выше привел аналогичную реализацию. В byteorder сделано также. Но это адов пиздец - вместо одного обобщенного метода писать эту ебанину с макросами для каждого конкретного случая. Вместо утиной типизации с опциональным указанием конкретных трейтов имеем обязаловку. Блядь, по мнению авторов, если я напишу просто fn add<T>(a: T, b: T) -> T { a + b } без указания трейтов, Луна ебанётся на землю, или что?
> В расте нет шаблонов
Ну, формально, их нет нигде кроме Си++ и, может Nemerle? :)
>>090389
Такую хуйню можно сделать процедурным макросом. Правда будет мегапердольно.
Тут на самом деле две проблемы.
Первая - трансмют не умеет работать с генериками - https://github.com/rust-lang/rust/issues/61956 То есть даже std::mem::transmute::<T, T>(...) выдаст ошибку, несмотря на то, что T очевидно равен по размеру самому себе. Тут либо использовать объединения (Си-стайл) либо трансмутить ссылки, а не сами объекты (т.е. std::mem::transmute::<&[u8; {std::mem::size_of::<T>()}], &T>)
Вторая - сложные вычисления внутри константных генериков пока не разрешены - https://github.com/rust-lang/rust/issues/76560
Хуй знает когда стабилизируют, но в найтли версии уже работает (хотф и ругается, что фича нестабильна и даже в ночнушке не стоит её использовать). Вот мой пример с объединениями и сложными вычислениями: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58dd9dd948a74c00e9d5b554042fa22d
> a) трейты можно было специализировать выбором из типов (условно: fn from_le<T: u8 | u16 | u32 | u64>(val: T) { return val.from_le(); } или
Такую хуйню можно сделать процедурным макросом. Правда будет мегапердольно.
> Я пробовал что-то типа std::mem::transmute::<[u8; std::mem::size_of::<T>()], T>
Тут на самом деле две проблемы.
Первая - трансмют не умеет работать с генериками - https://github.com/rust-lang/rust/issues/61956 То есть даже std::mem::transmute::<T, T>(...) выдаст ошибку, несмотря на то, что T очевидно равен по размеру самому себе. Тут либо использовать объединения (Си-стайл) либо трансмутить ссылки, а не сами объекты (т.е. std::mem::transmute::<&[u8; {std::mem::size_of::<T>()}], &T>)
Вторая - сложные вычисления внутри константных генериков пока не разрешены - https://github.com/rust-lang/rust/issues/76560
Хуй знает когда стабилизируют, но в найтли версии уже работает (хотф и ругается, что фича нестабильна и даже в ночнушке не стоит её использовать). Вот мой пример с объединениями и сложными вычислениями: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=58dd9dd948a74c00e9d5b554042fa22d
>>090429
И, кстати, я не знаю всегда ли yoba_transmute валидна или нет (но сделать её unsafe в любом случае надо). Там ведь ещё и выравнивания и прочая хуйня может быть, которая после подобного трансмута станет UB.
> Вот мой пример с объединениями
И, кстати, я не знаю всегда ли yoba_transmute валидна или нет (но сделать её unsafe в любом случае надо). Там ведь ещё и выравнивания и прочая хуйня может быть, которая после подобного трансмута станет UB.
>>090429
И небезопасно при этом - сами данные для этого должны торчать наружу, в отличие от трейта.
Ты ведь понимаешь, что такой код не очень вдохновляет, да? Тут ведь вопрос не в том, реализуемо ли это вообще, а в засорении бизнес-логики такими костылями. И опять unsafe. Хоть одна сколько-нибудь крупная программа без него обходится?
> Такую хуйню можно сделать процедурным макросом. Правда будет мегапердольно.
И небезопасно при этом - сами данные для этого должны торчать наружу, в отличие от трейта.
> Вот мой пример с объединениями и сложными вычислениями
Ты ведь понимаешь, что такой код не очень вдохновляет, да? Тут ведь вопрос не в том, реализуемо ли это вообще, а в засорении бизнес-логики такими костылями. И опять unsafe. Хоть одна сколько-нибудь крупная программа без него обходится?
>>090449
Не, безопасно (можно сделать без единого ансейфа). По сути будет аналог дак-тайпинга из С++, правда ошибки будут ещё запутанней.
Потому трансмутят обычно просто ссылки (оригинал при этом не трогают). Либо работают сразу с массивами, а не готовыми объектами. Просто трансмутить сам объект чревато неявными UB (включая невызов деструктора).
> И небезопасно при этом
Не, безопасно (можно сделать без единого ансейфа). По сути будет аналог дак-тайпинга из С++, правда ошибки будут ещё запутанней.
> Ты ведь понимаешь, что такой код не очень вдохновляет, да?
Потому трансмутят обычно просто ссылки (оригинал при этом не трогают). Либо работают сразу с массивами, а не готовыми объектами. Просто трансмутить сам объект чревато неявными UB (включая невызов деструктора).
>>090452
Я-то изначально хотел сделать преобразование в be/le, и казалось, что решение должно быть простым. А оно вон как получается.
В общем, спасибо за примеры - всё примерно так как я и думал. Сейчас я удалюсь и, наверное, почитаю спеки на Swift - интересно, как те же проблемы решаются там.
> Просто трансмутить сам объект чревато неявными UB (включая невызов деструктора).
Я-то изначально хотел сделать преобразование в be/le, и казалось, что решение должно быть простым. А оно вон как получается.
В общем, спасибо за примеры - всё примерно так как я и думал. Сейчас я удалюсь и, наверное, почитаю спеки на Swift - интересно, как те же проблемы решаются там.
>>090410
Знаешь, анон, похоже Расту похуй на ассерты. Вот пример: https://godbolt.org/z/T7WWjK98x - ассертов вроде достаточно, а проверка границ не убирается. Ну хотя бы каждую итерацию она не делается - и то хорошо.
Знаешь, анон, похоже Расту похуй на ассерты. Вот пример: https://godbolt.org/z/T7WWjK98x - ассертов вроде достаточно, а проверка границ не убирается. Ну хотя бы каждую итерацию она не делается - и то хорошо.
>>090490
В пизде, очевидно. Нехуй пользоваться индексами вместо итераторов, что могу сказать. Пиши хороший код, и всё будет летать.
В пизде, очевидно. Нехуй пользоваться индексами вместо итераторов, что могу сказать. Пиши хороший код, и всё будет летать.
>>090563
Идиоматичный код кстати тоже идёт с проверкой в каждой итерации:
v.iter().skip(from).take(to - from).fold(0, |acc, item| acc + *item as u32)
Вот это отсосец.
Идиоматичный код кстати тоже идёт с проверкой в каждой итерации:
v.iter().skip(from).take(to - from).fold(0, |acc, item| acc + *item as u32)
Вот это отсосец.
>>090563
Знаешь, в чём твоя беда? Ты очень злой. Знаешь, в чём беда Раста? Он реализован в виде тонкой обёртки над LLVM, поэтому в этом конкретном случае он сосёт даже у JIT-ов типа C#. Вот похожий код на ШарпЛабе: бит.ли/3qUnyZa
Надо на досуге сравнить производительность Раста и Свифта - может быть, простоту компилятора Раста не перебьют даже расходы на счётчик ссылок.
Знаешь, в чём твоя беда? Ты очень злой. Знаешь, в чём беда Раста? Он реализован в виде тонкой обёртки над LLVM, поэтому в этом конкретном случае он сосёт даже у JIT-ов типа C#. Вот похожий код на ШарпЛабе: бит.ли/3qUnyZa
Надо на досуге сравнить производительность Раста и Свифта - может быть, простоту компилятора Раста не перебьют даже расходы на счётчик ссылок.
>>090580
upd: а, не, ложная тревога. Свифт тоже сосёт! Пример, да ещё и идиоматичный (смотрите, я выучил Свифт за три минуты!): https://godbolt.org/z/js6v9j914
Хотя я мог бы догадаться - у Свифта единственный известный мне компилятор, способный производить 20-мегабайтные хеллоуворлды.
upd: а, не, ложная тревога. Свифт тоже сосёт! Пример, да ещё и идиоматичный (смотрите, я выучил Свифт за три минуты!): https://godbolt.org/z/js6v9j914
Хотя я мог бы догадаться - у Свифта единственный известный мне компилятор, способный производить 20-мегабайтные хеллоуворлды.
>>090582
Так на фото типичный говнарь же? Или я что-то важное не знаю о представителях нетрадиционных музыкальных предпочтений?
Так на фото типичный говнарь же? Или я что-то важное не знаю о представителях нетрадиционных музыкальных предпочтений?
>>090594
На фото один из растодевелоперов (перекатившийся из раби). Правда сейчас уже ничего не кодит и последний растокоммит у него - изменение имени в растовской репе с Шона на Сейдж.
>>090592
Мог бы. Оба основаны на ллвм и перекладывают на ллвм большую часть работы. А ллвм уже в свою очередь срёт себе в штаны.
На фото один из растодевелоперов (перекатившийся из раби). Правда сейчас уже ничего не кодит и последний растокоммит у него - изменение имени в растовской репе с Шона на Сейдж.
>>090592
> Хотя я мог бы догадаться
Мог бы. Оба основаны на ллвм и перекладывают на ллвм большую часть работы. А ллвм уже в свою очередь срёт себе в штаны.
>>090592
Разве это не проверка на переполнение регистра (т.е. на integer overflow)? Такое статическим анализом при компиляции не словишь. И да, если отключить проверку на переполнение (arr.reduce(0, +) поменять на arr.reduce(0, &+)), то генерируется нормальный код без двойных проверок да ещё и с SIMD. Раст соснууул.
> add rax, qword ptr [rdi + 8*rdx + 32]
> jo .LBB1_6
Разве это не проверка на переполнение регистра (т.е. на integer overflow)? Такое статическим анализом при компиляции не словишь. И да, если отключить проверку на переполнение (arr.reduce(0, +) поменять на arr.reduce(0, &+)), то генерируется нормальный код без двойных проверок да ещё и с SIMD. Раст соснууул.
>>090598
Я вот в компилеры не лезу - стесняюсь своих скромных знаний. А господин с фотки, видимо, в своём трансвестизме совсем стыд потерял.
Справедливости ради, проверка границ может быть связана с корректностью программ: в обоих языках взят курс на изничтодение UB, так что компилер может честно решать задачу по исполнению программы до последнего, пока она не ёбнет.
Я вот в компилеры не лезу - стесняюсь своих скромных знаний. А господин с фотки, видимо, в своём трансвестизме совсем стыд потерял.
Справедливости ради, проверка границ может быть связана с корректностью программ: в обоих языках взят курс на изничтодение UB, так что компилер может честно решать задачу по исполнению программы до последнего, пока она не ёбнет.
>>090604
Знаешь, а ты прав, конечно. Другое дело, что код реально всратый - надеюсь, внутри выражений он такие "оптимизации" не проводит, иначе функциональный код перестанет помещаться в кэш.
Знаешь, а ты прав, конечно. Другое дело, что код реально всратый - надеюсь, внутри выражений он такие "оптимизации" не проводит, иначе функциональный код перестанет помещаться в кэш.
>>090568
Это нихуя не идиоматичный код.
v.get(from..to)?.iter().fold(0, |acc, item| acc + *item as u32)
Вот это — идиоматичный код.
Это нихуя не идиоматичный код.
v.get(from..to)?.iter().fold(0, |acc, item| acc + *item as u32)
Вот это — идиоматичный код.
>>090609
Идиоматичный. Другое дело, что все эти крики про ZERO-COST итераторы - пук в лужу. Хоть итераторы и хранят размер массива и передают его дальше по цеопчке, компилятор (или ллвм) эту информацию не используют.
> Это нихуя не идиоматичный код.
Идиоматичный. Другое дело, что все эти крики про ZERO-COST итераторы - пук в лужу. Хоть итераторы и хранят размер массива и передают его дальше по цеопчке, компилятор (или ллвм) эту информацию не используют.
>>090613
Ало, ты размер не проверил перед созданием итератора, что ты блять хотел, UB получить в safe коде? `take` может и меньше выданного ему числа итераций совершить, если что, потому и проверки.
Ало, ты размер не проверил перед созданием итератора, что ты блять хотел, UB получить в safe коде? `take` может и меньше выданного ему числа итераций совершить, если что, потому и проверки.
>>090615
Итератор знает размер массива, потому что итератор vec'а имплементирует https://doc.rust-lang.org/std/iter/trait.ExactSizeIterator.html
ExactSizeIterator специально для этого и создавался, он передаёт размер итератора дальше по цепочке и в любой момент (кроме модификаций, при которых размер меняется например flat_map) этот размер известен.
> ты размер не проверил перед созданием итератора
Итератор знает размер массива, потому что итератор vec'а имплементирует https://doc.rust-lang.org/std/iter/trait.ExactSizeIterator.html
ExactSizeIterator специально для этого и создавался, он передаёт размер итератора дальше по цепочке и в любой момент (кроме модификаций, при которых размер меняется например flat_map) этот размер известен.
Аноны, пока у вас тут научный диспут, позволю себе рекламную паузу: rls для лохов, rust-analyzer - выбор мастеров. Помните это, когда вас тоже заебёт отваливающаяся проверка ошибок. Спасибо за внимание.
>>090617
Уточню - модификаций, при которых размер меняется на неизвестное значение.
> кроме модификаций, при которых размер меняется например flat_map
Уточню - модификаций, при которых размер меняется на неизвестное значение.
Здравствуйте. Насколько реально выучить Rust если знаний в области программирования нет никаких? Сложилось впечатление что c++ морально устарел и все программы переходят на rust. Discord, tor и т.п.
>>091314
Учи лучше жс. В расте работы для совсем нюфагов скорее всего ещё долго (возможно никогда) не будет.
Учи лучше жс. В расте работы для совсем нюфагов скорее всего ещё долго (возможно никогда) не будет.
>>091317
Это не так. Работа есть. Если программист не может быть самозянатым, то это плохой программист.
Это не так. Работа есть. Если программист не может быть самозянатым, то это плохой программист.
>>091321
С ЖСом (а точнее его братом-близнецом ТСом) самозанятым тоже быть проще.
С ЖСом (а точнее его братом-близнецом ТСом) самозанятым тоже быть проще.
>>017017 (OP)
Есть какие-то преимущества шарписту вкатиться в раст?
Есть какие-то преимущества шарписту вкатиться в раст?
Альтернативные компиляторы кто-нибудь пробовал юзать? Как работают?
>>091314
Нереально и ненужно. Раст нужен только для системного программирования, а оно в наше время почти умерло. Быстрее и полезнее будет выучить JS.
>>091321
Это неправда. Не у всех нас специализации позволяют прибыльно фрилансить, а собственный проект, с которого можно жить - это покруче Святого Грааля.
> Насколько реально выучить Rust если знаний в области программирования нет никаких?
Нереально и ненужно. Раст нужен только для системного программирования, а оно в наше время почти умерло. Быстрее и полезнее будет выучить JS.
>>091321
> Если программист не может быть самозянатым, то это плохой программист.
Это неправда. Не у всех нас специализации позволяют прибыльно фрилансить, а собственный проект, с которого можно жить - это покруче Святого Грааля.
>>091325
Есть какие-то преимущества русне поселиться в Махачкале?
> Есть какие-то преимущества шарписту вкатиться в раст?
Есть какие-то преимущества русне поселиться в Махачкале?
>>091838
Из двух часов аж сорок пять минут пиздежа о своей карьере. Блядские зумеры, откуда у них столько времени слушать говорящие головы?
> Интервью с Rust Developer
Из двух часов аж сорок пять минут пиздежа о своей карьере. Блядские зумеры, откуда у них столько времени слушать говорящие головы?
>>091440
Не палишься семен.
Не палишься семен.
100 Кб, 1104x738Здравствуйте. Насколько реально выучить Rust если знаний в области программирования нет никаких? Сложилось впечатление что c++ морально устарел и все программы переходят на rust. Discord, tor и т.п.
>>092000
Не страдай хуйнёй, анон, ты просто заебёшься и дропнешь нихуя не изучив.
Раст — хороший язык, когда он хотя бы 3-й и у тебя уже есть хотя бы крепкая база и какой-то опыт, но точно никак не первый.
>Насколько реально выучить Rust если знаний в области программирования нет никаких?
Не страдай хуйнёй, анон, ты просто заебёшься и дропнешь нихуя не изучив.
Раст — хороший язык, когда он хотя бы 3-й и у тебя уже есть хотя бы крепкая база и какой-то опыт, но точно никак не первый.
>>092000
Лучше изучи сначала основы С, Rust плох как первый язык
Лучше изучи сначала основы С, Rust плох как первый язык
>>092000
Сейчас главный тренд - это функциональное программирование. И Раст, что мог, перенял из функциональных языков. Но чтобы мышление сразу формировалось в правильном направлении, начинать нужно с хаскеля.
Сейчас главный тренд - это функциональное программирование. И Раст, что мог, перенял из функциональных языков. Но чтобы мышление сразу формировалось в правильном направлении, начинать нужно с хаскеля.
>>091859
Я например работаю и одновременно слушаю.
Я например работаю и одновременно слушаю.
>>092000
Хаскель не учи, нишевая хуйня для математиков и ученных или для илитариев, это вообще другая парадигма, другой мир программирования, другое мышление. Функциональщина ебаная крч. Оставь её для матанов поехавших.
Питон можно, но он скриптовый язык, да и зачем, когда есть Го компилируемый как Раст, а он ближе к Расту. Кто бы что не говорил, да, Го и Раст разные, но все жё они как два брата и похожи. cargo fmt / go fmt, go install, cargo install. Просто у них задачи разные и ниша. Раст системное программированеие, драйвера, ядра, лоу-лвлщина, когда написал 1 раз и на 10 лет надо и чтобы максимум скорость и минимум ресурсы жрало. Движок браузера например писать на нём идеально. А Го это здесь и сейчас, юзерспейс программы для пользователей, есть 2 дня надо сделать чтобы был результат и в продакшн. Ты посмотри ещё кто создавал Го и ахуеешь.
C# и Java два брата акробата сразу нах пушто виртуальная машина это и лагающая хуйня.
C/C++ устарели, можно учить если есть желание познать камплюктор саенс и как работает ПК, но оно тебя выматает нахуй и ты утратишь интерес к кодингу навсегда и не вернешься больше.
Как и если сразу начнешь кодить на Раст, ахуеешь и забросишь навсегда не вернувшись в этот мир.
Поэтому самый короткий путь это Го и потом Раст или Го, js/node.js -> Rust.
Я начинал кодинг с Дельфи, потом Бэйсик, С++ Билдер 6, СиШарп, потом Питон, потом Го, потом Раст. И я несколько раз срывался и забивал хуй на Раст возвращаясь к Го с утроенной силой, потому что Го самый простой и мощный язык что я учил, считаю все языки должны по простоте чтения кода и синтаксиса равнятся на Го. Хотя синтаксис Раста сложный начинаю любить все больше по мере того как втягиваюсь в него.
ЯваСкрипт просто потому что нахуя нужен Питон, когда есть ЯваСкрипт божественный, так он блядь ещё и в 3-5 раза быстрее Питона.
Просто забей хуй и иди по пути JS/Go -> Rust. Кстати на хей в сторону .js забей хуй, это уже давно не тот язык что был.
Хаскель не учи, нишевая хуйня для математиков и ученных или для илитариев, это вообще другая парадигма, другой мир программирования, другое мышление. Функциональщина ебаная крч. Оставь её для матанов поехавших.
Питон можно, но он скриптовый язык, да и зачем, когда есть Го компилируемый как Раст, а он ближе к Расту. Кто бы что не говорил, да, Го и Раст разные, но все жё они как два брата и похожи. cargo fmt / go fmt, go install, cargo install. Просто у них задачи разные и ниша. Раст системное программированеие, драйвера, ядра, лоу-лвлщина, когда написал 1 раз и на 10 лет надо и чтобы максимум скорость и минимум ресурсы жрало. Движок браузера например писать на нём идеально. А Го это здесь и сейчас, юзерспейс программы для пользователей, есть 2 дня надо сделать чтобы был результат и в продакшн. Ты посмотри ещё кто создавал Го и ахуеешь.
C# и Java два брата акробата сразу нах пушто виртуальная машина это и лагающая хуйня.
C/C++ устарели, можно учить если есть желание познать камплюктор саенс и как работает ПК, но оно тебя выматает нахуй и ты утратишь интерес к кодингу навсегда и не вернешься больше.
Как и если сразу начнешь кодить на Раст, ахуеешь и забросишь навсегда не вернувшись в этот мир.
Поэтому самый короткий путь это Го и потом Раст или Го, js/node.js -> Rust.
Я начинал кодинг с Дельфи, потом Бэйсик, С++ Билдер 6, СиШарп, потом Питон, потом Го, потом Раст. И я несколько раз срывался и забивал хуй на Раст возвращаясь к Го с утроенной силой, потому что Го самый простой и мощный язык что я учил, считаю все языки должны по простоте чтения кода и синтаксиса равнятся на Го. Хотя синтаксис Раста сложный начинаю любить все больше по мере того как втягиваюсь в него.
ЯваСкрипт просто потому что нахуя нужен Питон, когда есть ЯваСкрипт божественный, так он блядь ещё и в 3-5 раза быстрее Питона.
Просто забей хуй и иди по пути JS/Go -> Rust. Кстати на хей в сторону .js забей хуй, это уже давно не тот язык что был.
>>092793
Ещё забыл Раст реально никогда не должен быть первым языком. Потому что даже сейчас я его начал изучать и литералли везде вижу пример кода на Го в комментариях, а потом его реализация на Расте и так часто. То есть такое ощущение что нужно знать Го или предполагается что ты уже знаешь хорошо Го, чтоыб писать на Расте. То есть тебе объясняют Раст на примерах Го-кода, это пиздец смешно.
Я на данный момент хочу выйти в такой КПД на Расте, чтобы мог писать также быстро как на Го. Я надеюсь у меня получится и Раст станет моим silver bullet языком на абсолютно все мои прикладные задачи. Хочу писать только на 1-м языке и хорошо его знать, а не 10 разных языков и все плохо знаешь.
C# и java забыл скзаать что это языки прошлого поколения, не трать время, когда есть next gen как Го и Раст за которыми будущее.
Ещё забыл Раст реально никогда не должен быть первым языком. Потому что даже сейчас я его начал изучать и литералли везде вижу пример кода на Го в комментариях, а потом его реализация на Расте и так часто. То есть такое ощущение что нужно знать Го или предполагается что ты уже знаешь хорошо Го, чтоыб писать на Расте. То есть тебе объясняют Раст на примерах Го-кода, это пиздец смешно.
Я на данный момент хочу выйти в такой КПД на Расте, чтобы мог писать также быстро как на Го. Я надеюсь у меня получится и Раст станет моим silver bullet языком на абсолютно все мои прикладные задачи. Хочу писать только на 1-м языке и хорошо его знать, а не 10 разных языков и все плохо знаешь.
C# и java забыл скзаать что это языки прошлого поколения, не трать время, когда есть next gen как Го и Раст за которыми будущее.
>>092000
Зря на дваче спросил, тебя сейчас любители уёбищных языков попытаются из раста переманить.
Охуительно реально, но охуительно долго до реального выхлопа. Раст решает такие проблемы, которые тебе не снились, а крестовикам постоянно снятся в кошмарах. Поэтому тут больше вопрос, чего ты хочешь от программирования, а не реально ли выучить. Чтобы выучить раст, просто берёшь The Book, а потом хуяришь от вступления до самого конца, пописывая код из книги. После The Book выбираешь куда хочешь пойти дальше, и в зависимости от этого читаешь Rustonomicon, гайд по tokio или ещё что-нибудь.
Зря на дваче спросил, тебя сейчас любители уёбищных языков попытаются из раста переманить.
>Насколько реально выучить Rust если знаний в области программирования нет никаких?
Охуительно реально, но охуительно долго до реального выхлопа. Раст решает такие проблемы, которые тебе не снились, а крестовикам постоянно снятся в кошмарах. Поэтому тут больше вопрос, чего ты хочешь от программирования, а не реально ли выучить. Чтобы выучить раст, просто берёшь The Book, а потом хуяришь от вступления до самого конца, пописывая код из книги. После The Book выбираешь куда хочешь пойти дальше, и в зависимости от этого читаешь Rustonomicon, гайд по tokio или ещё что-нибудь.
>>092812
Никто его не отговаривает от Раста лол, а наоборот показываем ему максимально комфортный путь к нему. Самый короткий путь Go -> Rust. Но будет хромать кругозор, потому что будет знать 0 интерпретируемых языков вроде Питона и .js
Никто его не отговаривает от Раста лол, а наоборот показываем ему максимально комфортный путь к нему. Самый короткий путь Go -> Rust. Но будет хромать кругозор, потому что будет знать 0 интерпретируемых языков вроде Питона и .js
>>092812
Например?
>Раст решает такие проблемы, которые тебе не снились, а крестовикам постоянно снятся в кошмарах
Например?
>>092812
Ага да-да, Раст ещё даже не устоялся как язык и быстро меняется.
Я год назад видел Раст код, где писали return, потом мы с другом полгода назад рофлили с того, что там сокращения дикие, ещё более короткие чем в Go, вместо return стал видеть в коде просто r блять. А сейчас вообще блядь просто экспрессия, без r и без return, последняя строка кода это и есть return.
На данный момент все 3 способа работают выше, но сам факт что язык дико и быстро меняется, нахуя новичку в кодинге его учить, чтобы он потом через год полностью поменялся? Вели await? и прочее недавно. Пусть учит Го, а потом на Раст сядет когда стабилизируется. Вот на Го нельзя отличить код 5 летней давности и сегодняшний код, там код всегда выглядит современно и ничего не меняется.
Ага да-да, Раст ещё даже не устоялся как язык и быстро меняется.
Я год назад видел Раст код, где писали return, потом мы с другом полгода назад рофлили с того, что там сокращения дикие, ещё более короткие чем в Go, вместо return стал видеть в коде просто r блять. А сейчас вообще блядь просто экспрессия, без r и без return, последняя строка кода это и есть return.
На данный момент все 3 способа работают выше, но сам факт что язык дико и быстро меняется, нахуя новичку в кодинге его учить, чтобы он потом через год полностью поменялся? Вели await? и прочее недавно. Пусть учит Го, а потом на Раст сядет когда стабилизируется. Вот на Го нельзя отличить код 5 летней давности и сегодняшний код, там код всегда выглядит современно и ничего не меняется.
>>092819
Лайфтаймы и владение
Лайфтаймы и владение
>>092823
Гошники, что же с вами не так
Гошники, что же с вами не так
>>092823
Он не устоялся только в сравнении с Си и Го. Вот обзор изменений за пятилетку, на год устаревший, но по нему все равно видно, что именно новых фич языка не так много:
https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html
Если посмотреть, так await вообще ввели в 2019, а issue появился за год до этого. Понятно, до версии 1.0 язык корёжило - он вообще начинался с GC - но сейчас-то это всё в прошлом. Проблема языка не в том, что он молодой или плохой, а в том, что вся его ниша - это процентов 5 рынка коммерческой разработки, которые он ещё и делит с Си и Си++. На весь hh.ru я в прошлом году видел 1 (одну) вакансию Раст-разработчика. Учить его, если он не решает твои задачи, просто невыгодно.
> Ага да-да, Раст ещё даже не устоялся как язык и быстро меняется.
Он не устоялся только в сравнении с Си и Го. Вот обзор изменений за пятилетку, на год устаревший, но по нему все равно видно, что именно новых фич языка не так много:
https://blog.rust-lang.org/2020/05/15/five-years-of-rust.html
Если посмотреть, так await вообще ввели в 2019, а issue появился за год до этого. Понятно, до версии 1.0 язык корёжило - он вообще начинался с GC - но сейчас-то это всё в прошлом. Проблема языка не в том, что он молодой или плохой, а в том, что вся его ниша - это процентов 5 рынка коммерческой разработки, которые он ещё и делит с Си и Си++. На весь hh.ru я в прошлом году видел 1 (одну) вакансию Раст-разработчика. Учить его, если он не решает твои задачи, просто невыгодно.
Вдогонку, для чего может быть полезен Раст. На днях прочитал интересное интервью от разработчика sqlite:
https://corecursive.com/066-sqlite-with-richard-hipp/
Там есть момент - автор потратил год жизни, работая по 60 часов в неделю, на написание тестов, и тесты эти постоянно роняли не только его код, но и Oracle. И всё равно в sqlite, бывает, находят по 10 уязвимостей в год.
Раст же в большинстве случаев просто не позволит писать опасный код - участки, где он всё-таки используется, будут помечены блоком unsafe. Например, в веб-движке servo, при его размере в 320k строк кода, таких блоков порядка 1700, и это, наверное, самый сложный из возможных случай - unsafe в нём для оптимизации пиздецки сложной многопоточной бизнес-логики.
https://corecursive.com/066-sqlite-with-richard-hipp/
Там есть момент - автор потратил год жизни, работая по 60 часов в неделю, на написание тестов, и тесты эти постоянно роняли не только его код, но и Oracle. И всё равно в sqlite, бывает, находят по 10 уязвимостей в год.
Раст же в большинстве случаев просто не позволит писать опасный код - участки, где он всё-таки используется, будут помечены блоком unsafe. Например, в веб-движке servo, при его размере в 320k строк кода, таких блоков порядка 1700, и это, наверное, самый сложный из возможных случай - unsafe в нём для оптимизации пиздецки сложной многопоточной бизнес-логики.
>>092793
Ну языки всё же сильно разные в возможностях.
На шарпе есть структуры, есть указатели, есть очень низкоуровневые возможности, есть многопоточность в два клика.
Если написать код на шарпе, как на С++, с указателями и ручным управлением памяти (а в шарпе это тоже внезапно есть), то он будет работать так же быстро, как на С++.
Но при этом на шарпе конечно кодить намного приятнее, чем на крестах.
>C# и Java два брата акробата сразу
Ну языки всё же сильно разные в возможностях.
На шарпе есть структуры, есть указатели, есть очень низкоуровневые возможности, есть многопоточность в два клика.
Если написать код на шарпе, как на С++, с указателями и ручным управлением памяти (а в шарпе это тоже внезапно есть), то он будет работать так же быстро, как на С++.
Но при этом на шарпе конечно кодить намного приятнее, чем на крестах.
>>092966
Устройство их одинаковое, оба виртуальные машины и код над ним, оба вышли в одно время, оба ООП-ориентированные, потому что тогда считалось ООП в тренде, как щас в тренде функциональщина. В итоге сейчас снова ценят процедурность больше, а ООП оставили как возможность если хочеца.
Тогда вот считали что будущее будет за таким, теперь они на плаву держатся только потому что в них качают куча денег, на своём поддуве они оба умрут я считаю.
System.Println вот эти вот вызовы даже одинаковые что ява что шарп. Два брата это, которые срутся друг с другом кто из них круче и у кого фич больше.
Устройство их одинаковое, оба виртуальные машины и код над ним, оба вышли в одно время, оба ООП-ориентированные, потому что тогда считалось ООП в тренде, как щас в тренде функциональщина. В итоге сейчас снова ценят процедурность больше, а ООП оставили как возможность если хочеца.
Тогда вот считали что будущее будет за таким, теперь они на плаву держатся только потому что в них качают куча денег, на своём поддуве они оба умрут я считаю.
System.Println вот эти вот вызовы даже одинаковые что ява что шарп. Два брата это, которые срутся друг с другом кто из них круче и у кого фич больше.
>>092969
Ну так ООП для корпоративного софта был и остаётся лучшим вариантом, а это большая часть денег в отрасли. Чистое ФП до сих пор не созрело - в нём слишком много дроча на монады и хитровыебанные системы типов, и слишком мало внимания предметной области. ООП же приближает код к человеческому языку, и позволяет сходу разобраться в любой программе.
Ну так ООП для корпоративного софта был и остаётся лучшим вариантом, а это большая часть денег в отрасли. Чистое ФП до сих пор не созрело - в нём слишком много дроча на монады и хитровыебанные системы типов, и слишком мало внимания предметной области. ООП же приближает код к человеческому языку, и позволяет сходу разобраться в любой программе.
Как кастануть &str, чтобы его могла сожрать extern "C" { fn printf() -> i32 }? Пробовал делать fn printf(inp: &str) оно работает (с оговорками) и жалуется на improper_ctypes
warning: `extern` block uses type `str`, which is not FFI-safe
consider using `const u8` and a length instead
Попробовал fn printf(inp: const u8); let hell = "Hello, World" as const u8;, но тогда ошибка
error[E0606]: casting `&str` as `const u8` is invalid
Вокруг по всякому плясал, но не придумал, как сделать.
warning: `extern` block uses type `str`, which is not FFI-safe
consider using `const u8` and a length instead
Попробовал fn printf(inp: const u8); let hell = "Hello, World" as const u8;, но тогда ошибка
error[E0606]: casting `&str` as `const u8` is invalid
Вокруг по всякому плясал, но не придумал, как сделать.
>>092996
Сишные функции жрут в основном строки оканчивающиеся на ноль. В расте строки на ноль не оканчиваются (потому что у них длина стоит отдельно). Тут без копирования строки во временный буффер никак.
Сишные функции жрут в основном строки оканчивающиеся на ноль. В расте строки на ноль не оканчиваются (потому что у них длина стоит отдельно). Тут без копирования строки во временный буффер никак.
>>093008
Ага, хорошо. Спасибо, что пояснил!
Ага, хорошо. Спасибо, что пояснил!
>>092996
Всё правильно, &str - это слайс строки (указатель начала + указатель конца строки), а в C используется просто указатель на заканчивающуюся \0 строку. Для FFI используется CString и &cstr, CString делается (с копированием) из String или &str. Если ты совсем ебанулся на производительности, то бери слайс &[u8] от String или &str через .to_bytes() и разбей его на указатели перед передачей в функцию.
Всё правильно, &str - это слайс строки (указатель начала + указатель конца строки), а в C используется просто указатель на заканчивающуюся \0 строку. Для FFI используется CString и &cstr, CString делается (с копированием) из String или &str. Если ты совсем ебанулся на производительности, то бери слайс &[u8] от String или &str через .to_bytes() и разбей его на указатели перед передачей в функцию.
>>093014
Я для общего развития тыкаю
(можно было бы и догадаться по использованию printf() в качестве примера)
>Если ты совсем
Я для общего развития тыкаю
(можно было бы и догадаться по использованию printf() в качестве примера)
>>093014
Хотя звучит интересно, спасибо. Можно воспроизводимый пример?
>бери слайс &[u8] от String или &str через .to_bytes() и разбей его на указатели перед передачей в функцию
Хотя звучит интересно, спасибо. Можно воспроизводимый пример?
>>093019
Извини, я пока в FFI не лез. Есть статья от какого-то Хуя, где он исследует все варианты: https://thefullsnack.com/en/string-ffi-rust.html
Извини, я пока в FFI не лез. Есть статья от какого-то Хуя, где он исследует все варианты: https://thefullsnack.com/en/string-ffi-rust.html
>>093031
Спасибо!
Спасибо!
828 Кб, 3328x1868А что так бывает чтоли? 3 дня фармил архипелаг и накопил 1600 примогемов и уотаквот.
>>093078
А ОТ ТАКОГО ВАШИ БОРРОУ ЧЕКИ ЗАЩИТИЛИ БЫ, А?!?!
А ОТ ТАКОГО ВАШИ БОРРОУ ЧЕКИ ЗАЩИТИЛИ БЫ, А?!?!
>>092969
Функциональщина родом из начала 90-х, и из колыбели борщехлёбов она не вылезла и не вылезет никогда.
Нет, мне определённо самому нравится чистый функциональный код. Но проблема в том, что компьютеры работают не так. И какой бы компилятор не был умный, функциональный код в РАЗЫ медленнее.
Функциональщина родом из начала 90-х, и из колыбели борщехлёбов она не вылезла и не вылезет никогда.
Нет, мне определённо самому нравится чистый функциональный код. Но проблема в том, что компьютеры работают не так. И какой бы компилятор не был умный, функциональный код в РАЗЫ медленнее.
>>093084
Почему? Он в какие-то специальные функциональные процессорные инструкции превращается?
>И какой бы компилятор не был умный, функциональный код в РАЗЫ медленнее.
Почему? Он в какие-то специальные функциональные процессорные инструкции превращается?
>>093087
Вот пример qsort на Хаскелле: https://godbolt.org/z/19K756Goo
Я такого тупого говна в жизни не видел.
Вот пример qsort на Хаскелле: https://godbolt.org/z/19K756Goo
Я такого тупого говна в жизни не видел.
>>093106
При чём тут пример? Если на брейнфаке с конкретным компилятором получится не слишком красивый qsort, будет это значить, что
?
>Вот пример
При чём тут пример? Если на брейнфаке с конкретным компилятором получится не слишком красивый qsort, будет это значить, что
>И какой бы компилятор не был умный, процедурный код в РАЗЫ медленнее
?
>>093114
Ну так в этом вся суть ФП - красивый высокопарный пиздёж про теорию категорий и код без ошибок, и вырвиглазное позорище на практике.
> При чём тут пример? Если на брейнфаке с конкретным компилятором получится не слишком красивый qsort, будет это значить, что
Ну так в этом вся суть ФП - красивый высокопарный пиздёж про теорию категорий и код без ошибок, и вырвиглазное позорище на практике.
>>093117
Я взял первый пришедший на ум пример. Какие ко мне претензии?
Я взял первый пришедший на ум пример. Какие ко мне претензии?
353 Кб, 1194x856Девочки, подскажите как убрать отладочную информацию из бинарника. Вроде бы стрипнул, но куча мусора всё равно присутствует.
>>093127
panic = 'abort' в [profile.release], ну и может lto = true до кучи.
~твоя девочка с агромным хуищщем, всё как ты любишь
panic = 'abort' в [profile.release], ну и может lto = true до кучи.
~твоя девочка с агромным хуищщем, всё как ты любишь
130 Кб, 1349x646>>093133
А полностью можно вырезать?
Не очень помогает.
>panic = 'abort' в [profile.release], ну и может lto = true до кучи
А полностью можно вырезать?
>[profile.release]
>opt-level = 'z'
>lto = true
>panic = 'abort'
Не очень помогает.
>>093140
Это не отладочная информация, это ассерты. Их убрать невозможно. Если нужен меньший размер бинарника, есть вариант с еблей с Xargo и сборкой уменьшенной стандартной библиотеки, и всё.
Это не отладочная информация, это ассерты. Их убрать невозможно. Если нужен меньший размер бинарника, есть вариант с еблей с Xargo и сборкой уменьшенной стандартной библиотеки, и всё.
>>093144
Просто не используй ассерты в своём коде и всё. Эта самая хуйня роли не играет, т.к. в дизассемблере стандартные библиотеки распознаются по сигнатурам, отсутствие ассертов им не помешают. Я тут вижу только два варианта: хардкор с #[no_std] или пересборку std с патченым кодом assert-а.
> а там эта хуйня остаётся для ресёрчеров всяких
Просто не используй ассерты в своём коде и всё. Эта самая хуйня роли не играет, т.к. в дизассемблере стандартные библиотеки распознаются по сигнатурам, отсутствие ассертов им не помешают. Я тут вижу только два варианта: хардкор с #[no_std] или пересборку std с патченым кодом assert-а.
>>093146
Очевидно придётся делать это. А нет никакого таргета для embeded, где бы уже было пропатчено? В данный момент интересует только линукс, но с прицелом сборки таргета под вынь.
>пересборку std с патченым кодом assert-а
Очевидно придётся делать это. А нет никакого таргета для embeded, где бы уже было пропатчено? В данный момент интересует только линукс, но с прицелом сборки таргета под вынь.
>>093154
Точно нет, любая платформа, которая потянет libstd, не будет экономить на спичках :) Да и кончай заниматься хуйнёй - перед C в написании малвары у Раста никаких преимуществ.
Точно нет, любая платформа, которая потянет libstd, не будет экономить на спичках :) Да и кончай заниматься хуйнёй - перед C в написании малвары у Раста никаких преимуществ.
Да понятно что сишка топ, но стало модным переписывать на руст, вот и я не хочу отставать. Ладненько, спасибо за советы, девочки.
>>093226
Есть способы снизить вес: https://github.com/johnthagen/min-sized-rust
Так-то Сишка тоже не фонтан - при static линковке хеллоуворлд занимает аж 800КБ. Добро пожаловать в 2021, где всем похуй.
Есть способы снизить вес: https://github.com/johnthagen/min-sized-rust
Так-то Сишка тоже не фонтан - при static линковке хеллоуворлд занимает аж 800КБ. Добро пожаловать в 2021, где всем похуй.
Блядь, третий раз зашёл на изучение раста и просто охуеваю от качества кода. Блядь, нет ни одного другого языка, где бы так относились к вкатывальщикам в этот пиздец. Ладно там docs.rs совершенно неюзабельная параша, такой формат документации ломает судьбы и калечит психику. Но, блядь, для кого вы в ридми пишите примеры использования ваших уебанских библиотек, если вы, блядь, через день меняете название методов и хуй забиваете на документацию? Никто, от плюсанов до джаваскриптопитухов, так не делает. Блядь, четыре часа сижу пытаясь распарсить жсон в структуру с самоподписанным сертификатом и нихуя, блядь, не могу. Чувствую себя полным говном.
Идите вы нахуй со своим пидарастическим языком. никогда, блядь, я к нему больше не притронусь. Сидишь как долбоёб какие-то mut'ы клепаешь вместо продуктивной работы. Пиздец нахуй.
Идите вы нахуй со своим пидарастическим языком. никогда, блядь, я к нему больше не притронусь. Сидишь как долбоёб какие-то mut'ы клепаешь вместо продуктивной работы. Пиздец нахуй.
Есть ли основания полагать, что внутри компилятора Rust'а заложен бэкдор? Не особо понимаю тему, но читал, что там в основе какие-то блобы.
Просто реально подозрительно выглядит его пропихивание во все щели.
Просто реально подозрительно выглядит его пропихивание во все щели.
>>093416
Нет там блобов, он полностью опенсорсный. Если конечно речь не идёт про блобы внутри процессоров, но тогда раст ничем от других языков не отличается.
> там в основе какие-то блобы.
Нет там блобов, он полностью опенсорсный. Если конечно речь не идёт про блобы внутри процессоров, но тогда раст ничем от других языков не отличается.
>>093416
Есть ли основания полагать, что коронавирус — это заговор рептилоидов?
Ну и по теме: кроме rustc есть ещё cranelift, а ещё пилят фронтэнд под GCC. Но в расте просто слишком дохуя всякой хуйни, написать компилятор раста — это не хуй дёрнуть. Там даже парсер синтаксиса должен кучу хуйни распарсить, а уж доказывать лайфтаймы и exhaustiveness паттерн матчинга — это вообще пиздец. Но лично ты можешь считать, что там есть бекдор, и каждый раз когда ты компилируешь свой хелловорлд тебе вскрывают анус.
Есть ли основания полагать, что коронавирус — это заговор рептилоидов?
Ну и по теме: кроме rustc есть ещё cranelift, а ещё пилят фронтэнд под GCC. Но в расте просто слишком дохуя всякой хуйни, написать компилятор раста — это не хуй дёрнуть. Там даже парсер синтаксиса должен кучу хуйни распарсить, а уж доказывать лайфтаймы и exhaustiveness паттерн матчинга — это вообще пиздец. Но лично ты можешь считать, что там есть бекдор, и каждый раз когда ты компилируешь свой хелловорлд тебе вскрывают анус.
89 Кб, 1258x441>>093419
>>093443
Вспомнил, где про это читал:
https://old.reddit.com/r/rust/comments/2tdsev/compilers_with_backdoors/
Получается так, что в основе Rust-компилятора какие-то блобы на OCaml.
>>093443
Вспомнил, где про это читал:
https://old.reddit.com/r/rust/comments/2tdsev/compilers_with_backdoors/
Получается так, что в основе Rust-компилятора какие-то блобы на OCaml.
>>093411
Да обычное там качество кода. Пиздец нахуй - это когда я в Ноде искал LDAP-клиент, и единственный доступный не умел логиниться кроме как через plaintext. Про docs.rs вообще смешно - в Си/Си++, ЖС и Петоне вообще нет общего репозитория документации, самое близкое - readthedocs, в который она заносится вручную. Но я тоже ощущаю, что вместо написания кода я занимаюсь хуйнёй: безопасность работы с памятью не стоит многочасовой ебли с лайфтаймами.
Да обычное там качество кода. Пиздец нахуй - это когда я в Ноде искал LDAP-клиент, и единственный доступный не умел логиниться кроме как через plaintext. Про docs.rs вообще смешно - в Си/Си++, ЖС и Петоне вообще нет общего репозитория документации, самое близкое - readthedocs, в который она заносится вручную. Но я тоже ощущаю, что вместо написания кода я занимаюсь хуйнёй: безопасность работы с памятью не стоит многочасовой ебли с лайфтаймами.
>>093445
Не в основе. Это для бутстрапинга (т.е. создания компилятора с нуля). Версия на окамле тоже была опенсорсной (она и сейчас есть в гит-истории репы). К тому же современный раст можно бутстрапить с мраста, который компилируется любым компилятором Си.
> Получается так, что в основе Rust-компилятора какие-то блобы на OCaml.
Не в основе. Это для бутстрапинга (т.е. создания компилятора с нуля). Версия на окамле тоже была опенсорсной (она и сейчас есть в гит-истории репы). К тому же современный раст можно бутстрапить с мраста, который компилируется любым компилятором Си.
>>093445
Вернее, просто какие-то древние блобы, из которых бустрапят OCaml.
Конечно, такая закладка была бы эпичной.
> какие-то блобы на OCaml
Вернее, просто какие-то древние блобы, из которых бустрапят OCaml.
Конечно, такая закладка была бы эпичной.
62 Кб, 640x362>>093445
Блять, заговор тянется аж с 96 года, пиздец просто.
Блять, заговор тянется аж с 96 года, пиздец просто.
>>093469
Фигачит синхронную функцию, в которой заводит токийский рантайм, и блочит этот рантайм на выданной ему асинхронной функции, пока функция не вернёт результат.
Фигачит синхронную функцию, в которой заводит токийский рантайм, и блочит этот рантайм на выданной ему асинхронной функции, пока функция не вернёт результат.
>>093492
https://docs.rs/reqwest/0.11.4/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_certs
Сама ты блядь, у нас в Ржавом всё по любви, как видишь
https://docs.rs/reqwest/0.11.4/reqwest/struct.ClientBuilder.html#method.danger_accept_invalid_certs
Сама ты блядь, у нас в Ржавом всё по любви, как видишь
>>093492
Проще curl подлкючить через сишные биндинги, нормальных http-клиентов в расте нет.
Проще curl подлкючить через сишные биндинги, нормальных http-клиентов в расте нет.
>>093676
Какой в этом потаённый смысл?
Какой в этом потаённый смысл?
>>093676
Разве что если вместо карго хочешь использовать более мощный базел с полусырой интеграцией с растом: https://github.com/bazelbuild/rules_rust
Ручками делать - мазохизм.
> Забить на карго
Разве что если вместо карго хочешь использовать более мощный базел с полусырой интеграцией с растом: https://github.com/bazelbuild/rules_rust
Ручками делать - мазохизм.
Для го есть либа github.com/go-ping/ping пинг без рута/сеткапа. Есть аналогичная для раста?
>>092800
Переходил с Го на раст еще есть Си\С++-бекграунд. На расте де-факто получается быстрее писать, потому что борроу чекер, человеческая обработка ошибок, коллекции реализованы куда приятнее, чем в ГОвне. Зачастую, как бы странно не звучало, борроу чекер помогает тебе писать быстрее не только с точки зрения мемори-сейфти, но еще и с точки зрения логики. Поэтому, на расте примерно на ~15% быстрее получается писать кодяру.
Не знаю, как это конкретно работает, но часто замечал, что на расте я меньше обсираюсь именно в логике.
перешел с го-веба в раст-мультимедиа
Переходил с Го на раст еще есть Си\С++-бекграунд. На расте де-факто получается быстрее писать, потому что борроу чекер, человеческая обработка ошибок, коллекции реализованы куда приятнее, чем в ГОвне. Зачастую, как бы странно не звучало, борроу чекер помогает тебе писать быстрее не только с точки зрения мемори-сейфти, но еще и с точки зрения логики. Поэтому, на расте примерно на ~15% быстрее получается писать кодяру.
Не знаю, как это конкретно работает, но часто замечал, что на расте я меньше обсираюсь именно в логике.
перешел с го-веба в раст-мультимедиа
Такс, девочки. Поясните, пожалуйста, если я в features говорю использовать rustls, почему тянется openssl-sys? openssl-sys под musl компилится какими-то костылями с гитхаба, которые я не хочу тянуть в систему.
>>093783
Кмк, Раст хорош, когда у тебя нет произвольных ссылок между объектами, а большая часть методов может быть написана в функциональном стиле. Тогда тебе и лайфтаймы кроме 'static указывать не нужно, и сам подход универсален и экономит нервы что в Расте, что в Си++. Тут язык действительно экономит время, т.к. в нём очень многое сделано правильно - те же модули, или возможность определять трейты для любых классов, даже для стандартной библиотеки. Но как только у тебя деревья объектов превращаются в графы объектов, начинается хоррор-стори, и хочется сбежать куда угодно, хоть в Си++, хоть в Го, хоть в Паскаль.
Кмк, Раст хорош, когда у тебя нет произвольных ссылок между объектами, а большая часть методов может быть написана в функциональном стиле. Тогда тебе и лайфтаймы кроме 'static указывать не нужно, и сам подход универсален и экономит нервы что в Расте, что в Си++. Тут язык действительно экономит время, т.к. в нём очень многое сделано правильно - те же модули, или возможность определять трейты для любых классов, даже для стандартной библиотеки. Но как только у тебя деревья объектов превращаются в графы объектов, начинается хоррор-стори, и хочется сбежать куда угодно, хоть в Си++, хоть в Го, хоть в Паскаль.
>>093878
Не начинается. Используешь стандартные (A)Rc<Refcell<...>> и всё работает как надо. Хоррор-стори будет только если ты при этом захочешь избавиться от лишних счётчиков, проверок и выделений памяти. Тогда и приходится пердолиться с ансейф.
> начинается хоррор-стори
Не начинается. Используешь стандартные (A)Rc<Refcell<...>> и всё работает как надо. Хоррор-стори будет только если ты при этом захочешь избавиться от лишних счётчиков, проверок и выделений памяти. Тогда и приходится пердолиться с ансейф.
>>093891
Если бы я не хотел эффективности, я не стал бы ебать себе мозг Растом и ушёл бы на Nim какой-нибудь. Счётчика ссылок было бы достаточно.
Если бы я не хотел эффективности, я не стал бы ебать себе мозг Растом и ушёл бы на Nim какой-нибудь. Счётчика ссылок было бы достаточно.
А как проблема с произвольными ссылками решается в труъ функциональных языках? Во всех них есть GC?
>>094189
Языков без GC очень мало, в общем-то, функциональных без GC вообще нет.
Языков без GC очень мало, в общем-то, функциональных без GC вообще нет.
>>092800
Огромный и тяжелый энтерпрайз так и останется на джаве. Всякие сетевые поделия на говне, системщина на расте. Но бабло все в энтерпрайзе, тем более что у джавы сейчас отличные инструменты и экосистема. Вообще имхо чтобы вкатиться на работку лучше как раз учить жабу и жс, а не го и тем более раст.
>C# и java забыл скзаать что это языки прошлого поколения, не трать время, когда есть next gen как Го и Раст за которыми будущее.
Огромный и тяжелый энтерпрайз так и останется на джаве. Всякие сетевые поделия на говне, системщина на расте. Но бабло все в энтерпрайзе, тем более что у джавы сейчас отличные инструменты и экосистема. Вообще имхо чтобы вкатиться на работку лучше как раз учить жабу и жс, а не го и тем более раст.
>>092969
Внезапно, от ООП никуда так и не ушли, так как функциональщина и процедурность хуже подходят для построения рабочего софта. ООП повсюду. Если на фронтенде и на каких-нибудь пхп серверах его немного, то вот настоящий бекенд для огромных корпорация полностью завязан на ООП, так как это самый лучший вариант выразить бизнес-логику в коде.
>ООП
Внезапно, от ООП никуда так и не ушли, так как функциональщина и процедурность хуже подходят для построения рабочего софта. ООП повсюду. Если на фронтенде и на каких-нибудь пхп серверах его немного, то вот настоящий бекенд для огромных корпорация полностью завязан на ООП, так как это самый лучший вариант выразить бизнес-логику в коде.
>>094629
Процедурность понятно, а чем функциональщина плоха? Особенно в языках, в которых компиляция == корректная работа программы. Мне кажется что функциональщина просто слишком сложна для армии индусов и порриджей которые пилят современное ПО.
Процедурность понятно, а чем функциональщина плоха? Особенно в языках, в которых компиляция == корректная работа программы. Мне кажется что функциональщина просто слишком сложна для армии индусов и порриджей которые пилят современное ПО.
>>094869
Функциональность обычно ещё и очень медленная из-за её любви к иммутабельности, что выражается в том, иногда необходимо копировать кучу информации. Например если надо изменить один элемент массива очень желательно скопировать весь массив и уже в новом изменить элемент. Обычно решается всякими особенными коллекциями (например связанными списками вместо массивов), но из-за особенностей современных пекарен (относительно медленная память+быстрые кеши внутри процессоров) массивы работают гораздо быстрее (если сумеют полностью вместиться в кеш).
Функциональность обычно ещё и очень медленная из-за её любви к иммутабельности, что выражается в том, иногда необходимо копировать кучу информации. Например если надо изменить один элемент массива очень желательно скопировать весь массив и уже в новом изменить элемент. Обычно решается всякими особенными коллекциями (например связанными списками вместо массивов), но из-за особенностей современных пекарен (относительно медленная память+быстрые кеши внутри процессоров) массивы работают гораздо быстрее (если сумеют полностью вместиться в кеш).
>>094869
Обычно функциональщики как и ООП дауны слепо верят парадигме и отрицают любые аргументы против их подхода.
Но небыдло такое как я уже давно всё поняло, и юзает всякие OCaml/F# франкенштейны в продакшене, где когда нужно - вытаскиваются поинтеры из темных подземелий или мутабельные коллекции, а где нужна корректность программ и чистота кода - пишут на чистом ФП.
Борщи бугуртят, быдло не осиливает, пока мы на двух стульях на самом деле там 3+ стула сидим и разминаем простату, получая от этого удовольствие.
Обычно функциональщики как и ООП дауны слепо верят парадигме и отрицают любые аргументы против их подхода.
Но небыдло такое как я уже давно всё поняло, и юзает всякие OCaml/F# франкенштейны в продакшене, где когда нужно - вытаскиваются поинтеры из темных подземелий или мутабельные коллекции, а где нужна корректность программ и чистота кода - пишут на чистом ФП.
Борщи бугуртят, быдло не осиливает, пока мы на двух стульях на самом деле там 3+ стула сидим и разминаем простату, получая от этого удовольствие.
>>094912
Ещё Скалу забыл к адской семейке серебрянных пуль, но я никогда JVM family не юзал в продакшене.
Ещё Скалу забыл к адской семейке серебрянных пуль, но я никогда JVM family не юзал в продакшене.
>>094629
Самый хуевый.
Бизнестребования по своей природе декларативны, а оопе-параша - это просто надстройка над процедурщиной.
> ООП, так как это самый лучший вариант выразить бизнес-логику в коде.
Самый хуевый.
Бизнестребования по своей природе декларативны, а оопе-параша - это просто надстройка над процедурщиной.
>>095117
Выше приводил пример qsort на Поцкеле. Ни выполнить его на этапе компиляции, ни даже просто выдать внятный код, компилятор ghc не осилил.
А вообще, самое смешное, что есть в ФП - это долбоёбы, которые своими же руками пишут, по сути, говёного качества процедурный код (т.к. он пишется в терминах языка, а не бизнес-логики), и считают себя элиткой ФП. Это касается дрочеров ф-шарпа и скалы в первую очередь. А-у, задроты, вас наебали - если нет упаковки побочных эффектов в монады, то перед вами засутенёренный императивный язык. Это элементарно проверяется - код на таких языках строка-в-строку переносится в Си++. Вы же не настолько ебанулись, чтобы кресты считать функциональными?
>Компиляторы функциональных языков обычно умееют хорошо оптимизировать
Выше приводил пример qsort на Поцкеле. Ни выполнить его на этапе компиляции, ни даже просто выдать внятный код, компилятор ghc не осилил.
А вообще, самое смешное, что есть в ФП - это долбоёбы, которые своими же руками пишут, по сути, говёного качества процедурный код (т.к. он пишется в терминах языка, а не бизнес-логики), и считают себя элиткой ФП. Это касается дрочеров ф-шарпа и скалы в первую очередь. А-у, задроты, вас наебали - если нет упаковки побочных эффектов в монады, то перед вами засутенёренный императивный язык. Это элементарно проверяется - код на таких языках строка-в-строку переносится в Си++. Вы же не настолько ебанулись, чтобы кресты считать функциональными?
Объясните - в чём принципиальная разница между затенением переменных, и использованием изменяемых переменных
Проще говоря, что лучше и в каких ситуациях использовать?
1)
let x = 2;
let x = x 2;
2)
let mut x = 2;
x = x 2;
Проще говоря, что лучше и в каких ситуациях использовать?
1)
let x = 2;
let x = x 2;
2)
let mut x = 2;
x = x 2;
>>092800
"Охуенные" языки для старта, особенно когда дойдет до парадигм, ну кароч пук среньк у нас тут интырфейс, который реализует метод.
Погодите а что такое тырфейс, инкапсуляция ? ну кароч это Кофеварка, ну ты понял.
Я так в жс вкатился, а там костыли пытающиеся подражать джаве. Ни одной книги фундаментальной по ООП не нашел, что бы все понятно разжевали. Про го с нуля промолчу.
Ну это имхо конечно же.
>знаний в области программирования нет никаких
>не трать время, когда есть next gen как Го и Раст
"Охуенные" языки для старта, особенно когда дойдет до парадигм, ну кароч пук среньк у нас тут интырфейс, который реализует метод.
Погодите а что такое тырфейс, инкапсуляция ? ну кароч это Кофеварка, ну ты понял.
Я так в жс вкатился, а там костыли пытающиеся подражать джаве. Ни одной книги фундаментальной по ООП не нашел, что бы все понятно разжевали. Про го с нуля промолчу.
Ну это имхо конечно же.
>>095298
Например, затенённые переменные восстановятся после внутреннего скопа
let x = 2;
{
let x = 10;
println!("{}", x);
}
println!("{}", x);
Выведет:
10
2
> Объясните - в чём принципиальная разница между затенением переменных, и использованием изменяемых переменных
Например, затенённые переменные восстановятся после внутреннего скопа
let x = 2;
{
let x = 10;
println!("{}", x);
}
println!("{}", x);
Выведет:
10
2
>>095329
А нужна ли для этого книга? Это же по большому счёту конвенция. Прочитал, пару абзацев рациональ, для чего так делается; прочитал, как в знакомом тебе языке это синтаксически реализуется; и, вроде, всё. Что там ещё можно по этому поводу изучить? Если очень хочется легализ уровня стандартов языка почитать, то это в статьи, ане в книжки.
>Погодите а что такое тырфейс, инкапсуляция ?
> Ни одной книги фундаментальной по ООП не нашел
А нужна ли для этого книга? Это же по большому счёту конвенция. Прочитал, пару абзацев рациональ, для чего так делается; прочитал, как в знакомом тебе языке это синтаксически реализуется; и, вроде, всё. Что там ещё можно по этому поводу изучить? Если очень хочется легализ уровня стандартов языка почитать, то это в статьи, ане в книжки.
>>095298
Нужно помнить что у неиспользуемой больше переменной будет вызван drop
Нужно помнить что у неиспользуемой больше переменной будет вызван drop
Блять, хули у него установка такая ебанутая? Какой раз уже на него перекатываюсь, постоянно на установке хуй забиваю просто в рот ебал это говно, охуеть блять просто пиздец, какой то нахуй Visual Studio C++ Build tools требует еще и Win10 SDK с инглиш пакетом да пошел ты нахуй охуеть можно просто пиздец
>>097159
Потому что винда мастдай.
А вообще, просто загугли как поставить pc-windows-gnu тулчейн под mingw.
https://rust-lang.github.io/rustup/installation/windows.html#windows
Потому что винда мастдай.
А вообще, просто загугли как поставить pc-windows-gnu тулчейн под mingw.
https://rust-lang.github.io/rustup/installation/windows.html#windows
>>097166
Пиздец аж на линукс захотелось, столько языков уже отбросил нахуй из за ебанутой установки и компиляции просто пиздец, однако весь настроенный софт на винде и хуй знает как все это теперь на лин переносить
Пиздец аж на линукс захотелось, столько языков уже отбросил нахуй из за ебанутой установки и компиляции просто пиздец, однако весь настроенный софт на винде и хуй знает как все это теперь на лин переносить
>>097420
arch + i3 либо sway самый идеальный вариант будет для древнего пк и 64 бит поставится
arch + i3 либо sway самый идеальный вариант будет для древнего пк и 64 бит поставится
>>097247
Установи пакеты, это гораздо проще, чем софт искать и настраивать.
Установи пакеты, это гораздо проще, чем софт искать и настраивать.
>>065719
Я не смог вкатиться в Джаву из-за ООП и классов, ты хочешь сказать что в Руби тоже сплошное ООП? Но синтаксис там очень нравится
Я не смог вкатиться в Джаву из-за ООП и классов, ты хочешь сказать что в Руби тоже сплошное ООП? Но синтаксис там очень нравится
>>065035
Там тоже консоль и прочее? Возможно параллельно учить этот ЯП и Раби?
Там тоже консоль и прочее? Возможно параллельно учить этот ЯП и Раби?
Хочу вкатиться в программирование графики на Vulkan.
Погуглили - не нашёл ни ождного нормального ресурса, посвящённому связке Vulkan + Rust. Может кто-нибудь знает годные гайды? Можно а Ангельском
Погуглили - не нашёл ни ождного нормального ресурса, посвящённому связке Vulkan + Rust. Может кто-нибудь знает годные гайды? Можно а Ангельском
>>100308
https://lib.rs/crates/ash
https://github.com/unknownue/vulkan-tutorial-rust
Но больше вроде бы нет ничего, так что хуярь обычные вулканские туториалы, а потом переноси на раст.
https://lib.rs/crates/ash
https://github.com/unknownue/vulkan-tutorial-rust
Но больше вроде бы нет ничего, так что хуярь обычные вулканские туториалы, а потом переноси на раст.
>>100397
Чтобы начать с плюсов/Си, надо сперва разобраться с этими языками, и их ебанутыми системами сборки, зависимостями (Который нихуя не желают просто так брать и устанавливаться, ебанутыми IDE-шками, которые превратили язык программирования в отдельную программу и прочим дерьмом.
Нет уж, спасибо...
Чтобы начать с плюсов/Си, надо сперва разобраться с этими языками, и их ебанутыми системами сборки, зависимостями (Который нихуя не желают просто так брать и устанавливаться, ебанутыми IDE-шками, которые превратили язык программирования в отдельную программу и прочим дерьмом.
Нет уж, спасибо...
Блять, как раст на винду поставить? Учитывая, что установка у него заебистая, не хочу все эти vs библиотеки качать, которые еще и sdk ебаные требуют, в пизду. Cygwin не под раст. Линукс как 2 ос ставить - самый последний вариант, неужели других нет, че делать то пиздец?
>>100603
Vagrant + виртуалка с убунтой под каждый проект. Сам так делаю, зависимость есть
> Линукс как 2 ос ставить - самый последний вариант
Vagrant + виртуалка с убунтой под каждый проект. Сам так делаю, зависимость есть
>>100605
Интересно, пока изучаю
Интересно, пока изучаю
>>100668
Бля говорят в имя хоста писать x86_64-pc-windows-gnu, но это ведь только для 64, а про i686-pc-windows-gnu нихуя не написано, пиздец надеюсь прокатит
>как поставить pc-windows-gnu тулчейн под mingw
Бля говорят в имя хоста писать x86_64-pc-windows-gnu, но это ведь только для 64, а про i686-pc-windows-gnu нихуя не написано, пиздец надеюсь прокатит
>>100986
Ебать получилось! Странно, что раст так легко поставить на самом деле, хотя нигде про это особо не пишут и хотят чтоб юзали msvc, пиздец а я уже линукс поставил ради него ну ебаный в рот, столько дней ебался, а тут такая легкая установка просто охуеть можно, спасибо анонам.
Ебать получилось! Странно, что раст так легко поставить на самом деле, хотя нигде про это особо не пишут и хотят чтоб юзали msvc, пиздец а я уже линукс поставил ради него ну ебаный в рот, столько дней ебался, а тут такая легкая установка просто охуеть можно, спасибо анонам.
>>101202
Неа хуйня, там по умолчанию msvc и windowds sdk всякие нужно скачивать и хуй догадаешься, что оказывается надо кастом сеттингс делать и писать туда i686-pc-windows-gnu чтоб все заебись поставилось, с чем мне и помог другой анон
Неа хуйня, там по умолчанию msvc и windowds sdk всякие нужно скачивать и хуй догадаешься, что оказывается надо кастом сеттингс делать и писать туда i686-pc-windows-gnu чтоб все заебись поставилось, с чем мне и помог другой анон
>>101259
Блять, а как я то теперь доволен, это просто пизда, столько дней возился, а фикс так легок, ну впрочем как и многие баги собственно
Блять, а как я то теперь доволен, это просто пизда, столько дней возился, а фикс так легок, ну впрочем как и многие баги собственно
>>101281
Блять, ну мы же не 24/7 программируем, иногда хочется и отдохнуть, поиграть в ченить, фотошоп бля нормально без костылей запустить, зайти в привычные приложения которые онли под винду, не перезапускать же комп каждый раз из за этого, чтоб сменить ос
Блять, ну мы же не 24/7 программируем, иногда хочется и отдохнуть, поиграть в ченить, фотошоп бля нормально без костылей запустить, зайти в привычные приложения которые онли под винду, не перезапускать же комп каждый раз из за этого, чтоб сменить ос
>>101291
wsl ни нужон ибо только под дрисятку. да и нахуя если все под винду устанавливается с должным усилием
wsl ни нужон ибо только под дрисятку. да и нахуя если все под винду устанавливается с должным усилием
>>101288
Любую UNIX-like систему. Линух, БСД, гейось.
>>101293
Виртуалка?
Вообще проблемы не вижу, ты же не каждые полчаса переключаешься. У меня давно такой порядок: винда - для развлечений, линух - для работы. Ибо винда после установки софта для программирования сразу превращается в мусорку.
>Нормальную - это какую?
Любую UNIX-like систему. Линух, БСД, гейось.
>>101293
Виртуалка?
>не перезапускать же комп каждый раз из за этого, чтоб сменить ос
Вообще проблемы не вижу, ты же не каждые полчаса переключаешься. У меня давно такой порядок: винда - для развлечений, линух - для работы. Ибо винда после установки софта для программирования сразу превращается в мусорку.
>>101432
Просто вся работа программиста на винде происходит в IDE, а любой шаг в сторону вызывает лютую попаболь.
Просто вся работа программиста на винде происходит в IDE, а любой шаг в сторону вызывает лютую попаболь.
6 Кб, 250x226Так бля, че началось то блять? Какого то хуя в саблайме скобка как то рандомно ставится, то как надо прилипая слева, то блять посреди кода нахуй в воздухе, у кого так же было? Как фиксить пиздос
Нихуя прикол, крч по фану затестил функцию чисел фибоначчи с числом 42 на старом ноуте:
Rust - 1.6s
Lisp (racket) - 3.7s (cpu time: 3666 real time: 3745 gc time: 0) (и 0.5s время компиляци)
C++ 4.2s (и 0.7s время компиляции)
Хуй знает как так, видимо для с++ надо 999 флагов еще написать при билде, чтоб хоть как то оптимизированно было, но хуй знает, везде по стандарту в релиз билдил и все ниче не знаю нахой
Rust - 1.6s
Lisp (racket) - 3.7s (cpu time: 3666 real time: 3745 gc time: 0) (и 0.5s время компиляци)
C++ 4.2s (и 0.7s время компиляции)
Хуй знает как так, видимо для с++ надо 999 флагов еще написать при билде, чтоб хоть как то оптимизированно было, но хуй знает, везде по стандарту в релиз билдил и все ниче не знаю нахой
>>101919
Ты растовский вариант считаешь встроенными средствами, а остальные таймерами ОС? Так там секунды могут на загрузку библиотек и прочие шаманства при запуске уходить.
Ты растовский вариант считаешь встроенными средствами, а остальные таймерами ОС? Так там секунды могут на загрузку библиотек и прочие шаманства при запуске уходить.
>>101933
А бля точно сорри, я только с с++ забыл time ебануть, в лисп не забыл там все норм, но хз насколько это улучшит показатели с++ , завтра тогда затестирую
А бля точно сорри, я только с с++ забыл time ебануть, в лисп не забыл там все норм, но хз насколько это улучшит показатели с++ , завтра тогда затестирую
Поясните за Ржавого в вебе. Котируется?
>>058777
Потому что "модна", перспективный язык. А так, из системных языков больше ламповый Си нравится.
Потому что "модна", перспективный язык. А так, из системных языков больше ламповый Си нравится.
Какой самый труъ способ абстракции зависимостей, которые должны храниться в структуре, но не будут меняться в рантайме?
trait SomeTrait {}
struct Foo {
dep: SomeTrait // вот так не работает без Box<dyn SomeTrait>, большой ли рантайм кост у такого способа?
}
struct Bar<TDep: SomeTrait> {
dep: TDep
} // при добавлении новых зависимостей, придётся добавлять новые дженерики.
trait SomeTrait {}
struct Foo {
dep: SomeTrait // вот так не работает без Box<dyn SomeTrait>, большой ли рантайм кост у такого способа?
}
struct Bar<TDep: SomeTrait> {
dep: TDep
} // при добавлении новых зависимостей, придётся добавлять новые дженерики.
>>102062
Или это не раст-вей, и всё передаём как есть?
Или это не раст-вей, и всё передаём как есть?
>>101445
У меня как-то наоборот, Visual Studio вызывает жопоболь. Просто не перевариваю я эту IDE-шку
Мне проще в Notepad++ код написать и запустить Cargo run, чем настраивать всё под визуалку, пытаться понять - что там наговнокодили мелкомягкие и т.д.
Хотя вообще, есть годный плагин для Pycharm-a, и сейчас я пользуюсь им
У меня как-то наоборот, Visual Studio вызывает жопоболь. Просто не перевариваю я эту IDE-шку
Мне проще в Notepad++ код написать и запустить Cargo run, чем настраивать всё под визуалку, пытаться понять - что там наговнокодили мелкомягкие и т.д.
Хотя вообще, есть годный плагин для Pycharm-a, и сейчас я пользуюсь им
>>102062
&'static? Или что тебе нужно?
>зависимостей, которые должны храниться в структуре, но не будут меняться в рантайме?
&'static? Или что тебе нужно?
30 Кб, 711x511>>101933
Ну хуй знает чел, раст все равно обгоняет, а это еще учитывая, что я с флагами для с++ поебался, поставил чтоб оптимизированно было, на скрине до/после оптимизации и все равно раст лидирует лол
Ну хуй знает чел, раст все равно обгоняет, а это еще учитывая, что я с флагами для с++ поебался, поставил чтоб оптимизированно было, на скрине до/после оптимизации и все равно раст лидирует лол
Как без лишней ебли, внедрить в ехе файлы, которые я читаю через std::fs например? Не хочу чтобы рядом с ехешником были эти файлы, но при этом система должна их увидеть.
>>102380
P.S. Там есть ещё include_str!(); если файлы текстовые, сразу строку тебе сделает.
P.S. Там есть ещё include_str!(); если файлы текстовые, сразу строку тебе сделает.
>>102380
Типа при компиляции файл уже войдет в ехе благодаря этой теме? А есть ли более универсальный способ? Вдруг я какой нибудь библиотекой импортирую изображение, которое юзер тоже не должен видеть рядом с ехе.
Типа при компиляции файл уже войдет в ехе благодаря этой теме? А есть ли более универсальный способ? Вдруг я какой нибудь библиотекой импортирую изображение, которое юзер тоже не должен видеть рядом с ехе.
>>102393
Если изображение статично в рантайме (то есть известно на этапе компиляции и не будет изменяться), то хуяришь его тем же статиком в либу. А если оно не статично, то как ты его в статичный exe хочешь захуярить?
Если изображение статично в рантайме (то есть известно на этапе компиляции и не будет изменяться), то хуяришь его тем же статиком в либу. А если оно не статично, то как ты его в статичный exe хочешь захуярить?
5 Кб, 187x190>>102405
Ок буду пробовать пасиб
Вопрос №2
Нахуя столько лишних папок и файлов создается при cargo build --release? Достаточно ведь всего одного ехе файла который я на другом пк тестил и все работало без этих ебаных папок.
Можно ли как то отключить их создание при билде?
Ок буду пробовать пасиб
Вопрос №2
Нахуя столько лишних папок и файлов создается при cargo build --release? Достаточно ведь всего одного ехе файла который я на другом пк тестил и все работало без этих ебаных папок.
Можно ли как то отключить их создание при билде?
>>102409
Нельзя, они все нужны, чтобы собрать конечный .exe файл.
Но конечный файл потом из папки можно отдельно вытаскивать куда хочешь, офк, а /target/ почистить с помощью cargo clean.
Нельзя, они все нужны, чтобы собрать конечный .exe файл.
Но конечный файл потом из папки можно отдельно вытаскивать куда хочешь, офк, а /target/ почистить с помощью cargo clean.
>>102409
Туда складывается выхлоп растовского компилятора и ллвм. Позволяет например делать относительно быстрые инкрементальные билды (когда поменял в коде одну строчку и не надо заново компилировать весь проект со всеми зависимостями).
> Нахуя столько лишних папок и файлов создается при cargo build --release?
Туда складывается выхлоп растовского компилятора и ллвм. Позволяет например делать относительно быстрые инкрементальные билды (когда поменял в коде одну строчку и не надо заново компилировать весь проект со всеми зависимостями).
147 Кб, 840x540Попробовал я ваш раст, значит. И как плюсовик со стажем заявляю, что раст - это полное блаженство. Уебищный синтаксис и спагетти из символов, на первый взляд, оказались вполне логичными и удобными. В общем, желаю языку дальнейшего развития, чтобы я смог пересесть на него полноценно.
>>102707
В основном из-за отсутствия большого количества работы на рынке. Да и подожду, что Линус скажет по поводу раста в ядре линукс.
>В смысле, а что сейчас мешает пересесть полноценно?
В основном из-за отсутствия большого количества работы на рынке. Да и подожду, что Линус скажет по поводу раста в ядре линукс.
>>102944
Ты собрался стать мейнтенером ядра?
>Да и подожду, что Линус скажет по поводу раста в ядре линукс.
Ты собрался стать мейнтенером ядра?
>>102964
Нет, просто мы на работе системщину пишем, а для этих целей, сам понимаешь, выбор языков небольшой. А добавления раста в линукс был бы хорошим звоночком для применения последнего в системщине.
>Ты собрался стать мейнтенером ядра?
Нет, просто мы на работе системщину пишем, а для этих целей, сам понимаешь, выбор языков небольшой. А добавления раста в линукс был бы хорошим звоночком для применения последнего в системщине.
>>102062
Рантайм кост у такого способа как у таблицы виртуальных функций. https://stackoverflow.com/questions/62207849/how-does-boxdyn-trait-deconstruct-itself
Рантайм кост у такого способа как у таблицы виртуальных функций. https://stackoverflow.com/questions/62207849/how-does-boxdyn-trait-deconstruct-itself
Почему для компиляции раста требуется плюсовый компилятор? Я не троллю и вообще джун, мне действительно интересно.
>>104043
Операционная система у тебя на каком языке написана? Поэтому.
Операционная система у тебя на каком языке написана? Поэтому.
>>100603
WSL2
WSL2
>>104043
Не компилятор, а линкер, это раз.
Только на винде, это два.
Хотя по второму пункту могу пиздеть, может на линупсе тоже какую-то сишную либу тянет для линковки.
Не компилятор, а линкер, это раз.
Только на винде, это два.
Хотя по второму пункту могу пиздеть, может на линупсе тоже какую-то сишную либу тянет для линковки.
Поясните кто-нибудь за WinAPI
Вот есть в доках Microsoft такая функция:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasusera
Я хочу её вызвать. Открываю документацию к крейту который вроде как даёт открывает доступ к winapi:
https://docs.rs/windows/0.17.2/windows/
The windows crate lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module.
Пытаюсь найти в доках эту функцию - её нет.
Как эту залупу вызвать?
Вот есть в доках Microsoft такая функция:
https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasusera
Я хочу её вызвать. Открываю документацию к крейту который вроде как даёт открывает доступ к winapi:
https://docs.rs/windows/0.17.2/windows/
The windows crate lets you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API and right into your Rust package where you can call them as if they were just another Rust module.
Пытаюсь найти в доках эту функцию - её нет.
Как эту залупу вызвать?
>>104282
Выглядит интересно. Спасибо.
Знать бы ещё насколько это васянство, и насколько криво это работает.
Выглядит интересно. Спасибо.
Знать бы ещё насколько это васянство, и насколько криво это работает.
>>104287
Стой. Ты выбрал правильную либо походу. Она официальная.
Просто там надо через use подключать сначала https://microsoft.github.io/windows-docs-rs/doc/bindings/Windows/Win32/System/index.html?search=CreateProcessAsUser
Тут написано как подключать. Пример есть https://github.com/microsoft/windows-rs
Стой. Ты выбрал правильную либо походу. Она официальная.
Просто там надо через use подключать сначала https://microsoft.github.io/windows-docs-rs/doc/bindings/Windows/Win32/System/index.html?search=CreateProcessAsUser
Тут написано как подключать. Пример есть https://github.com/microsoft/windows-rs
>>104297
Я читал этот вводный гайд. Но так нифига из него и не понял.
Наверное слишком тупой
> Тут написано как подключать. Пример есть https://github.com/microsoft/windows-rs
Я читал этот вводный гайд. Но так нифига из него и не понял.
Наверное слишком тупой
>>104303
Единственное что там необычно новичку - это билд-скрипт (почитать про них можно тут https://doc.rust-lang.org/cargo/reference/build-scripts.html ) Это отдельный файл в корне твоего проекта (build.rs). Написано что в него надо запихать указания что надо взять из библиотек винАПИ.
Единственное что там необычно новичку - это билд-скрипт (почитать про них можно тут https://doc.rust-lang.org/cargo/reference/build-scripts.html ) Это отдельный файл в корне твоего проекта (build.rs). Написано что в него надо запихать указания что надо взять из библиотек винАПИ.
То есть в cargo.toml:
[code]
[dependencies]
windows = "0.17.2"
[build-dependencies]
windows = "0.17.2"
[/code]
В build.rs:
[code]
fn main() {
windows::build! {
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::MessageBoxA,
};
}
[/code]
И в main.rs:
[code]
mod bindings {
windows::include_bindings!();
}
use bindings::{
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::{MessageBoxA, MB_OK},
};
fn main() -> windows::Result<()> {
let doc = XmlDocument::new()?;
..................................
[/code]
[code]
[dependencies]
windows = "0.17.2"
[build-dependencies]
windows = "0.17.2"
[/code]
В build.rs:
[code]
fn main() {
windows::build! {
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::MessageBoxA,
};
}
[/code]
И в main.rs:
[code]
mod bindings {
windows::include_bindings!();
}
use bindings::{
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::{MessageBoxA, MB_OK},
};
fn main() -> windows::Result<()> {
let doc = XmlDocument::new()?;
..................................
[/code]
То есть в cargo.toml:
[code]
[dependencies]
windows = "0.17.2"
[build-dependencies]
windows = "0.17.2"
[/code]
В build.rs:
[code]
fn main() {
windows::build! {
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::MessageBoxA,
};
}
[/code]
И в main.rs:
[code]
mod bindings {
windows::include_bindings!();
}
use bindings::{
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::{MessageBoxA, MB_OK},
};
fn main() -> windows::Result<()> {
let doc = XmlDocument::new()?;
..................................
[/code]
[code]
[dependencies]
windows = "0.17.2"
[build-dependencies]
windows = "0.17.2"
[/code]
В build.rs:
[code]
fn main() {
windows::build! {
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::MessageBoxA,
};
}
[/code]
И в main.rs:
[code]
mod bindings {
windows::include_bindings!();
}
use bindings::{
Windows::Data::Xml::Dom::,
Windows::Win32::Foundation::CloseHandle,
Windows::Win32::System::Threading::{CreateEventW, SetEvent, WaitForSingleObject},
Windows::Win32::UI::WindowsAndMessaging::{MessageBoxA, MB_OK},
};
fn main() -> windows::Result<()> {
let doc = XmlDocument::new()?;
..................................
[/code]
>>104328
Пиздос.
Пиздос.
>>102944
А что он еще не высказался?По-моему он где-то писал что относится к этому нормально
>Да и подожду, что Линус скажет по поводу раста в ядре линукс.
А что он еще не высказался?По-моему он где-то писал что относится к этому нормально
>>105019
Можно конечно, и примеры есть. Но нет готовых фреймворков чтобы собрать все компоненты необходимые для создания среднего сайта воедино.
https://github.com/steadylearner/Rust-Full-Stack
Можно конечно, и примеры есть. Но нет готовых фреймворков чтобы собрать все компоненты необходимые для создания среднего сайта воедино.
https://github.com/steadylearner/Rust-Full-Stack
>>104073
Сегодня как раз на убунте пришлось ставить линкер.
Сегодня как раз на убунте пришлось ставить линкер.
>>105642
Никаких блобов.
Никаких блобов.
>>105019
Привет, как дела? Или это не мне привет, чет не понятно.
Привет, как дела? Или это не мне привет, чет не понятно.
>>105019
Да хоть на ассемблере.
Да хоть на ассемблере.
>>107298
Да и поебать. Зачем нам двач, мы и так охуенны.
Да и поебать. Зачем нам двач, мы и так охуенны.
Пока тред не утонул, расскажите вкратце, почему в бэке Go набирает популярность гораздо быстрее Rust? В чём его преимущество (-ва, если их много, конечно)?
>>107780
Печаль. Маскот своей няшностью убеждал заскочить на ржавый поезд, а тут вон оно как.
Печаль. Маскот своей няшностью убеждал заскочить на ржавый поезд, а тут вон оно как.
>>107776
Блядь, как там говорилось? Хочешь сделать хорошо, сделай сам?
>Кто-нибудь по-настоящему крутой. Кто-то, кто умеет ПЕРЕКАТЫВАТЬ ТРЕДю
Блядь, как там говорилось? Хочешь сделать хорошо, сделай сам?
>>107841
>>107686
Все, готово. Не так уж это и сложно.
ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (
М)
ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (М)
ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (М)
>>107686
Все, готово. Не так уж это и сложно.
ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (
М)ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (
М)ПЕРЕКАТ: https://2ch.hk/pr/res/2107844.html (
М)Тред утонул или удален.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 31 июля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.