Свежие новости: из исходников языка были удалены почти все расистские комментарии и изменены имена переменных содержащие такие ужасные слова как "белый" и "чёрный". Ура, товарищи, Раст стал ещё безопасней!
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Перед тем как задать вопрос не забываем пожертвовать ЧёрноЖизненнойМатерии минимум $100 с пруфами: https://blacklivesmatters.carrd.co/
Предыдущий тред: >>1744787 (OP)
Все undefined behavior поймали, ржавые?
https://lore.kernel.org/lkml/CAKwvOdmuYc8rW_H4aQG4DsJzho=F+djd68fp7mzmBp3-wY--Uw@mail.gmail.com/T/#u
Смех-смехом, а раст проникает в Линукс. Мелкософты тоже начали юзать его и даже переписывать некоторый свой софт на него (но скорее новые проекты будут на нем активно пилиться, легаси есть легаси, оставим это дедуганам с\с++)
Через лет 10, максимум 15, большая часть инфосека умрет как отрасль (лоу лвл), дохуя людей потеряют работу, хацкеры станут прошлым.
Я прям не совсем системщик, но помню еще с учебы, что вот эти все УБэшки в сях достигались путем компромисса, ради поддержки большого числа платформ. не вспоминая кривобокость компиляторов
Раст, по сути, упирается в возможности LLVM, так как они хотят в линукс то попасть, если линукс работает даже в твоих носках?
Твой код может навернуть говна, если крейт который ты используешь был написан подобным коляном. А стандартная библиотека раста очень мала и крейты ты будешь использовать даже для проектов уровня laba1. Например для того чтобы написать любой асинхронный код тебе в любом случае придётся выбирать крейт с асунк-рантаймом (потому что в стд его нет) написанный васянами и все из них содержат ансейф-код (даже элементарный реактор block_on, который превращает асинхронную функцию в синхронную, потому что создать TLS без ансейфа в расте невозможно, лол).
Любой код навернет говна. Вопрос только в том, кто будет виноват. Моя задача - спихнуть ответственность на Коляна, разработчиков Rust, или васянов из Linux kernel.
Я уже достаточно насладился свободой С, и не хочу чтобы юниоры наслаждались ей за мой счет.
Эх, если бы я только мог вести себя, на review PR, как ведет себя компилятор Rust.
> спихнуть ответственность на Коляна, разработчиков Rust, или васянов из Linux kernel.
Только вот на кого проблему не спихивай, а работающий продукт тебе в любом случае придётся делать. Тот же токио например известен своими дедлоками, которые отлаживать ничуть не легче чем UB в недрах сишного кода, а девелоперы закрыли issue как worksforme. Удачи в спихивании ответственности в этом случае.
Меня где-то ждёт пиздец на этом пути?
Единственный вопрос как я вижу — не очень понятно, куда это всё будет развиваться, но тут и с остальными ЯП непонятно, кроме быть может джавы и си.
Ну во-первых ящитаю кайфовость — важный критерий. А как ты ещё будешь формировать комьюнити задротов, которые тратят своё свободное время, чтоб опен сорс либы писать? Как ты будешь привлекать талантливых людей, у которых сейчас широкий выбор на чём писать, если от языка блевать хочется? Девелопер который кайфует от процесса дорогого стоит.
Во-вторых, по поводу объективных свойств — так я и прошу анонов с опытом рассказать что как.
Сказали уже, что у проекта случился фатальный недостаток.
http://lurkmore.to/%D0%A4%D0%B0%D1%82%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9_%D0%BD%D0%B5%D0%B4%D0%BE%D1%81%D1%82%D0%B0%D1%82%D0%BE%D0%BA
Готовность языка (точнее отсутствие честной заморозки), качество библиотек (и их количество) и само управление растом (субъективно делается все очень медленно, но за то они рады заниматься полит херней) - ставит под сомнение потенциал языка до продакшен-реди (если только твой код, это не какой-то кусок утилиты). Плюс из-за агрессивного маркетинга в язык периодично вливаются не совсем компетентные люди, которые своими фанатическими текстами подрывают пердаки даже равнодушным.
Как и в случае го, желаемое выдается за действительное. Как и в случае ФП языков, язык собрал вокруг себя ИТ-онанистов, которые язык благотворят и любят, но никто на нем почти не пишет ибо одно дело создать себе кумира и трепаться на нем, другое дело работать
Так же, сугубо мое мнение, язык просто не нужен. Раст действительно решает некоторые вопросы безопасности (некоторые притянутые за уши) но делает это он ценой производительности. Если бы это говорили тебе честно в лицо, то ничего страшного не было. Но каждая маня статья в очередной раз может рассказать что раст быстрее си или про какую-нибудь абстракцию нулевой стоимости, что в реальности о расте оставляет другие впечатление, чем они на самом деле есть.
Опять имхо.
Естественно рынку нужно и быстро и безопасно. Но реальность такова, что это всегда два отдельных стула и выбрать можно только одно. Поэтому если рынку нужно быстро - то это C/C++, если нужно безопасно - то какая-нибудь java. Если бы раст не накладывал определенных оверхед на разработчика, то он мог бы влезть между С++ и Джавой. Отсюда мы видим такой феномен, когда бэкенд макаки с какого-нибудь питона лезут в раст, за производительность. Но как я и сказал, раст накладывает оверхед, сравни оверхеду С++, поэтому и в этом участке рынка он нахер не нужен.
>раст накладывает оверхед, сравни оверхеду С++
Сравнил. Если мы говорим про stdlib, то никакого оверхеда нет, пока ты используешь правильные инструменты (buffer.iter().for_each(|_|); а не for i in 0..buffer.len() {}).
А если мы говорим про тех, кто пишет либы, но пишет их плохо, то такая херня не только в расте есть, и если выбирать между чуть более медленной программой или 70% багов, которые надо дебажить (или статистика мелкомягких на пустом месте возникла?), лично я выберу первое.
PS для любителей аналогии.
В сях (С++) есть философия - не плати за это, если тебе это не нужно. Это очень жесткая философия, делающая С++ мощным инструментом. То есть, тебе буквально говорят - на тебе нож, он очень острый, будь осторожен. Но выросло новое поколение питонистов, которые берут нож и начинают им махать, тыкать и в следствие режутся и плачутся. Тут на помощь должен прийти раст и дать тебе другой нож, такой же острый но безопасный (как это возможно, непонятно, но говорят же). Но на деле ты берешь и видишь что это ржавый и затупленный нож, хотя тебе в лицо говорят, что он такой же острый. И кто-то даже верит, бежит писать статьи что ржавый нож такой же острый и даже приводит примеры как он хорошо режет картон. А кто-то видит что он тупой, пытается его заточить и ему это удается. Но вдруг его проект становится очень популярным и ему говорят - "Коля! Ты не правильно используешь наш нож, он не должен быть так заточен, кто-то когда-нибудь порежется!! Затупи!".
Для меня оверхед раста больше оверхеда С++, но я не смогу это объяснить на пальцах, это чисто субъектившина. Конечно, можно сказать я не осилил. Но языки программирования это не состязания по олимпиаде, то что я не осилил, хотя осилил С++, говорит о том что они скорее всего плохо сделали.
В раст стоит поиграться, чисто для эксперимента. Но у меня он дальше эксперимента не зашел. ааа, лалка, неосилил
Если уж проводишь аналогии, то изволь проводить правдоподобные:
C/C++ — это Desert Eagle без предохранителя и со слишком легко нажимающимся спуском. Охуительно мощный и крутой, но по ты его с собой носишь, ты не знаешь, когда он ебанёт и выживешь ли ты после того как он ебанёт. И каждый раз когда ты его носишь с собой, ты либо обкладываешь его ватой и тряпками, либо молишься какому-нибудь богу, чтобы не ебануло в тебя или во что-нибудь такое, за что тебя посадят.
Rust — тот же пистолет, но с предохранителем. Да, ты не можешь хуярить из него сразу как достал из кармана, но для девяноста пяти процентов задач снимать предохранитель не нужно, а для оставшихся пяти у тебя есть время удостовериться, что пистолет не направлен в твою же голову (это я про unsafe, если что).
То, что кому-то не нравится идея предохранителя, не значит, что она не нравится людям вокруг этого человека. Ну и эволюция всё решит сама по поводу того, кто был прав.
>но я не смогу это объяснить на пальцах, это чисто субъектившина
А если не можешь объективно объяснить свою позицию, то нахуя ты её отстаиваешь? Потому что твоя?
Да, окей, питонисты пишут растовый код намного более медленный, чем профессиональные растовые байтоёбы, ну так и что? Багов нет, работает быстрее питона, проблема только в том, что учить долго. Если тебе не похуй на скорость питонистов, то почему тебе не похуй? Или ты хочешь, чтобы эти бедные нелюди себе мозг ебали твоими проблемами? Так ты много хочешь. А если ты хочешь, чтобы было и сейфово и чтобы с голыми указателями можно было поиграться, и чтобы можно было регистры подвигать, так ты просто много хочешь.
Ну так фишка в том, что люди — кретины, и поэтому на опасной хуйне им нужен предохранитель, который надо уметь снимать. Да, неприятно, когда лично тебя называют кретином, но когда всех людей скопом называют кретинами и пихают предохранитель в пистолеты и автоматы, уже не так и обидно.
У Си и крестов столько лет было, чтобы выдрочить GCC? Дай расту столько же, а потом поговорим про лишние ассемблерные инструкции. Да, окей, оверхед есть в сложнооптимизируемом коде, ну так кто мешает писать простой код? Это опять-таки скорее характеристика программиста, а не раста. И правильно дебилам и детям не дают играть со спичками, ибо нехуй.
>Забавно, что суть предохранителя - это исключить нажатия спускового крючка.
>А не защита от произвольного выстрела.
Ты сам-то читаешь что пишешь? Это же ебота без смысла.
>Если ты пистолет кидаешь об стену, то это говорит лишь о том, что ты некомпетентен, а не пистолет плохой.
Т.е. солдат/мент/итд, которому надо бегать и прыгать с этим пистолетом в трусах, будет виноват в том, что после очередного прыжка в укрытие это оружие без предохранителя отстрелит ему яйца нахуй?
Тащемта в любом деле есть техника безопасности итд, просто программирование очень молодая область и никто буквально не отстреливал себе ноги, не отрезал пальцы и не дышал химикатами из-за своей неосторожности, вот никто этим и не занимается.
>Надо писать больше кода чем в плюсах
Вот тут пруфы давай.
>и выдает больше лишних ассемблерных инструкций.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gpp-rust.html
Ну выдаёт и выдаёт, на хабре уже был разбор одного яндексоида которому не нравилось, что если где-то кидается память то компилятор может лишний раз тронуть стек, ахуеть, смертьгробпидор.
Ну я-то про самих программистов говорю. Просто пока очерендой самолёт/ракета не упадёт из-за ошибки, которая решается даже, блять, просто строгим компилятором без всякой хуйни вроде неявного каста интов — никто нихуя делать не будет. Хотя и после быстро забудут и забьют.
>.as_ref()
>.unwrap()
В плюсах кстати операторы & и ★ наверно много оверхеда генирируют?
>.borrow()
А вот это такой же тяжелый оверхед как шаблоны примерно.
Скомпилируй в релизный билд без чеков и посмотри что он там даёт, лол. Ты пытаешься что-то пёрнуть про оптимизацию даже не зная о чём пердишь.
>Ясно.
https://habr.com/ru/post/492410/
Если при прыжке пистолет стреляет - это дефект. Дефект исправляют.
Если есть шанс выйти за границу массива - С++ программист ставит проверку.
Раст это как телефоны эпл. Ты не можешь поменять сам батерейку - ведь это же не безопасно, да? Так же и раст тебя держит за лоха. Ну ушел ты за границы - значит плохая квалификация. Пиши больше тестов.
Там на ещё более древнем говне пишут, ага.
>>1749020
>Если при прыжке пистолет стреляет - это дефект. Дефект исправляют.
Да, и его исправили предохранителем, гений.
>Если есть шанс выйти за границу массива - С++ программист ставит проверку.
И почему чуть ли же каждая 3-я CVE — это отсутствие этой проверки?
>Пиши больше тестов.
Сходи-ка в хром/итд и поясни за тест кавередж, кекус. Тесты — это про формальную фиксацию функционала, не более. Не спасут они тебя ни от чего, разве что можно каким нибудь фаззером ввод подрочить чтобы не сегфолтился на рандомных символах.
Ну, ты же и про него пишешь одновременно.
И вообще, насколько надо быть дауном, чтобы считать что это как-то увеличивает исходный код?
У тебя на плюсах идентичная программа всегда будет как минимум в 1,5 раза больше просто из-за хедеров (а ещё бесконечные std::zalupa::krutoi_ptr<allocator, deallocator, tip, huita>, std::make_huita/etc), ты о чём вообще?
>нассали за воротник
>а я пукну на двоще)0
Ну 85% плюсогоспод же не могут ошибаться.
Почему нет таких баранов, которые жалаются что они делают ошибки на питоне?
Почему для С++ это стало нормой? Почему показывать свою некомпетентность на плюсах перестало быть зазорным?
У плюсов уже было столько "убийц", что они целому поколению забили в голову, что твои ошибки на сях, это проблема си, а не твоей профпригодности.
С++ острый, очень острый. Не порежься!!!
Кретин, что значит "одновременно"? Если я сначала написал про синее, а потом про слонов, по твоему я написал про синих слонов?
>на плюсах идентичная программа всегда будет как минимум в 1,5 раза больше
Не будет.
>из-за хедеров
Давай тогда крейты приплюсовывать.
>std::zalupa::krutoi_ptr<allocator, deallocator, tip, huita>, std::make_huita/etc
auto
>Кретин, что значит "одновременно"? Если я сначала написал про синее, а потом про слонов, по твоему я написал про синих слонов?
Они в одном куске памяти лежали, типичный пример ошибки с reinterpret_cast.
>Не будет.
Потому что ты скозал?
>Давай тогда крейты приплюсовывать.
Не сворачивай с темы, я говорил про код того же проекта, который ты пишешь. Крейты не дублируют один и тот же код 2 раза.
>auto
auto hui = std::zalupa::krutoi_ptr<std::allocator, nestd::deallocator>(tip, huita)
Ну 2 поля сократили, уже норм наверно?
Фишка в том, что тупой стороной как раз порезаться почти невозможно, пока какой-нибудь Колян не решит эту сторону заточить, прикола ради. А вот если ты в unsafe расте объебался, то ССЗБ.
Ну и да, то, что если ты в C++ порежешься, то ты тупой, но почему-то любой достаточно серьёзный продукт пишут тупые люди, у которых все руки в кровавых бинтах. Не знаешь, почему?
Раст приди! Порядок наведи!
Ты реально такой дебил, что если у тебя в крестах сегфолт вылезет, ты пойдёшь проверять весь плюсовый код, которого многие тысячи строк?
Смысл unsafe не в том, что он помогает дебажить, а в том, что ансейф проверяется программистом, пока safe код проверяется компилятором. И если сравнивать количество работы по проверке коде в расте и крестах, то очевидно, что в расте такой хуйни меньше.
>сегфолта
/0
Кто о чём, а плюсодибил о своём.
>>1749061
>Ты со своим питоном его просто так не возьмешь.
Ну вот и оно, собственно. Плюсодибил — это настолько серьёзный диагноз, что он даже спорить в интернете уже не в состоянии, и пытается перевести стрелочку. Потому что плюсодибил — это необучаемая мартышка, которая никогда не сможет выучить даже другой язык.
>Более того, скорее всего еще надо будет лесть в ассемблер. Ты еще ему предъяви, почему он такой сложный.
Нет, плюсодибил, ассемблер не сложный, это байка от восторженных студентиков. Ну разве что для плюсодибилов.
Он просто не подходит для написания чего-то большого, потому что сейчас кодобаза ебучего среднего мобильного клиент-серверного приложения даже на хайлевел языках может уходить куда-то в ебеня за 100k loc.
Да, ок, у нас не PHP, у нас есть ансейф и указатели. Но теперь давай посмотрим на кресты: кто там проверяет код? Или у вас Коляны код не пишут, код пишут только охуительные компьтерные монахи, которые первые сто лет своей жизни провели в заточении со стандартом крестов?
Критикуешь — предлагай. В каком месте я могу писать код быстрее растового, имеющий возможности ансейфа для боттлнеков, но при этом сейфовый в 50-100% (в зависимости от того, что именно ты пишешь) моего кода? Кресты очевидно не подходят по последнему параметру.
Я её вычислил на основе того кода, который я пишу. Сейфовость — штука переменчивая, но я пока что не писал что-то настолько низкоуровневое, чтобы ансейф был больше чем в половине моих модулей. Код без ансейфа, используеющий только stdlib я взял за 100%. И если ты сейчас спизданёшь, что в stdlib может быть UB, потому что его писали Коляны, то я не смогу парировать, потому что stdlib крестов писали конечно же не Коляны и не на 100% unsafe языке.
>В каком месте я могу писать код быстрее растового
Ты куда тему повел то?
Я говорю что философия раста это безопасность. Но реальность это глубоко не так.
И не надо тащить свои плюсы, мы в раст треде говорим про раст. Я понимаю что вас там выдрессировали лаять на С++, мы сейчас анализируем именно раст, не в сравнение.
Ты хочешь всё и сразу, но так не бывает. Хочешь анальную безопасность — иди на идрисе пиши, а не на расте. У нас тут вообще-то системный язык, у которого скорость на первом месте, и в угоду этой самый скорости можно приносить человекочасы программистов, проверяющих ансейф код. Вот только этих человекочасов тратится меньше, чем на плюсовый код из-за той самой безопасности, которая в расте всё же есть, несмотря на все пуки крестовиков.
>Ты хочешь всё и сразу, но так не бывает.
Нет, я хочу то, что мне заявляют.
Если тебе говорят что шампунь не щиплет глазки, значит я ожидаю от него что он не щиплет глазки. Представь я начну оправдывать и говорить - ты хочешь все и сразу, так не бывает, подожди через 5 лет не будет щипать.
Теперь ты видишь как это глупо со стороны смотрится?!
>пуки крестовиков
Фу, фу, перестань трогать кресты, ну серьезно, перестань, мы говорим о расте. Перестань сравнивать.
>Вот только этих человекочасов тратится меньше, чем на плюсовый код
Чел, что ты вообще несешь.
Какую проблему решает раст, которую не решает с++?
Выход за пределы массива? Так в крестах давно есть vector.at<>
Обращение к освобожденной памяти? Да, борроу чекера нет (хотя есть инструменты вроде unique_ptr), но сколько в реальности из за этого багов? Причем тех что не отлавливаются элементарной проверкой тестами, утилитами санитайзерами?
У тебя есть какие то конкретные, документированные пруфы, например, что программа на крестах написана за N времени, поиск бага которому причиной был именно с++ заняла M времени, переписывание на Rust заняло K < N+M времени и багов в нем гарантрованно 0.
Так тебе и заявляют, что язык быстр, безопасен и продуктивен. Но ты, видать, незнаком с CAP теоремой, а потому и не можешь нормально воспринимать такие штуки.
Раст быстр? Быстр. GC нет, итераторы нихуя не медленнее сишных. Тут всё правильно.
Безопасен? Да, просто не пиши unsafe, а если ты используешь либу, автору которой моча в голову ударила, и который объявил transmute функцию безопасной, то уж язык тут точно не виноват.
Продуктивен? Да, если надо, можно написать unsafe.
Очевидно, что компромиссы будут, их просто не может не быть, но если ты слишком школьник, чтобы мириться с компромиссами и слишком тупой, чтобы написать свой язык, который будет работать со скоростью раста там, где растовики пишут unsafe, то просто иди повзрослей, или иди прими таблетку для гениальности.
>Раст быстр?
Что там CAP теорема говорит по поводу лишних инструкций?
>безопасной, то уж язык тут точно не виноват.
А кто виноват? Экосистема языка?
>если ты используешь либу, автору которой моча в голову ударила,
Авторам std ударила в голову моча? Предлагается переписать весь std и крейты?
>Что там CAP теорема говорит по поводу лишних инструкций?
Так раст же не обещает, что он быстрее всех. Но он гарантирует, что будет быстрее всяких скриптов и GC-параш, и тут никакого обмана нет.
>А кто виноват?
Ты. Как и в случае с крестами. Просто ты слишком школьник, чтобы это признать.
>Авторам std ударила в голову моча?
Там как раз всё заебись, и трансмут помечен как unsafe, а все сефовые функции никогда не вызывают UB (даже старый кастовый баг пофиксили).
Так что просто пойди на хуй.
>Теорема CAP (известная также как теорема Брюера) — эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:
>согласованность данных (англ. consistency) — во всех вычислительных узлах в один момент времени данные не противоречат друг другу;
>доступность (англ. availability) — любой запрос к распределённой системе завершается корректным откликом, однако без гарантии, что ответы всех узлов системы совпадают;
>устойчивость к разделению (англ. partition tolerance) — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.
Причем тут это? Может тогда еще SAT-теорему применим?
>Причем тут это? Может тогда еще SAT-теорему применим?
У чела тупо кончились аргументы и он по принципу демагогии хочет взять спор авторитетом. мол он владеет какими-то знаниями, которые ставит его выше собеседника. Но в реале тут просто уже вытекает из треда такой толстотой
Не ошибка, а специально написанный UB, который со специальными флагами компиляции ускоряет код на 0.0001%, но с без этих флагов либо не компилируется, либо замедляется на 300%. Просто тупые растовчане как всегда не смогли угадать нужные флаги, потому что в документации они не указаны.
Наличие юб только потенциально даёт возможность конпелятору (зачастую в рамках оптимизаций) сгенерировать говно вместо программы.
Например я не раз видел как в С++ проектах вырубали strict aliasing, потому что к коде было огромное количество reinterpret_cast с UB если эта опция включена. Но при выключенном strict aliasing компилятор генерировал нормальный код несмотря на UB, потому что множество оптимизаций отключаются.
Потому что мы пишем максимально близко к аппаратному уровню обе программы.
А, погоди, я понял. То есть растофаны верят, что вот так вдруг ни с хуя раст подберет какое то новое сочетание ассемблерных инструкций, которое будет в разы быстрее самой оптимизированной программы на Си.
На десктопе и/или в мобилах расту понадобится лет 20-25, чтобы частично заменить с/с++, и это как минимум, ибо сишного и крестового кода слишком много.
Легаси как было на С/С++, так и будет, новые же проекты на уровне системщины все же скорее будут писать на расте. Оверолл доминацию раста вы точно не застанете, к тому времени уже все аноны в треде будут в земельке, но это случится рано или поздно. Так какая вам нахуй разница тогда?
На мобилах раста считай вообще нет. Рассматривал его как вариант языка для кроссплатформенного движка, остановился на C++
> жирный и его конпелятор высирает слишком жирные бинари для окружений с жесткими ограничениями ресурсов.
Жирные бинари он высирает только с std, а в bare metal используется особый режим - no_std, где бинари миниатюрны, но нет большей части стандартной библиотеки.
Политика важнее технологий. Это позиция разработчиков раста и всех нормальных расто-евангелистов в этом треде. Не нравится - чемодан, вокзал, язык_нейм.
>>1749569
Без доказательств не считается. Нужен скан чека и открытое письмо соседа с благодарностью. Плюс генетические тесты соседа, чтобы доказать, что он не белы.
> юмор
Всё серьезно.
https://github.com/rust-lang/rust/pull/74127
Какой то более лучший ECS
https://github.com/amethyst/rfcs/issues/22
Да не, на главной у них это чуть ли не единственная цель в 2020 году
https://amethyst.rs/roadmap
Нет. Я сижу в специальной одежке, которая охраняет меня от стыда и позволяет травить наци-токсиков в 10 раз эффективней.
The Book (Rustbook). Читаешь, пишешь примеры (можно на https://play.rust-lang.org), учишься. Если потом хочешь в асинк — читаешь Async Book; хочешь в гейдев — читаешь какой-нибудь гейдев бук; хочешь поебаться с UB — читаешь Rustonomicon. Книг дохуя, просто бери да читай. Если The Book не зашла, то гугли Rust by Example. Если даже с примерами никак не осиливается, то Rustlings хуярь
Короче говоря, просто идёшь сюда и учишь себя сам: https://www.rust-lang.org/learn
Извини, что я такой токсик, но никто за тебя ничего выучить не сможет.
Там в расте ансейф, хуета какая-то опасная, не стоит такое запускать, бенчмарк поломан и испорчен.
> раст обоссывает кресты по бенчмаркам
the trait `diesel::Queryable<diesel::sql_types::Nullable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer)>, diesel::sqlite::Sqlite>` is not implemented for `(i32, std::string::String, std::string::String, std::string::String, i32, i32, std::string::String, i32, i32)`
help: the following implementations were found:
<(A, B, C, D, E, F, G, H, I) as diesel::Queryable<(SA, SB, SC, SD, SE, SF, SG, SH, SI), __DB>>
note: required because of the requirements on the impl of `diesel::Queryable<diesel::sql_types::Nullable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer)>, diesel::sqlite::Sqlite>` for `posts::BlogPosts`
note: required because of the requirements on the impl of `diesel::Queryable<((diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Integer), diesel::sql_types::Nullable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer)>), diesel::sqlite::Sqlite>` for `(posts::Tag, posts::BlogPosts)`
note: required because of the requirements on the impl of `diesel::query_dsl::LoadQuery<diesel::SqliteConnection, (posts::Tag, posts::BlogPosts)>` for `diesel::query_builder::SelectStatement<diesel::query_source::joins::JoinOn<diesel::query_source::joins::Join<schema::tags::table, schema::blogposts::table, diesel::query_source::joins::LeftOuter>, diesel::expression::operators::Eq<schema::blogposts::columns::id, schema::tags::columns::post_id>>, diesel::query_builder::select_clause::DefaultSelectClause, diesel::query_builder::distinct_clause::NoDistinctClause, diesel::query_builder::where_clause::WhereClause<diesel::expression::operators::Eq<schema::tags::columns::tag_name, diesel::expression::bound::Bound<diesel::sql_types::Text, &str>>>>`rustc(E0277)
posts.rs(477, 103): the trait `diesel::Queryable<diesel::sql_types::Nullable<(diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer, diesel::sql_types::Text, diesel::sql_types::Integer, diesel::sql_types::Integer)>, diesel::sqlite::Sqlite>` is not implemented for `(i32, std::string::String, std::string::String, std::string::String, i32, i32, std::string::String, i32, i32)`
Пацаны, я в печали. Почему у вашего ЯП такой хуёвый суппорт? Коммьюнити - говно! Я искренне хочу перекатиться с Laravel/Lumen, но не нашёл хотя бы близко подходящей альтернативы. Фреймворки какие-то отстойные, ORM вообще никуда не годятся. SQL в миграциях, штооо. Это совсем пиздец уныние. Я ведь просто хочу удобно писать REST API и при этом не хочу плодить кучу говна каждый раз заново, из проекта в проект, которое я всё равно не буду суппортить. Неужели я так много прошу? ((
В чем проблема использовать раст для веба? Вообще в чём проблема использовать язык с более широкими возможностями для более узких целей? Cужение области применения достигается вполне успешно как раз библиотеками и фреймворками, поэтому тут анон, который хочет Laravel, прав.
>>1749928
Тут только есть наблюдение что в не-ООП мире ща немодно делать монолитные фреймворки. Поэтому тебе надо будет собрать какой-то свой конструктор из библиотек. Я юзал что-то типа warp + sqlx, но вариантов много.
>В чем проблема использовать раст для веба?
Есть секта верующих в производительность. И пофиг что 90% времени занимает работа базы и пинг до сайта у тебя под сотню.
>что в не-ООП мире ща немодно делать монолитные фреймворки
Именно с ООП мира и пошли микрофреймворки. Не-ООП мир сейчас никакие идеи не продвигает, вообще все что можно уже перетащили в свои мультипарадигменные языки
> вотвот
Не завезли ещё.
> конпелятор незавезли
https://github.com/rust-lang/rust/issues/73908
> Current status summary (2020-07-04)
> There is no timeline for any level of support.
> The x86_64 version of rustc works under Rosetta, producing x86_64 binaries that themselves run under Rosetta.
> The x86_64 version of rustc has cross-compiled an aarch64 version of rustc.
> The aarch64 version of rustc has compiled an aarch64 version of rustc.
> The aarch64 version of rustc has cross-compiled an x86_64 version of "hello world".
>Слишком лоу лвл
Да не такой уж раст лоу левел. Типы примерно как в скале, ADT, паттерн матчинг, функции-хуюнкции, трейты — всё как у людей.
Ну да, тебе иногда приходится делать .as_ref(), но это говно за неделю учится и становится фоном, на который внимания не обращаешь. Считай просто часть DSL.
В дополнение к предыдущему посту: есть Future и async/await, есть итераторы с кучей операций а-ля map/flatmap, есть Option и Result, есть стримы тоже с кучей операций (не fs2, конечно, но с пивом прокатит).
По мне так для веба абсолютно годный набор фунциональности в языке. В отличие от куска goвна, в котором ты императивные простыни пишешь всякий раз.
>Не-ООП мир сейчас никакие идеи не продвигает
Они никогда и не продвигали. Напомню что фишкой ноды были именно АСИНХРОННЫЕ КИШОЧКИ СТОПИЦОТ МЕГАЗАПРОСОВ В НАНОСЕКУНДУ, а позволяющий пересадить версталомакаку на бэк жабоскрипт шел бонусом - просто разрабам показалось удобным не изобретать велосипед, а спиздить быструю жид-машину у хромога.
>Есть секта верующих в производительность. И пофиг что 90% времени занимает работа базы и пинг до сайта у тебя под сотню.
Есть околореалтаймовые задачи, внезапно. И да, с пингом и работой с базой борятся в первую очередь - с первым борются императоры облаков путем мелланоксов и прочих дорогих игрушек и пердолингом сборочек гипервизоров и прочих опенстаков с кубернетисами, со вторым - прорвой ультрабыстрых носкул-баз.
Так что производительность нужна не только что бы в 4к120фпс играть, у всяких скальпотрейдингов бирж крипты требования к реалтайму раз в 10 пожесче чем у привередливого пекабоярина.
Стримы не стандартизированы, так что смотреть только в крейте futures-rs где эти самые стримы и определены, ну и в рантайме который ты выберешь.
Написание своих стримов тоже задача нетривиальная, потому что асинхронных генераторов (да и простых генераторов тоже, лол) не завезли, а значит придётся ебаться с пинами/прожектами и прочим говном.
Не для веба, а для бикенда! Это джве большие разницы! Это server side. Это не только PHP, это Java, .Net это Python и Go. И да, для конкретно моего проекта нужно что-то компилируемое и при этом вменяемое (казалось бы, несочетаемые вещи). Нашёл только 2 варика - это Swift и Rust. И первый по понятным причинам не подходит
> pub struct Velocity3<N: RealField> {
> /// The linear velocity.
> pub linear: Vector3<N>,
> /// The angular velocity.
> pub angular: Vector3<N>,
> }
> pub fn as_vector(&self) -> &Vector6<N> {
> unsafe { mem::transmute(self) }
> }
И растобляди после этого что то там кукарекают про UB, мде.
Мантры неосилятора. Вот почему после симфони на ларе можно писать свободно почти без чтения доки сам так делал, а когда ларавальщикам предлагаешь обратное, начинается маневрирование? Да потому что они тупые и привыкли делать тяп-ляп и в продакшен без напрягания межушного ганглия.
Нахуя тебе компилируемое для бекенда?
Твои байтоёбские микрооптимизации никто не заметит за нетворк латенси, походами в базу и к 3rd party сервисам.
Ну допустим у тебя есть там числодробильный тяжёлый кусок, ну так любой нормальный язык позволяет встраивать низкоуровневый код для трудоёмких задач, где байтоёбство оправдано, но блять писать весь бекенд, где 75% - сверхвысокоуровневая доменная логика и ещё 20% всякий хитрый process-based код на низкоуровневой хуите, просто патамушто конпелируемое значит быстра работаит - это наркомания.
На бекенде скорее ценится возможность быстро линейно отмасштабироваться на N узлов, и сих пор на каком нибудь устаревшем JVM говне это задача со звёздочкой, а на лоулевел параше ты там вообще охуеешь.
>На бекенде скорее ценится возможность быстро линейно отмасштабироваться на N узлов, и сих пор на каком нибудь устаревшем JVM говне это задача со звёздочкой, а на лоулевел параше ты там вообще охуеешь.
На устаревшем JVM говне это главная фишка была ещё с первых стандартов JavaEE и корпоративных серверов приложений.
>На бекенде скорее ценится возможность быстро линейно отмасштабироваться на N узлов, и сих пор на каком нибудь устаревшем JVM говне это задача со звёздочкой, а на лоулевел параше ты там вообще охуеешь.
И кстати, для тех кому денег девать некуда, по прежнему легкой и является, заносишь лямы зелени и всё само масштабируется на JVM без ебли и пердолинга:
http://www.redbooks.ibm.com/abstracts/sg248006.html?Open
Лол, на устаревшим JVM такая JIT компиляция, что может кусок мегаабстрактного говна типа джавы, может довести до производительности С++ (и я про реальные приложения, а не тесты лошадей в вакуум). Я уже молчу про фрагментацию памяти.
Вообще плохая привычка демагогии, брать таких великих как С++, Джава etc... и потом сравнивать с куском сырого говна типа Раст.
Может сложиться впечатление, что он им как-то вровень.
Я-то мимокрок
Житами с фрагментацией памяти уже давно никого не удивить
Как языки цпп с явой за все декады удержания ради рыночка с ордами уже обученных макак остались такими же сырыми копролитами во многом всратыми бай дизайн
Такая же "великая зачем-что-то-еще-нужно не-имеющая-серьёзных-конкурентов" но только высокоуровщина в лице перла была в одночасье слита
Взял cython сишные/плюсовые либы и питон для бека, спрашивай ответы. На ситоне вроде нормас либы можно будет соединить качественно и быстро, чуть приятнее чем на голом си. Сейчас выбираю только либы и фреймворки.
Раст как и всё остальное, вроде элексира оказывается может нивывести по скорости и надежности, а ебли с ним почти столько же сколько и с сиплюсами. Ноль профитов. Плюс на питоне можно управлением серверами/облаками сделать просто и безболезненно.
Поэтому трансмут и помечен как ансейф.
И даже в доках 10 раз написано мол смотри не натвори хуйни. И ещё 20 примеров где ты возможно захочешь трансмут, но есть варианты получше.
> Нет, трансмут только размеры проверяет, а не layout.
Ващет трансмут буквально копирует байты объекта в новое место и удаляет старый. Потому (после исправления бага [1], лол) на выравнивание ему строго похуй. Тут многие думаю, что это аналог reinterpret_cast, но это далеко не так. Это аналог вызова move-конструктора. А вот оптимизируется ли копирование или нет уже зависит от LLVM (как и 90% остальных зиро-кост абстракций).
[1]: https://github.com/rust-lang/rust/pull/38670
Самые быстрые и вменяемые синхронные БД драйверы это у пхп (как для динамического языка) и джава. Если база у тебя до сих пор узкое место. И ты не хочешь вкладывать в 4-10 больше кода и контроля чем это нужно (то есть, не писать на C++ или Rust), то конечно, джава или пхп это твой выбор без вариантов.
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=query&d=9
Там, конечно, есть еще го в списке, но для полного асинхронного языка, показатели вообще не впечатляющие (ну и как по мне, чтобы писать на го, надо иметь вдохновения больше чем здравого смысла, тем более когда асинхронное программирование есть уже везде).
Ну давай удали мне значение из ENUM'а без SQL'а в миграции.
Или любую другую операцию, по типу взять стринговую колонку с дефолтом и без нон-нулл констрейнта и сделать из него ENUM (тоже с дефолтом) и с нон-нулл констрейнтом.
>>1751705
>Самые быстрые и вменяемые синхронные БД драйверы это у пхп (как для динамического языка) и джава.
Это если ничего кроме пыхапе и джявы в жизни не видел.
Питон слишком распиздяйский. У меня часто бывает так: пишу-пишу, хуярю прям, наконец оно работает - и я закрываю проект на неделю-две, ибо заебался.
Когда возвращаюсь, то код на питоне читаю с трудом. Начинаю править - вообще пиздос. На расте хотя бы строгость типов выручает.
Плюс к этому питон ещё и тупо медленный, а cython ебически костыльная параша, которая ни там, ни там.
Смысл в питоне - или прототипировать по-быстрому, или взять готовый комбаен, типа джанги. Хотя мне и на расте норм прототипируется - в этом его охуенный плюс в сравнении с сями.
Вообще, такое моё отдельное имхо, время питона, как и бейсика, осталось где-то там, когда не только лишь все могли позволить себе 48G оперативы для работы Ide и 8 ядер для компиляции. Если хренакать код в блокноте без всякой подсветки на 486DX, то питон прям самое оно - и ждать конпеляции по 15 минут не надо, и опечаток в коде минимум - типы-то указывать не надо.
> Когда возвращаюсь, то код на питоне читаю с трудом
Гыкнул нах, такая же хуйня. Вообще не ебу как это работало и почему. Но это смотря как писать, да.
> а cython ебически костыльная параша, которая ни там, ни там.
Не, это же просто си с обёрткой. Как жобаскрипт/типаскрипт, а это си/ситон. Пишешь костыли - на выходе получаешь костыль ебаный. Проблемы написания, так сказать.
> Хотя мне и на расте норм прототипируется - в этом его охуенный плюс в сравнении с сями.
Тоже хочу раст, но подожду еще годик, пока состарюсь его нормально не доделают, вместе с либами. Или команда раста разъебется и новую найдут. Или форкну сам раст к тому времени.
> 48G оперативы для работы Ide и 8 ядер для компиляции.
Как тебе сказать... Дело в том что компиляции ждать в некоторых проектах приходится по 8 часов на кластере. Так что ты поосторожнее с этой хуйней. Не то чтобы это сильно к расту относится, но и раст ну нихуя не быстро компилирует. И это нихуя не хихи-хаха, это реальная проблема для разработки.
Я серьезно. У тебя есть аргумент против? У языка только 1 изъян - он еще молод, а молодость не наруку молодым ЯПам, инфраструктура еще зеленая, но это дело времени. С инженерной точки зрения - уникальнейший язык программирования. Гонять байтики на топовых скоростях, не высирая при этом UB на каждом пук-среньке, как в с и с++, имея синтаксис полускриптового-полуфункционального языка без блевотины. И безопасность памяти в 98% случаев (остальные 2% случая ансейфа идут на фокус во время тестов), не имея сборщика мусора.
Это официально первый язык в мире, которому удалось и рыбку съесть, и на хуй сесть. Казалось бы, это было невозможно.
Ну, так скажем, это явно не про меня и не про мои масштабы. Хотя перед растом я пробовал Julia (идеологически она замена питона для яйцеголовых) - вот там оно пиздос как долго собиралось.
Вот лет 10 назад, будь даже раст так же развит, как сегодня, я бы может и остался на питоне - на 2гига/2 ядра далеко не уконпеляешь, а больше у меня тогда не было.
>а 2% так называемой безопасности с памятью это всего лишь 0.01% реальных
https://www.chromium.org/Home/chromium-security/memory-safety
https://msrc-blog.microsoft.com/2019/07/18/we-need-a-safer-systems-programming-language/
~70%
>>1752487
>>1752504
>пук
>>1752505
> РЯЯЯ АНСЕЙФ РЯЯ
Опять гуманитарии срут в треде. Иди с пхп ебись, неосилятор.
>Это официально первый язык в мире, которому удалось и рыбку съесть, и на хуй сесть. Казалось бы, это было невозможно.
Это связанно с тем, что он юзает наработки современных computer science, теории типов и компиляторов. Ну и стоит на плечах гигантов конечно (llvm, компилы плюсов и си). У Rust ещё есть куда расти и где развернуться в плане оптимизаций и анализа.
Большинство остальных языков по сути только комбинируют подходы 30-ти летней давности.
О том и речь.
В хромиуме сейчас открыто 62590 багов.
Всего счетчик багов переваливает за миллион.
По твоей ссылке 70% от 912 багов
Это 638 багов
Это 1% от открытых на данный момент багов.
Это 0.06% от всех открытых багов.
Как я и говорил значимость раста для безопасности СИЛЬНО преувеличена.
>По твоей ссылке 70% от 912 багов
>Это 1% от открытых на данный момент багов.
Это критические и опасные баги. И анализ на их основе.
Причем тут открытые баги? Если это был анализ на основе всех открытых багов, то окей - твоя правда. И какое распределение опасных или критических багов среди открытых сейчас ты умолчал.
Можете сходить в асм тред, там вам объяснят, что даже один такой баг - это потенциальная дыра в безопасности всей программы. Поиск и устранение таких багов - это сотни тысяч долларов.
> С 2004 года Центр реагирования Microsoft Security (MSRC) обрабатывает все обнаруженные уязвимости безопасности Microsoft. Из всей этой сортировки выделяется один удивительный факт: как говорил Мэтт Миллер в своей презентации в 2019 году в BlueHat IL, большинство исправленных уязвимостей и с назначенным CVE вызваны тем, что разработчики непреднамеренно вставляют ошибки повреждения памяти в свой код C и C ++. Поскольку Microsoft расширяет свою кодовую базу и использует больше программного обеспечения с открытым исходным кодом в своем коде, эта проблема не становится лучше, она ухудшается. И Microsoft не единственная, кто подвержен ошибкам повреждения памяти - это только те, которые приходят в MSRC.
https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/
В России же на нем вакансии появятся в следующем году? Смотрю на запад, там уже. Хочу пилить что-то хардкорное на расте.
Чтобы побеждать в бенчмарках? А потом говорить что """"безопасный язык"""" быстрее крестов. Правда, злобные кресты все равно почему то быстрее, вот вредины.
>пруфов конечно же не будет.
Не будет. Чисто интуитивно, ведь надо следить не только за всякими временами жизни, но и еще за одной сущностью (владение). И по отзывам, как долго ублажать компилятор чтобы заработало.
>Можно для начала переписать лишь некоторые модули
И внезапно безопасность всей системы остается такой же низкой, как низка безопасность самого уязвимого непереписанного модуля.
Так нет, раст быстрее жи.
Совсем плюсодибилы стыд потеряли уже, скрины обрезанные кидают и выдают за аргумент.
А в рамках одного и того же LLVM-а он и си раздрачивает.
>Чтобы побеждать в бенчмарках?
В том числе и для этого.
Это картинка какого года? 15го?
Тут, кстати, и код тестов есть. В некоторых вообще нет unsafe.
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-gpp.html
>>1752834
>Не будет. Чисто интуитивно, ведь надо следить не только за всякими временами жизни, но и еще за одной сущностью (владение). И по отзывам, как долго ублажать компилятор чтобы заработало.
Что-то где-то от кого то слышал, пруфов не будет. Понятно.
>И внезапно безопасность всей системы остается такой же низкой, как низка безопасность самого уязвимого непереписанного модуля.
Поэтому нужно переписать его.
>Не будет.
Ну не будет и не будет, всё равно 80% работы над кодом — это его поддержание/фиксы/расширение, а не написание нового кода.
>И внезапно безопасность всей системы остается такой же низкой, как низка безопасность самого уязвимого непереписанного модуля.
Снова потому что ты скозал?
>>1752848
>5:5
>раст сливает крестам
У тебя в голове arithmetic overflow чтоле, плюсодибил?
>>1752835
>>1752841
>>1752844
>>1752848
Все эти тесты на самом деле вообще не роляют.
В 15-ом году Rust был по скорости как Java, а то и хуже.
В 19-ом году Rust по всем пунктам взъебал плюсы и си.
Сейчас он въезбал си, но уступает плюсам в некоторых тестах. Эти тесты пишут и отправляют туда такие же аноны. Завтра какой-нибудь растаман напишет лучший тест, а послезавтра сишник взъебёт и плюсовиков и растаманов вместе взятых. Поэтому сомнительные пруфы чего-либо нибудь.
Язык нужно судить по рантайму и оптимизациям. Рантайм у раста меньше плюсов и больше си. Но по оптимизациям он им уступает (+ баги компилятора). В будущем это возможно поправят, но сейчас он очевидно по некоторым пунктам должен уступать плюсам и уж тем более уступать си. Хотя в тестах внезапно рвёт си, но это скорее говорит про качество самих тестов.
https://xakep.ru/2006/12/16/35784/
>Я отлично понимаю
Нет.
>Что язык (с ансейом везде) безопасный и быстрее с++.
Rust гарантирует безопасность в safe подмножестве и по скорости он на уровне плюсов (примеров масса, что в практике, что в теории).
>Значит ты умышленно вредишь языку, ясно.
Я не собираюсь убеждать тебя изучать Rust, с чего мне это может быть нужно? Вы и ещё несколько анонов, что тут срёте уже несколько тредов - просто хейтеры. Я сомневаюсь, что вы даже плюсы знаете, которые (якобы) защищаете.
Я это всё пишу для анонов, которым возможно интересен язык и его экосистема. Дабы они не велись на все эти бесконечные набросы про ансейфы, скорость, баги, якобы сложный синтаксис и прочее.
>Rust гарантирует безопасность в safe подмножестве
Круто. А то что этот safe код дергает постоянно unsafe коляна закроем глаза.
>по скорости он на уровне плюсов
Плюс минус, но чаще минус.
>Я это всё пишу для анонов, которым возможно интересен язык и его экосистема. Дабы они не велись на все эти бесконечные набросы про ансейфы, скорость, баги, якобы сложный синтаксис и прочее.
Ну то есть занимаешься умышленным враньем, о чем тебе и указали.
>почему язык вставляющий лишние инструкции медленнее другого языка
Во первых раст не генерит так уж много лишних инструкций (он их вообще почти не генерит). Разница между safe и unsafe кодом в реальных проектах - доли наносекунд. Это пустяк, по сравнению с другими безопасными языками. Но при этом ты можешь отключить этот функционал в раст (привет unsafe!).
Во вторых если ты пишешь на плюсах или си, то ты их так и так будешь вставлять, если хочешь писать безопасный код.
>>1752901
>А то что этот safe код дергает постоянно unsafe коляна закроем глаза.
Нет, не закроем. И не закрыли. Эту багу исправили, а колян ретировался из-за хейта.
На некоторые особенности unsafe накладываются ограничения в safe подмножестве. И искать баги, которые ты знаешь где искать (unsafe) проще, чем искать их по всей программе, которая вся unsafe (как в плюсах или си).
>Ну то есть занимаешься умышленным враньем, о чем тебе и указали.
Враньём и невежеством занимаешься ты и твои сотоварищи. Вы вообще ничего не понимаете в расте и его экосистеме, но продолжаете тут семинить и набрасывать ради внимания.
Тут я отвечал, отчасти >>1752862
Ну и многие, т.н. "проверки раста" - делаются на этапе компиляции. Другие конструкции делают по минимуму проверок или разворачиваются в более сложные структуры.
Ну и сами эти "проверки" не жрут столько, сколько о них принято говорить. Тут был анон, который утверждал, что эти проверки чуть-ли не каждый такт происходят как в какой нибудь GC. Это чушь, но ему тут поверили. Кто-то даже "разуверился" в расте, лол.
В Расте UB, который происходит в библиотеке, ограничен этой библиотекой. Соответственно, если пофиксить этот баг, то ты автоматически фиксишь вообще весь код, который только использует эту либу. А инвалидация итераторов и прочее подобное говно считаются фичей, поэтому никто никогда не будет их фиксить. Да и пофиксить без потери производительности нелья, потому что компилятор не помогает.
Дружок, ты какой-то ебанутый. Ансейф, это не плохо, это потенциальная возможность сделать плохо, когда на разработчика ложится чуть больше ответственности, чем обычно.
Допустим, есть у тебя бинарные данные, в которых ты 100% уверен, что там некая repr(C) структура. Берёшь, и через transmute ебошишь в ансейфе. Какие у тебя претензии к такому подходу?
Коляна загнобили за то, что через ансейф он пытался наебать бч, создав потенциальные дыры в безопасности. Ну дак, все остальные ансейфы в расте также худо-бедно просматриваются на предмет таких выкрутасов.
https://this-week-in-rust.org/blog/2020/07/14/this-week-in-rust-347/
Постоянно висят вакансии.
> ведь растаманам тема ансейфа неудобна
У растаманов есть целая книжка про unsafe, где рассказывается как его применять и в каких случаях, как работает компилятор и как лучше обезопасить себя при работе с ними.
https://doc.rust-lang.org/nomicon/
Тема ансейфов юзается только ниосиляторами из треда
Ты - не используй. Вот прям совсем не используй, если совсем не хочешь проблем. А если твоя прога вылетит из-за чужого ансейфа - репорти баг её авторам, вот и всё. Либу с ансейфом юзает больше народу, чем твоё конечное приложение - соответственно, вероятность исправления довольно высока.
А у тебя всё safe и чики-пики, здорово, правда?
Ты, конечно, можешь и сразу использовать unsafe, но это не есть дефолтная опция, как в сях/плюсах. А это значит, что немного погуглив, ты, скорее всего, найдёшь решение своей проблемы без ансейфа.
Я наблюдаю обратную тенденцию. Как раз таки ребята, кто осилили и писали много на си и плюсах чаще положительно относятся к раст, потому что понимают в чем он может им помочь и в чём его фишка. Например, в прошлом треде был зумер, которому приходилось объяснять что такое ub и почему это геморрой. Он то писал на си и у него всё нормально. Ни о каких ub он и не слышал. Это маркетинговый буллщит. >1747649
Это вкратце о противниках раста в треде.
Можно посмотреть на хабре статьи про раст, где люди перешедшие из плюсов положительно о нём отзываются.
https://habr.com/ru/post/497114/
Одни из лучших статей про Rust в русскоязычном комьюнити были написаны плюсовиком со стажем.
https://habr.com/en/users/humbug/
https://habr.com/en/post/434200/#comment_19552096
Что значит не работает?
https://habr.com/ru/post/504020/
https://rust-lang.github.io/async-book/
Более глубокая поддержка async/await разрабатывается прямо сейчас
> Что значит не работает?
Это когда виснет приложение, тип того, ну когда тип тестируешь, а потом раз и отказ хех))))
> Более глубокая поддержка async/await разрабатывается прямо сейчас
Вот когда будет, тогда и приходи. Охуеть блядь, 2к20, асинк не осилили напердолить без проблем.
>>1753000
Так понимаю для тебя асинк это сложно и неважно, зумерок?
>а потом всплывает ансейф
>ансейф
На какую ты выходишь уже итерацию?
В шапку нужно вынести что-то связанное с ансейфом. Ибо поток дебилов, которые про него упоминают (ничего о нём не понимая) - колоссален.
>Да-да, магией, каким то образом раст станет быстрее.
>Да, здорово. Надо просто репортить баги в либе, ясно
>Да все все отлично понимают. Это только ты дурочка строишь из себя.
Камон, аноны, мир технологий развивается, новые, более совершенные поколения приходят на смену, откуда столько негатива? Неужели и в 2к20 большинство людей ретрограды и готовы жрать говно из 80ых по непонятным причинам?
Как зумерку-фанатику неприятно. Опять твой выбор оскорбляют, да?
>>1753012
> Охуенно. Что ещё расскажешь?
Да ничего, большего тут и не нужно. В каких вообще областях можно без асинка работать?
> Это ты сюда пришел. Это растотред, если что.
Так ты советуешь в этом разделе, мол хороший, годный язык, работайте. Советуй в другом разделе.
>>1753053
Когда приходила сишка, люди ебали технологии и си был максимально технологичным. Сейчас вайт/блек листы правят, вместо языка и критически важных либ.
Добавят борроу-чекер и сломают 80% программ, написанных на крестах, да еще и обратную совместимость в придачу, ага
И да, борроу-чекер - революция в мире языков программирования. Досель не было ни одного задокументированного эксплоита под программу, написанную на Расте, и вряд ли когда-то будет, в то время как в С/С++ коде находят переполнения буфера даже в 2к20 году. Проблемы 20-ого века должны остаться в 20ом веке, иметь ошибки памяти в 2к20 году - это просто смех, лишь показатель того, что системщина была ОЧЕНЬ долгое время в стагнации.
>большинство людей ретрограды
Тут и в других тредах про раст сидит два с половиной долбоёба, семенят, кидают одни и те же тейки, отвечают на все положительные/нейтральные посты набросами. Если отфильтровать этих мудаков, то в целом раст как раз довольно положительно встречают, учитывая положение C/C++.
5 лет к ряду быть самым любимым языком на stack overflow это тоже наверно буржуазная пропаганда или жидомасонский заговор.
https://insights.stackoverflow.com/survey/2020#technology-most-loved-dreaded-and-wanted-languages-loved
> И да, борроу-чекер - революция в мире языков программирования.
Магическое мышление итт. Это просто подсчет ссылок контекста, ты в курсе? Эту хуйня на первом курсе наверн проходится, есть в каждом профайлере. Так и называется "reference counting". Можешь в любой компенлятор добавить.
> Досель не было ни одного задокументированного эксплоита под программу, написанную на Расте
Ору
>Твоя ошибка в том что ты дядей поумнее тебя считаешь более глупыми чем ты.
Подсчет ссылок контекста это вполне примитив.
>>1753100
> Пруфанешь мб?
Пруфану мб.
https://medium.com/@shnatsel/how-rusts-standard-library-was-vulnerable-for-years-and-nobody-noticed-aebf0503c3d6
https://www.cvedetails.com/vulnerability-list/vendor_id-19029/product_id-48677/Rust-lang-Rust.html
> потому что эксплоитов, использующих уязвимость в программе, написанной на Расте, пока еще не было
Как тебе и говорил анон выше - неуловимый джо. Раст попросту не используют в продакшене и всем поебать на него.
Но в случае чего ошибок дохуя можно найти. Ошибок в сторонних либах еще больше.
>Пруфану мб.
Маня, ты эксплоит от уязвимости отличаешь вообще? Судя по всему нет.
Иметь уязвимость - одно дело, написать под нее работающий эксплоит, который исполняет произвольный код от лица уязвимой программы - совсем другое дело.
Пару дней назад нашли серьезную дыру в реализации dns сервера в винде, написали PoC эксплоита, который удаленно ставил раком компьютер. Написано на Сишечке, разумеется.
Когда подобная дичь произойдет с программой, написанной на Расте, приходи. А сейчас это не более, чем пуксреньк.
>Но в случае чего ошибок дохуя можно найти. Ошибок в сторонних либах еще больше.
Толи дело...Ой. А не напомнишь в каких языках их нет?
>>1753142
Он тебе всё правильно написал. То, что ты скинул - это какие-то мимохуи нашли баги в библиотеке. Таких багов прям сейчас кучка лежит (потому что они есть всегда).
Эксплойт это возможность заюзать уязвимость в памяти. В расте это даже через ансейф не так просто сделать.
>Он тебе всё правильно написал.
Уязвимость это и есть уязвимость. То что там не RCE а просто сегфолт - это не значит что это не эксплойт, лалка.
Вот первый же нагугленный экспойт на раст
https://saaramar.github.io/str_repeat_exploit/
Все? Можем закрывать тему что на раст не бывает эксплойтов? Или дальше начнутся маневры?
> Маня, ты эксплоит от уязвимости отличаешь вообще? Судя по всему нет.
Аааааа ору нахуй скажите ему кто-нибудь
>>1753145
> Толи дело...Ой. А не напомнишь в каких языках их нет?
Лол, тут был кукарек что там эксплоитов нет, а тут раз и конкретные уязвимости ядра. Ядра даже, не отдельных либ.
> это какие-то мимохуи нашли баги в библиотеке
> Эксплойт это возможность заюзать уязвимость в памяти.
Там даже написано как можно заюзать эту уязвимость в памяти, чтобы она эксплоитом. Хватит серить в штаны.
Ну подумаешь язык дырявый, разве так сложно признать? Зачем весь этот визг? Ради чего?
Это ты дурачок.
Уязвимость - это vulnerability.
У эксплоита есть 2 формы - глагол и существительное.
Глагол - to exploit something - использовать(читай, эксплуатировать) что-либо, в данном случае уязвимость в программном обеспечении.
Существительное - exploit - программа, цель которой - использовать (читай, эксплуатировать) уязвимость другой программы, в сфере инфобеза чаще всего цель эксплуатации - исполнение произвольного кода.
Ты бы лучше банально в википедию заглянул, прежде чем так позориться, анон.
>https://saaramar.github.io/str_repeat_exploit/
> Небольшое замечание: Rust - удивительный язык, и я действительно рекомендую его для разработки приложений, которые должны быть безопасными. Эта уязвимость уже исправлена в последних версиях. Никогда не принимайте одну уязвимость в качестве показателя общей безопасности. Я пишу об этой уязвимости, потому что мне нравится язык и ошибка, и мне интересно узнать больше.
>потому что эксплоитов, использующих уязвимость в программе, написанной на Расте, пока еще не было
А вот и мантры сектантов подъехали.
Ни один безопасник никогда не скажет что эксплойтов не было.
Они всегда говорят что эксплойтов пока не выкладывали в паблик.
Ну а тут - как всегда маркетинговый булщит о неуязвимом русте.
Эксплоиты находили уже даже в стандартной либе [1]. Правда сомневаюсь что хоть кто-то их использовал in the wild из-за отсутствия раст-программ. А вообще вот весь список [2], что нашли фаззерами, мири и иногда ручным аудитом. Как полагается большинство - колянские баги с ансейфом.
[1]: https://github.com/RustSec/advisory-db/tree/master/rust/std
[2]: https://github.com/RustSec/advisory-db
Там и используют фаззеры, изначально разработанные под С++. Правда интеграция гораздо проще, благодаря тому что фаззер можно установить в виде плагина cargo и запускать одной командой, в С++ придётся пердолиться (вообще пердоление в сборке любого С++ проекта это норма).
Странно, что в растотреде до сих пор подняты вопросы: раст нужен/не нужен, ряя ансейф, ряя раст безопасный. Это какой-то плохой знак, скажу я вам. Умные люди уже за столько тредов могли бы для себя найти ответы, а дураки способны были прочитать в мануале, что такое unsafe блок в расте.
Херня какая-то, не сразу даже понятно что происходит, потому что говно происходит. Насколько скучно должно быть, чтоб это понравилось так, что сюда притащил?
А вообще, вот вам идея, пока компилится ржавый, можно запускать видосики, какие-нибудь СЖВ идеи или правила, и в середине компиляции спрашивать их, не ответил, сразу паника сука, как же бесят эти инфантильные названия - паника, демоны, зомби, реально не хватает имен с супер героев, а еще лучше из того мультика с пони
Наткнулся на то, что Кармак щупал Rust и остался доволен. Тоже наверное человек незнакомый с плюсами, да? Интересно, что к нему успела прибежать толпа плюсодебилов и пояснить, что он не прав. Хотя казалось бы...
В небольшом размере норм смотрится, но вот при увеличении текстура ржавчины не оче убедительна. Ну и голубые шестерёнки - это, типа, металл? Есть же норм материалы, имитирующие металл.
Ещё, судя по всему, ты заюзал древний легаси рендер, переключись лучше на Cycles.
>Тоже наверное человек незнакомый с плюсами, да?
Ты, блядь, не поверишь:
https://github.com/id-Software/DOOM-3-BFG
>Я думал Кармак - полубог, и не щупает, а сразу делает продукт.
Все его достижения байтоебли были в эпоху актуальности софтрендера - вульф, дум, первые две кваки. Уже рендер Q3 был красив, но морально устарел - в видеокартах начали появляться шейдеры и пошел спрос на попиксельное освещение, которое idtech3 умел делать только офлайново в редакторе карт, запекая в лайтмапу. Шейдеры, лал, там тоже были и так же офлайново работали.
С видеокартами и рендером на GPU он уже не справлялся, думец 3 вышел неоптимизированным и сливал по красоте графона халфачу, на выпуске Rage кармаку в жопу говна залили и не подвезли NVMe SSD, в результате чего текстуры не прогружались, к моменту выпуска Doom 2016 кармак ушел, но и там успел насрать - подгружающуюся мегатекстуру, вроде, выпилили каким-то там патчем.
В итоге чувак остался в 90х, до последнеого даже не признавал кресты, отдавая предпочтение сям (первый его проект на крестах - думец 3 и выше по ссылке можете убедиться в качестве крестокода)
>кресты, ну они такие модные-молодёжные
>старик Кармак не осилил
>В итоге чувак остался в 90х, до последнеого даже не признавал кресты, отдавая предпочтение сям
Т.е. тебя не смущает, что дум 3 выходил на пс3, у которой в девките был форк протухший уже на 2007 год форк гцц? Ну ты покажи кошерный код того времени, который ещё и копилился под весь зоопарк тогдашних соснолей.
Тут даже в ассемблер никто не полез, хотя руки чесались явно (например https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/ModelOverlay.cpp#L109-L176 ), что уже похвально, лол.
>Тут даже в ассемблер никто не полез, хотя руки чесались явно (например https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/ModelOverlay.cpp#L109-L176 ), что уже похвально, лол.
Лучше бы полезли, высрали asm в отдельные файлы в папке arch, а ифдефы выкинули в линковочные настройки проекта, как это делают все нормальные люди.
> Уже рендер Q3 был красив, но морально устарел - в видеокартах начали появляться шейдеры
Пиздец зумерки любят историю переписывать. Q3 - это 1999 год, в этом году был выпущен первый джифорс, у которого шейдеров не было, только хардварный блок T&L, который так никто и не использовал, и квейк на нем работал далеко на на 60 фпс, какой нахуй "спрос на попиксельное освещение", что ты несешь вообще. Шейдеры появились только в 3-й серии, через 2 года после выхода кваки. А два года для тех лет срок очень большой.
Остальная часть поста у тебя примерно такая же шиза.
В первом и втором жифорсе (а так-то еще и в риве, есличто) были
http://developer.download.nvidia.com/assets/gamedev/docs/BumpMappingWithRegisterCombiners.pdf
В 3 серии "шейдеры" которые появились, были ничем иным как ссылка выше, только увеличенный в 2 раза и ещё к ним сделали псевдоассемблер вместо дерганья setStage().
И такая вот хуита с развитием технологии Riva TNT продолжалась еще долго, где-то до 6 поколения.
Так что шейдеры были, normal mapping был, движок устарел.
>Шейдеры появились только в 3-й серии, через 2 года после выхода кваки.
И вот по этой строчке безошибочно ты и попался википидорный зумерок, потому что хардвачные веб1.0 олды того времени как раз застали техносрач начала нулевых с подробностями про "шейдеры-нешейдеры" и архитектуры TNT, GF, GF2, ПF3 .
>Обновили на _что_, чел? На C++03? А чем этот код по тому стандарту плох? uniqueauto_ptr и ещё пол буста не претащили?
Как тебе сказать... Там по хардкору угорали:
https://github.com/electronicarts/EASTL
http://alenacpp.blogspot.com/2007/06/eastl.html
А ещё аноны поговаривают что эту хуйню не то, чтобы даже половина их же игорей юзала, а ещё анон из 2к17 нашептал, что она сосёт у м$овской, лул.
>>1756617
Там именно C++03, даже темплейты есть и ссылки юзаются активно (лол). Всё таки до 11-го стандарта измазывать всё RAII и метапрограммированием было considered harmful практикой, а потом стрелочка повернулась. Просто пеки стали мощнее и ушла необходимость делать кофебрейк чтобы пересобрать модуль.
И всё таки — чем это не плюсы? Есть функции в глобалспейсе? Или всё надо было закрыть в три::ебаных::слоя::неймспейсов? Этим кстати тоже никто не занимался до 11-го стандарта, он прямо таки сексуальную революцию устроил.
Пиздец, уже и Кармака из своих рядов плюсодебилы отписывают. Недостаточно программист, недостаточно плюсовик...И всё потому, что сказал пару положительных вещей про Rust. У вас какая-то религия, культ? Кармак оказался язычником?
>Тут даже в ассемблер никто не полез, хотя руки чесались явно (например https://github.com/id-Software/DOOM-3-BFG/blob/master/neo/renderer/ModelOverlay.cpp#L109-L176 ), что уже похвально, лол.
Вангую, из сорцов в этом месте вычистили весь Altivec код под NDA.
>И вот по этой строчке безошибочно ты и попался википидорный зумерок, потому что хардвачные веб1.0 олды того времени как раз застали техносрач начала нулевых с подробностями про "шейдеры-нешейдеры" и архитектуры TNT, GF, GF2, ПF3 .
Нет, мань, у меня gf1 был. И я запускал на нем квейк. А вот ты как раз википидорный зумерок, пытающийся сделать вид, что он помнит какие-то срачи из 2003 года, и это каким-то образом делает легитимной ту хуйню, которую он несет про 99. Хотя о 99 ты судишь по нагугленным тобой только что рекламным материалам нвидии. T&L в gf1 годился только на технодемки, повыпендриваться, для игр технология была никакая, если не веришь мне - покупай ретрокомп и пробуй, может хоть немного до твоих зумерских мозгов дойдет уровень железа тех лет.
Говна пожуй. Переиздали именно оригинальный Дум. Причем, отзывы были не самые лучшие, в связи с тормозами игры.
Пошли маняоправдания зумерка, обосравшегося с "шейдерами" GF3.
> T&L в gf1 годился только на технодемки/
Зумерок как раз не в курсе что эти три буквы относятся к вертексной части, а не к пиксельной, где и происходил весь графен.
> покупай ретрокомп и пробуй, может хоть немного до твоих зумерских мозгов дойдет уровень железа тех лет.
Я, в отличии от тебя дебика, как раз тогда еще в Visual Studio 6 на как раз ретрокомпе (GF1? celeron 300 slot A 64 MB RAM Win98) всю вот эту хуету:
https://www.khronos.org/registry/OpenGL/extensions/NV/NV_register_combiners.txt
https://www.khronos.org/registry/OpenGL/extensions/NV/NV_texture_shader.txt
https://gamedev.ru/code/articles/?id=4155
Щупал руками, от того и лолирую с дауна, у которого шейдеры в GF3 появились.
>https://gamedev.ru/code/articles/?id=4155
Статья 2002 года с обновлениями 2009
>https://www.khronos.org/registry/OpenGL/extensions/NV/NV_texture_shader.txt
>https://www.khronos.org/registry/OpenGL/extensions/NV/NV_register_combiners.txt
NVIDIA Date: February 1, 2007 (version 1.7)
мимо
>Я, в отличии от тебя дебика, как раз тогда еще в Visual Studio 6 на как раз ретрокомпе (GF1? celeron 300 slot A 64 MB RAM Win98) всю вот эту хуету:
Не-а, ты зумерок, который написал рандомную конфигурацию, которой быть не могло, потому что gf1 был дорогой картой, даже в урезанном виде, а целерон, да еще и трехсотый - это полное дно, для которого даже тнт был бы роскошью. А ссылки ты приносишь, которые в топе гугла по соответствующим запросам - даже проверять лень. Запросы типа "gefoce 1 shaders" с последующим черри-пикингом, в который даже GL_NV_texture_shader пойдет, ну а хули, шейдер же слово есть.
Поэтому и приходится сводить все к срачу о терминах (я называю шейдерами не то, что написано в свеженагугленных ссылочках - охуеть открытие). А на деле ты просто обосрался с квейком, очень сильно.
> БАБАХ БАБАХ ТРАХ ТАРАРАХ ВРЕТИИИИ
То что я мог свою Ati Rage IIC, которая была в пекарне 98 года изначально, поменять в 2000 на GF 256 и купить вторую плашку на 32 до дебича не доходит? А про биос и возможность поставить ранний PIII я узнал уже потом, когда данную пекарню сменил на Athlon XP /512/Radeon 9600 Pro.
> РЯЯЯЯ Я НЕ ОБОСРАЛСЯ C GF3, ТАК ЧТО ПЕРЕВЕДУ СТРЕЛКИ НА КВЕЙК.
Признай уже, обосрался с подливой.
