Это копия, сохраненная 24 февраля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Язык, позволяющий каждому создавать надёжное и эффективное программное обеспечение.
Обязательно для прочтения: https://doc.rust-lang.ru/book/
Вместо шапки: https://gist.github.com/TatriX/183c816f1346d418f969c4576c2b9b41
Ресурсы на русском: https://rust-lang.ru/
Предыдущий (лже-тред): >>1748459 (OP)
https://www.youtube.com/watch?v=lpOg2nl3kr0
>ПЕРЕВЕДУ СТРЕЛКИ НА КВЕЙК.
Мань, я с этого разговор с тобой начал. Ты написал "Уже рендер Q3 был красив, но морально устарел - в видеокартах начали появляться шейдеры и пошел спрос на попиксельное освещение". Спрос на попиксельное освещение в 1999 году. Охуенно. А остальное уже твои доебки до терминов, потому что ничего другого тебе не остается, кроме как пиздеть уже до конца и выдумывать на лету конфигурацию своей пеки, с купленной в 1998 AGP карточкой и неумением проапгрейдить процессор (зато с умением в бампмаппинг).
Ты просто тупой С++-дебил, небось ещё и негей. А он умный растобоярин и возможно любит под хвост. Уходи, гомофоб.
В нём зашито в синтаксисе 3.5 эффекта. Шах и мат!
А какие игры они сделали? Не обязательно на расте. Нашел только скрин из УЕ4.
Не просто ансейф-код, у них там оффициальный UB есть и они об этом знают:
https://doc.rust-lang.org/src/std/io/mod.rs.html#381
> // - This creates a (mut) reference to a slice of
> // _uninitialized_ integers, which is undefined behavior
> //
> // - Only the standard library gets to soundly "ignore" this,
> // based on its privileged knowledge of unstable rustc
> // internals;
А всё из-за говнотрейта Read, который рассчитан на использование только с инициализированным буфером (т.е. на выбор два стула - либо медленное чтение с предвалительным заполнением буфера нолями, либо быстрое но с UB). При том ВСЕ кто его используют с неинициализированным буфером (включая оффициальный код из библиотеки выше) по сути делают UB. И такого кода на самом деле очень дохуя.
Уже пытаются сделать мегакостыль, чтобы хоть как-то это говно исправить: https://github.com/rust-lang/rfcs/pull/2930
> с купленной в 1998 AGP карточкой
Прикинь, там даже на мамке даже USB порты были, 2 штуки. В 98 году, да. Компутахтор новый был, из магазина, бате тогда как раз за пару месяцев перед черным вторником бабос в конверте баксами дали, ну вот они с мамкой и купили пекарню для учебы. Потом я в силу своих финансовых возможностей проапгрейдил. Поскольку проц меня устраивал (менять на P2 когда уже вовсю анаонсировали 370 сокет чет шило на мыло, а на пень 3 вместе с матерью и видюхой денег не было) а видюха - нет, то все деньги ушли на GF256 и плашку на 32.
И да, вот такая у меня мать была:
Ухх красота.
4 пик умышленное вранье, все же видели что по бенчмаркам у Раста и плюсов паритет.
>4 пик умышленное вранье, все же видели что по бенчмаркам у Раста и плюсов паритет.
У крестов сейчас лучше оптимизон, чем у сей.
В чём вранью. На оси ординат не просто перформанс, а контроль делённый на перформанс. Т.е. чем перформанс выше, тем язык должен быть на этой оси ниже при одинаковом контроле. Чем выше язык, тем либо выше контроль, либо ниже перформанс, либо оба. Очевидно пик создавался поехавшими хаскеллоёбами.
Я вообще запостил это для демонстрации синтаксиса, но борроуинг и овнершип очень близкие концепты. Это слайд из какой-то лекции или вроде того.
Я знаю что они равны, ты угараешь что ли? На пике не равны.
Не знаю насчет ансейфов, но если нужен перформанс, то они кучу странной хуйни из библиотек достают. Может и ансейфы тоже.
Не так, но тоже можно. Поэтому тоже на свалку.
Соглы. Пофиксил, без маркетологового булшита уже не так радужно.
Ну я так думаю, что IO без ансейфов никак не сделать, ибо придётся в любом случае вызывать АПИ конкретной системы.
Значит остаются только хардварные имплементации языков без небезопасных операционных систем, небезопасного ассемблера и прочего говна.
Я вообще считаю, что все кто ненавидит раст - это на самом деле один человек, который умеет писать на куче языков и непрерывно поносит этот прекрасный язык по всему интернету.
7 > 1
Соглы. Пофиксил, без маркетологового булшита уже не так радужно.
Хуёво исправил. Вот окончательный вариант.
Всем похуй на твою версию правды. По нашей версии правды раст - самый быстрый и безопасный язык когда либо созданный в этой вселенной, а все кто не согласны - растофобы, расисты, нацисты и хуже гитлера. Вы просто ненавидите раст, потому что вы фашисты. Вся ваша суть существования - это ненависть ко всему вокруг.
Соглы. Пофиксил, без маркетологового булшита уже не так радужно.
> Какой же ахуенны тред, перекатили полтора часа как а уже на десятую часть заполнили, скоро так /зк/ до /б/ по продуктивности постинга выйдем, лол.
При том, что в треде всего 9 постеров.
>раст - самый быстрый и безопасный язык когда либо созданный в этой вселенной
Немного пафосно, но в целом верно.
>растофобы, расисты, нацисты и хуже гитлера. Вы просто ненавидите раст, потому что вы фашисты
Я думаю всё гораздо проще. Они просто тупые.
>Вся ваша суть существования - это ненависть ко всему вокруг.
А это прямо в точку, посмотреть хотя бы на царешиза.
>самый быстрый
Когда LLVM в state-of-art оптимизации gcc научится, тогда и приходите. Бенчмарки сейчас это битва говна и мочи, и можно легко подобрать ситуацию, в которой один язык с перевесом одолеет второй (даже если это Haskell против C).
А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит.
>безопасный
До пруверов и даже хацкеля ему очень далеко.
>До пруверов и даже хацкеля ему очень далеко.
Скорее пруверам и хачкелю до полезности раста далеко, лел.
>state-of-art оптимизации gcc
Такое вот "искусство" заканчивается ругающимся Торвальдсом если повезёт, а если нет — поломкой половины мира и последующими анальными граблями ещё на несколько лет.
>А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит.
Ну так ассемблер это даже и не язык программирования.
>Скорее пруверам и хачкелю до полезности раста далеко
Действительно, они сильно полезнее нуля.
>LLVM
В этом смысле Rust и C/C++ в одной лодке.
> в state-of-art оптимизации gcc научится
А причем тут gcc? Не уловил твою мысль. Хотя понимаю, что это просто подъёбка
>даже если это Haskell против C
А что не так с хаскелем? Их GHC хорош, пусть и чуток медленный в компиле.
>А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит.
Ассемблер это не язык. Даже если ты попробуешь взять какой-нибудь хорошо оптимизированный ассемблер под твою систему, то я сомневаюсь что у тебя получится сделать более быстрый код чем на том же Си или плюсах кроме хелоуворлда, безусловно. Оптимизаторы существуют не зря. И сравнивать языки ассемблеров с адекватными языками всерьёз это просто наивняк. Про какой-то там продакшн, поддержку, порог входа вообще можно промолчать.
Нет. Это ты перепутал а скорее всего и не знал. Можешь считать ассемблерные языки способом для представления машинных кодов в более-менее человеческом виде. Этих ассемблерных языков просто уйма, каждый со своими свистоперделками.
Ассемблер это программа, которая транслирует ассемблерный код в машинный. И самих этих ассемблеров тоже уйма.
C ходу: masm, nasm, fasm, zasm, tasm и т.д.
И каждый хуй может сделать свой, что собсна и делает.
>Действительно, они сильно полезнее нуля.
Чел, если у тебя это как-то состыкуется с гринтекстом который ты переиначиваешь — время лечится, у тебя в голове прувер поехал уже.
>>756931
Нет, чел, ассемблер это и есть представление этих машинных кодов. Даже всякие масмы/насмы у которые всякие йоба довесы вроде меток и текстовой подстановки есть язык не поворачивается так назвать.
>Даже всякие масмы/насмы у которые всякие йоба довесы вроде меток и текстовой подстановки есть язык не поворачивается так назвать.
Ты же просто не в теме, да?
С чем ты не согласен? С тем что примеры выражений на скрине - не язык? Но это язык. То что диалектов ассемблера много? Так и в Си/с++ много диалектов (не только стандартов, всякие Turbo C вспомнить), да и Раст чтобы собрать бутстрапом с нуля надо диалектов 8 минимум. С тем, что ассемблер - неоднозначное слово, означающее и язык, и инструмент? Так и в русском такие слова есть, например ПЕЧЬ - устройство в котором пекут, ПЕЧЬ - готовить в печи.
С тем, что ты показал не ассемблер, а какой-то язык с переменными и циклами. То, что он сделан поверх ассемблера — не значит что это ассемблер, такими ахуительными сравнениями можно всякие джавы до ассемблера опустить, ведь всё сделано над ним.
mov eax, gamma и jmp alpha это у тебя уже не ассемблер? Может у тебя и dd не ассемблер?
>>756954
Ассемблерный язык - ассемблерный только потому что может однозначно быть транслирован в машинный код и обратно. То, что ты привёл на картинке не может быть транслированно в машинный код однозначно. И тут тебе нужно сделать манёвр. Либо это всё равно ассемблерный язык (с какого то хера), либо это какой-то особый язык (это так и есть).
>ассемблер - неоднозначное слово
Ассемблер вполне однозначное слово. Это программа. Просто ты запутался. В английском это слово ещё более однозначное. Assembly language & Assembler.
>ПЕЧЬ - устройство в котором пекут, ПЕЧЬ - готовить в печи.
Плохой пример, потому что это две разные части речи. Существительное и глагол. Их невозможно перепутать в контексте.
Не совсем понимаю какую позицию ты хочешь отстоять. Что ассемблер - это язык? Ну так это просто фактически не так.
Ассемблерные языки - языки? Ну они конечно языки, полные по тьюрингу. Но какой смысл о них рассуждать? В этих диалектах, супер-макросах и древней документации чёрт ногу сломит. И быстрее всех они только в теории.
На практике, код написаный на ассемблере запросто может быть медленее, чем код написанный даже на плюсах и си.
https://habr.com/ru/post/254121/
пиздец зашел в комменты. Такая хуйня повторяется из раза в раз. И когда пытаешься объяснить этим зумерам, что у вас всё равно будет хуёвый, медленный код. Потому что перед компьютером сидит человек, а не робот-компилятор, то они начинают рассказывать про "руки из жопы". Та же хуйня с плюсодебилами и растом. Тычешь им в ~70% критов в популярном софте из-за проблем с памятью, а в ответ только копротивляния.
>Ассемблерный язык - ассемблерный только потому что может однозначно быть транслирован в машинный код и обратно. То, что ты привёл на картинке не может быть транслированно в машинный код однозначно. И тут тебе нужно сделать манёвр. Либо это всё равно ассемблерный язык (с какого то хера), либо это какой-то особый язык (это так и есть).
Как ты ловко скипнул примеры с диалектами раста. Может по твоему и Бейсик - не язык программирования? Ну а че ведь бейсик с одного компа не запустится на другом (а должен был?)
>Ассемблер вполне однозначное слово. Это программа.
Даже если так, только даун будет притворяться что не понимает о чем идет речь.
>В этих диалектах, супер-макросах и древней документации чёрт ногу сломит.
Будто бы в расте или крестах не так.
>На практике, код написаный на ассемблере запросто может быть медленее, чем код написанный даже на плюсах и си.
Пиши нормально.
Прости, а какая еще реакция может быть на людей у которых руки из жопы? Может быть называть их транс-ручными?
Транс-рукими.
>Как ты ловко скипнул примеры с диалектами раста
Скинь, я посмотрю.
>Может по твоему и Бейсик - не язык программирования?
Ты гринтекстишь быстрее чем читаешь? Причем тут бейсик? Или диалекты раста? Или диалекты си? К чему это?
>Даже если так, только даун будет притворяться что не понимает о чем идет речь.
Препод в универе постоянно поправлял, если кто-то называл ассемблерный язык - ассемблером. Это как называть код на языке си - компилятором си.
Но да, ты прав. Даже если ты понял о чём я - ты дальше будешь притворяться.
>Будто бы в расте или крестах не так.
В расте нет. В плюсах хуже, но тоже нет.
Пик. И вообще, что вы делаете со старыми карго которые не обновили? Просто выкидываете? Или придется в проект тащить несколько разных версий раста и таки разбираться в разных диалектах?
>Такое вот "искусство" заканчивается ругающимся Торвальдсом если повезёт
Я не говорил, что им стоит выбросить свой оптимизатор и взять его у gcc. Но разница в результатах на разных бенчмарках показывает, что их оптимизации - непересекающиеся множества.
Если коммьюнити хочет сделать LLVM действительно лучшим, им стоит перенять недостающие оптимизации.
>Ну так ассемблер это даже и не язык программирования.
>>756927
>Ассемблер это не язык.
Разве англоязычный термин assembly переводится не как "ассемблер"? Ну окей, язык ассемблера.
>А причем тут gcc? Не уловил твою мысль. Хотя понимаю, что это просто подъёбка
А я не уловил твою подъёбку. gcc = GNU Compiler Collection.
>А что не так с хаскелем?
Всё так, но ошибочно его часто считают медленным языком. Ну и в модные фишки вроде автовекторизации (SSE, AVX) GHC ещё не научился вроде бы.
Причем тут диалекты? На пике же изображена плюсовая фан. имплементации компилятора. clang, gcc, msvc это тоже разные "диалекты" Си?
>>757072
Что конкретно нужно? Rust неплохо расширяется внутри себя средствами самого раст. Так же есть список анстейбл фич, которые разрабатываются сейчас. Можно перейти на nightly ветку и попробовать.
Вот, аналог react/vue с JSX внутри самого Rust: https://github.com/yewstack/yew
>C
Который никому не нужен.
> JS
Rust и JS между собой не конфликтуют. JS - это скриптовый язык.
Создатель Node.js (где ядро написано на Си) Ryan Dahl сейчас работает над Deno. Это тоже рантайм для JavaScript/TypeScript, но уже он написан на Rust. Потому что Rust - это язык будущего.
https://deno.land/v1
>В последние годы языки программирования, такие как Rust и Go, значительно упростили создание сложного машинного кода; Эти проекты являются невероятно важными разработками в компьютерной инфраструктуре. Однако мы утверждаем, что по-прежнему важно иметь мощную среду сценариев, которая может решать широкий спектр проблемных областей.
В дено v8 никуда не делся. А Райн Дал просто хаупо дурачок. Он пять лет назад на го убежал с теми же криками. Всем поебать.
Ничего лучше js нет.
while (true) {}, if (huita || huita) и mask &= hui в джаве — это у тебя уже не C?
>Всё так, но ошибочно его часто считают медленным языком.
Потому что это медленный язык, по всем пунктам. И любой быстрый код на нём — это императивная параша с мутабельным стейтом и сырыми указателями.
Ну да, пытается сделать безопаснее хуитку которую юзает пол мира и которая зачастую торчит внаружу во весь интернет. Плюсодибилы as is.
Это какой-то хуевый аргмумент. Ты же с аноном говоришь.
Но и апеллирование к личности кого-либо (в том числе создателя) и его мировозрения - это не менее хуевый аргумент. Тебе, конечно, не понять.
>по всем пунктам
Но он не интерпретируемый, имеет статическую типизацию и компилируется в нативный код.
>И любой быстрый код на нём — это императивная параша с мутабельным стейтом
Если у тебя строчка для отключения ленивости - это императивная параша, тогда возможно. Так-то, конечно, придётся себя ограничивать в некоторых конструкциях языка, но в целом это всё равно выйдет в разы короче C. И да, там, где без стейта не обойтись - Haskell покажет себя плохо.
Т.е. обосновывать свою позицию тем, что кто-то просто дурачек (iq тесты провёл?) это нормально. Но как только говорят, что ты сам некомпетентый дурачек НУ ВСЕ ЖЕ МЫ ЛЮДИ НУ ЧЕГО ВЫ ОТКУДА ТЫ ЗНАЕШЬ ЯЖЕ АНОНИМ.
>апеллирование к личности кого-либо (в том числе создателя) и его мировозрения
Конечно, нельзя аппелировать к мнению изестных людей имеющих опыт в разработке прикладного ПО. Нужно слушать только хуесосов анонов с двачей. Ты когда дом строишь или хочешь себе зуб сделать - к бомжам у подъезда идёшь? Или к дворникам обращаешься?
>Тебе, конечно, не понять.
Конечно-конечно. Ведь это только ты читал, что нельзя ссылаться на авторитеты. Ты наверное это у какого-то авторитета прочитал?
>Но он не интерпретируемый, имеет статическую типизацию и компилируется в нативный код.
Но он имеет GC, нет контроля над памятью, почти нет контроля над тем, во что вообще развернётся твой код и не обосрётся ли компилятор при оптимизации твоей программы.
Можно конечно ебашить unsafeWithPtr через unsafePerformIO через unsafeWrite итд, но нахуя мне так ебаться? В прод я бы такой код точно ни за что не потащил, для себя бы так писать не стал (потому что это означает отказ от всех плюх хачкеля кроме синтаксиса, с которого можно угарать в наркотрипе), и если у тебя цель именно быстро ебать байтики но без излишнего геморроя — есть раст (внезапна).
>Если у тебя строчка для отключения ленивости - это императивная параша, тогда возможно.
Чел, ты же не живёшь в сферическом коне в вакууме. Вокруг тебя есть окружающий мир, и все библиотеки всегда пишутся по канонам языка, а не по тем изъёбствам которые ты себе напридумывал (какую нибудь либу на джаве дрочащую поинтеры или либу на обж-с без рефкаунтинга ещё надо хорошо поискать), я не думаю что хачкель настолько обособленно стоит тут ото всех.
>но в целом это всё равно выйдет в разы короче C
А зачем тебе вообще перформанс если у тебя мерило "короче чем на С"? Делай себе цепочки из мапов и молись на то, что компилятор их сфолдит а LLVM анрольнет, лол.
>И да, там, где без стейта не обойтись - Haskell покажет себя плохо.
Так стейт для того и существует, чтобы можно было делать быстро, странно вообще такое читать.
>Но он имеет GC, нет контроля над памятью
Это не обязательно делает язык медленным. Оптимизатор вообще может преаллоцировать память или сразу вернуть результат, подсчитанный на этапе компиляции.
>почти нет контроля над тем, во что вообще развернётся твой код и не обосрётся ли компилятор при оптимизации твоей программы.
Это особенность языков программирования в целом. Хочешь знать - пиши сразу на машинном коде.
>но нахуя мне так ебаться?
С этого и стоило начать. Haskell вообще для этого не предназначен.
>и если у тебя цель именно быстро ебать байтики но без излишнего геморроя
И тут начинается проблема определения слова "быстро", ведь почти всегда можно подобрать задачу, сделанную под особенности конкретного языка. Но даже под эту задачу можно написать на Rust алгоритм O(n), а на Haskell - O(2^n), и потом бегать доказывать, какой же Rust быстрый.
>А зачем тебе вообще перформанс
Так мне он и не нужен. Но вот только это не делает Haskell медленным.
Вообще - язык-полигон для перспективных математических фич без определённых задач. Т.к. начальное коммьюнити и основные концепты - математические, это привлекает и других людей, знакомых с матаном.
На деле можно писать однострочники, уделывающие по краткости многие другие языки. Зачастую, короче выйдет только на ныне почившем APL.
js лучше.
Сойдёт, но можно и получше.
>Язык точно норм?
Язык норм, но очень маленькое комьюнити (особенно русскоязычное). Постеры в треде имеют крайне смутное представление о расте, что критикующие, что защищающие. В треде уже >100 постов и только 15 постеров. Примерно такая же ситуация была и в предыдущем и ещё в других за ним.
Т.е. все эти срачи и всё что ты видишь - это пару анонов, что срутся с друг-другом. И это скорее грустно.
Ну для примера соседние треды можно взять. Где сообщений может быть в два-три раза больше чем сейчас здесь, но и постеров в 3-4 раза больше. Ну и качество совсем иное общения. Ну конечно не прям совсем, это всё таки двач, но хотя бы обсуждают язык и тему треда. У нас же в лучшем случае ансейфы обсуждают, а в худшем просто срутся.
Позапрошлый тред это вообще ахтунг. На 560 всего ~30 постеров. Т.е. ~20 постов на каждого. Понятно, что это просто срутся 4-5 человек. Я их уже даже по стилю письма начинаю отличать друг от друга.
Не конструктивно это как-то.
Действительно.
Гораздо лучше продолжать просто говниться ещё n^2-тредов, пока окончательно не проебёшь всё свободное полезное время. С такими амбициями можно и сразу на /b/ пройти.
Два человека уже не семёнство.
Ирл тебе тоже надо обязательно толпу собирать, чтобы пообщаться или уже в 2-4 человека нормально общается?
От судьбы не отвертишься, как говорится. Через 15 лет на Расте будет написан весь IoT, куча критических мест в ядрах ОС будут на него переписаны (винда и линукс уже внедряют раст), тысячи нормисов из инфосек индустрии потеряют работу, а на биржах эксплоитов цена оных поднимется с текущих 2-3 миллионов долларов до 20-25, потому что взлом будет настолько сложный, что будет удаваться это сделать только если звезды на небе определенным образом сойдутся.
Вперед, Раст!
>Через 15 лет на Расте будет написан весь IoT
Через 15 лет IoT будет писаться на жабаскрипте
Через 15 лет будет нормальный язык системного уровня, с нормальным синтаксисом, а эта отрыжка будет на помоечке. Ну да будет пара кусков которые сейчас успеют пропихнуть, как сейчас иногда встречаются ошметки перла.
С и С++ от А до Я unsafe, но все равно находятся дауны, которые считают эти языки нормальными. Чёт ору с даунят xD
Да, сижу ща пилю дрова на usb под линь на сишарпе, все так делают
А каковы масштабы этого? Я правильно понимаю что любая программа на Расте читающая что то из файлов или терминала автоматически UB? И все гарантии это "мамой клянусь у авторов стд есть понимание внутреннего устройства"
Ты понял что вообще сказал?
А кто себя рекламирует, как АНСЕЙФ?
Вдумайся еще раз в написанное.
Спроси любого челика, который работает в отрасли системной безопасности, он тебе скажет, что по-хорошему весь мир должен перестать писать на С/С++ (сам он в глубине души этого не хочет, ибо потеряет работу, если это произойдет, ну или придется ему перекатываться в другую область ИБ), потому что это дырявая блевотина из-под коня, а не языки. Дедовская отрыжка сорокалетней давности.
> у авторов стд
У них, у авторов ллвм, у авторов ос, у авторов цп и остального железа, у компьютер саентистов, у физиков итд.
Походу ты не ведаешь что в эмбедщине творится. Берут щепотку линуксового кода и наворачивают кучу кастомного говна, иногда откровенно проприетарного. РТОС тоже бывает много кастомных. ОСи не ограничиваются виндой на компьютере твоей бабки, анон.
По такому сценарию их и пишут на жс, в таком случае. См runtimejs
Открой CVE и посмотри что творится. 2к20 год на дворе, а проблемы с безопасностью как в 90ых, только сверху кучу митигаций навернули, чтобы усложнить, но не искоренить.
Каждый второй CVE с критическим CVSS - результат ошибок работы с памятью.
Нет никакого смысла продолжать цепляться за это говно, только легаси держит эти языки. Все, кто пишут новые проекты на сиплюсах, конченные ебанаты. Благо, много компаний это осознали и новые проекты на них стараются действительно не писать.
Сиплюсы были заебись потому, что не было альтернатив раньше. Да и сейчас они резко не подвинутся, тупо из-за огромной кучи вонючего легаси, но со временем это обязано произойти. Благо, все к этому идет, медленно, но уверенно.
> Я правильно понимаю что любая программа на Расте читающая что то из файлов или терминала автоматически UB?
Не любая. Конкретно в СТД UB находится только внутри BufReader. Если использовать трейт Read напрямую предварительно инициализировав массив нолями, то юб не будет. Но очень многие библиотеки ради скорости используют неинициализированные массивы (что логично - нахуя заполнять массив данными, которые моментально будут переписаны?) и автоматом получают UB.
>Через 15 лет на Расте будет написан весь IoT
>Походу ты не ведаешь что в эмбедщине творится
>Через 15 лет
>творится
Ты наркоман ебаный
Ахуеть. И где же были альтернативы, если их небыло? Ада, агла, паскаль, оберон, симула, алгол
Ты про что? Я говорю, что не сам трейт Read генерирует UB, а его пользователи при определённом паттерне использования (если ты не используешь BufReader, то кода с ним в твоём бинарнике не будет вообще как бы).
Стоит заметить, что в расте есть АПИ которые генерируют всегда UB при использовании, например [1] и на самом деле дохуя кода, который не мигрировал на MaybeUninit (либо используют MaybeUninit::uninit().assume_init(), что необходимо для трейта Read), в котором эту проблему решили.
[1]: https://doc.rust-lang.org/std/mem/fn.uninitialized.html
В первый же написанный для Хрома или операционки модудь Коляны воткнут ансейф, ну и чем тут поможет Раст?
Серьезно.
>Думал в расте адекватное сообщество
Почему ты так думал? Эксперементальные языки всегда привлекали в основном фриков и поехавших.
Js тоже эксперементальный язык, но там адекватное сообщество. И все очень образованные.
Хаскель вроде довольно быстр.
> Причем тут диалекты? На пике же изображена плюсовая фан. имплементации компилятора.
Ты тупой? Он собирает только первый шаг. Все дальнейшие версии собираются уже растом. Но растом разных версий. Т.е. в более ранних будет другой синтаксис.
Синтаксис одинаковый (синтаксис отличается только у 2018/2015 редакций, но компилятор поддерживает обе), разница только в АПИ внутри стандартной библиотеки. В расте всегда компилятор пишется так, чтобы собираться предыдущей версией (причём бывает так, что собирается предыдущей, но не может собрать сам себя, лол).
>Js
>Все очень образованные
Ты не мог становиться толще, и твой тип переменной yoba переполнился до нуля.
>Так мне он и не нужен.
Ну и как ты вообще оперируешь словом "быстрый" по отношению к языку, если ты на нём ничего требовательного к перформансу не писал?
>Это не обязательно делает язык медленным.
>Так мне он и не нужен. Но вот только это не делает Haskell медленным.
Давай-ка я тебе кину твой де тейк
>И тут начинается проблема определения слова "быстро"
для меня быстрый язык — это тот, с которым нужно меньше ебаться чтобы он работал быстро. Можно утрахаться и с джавой, чтобы инкрементить там указатели и компилировать АОТ, только вот я потрачу на это как минимум в 3 раза больше времени, чем просто ебануть этот же алгоритм на плюсах/расте.
Хаскель в плане ебли за перформанс — это вообще лидер, надо выкинуть почти всё что есть в языке, оставив из стдлибы только то, что интерфейстится к С или где имя импорта заканчивается на .Unsafe. Именно это и
>делает Haskell медленным.
там на самом деле много чего помимо unsafe функций
VSCode такая параша, идите нахуй
Gdb, сучка.
Открою тебе небольшой секрет - не бывает "медленных" компилируемых языков - бывают компиляторы, генерирующие субоптимальный набор машинного кода.
>если ты на нём ничего требовательного к перформансу не писал?
Предложи ещё на JS или другой динамикодрисне требовательное к перформансу писать. У меня есть сишечка, и если будут жёсткие ограничения по времени - я воспользуюсь ей, а не буду бегать по коду, плодя unsafe и говнокод.
>для меня быстрый язык — это тот, с которым нужно меньше ебаться чтобы он работал быстро
Haskell работает быстро, а быстрее можно почти всегда - пиши сразу на assembly/машкоде. Единственная нужная оптимизация там - это правильно расставить флаги и отключить ленивость в функциях, принимающих много данных.
>Хаскель в плане ебли за перформанс — это вообще лидер
На деле никто за перформанс там не борется, кроме полтора шизов на бенчмарках.
>Именно это и
>>делает Haskell медленным
Нет, не делает. Хороший компилятор мог бы сам провести все те оптимизации, которые ты предлагаешь делать ручками (кроме тех, которые являются оптимизациями алгоритмов).
Сможешь ли ты так же быстро найти опасные места в хромиуме/блинке?
> third_party
Ну и на скрине как раз правильно сделанный ансейв.
>Сможешь ли ты так же быстро найти опасные места в хромиуме
Покажи исходники на расте в хромиуме.
>в хромиуме
А что, разве Раст не в мозилле сделали?
> third_party
Так раст тянет все крейты с собой.
Да и какая разница, взломают браузер через компонент third party или какой то другой?
>Ну и на скрине как раз правильно сделанный ансейв.
Коляны одобряют.
> исходники на расте в хромиуме
Опасные места в с++ коде.
> какая разница
Есть разница.
> Коляны одобряют
Ты не сможешь без дополнительного ансейва заюзать этот трейт, а значит при коммите доебутся.
>Опасные места в с++ коде.
Причем тут с++? Покажи где раст в хроме. Я сходу не нашел.
>Есть разница.
Какая? Это то что притащил с собой раст.
Всё-таки раст - это фейл, но не потому что концепция плохая. Говорим про бороучекер, говорим про unsafe блок, всё нахуй, хомяки в панике ищут везде это ключевое слово, потому что боятся его как огня => у них в башке уже серьёзное непонимание, мол, зачем нужен раст, если там есть unsafe блоки. Не, фирмы туда точно не пойдут.
Если цель "продать и похуй", то возможно. А так вполне нормальное слово.
Ну не выходит одновременное скакание на хуйцах и рыбку съесть, тут или байты пердолить или ядро в соточку.
Ну они сами виноваты, добавили фактически ключевое слово ЗАШКВАР в язык и теперь получили закономерные АУЕ дилеммы в духе "как не зашквариться ходя на дальняк"
Есть цпп где по дефолту быстро и для безопасности натыкиваешь ассерты.
Есть руст где по дефолту безопасно и для скорости натыкиваешь ансейфы.
>Есть руст где по дефолту безопасно и для скорости натыкиваешь ансейфы.
Но, см >>757703
unsafe в среде сойбоев признано чем то вроде goto или singleton и если по масти писать на сях быстро тебе не запрещают, то по масти писать быстрые программы на расте это зашквар, пока зеон платинума хватает - не выебывайся.
Даже если бы там было please_be_gentle_with_me {}, то все равно бы были претензии.
Ты так говоришь как будто дело в слове, а не в том что оно убирает нахуй всю безопасность.
>Ты вообще в мане читал, что такое unsafe?
Ты читал, я читал, сойбой у которого раньше 32гб хватало на все а если что, ПМ клиента еще на тарифный план в облаке разведет - не читал, у него unsafe это ФУБЛЯДЬ ФУНАХУЙ КТО ЭТО СДЕЛАЛ ГДЕ ЭТОТ БАЙТОЕБ СУКА.
>Есть цпп где по дефолту быстро и для безопасности натыкиваешь ассерты.
>Есть руст где по дефолту быстро и для безопасности натыкиваешь ассерты
Вот валидный пост, а не то клоуничество.
А, то есть это дисфункциональный кейворд, типа как register в с++ и ничего не делает?
Это противоречивый кейворд в результате которого будут с одной стороны школотроны с их "МАМА СМАТРИ КАК Я КРУТО ХАКСОРЮ БАЙТЫ НА ИНТРИНСИКАХ AVX ИНСТРУКЦИЯХ ПОКА ТЕЧЕТ МОЙ ЛЮБИМЫЙ КЕПЧУК", с другой стороны будут сойбои с менторским тоном оттопырив мизинчик пояснять этим школотронам стоимость четырехголового зеона платинум по сравнению со стоимостю факапа по вине сегфолта, а то и кражи базы из-за одной AVX инструкции.
В итоге, вангую, галеры будут в кодстайлах ЗАПРЕЩАТЬ UNSAFE и на всех семинарах распинаться про какой же UNSAFE ФУУУУУ.
Вопрос не в том сколько я вижу или не вижу ассертов. Rust ~ C. Ты просто почему то думаешь, что Rust далеко ушёл от C в плане безопастности, но он ушёл от него ровно на столько, на сколько у тебя статически анализируема твоя программа, вернее, сделать определённые выводы из этого анализа - не больше, не меньше +/- возможности объяснить этому анализатору доп. параметры. По факту это улучшенный в некотором смысле всем известный C, хомяки просто подумали, что это ЕБАТЬ СЕЙФ, хотя тут нужно сказать, что его продали хомякам под этим лозунгом, возможно даже другие хомяки продали, что тащемта вина этих самых лгбт блм разработчиков.
>>757770
Есть эльф, который экспортит функцию, которая, допустим, вообще не изменяет ничего вне своего фрейма, я использую эту функцию, т.е. через ужасный unsafe - всё, пиздец, побежишь жаловаться на реддит?
Вижу, не вижу. Ушёл, не ушёл. Больше, не меньше. Плюс, минус. Хули ты как девочка 15 летняя?
Я не шучу.
Раст уже по скорости около с, уже имеет заебатый пакет менежер, при этом уже требуя в разы меньше ебли с памятью
Даже жаваскрипт быстрее и безопаснее раста, мань.
>жижа типа хаскеля и близко не подобралась хотя бы к определению практической реализации сейфовости
Хаскель - тоже ЯП общего назначения, и там тоже есть unsafe. Но на деле его используют только в бенчмарках.
Так-то есть ещё пруверы, в которых подорваться можно разве что на FFI (если он там есть).
На деле на сейфовость положили хуй и даже основные принципы её придерживания вынесли в отдельный экстеншон
Кроме раста не осталось ни одного языка хотя бы пытающегося в серьёзную сейфовость
Полегче на поворотах. Еще раз повторяю - покажи код на расте в Хроме. Если там ансейф на ансейфе - это самообоссывание.
Объясняю на пальцах.
Чел скинул пик, в котором нашел 3к ансейфов. По вашей версии это пиздец пиздецов, так? Ведь ансейф это опасно, уязвимо и пр.
Ему ответил анон
> Сможешь ли ты так же быстро найти опасные места в хромиуме/блинке?
Т.е. сможешь ли так же быстро и просто найти потенциально уязвимые и опасные места в коде на C++? Просто поиском по ключевым словам?
В ответ на это начались какие-то тупейшие манёвры, аля "покажи мне код на расте в хроме". О чем тут можно спорить, если вы элементарные тейки воспринять не в состоянии?
>Haskell работает быстро, а быстрее можно почти всегда - пиши сразу на assembly/машкоде.
Справедливо. Дальше спорить смысла нет. Ты поехавший.
Пчел, но маневрируешь только ты.
Я в третий раз прошу - покажите мне код на расте в Хром(иум)е. Ведь апологеты Раста в этом треде безустанно повторяют, что в браузерах огромная проблема с уязвимостями и поэтому туда непременно нужен безопасный раст, и еще эти апологеты утверждают что если нужен безопасный раст то не надо пользоваться unsafe. Но вот я открыл сорцы Мозиллы Файрфокс, т.е. продукта который делается авторами Раста, и там куча ансейфов (не 3к, конечно, это поиск по всем файлам в т.ч. документации, конфигам) После чего ты начинаешь маневрировать не видя противоречия заявленным свойствам языка.
Так выходит, что в коде на расте (по-твоему же примеру с фаерфоксом) все небезопасные места в коде, явно обозначены, верно?
У меня нет компа который потянет сборку хрома.
Если ансейф функцию с ненайденным уб юзает другая функция, ее третья, ее четвертая, то что будет?
>заявленным свойствам языка
Эти "заявленные свойства языка" только в твоей голове. Ты их сам выдумал и сам с ними воюешь.
>апологеты утверждают
Какие апологеты? Такие же долбоёбы из треда как и ты?
Ансейф опасен, так? Ты пошел в браузер мозиллы и нашел все ансейфы. Сможешь ли ты провернуть тоже самое для поиска опасных места хрома? Ты на этот вопрос до сих пор не смог ответить. И это я маневрирую? Ты видимо просто понял, что обосрался.
>что в браузерах огромная проблема с уязвимостями и поэтому туда непременно нужен безопасный раст
Не только в браузерах, вот Microsoft https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
Вот, кстати, репы от них же
https://github.com/microsoft/winrt-rs
https://github.com/microsoft/com-rs
Ты тупой нахуй или как? При аудите кода можно сосредоточить проверки на ансейф блоках, потому что вне них ты не можешь выстрелить себе в ногу. А имея четко ВИДИМЫЕ блоки кода, где потенциально может быть уязвимый код, все усилия тестеров устремляются туда. Засим и шанс выловить баг гораздо выше, нежели оставить все как есть.
У хрома примерно 80 миллионов строк кода (включая все-все-все). Грубо говоря, как думаешь, лучше чтобы 80 миллионов строк кода были ансейф или чтобы были 2-3к ансейф блоков, куда можно устремить все усилия для поиска возможных багов?
Полная безопасность в системщине нереально при данной архитектуре железа, но то, что раст делает системщину НАМНОГО безопаснее - факт. Он четко обозначает опасные места. В сиплюсах у тебя все от первой до последней строчки кода - один сплошной ансейф. Чисто по теории вероятности в такой кодовой базе будет больше багов.
>то что будет?
Будет поиск ошибки в дебаггере прямо как в плюсах. Только сужен он будет до области unsafe кода.
>пуксреньк ряяяя раст не может быть лучше сиплюсов ряяяя ансейф ррряяя
Плюсодебилов даже могила не исправит. Земля тебе сегфолтом.
Кроме маняфантазий про безопасный раст. Покажите безопасное приложение на расте масштаба хрома.
>Сколько жс-завистников в треде, мамочки. Так и не смогли осилить язык высокого уровня. Дебилы.
C++ — пик 1
Rust — пик 2
JS — пик 3
Рождённый ползать — летать не может.
К чему ты это спрашиваешь? Хочешь сказать, что в хроме их нет? Или что наличие cve обнуляет импакт от Rust?
Мне это напоминает мем про илона маска.
== ВЫ НАХОДИТЕСЬ ЗДЕСЬ ==
Когда на расте появится софт уровня хрома или какая-то часть хрома/винды/{аппнейм} будет переписана на него, то что ты будешь говорить? Или вы правда думаете, что это настолько нереалистичный сценарий? Ведь в ваших представлениях никто никогда не переписывает старый коммерческий код, да? А вероятность, что появится хоть какая-то серьёзная альтернатива плюсам или самому расту в ближайшие 5 лет - просто ничтожна, но к тому времени сам раст станет ещё популярней и больше.
Я всегда скриню самые лютые прогнозы про провал раста, чтобы лет через пяток показывать другим как прорывные технологии встречают сопротивление среди дураков и луддитов.
>Справедливо. Дальше спорить смысла нет
На Haskell 20% усилий на оптимизации (отключение ленивости, флаги, оптимизации алгоритмов) дадут 80% ускорения (от 100% теоретически возможных). Так-то почти все unsafe-функции небезопасны только для многопотока (т.к. в них нет мьютексов), а указатели оставлены больше как возможность, а не как пространство для оптимизаций.
А если ты берёшь хацкель (язык с GC!) для real-time приложений, то земля тебе пухом.
>Ты поехавший
Я не растосектант.
Когда появится большой софт на расте, им заинтересуются и будут ломать. И потом те кто кукарекали про безопасность будут молча сидеть в стыде.
>им заинтересуются и будут ломать
Безусловно. Только сколько будет стоить взломать такой софт ты конечно не уточняешь и уж тем более не уточняешь стоимость фикса.
Есть логические баги, от которых раст не спасает. Пока люди пишут код - инфосек будет жив.
Но есть целый класс багов, связанных с порчей памяти. Эта шняга сдохнет как только раст взойдет на пьедестал. Учитывая, что как раз баги с памятью чаще всего ведут к исполнению произвольного кода, и что 80% критических багов тоже относятся к этой категории, то выстрел раста уволит несколько сотен тысяч ИБшников по всему миру, которве занимаются лоу лвл безопасностью. Бедолаги уже от невроза наверное впопыхах учат жс и планируют перекат в веб инфосек, где все только начинается)
А что, если не сразу переписывать а постепенно то это как то удешивит тотал? Пиздец ты воробушек.
Рыночек вас и так бесплатно гроздьями вешает, лол, куда дешевле то.
Плохо, что в мелксофте не такие умники как ты сидят. Они то и не знали, что можно только модули на раст переписать потому что так дешевле, а не сразу всю винду.
>Как надо потратить N часов так и останется.
Пиздец у тебя с матешей туго. Ты думаешь переписать весь хром это столько же по времени как и переписать, например, какой-нибудь css-парсер?
Fust!
Rust!
Есть код, который и так приходится переписывать как в случае с тем же Фаерфоксом или писать с нуля.
У меня с матешей все отлично.
Переписать N модулей 1 человеком за M лет = Переписать N модулей M людьми за 1 год.
>РЯЯЯЯ, ГОВОРИШЬ НА МЕНЯ ПЕРЕВОДИШЬ НА СЕБЯ
А чего текстом, смишные макросы со стрелочкой в цвет дефолтной темы не нашел? И плачущих амудебичей еще не приволок, странно.
Я конечно не тот анон, что начал хуярить картиночки, а тот что написал что хачкель медленный, но не присоединиться к нему уже не могу.
Вопрос был:
>Ты думаешь переписать весь хром это столько же по времени как и переписать, например, какой-нибудь css-парсер?
Ты высрал:
>Переписать N модулей 1 человеком за M лет = Переписать N модулей M людьми за 1 год.
Чувствуешь разницу между одним модулем и всей аппой с n>1 модулями?
Ну и твои представления об этом — просто дикий наивняк. Это работает так только в голове зумера-долбоёба ни написавшего ни строчки кода. Если переписывание одного конкретного модуля может стоить 100k$, то переписывание 10 модулей программы может запросто обойтись в десятки миллионов, а всей программы в сотни миллионов долларов. Сложность/стоимость/время написания самих модулей может варьироваться и расчитывается оно нелинейно, не думаешь? Так же на цену переписывания влияет ситуация на рынке...Но это вообще забей, тебе до этого далеко.
Переписывание одного модуля вообще никак не повлияет на безопасность хрома (ну это если мы допустим, что на расте действительно переписали безопасно, а не через ансейфы, хехе). Хром станет безопасным только когда перепишут все модули. Поэтому растовикам и неприятно упоминать, что переписывание всего на раст обойдется в
>запросто обойтись в десятки миллионов, а всей программы в сотни миллионов долларов.
Скорее всего этого и не произойдет, ибо экономически это пиздец как невыгодно.
Но в будущем, при условии что раст выстрелит, гугл могут написать новый йоба-браузер и задепрекейтить хром. Хомячкам скармливать что-то новое в красивой оберточке - проще простого, особенно когда этим занимается такой гигант, как гугл.
Вот когда напишут, тогда и приходите.
Будет как-то так:
1. Эппл заебётся пилить своё поделие на устаревшем вебките
2. Форкать хром как-то слишком мейнстримно для них, форкнут ФФ - тем более, шта
а. родитель раста как раз в эппл пилит свифт
б. по части лгбт/блм продвинутости мозилла и раст сейчас ушли далеко вперёд, Эппл и тут надо будет догонять
3. Погрязший в уязвимостях Гугл форкнет эпплоподелие
получится повтор цикла
KHTML -> WebKIT -> Chrome, только вместо KHTML будет ФФ
На оп пик
Решил угареть по расту, пишу вот утилитку для себя по уцелевшим воспоминаниям раст бука.
По коду:
push должен имплементироваться страктом
header, footer могут имплементироваться страктом
body, content никогда не должны быть имплементированы для стракта
Создал трейт для того, чтобы раздавать его остальным структурам и не писать лишний код, но сука не знаю как сделать, чтобы работало body. Я понимаю, что видимо трейтами подобную задачу не решить, но может хоть дорогу верную подскажите. Писать бойлерплейт с fn body для каждой сущности (а их там штук 10 будет) совсем некрасиво выходит.
Трейт это просто набор методов которые можно вызвать. Поэтому "не должны быть имплементированы" лишено смысла.
В остальном я нихуя не понял, но похоже у тебя много очень похожих структур и может тебе просто поле с енумом добавить?
И точно ли нужен тебе этот трейт?
Может вообще все типы/структы переосмыслить?
Можно еще макросами попробовать.
>Можно еще макросами попробовать.
Я так понял это ещё больший геморрой.
>и может тебе просто поле с енумом добавить?
Можешь объяснить что имеешь ввиду? Я не совсем понял.
>Поэтому "не должны быть имплементированы" лишено смысла
Если не задавать определения для метода трейта без реализации, то компилер будет ругаться. А значит не лишено?
>В остальном я нихуя не понял, но похоже у тебя много очень похожих структур
Да. У меня куча (10+) "классов" с одинаковыми "свойствами", почти все они должны переопределять только один метод - push (логика в котором отличает их друг от друга). Но я не знаю как подобное реализовать на Rust. Гугл ответов не дал. Я не верю, что в расте такое нельзя провернуть, но как нагуглить точнее не знаю.
>Может вообще все типы/структы переосмыслить?
Единственное, что я придумал - просто сделать огромные функции. Но это дико уродливо.
У меня видимо ООП головного мозга, но я не понимаю как сделать это красивей и лаконичней в данном случае. Прошу помощи.
> для метода трейта без реализации
Это как раз наоборот, должны быть имплементированы.
> куча (10+) "классов" с одинаковыми "свойствами"
Нужны ли тебе эти 10 "классов"? Или лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push.
>лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push
Вот это современный и безопасный подход, браво.
И чем это лучше C со структурой, в которой есть указание типа и указатель на void?
>Или лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push.
Как это? C помощью match? Думаю получится как очень уж монструозно и уродливо. Или можно это как-то по другому обработать?
Можно в принципе вызывать функцию push для каждого, но проблема в том, что некоторые ещё могут переопределять методы header и footer.
>И чем это лучше C со структурой
А как бы ты подобное на си провернул? Там же даже до плюсов не было екстендов с методами, насколько я помню. Тебе бы такую же ебалу бы пришлось делать. Но при этом ещё и с возможностью словить ub при выходе за какую нибудь границу массива.
>Тебе бы такую же ебалу бы пришлось делать
Так в этом и проблема. Твой подход настолько же современ, насколько и подход ненавистных тебе сишников.
>А как бы ты подобное на си провернул?
Начнёт с того, что я бы в любом случае старался избегать подобных велосипедов, и взял бы другой язык - посахарнее, в котором подобное можно делать из коробки. Но если бы понадобилось - я бы воспользовался макросами или препроцессором для генерации логики, и добавил туда побольше assert'ов.
>Но при этом ещё и с возможностью словить ub при выходе за какую нибудь границу массива.
Хочешь сказать что в Rust, если ты читаешь указатель на тип a, когда там тип b - будет не тоже самое?
Суть токова, у меня есть код на другом языке. Там есть класс от и него наследуется 10 других классов, они переопределяют метод push, а некоторые ещё переопределяют методы header и footer. Очень всё аккуратно.
Я ради тренировки решил эту утилитку переписать на расте, но не понимаю как это сделать лаконичней средствами раста.
>>758922
>Твой подход настолько же современ, насколько и подход ненавистных тебе сишников
Какой мой подход? О чём ты?
>Но если бы понадобилось - я бы воспользовался макросами или препроцессором для генерации логики, и добавил туда побольше assert'ов
>Хочешь сказать что в Rust, если ты читаешь указатель на тип a, когда там тип b - будет не тоже самое?
Ты просто не понимаешь о чём говоришь. Абсолютно. Не вижу смысла тут о чём то рассуждать.
>Какой мой подход?
This:
>лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push.
Такой большой, а двачами пользоваться не научился. По твоему мнению это я сам себе отвечал?
>Такой большой, а двачами пользоваться не научился
Так самокритично. А теперь перечитай ещё раз ветку триолога. Если ты не он, то какого чёрта ты отвечал на посты, в которых я задавал вопросы ему?
>Если ты не он, то какого чёрта ты отвечал на посты, в которых я задавал вопросы ему?
Что я ещё должен не делать?
Вот реальное положение.
1. С++ // Популярная "рабочая лошадка" уже много лет.
2. Rust // Никому не нужно ржавое говно, но за то мог безопасно садиться на воду.
3. JS // Частный спортивный самолет, конечно, грузоподъемность не такая как у боинга, но за то на нём может научиться летать каждый.
747 как раз списывают в хлам, символично. А раст, это скорее эйрбас, который больше думает за пилота.
Большую ёбу от эйрбаса (A380) так-то тоже списывают. Авиаперевозки изменились, возить пачками в охулиард паксов через международные ёба-терминалы стало невыгодно.
И тем не менее, символичен именно выбор картинки, ведь что кресты, что 747 - оба подходят под определение
>Популярная "рабочая лошадка" уже много лет
и обоих потихоньку списывают на свалку.
Тащемта, либо пишешь имплементацию трейта для всех типов, либо занимаешься вот таким динамикомакакенгом https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=13d3baccaaeffff4868d46f529a3683a
можно с макросами
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=dcc77c1da1ea7d4b162b21451a232cee
а можно разобраться с proc_macro и запилить это в виде
#[derive(GenerateMneEtuHuituSuka)]
struct ...
>>758910
Тем, что это типобезопасно, с борроу чекером и куртизанками чел. Раст и есть C с навороченными типами. Отказ от всех подобных плюх — это именно продуманное решение, к которому приводит идеология explicit over implicit. Какое нибудь наследование и уж тем более интерфейсы, позволяющие регулировать поля — это вот нихуя не zero cost abstraction (первый тащит динамеческий диспатч с виртуальными таблицами и прочим, а второй это всё + ещё кучу метаинформации, с которой можно чуть ли не исходники восстанавливать как в джаве/шарпе/обжс).
Ты не объяснил нормально, что тебе нужно. Можешь сделать что-то такое:
struct {
body : Body
kind: Kind
}
enum kind {
A(i32)
B((i32,f32))
}
body обработаешь один раз, а более конкретные данные через матч.
>можно с макросами
Единственное что меня смущает. Неужели нет нормальных способов определить структуру, которая по полям полностью соответствует другой структуре или дополняет её обычным способом? Они просто обязаны запилить что-то подобное, я так щитаю.
Да и трейты, которые могут обращаться к свойствам очень бы не помешали.
Можно и внутри макроса создавать структуры, но если они не все одинаковые будут, то там начинается ебля с :tt, :item и скобочками. Проще отличающиеся руками запилить. Наследования в расте не было, нет и не будет, потому что наследование — антипаттерн из мира ООП; хочешь наследования — Python/C++ brr.
Трейты не могут обращаться к свойствам, потому что это тебе не методы. Если хочешь обращение к свойствам, то делаешь `trait GiveBody: ?Sized { fn give_body(&self) -> Cow<str>; }`, имплементишь для каждой своей структуры, а потом делаешь `fn body_shaker<T: GiveBody>(body_giver: &T) {}` или `trait BodyShaker: GiveBody {}` и уже можешь там везде использовать `body`.
>Да и трейты, которые могут обращаться к свойствам очень бы не помешали.
Я в том же сообщении писал чому их нет
>интерфейсы, позволяющие регулировать поля — это вот нихуя не zero cost abstraction (первый тащит динамеческий диспатч с виртуальными таблицами и прочим, а второй это всё + ещё кучу метаинформации, с которой можно чуть ли не исходники восстанавливать как в джаве/шарпе/обжс).
из вариантов — макачить на этих самых процедурных макросах в которых можно прям ручками писать в AST, но это тоже костыли не хуже уровня плюсовых SFINAE/итд. Но хоть появились не случайно, лол.
Если что, я говорю именно про proc-macro — https://doc.rust-lang.org/reference/procedural-macros.html
>Procedural macros are unhygienic. This means they behave as if the output token stream was simply written inline to the code it's next to. This means that it's affected by external items and also affects external imports.
Очередная прекрасная безопасная возможность языка :3
Говно если и вылезет, то при конпеляции.
Ты будешь думать что твой код делает одно. А кто то напишет функцию с именем от чего у тебя совсем другое наворотится. Прям в лучших традициях препроцессора Си
Например ты будешь думать что у тебя программа считает с двойной точностью, а она считает с одинарной.
`boilerspawn! { MyStruct, MyOtherStruct, … }`
Это если они прямо совсем идентичные. Если с маленькими изменениями, то там надо в кроличью нору :tt, :item и &()* заползать, но это я уже говорил.
А, кстати, можно делать несколько impl блоков на одну структуру. Так что если различий структурных нет, только методы отличаются, то после макроса делаешь
impl MyStruct {
fn kek() {}
}
impl MyOtherStruct {
fn lol() {}
}
даже если внутри макроса уже есть блоки `impl MyStruct` и `impl MyOtherStruct`.
Что? Там вместо f64 используется f32 (на что и указывает type_name). В макросе можно f64 сделать алиасом для любого типа и этот алиас будет действовать и за пределами макроса.
А нормальные примеры ты будешь потом ручками проверять, вслед за ансейфом, еще и все макросы, все использования макросов, и все использования имен использующихся в макросах.
Да, раст жалуется, что твой новый тип f64 не соответствует именованию типов принятому в растокоде (с большой буквы, КамелКэйс). Можно поставить #[allow(non_camel_case_types)] в макросе и варнинг уйдёт.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=b8d7eb3e6147bdc688a6247f23496f22
Баюс-баюс
>>759926
Ну а как по воему макросы должны работать в байтойобском языке? Написал такой макросик с ассемблером чтобы подхачить стек, переопределил всё что нужно, а компилятор такой — иди-ка ты нахуй, другалёчек, тут низя какать в AST? Это же Раст а не не хачилелиспы.
> Баюс-баюс
> 1234.9_f64
Ну да, а если убрать суффикс, то замены даже не заметишь, потому что у раста есть неявные преобразования у числовых литералов. Шикарный способ выстрелить себе в ногу.
> Неявные типы в литералах Rust, сделанные для удобства; фиксится добавлением типа к литералу.
> Неявные преобразования чисел (и булей) в C; не фиксится ничем.
Ваши присваивания не присваивания.
Шикарный, правда выдуманный на 120%.
>>759949
О, вы из 80-х? Нам тут в 2к20 линтеры завезли для такого, можно даже PR-ы автоматически заворачивать если там что-то не так.
>>760025
> This is a duplicate of the already fixed #73609
>It seems like this bug somehow slipped into beta :/
Это называется перестановочки в мозилле. Зато эффективные кобанчики денех с нон профит прожектов сэкономили))0
> It seems like this bug somehow slipped into beta :/
Он slipped не просто в бэту, а в релизную версию 1.45. И нашёл баг какой-то хуй из стэковерфлоу. Что смешно версия 1.45.1 даже ещё не вышла, а те кто по какой-то причине будут конпелировать на 1.45 получат потенциальные UB и без ансейфов с колянами.
Бля, а я думал он заорёт что-то вроде "f64 defined multiple times".
Если поставить в начале use core::f64;, то заорёт. Хуй их знает зачем они разрешили переопределять типы из prelude (т.е. типы автоматически импортирующиеся в каждой программе в расте).
Если будет баг в либах или самом расте.
Да. Нагадить могут компилятор, сгенерировав говно вместо кода (как в баге выше), крейты, апи стандартной библиотеки, которые могут иногда выдавать UB если не повезёт [1], операционная система, железо.
[1]: https://github.com/rust-lang/rust/issues/10389
Видимо с с беты ничего такого не нашли и выпустили, типичное дело. Тащемта, даже гуглы с эплами переодически пропускают вещи и более детские ошибки с их-то ебическими бюджетами и уровнями QA, вспомнить всякие экраны с пинами который можно обойти через камеру/нотификейшены или как фб месяц назад и ещё неделю назад ронял 3/4 приложений в мире из-за того, что у них в SDK не было проверок на nil.
>И нашёл баг какой-то хуй из стэковерфлоу
Ну так 80% багов всегда находят юзеры а не разработчики.
>>760073
Конечно, оно у тебя даже в какой нибудь джаве (или, проти господи, хачкеле) может вылезти.
>>760070
Скорее всего там вообще никаких проверок на эту тему и нет, т.к. не было кейса когда до такой хуйни неумышленно кто-то додумался.
> Скорее всего там вообще никаких проверок на эту тему и нет, т.к. не было кейса когда до такой хуйни неумышленно кто-то додумался.
В целом это сделано специально чтобы можно было добавлять новые элементы в prelude без поломки обратной совместимости. Но ведь можно было хотя бы элементарные типы запретить переопределять.
Хочу сам для себя для души попробовать Rust.
Но не хочу ограничиваться одной консолью, возникает вопрос, можно ли написать GUI или хотя бы работать с ВЕБ-ятиной без жопоебли? На сколько это реализовано для удобства программиста?
> можно ли написать GUI или хотя бы работать с ВЕБ-ятиной без жопоебли
Нет, и нет (если речь про фронтэнд). Всё сырое в альфа (или пре-альфа) состоянии. Если речь про бэкэнд, то можно попробовать. Сам балуюсь с graphql [1] на расте и выходит ничо так. Но всё равно сыровато.
[1]: https://github.com/async-graphql/async-graphql
>Конечно, оно у тебя даже в какой нибудь джаве (или, проти господи, хачкеле) может вылезти.
Не может. Только если это будет динамическая либа, написанная на небезопасных языках вроде С или С++, и там будет эдж кейс, который наебнет прогу, но не сам код на джаве/хачкеле
>можно ли написать GUI
Можно.
>работать с ВЕБ-ятиной без жопоебли?
Нельзя, только с поёбкой в сраку, причём если это бэк — то всё равно тормозить всё будет IO+база, а если фронт — ну просто земля тебе пухом.
>Но не хочу ограничиваться одной консолью
Ну так и не ограничивайся, тебя в этом не один язык не ограничит.
>На сколько это реализовано для удобства программиста?
На 0. Это язык дле ебли байтиков, с кучей анальных ограничений чтобы отлавливать максимальное кол-во косяков в компайлтайме.
Для удобства программиста есть языки вроде питона/руби/шарпа/свифта/котлина/итд.
>Хочу сам для себя для души попробовать Rust.
Чтобы попробовать его "для души" надо хотя бы пару лет поотлавливать сегфолты в каких нибудь плюсах, чтобы понимать почему раст сделан вот так и почему это лучше, иначе ты просто нихуя не поймёшь и забьёшь поборовшись с компилятором пару вечеров.
Ага, не может такого быть, как и утечек памяти которые даже на этих языках как-то появляются и всего остального.
А учитывая что та же жава сейчас выходит каждые пол года (а не как раньше раз в 10 лет, 9 из которых — это обкатка 1,5 новых "фич") и туда уже пихают почти всё, что есть в этих ваших модных языках — я бы на твоём месте свечку так не держал.
Утечка памяти это как бы не UB. В расте так вообще утечка считается абсолютно безопасной вещью и никак не возбраняется.
Мм, линтер с искусственным интеллектом? Он прямо все 30кк строк каждый раз проверит на предмет что твой коммит не изменит семантику какого то макроса?
Ну а что, все правильно. Зато так точно не будет use after free.
Мне кажется проблема скорее в этом, а не в макросах.
Вообще этот дроч на обратную совместимость по-моему везде больше проблем приносит, чем толку. Но у меня почти нихуя опыта в больших и долгих проектах.
>Утечка памяти это как бы не UB
А я сказал обратное?
>>760113
Чтобы проверить, все ли литералы написаны с явным типом он может, и для этого никакого интеллекта не нужно, хотя тебе твоего почему-то не хватило.
>>760114
А в чём предъява-то? Ну выпустили версию с багом и выпустили, ты в этом находишь какой-то сакральный смысл? Или у тебя в жс мире принято прыгать на новый релиз сразу после выхода, а не сидеть в проде на LTS?
>>760121
>обратную совместимость по-моему везде больше проблем приносит
Да не по твоему, оно так и есть по факту, причём оно так везде — и в промышленной области, где есть вот такое говно как плюсы/джава/кобол и ты будешь на нём писать потому что уже написаны хуйлионы строк, и в научной (где есть какая-то конъюнктура и тебя будут поливать говном а если ты ещё и не 0 в ней, то запишут в плоскоземельщики и предадут анафеме нахуй на неправильное мнение, например — если что-то пёрнешь про истерию с потеплением), и в социальной (совки и прочая ортодоксия), и везде.
В макросах эта проблема выражается в перенятом из плюсовских макросов namespace clash (что особенно весело если название модуля в области видимости макроса совпадает с названием крейта из которого макросу нужно взять пару типов).
>А в чём предъява-то?
В том что кто то возьмет язык потому что его разрекламировали как безопасный, а потом у него боинг упадет а ему такие - ну а чо, у фейсбука сайт тоже падал ))
>самолёты
>самая последняя версия компилятора))0
В жс-макакены уже берут даже неумеющих читать?
Бля, чел реально аутист. Ты прочитал что я тебе писал?
> >самая последняя версия компилятора))0
Ну вот и возьмут версию 1.45 вместо последней, лел. К тому же у раста ЛТС версий нет. Любая версия кроме последней - неподдерживаемая.
> Each Rust release is tested against all crates on crates.io - including running their tests - and none were affected.
А вот это мне понравилось. Даже и не знал.
Только вот тестируют на линуксе, а значит виндовсо- и мако- специфичный код в пролёте (ну и плюс вроде как тестируют только на x86_64).
А что если в коде который выполняет тесты баг и он не отлавливает ошибки?
Это из поста на реддите с обсуждением этого последнего бага. Как оно на самом деле устроено не изучал.
https://crater.rust-lang.org/ex/pr-74409
https://crater-reports.s3.amazonaws.com/beta-1.45-1/index.html выглядит так вроде
https://github.com/rust-lang/crater этим тестят
>можно ли написать GUI
>Нет
А чому нет? Если я не чужое собираюсь использовать, а писать с нуля своё, например.
Ты что то путаешь. Раст это язык специально для фронтенда веб макак.
Если только на винапи или winrt (современный аналог винапи начиная с виндовс 8 или 10). Только для них есть адекватные биндинги. Ну ещё немного гтк. Всё остальное в (пре-)альфа состоянии.
Чтобы можно было делать всякие штуки вроде
use InlinableString as String;
Иногда дефолтный выбор не является лучшим.
И сломать все вызовы функций со сторонних модулей, которые ожидают стринг, а не твоё говно? Это тебе не С++ хеадеры. Тут такая замена сработает только внутри одного файла.
Местный расист-кун был прав, лучше бы баги правили, а не ебались в жопы и неграм ботинки целовали.
Да.
>thread 'main' panicked at 'attempt to add with overflow
Почему это не проверяется на этапе компиляции? и как побороть кстати? я решил не терять интерес и не вникать в тонкости - сразу в бой, а тут такое и как дальше с этим быть непонятно
> Почему это не проверяется на этапе компиляции?
Возможно проверяется. Хороший оптимизатор вполне может выкинуть все вычисления и оставить в мейне только вызов паники.
Это переполняется arg: i32. Если поставить меньше циклов, то работает. А как это поправить, сделать проверку на размер i32? Это получается что у меня программа может упасть в неожиданных местах? Бред
Ну у тебя arg в функции slow постоянно увеличивается, так что паника будет либо в пятой, либо в седьмой строке. Либо где-то вместо плюса должен быть минус, либо вместо i32 нужно использовать i128 (или какой-нибудь BigInt, если и 128 бит не хватает).
> Это получается что у меня программа может упасть в неожиданных местах?
В релизной версии не упадёт, а выдаст мусор (там проверок на переполнение нет).
А тебе надо чтоб как было? В релизе оверфлов без паник будет. Так же есть методы овефловинг_мул, сатуратинг, чекед итд
Я тебе открою тайну - любой язык так сделает. В расте обещают только memory safety, а от логических ошибок компилятор не защитит.
> Почему это не проверяется на этапе компиляции?
Лол. Я хотел посоветовать ему использовать константные функции, но вместо этого нашёл баг в компиляторе, где раст иногда не проверят переменные на переполнение в константах.
>Ещё лучше. Что-то он мне перестал нравиться
Используй крейт для длинной арифметики, если не хватает четырех\восьми байт. Таки не Питон, за тебя это никто не сделает.
> четырех\восьми байт
В расте есть и 16-байтовые типы: i128/u128, но в его примере их тоже не хватит.
Нихуя. Это раст сам себе залил. Конкретно оптимизации в компиляторе, если два раза присваиваются константы.
Есть Типажи (Traits)
Я расписывать не будут и просто ставлю ссылку: https://ru.wikipedia.org/wiki/Контрактное_программирование
Нашёл такое https://crates.io/crates/contracts это оно? Если да, то нахуй не нужно, это ёбаный раст, ты бы ещё для сей такое предложил.
Я как бы не тот, кто спрашивал. А тот проект имеет последний коммит в 2016 году и реализован на ещё тогдашних костыльных макросах, которые в современном расте не работают.
Бомбишь тут только ты, растаман))
Все проекты на которые есть ссылки из википедии довольно мертвы, что немного намекает на нужность этих контрактов.
Чтобы при переполнении этот int равнялся int_max или -int_max, как вообще задетектить переполнение чтобы прога не упала? Это жизненно необходимо
>Чтобы при переполнении этот int равнялся int_max или -int_max
https://doc.rust-lang.org/std/primitive.i32.html#method.overflowing_add
> как вообще задетектить переполнение чтобы прога не упала?
https://doc.rust-lang.org/std/primitive.i32.html#method.checked_add
Нюфаги уже совсем ахуели, даже не пытаются гуглить.
Спасибо
Тебе возможно бигинт тут нужнее, а не проверки.
https://crates.io/crates/num-bigint или https://crates.io/crates/gmp
Он написал что ему надо. Чтобы при переполнении, был либо i32::MAX (в случае сложения) либо i32::MIN (в случае вычитания).
overflowing_add по сути аналогичен оператору +, только ещё возвращет булево значение которое указывает на переполнение и не паникует в дебаг-билдах.
Тогда saturating.
5 лет назад добавили, но никому не понадобилось.
Но это всё равно какой-то пиздец. Получается, я не могу гарантировать, что внешние данные всегда поместятся в такой промежуток чтобы прога не упала. Получается всегда надо их клампить
>>761893
Не, спасибо, это тестовый пример который я переписал из js. Проверяю, как работает асинк в жс если интересно асинк однопоточный, slow выполнится перед fast в любом случае
> Получается, я не могу гарантировать, что внешние данные всегда поместятся в такой промежуток чтобы прога не упала.
Это во всех яп так. Только в жс не 32 бита, а 52, лол.
> в жс если интересно асинк однопоточный, slow выполнится перед fast в любом случае
В расте поточность задаётся перед вызовом функции (либо при инициализации реактора, если используешь стандартный оператор await).
Ты не поверишь, но для этого придумали типы данных. Т.е. никто в здравом уме не работает с сырыми цифрами, если нужен диапазон. Более того, если ты просто клампаешь, тебе вообще пофиг на то что пользователь вводил выходит?
Если посмотреть на конпеляторы, то там наблюдается похожее: есть спеки жабы и пара реализаций, есть стандарт и куча реализаций сей/плюсов, у питона есть стандарт и всякие juthon/nuitka.
А у раста спеков + альтернативной реализации нет, только rfc и сразу код, нахуй. С одной стороны это плюс, так как снижает градус бюрократизма и ускоряет внедрение новых фич, а с другой - отпугивает крупных игроков, которым не хочется попадать в зависимость от того, какие гормоны сейчас пьёт кучка лгбт-шизиков.
Я хз, как решить эту проблему, не снижая скорости разработки, но как-то вот так. Ещё я боюсь, что с выкристаллизовыванием центрального комитета у раста может получиться как у питона, когда, например, бюрократы наверху придумали фичу "for/else", а обычные программеры сперва не поняли как ей пользоваться, а потом не поняли зачем.
Ошибка выжившего.
>Помните, почему выстрелил x86?
Потому что устройство IBM PC было практически не запатентованым и достаточно было сделать альтернативную реализацию биоса, что бы любой мог из имеющихся в магазинах деталек клепать клоны.
Так то и моторолла 68к выпускалась хуевой тучей производителей по всему миру.
Затем, за счет изысканий интела в микроархитектуре были похоронены RISC-архитектуры, кроме ARM, которая тоже вовремя включилась в изыскания по микроархитектурам.
>Потому что устройство IBM PC было практически не запатентованым и достаточно было сделать альтернативную реализацию биоса, что бы любой мог из имеющихся в магазинах деталек клепать клоны.
И да, если бы IBM запатентовал бы полностью свою пеку, а коммодор не запатентовал амигу - то история могла бы пойти по-другому, у амиги полноценный шиндовс с окнами и полноцветная графика со спрайтами и прочим 2д-ускорением вместо CGA еще в 83 году была.
Забей. Раст это хобби, которое работает только в файрфоксе или в качестве баловства используется в малочисленных проектах. Жто хобби превратится в инструмент версии 1.0 только лет через 30, и то при условии, что на его развитие на забьют как забили на какой нибудь руби.
Для того чтобы вознести сисярп ввысь из могилы достаточно было двух проектов - Xamarin и Unity3D.
Что это?
Сисярп не позиционировал себя как замену плюсам, а только как замену жабе, при этом развиваться он начал в 2000-х, когда самой жабе было 5 лет. Т. е. ты сравниваешь конкуренцию с 35+ летним языком (потому что плюсы это развитие сишки, а не проект с нуля), с конкуренцией с 5ти летним языком.
Ты меня не опроверг, в любом случае, спрос на PC был именно благодаря наличию альтернатив - не было боязни оказаться у разбитого корыта из-за того, что единственный производитель решил свернуть не туда. А уже альтернативы были благодаря открытости.
Раст же вроде бы и открыт, но пока не имеет ни альтернативных имплементаций, ни какого либо стандарта, на основе которого они могли бы появиться - во многом из-за высокой скорости выхода новых версий с новыми фичами, которые тут же начинают использоваться сторонними крейтами.
Вот, например, захочет Oracle выпустить Enterprise Rust версии 1.45, когда на дворе давно будет 1.50 - есть сейчас какой-то способ ограничить версии используемых крейтов, типа "версия 0.77 крейта foo не работает с этой версией раста, используйте 0.74", ну и автоматом брать не выше 0.74, если стоит ✡ ?
У крейта можно поставить минимальную версию. Убедить людей поддерживать старую версию компилятора - это вопрос работы с сообществом.
Что не так, сычуш? Первые стандарты C++ были мало отличимы по синиаксису от С, их трудно было различать. Твой раст изначально пилился шизиком на коленке и не имел общего синтаксиса с плюсами или сишкой
> поставить минимальную версию
В том и дело, что есть зависимость, зависимость зависимости, зависимость зависимости зависимости и так далее. Что-то уже использует фичи позднее 1.45, что-то нет. Нужно, чтобы ты просто пишешь foo = "✡", а cargo уже всё разрулил. Х.з., возможно эта проблема надуманная.
Но главная проблема - что разработкой раста рулит мозилла и кучка истеричных пидарасов, а крупные вендоры пока принюхиваются, но прямо не участвуют - она остаётся.
>>761929
Да, если подумать то в любом случае надо проверять данные. Если в релизе не падает от такого - то ок. Жалко что стак трейс не пишет.
А есть вариант, чтобы fast не ждала выполнения slow? Мне казалось, что синтаксис языка специально придуман чтобы самостоятельно разбивать на потоки, такое бывает вообще?)
> А есть вариант, чтобы fast не ждала выполнения slow? Мне казалось, что синтаксис языка специально придуман чтобы самостоятельно разбивать на потоки, такое бывает вообще?)
Ты не совсем понимаешь смысл асинхронщины. Асинхронные функции просто позволяют писать асинхронный код как синхронный. Проще говоря после каждого вызова await функция автоматом возвращает результат в самый верх рантайму (в твоём случае рантайм - это функция block_on) и тот ждёт когда результат доступен и продолжает выполнение функции с того момента где она остановилась. Вот и всё. Всё остальное делается только средствами самого рантайма.
Тогда slow не вызовется совсем. У раста асинхронные функции ленивые - при вызове они просто инициализируют память, а запускаются только при вызове await.
В твоём случае можно использовать join [1] - он одновременно запустит fast и slow. Как-то так:
use futures::join;
let (x: i32, y) = join!(slow(2), fast());
[1]: https://docs.rs/futures/0.3.5/futures/macro.join.html
Правда сам рантайм block_on однопоточный (он выполняется только в текущем потоке), так что разницы скорее всего не будет. Тебе нужен будет более крутой рантайм с несколькими потоками, например async-std или tokio.
1. Случайно у себя в фейсбуке/вк называешь пидарасов пидарасами, а нигеров нигерами.
2. Какой-то озорник находит твой гитхаб/линкдин и стучит куда надо.
3. Тебя вносят в специальный список тех, кому запрещено пользоваться растом. Т.е. дома-то ты сможешь им пользоваться, но захочешь написать приложение на расте - и тебя забанят в маркетах согласно лицензии.
4. Просыпаешься на лекции.
А причём тут раст? Берёшь зажигалку/спички и делаешь свой фаер и форгет.
>3. Тебя вносят в специальный список тех, кому запрещено пользоваться растом. Т.е. дома-то ты сможешь им пользоваться, но захочешь написать приложение на расте - и тебя забанят в маркетах согласно лицензии.
Ну так это не только раст ожидает но и отстальные отрасли. Свободное общество потребления закрывают, если ты еще не понял, будет полтора миллиардера - илитария, рабы и вот как раз небинарные вахтеры-вертухаи, с помощью которых илита будет править быдлорабами.
Никак, господин запретил, в футурах смысла быть не должно.
https://github.com/rust-lang/futures-rs/issues/121
планирую вкатится в rocket.rs, как он в плане вебсервисов? И как сам раст в плане вебсервисов, не зря учу именно его?
Рокет буквально в ближайшее время перекатывается на ветку 0.5, которая будет асинхронной и будет компилироваться на стейбл компайлере. Зависимость есть, брат жив.
Нищук порвался
Вот это подрыв, кек.
сколько нужно js-кода, чтобы прострелить рельсу?
на этом тред умер
А разве предупреждения нету? Трейт Future помечен как must-use, т.е. должно быть предупреждение от компилятора. Можно предупреждение превратить в ошибку поставив #![deny(unused_must_use)] в начало, но случайно обойти его будет просто например сделав.
let a = async_fun();
и забыв вызвать a.await (что в свою очередь сгенерирует другое предупреждение, что a не используется).
https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=7696fdf05d2ca7b3e2e3b86ea8609760
там скорее всего логические ошибки в коде, компилятор тупой он их ловить за погромиста не будет
Хром не ржавеет.
На расте есть runtime
Это постирония или в хачкеле ленивость вычислений святым духом обеспечивается?
Ты что, не слышал, что хаскель скоро перейдёт на As Static As Possible и вся ленивость будет на лайфтаймах из компайл-тайма?
Все верно. Не продаешь продукт (браузер) = не получаешь денег = борщ.
> ленивость вычислений
Программа не пишется, а сразу объявляется написанной. Фактическое формирование кода программы должно происходить при первом непосредственном обращении к ней, но поскольку никто не обращается, код тоже не формируется.
После прочтения про polysemy, мне он видится охуенной заменой джаве. Пишешь императивный код, все возможные эффекты описываешь в сигнатуре функций, нереально удобный мокинг для юнит тестов и тд.
>>757253
> Вообще - язык-полигон для перспективных математических фич без определённых задач. Т.к. начальное коммьюнити и основные концепты - математические, это привлекает и других людей, знакомых с матаном.
Для любителей мотематики есть кок, агда, идрис и куча других языков со своей теорией типов.
>После прочтения про polysemy, мне он видится охуенной заменой джаве.
никогда не будет, хуяк хуяк и в продакшен не получится.
хуяк хуяк и в продакшен это про ноду. А джава это AbstractSingletonBeanFactoryManager, что хаскель и способен заменить своей более крутой теорией типов.
Они есть, только мало, но ремоут в принципе может решить эту проблему.
Ну или как альтернатива - вырастить своих.
И нахуя тратить годы на то, чтобы вырастить челов которые могут съебнуть и надо инвестировать тонны нефти в других по новой?
Легче взять любую попсовую технологию и ебашить код прямо на проде, лол.
Ну что, аноны. Пик хипстерства настал, по-моему. Осталось на этом запустить рельсы и можно будет пересажиать раби-макак на раст, лул.
Чел, так это даже близко не FFI, это нахуй раби в расте, хоть для чего-то макросы хорошо зашли, лол.
А если баян — извините, я из танка видимо вылез.
>Легче взять любую попсовую технологию и ебашить код прямо на проде, лол.
Все так и делают:
Архитектура жава-приложения:
1. договариваемся к американской компанией, что сделаем софт за половину стоимости.
2. нанимаем сотни индусов русских студентов за ЖРАТ.
3. лепим невменяемое говно из жавовских опенсорсных быдлиотек, сдобренное говнокодом студентов под управлением виабушных акхикектогов.
4. слегка проябываем дедлан, поэтому в конце добиваем код хаками, лишь бы запустилось (тем более выясняется, что акхитектогы напроектировали неудобную и нерабочую хуйню, зато по умным книжкам, которых они начиталсь).
5. ????
6. Единоразовый PROFIT
7. Заклюючаем договора поддержки и сажаем на поддержку в 3 раза больше жавообезьян, чем было на разработке (оно и понятно, написать хуйню легко, а вот как потом её сопровождать?).
8. Дополнительный PROFIT в течение многих лет.
Оно везде так. ДЕЛАЕМ ХУЯК ХУЯК ОЙ Я ТУТ ВАМ НОВУЮ ФИЧУ ПРИНЁС ЗА 2 ДНЯ ДО РЕЛИЗА НУЖНА БЫЛА ВЧЕРА БЛЯ ПОЦАНЫ ДЕДЛАЙН ПРОЕБАЛИ А ХУЛИ ТАК ЛОГАЕТ СУКА А ЭТИ ДЕСЯТЬ ФИЧ ДОЛГО ДЕЛАТЬ? ДОЛГО? ЗНАЧИТ ВЫКАТЫВАЕМ ИХ ЗАВТРА
В смысле, ты че нахуй? А кто будет продолжать писать растокод в движке браузера?
Только не говори, что там оставят кресты
unsafe код != дырявый код. Возможно, там нет уязвимости, ибо разрабы и куа-макакены знали где нужно чекать интенсивнее.
Ты хоть примеры получше выбирай. А то у тебя одни комментарии и (фаззинг-)тесты в скриншоте.
Бля, чел, такое себе даже в лабах не позволяют.
Скорее всего уже никогда. Там кучу людей с работы выгнали, чтобы мозилловская СОЕ_эсса могла себе зарплату поднять, а то 2.5 миллиона слишком мало для приличного человека (хотя вангую что в 2019 году, отчёт по которому скоро выйдет, там будет уже за 3 миллиона).
Надеюсь, что это не так. Вот не большой лучик надежды
https://twitter.com/rustlang/status/1294024734804508679
Заглянул в их мини-список и увидел это: http://https://talentdirectory.mozilla.org
> Manish Goregaokar
Это тот чувак который так торопился замержить пулл-реквест с заменой блек-/вайт- листов в основную ветку, что несколько раз (лол) замержил ещё до ревью (так что пришлось откатить).
Как раз наоборот. Это (неполный) список пидорнутых от самой мозиллы. Не помогли ему ценности.
У них там главного топителя тоже уволили. Пикрил существо. Возможно в менеждеры пробрался гитлер.
Их гитлер — это, собственно, CEO, которой мало 2,5kk$.
Капиталист, классовый враг жи. Правда быть врагом с кем-то вне твиттора и тамблера внезапна бывает ниприятна.
Если ты вкатыш (а ты, очевидно, вкатыш) — иди в плюсы. Без этого не понять ни зачем нужен раст, ни найти работу.
не вкатыш, жавадебил
Увы, больно это говорить, но в плюсы.
Раст не факт, что взлетит, а если и взлетит, то подвинет плюсы в их сфере минимум через лет 15, а то и 20.
Но если тебе для души, а не для вката в индустрию, то раст вполне норм.
Из гугла был контрибьютор без права мержить пулл-реквесты в ветку. А этот в тот день именно мержами пулл-реквестов и занимался - у них там всё полу-автоматизировано.
>Manish Goregaokar
Посрал у обочины, подтёрся платьицем девчушки из низшей касты и вперёд, толерантные коммиты накатывать.
и че по зп?
спасибо
ок, а на остальные вопросы какой ответ?
А как же замена С и С++? Ведь раст лучше и современнее. Сейчас офк без шансов, но через 20 лет он будет доминировать, я думаю.
Хорош троллить, какие 40. 20 - потолок.
Вы утонули))
Все таки погнала мозила саными тряпками.
Так потолок в 500 постов пробили, надо новый тред делать. А всем лень.
На этот пик нужно добавить ещё и третье измерение, на котором будет отображена скорость разработки.
>>thread 'main' panicked at 'attempt to add with overflow
>и как дальше с этим быть непонятно
Ты наоборот должен радоваться, что у тебя задетектилось переполнение инта. Представь, чё было бы в сишечке. Ссылки по теме:
https://doc.rust-lang.org/std/primitive.u32.html#method.checked_add
https://doc.rust-lang.org/std/primitive.u32.html#method.saturating_add
https://doc.rust-lang.org/std/primitive.u32.html#method.wrapping_add
https://doc.rust-lang.org/std/primitive.u32.html#method.overflowing_add
У кого-то осталась фото рабочего стола которого постили в одном из тредов. Там был повернут вертикально монитор, мышка лоджитек вертикальная. Ламповая, но не могу найти. Скиньте пожалуйста у кого есть
Это копия, сохраненная 24 февраля 2021 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.