создавать надёжное и эффективное программное обеспечение
async/await наконец-то в стабильной версии!
https://www.rust-lang.org
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Предыдущий тред: >>1664495 (OP)
Решил переосмыслить язык заново. Открыл ру документацию кстати, это говорит о вменяемом ру-сообществе, я такое редко вижу и там говорится про настройку edition="2018".
Что с растом произошло кардинального в 2018? Я так понял, была нарушена обратная совместимость?
https://doc.rust-lang.org/edition-guide/editions/index.html
> When a new edition becomes available in the compiler, crates must explicitly opt in to it to take full advantage. This opt in enables editions to contain incompatible changes, like adding a new keyword that might conflict with identifiers in code, or turning warnings into errors.
Надо написать функцию, которая на входе берет строчку и пытается распарсить её в число (f64). Если в строке совсем хуйня, то в ошибке должно быть "о вей, не число совсем". Если там почти число но вместо десятичной точки запятая, ошибка должна быть "вай, почти число, может надо . вместо ,"
API тоже могут удалить, но удаление ты заметишь, только если включишь новый вариант, а в старом всё останется как есть (т.е. все старые крейты изменений не заметят). Исключения составляют методы/конструкции, которые уже сейчас имеют неопределённое поведение. Их могут изменять как захотят (и без привязки к варианту языка), потому что если ты их используешь, то твой код уже по сути поломан и от изменений он сильнее не сломается.
> И насколько часто это происходит?
Хотят раз в три года. Но будут делать только в том случае, если наберётся достаточное количество ключевых изменений. Например в 2018 варианте большинство изменений были направлены на улучшение поддержки NLL (хотя NLL портировали позже и на 2015 вариант), асинхронных функций (например сделали async ключевым словом) и улучшенного менеджмента модулей.
> но хотел бы на работу его принести
С этим я был бы очень осторожен. Главные в разработке раста чрезвычайно политизированы (все эти шуточки про смену пола и любовь к блм не из пустого места берутся) и не скрывают этого [1]. Так что если повесточка прикажет, он вполне себе смогут выписывать санкции всем неугодным и смогут вашей компании даже заблокировать доступ к крейтам и подобное.
[1]: https://www.reddit.com/r/rust/comments/gwmmum/announcing_rust_1440/
> The Rust Core Team believes that tech is and always will be political
Упс, не та ссылка: https://blog.rust-lang.org/2020/06/04/Rust-1.44.0.html
Мы Барнаульская маленькая компания. Язык мне там нужен только для того чтобы скилуху прокачать, а не чтобы галочку поставить типа "Рога и копыта теперь на расте, история успеха". Никто и не узнает на чем там микросервис.
Хочу сделать его себе основным языком, потому как старый и жирный и С++ уже не осилю. Да еще на горизонте маячит поезд с перспективами webassembly, где такие языки зайдут всегда лучше, чем управляемые.
> Мы Барнаульская маленькая компания.
А на тех кто будет поддерживать код после тебя, видимо тебе похуй? Да и так просто всё не делается. "Вчера" заблокировали крым по политическим причинам, завтра барнаул, а rust core team со слюнями выпадающими изо рта быстро побежит выполнять требование правительства, потому что политика важнее каких-то там технических деталей. Да и вообще в барнауле нацисты сидят.
> Никто и не узнает на чем там микросервис.
Зато ты узнаешь, когда не сможешь сконпелировать приложение, если crates.io заблокирует по политическим причинам все российские ip-адреса.
> Хочу сделать его себе основным языком
Себе можешь делать что угодно, но зачем компанию-то так подставлять? Принудительно переводить её на слабо-поддерживаемый язык с непонятными перспективами, особенно внутри россии.
> на горизонте маячит поезд с перспективами webassembly
Чтобы он маячил на горизонте, надо чтобы туда добавили нативную поддержку DOM. А так сейчас это не более чем игрушка, где самые топовые и быстрые библиотеки (с отсутствующим функционалом) медленней монструозных жс-фреймворков.
> если npm заблокирует по политическим причинам все российские ip-адреса.
Пофиксил тебя.
Одного поля ягоды, кстати. node.js возможно политизирован ещё сильнее. А политические санкции в коде я вообще впервые увидел в жс-библиотеках, которые чуть ли не перечисляли в лицензионном соглашении все компании которым запрещено использовать библиотеку, потому что они не соответствуют повесточке.
Блокируют, вероятно, из-за санкций. Если будет на всю Россию, то ты и сдк джавы не скачаешь и даже пхп. Причем тут раст вообще.
> побежит выполнять требование правительства
Ты предлагаешь им сопротивляться, чтобы санкции накинули уже им?
>А на тех кто будет поддерживать код после тебя, видимо тебе похуй?
Я стану ценным сотрудником потому, что кодера на расте в моем мухосранске будет не найти. Шучу, на самом деле это микросервис, его просто возьмут и перепишут. А если еще точнее, то там есть момент где нужно взять яп без GC и конечно я С++ не хочу и, в целом, давно поглядывал на раст, хотя первое знакомство у меня было с синдромом утенка. бывает
>Чтобы он маячил на горизонте, надо чтобы туда добавили нативную поддержку DOM
Ты, видимо, так и не уловил месседж. То что там будет в будущем, ему твой DOM уже будет не нужен.
> Блокируют, вероятно, из-за санкций.
А рамках ЯП блокируют исключительно на добровольной основе. Как например жс библиотеки прямо в лицензии запрещали американскому агенству, работающему с нелегалами использовать их библиотеки, потому что их работа противоречит повесточке.
> Ты предлагаешь им сопротивляться, чтобы санкции накинули уже им?
Санкциям обязаны подчиняться только крупные корпорации, а все остальные на добровольной основе. Я просто указываю, что если повесточка прикажет разрабы раста на добровольной основе вполне могут оставить россию без своего языка.
> Я стану ценным сотрудником потому, что кодера на расте в моем мухосранске будет не найти.
Тебя просто пошлют нахуй с такими идеями.
> То что там будет в будущем, ему твой DOM уже будет не нужен.
А, ну я просто в настолько далёкое будущее не заглядывал. А так да, нейроинтерфейсы, ИИ, перенос сознания, вечная жизнь, сингулярность. Правда раст и сам вебассембли там тоже будут не нужны.
>Санкциям обязаны подчиняться только крупные корпорации, а все остальные на добровольной основе
Не слышал такое, да ну и не хочу в полит срач. Тебе походу очень скучно, раз для тебя это важно.
>далёкое будущее не заглядывал
Ты просто рогом уперся в политику. Или очень скучно. Иди уже в /po, там тебя поймут.
> Ты просто рогом уперся в политику.
Лол блядь. Сами разрабы раста заявили что политика настолько же важна, насколько и технические детали языка. Если не хочешь обсуждать политику и соответствовать повестке, то нехуй тебе делать в этом треде и изучать этот язык в целом.
Я >>1745096 и есть >>1745177 и не смотря на то что знаком с технической частью раста, так же знаком с тем, что они ставят политику наравне с ней и активно продвигают свои идею. Я сам был в восторге от языка, но последние события изменили мой мнение к нему. Так что иди нахуй, раз считаешь меня невменяемым.
Ну а что если я с ними согласен?
Вот прилетят инопланетяне и скажут - "какие нахуй вам технологии, у вас 70% до сих пор голодают, 1% усрался жиреть, и вы до сих пор пиздите друг друга по цвету кожи и форме сосков??"
Но на самом деле мне глубоко насрать. Я когда беру молоток, мне наплевать что компания которые его создала в чем-то там убеждена, мне нужен именно этот молоток, а тебе нужно идти в /po с этой темой. Тебя там реально поймут, там есть кодеры.
У раста быстрый только актикс, который известен своим отношением к безопасности и даже сейчас имеет кучу багов с утечкой памяти: https://github.com/actix/actix-web/issues?q=is%3Aissue+is%3Aopen+leak
Я бы его использовал с осторожностью (а лучше не использовать вообще). В целом достаточно быстры некоторые библиотеки жавы, го, и внезапно .net core: https://www.techempower.com/benchmarks/
Если уж достал линейку, то показывай чистые тесты без бд и рандома.
https://www.techempower.com/benchmarks/#section=data-r19&hw=ph&test=plaintext
> У раста быстрый только актикс
Не, раст сам быстрый, на уровне с.
> В целом достаточно быстры некоторые библиотеки жавы, го, и внезапно .net core:
Если на расте говна в либы навалили, то боюсь представить что там будет.
Тогда можно мозги с шарпами не ебать, сразу же взяв си.
>некоторые библиотеки жавы
Ровно пока не подключишь тырпрайзные либы, которому срать на ресурсы.
Не знаю что у шарпистов. Но думаю такое же.
А на го, писать долго, просто невозможно, если хотя бы немного знаешь как сделано это в других языках боль
> Не, раст сам быстрый, на уровне с.
На бэке эта быстрота очень редко когда имеет решающее значение. Особенно если ты сам не умеешь её использовать. Вот ты лично например знаешь как бороться с фрагментацией памяти при огромном количестве запросов? Сможешь сам написать обёртку над аллокатором, чтобы всё это работало быстро? Нет, тогда без ГЦ тебе делать нечего - там умные дяди уже всё за тебя сделали.
> Если на расте говна в либы навалили, то боюсь представить что там будет.
Конкретно в .net core веб-сервер пишут разрабы из микрософт и они там очень неплохи, потому что команды из asp.net и разрабы вм активно сотрудничают и даже вводят новые фичи, котоыре в первую очередь нужны именно для ускорения веб-сервера. Единственный недостаток шарпа (особенно в сравнении с жавой или жс) - маленькое коммьюнити и порой отсутствие библиотек.
> На бэке эта быстрота очень редко когда имеет решающее значение.
Смотря что делать.
> можешь сам написать обёртку над аллокатором, чтобы всё это работало быстро?
Да делов-то, просто спрошу на форуме как правильно написать. Либо просто найму человека который за меня напишет.
> Единственный недостаток шарпа (особенно в сравнении с жавой или жс) - маленькое коммьюнити и порой отсутствие библиотек.
Шарп это майкрософт же, зашквар похуже политики раста. Если у раста "политика имеет значение", то микрософт и политика = одно целое.
> Круто, вообще в вебе решает кэш и процессорное время.
Ну тогда тебе дорога в С/С++. Хоть они поля автоматом и не переставляют (на самом деле элементарно делается вручную), но у них хоть компиляторы умеют оптимизировать код, в отличии от раста. Растовский компилятор сам практически не делает никаких оптимизаций и просто выплёвывает огромное количество почти не оптимизированного IR-кода для LLVM, в надежде что последняя там что-нибудь соптимизирует. Отсюда и огромное время компилирования. И что самое смешное разрабы компилятора любят ругать ллвм за медлительно, но почему они ожидают от линкера быстроты если он сам выполняет 90% оптимизаций, которые компилятор смог бы выполнить в разы быстрее из-за дополнительной информации.
> Because of that, on some topics at least, there is no way to avoid taking a political stance.
Шепчу.
Нужно срочно создать тему про пыню на форуме раста. Всё же политика имеет значение.
Я ничего не считаю. Просто привожу несколько фактов. Они периодически пытаются добавить какие-то оптимизации, но они либо что-то ломают, либо оказываются слишком медленными, либо так и остаются экспериментальными на протяжении годов.
Что особенно смешно от языка, с кучей излишних дополнительных проверок, например того что индекс меньше длины массива. Авторам библиотек остаётся либо использовать unsafe в тех местах где раст ллвм обсирается с оптимизациями, либо использовать ебанутые конструкции вроде
assert!(i < array.len());
let a = array;
чтобы ллвм было легче понять что достаточно одной првоерки а дальше i всегда меньше длины массива.
> к 2030, когда сменится поколения, все будут писать
Что писать будут? Где хоть одна либа написанная нормально? Кто там пистаь будет, какие гении? Уже сейчас никто писать не может ничего нормальное, говно на говне, зато "мы принимает политику кокок".
Через 10 лет всё это говно китайскими хацкерами в бесконечный локдаун уйдет, а сервера будут натурально гореть, когда обнаружат уязвимость в интел 11.
Контрибьюторы слишком заняты переименованием расистских слов в более толерантные термины:
https://github.com/rust-lang/rust/pull/74127
https://github.com/rust-lang/rust/pull/74150
И баном всех несогласных, лол.
Некогда им вашим техническим говном заниматься. Писать код слишком сложно, лучше что-нибудь ещё расистское переименовать.
Ебаните туда коммент в стиле "черные разработчики оспорблены тем, что вы не спросили их мнения, вы используете свои белые привелегии, не спрашивая разрешения у черного комьюнити раста"
Они уже и часть своего комьюнити отпугнули. Несколько активные участников на реддите забанили. Ищут САБОТАЖНИКОВ [1], бан всех несогласных оправдывают парадоксом толерантности [2], мол быть толерантными невозможно, так что легче всех несогласных не слушать и забанить. Так торопились показать свой virtue signaling, что замержили коммиты до того как автор успел исправить все найденные неточности. Я вообще проигрываю с этого цирка.
[1]: https://www.reddit.com/r/rust/comments/hnfnti/where_is_the_rust_community_allowed_to_talk_about/fxbvb08
[2]: https://www.reddit.com/r/rust/comments/hnfnti/where_is_the_rust_community_allowed_to_talk_about/fxb3xjq
Ну вдруг он любит быть альфа-тестером. Можно взять супер-быстрый актикс с утечками памяти и неясной безопасностью. Или другой фреймворк, который правда будет медленней аналогов на языках с GC, ну зато вроде безопасно, если не считать те 1000 unsafe-блоков.
Ну и в расте самые быстрые асунк-функции (если ллвм соизволит соптимизировать, сам раст такой мелочью не занимается - не по барски это), правда есть два несовместимых реактора для них и каждая библиотека привязана к какому-то из них, а использовать оба одновременно не получится. Но это мелочи, зато наверное быстро (если ллвм соптимизирует).
>Можно взять супер-быстрый актикс с утечками памяти и неясной безопасностью.
И упереться в базу, продрочив оптимизацию кода, который работает хорошо если 10% всего времени, тащемта логично.
>Ну и в расте самые быстрые асунк-функции
Ага, иначе ведь в современном бэке походы в бд не пишутся, панимаю.
> Был и остался
Не думаю...
> но для бэка нахуй не нужон если ты хотя бы не яндекс.
Нет, если делать нормально, то делаешь нормально. Делать говно вообще не вариант.
> Даже полумёртвая скала которая
Ну так я и говорю что скалу нужно для бека.
> дотти десять
Че это? Лучше чем скала? Работать хоть?
>>1745431
Ни, скала. У скалы есть неплохая сетевуха и хорошие либы. Хз что там у котлина и имеет ли его смысл вообще щупат и смотреть. К тому же он от гугла.
Кто-то уже вбросил: https://www.reddit.com/r/rust/comments/hnnh9x/dark_skinned_folks_in_rust/
Ждём когда его забанят со всеми отписавшимися.
>Не думаю...
Очень много из-за долбоёбов переименовывающих веточки на гитхабе поменялось, прям перформанс на 300% опустился.
>Че это? Лучше чем скала? Работать хоть?
Это скала 3, которую так и не дождались и начали массово валить на котлин, лол. Если бы она вышла 2 года назад — никакого котлина бы не существовало.
>У скалы есть неплохая сетевуха и хорошие либы
У скалы есть жвм и нихуя своего, ты о чём вообще? На котлине/кложе/чём угодно, что на жвм работает ситуация с либами одна.
Эти все проблемы решаемые, не пизди хуйню. Главное - ограничения платформы. Си и плюсы имеют ограничения в сложности и поддержки миллионов строк кода, почти все остальные - производительность и кол-во нормальных библиотек.
Остается только сисярп и скала. Сисярп - майки, нахуй нинужны. Остается скала.
>>1745439
> И упереться в базу
Кэш, уже давно можно в озу всё важное хранить.
> Эти все проблемы решаемые
Что ж их за всё это время не решили? Стандартизировать реакторы даже в планах нет - они планируют только асинхронные функции в трейтах к концу 2021 года. Готов ждать пару лет, пока язык достаточно разовьётся?
> Главное - ограничения платформы.
Когда используют ансейф и херят всю безопасность ради того чтобы оптимизировать кусочек кода, который компилятор сам должен был соптимизировать, но разрабам лень - заняты переименованием плохих слов.
>Кэш, уже давно можно в озу всё важное хранить.
Ну ты же понимаешь, что если у тебя настолько простая ситуация, что всё закрывается одним кэшом — то ты прикрутив этот самый кэш ты и на пхп медленно не сможешь написать?
>Остается скала.
Ахуеть, чел, ты как вообще такую выборку сделал? У тебя все дома?
Да похуй, пидоры же какие-то в любом случае.
>>1745449
>>1745450
Не, нужно же прям было "я черная женщина какого хуя не спросили моего мнения я за блеклист ряяя". Ей бы еще задали вопрос "а вы точно черная?", а потом значит "вы не верите что черные погроммисты бывают ЗАБАНИТЬ".
Но тоже неплохо.
мимо нешарящий
> Остается скала.
Скалу тоже убираем. https://www.scala-lang.org/blog/2020/06/22/the-scala-center-stands-with-black-lives-matter.html
Остаётся только котлин.
> Что ж их за всё это время не решили?
Их решают в компаниях, а не в опенсорс сообществе.
> Когда используют ансейф
Это - решаемая проблема. Просто берешь и переписываешь в сейф.
> заняты переименованием плохих слов.
А это - проблема политики этих дебов, теперь совершенно ясно что они развитием языка не заинтересованы.
>>1745461
> и на пхп медленно не сможешь написать?
Нет, пхп медленнее натива.
> Ахуеть, чел, ты как вообще такую выборку сделал? У тебя все дома?
А какой выбор? Ну-ка ебани.
>>1745464
Ах ты! Ладно, ладно, хорошо, котлин. Посмотрю только! Одним глазом.
> Просто берешь и переписываешь в сейф.
Тогда он из топа бенчмарков переместится вниз. И перестанет раст быть самым быстрым языком. Хоть раст и компилируем, его безопасность с таким-то отношением к оптимизации очень дорого стоит. Там 80% абстракций будут зиро-кост только если ллвм созволит их достаточно соптимизировать, а он зачастую этого не делает. У раста гарантированных оптимизаций очень мало, а зиро-кост он зачастую только в теории или если повезёт.
> Не на столько вниз. Он все же сравним с производительностью с си.
Если ллвм созиволит достаточно соптимизировать.
> В проблемных местах это вообще вручную делается.
Вот разрабы и делают это вручную ансейфом, игнорируя те самые "бесплатные" абстракции, которые нихуя не бесплатны. А ты предлагаешь эти оптимизации убрать, лол.
Вот интересный пример: https://github.com/BurntSushi/aho-corasick Статистика ансейфов: Functions - 19, Expressions - 678, Methods - 22. Вот как оправдывается автор:
> When you combine all of this together along with trying to make everything as fast as possible, what you end up with is enitrely too much code with too much unsafe. Alas, I was not smart enough to figure out how to reduce it. Instead, we will explain it.
Самое главное сделан одним из разрабов и модераторов раста (именно он удалял все неугодные треды, лол).
Ещё один пример: https://github.com/tokio-rs/bytes Статистика: Functions - 17, Expressions - 602, Impls - 6, Methods - 18. Библиотека активно используется в коммьюнити (фактически она используется во всех асинхронных приложениях с реактором tokio) и в ней не раз находили UB и даже уязвимости.
Вот тебе и безопасный и быстрый раст. Хочешь быстроты - используй полтыщи ансейф-блоков и надейся, что ты умнее всех и у тебя UB точно не будет.
Хотя мой самый любимый крейт это конечно же https://github.com/BurntSushi/rust-memchr
Unsafe Expressions - 1896!!!
При том, что это не FFI. Там буквально пердоление с байтами, указателями и прочими небезопасными вещами.
> А ты предлагаешь эти оптимизации убрать, лол.
Нет, я предлагаю открывать байты и ебать их. Высокропоизводительные интепрайз ядра на уровне машинных инструкций оптимизируют.
> Вот тебе и безопасный и быстрый раст
Чел, я вообще бек собрался выбрать. Мне не похуй на раст только из-за производительности.
>>1745503
> Я бы сказал что производительность между си++ и джава.
Ну где-то там и стоят либы с си, да. Хорошая жава на уровне хуевастого си.
> Нет, я предлагаю открывать байты и ебать их.
Быстро ебать их сможешь только в ансейф-коде. Иначе после каждого сложения компилятор будет любезно проверять не переполнился ли байтик. В теории с хорошим range analysis эти проверки можно полностью убрать, но у раста вообще никакого range analysis нету - ни хорошего, ни плохого, а ллвм зачастую обсирается и в итоге вместо байтоёбства е тебя будет несколько десятков проверок и условных переходов и вся производительность пойдёт по пизде.
Я честно сам был фанатом раста. Очень обрадовался когда увидел этот пулл-реквест [1] и прочитал про новый фреймворк для dataflow-анализа (а именно здесь и нужно проводить большинство оптимизаций кода, с которыми не справляется ллвм). А воз и ныне там. Что-то активно там делает только один человек. Полный анализатор включён только для константных функций и генераторов (а значит и асинхронных функций), потому что он оказывается слишком медленный если включить его для всех функций.
[1]: https://github.com/rust-lang/rust/pull/65672
А что конкретно в асинке у тебя медленно? В качестве рантайма можешь попробовать smol [1], он реально очень быстр. В теории быстрее может быть только реализация рантайма поверх io_uring в линуксе, но стабильных реализаций для раста пока нет.
[1]: https://github.com/stjepang/smol
Не медленно, а проебываение и зависание.
https://github.com/seanmonstar/reqwest/issues/746
Это уже проблемы платформы, да.
Которые проявляются вот прямо сейчас, а устранимые ну вообще хуй знает когда.
Зависания - это практически самое хуёвое, что может случиться. Даже паника более предпочтительна чем зависание - панику хоть отладить и исправить можно. А вообще tokio известен своим похуистичным отношением к ансейфу. Там один чел помешанный на безопасности тоже жаловался, что с асинхронщиной всё плохо: https://medium.com/@shnatsel/smoke-testing-rust-http-clients-b8f2ee5db4e6
> Two months in, the async/await ecosystem is as immature as you’d expect. If I needed an HTTP client with async I/O right now, I’d use a different memory-safe language.
Что смешно с тех пор практически ничего не изменилось, только разве что синхронные клиенты исправили найденные им ошибки и стали довольно неплохими.
Ну это мне напоминает всяких додиков, которые "я щас запилю GUI на расте, чтоб все охуели" и спустя пару месяцев сливаются, потому что гуй оказывается - это мегасложно.
Так и тут каждый делает свою говнолибу как может, думая что если будет писать на расте, то всё автоматом станет в разы проще.
> потому что гуй оказывается - это мегасложно.
Ну не то чтобы мегасложно. Впринципе даже мне, нуфагу без опыта системки, видно направление. Скорее объемно. Что-то - вроде хочешь анимацию, а анимация это уже 8-40к строк асинхронного кода, без тестов. Простой гуи даже этот https://github.com/vlang чел напердолил вместе с своим языком, лол. Еще бы там либы были нормальные, закрытие всех багов, объемные тесты и можно начинать писать на v. Но там ансайф это повседневная реальность, лол, страшна оче даже прод-микросервис писать. Хотя можно всё в контейнеры захуярить, хмм.
> Так и тут каждый делает свою говнолибу как может, думая что если будет писать на расте, то всё автоматом станет в разы проще.
Как бы подразумевается что должно хотя бы немного проще. Иначе нахуя языки-то новые создают. Раст, как помню, создавали с благой целью - сделать проще написание сейфа системного. Но в процессе проебались, как всегда.
Ты бы какую-нибудь шапку нормальную для треда написал, вместо того чтоб их постоянно перекатывать. Добавь туда пейперов, статей про раст, QA. Чтоб в треде хотя бы не было хуесосов, которые ноют про то что в раст слишком медленный GC или "у вас unsafe. всё? соснули?"
Проблема в том, что скорее всего нужно будет вынуть кишки расту, распутать и вставить обрато. Или написать полностью свою либу для асинхронки с нуля и заменить модули в расте. Это конечно ебланство то еще, не, таким заниматься точно не стоит. Эти должны заниматься создатели раста.
Обучение:
Программирование на Rust (лекции от @matklad) (https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e)
Rust Book (ru) (https://doc.rust-lang.ru/book/)
Rust by Example (ru) (https://doc.rust-lang.ru/stable/rust-by-example/)
The Rustonomicon (https://doc.rust-lang.org/nomicon/#the-rustonomicon)
The Rustonomicon (ru) (https://github.com/rust-lang-ru/rustonomicon/blob/master/src/SUMMARY.md)
Статьи:
Что делает Rust универсальным языком программирования (https://habr.com/ru/post/504622/)
Что значит unsafe в Rust? (https://habr.com/ru/post/460295/)
C++ быстрее и безопаснее Rust, Yandex сделала замеры (https://habr.com/ru/post/492410/)
Go быстрее Rust, Mail.Ru Group сделала замеры (https://habr.com/ru/post/492410/)
Бот для Starcraft на Rust, C и на любом другом языке (https://habr.com/ru/post/416743/)
Это с ходу. Может кто и QA сделает.
И сделайте там нормальные ссылки, в md это [тайтл](url)
ёбаные скобки, абу сука
Обучение:
Программирование на Rust (лекции от @matklad) https://www.youtube.com/playlist?list=PLlb7e2G7aSpTfhiECYNI2EZ1uAluUqE_e
Rust Book (ru) https://doc.rust-lang.ru/book/
Rust by Example (ru) https://doc.rust-lang.ru/stable/rust-by-example/
The Rustonomicon https://doc.rust-lang.org/nomicon/#the-rustonomicon
The Rustonomicon (ru) https://github.com/rust-lang-ru/rustonomicon/blob/master/src/SUMMARY.md
Статьи:
Что делает Rust универсальным языком программирования https://habr.com/ru/post/504622/
Что значит unsafe в Rust? https://habr.com/ru/post/460295/
C++ быстрее и безопаснее Rust, Yandex сделала замеры https://habr.com/ru/post/492410/
Go быстрее Rust, Mail.Ru Group сделала замеры https://habr.com/ru/post/492410/
Бот для Starcraft на Rust, C и на любом другом языке https://habr.com/ru/post/416743/
Это с ходу. Может кто и QA сделает.
И сделайте там нормальные ссылки, в md это [тайтл](url)
> Ну не то чтобы мегасложно.
На самом деле очень сложно. Не зря же гуйные либы так неохотно пилят, и электрон настолько популярен. В нативных либах добавляются такие забавные вещи как интернационализация и ацессибилити, которые в разных ОС работают по-разному. Возможно за пару лет и сумеешь сделать свой фреймворк с нескучными кнопочками и лабелами (если будешь делать поверх какого-нибудь вебрендера, где уже решили все проблемы с рендерингом шрифтов и прочим низкоуровневым говном). Но дальше начинается особое веселье. Одна качественная реализация GridView может занять пару тыщ LOC и внутри быть сложнее всех асинхронных рантаймов вместе взятых.
>Не зря же гуйные либы так неохотно пилят
Пиздец у тебя в голове насрано. Гуйных либ просто жопой жуй, что на плюсах, что на сях, раст не будет исключением. Плюс в каждой оси есть встроенные, пусть и кривые.
>и электрон настолько популярен
Электрон настолько популярен, потому что гуёв настолько много и под каждую платформу они свои, что даже qt не всегда вывозит. Поэтому легче сделать на вебфронте один раз и потом использовать везде, хоть в вебе, хоть на мобилке, хоть на декстопе.
>Одна качественная реализация GridView может занять пару тыщ LOC
Пиздец как страшно. Аж пару тысяч, да? Ой-ой-ой.
> и внутри быть сложнее всех асинхронных рантаймов вместе взятых.
Ещё что расскажешь?
Гуй пилить это именно, что уныло, а не "сложно". Кому нибудь будет не лень и кто нибудь это проблему всё равно решит (особенно если будет спрос).
> Пиздец у тебя в голове насрано.
Хорошее начало дискуссии. Сразу видно профессеанала.
> Гуйных либ просто жопой жуй
С 3.5 кнопочками и лабелами? Именно что нормальных либ очень мало. Многие даже для элементарных вещей не годятся в силу отсутствия простейших контролов. А для чего-то более сложного и подавно. Посчитай в скольких из твоих "жопойжуйных" либах реализована ацессибилити? Или нинужно?
> Электрон настолько популярен, потому что гуёв настолько много
Проффисианал даже в терминологии сумел обосраться. Каких гуев? Чего много? Или речь про системные АПИ?
> Гуй пилить это именно, что уныло, а не "сложно".
Любой сложный код пилить уныло. И никакие кривляния и попытки выставить себя умнее чем есть в этом не помогут.
>а именно здесь и нужно проводить большинство оптимизаций кода, с которыми не справляется ллвм
Такие как? В Расте многое жестко завязано на порядке выполнения операций, ничего особо умного не сделаешь. Нет лишних аллокаций, поэтому не нужен эйспейп-анализ. От замудреных оптимизаций типа автомагической замены Vec на SmallVec будет больше вреда, чем пользы.
Этот фреймворк нужен не для перформанса.
>Не зря же гуйные либы так неохотно пилят
https://wiki.dlang.org/GUI_Libraries
А эта хуйня ещё менее популярная чем Rust
Когда этот самый ди уже был известен даже мне (года так с 2006) не было электронов и мобилок, даже слова "приложение" не было. Программа была прежде всего окном с кнопочками, соответственно, написание гуя тогда было куда более необходимым.
Сейчас всё куда менее монолитно и менее завязано на десктопы, поэтому и стимула писать гуй на новых языках куда меньше.
> Такие как?
Уже упомянутый мной range analysis. Пока что этим занимается llvm с переменным успехом. Что интересно, наверное около половины репортом о медленности раста идут именно из-за излишних првоерок, потому что llvm не может понять что переменная всегда будет меньше какого-то значения и повторно проверять её не нужно. Особо ебанутый пример, где таких проверок с десяток подряд: https://github.com/rust-lang/rust/issues/73512
> Нет лишних аллокаций
Лишних аллокаций в куче нет, зато есть излишнее использование стека: https://github.com/rust-lang/rust/issues/53827 или https://github.com/rust-lang/rust/issues/62446 И есть одна оптимизация под названием NRVO, которая как раз избавляет от лишних аллокаций и выполняется во время dataflow-анализа. В расте как раз недавно добавили её простейший вариант: https://github.com/rust-lang/rust/pull/72205 который, правда, помогает не во всех случаях.
>Хорошее начало дискуссии
Не ты писал, эксперд?
>Ну это мне напоминает всяких додиков
>С 3.5 кнопочками и лабелами?
>Именно что нормальных либ очень мало
Когда не можешь пруфануть ссылайся на качество. Ну так они говно просто, да.
>Посчитай в скольких из твоих "жопойжуйных" либах реализована ацессибилити?
Жду определения в студию.
>Любой сложный код пилить уныло
Есть разница между унылостью и "сложностью". Когда тебе нужно написать 10kLOC и ты точно знаешь как это нужно сделать и как оно должно работать - это уныло. Тут нет никаких копротивляний. Все эти твои киллер-фичи и нескучные кнопки уже есть, уже есть архитектура и примеры реализаций, уже есть алгоритмы для оптимизации, бест практис для i18n, для сглаживания шрифтов. И поэтому это "уныло". Писать гуй в нулевых, и переписывать гуй в 2к20 это не тоже самое.
Но кто нибудь это рано или поздно всё равно сделает, особенно на расте. Потому что есть запрос, множество есть примеров где без него никуда. Но на топе веб всё равно всех вздёрнет, ибо спрос больше. Поэтому скорее стоит ждать какого нибудь убер отрисовщика html+css на расте.
>Проффисианал даже в терминологии сумел обосраться
>Каких гуев? Чего много?
Ты на ходу забываешь о чем говоришь?
Слился? Где определение?
>Пока что этим занимается llvm с переменным успехом
И что может сделать rustc, чего не может llvm? Тебе пришло 4 байта по сети, больше ты ничего о них ничего не знаешь. Количество информации в точности одинаковое.
>который, правда, помогает не во всех случаях.
Никакой вариант не будет помогать во всех случаях в условиях, когда тебе нужны детерминированное освобождение ресурсов, использование кастомных аллокаторов, паники и паники во во время детерминированного освобождения ресурсов. В какой-то момент всё-равно придётся что-то оптимайзить вручную.
У тебя плохие примеры. Речь про то, когда можно убрать проверку индекса массива, потому что индекс всегда меньше длины массива. Вот тебе пример. Пик 1 - функция, где y всегда меньше длины массива, но тем не менее llvm вставляет вторую излишнюю проверку - пик 2. Пик 3 - та же функция, но слегка переделана, llvm уже понимает что y всегда меньше длины массива и вторую проверку не вставляет - пик 4. На стороне компилятора подобные проверки проводить гораздо проще.
Конкретно те проверки называются integer overflow check и в расте они по-умолчанию в релизном режиме не включены, потому что раст не способен их адекватно оптимизировать: https://github.com/rust-lang/rust/issues/47739
Ну так делай нормально гет и анврап_ор какой-нибудь, будет одно сравнение. Что за си++шная дрисня на пикчах??
> Объясни на пальцах - почему это проблема?
Потому что у компилятора гораздо больши информации и способов оптимизировать подобный код, чем у линкера.
> Что мешает расту в будущем это пофиксить?
Конкретно этот элементарный пример уже в llvm исправили, но более сложные возможно не исправят никогда (и как я уже сказал около половины жалоб на тормоза истекают из отсутствия этой оптимизации). Сейчас в расте над dataflow-анализом работает один человек и в приоритете у него константные и асинхронные функции (где датафлоу работает на полную мощь). Так что ждать подобных оптимизаций для простых функций мы будем ещё долго.
In acknowledgement that taking a stand against police brutality is more important than sharing tech knowledge, this account will pause tweeting until further notice.
https://twitter.com/rustlang/status/1267519580756422659
> А это проблема llvm или rust?
Конкретно тот пример - проблема llvm (потому что раст подобного анализа вообще не проводит). ЛЛВМ преобразовывал x > 7 || y > 7 в (x | y) <= 7, но при этом забывал о том что при выполнении этого условия обе переменные будут меньше или равны семи.
> Т.е. я попробую сделать что-нибудь на си или плюсах у меня будет иной результат?
Проверил в clang/gcc/icc. gcc и icc убирают дополнительную проверку (пик 1), но не преобразуют x > 7 || y > 7 в (x | y) <= 7, и в итоге получаются все те же две проверки. Стабильный сlang как и раст генерирует лишнюю проверку (пик 2), с исправлениями от раста лишней проверки нет (пик 3). Значит у них в компиляторе range analysis тоже нет. Правда мне проверку на то что y меньше длины массива пришлось писать самому.
>Потому что у компилятора гораздо больши информации и способов оптимизировать подобный код, чем у линкера.
Да нет же, не больше. LLVM IR основан на SSA, который буквально разработан ради подобного рода оптимизаций. RustC такие же фишки придётся реализовывать в присутствии мутабельных переменных и замудреных конструкций флоу-контроля вместо тупых условных переходов и Ф-функций. Это сложнее в реализации и абсолютно не факт, что эффективнее.
Есть миниатюрный smol, который на линуксе и маке использует системные функции, а на винде довольно неплохую сишную библиотеку: https://github.com/stjepang/smol
Или асунк-стд, который ныне представляет из себя смол (там был прикол в том, что автор смола считал подход асунк-стд мертворождённым из-за странного взаимодействия синхронного и асинхронного кода, пытался несколько раз неудачно исправить, но потом написал свою библиотеку с нуля и в асунк-стд заменили весь реактор на его вариант) + удобные фичи. https://github.com/async-rs/async-std
И да проблема в том, что либы очень сильно привязаны к конкретным библиотекам. Если крейт поддерживает только токио, то на другой реактор его придётся переводить самому заменяя вызовы элементарных функций (например таймеров, создания новых потоков и т.п.) с одного реактора на другой. В теории стандартизация реактора в стандартной либе (причём можно стандартизировать только трейты, а реализацию не делать) должна решить эту проблему - ты просто подключаешь нужный реактор и всё автоматически работает. Но для этого как минимум нужны асинхронные функции в трейтах и возможно что-то ещё.
Можно как указывать локальные крейты
hello_utils = { path = "hello_utils" }
так и использовать свой локальный вариант crates.io https://doc.rust-lang.org/edition-guide/rust-2018/cargo-and-crates-io/cargo-can-use-a-local-registry-replacement.html
Такой код генерирует ещё более говняный асм.
Для этого надо вводить специальные типы, возможно зависимые, может и без них можно, концептами какими то. Т.е. тип должен быть не абстрактно uint8, а конкретно от min_y до max_y, а если в него конвертируют из обычного инта, то там программист должен явно чекнуть что инт в диапазоне.
Но он не чекнет, так же как не чекает исключения в яве, как не чекает еррно в си, и так далее. А виноват язык, да.
Обновил гист. Мерси.
> Для этого надо вводить специальные типы
Для этого всего лишь надо читать посты не жопой и понять, что речь о том когда компилятор сам сможет понять, когда можно убрать проверку индекса. Например пик 1. Раст проводит проверки для каждого индекса - 0, 1, 2, 3. Хотя очевидно, что можно провести всего одну проверку - того что длина массива больше или равна 4. И если такую проверку провести принудительно, все остальные убираются - пик 2. Раст должен делать это автоматически.
Раст никаких гарантий о расположении паник не даёт. До того как сделали #[track_caller] большинство паник вообще были из глубин стандартной библиотеки.
>>1746473
Во-во. Так и живём. Сумеет ли ллвм соптимизировать, или нет? И зачастую ллвм обсирается, ведь в С/С++ таких повсеместных проверок нет и там такие крутые анализаторы нинужны.
В целом, я тут повеселил анона и потрепал нервы (да простит меня те кто помнят :) ). Но ушел я с мыслю, что технология еще сыроватая, да и я верил, что мозила наведет порядок и все будет хорошо. все таки на их средства, этот праздник жизни.
Но что я увидел когда вернулся в тред. А то что, уже другой анон, более технический подготовленный чем я, тоже оговаривает некоторые моменты и высказывает похожее разочарование. В общем, сталкивается с мыслью что его где-то наебали фрустрация.
Сама идея языка может быть и не плоха, но кадры и организация решает. И мне показалось язык окончательно забуксовал. Все это больше похоже на тестовый полигон, а не на разработку языка. Не удивлюсь, если мелкомягкие посмотрят на это все и запилят какой-нибудь свой хруст-шарп, который окажется успешнее на фоне труда раста.
>>1746812
Ну, хуй знает. Как по мне, так раст, это язык, который разрабатывается в наиболее тесном контакте с сообществом и который успешен именно поэтому.
Надеяться, что сейчас некая корпорация возьмёт под своё крылышко и всё правильно сделает, ну это как в 1917 надеяться, что ща доброе комми-государство (сверхкорпорация, по сути) как отберёт у капиталистов средства производства и тоже всё сделает правильно.
Если бы m$ могла родить что-то подобное, давно бы уже родила - кому, как не им с их экранами смерти испытывать в нём потребность. Родить не смогла (как комми не могут создать "красную залупу") - а форкнуть и довести до ума сможет? Наивные вы, пиздос.
> в наиболее тесном контакте с сообществом и который успешен именно поэтому.
Как я понял под тесным контактом ты понимаешь, когда всем несогласным с мировоззрением "главных разрабов" затыкают рты и запрещают участвовать в обсуждении [1], оправдывая это парадоксом толерантности - что единственный способ остаться толерантным это забанить всех несогласных чтобы среди оставшихся царила понимание и толератность [2]?
[1]: https://www.reddit.com/r/rust/comments/hnfnti/where_is_the_rust_community_allowed_to_talk_about/
[2]: https://www.reddit.com/r/rust/comments/hnfnti/where_is_the_rust_community_allowed_to_talk_about/fxb3xjq
Да, это плохо. Это, как раз, уход от контакта с сообществом. В идеале я даже не против корпораций, но чтобы их было несколько - как с linux.
>>1746841
>ансейф
я аж под себя сходил, нельзя такие страшные слова вот так без спойлера открыто писать. Сообщество, это прежде всего RFC и пулл-реквесты от кого угодно и их адекватное рассмотрение. Я против sjw/blm-шизы, но не уверен, что ms будет приветствовать участие сторонних разработчиков.
И как минимум в процессе разработки они уже сделали очень неплохой аллокатор, который можно использовать в С/С++ и расте: https://github.com/microsoft/snmalloc
Примечательно, что в многопоточных приложениях он один из лучших аллокаторов наравне c другим аллокатором от той же микрософт: https://github.com/microsoft/mimalloc
Если отрытая разработка позволила сделать что-то более успешное, чем до сих пор это делали корпорации, значит в этом конкретно вопросе не так уж они и успешны.
Пример из HW: Маск сделал Теслу, но есть некоторые проблемы. "Ох, ну хоть бы GM купила теслу, ужо они-то имеют опыт и сделают всё как надо". Могли бы - сделали бы с 0.
Ну и хули они лезут тогда? Сидели бы пилили свой go.
https://github.com/rust-lang/rust/pull/74127
Как показывает история линукса, не всегда сообщество может хоть что-то сделать без корпораций. Вот один занимательный примет: LTO - link time optimisation. Очень крутая оптимизация, при которой инлайнятся функции написанные даже на разных языках и удаляются лишние во время компоновки. Т.е. оптимизация которая как уменьшает размер программы, так зачастую и ускоряет её. И есть один дистрибутив, поддерживаемый сообществом, - генту, где такая оптимизация была бы очень кстати. И что мы видим? Эту оптимизацию искаробки там не сделали до сих пор. Оказывается это очень сложно. Многие пакеты ломаются при этой оптимизации, либо потому что сам линкер срёт под себя и генерирует неправильный код, либо потому что в коде есть UB (а для С/С++ юб - норма, сам линус так сказал), и при LTO из-за него начинают нарушаться инварианты.
Но вот пришла корпорация делающая дистрибудив SUSE Linux и что случилось? А они сделали кучу патчей для ГЦЦ, которые исправляют мискомпиляции с ЛТО и смогли скомпилировать с ним большинство приложений (ядро до сих пор не компилируется, лол, линус слишком сильно любит UB). И теперь ред хат тоже добавляет поддержку ЛТО - https://fedoraproject.org/wiki/LTOByDefault
Не удивлюсь если и ядро начнёт нормально компилироваться с ЛТО, поскольку у них там работает дохуя людей.
Вот так корпорации смогли сделать то, что не смогло сообщество. И на самом деле таких примеров куча.
Только вот захотят ли корморации сотрудничать с сообществом, возглавляемыми неадекватами у которых политика превыше всего. Некоторые там хотят уже чуть ли не линчевать некоторых активных членов сообщества, потому что они работают в компаниях, сотрудничающих с миграционным агентством (которые депортируют несчастных нелегалов в трусиках, что против повесточки).
Хуй их знает, там язык на очень ранней стадии разработки и всё может сто раз поменяться. Пока что примеры кода больше похожи на C# чем на раст: https://github.com/microsoft/verona/tree/master/testsuite/demo/run-pass
> И если такую проверку провести принудительно, все остальные убираются - пик 2. Раст должен делать это автоматически.
Это неэквивалентное преобразование, которое меняет дебажный вывод программы (строку с началом паники). Ни один язык, включая Хашкелль, такого делать никогда не будет . Додумывать за программиста - это не работа компилятора.
Ну или напиши RFC, которое четко прописывает, в каких условиях компилятор может менять паники местами или выкидывать их или еще чего. Докажи, что это ничего не сломает и даст профит в реальных примерах.
Причем учти, что в этом месте компилятор не "проверяет границу массива", а сравнивает одно целое число с другим целым число, ибо без необходимости добавлять магические типы, которые нельзя описать через стандартный синтаксис тебе точно никто не даст.
И что? Паника тебе скажет, что ошибка случилась на строке 8. Где это находится в ASM на поведение не влияет. В первом примере всё может сломаться на 2, 3, 4 и 5 строчке. Максимум, что тут можно сделать - это заменить ифы на свитч-кейс, но это как-то дохрена работы для супер частного случая, который можно исправить руками в один ассерт. Замени паники на аборт, может станет по твоему.
То, что у нас тут убийца плюсов, не означает, что программисту можно уже не изучать, как работают компы и компиляторы.
https://github.com/rust-lang/rust/issues/50759
Тут человеки настаивают на том же, что это ради разных паник.
> Interesting idea, but seems a bit difficult to generalize this even a little bit (if you want to avoid regressions). While each of the branches is unlikely individually, they might be statistically independent for all LLVM knows
Лол, как я и говорил. На стороне компилятора элементарно можно сделать одну проверку на happy path (то что не будет ни одной паники) и сразу возвратить результат по пути векторизовав его (а во всех примерах выше ллвм не векторизовывал код если не мог убрать паники, лол), а в случае возможной паники уже кучей ветвлений выбрать нужное сообщение. Но слишком сложна для ллвм, а для раста слишком зашкварно - не барское это дело код оптимизировать.
Яркие примеры:
Nell Shamrell-Harrington - комьюнити менеджер, лесбуха (1 пик)
Steve Klabnik - один из главных, блмщик, defund the police и вся херня в твиттере
Saoirse Shipwreckt (@withoutboats) - (2, 3 пик)
У почти всех подписи she/her, they/them, he/him в твиттере.
Половина или больше половины команды - женщины.
Я с уважением отношусь к женщинам в ИТ, но чтобы набрать половину команды женщин (при условии, что в индустрии их <10%) - нужно искать их специально.
Почему просто не набрать нормальных, взрослых, опытных людей? Зачем весь этот цирк с конями?
И к чему все эти политические лозунги в твиттере о языке программирования. Я не против, но это дико меня бесит когда политическую повестку суют куда не попадя:
https://twitter.com/rustlang/status/1267519582505512960
>Не удивлюсь, если мелкомягкие посмотрят на это все и запилят какой-нибудь свой хруст-шарп, который окажется успешнее на фоне труда раста.
Уже делают. Называется Project Verona, но возможно это только кодовое название. Юзает идеи раста в том числе.
https://github.com/microsoft/verona
Думаю главное, что Rust показал что запрос на подобные вещи есть. Гегемония плюсов и си когда нибудь должна сгинуть, но это точно будет не Rust.
Ушлы, но ленивые люди, присосались с спонсорству, собрали вокруг себя такую же команду, чтобы усилить свое влияние и по хорошему доят корову.
Это очень старая тема, тысячи стартапов лопались как пузыри, а кабанчики даже не успевали понять что происходит.
Тут просто очень крупный проект и паразитировать можно бесконечно долго. А не нравится, твою компанию сольют вмиг, ибо зло укрепилось в корню, попробуй, тронь их сейчас.
а почему там белые одни?
> присосались с спонсорству
Ну мозилла сама уже давно занимается различными диверсити, странно было от неё другого ожидать.
https://news.ycombinator.com/item?id=22057737
> Mozilla lays off 70
> I'm one of the 70
> I was working on Cranelift, the WebAssembly compiler that is also a plausible future backend for Rust debug mode. Before that, I worked on the SpiderMonkey JITs for 9 years.
> I'm one of the 70. I was working on Cranelift, the WebAssembly compiler that is also a plausible future backend for Rust debug mode. Before that, I worked on the SpiderMonkey JITs for 9 years.
Лучше б его в раст кор тим перевели. Там и так людей настолько мало, что они фичи годами пилят (в свободное от раздумий о будущем мира время).
> All the leads in QA got let go.
Что-то все корпорации резко разлюбили тестировщиков. Видимо телеметрии им хватает. Некоторые компиляторы ЯП тоже телеметрию собирают (почти все компиляторы от микрософт, лол).
Ну зато там топ-менеджеры себе каждый год зарплаты поднимают. Хороши жить не запретишь. А мозилла фоундэйшн (которая является материнской компанией мозилла корпорейшн и занимается в основном интернет-активизмом) вообще стали королями повесточки в интернете.
> а почему там белые одни?
Один, эммм, швед любитель функциональщины и хаскеля у них таки был. Наверное был самым активным контрибьютором что я видел. Комментировал чуть ди не каждый issue и pull request. Ратовал за "чистоту" языка и срался со всеми несогласными, зачастую чуть ли не унижая их своими познаниями в теории. Не так давно ушёл вместе с ещё несколькими активными контрибьюторами.
https://github.com/Centril
> Причина?
Хуй знает. В отличии от клабника никаких постов не писал. Взял и тихо ушёл.
>>1747307
Проверил - нихуя не сидит. https://www.reddit.com/user/etareduce/
>Хуй знает. В отличии от клабника никаких постов не писал. Взял и тихо ушёл.
Конечно не написал, у них там 33-й год на дворе начинается
https://www.vancouverisawesome.com/vancouver-news/vandals-deface-new-pride-rainbow-crosswalk-west-vancouver-bc-2551140
тащемта, Европка всего на пару лет отстаёт по прогрессивность от Канады.
>>1747306
Да заебался с мудаками в комьюнити жить, какая ещё причина нужна-то? Или вообще возможно?
Вот лез чувак из кожи вон, наращивал геморрой и простатит чтобы развить технологию, а в руководят всем пидорасы, банящие за неправильное мнение — я бы тоже ушёл.
Алсо, мозилла активно топит нахуй оптимизирует всю свою технологичную часть
https://news.ycombinator.com/item?id=22057737
что, возможно, ещё один повод почему бы самому не съебаться с тонущего корабля.
1 пик его.
https://github.com/withoutboats
2 пик >>1747289 его.
https://github.com/Centril
Ну хоть он тот ещё фрик, для раста сделал более чем дохуя. В частности именно он сделал фьючерсы безопасными придумав абстракцию в виде Pin'ов и в целом активно их запиливал, вместе с ещё большим фриком (причём со справкой) Аароном Тюроном (один пост в его блоге скажет больше, чем смогу я: http://aturon.github.io/personal/2019/06/24/survivor-skills/ ).
C, Cobol, Ada, Haskell, Fortran, Lisp, Python, R, Kotlin, Swift, Objective-C, PHP, C++, C#, Lua, РЖАВЫЙ
Что за тупость? Неужели никто не подумал ни секунды про маркетинг там или воспринимаемость?
>>1744787 (OP)
>а раст так и не осилил
А может да ну его нахуй этот раст? Ну правда:
1) компилер говно неоптимизирующее
2) команда говно
3) сырые крейты с дырами
4) в продакшене почти не применяется спустя 5 лет после релиза
Какие есть преимущества по его изучению? Я в унынии.
>Буква
>Аббревиатура-неназвание
>Пропихнутая толерастнёй фамилия рандомной пизды из 19 века
>Фамилия хуя спиздевшего концепт у великого русского математика из одессы
>Аббревиатура еще тупее
>Губа-имеющая_какой-то_смысл_аббревиатура
>Питон
>Другая буква
>Название рандомного острова
>Быстрота
>Объективная буква
>Симпотичная домашняя страница
>Буква++
>Буква-решотка
>Сокращенное имя бабы создателя
лол,
в реале тупа дроч на лофт
https://www.youtube.com/watch?v=sPYHXR6QyMY
Смотря в чём.
В среднеуровневых я думаю хорош C# (ну или Java)
В высокоуровневых (при всей возможной ненависти) ещё очень долго протусуется JavaScript (+ TS)
В низах как были, так и останутся C/C++. Никуда ты от них не убежишь, к сожалению.
Всё остальное - говно на пару лет. Сегодня - есть, завтра - нету.
> В низах как были, так и останутся C/C++. Никуда ты от них не убежишь, к сожалению.
Это печально.
Разве что новый стандарт плюсов с модулями и асинхронщиной аля C++23.
Rust появился в 2006 году. Go появился в 2007. Первые 1.0+ релизы 2015 и 2012 соответственно. Это "новые" языки.
Большинство языков, что мы юзаем сейчас уходят корнями в 90е, глубокое начало нулевых.
Самые новые, аля Swift и Kotlin это начало десятых-конец нулевых.
Это не разработки, которые можно сделать за день. Если кто-нибудь возьмётся за это серьёзно сегодня, то результат мы увидим лет, эдак так, через 5-10.
Си и плюсы уже существуют ~40 лет. Что помешает им просуществовать ещё 10? 15? А если завезут новые стандарты с поддержкой сети, с пакетными менеджерами, быстрой сборкой и прочей чепухой? И конечно любой камень в огород этих "новых" языков это повод ещё раз подумать, а стоит ли на эту фигню тратить своё время и силы?
>Rust появился в 2006 году. Go появился в 2007.
Нет, чел, не появились. Они появились когда вышли первые релизы. До этого это были другие языки. Разве что годик за глаза до релиза вписать можно из-за полноценной работы над языком.
Я вот писал где-то 2 года назад язычок и компилятор к нему на диплом, возможно допилю за пару-тройку месяцев до 1.0 ещё через 2 года. Ему будет 4 года если я над ним целенаправленно работал меньше года? Не, нихуя. Не надо считать года когда эти языки лежали у кого-то в виде лабы1 или в виде идей в голове.
>Не надо считать года когда эти языки лежали у кого-то в виде лабы1 или в виде идей в голове.
С чего бы это вдруг не надо? Вопрос не в том когда ты эти языки выпустишь, а сколько ты будешь над ними работать. Мы говорим о том насколько вероятно что сейчас или ближайщем будущем появится ещё что-то аля плюсы или раст. И вероятность этого - крайне мала.
Если ты 4 года будешь ебаться с языком и выпустишь его через 4 года, то оно выйдет через 4 года. Мне похуй сколько оно будет у тебя где лежать, когда у него выйдет первая версия или за сколько ты это напишешь.
Ну и обычные сроки производства языков в индустрии я тебе назвал.
Котлин может быть и нет, а кресты очень даже да. Даже если ты в раст собрался, кресты тебе там понадобятся. Ведь ты будешь ебать и оборачивать крестовые библиотеки, написанные для тебя крестовыми программистами. Потому что нормальных библиотек без дырок за 5 лет в раст не завезли толком. Ну и си, само собой разумеется. Ведь тебе и си библиотеки тоже придётся оборачивать, лол.
Эта активность на самом деле не показатель. Центрил делал дохуя rollup merges - это когда несколько пулл-реквестов объединяются в один после чего разом мерджатся в основную ветку, как например здесь: https://github.com/rust-lang/rust/pull/74208
Подобная хуйня у них до сих пор полу-автоматизирована и требует ручной работы. Отсюда и ебанутая активность, поскольку таких пулл-реквестов может быть десяток за день.
Область неуправляемых языков сужается. Совсем они никуда не денутся, но и видеть мы будем их все реже.
Лично мое мнение, отсутствия успеха у раста в том, что он не дает особых преимуществ перед си++, либо раст безопасен, но проседает по производительности. Либо он не безопасен и быстр, но тогда смысла и нет. При всем при этом, раст вводит сложную парадигму для разработчика. Можно конечно гордится что ты осилил и молодец, но речь не об этом. Новый язык должен разгружать разработчика, а не делать из него часть компилятора.
Мы видим, что у людей есть потребность в быстрых языках, они хотят быстрый веб и какой-то го им вроде как дает на самом деле не очень, но они верят что он быстрее джавы. Но есть и другой фронт, где люди хотят контролировать узкие небезопасные места и делать быстрый софт. И что мы имеем? Потребность в расте то и нет.
> Но есть и другой фронт, где люди хотят контролировать узкие небезопасные места и делать быстрый софт. И что мы имеем? Потребность в расте то и нет.
https://www.chromium.org/Home/chromium-security/memory-safety
Потому что сидеть на стуле неуправляемых языков никто не хочет. Те люди который хромиум пишут, не думаю что им надо конкретно работать с памятью все время. Я уверен что там только малая часть требует прямого байтоебство, а все остальное галимая логика уровня диалекта жабы или питона (если туда типы завести)
Программы становится сложнее, то что писали во времена Си, можно назвать больше скриптами чем приложениями и натягивая эту сову на глобус 2020, мы видим 70% боли (не совы, а разработчиков).
Причем мало кто думал решить проблему с память на стороне железа или операционной системы.
Ты по сути нихуя не ответил. Почему невозможен третий стул и почему он должен скатываться в джаву? На примере раста мы видим, что это не так - он работает на уровне C/C++ и при этом даёт надёжность памяти.
Хромиум, кста, уже вводит раст в систему - такой себе аргумент.
> проблему с память на стороне железа
Проблема памяти со стороны железа - это ей медлительность во всех смыслах (особенно в плане задержек). И "решают" её в основном за счёт кэша. И каждый байтоёб знает что основная оптимизация софта в плане памяти - это сделать так, чтоб как можно большее количество одновременно используемого кода и данных поместилось в кэш до того как произойдёт переключение контекста и/или другие потоки сметут всё это нахуй. Например хэш-карта под названием SwissTable (хоть и придумана в гугле, раст единственный язык, где вариант используется в стандартной либе) и она мегабычтрая. И быстрая только потому что заточена под активное кэширование процессором своих данных.
Даже разжевал почему. Потому что и первый стул ненужен. если скажешь что нужен, тогда перечитай тот пост
Ты писал?
>Как только будешь делать третий стул, безопасный, он просядет до уровня джавы
Но за базар отвечать не хочешь.
>>1747487
>Потому что и первый стул ненужен
Прямо сейчас огромное количество нового софта пишется на плюсах именно ради первого стула. Игры, 3Д редакторы, браузеры, операционки, производительные неблокирующие сервера, базы данных - это всё первый стул. Доля плюсов уже несколько лет к ряду нихера не падает. К чему вдруг она должна снизится через 5 лет, к примеру?
>>1747488
А с чего она должна проседать?
Ну например мы пишем браузер или базу данных или игру.
В согласитесь со мной, что во всех этих программах, есть только узкая часть где требуется перепихнуться с байтами. Далее абстракция которая уже дергает перепих.
То есть, потребности писать весь софт на плюсах (как когда-то в ассемблере) уже нет. Нужны только вставки.
Но раст пошел по другому пути. Он говорит либо так либо никак.
А это вообще никак уже не нужно. в этом мой месседж
> Да и в расте можно на макросах же dsl делать, не?
Можно. Можно даже на С++ внутри макросов писать и код будет автоматически компилироваться. https://github.com/mystor/rust-cpp
Основное ограничение - код внутри макросов должен быть валидным растокодом с точки зрения парсера, чтобы тот мог построить ast-дерево для передачи его функции макроса (и почти весь с++ этому условию удовлетворяет, лол).
>В согласитесь со мной, что во всех этих программах, есть только узкая часть где требуется перепихнуться с байтами. Далее абстракция которая уже дергает перепих.
Это наивняк. Посмотри на какой-нибудь анрил, к примеру.
Нельзя один раз попихать биты и пойти чилить, ты потом эти биты будешь всю жизнь пихать. Это не так работает. Посмотри на тот же хромиум, они же свой рендер сколько уже ебут. И он на плюсах в основном.
>>1747494
>По большей части из-за GC
Рофлишь? В расте нет GC.
Узкие места типа с графикой, обсчетом физики и прочее, делается на вставке, из С++.
А бизнес-логика пишется на компилируемом языке с каким-нибудь циклическим сбором ссылок (чтобы тупо не дергало, а периодично накладывала ровно оверхед)
Да, мы может потеряем 10-20% производительности, но разве не похер, во времена когда делают двустопные приложения на джаваскрипте.
> А не из-за его оверхеда производительности.
Вообще у жавы оверхед есть. Как минимум из-за отсутствия value types, генериков со стиранием типов (обе эти проблемы сейчас исправляются [1]) и тем что там все функции виртуальные. В C# этих проблем нет и он зачастую быстрее жавки (плюс в C# особенно с 8-ой версии есть куча байтоёбских конструкций для низкоуровневых оптимизаций).
[1]: http://openjdk.java.net/projects/valhalla/
Что-то мы всю нить переколбасили
>Прямо сейчас огромное количество нового софта пишется на плюсах именно ради первого стула
Почему пишется на С++, потому что каждый бизнес знает что это быстрый язык, потому что есть специалисты. И почему не пишут на других? Потому что там есть ГЦ.
Игры пишутся по принципу хуяк-хуяк и забыли, больше по инерции. Потому что С++ макака пишуших игры будет больше чем Java макак.
Браузеры - потому что конкуренция, 20% уступки конкурентам - много. По той же причине не возьму они никогда ни раст, ни Д, ни дубль W
Нет никакой проблемы взять тот же раст для реализации каких-то фич или "узких опасных мест".
>По той же причине не возьму они никогда ни раст
Так уже ж взяли, ало.
https://chromium-review.googlesource.com/q/hashtag:%22rust%22+(status:open%20OR%20status:merged)
Это конечно пыль по сравнению с долей плюсов, но тем не менее караван идёт, собаки лают.
>Игры пишутся по принципу хуяк-хуяк и забыли, больше по инерции.
Это просто дикий наивняк. Чтоб выдавать тебе тонны мыла, нужно чтоб куча PhD сначала придумали алгоритмы, а потом их куча программистов их реализовали в движках. И это не фига не две строчки кода. Это огромная работа.
>Это конечно пыль по сравнению с долей плюсов, но тем не менее караван идёт, собаки лают.
Ой, да постоянно дают кому-то с чем-то поиграться. Это вопрос текучки кадров, людям дают освежиться в новых технологиях. Никто там на серьезных шах, не будет тащить язык с мутным управлением и не замороженной кодовой базой.
>>1747531
Вот единственный способ попасть к титанам как реально используемый язык
https://kotlinlang.org/foundation/kotlin-foundation.html
Либо быстро, либо прикладное удобное
В целом ансейф позволяет пердолиться с указателями (точнее пердолиться ты с ними можешь и в безопасном коде, а вот разыменовать только в ансейве), плюс вызывать ffi-функции. Ну и в стандартной библиотеке есть ансейф-функции которые отличаются от безопасных аналогов тем, что не проверяют все инварианты и это должен делать сам программист.
Вот пулл реквест, который удаляет печально знаменитый ансейф и заменяет его на полностью безопасный стандартный аналог: https://github.com/actix/actix-net/pull/113
> AndThen with UnsafeCell #2 time: [54.157 ns 54.850 ns 55.605 ns]
> AndThen with RefCell #2 time: [54.976 ns 55.624 ns 56.353 ns]
Разница в том, что ансейф-версия выполняет при каждом использовании один счётчик, а безопасный аналог - два. Как видим перформанс упал почти в два раза с 54.157нс до 54.976нс.
На самом деле медлительность безопасного раста сильно перувеличена. Просто байтоёбы гонятся за десятыми долями наносекунд и рыдают в подушку когда инкрементируется лишний байтик.
>Так?
Да.
>>1747566
>И нахер такой стул?
Чтоб не сидеть на пиках (неуправляемые) и членах (управляемые). И при этом писать эффективные программы.
>>1747571
>Получили относительно (си) медленный язык
https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/gcc-rust.html
Медленный просто куда деваться. Это при том, что в прошлом году он его по некоторым пунктам даже обгонял, но аноны сишные постарались и вывели си выше.
Я писал, мне говорили будет поначалу больно сложно, а потом пойдет хорошо. На что я начал сопротивляться и мне сказали что я не осилил. А тут я впервые услышал фразу, как сам растаман признается в том, что язык накладывает некий оверхед на программиста.
Понятное дело я зацепился.
Меня даже за эту херню где-то забанили.
>мне говорили
>мне сказали
>я впервые услышал
>Понятное дело я зацепился.
Вся суть пр
Там прикол был в том, что сначала был Rc<RefCell<T>>. Но коляну (а написал актикс наш парень, аж на хабре хвастался) эта конструкция не нравилась - для доступа к T нужен инкремент и ветвление (у RefCell), которые гарантируют соблюдение правил борроу чекера в рантайме. Слишком скучно и медленно. И в итоге колян подумав задним мозгов ни с того ни с сего заменил эту конструкцию на своё лично созданное детище - КоляноCell [1], где вместо RefCell использовался UnsafeCell у которого этой проверки нет. При аккуратном использовании и ручном соблюдении правил как бы проблем не будет, но колян (как это всегда бывает) обосрался.
Вот так ради экономии одного инкремента и ветвления, николаеч ким сделал свою библиотеку печально знаменитой.
[1]: https://github.com/actix/actix-net/commit/20b03a478063d6bb293a6636632f976113812e13
> поначалу больно сложно, а потом пойдет хорошо
Когда начинаешь понимать почему так делать не надо и почему что-то может пойти не так, то тут и начинается хорошо. И начинаешь компилятору вместо "как же ты заебал" говорить "ой блядь, действительно проебался".
Как минимум наличие ревьюверов, которые зададут несколько хороших вопросов: "А оно точно быстрее?", "А у нас точно все инварианты выполняются?" и "А точно стоит ли оборачивать вызов небезопасной функции в безопасную словно её можно использовать как раньше без соблюдения определённых правил?"
undefined behavior
Сам язык тебе не даёт никаких гарантий, что твой код, написанный синтаксически и логически верно будет работать правильно. Тебе нужно это пердолить вручную. Проблема в том, что UB могут возникать в самых удивительных, порой, местах.
Тебе нужно понимать и помнить основные запрещённые подходы, их комбинации и обходить их. Но в итоге это проскакивает почти везде, в любом софте.
И те дурики, что пишут мол компилер растовский их слишком щемит просто не понимают, что сишный компилер бы их тоже щемил во всех этих местах (если бы умел).
Это если очень грубо.
> наличие ревьюверов
Их уволили.
> зададут несколько хороших вопросов
Всем поебать.
> А оно точно быстрее?
Да
> А у нас точно все инварианты выполняются?
Да
> А точно стоит ли оборачивать вызов небезопасной функции в безопасную словно её можно использовать как раньше без соблюдения определённых правил?
Да
Если говорить конкретно про дотнет, то иногда просматриваю их гитхаб и дядьки там очень профессиональные. Подобное колянство там не пройдёт.
https://github.com/dotnet/runtime
Слишком абстрактно.
А вообще тесты все равно писать, как юнит, так и регресс. Но в тоже время сам си меня никак не сковывает и не навязывает. Мне нравится ощущение когда тискаешь каждый байт, когда указателями щекочешь данные. Это круто.
Был бы может синтаксис чуть по современнее и с типами получше, может быть я и перекатился. А то мне просто какой-то пласт проблем решили, но головняка положили, а тесты..., что тесты, их все равно писать.
>Да что за ub, звучит как маркетинговый буллшит.
>>1747644
>кококо, наш хруст помогает от UB, правда вставляет в жопу палку
>но я пишу тесты на сях и ловлю часть этих проблем, о каком UB вы говорите
>кококо, не знает что такое UB иди гугли, на тебе боевую картинку.
Понятно, поговорили. Вы ничем от основного комьюнити и не отличаетесь, как только неудобная тема начинается.
Конечно, слились. Ведь ты самый умный, самый компетентный. У тебя никогда никаких UB не будет (тем более, что это маркетинговый булшит тащемта). Это мы тут дураки собрались, хуйней страдаем.
>>1747654
>Мне интересно, как бы тут раст меня спас?
Что за тупой вопрос? Раст это софтвара. Если ты по процессору ебанёшь кувалдой - никакой раст, ни плюсы, ни даже, прости господи, джаваскрипт тебя не спасёт.
>Конечно, слились. Ведь ты самый умный, самый компетентный. У тебя никогда никаких UB не будет (тем более, что это маркетинговый булшит тащемта). Это мы тут дураки собрались, хуйней страдаем.
Но так это и выглядит, лол. Как только я попросил прояснить что конкретно под этим подразумеваете или пример, то начался зумерский ор с картинками и маневрами.
Я даже UB железки из ардуины привел. Я хз как мне там раст помог бы, чистая магия.
>Что за тупой вопрос? Раст это софтвара. Если ты по процессору ебанёшь кувалдой - никакой раст, ни плюсы, ни даже, прости господи, джаваскрипт тебя не спасёт.
Значит, все таки, тесты эффективны, да? И этот клоунский ор был просто показателем некомпетентности?
Ну, если предусмотрено что программа должно работать при разбитии чипа кувалдой, то тест при котором чип разбивается кувалдой будет необходим. Только причём тут раст, с++ и юб? Или мне нужно ещё принести ссылку из гугла на определение слова "аналогия"? А то я вижу с аналогиями тут всё очень плохо.
> есть самый настоящий UB
Ну хоть понятно почему ты просил дать тебе ссылку на определение юб. Ведь ты сам абсолютно не понимаешь. Юб - это часть языка, конструкция или вызов функции с несоблюдаемым инвариантом при котором компилятор может натворить хуйни (а может и не натворить). К багам процессоров это не имеет никакого отношения. Охуеть тут мамины профессора ардуины и неопределённого поведения сидят.
Кому-то надо погуглить самому.
ЮБ начинается за чтением границы массива или с неточностей стандарта, или кривого компилятора и заканчивается железным фактором.
Даже переполнение ебучего маленького инта в 16 бит, это UB, который вместо двух лярдов, неожиданно превращается в 32кбайт.
Я ожидал услышать пасту, про то как больно писать под разные компиляторы или платформы, месячные дебаги плавающих ошибок. Но нет, питонисты же такого никогда не писали, они лишь знают что есть страшный UB, но раст их спасет.
Да конечно хер. Помима штопора в заднице, придется так же писать регресс тесты, ведь у растаманов UB - являются только косяки Си.
> заканчивается железным фактором
Только вот баги железа, если они не описаны в errata в юб никак входить не могут.
> писать регресс тесты
От рандомных багов, тебя никакие тесты не защитят.
А вообще ты просто какой-то агрессивный шиз с ебанутым примерой с ардуиной. Серьёзно считаешь перегрев чипа - UB языка программирования и безопасный яп должен иметь какой-то встроенный термодатчик, который с инфополя будет считывать температуру чипа?
Я тебе говорю, перечитай термин. У тебя восприятия UB как восприятие софтварной баги си.
Тут прям чувствуется влив раста евангелистов. Вы прям как выдрессированные собачки, даже одновременно триггеритесь, хотя я просто спросил конкретный пример (ну например чтение за массивом может прочитать, а может упасть, так тут прям и пишут, это неопределенное поведение)
Регресс тесты как раз и создаются чтобы проверить статус-кво.
Плавающая (рандомная) бага, может быть и логической, даже в расте. То есть, тесты писать все равно придется.
Вопрос только, насколько надо будет меньше писать тестов и соизмеримо ли это с анальным валуном в виде компилятора раста (этого б.чекера) или статический анализатор кода, был бы менее болезненный тут?!
Зачем мне читать шиза у которого перегрев чипа приравнивается к UB языка?
Напомню, что писать на чистом железе без unsafe принципиально в расте невозможно и все баги процессора ты должен отлавливать именно во всех этих unsafe-абстракциях для железа, а сейф код уже будет считать что всё нормально и никаких проблем не будет. Есть только один случай, когда ты сможешь написать сейф-код с нуля - если ты используешь библиотеку. И тогда вина за то, что конкретный баг ломает программу лежит на плечах именно этой библиотеки, потому что она не гарантирует все правила растовской безопасности в своих безопасных абстракциях над железом.
Вот те самые issue: https://gist.github.com/bb010g/705c8ffe4b9db9550a7782d25e5a53be
Сначала он кричал урёёти, нет там UB. Принесите пруфы и код и тогда поверю. Но суть в том, что расторазрабы к тому времени успели разработать интерпретатор раста [1], который может проверять ансейф код и находить там часть возможных UB. Ему принесли пруфы кода, он всё таки сделал исправление, но исправил не до конца.
Вся суета началась после того как он "исправил" баг, но при помощи мири нашли ещё один такой же, который без поломки обратной совместимости уже не исправить. Кто-то написал патч, чтобы вернуть Rc<RefCell<T>> вместо его КоляноCell'а, на что колян обиделся и высрал эпический ревью:
> this patch is boring
Всё бы ничего но ещё до этого случая у него в коде находили более сотни unsafe-блоков и несколько UB. Тут все настолько охуели, что началась ДРАМА в реддите и колян не выдержал и УДОЛИЛ репы с актиксом. Потом восстановил и заявил что завязывает с опенсорсом и вообще виноваты все кроме него.
[1]: https://github.com/rust-lang/miri
Напомним, что в недавней дискуссии на конференции "Open Source Summit and Embedded Linux" Линус Торвальдс не исключил появление привязок для разработки неосновных подсистем ядра (например, драйверов) на таких языках как Rust. Возможность разработки драйверов на языке Rust позволила бы с минимальными усилиями создавать безопасные и более качественные драйверы, избавленные от таких проблем, как обращение к области памяти после её освобождения, разыменование нулевых указателей и выход за границы буфера. Уже существует несколько сторонних проектов по реализации такой возможности:
- Разработчики из компании "Fish in a Barrel" подготовили инструментарий для написания загружаемых модулей для ядра Linux на языке Rust, используя для повышения защиты набор абстрактных прослоек над интерфейсами и структурами ядра. Прослойки автоматически генерируются на базе имеющихся заголовочных файлов ядра при помощи утилиты bindgen. Для сборки прослоек используется Clang. Собираемые модули помимо прослоек используют пакет staticlib.
- Исследователи из Китайского университета в Гонконге развивают проект для разработки на Rust драйверов для встраиваемых систем и устройств интернета вещей, который также использует bindgen для генерации прослоек на основе заголовочных файлов ядра. Фреймворк позволяет добиться повышения безопасности драйверов без внесения изменений в ядро - вместо создания в ядре дополнительных уровней изоляции для драйверов, предлагается блокировать проблемы на этапе компиляции, применяя более безопасный язык Rust. Предполагается, что подобный подход может оказаться востребован производителями оборудования, разрабатывающими проприетарные драйверы на скорую руку без проведения должного аудита.
- Разработчики фреймворка C2Rust для трансляции Си-кода на Rust, проводят эксперименты по преобразованию модулей ядра с минимальными ручными правками. Из проблем отмечается применение во многих частях ядра кода, в котором используются расширения GCC, пока не поддерживаемые в C2Rust. Для решения данной проблемы в C2Rust планируется добавить поддержку GCC атрибутов inline, cold, alias, used и section, а также расширить возможности inline-ассемблера и решить проблемы со структурами, которые одновременно выровнены и упакованы (например, xregs_state). Из существенных проблем, требующих ручной работы, отмечается невозможность транслировать нетривиальные Си-макросы в макросы Rust и необходимость переопределения типов, так как C2Rust транслирует Си-типы в определения в пакете libc, но этот пакет нельзя использовать в модулях ядра.
https://www.opennet.ru/opennews/art.shtml?num=53331
Безотносительно новости - смешно смотреть как там линуксоиды в треде копротивляются, как им неприятна. Напоминает некоторых анонов с растотреда.
>но ещё до этого случая у него в коде находили более сотни
Я сейчас просто тупо вбил в поиск unsafe по расту и там мне высрало около полумиллиона результатов.
Конечно, так себе статистический подход, но все равно, что-то растаманы тут лицемерят.
Я так понимаю, когда actix стал очень популярен, у него случился фатальный недостаток, его написали не они? Не получилось ли так, что вся это компания связанна с тем, чтобы умело увести форк у Коли?
Тот ансейф торчал наружу как сейф.
> This is internal code. There is no repeated call to get_mut() anywhere in code
> The unsoundness of the Cell API is publicly exposed through AndThenService::{clone, call}.
> UB from multiple unrelated &mut First borrows existing simultaneously while using only the safe public API of actix-service
> умело увести форк у Коли
Он сам раньше предлагал передать кому нибудь проект.
Это я говорил не про программистов, а про тебя. Ты не понимаешь зачем нужен unsafe и зачем его нужно использовать, вся твоя позиция это где-то, кем-то сказанная чушь про раст и мышление построенное на каких-то детских ассоциациях (как у анона, который про стулья писал). И при этом что-то там ещё ищешь, находишь какое-то "лицемерие".
Никто тебя ни в чём убеждать не будет, и питчить тебе раст тоже. Ты просто мимохуй, которые ни в чём не разбирается. Гуляй дальше.
Ты же понимаешь что твой пост смысловой нагрузки не несет? Тупо какая-то истерика не о чем.
>Ты не понимаешь зачем нужен unsafe
Откуда ты знаешь вообще??
Тут вообще был поинт, что говнопроектов куча, он доебались к Коле.
>>1747850
>Он сам раньше предлагал передать кому нибудь проект.
Но никто не взял или он передавал не "тем" и не "те" взъелись?
Ну как бы Коля говнил в коде не один день, почему так резко решили его доебать?
> никто не взял
Большой активный опенсорс проект не только лишь ачивка и ЧСВ, но и куча геморроя.
> говнил в коде не один день
Он не то чтобы говнил, просто это расходилось с повесточкой. Сам раст позиционирует себя как безопасный, а самая популярная и быстрая его "веб"-либа с этим проёбывалась.
Плюс он сам пытался в Торвальдса, но не потянул.
> резко решили его доебать
Случайно получилось.
>за столько лет
За сколько? 5 лет? Причём 5 лет назад это был совсем не тот язык и окружение, что и сейчас. Нормальный Rust сформировался только пару лет назад и продолжает это делать.
https://habr.com/ru/post/502046/
Redox - жив, но это экспериментальный проект. Понятно, что долбоёбы из интернета ждут, что кто-нибудь сделат второй linux и поставит всех раком, но такого не бывает.
Servo - от мозиллы закончилось финансирование, хотя контрибы всё равно контрибят.
>Даже коммент по теме нашел.
Это такие же набросы от неразбирающихся ни в чём линуксоидов как и unsafe-долбоёбов в этом треде. Не стройте своё мнение на мимохуях из интернета.
В общем, растаманы сами нехера не пишут, только переименовывают белые списки и переписывают grep, тут естественно в таком глухом лесу (околонулевой конкуренции) с легкостью выстреливает веб-либа сомнительного качество, сомнительного анона. Но виноват, конечно, Коля.
>Как интересно раст будет это все поддерживать?
> Servo project is not a complete browser. It is an experimental project that delivers components that can load, run, and display web sites and applications. These components include:
>
> A parallelized CSS Style engine that can speed page load times and improve stability
Уже в лисе и включено по дефолту везде.
> A Paint engine, called WebRender, that moves drawing almost entirely to GPUs, ensuring high frame rates and freeing up the CPU to do other work
Уже в лисе, но пока только частично выкатывают (только на некоторых конфигурациях железа)
Мавр сделал своё дело.
>кого-то поувольняли
...
>Проект не закрыли.
Пиздец
>Как интересно раст будет это все поддерживать?
>
Всё, что UB в Си точно такое же UB в Расте, смысл только в том, чтобы запрятать его поглубже. Сложности в реализации будут проблемы только на ебанутых платформах, где трёхбайтовые инты, сложение saturating и тому подобное. Но так там до сих пор пишут на фортранах и коболах, а про C новее С89 никто и не думает.
Пилился там в основном вебрендер, когда он стал юзабельным его перекинули в центральную репу мозиллы и продолжают пилить уже там.
> Note that the canonical home for this code is in gfx/wr folder of the mozilla-central repository at https://hg.mozilla.org/mozilla-central. The Github repository at https://github.com/servo/webrender should be considered a downstream mirror
Причём большинство этих постов в духе: "Зачем нужен Rust?", "У вас же unsafe", "Докажите мне что Rust нормальный тогда я буду его учить", "А команда раста педики". Это всё одни и те же зумеры-долбоёбы.
Я предлагаю в следующем треде просто нахуй слать всех этих говноедов. Не хочешь - не надо, не твоего ума дела, не для тебя это было сделано, иди дальше страдай.
Ну хуй знает. Мне такое больше нравится, чем мертвый тред. Да и вопросы не сказать что всегда пиздец.
По стопам основного комьюнити - окуклиться в своем маня мирке и тонуть дальше.
Не будет хейта, тред утонет. Это же не жопаскрипт и не петухон.
>Кстати я старше тебя раза в полтора-два.
>>1747958
> окуклиться в своем маня мирке и тонуть дальше
>будут писать всю правду
Раст тут не виноват, просто агрессивный маркетинг зло. И го, походу, уже вышел на свое плато.
>правду
Что в расте есть unsafe? Ууу, прямо в самое сердце
>>1747992
Тебе на хабр. Там отдельные крестоёбы уже придумали теорию о том, что раст агрессивно продвигают маркетолухи направляемые массонами из гугла (вау). Пишут они это, конечно, под всеми постами про Rust. Никто конечно так и не объяснил в чём заключается эта "агрессивная" пропаганда? В том, что комьюнити пишет посты о мифах про Rust? Или в том, что они пишут на нём что-то?
Хороший пример такого поехавшего: https://tsar1997.blogspot.com/
Тред с opennet.ru тоже очень показателен.
Факт в том, что Rust один из немногих языков, который встречает такое яркое и живое сопротивление в комьюнити. Хорошо заметил один комментатор, что в принятии неизбежного у вас сейчас стадия Отрицания. Скоро будет Гнев и Торг.
Я не знаю почему. Луддиты они и в 21 веке луддиты, наверное.
Думаю растокомьюнити нужно реагировать просто: Не нравится? Пошел нахер отсюда. Это не для тебя сделано и не для таких как ты. Не ходи, не засирай комменты. Ты тут никому не нужен. Тебя не звали сюда. Тебе тут не рады. Уйди отсюда. И больше никогда не приходи. Так понятно?
шутка
>Тред с opennet.ru тоже очень показателен.
Показателен. Узнал оттуда что борроу чекер не работал. Отличное дополнение инфе про unsafe везде, даже в стандартной либе. Почему то при знакомстве с языком это не говорят. А говорят что такой растакой безопасный язык.
Про бутстрап сборку тоже порадовало. Даже не то что 100 раз пересобирать раст растом, а то, что это каждый раз разный диалект.
Ты просто ищешь оправдания. Зачем? Если для тебя очевидно что Rust это маркетинговый булщит (как и ub, да) - ну так и забей на это говно, иди дальше, наслаждайся жизнью. Но ты конечно должен спасти нас всех, ведь мимохуй с opennet написал:
>лол! буквально в этом году был баг пофикшен (уж не помню во фронтенде или в llvm), из-за которого borrow checker не работал как положено. т.е. никто за ним не проверял (зачем?)) а тот не работал xD
Это твои авторитеты?
Согласен. Просто это выглядит по другому. Если даже посмотреть на этот тред, куча анонов после того как узнали о каком-то баге или проблеме в раст пишут, что то вроде
>>1745573 Или >>1747340 Или >>1745568
Эти люди сюда пришли для чего? Это как маленькие дети, которые хотят чтоб их убедили, чтоб им доказали, чтоб их опровергли или просто защищающие свои позиции, которые требуют внимания. Толку с ними разговаривать? Зачем на них тратить своё время? У них уже всё в голове построилось, ведь аноны с opennet им всё уже объяснили своё отношение к языку (который большинство из них не знает). Это их авторитеты.
Эти споры никуда кроме как к бамплимиту не приведут.
> Была бы альфа, можно было на это глаза еще закрыть.
Баги были, есть и будут всегда. И проблемы были, есть и будут всегда. Большинство багов может быть пофикшено как только в раст войдут большие мейнтейнеры. Но и появятся новые (при вводе новых фич) и что тогда? Опять визжать и кричать: "ну всё, нахуй этот раст"? Это не конструктивно.
Но я боюсь мои слова не будут поняты, я тут уже несколько раз объяснял свою позицию. В итоге это опять скатывалось к спору про unsafe и баги в каких-то либах или о том, что в команде раста есть инкзлюзивно повернутые. Поэтому просто легче пройти мимо и не реагировать на такое. Собака лает, караван идёт.
> unsafe везде, даже в стандартной либе
> такой растакой безопасный язык
Суть в том, что при написании конкретно твоей программы, ты без ансейфа не сможешь сделать сегфолт.
Если же всё таки сможешь, то это или КоляноCell в какой-то библиотеке, или растобаг и хорошо бы его зарепортить.
А если используешь всё таки ансейф, то уже ты сам ответственен за то, что происходит в этом блоке.
Умение говорить о недостатках инструмента - признак профессионализма.
Индустрия и так глупа и жрет одни только буллшиты. И вот и раст в буллшитах. И никто не парятся, белые списки переименовывают. У всех, манямир, всех все устраивает.
Нахер таких ваннаби-технарей.
Весь остальной твой текст, глупая демагогия. Таким как ты, видимо нравятся эти манямиры.
>Умение говорить о недостатках инструмента - признак профессионализма.
Я и говорю. Я принёс очень многие баги раста в тред и я перечислял в чем раст хуев.
>Индустрия и так глупа и жрет одни только буллшиты. И вот и раст в буллшитах. И никто не парятся, белые списки переименовывают. У всех, манямир, всех все устраивает.
>Весь остальной твой текст, глупая демагогия. Таким как ты, видимо нравятся эти манямиры.
>Нахер таких ваннаби-технарей.
Что я должен ответить на эти высеры? Это именно то о чем я и говорил выше. Ну не нравится - не юзай. Вот беда.
>не сможешь сделать сегфолт
Офигеть, если ты можешь писать такой код, в котором ты уверен что нет сегфолта. Нахер тебе вообще раст?
Может Коля был уверен в этом?
>В актиксе всё еще есть ансейфы
Так теперь у актрикса нет фатального недостатка и он принадлежит тем кто и устроил эту показательную порку?
Теперь все ансейфы правильные.
pub fn do_shit(data: u32)
и ты при помощи анcейфа сделал её мегабыстрой, но теперь она вызывает UB при data равном 0 (потому что делать проверку - слишком медленно лишнее ветвление замедлит код на сотую долю наносекунды, что недопустимо). В данном случае система типов не может гарантировать что дата не будет равен нулю, а значит есть шанс что юзер (а ведь функция публичная) таки случайно отправить туда нолик и получит неопределённое поведение. Вот такое использование ансейфа и не любят, когда ты не можешь гарантировать что при любых входных дынных в публиынх функциях твой ансейф код не будет вызывать UB.
В случае выше можно либо пометить функцию как небезопасную и указать, что проверять дату надо юзеру самому перед вызовом, если он не уверен, чито она не будет равна нулю, либо использовать систему типов и заменить входной параметр функции на
pub fn do_shit(data: NonZeroU32)
и всё станет безопасно, идиоматично и беспроблемно, однако сломается обратная совместимость, да.
И добавлю, конкретно коляноцелл был похож на эту функцию: при определённых входных параметрах в публичных апи его код генерировал UB. Ему предложили временно убрать ансейф-код, пока не будет исправлен публичный апи, чтоб не допускать нарушения инвариантов для той ансейф оптимизации. Но колян запустил истерику и в итоге случилось то, что случилось.
>растаманы
Ты сам походу какой-то растаман. Что за хуйню ты тут городишь?
Суть в том, что когда ты будешь писать программу, тебе придется пользоваться стандартной либой, библиотекой коляна, или другой, где есть ансейф. И не один, а соти. И тебе придется поверить на слово Коляна что он честно честно учел все пути кода. А мы уже видели что Колян не учел. Это не совсем то, что постулируется евангелистами языка.
Никто еще так пассивно не унижал сообщество фанатиков растафилов. Если на раст было более менее всем насрать, то Коля просто вскрыл загон шизиков и показал всему миру его истинное лицо.
Если до того дня мои знакомые макаки воспринимали раст как сетевую игру и где-то может краем уха слышали про затухший проект. То после этого события, раст стал воплощением всего упоротого зла попенсорса.
Стёб над unsafe рождает предубеждение о том, что это что-то плохое. Но если после этого человек погрузиться в потроха раста, он увидит тучу этого unsafe в стандартной либе и во всяких токио.
Это, конечно, порвет его шаблон.
Так что, расташизики, лучше об этом просто молчать, не все у вас там гладко.
Какое мне дело до unsafe в коде Коляна? Это опенсорс, сучка, я отвечаю только за свой код, и только если мы подписали контракт.