И так, что мы имеем, в предыдущей серии школотрон обосрался с шейдерами GeForce 3, украл мою зарплату за 3 месяца и запретил мне купить и вставить geForce 256 и 32 метра оперативы SDRAM.
>>1756678 → >ПЕРЕВЕДУ СТРЕЛКИ НА КВЕЙК. Мань, я с этого разговор с тобой начал. Ты написал "Уже рендер Q3 был красив, но морально устарел - в видеокартах начали появляться шейдеры и пошел спрос на попиксельное освещение". Спрос на попиксельное освещение в 1999 году. Охуенно. А остальное уже твои доебки до терминов, потому что ничего другого тебе не остается, кроме как пиздеть уже до конца и выдумывать на лету конфигурацию своей пеки, с купленной в 1998 AGP карточкой и неумением проапгрейдить процессор (зато с умением в бампмаппинг).
>>1756716 Не просто ансейф-код, у них там оффициальный 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. И такого кода на самом деле очень дохуя.
Прикинь, там даже на мамке даже USB порты были, 2 штуки. В 98 году, да. Компутахтор новый был, из магазина, бате тогда как раз за пару месяцев перед черным вторником бабос в конверте баксами дали, ну вот они с мамкой и купили пекарню для учебы. Потом я в силу своих финансовых возможностей проапгрейдил. Поскольку проц меня устраивал (менять на P2 когда уже вовсю анаонсировали 370 сокет чет шило на мыло, а на пень 3 вместе с матерью и видюхой денег не было) а видюха - нет, то все деньги ушли на GF256 и плашку на 32.
>>1756728 В чём вранью. На оси ординат не просто перформанс, а контроль делённый на перформанс. Т.е. чем перформанс выше, тем язык должен быть на этой оси ниже при одинаковом контроле. Чем выше язык, тем либо выше контроль, либо ниже перформанс, либо оба. Очевидно пик создавался поехавшими хаскеллоёбами.
>>1756703 Я вообще запостил это для демонстрации синтаксиса, но борроуинг и овнершип очень близкие концепты. Это слайд из какой-то лекции или вроде того.
Почему раст на ОП-пике безопасней жавы? Объясняйте. И да, утечки памяти в растомирке не являются чем-то плохим и есть куча безопасных способов их достичь. И кроме утечек я ничего плохого в жаве с точки зрения безопасности не знаю.
>>1756755 Я вообще считаю, что все кто ненавидит раст - это на самом деле один человек, который умеет писать на куче языков и непрерывно поносит этот прекрасный язык по всему интернету.
>>1756768 Всем похуй на твою версию правды. По нашей версии правды раст - самый быстрый и безопасный язык когда либо созданный в этой вселенной, а все кто не согласны - растофобы, расисты, нацисты и хуже гитлера. Вы просто ненавидите раст, потому что вы фашисты. Вся ваша суть существования - это ненависть ко всему вокруг.
>>1756780 > Какой же ахуенны тред, перекатили полтора часа как а уже на десятую часть заполнили, скоро так /зк/ до /б/ по продуктивности постинга выйдем, лол. При том, что в треде всего 9 постеров.
>>1756769 >самый быстрый Когда LLVM в state-of-art оптимизации gcc научится, тогда и приходите. Бенчмарки сейчас это битва говна и мочи, и можно легко подобрать ситуацию, в которой один язык с перевесом одолеет второй (даже если это Haskell против C).
А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит.
>безопасный До пруверов и даже хацкеля ему очень далеко.
>>1756902 >До пруверов и даже хацкеля ему очень далеко. Скорее пруверам и хачкелю до полезности раста далеко, лел.
>state-of-art оптимизации gcc Такое вот "искусство" заканчивается ругающимся Торвальдсом если повезёт, а если нет — поломкой половины мира и последующими анальными граблями ещё на несколько лет.
>А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит. Ну так ассемблер это даже и не язык программирования.
>>1756902 >LLVM В этом смысле Rust и C/C++ в одной лодке.
> в state-of-art оптимизации gcc научится А причем тут gcc? Не уловил твою мысль. Хотя понимаю, что это просто подъёбка
>даже если это Haskell против C А что не так с хаскелем? Их GHC хорош, пусть и чуток медленный в компиле.
>А самым быстрым он быть не может, т.к. ассемблер ничто не обгонит. Ассемблер это не язык. Даже если ты попробуешь взять какой-нибудь хорошо оптимизированный ассемблер под твою систему, то я сомневаюсь что у тебя получится сделать более быстрый код чем на том же Си или плюсах кроме хелоуворлда, безусловно. Оптимизаторы существуют не зря. И сравнивать языки ассемблеров с адекватными языками всерьёз это просто наивняк. Про какой-то там продакшн, поддержку, порог входа вообще можно промолчать.
>>1756931 Нет. Это ты перепутал а скорее всего и не знал. Можешь считать ассемблерные языки способом для представления машинных кодов в более-менее человеческом виде. Этих ассемблерных языков просто уйма, каждый со своими свистоперделками.
Ассемблер это программа, которая транслирует ассемблерный код в машинный. И самих этих ассемблеров тоже уйма. C ходу: masm, nasm, fasm, zasm, tasm и т.д. И каждый хуй может сделать свой, что собсна и делает.
>>1756926 >Действительно, они сильно полезнее нуля. Чел, если у тебя это как-то состыкуется с гринтекстом который ты переиначиваешь — время лечится, у тебя в голове прувер поехал уже.
>>1756931 Нет, чел, ассемблер это и есть представление этих машинных кодов. Даже всякие масмы/насмы у которые всякие йоба довесы вроде меток и текстовой подстановки есть язык не поворачивается так назвать.
>>1756936 >Даже всякие масмы/насмы у которые всякие йоба довесы вроде меток и текстовой подстановки есть язык не поворачивается так назвать. Ты же просто не в теме, да?
>>1756949 С чем ты не согласен? С тем что примеры выражений на скрине - не язык? Но это язык. То что диалектов ассемблера много? Так и в Си/с++ много диалектов (не только стандартов, всякие Turbo C вспомнить), да и Раст чтобы собрать бутстрапом с нуля надо диалектов 8 минимум. С тем, что ассемблер - неоднозначное слово, означающее и язык, и инструмент? Так и в русском такие слова есть, например ПЕЧЬ - устройство в котором пекут, ПЕЧЬ - готовить в печи.
>>1756954 С тем, что ты показал не ассемблер, а какой-то язык с переменными и циклами. То, что он сделан поверх ассемблера — не значит что это ассемблер, такими ахуительными сравнениями можно всякие джавы до ассемблера опустить, ведь всё сделано над ним.
>>1756945 >>1756954 Ассемблерный язык - ассемблерный только потому что может однозначно быть транслирован в машинный код и обратно. То, что ты привёл на картинке не может быть транслированно в машинный код однозначно. И тут тебе нужно сделать манёвр. Либо это всё равно ассемблерный язык (с какого то хера), либо это какой-то особый язык (это так и есть).
>ассемблер - неоднозначное слово Ассемблер вполне однозначное слово. Это программа. Просто ты запутался. В английском это слово ещё более однозначное. Assembly language & Assembler.
>ПЕЧЬ - устройство в котором пекут, ПЕЧЬ - готовить в печи. Плохой пример, потому что это две разные части речи. Существительное и глагол. Их невозможно перепутать в контексте.
Не совсем понимаю какую позицию ты хочешь отстоять. Что ассемблер - это язык? Ну так это просто фактически не так. Ассемблерные языки - языки? Ну они конечно языки, полные по тьюрингу. Но какой смысл о них рассуждать? В этих диалектах, супер-макросах и древней документации чёрт ногу сломит. И быстрее всех они только в теории.
На практике, код написаный на ассемблере запросто может быть медленее, чем код написанный даже на плюсах и си. https://habr.com/ru/post/254121/
>>1757042 >https://habr.com/ru/post/254121/ пиздец зашел в комменты. Такая хуйня повторяется из раза в раз. И когда пытаешься объяснить этим зумерам, что у вас всё равно будет хуёвый, медленный код. Потому что перед компьютером сидит человек, а не робот-компилятор, то они начинают рассказывать про "руки из жопы". Та же хуйня с плюсодебилами и растом. Тычешь им в ~70% критов в популярном софте из-за проблем с памятью, а в ответ только копротивляния.
>>1757042 >Ассемблерный язык - ассемблерный только потому что может однозначно быть транслирован в машинный код и обратно. То, что ты привёл на картинке не может быть транслированно в машинный код однозначно. И тут тебе нужно сделать манёвр. Либо это всё равно ассемблерный язык (с какого то хера), либо это какой-то особый язык (это так и есть). Как ты ловко скипнул примеры с диалектами раста. Может по твоему и Бейсик - не язык программирования? Ну а че ведь бейсик с одного компа не запустится на другом (а должен был?) >Ассемблер вполне однозначное слово. Это программа. Даже если так, только даун будет притворяться что не понимает о чем идет речь. >В этих диалектах, супер-макросах и древней документации чёрт ногу сломит. Будто бы в расте или крестах не так. >На практике, код написаный на ассемблере запросто может быть медленее, чем код написанный даже на плюсах и си. Пиши нормально.
>>1757050 >Как ты ловко скипнул примеры с диалектами раста Скинь, я посмотрю.
>Может по твоему и Бейсик - не язык программирования? Ты гринтекстишь быстрее чем читаешь? Причем тут бейсик? Или диалекты раста? Или диалекты си? К чему это?
>Даже если так, только даун будет притворяться что не понимает о чем идет речь. Препод в универе постоянно поправлял, если кто-то называл ассемблерный язык - ассемблером. Это как называть код на языке си - компилятором си.
Но да, ты прав. Даже если ты понял о чём я - ты дальше будешь притворяться.
>Будто бы в расте или крестах не так. В расте нет. В плюсах хуже, но тоже нет.
>>1757061 Пик. И вообще, что вы делаете со старыми карго которые не обновили? Просто выкидываете? Или придется в проект тащить несколько разных версий раста и таки разбираться в разных диалектах?
>>1756923 >Такое вот "искусство" заканчивается ругающимся Торвальдсом если повезёт Я не говорил, что им стоит выбросить свой оптимизатор и взять его у gcc. Но разница в результатах на разных бенчмарках показывает, что их оптимизации - непересекающиеся множества.
Если коммьюнити хочет сделать LLVM действительно лучшим, им стоит перенять недостающие оптимизации.
>Ну так ассемблер это даже и не язык программирования. >>1756927 >Ассемблер это не язык. Разве англоязычный термин assembly переводится не как "ассемблер"? Ну окей, язык ассемблера.
>А причем тут gcc? Не уловил твою мысль. Хотя понимаю, что это просто подъёбка А я не уловил твою подъёбку. gcc = GNU Compiler Collection.
>А что не так с хаскелем? Всё так, но ошибочно его часто считают медленным языком. Ну и в модные фишки вроде автовекторизации (SSE, AVX) GHC ещё не научился вроде бы.
>>1757068 Причем тут диалекты? На пике же изображена плюсовая фан. имплементации компилятора. clang, gcc, msvc это тоже разные "диалекты" Си?
>>1757072 Что конкретно нужно? Rust неплохо расширяется внутри себя средствами самого раст. Так же есть список анстейбл фич, которые разрабатываются сейчас. Можно перейти на nightly ветку и попробовать.
>>1757085 >>1757086 Сложно сказать, раст вроде не пилят вне раст блм-сообщества, но вообще там много "всякого" в унстабле, помимо странных маня-предложений, я помню, даже какой-то пидор хотел что-то похожее на эксэпшоны сделоть.
> JS Rust и JS между собой не конфликтуют. JS - это скриптовый язык.
Создатель Node.js (где ядро написано на Си) Ryan Dahl сейчас работает над Deno. Это тоже рантайм для JavaScript/TypeScript, но уже он написан на Rust. Потому что Rust - это язык будущего.
https://deno.land/v1 >В последние годы языки программирования, такие как Rust и Go, значительно упростили создание сложного машинного кода; Эти проекты являются невероятно важными разработками в компьютерной инфраструктуре. Однако мы утверждаем, что по-прежнему важно иметь мощную среду сценариев, которая может решать широкий спектр проблемных областей.
>>1757092 >Всё так, но ошибочно его часто считают медленным языком. Потому что это медленный язык, по всем пунктам. И любой быстрый код на нём — это императивная параша с мутабельным стейтом и сырыми указателями.
>>1757145 Это какой-то хуевый аргмумент. Ты же с аноном говоришь. Но и апеллирование к личности кого-либо (в том числе создателя) и его мировозрения - это не менее хуевый аргумент. Тебе, конечно, не понять.
>>1757165 >по всем пунктам Но он не интерпретируемый, имеет статическую типизацию и компилируется в нативный код.
>И любой быстрый код на нём — это императивная параша с мутабельным стейтом Если у тебя строчка для отключения ленивости - это императивная параша, тогда возможно. Так-то, конечно, придётся себя ограничивать в некоторых конструкциях языка, но в целом это всё равно выйдет в разы короче C. И да, там, где без стейта не обойтись - Haskell покажет себя плохо.
>>1757171 Т.е. обосновывать свою позицию тем, что кто-то просто дурачек (iq тесты провёл?) это нормально. Но как только говорят, что ты сам некомпетентый дурачек НУ ВСЕ ЖЕ МЫ ЛЮДИ НУ ЧЕГО ВЫ ОТКУДА ТЫ ЗНАЕШЬ ЯЖЕ АНОНИМ.
>апеллирование к личности кого-либо (в том числе создателя) и его мировозрения Конечно, нельзя аппелировать к мнению изестных людей имеющих опыт в разработке прикладного ПО. Нужно слушать только хуесосов анонов с двачей. Ты когда дом строишь или хочешь себе зуб сделать - к бомжам у подъезда идёшь? Или к дворникам обращаешься?
>Тебе, конечно, не понять. Конечно-конечно. Ведь это только ты читал, что нельзя ссылаться на авторитеты. Ты наверное это у какого-то авторитета прочитал?
>>1757177 >Но он не интерпретируемый, имеет статическую типизацию и компилируется в нативный код. Но он имеет GC, нет контроля над памятью, почти нет контроля над тем, во что вообще развернётся твой код и не обосрётся ли компилятор при оптимизации твоей программы.
Можно конечно ебашить unsafeWithPtr через unsafePerformIO через unsafeWrite итд, но нахуя мне так ебаться? В прод я бы такой код точно ни за что не потащил, для себя бы так писать не стал (потому что это означает отказ от всех плюх хачкеля кроме синтаксиса, с которого можно угарать в наркотрипе), и если у тебя цель именно быстро ебать байтики но без излишнего геморроя — есть раст (внезапна).
>Если у тебя строчка для отключения ленивости - это императивная параша, тогда возможно. Чел, ты же не живёшь в сферическом коне в вакууме. Вокруг тебя есть окружающий мир, и все библиотеки всегда пишутся по канонам языка, а не по тем изъёбствам которые ты себе напридумывал (какую нибудь либу на джаве дрочащую поинтеры или либу на обж-с без рефкаунтинга ещё надо хорошо поискать), я не думаю что хачкель настолько обособленно стоит тут ото всех.
>но в целом это всё равно выйдет в разы короче C А зачем тебе вообще перформанс если у тебя мерило "короче чем на С"? Делай себе цепочки из мапов и молись на то, что компилятор их сфолдит а LLVM анрольнет, лол.
>И да, там, где без стейта не обойтись - Haskell покажет себя плохо. Так стейт для того и существует, чтобы можно было делать быстро, странно вообще такое читать.
>>1757188 >Но он имеет GC, нет контроля над памятью Это не обязательно делает язык медленным. Оптимизатор вообще может преаллоцировать память или сразу вернуть результат, подсчитанный на этапе компиляции.
>почти нет контроля над тем, во что вообще развернётся твой код и не обосрётся ли компилятор при оптимизации твоей программы. Это особенность языков программирования в целом. Хочешь знать - пиши сразу на машинном коде.
>но нахуя мне так ебаться? С этого и стоило начать. Haskell вообще для этого не предназначен.
>и если у тебя цель именно быстро ебать байтики но без излишнего геморроя И тут начинается проблема определения слова "быстро", ведь почти всегда можно подобрать задачу, сделанную под особенности конкретного языка. Но даже под эту задачу можно написать на Rust алгоритм O(n), а на Haskell - O(2^n), и потом бегать доказывать, какой же Rust быстрый.
>А зачем тебе вообще перформанс Так мне он и не нужен. Но вот только это не делает Haskell медленным.
Сколько слежу за вашими тредами и еще не видел ни одного вопроса по языку, а только срачи c++ vs rust или если какой шиз, то сравнивают с js. Язык точно норм?
>>1757247 Вообще - язык-полигон для перспективных математических фич без определённых задач. Т.к. начальное коммьюнити и основные концепты - математические, это привлекает и других людей, знакомых с матаном.
На деле можно писать однострочники, уделывающие по краткости многие другие языки. Зачастую, короче выйдет только на ныне почившем APL.
>>1757251 >Язык точно норм? Язык норм, но очень маленькое комьюнити (особенно русскоязычное). Постеры в треде имеют крайне смутное представление о расте, что критикующие, что защищающие. В треде уже >100 постов и только 15 постеров. Примерно такая же ситуация была и в предыдущем и ещё в других за ним.
Т.е. все эти срачи и всё что ты видишь - это пару анонов, что срутся с друг-другом. И это скорее грустно.
>>1757302 Ну для примера соседние треды можно взять. Где сообщений может быть в два-три раза больше чем сейчас здесь, но и постеров в 3-4 раза больше. Ну и качество совсем иное общения. Ну конечно не прям совсем, это всё таки двач, но хотя бы обсуждают язык и тему треда. У нас же в лучшем случае ансейфы обсуждают, а в худшем просто срутся.
Позапрошлый тред это вообще ахтунг. На 560 всего ~30 постеров. Т.е. ~20 постов на каждого. Понятно, что это просто срутся 4-5 человек. Я их уже даже по стилю письма начинаю отличать друг от друга.
Гораздо лучше продолжать просто говниться ещё n^2-тредов, пока окончательно не проебёшь всё свободное полезное время. С такими амбициями можно и сразу на /b/ пройти.
Haters gonna hate :) От судьбы не отвертишься, как говорится. Через 15 лет на Расте будет написан весь IoT, куча критических мест в ядрах ОС будут на него переписаны (винда и линукс уже внедряют раст), тысячи нормисов из инфосек индустрии потеряют работу, а на биржах эксплоитов цена оных поднимется с текущих 2-3 миллионов долларов до 20-25, потому что взлом будет настолько сложный, что будет удаваться это сделать только если звезды на небе определенным образом сойдутся. Вперед, Раст!
>>1757330 Через 15 лет будет нормальный язык системного уровня, с нормальным синтаксисом, а эта отрыжка будет на помоечке. Ну да будет пара кусков которые сейчас успеют пропихнуть, как сейчас иногда встречаются ошметки перла.
>>1756719 А каковы масштабы этого? Я правильно понимаю что любая программа на Расте читающая что то из файлов или терминала автоматически UB? И все гарантии это "мамой клянусь у авторов стд есть понимание внутреннего устройства"
>>1757343 Ты понял что вообще сказал? А кто себя рекламирует, как АНСЕЙФ? Вдумайся еще раз в написанное.
Спроси любого челика, который работает в отрасли системной безопасности, он тебе скажет, что по-хорошему весь мир должен перестать писать на С/С++ (сам он в глубине души этого не хочет, ибо потеряет работу, если это произойдет, ну или придется ему перекатываться в другую область ИБ), потому что это дырявая блевотина из-под коня, а не языки. Дедовская отрыжка сорокалетней давности.
>>1757344 Походу ты не ведаешь что в эмбедщине творится. Берут щепотку линуксового кода и наворачивают кучу кастомного говна, иногда откровенно проприетарного. РТОС тоже бывает много кастомных. ОСи не ограничиваются виндой на компьютере твоей бабки, анон.
>>1757348 Открой CVE и посмотри что творится. 2к20 год на дворе, а проблемы с безопасностью как в 90ых, только сверху кучу митигаций навернули, чтобы усложнить, но не искоренить. Каждый второй CVE с критическим CVSS - результат ошибок работы с памятью. Нет никакого смысла продолжать цепляться за это говно, только легаси держит эти языки. Все, кто пишут новые проекты на сиплюсах, конченные ебанаты. Благо, много компаний это осознали и новые проекты на них стараются действительно не писать. Сиплюсы были заебись потому, что не было альтернатив раньше. Да и сейчас они резко не подвинутся, тупо из-за огромной кучи вонючего легаси, но со временем это обязано произойти. Благо, все к этому идет, медленно, но уверенно.
>>1757342 > Я правильно понимаю что любая программа на Расте читающая что то из файлов или терминала автоматически UB? Не любая. Конкретно в СТД UB находится только внутри BufReader. Если использовать трейт Read напрямую предварительно инициализировав массив нолями, то юб не будет. Но очень многие библиотеки ради скорости используют неинициализированные массивы (что логично - нахуя заполнять массив данными, которые моментально будут переписаны?) и автоматом получают UB.
>>1757369 Ты про что? Я говорю, что не сам трейт Read генерирует UB, а его пользователи при определённом паттерне использования (если ты не используешь BufReader, то кода с ним в твоём бинарнике не будет вообще как бы).
Стоит заметить, что в расте есть АПИ которые генерируют всегда UB при использовании, например [1] и на самом деле дохуя кода, который не мигрировал на MaybeUninit (либо используют MaybeUninit::uninit().assume_init(), что необходимо для трейта Read), в котором эту проблему решили.
>>1757098 > Причем тут диалекты? На пике же изображена плюсовая фан. имплементации компилятора. Ты тупой? Он собирает только первый шаг. Все дальнейшие версии собираются уже растом. Но растом разных версий. Т.е. в более ранних будет другой синтаксис.
>>1757427 Синтаксис одинаковый (синтаксис отличается только у 2018/2015 редакций, но компилятор поддерживает обе), разница только в АПИ внутри стандартной библиотеки. В расте всегда компилятор пишется так, чтобы собираться предыдущей версией (причём бывает так, что собирается предыдущей, но не может собрать сам себя, лол).
>>1757236 >Так мне он и не нужен. Ну и как ты вообще оперируешь словом "быстрый" по отношению к языку, если ты на нём ничего требовательного к перформансу не писал?
>Это не обязательно делает язык медленным. >Так мне он и не нужен. Но вот только это не делает Haskell медленным. Давай-ка я тебе кину твой де тейк >И тут начинается проблема определения слова "быстро" для меня быстрый язык — это тот, с которым нужно меньше ебаться чтобы он работал быстро. Можно утрахаться и с джавой, чтобы инкрементить там указатели и компилировать АОТ, только вот я потрачу на это как минимум в 3 раза больше времени, чем просто ебануть этот же алгоритм на плюсах/расте.
Хаскель в плане ебли за перформанс — это вообще лидер, надо выкинуть почти всё что есть в языке, оставив из стдлибы только то, что интерфейстится к С или где имя импорта заканчивается на .Unsafe. Именно это и >делает Haskell медленным.
>>1757502 Открою тебе небольшой секрет - не бывает "медленных" компилируемых языков - бывают компиляторы, генерирующие субоптимальный набор машинного кода.
>если ты на нём ничего требовательного к перформансу не писал? Предложи ещё на JS или другой динамикодрисне требовательное к перформансу писать. У меня есть сишечка, и если будут жёсткие ограничения по времени - я воспользуюсь ей, а не буду бегать по коду, плодя unsafe и говнокод.
>для меня быстрый язык — это тот, с которым нужно меньше ебаться чтобы он работал быстро Haskell работает быстро, а быстрее можно почти всегда - пиши сразу на assembly/машкоде. Единственная нужная оптимизация там - это правильно расставить флаги и отключить ленивость в функциях, принимающих много данных.
>Хаскель в плане ебли за перформанс — это вообще лидер На деле никто за перформанс там не борется, кроме полтора шизов на бенчмарках.
>Именно это и >>делает Haskell медленным Нет, не делает. Хороший компилятор мог бы сам провести все те оптимизации, которые ты предлагаешь делать ручками (кроме тех, которые являются оптимизациями алгоритмов).
>>1757582 >Сможешь ли ты так же быстро найти опасные места в хромиуме Покажи исходники на расте в хромиуме. >в хромиуме А что, разве Раст не в мозилле сделали? > third_party Так раст тянет все крейты с собой. Да и какая разница, взломают браузер через компонент third party или какой то другой? >Ну и на скрине как раз правильно сделанный ансейв. Коляны одобряют.
>>1757607 >Опасные места в с++ коде. Причем тут с++? Покажи где раст в хроме. Я сходу не нашел. >Есть разница. Какая? Это то что притащил с собой раст.
>>1757374 Всё-таки раст - это фейл, но не потому что концепция плохая. Говорим про бороучекер, говорим про unsafe блок, всё нахуй, хомяки в панике ищут везде это ключевое слово, потому что боятся его как огня => у них в башке уже серьёзное непонимание, мол, зачем нужен раст, если там есть unsafe блоки. Не, фирмы туда точно не пойдут.
Ну они сами виноваты, добавили фактически ключевое слово ЗАШКВАР в язык и теперь получили закономерные АУЕ дилеммы в духе "как не зашквариться ходя на дальняк"
>>1757697 Есть цпп где по дефолту быстро и для безопасности натыкиваешь ассерты. Есть руст где по дефолту безопасно и для скорости натыкиваешь ансейфы.
unsafe в среде сойбоев признано чем то вроде goto или singleton и если по масти писать на сях быстро тебе не запрещают, то по масти писать быстрые программы на расте это зашквар, пока зеон платинума хватает - не выебывайся.
>>1757697 >Ну не выходит одновременное скакание на хуйцах и рыбку съесть По факту суть не в этом, но хомяк бы понял это именно так. >>1757703 >добавили фактически ключевое слово Ты вообще в мане читал, что такое unsafe?
>>1757719 >Ты вообще в мане читал, что такое unsafe?
Ты читал, я читал, сойбой у которого раньше 32гб хватало на все а если что, ПМ клиента еще на тарифный план в облаке разведет - не читал, у него unsafe это ФУБЛЯДЬ ФУНАХУЙ КТО ЭТО СДЕЛАЛ ГДЕ ЭТОТ БАЙТОЕБ СУКА.
>>1757728 >Есть цпп где по дефолту быстро и для безопасности натыкиваешь ассерты. >Есть руст где по дефолту быстро и для безопасности натыкиваешь ассерты Вот валидный пост, а не то клоуничество.
Это противоречивый кейворд в результате которого будут с одной стороны школотроны с их "МАМА СМАТРИ КАК Я КРУТО ХАКСОРЮ БАЙТЫ НА ИНТРИНСИКАХ AVX ИНСТРУКЦИЯХ ПОКА ТЕЧЕТ МОЙ ЛЮБИМЫЙ КЕПЧУК", с другой стороны будут сойбои с менторским тоном оттопырив мизинчик пояснять этим школотронам стоимость четырехголового зеона платинум по сравнению со стоимостю факапа по вине сегфолта, а то и кражи базы из-за одной AVX инструкции.
>>1757764 Вопрос не в том сколько я вижу или не вижу ассертов. Rust ~ C. Ты просто почему то думаешь, что Rust далеко ушёл от C в плане безопастности, но он ушёл от него ровно на столько, на сколько у тебя статически анализируема твоя программа, вернее, сделать определённые выводы из этого анализа - не больше, не меньше +/- возможности объяснить этому анализатору доп. параметры. По факту это улучшенный в некотором смысле всем известный C, хомяки просто подумали, что это ЕБАТЬ СЕЙФ, хотя тут нужно сказать, что его продали хомякам под этим лозунгом, возможно даже другие хомяки продали, что тащемта вина этих самых лгбт блм разработчиков. >>1757770 Есть эльф, который экспортит функцию, которая, допустим, вообще не изменяет ничего вне своего фрейма, я использую эту функцию, т.е. через ужасный unsafe - всё, пиздец, побежишь жаловаться на реддит?
Даже анальная жижа типа хаскеля и близко не подобралась хотя бы к определению практической реализации сейфовости Раст уже по скорости около с, уже имеет заебатый пакет менежер, при этом уже требуя в разы меньше ебли с памятью
>>1757900 >жижа типа хаскеля и близко не подобралась хотя бы к определению практической реализации сейфовости Хаскель - тоже ЯП общего назначения, и там тоже есть unsafe. Но на деле его используют только в бенчмарках.
Так-то есть ещё пруверы, в которых подорваться можно разве что на FFI (если он там есть).
>>1757911 На деле на сейфовость положили хуй и даже основные принципы её придерживания вынесли в отдельный экстеншон Кроме раста не осталось ни одного языка хотя бы пытающегося в серьёзную сейфовость
>>1757607 >>1757598 >>1757626 Дурачек. Тебя спрашивают сможешь ли ты так же быстро найти unsafe в C++, где потенциально сидит ошибка? Хули ты дауном прикинулся?
Чел скинул пик, в котором нашел 3к ансейфов. По вашей версии это пиздец пиздецов, так? Ведь ансейф это опасно, уязвимо и пр. Ему ответил анон > Сможешь ли ты так же быстро найти опасные места в хромиуме/блинке?
Т.е. сможешь ли так же быстро и просто найти потенциально уязвимые и опасные места в коде на C++? Просто поиском по ключевым словам?
В ответ на это начались какие-то тупейшие манёвры, аля "покажи мне код на расте в хроме". О чем тут можно спорить, если вы элементарные тейки воспринять не в состоянии?
>>1757575 >Haskell работает быстро, а быстрее можно почти всегда - пиши сразу на assembly/машкоде. Справедливо. Дальше спорить смысла нет. Ты поехавший.
>>1757986 Пчел, но маневрируешь только ты. Я в третий раз прошу - покажите мне код на расте в Хром(иум)е. Ведь апологеты Раста в этом треде безустанно повторяют, что в браузерах огромная проблема с уязвимостями и поэтому туда непременно нужен безопасный раст, и еще эти апологеты утверждают что если нужен безопасный раст то не надо пользоваться unsafe. Но вот я открыл сорцы Мозиллы Файрфокс, т.е. продукта который делается авторами Раста, и там куча ансейфов (не 3к, конечно, это поиск по всем файлам в т.ч. документации, конфигам) После чего ты начинаешь маневрировать не видя противоречия заявленным свойствам языка.
>>1758020 >заявленным свойствам языка Эти "заявленные свойства языка" только в твоей голове. Ты их сам выдумал и сам с ними воюешь.
>апологеты утверждают Какие апологеты? Такие же долбоёбы из треда как и ты?
Ансейф опасен, так? Ты пошел в браузер мозиллы и нашел все ансейфы. Сможешь ли ты провернуть тоже самое для поиска опасных места хрома? Ты на этот вопрос до сих пор не смог ответить. И это я маневрирую? Ты видимо просто понял, что обосрался.
>>1758020 Ты тупой нахуй или как? При аудите кода можно сосредоточить проверки на ансейф блоках, потому что вне них ты не можешь выстрелить себе в ногу. А имея четко ВИДИМЫЕ блоки кода, где потенциально может быть уязвимый код, все усилия тестеров устремляются туда. Засим и шанс выловить баг гораздо выше, нежели оставить все как есть. У хрома примерно 80 миллионов строк кода (включая все-все-все). Грубо говоря, как думаешь, лучше чтобы 80 миллионов строк кода были ансейф или чтобы были 2-3к ансейф блоков, куда можно устремить все усилия для поиска возможных багов? Полная безопасность в системщине нереально при данной архитектуре железа, но то, что раст делает системщину НАМНОГО безопаснее - факт. Он четко обозначает опасные места. В сиплюсах у тебя все от первой до последней строчки кода - один сплошной ансейф. Чисто по теории вероятности в такой кодовой базе будет больше багов.
>>1758108 К чему ты это спрашиваешь? Хочешь сказать, что в хроме их нет? Или что наличие cve обнуляет импакт от Rust?
Мне это напоминает мем про илона маска.
== ВЫ НАХОДИТЕСЬ ЗДЕСЬ ==
Когда на расте появится софт уровня хрома или какая-то часть хрома/винды/{аппнейм} будет переписана на него, то что ты будешь говорить? Или вы правда думаете, что это настолько нереалистичный сценарий? Ведь в ваших представлениях никто никогда не переписывает старый коммерческий код, да? А вероятность, что появится хоть какая-то серьёзная альтернатива плюсам или самому расту в ближайшие 5 лет - просто ничтожна, но к тому времени сам раст станет ещё популярней и больше.
Я всегда скриню самые лютые прогнозы про провал раста, чтобы лет через пяток показывать другим как прорывные технологии встречают сопротивление среди дураков и луддитов.
>>1758015 >Справедливо. Дальше спорить смысла нет На Haskell 20% усилий на оптимизации (отключение ленивости, флаги, оптимизации алгоритмов) дадут 80% ускорения (от 100% теоретически возможных). Так-то почти все unsafe-функции небезопасны только для многопотока (т.к. в них нет мьютексов), а указатели оставлены больше как возможность, а не как пространство для оптимизаций.
А если ты берёшь хацкель (язык с GC!) для real-time приложений, то земля тебе пухом.
>>1758125 Когда появится большой софт на расте, им заинтересуются и будут ломать. И потом те кто кукарекали про безопасность будут молча сидеть в стыде.
>>1758137 >им заинтересуются и будут ломать Безусловно. Только сколько будет стоить взломать такой софт ты конечно не уточняешь и уж тем более не уточняешь стоимость фикса.
>>1758137 Есть логические баги, от которых раст не спасает. Пока люди пишут код - инфосек будет жив. Но есть целый класс багов, связанных с порчей памяти. Эта шняга сдохнет как только раст взойдет на пьедестал. Учитывая, что как раз баги с памятью чаще всего ведут к исполнению произвольного кода, и что 80% критических багов тоже относятся к этой категории, то выстрел раста уволит несколько сотен тысяч ИБшников по всему миру, которве занимаются лоу лвл безопасностью. Бедолаги уже от невроза наверное впопыхах учат жс и планируют перекат в веб инфосек, где все только начинается)
>>1758158 Плохо, что в мелксофте не такие умники как ты сидят. Они то и не знали, что можно только модули на раст переписать потому что так дешевле, а не сразу всю винду.
>>1758162 >Как надо потратить N часов так и останется. Пиздец у тебя с матешей туго. Ты думаешь переписать весь хром это столько же по времени как и переписать, например, какой-нибудь css-парсер?
>>1758476 Вопрос был: >Ты думаешь переписать весь хром это столько же по времени как и переписать, например, какой-нибудь css-парсер? Ты высрал: >Переписать N модулей 1 человеком за M лет = Переписать N модулей M людьми за 1 год. Чувствуешь разницу между одним модулем и всей аппой с n>1 модулями?
Ну и твои представления об этом — просто дикий наивняк. Это работает так только в голове зумера-долбоёба ни написавшего ни строчки кода. Если переписывание одного конкретного модуля может стоить 100k$, то переписывание 10 модулей программы может запросто обойтись в десятки миллионов, а всей программы в сотни миллионов долларов. Сложность/стоимость/время написания самих модулей может варьироваться и расчитывается оно нелинейно, не думаешь? Так же на цену переписывания влияет ситуация на рынке...Но это вообще забей, тебе до этого далеко.
>>1758524 Переписывание одного модуля вообще никак не повлияет на безопасность хрома (ну это если мы допустим, что на расте действительно переписали безопасно, а не через ансейфы, хехе). Хром станет безопасным только когда перепишут все модули. Поэтому растовикам и неприятно упоминать, что переписывание всего на раст обойдется в >запросто обойтись в десятки миллионов, а всей программы в сотни миллионов долларов.
>>1758535 Скорее всего этого и не произойдет, ибо экономически это пиздец как невыгодно. Но в будущем, при условии что раст выстрелит, гугл могут написать новый йоба-браузер и задепрекейтить хром. Хомячкам скармливать что-то новое в красивой оберточке - проще простого, особенно когда этим занимается такой гигант, как гугл.
>>1758539 Будет как-то так: 1. Эппл заебётся пилить своё поделие на устаревшем вебките 2. Форкать хром как-то слишком мейнстримно для них, форкнут ФФ - тем более, шта а. родитель раста как раз в эппл пилит свифт б. по части лгбт/блм продвинутости мозилла и раст сейчас ушли далеко вперёд, Эппл и тут надо будет догонять 3. Погрязший в уязвимостях Гугл форкнет эпплоподелие получится повтор цикла KHTML -> WebKIT -> Chrome, только вместо KHTML будет ФФ
Решил угареть по расту, пишу вот утилитку для себя по уцелевшим воспоминаниям раст бука.
По коду: push должен имплементироваться страктом header, footer могут имплементироваться страктом body, content никогда не должны быть имплементированы для стракта
Создал трейт для того, чтобы раздавать его остальным структурам и не писать лишний код, но сука не знаю как сделать, чтобы работало body. Я понимаю, что видимо трейтами подобную задачу не решить, но может хоть дорогу верную подскажите. Писать бойлерплейт с fn body для каждой сущности (а их там штук 10 будет) совсем некрасиво выходит.
>>1758842 Трейт это просто набор методов которые можно вызвать. Поэтому "не должны быть имплементированы" лишено смысла.
В остальном я нихуя не понял, но похоже у тебя много очень похожих структур и может тебе просто поле с енумом добавить? И точно ли нужен тебе этот трейт? Может вообще все типы/структы переосмыслить? Можно еще макросами попробовать.
>>1758891 >Можно еще макросами попробовать. Я так понял это ещё больший геморрой.
>и может тебе просто поле с енумом добавить? Можешь объяснить что имеешь ввиду? Я не совсем понял.
>Поэтому "не должны быть имплементированы" лишено смысла Если не задавать определения для метода трейта без реализации, то компилер будет ругаться. А значит не лишено?
>В остальном я нихуя не понял, но похоже у тебя много очень похожих структур Да. У меня куча (10+) "классов" с одинаковыми "свойствами", почти все они должны переопределять только один метод - push (логика в котором отличает их друг от друга). Но я не знаю как подобное реализовать на Rust. Гугл ответов не дал. Я не верю, что в расте такое нельзя провернуть, но как нагуглить точнее не знаю.
>Может вообще все типы/структы переосмыслить? Единственное, что я придумал - просто сделать огромные функции. Но это дико уродливо.
У меня видимо ООП головного мозга, но я не понимаю как сделать это красивей и лаконичней в данном случае. Прошу помощи.
>>1758893 > для метода трейта без реализации Это как раз наоборот, должны быть имплементированы.
> куча (10+) "классов" с одинаковыми "свойствами" Нужны ли тебе эти 10 "классов"? Или лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push.
>>1758904 >лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push Вот это современный и безопасный подход, браво.
И чем это лучше C со структурой, в которой есть указание типа и указатель на void?
>>1758904 >Или лучше оставить один, добавить поле kind и, в зависимости от того что там, делать разные вещи в push. Как это? C помощью match? Думаю получится как очень уж монструозно и уродливо. Или можно это как-то по другому обработать?
Можно в принципе вызывать функцию push для каждого, но проблема в том, что некоторые ещё могут переопределять методы header и footer.
>>1758910 >И чем это лучше C со структурой А как бы ты подобное на си провернул? Там же даже до плюсов не было екстендов с методами, насколько я помню. Тебе бы такую же ебалу бы пришлось делать. Но при этом ещё и с возможностью словить ub при выходе за какую нибудь границу массива.
>>1758915 >Тебе бы такую же ебалу бы пришлось делать Так в этом и проблема. Твой подход настолько же современ, насколько и подход ненавистных тебе сишников.
>А как бы ты подобное на си провернул? Начнёт с того, что я бы в любом случае старался избегать подобных велосипедов, и взял бы другой язык - посахарнее, в котором подобное можно делать из коробки. Но если бы понадобилось - я бы воспользовался макросами или препроцессором для генерации логики, и добавил туда побольше assert'ов.
>Но при этом ещё и с возможностью словить ub при выходе за какую нибудь границу массива. Хочешь сказать что в Rust, если ты читаешь указатель на тип a, когда там тип b - будет не тоже самое?
>>1758921 Суть токова, у меня есть код на другом языке. Там есть класс от и него наследуется 10 других классов, они переопределяют метод push, а некоторые ещё переопределяют методы header и footer. Очень всё аккуратно.
Я ради тренировки решил эту утилитку переписать на расте, но не понимаю как это сделать лаконичней средствами раста.
>>1758922 >Твой подход настолько же современ, насколько и подход ненавистных тебе сишников Какой мой подход? О чём ты?
>Но если бы понадобилось - я бы воспользовался макросами или препроцессором для генерации логики, и добавил туда побольше assert'ов >Хочешь сказать что в Rust, если ты читаешь указатель на тип a, когда там тип b - будет не тоже самое? Ты просто не понимаешь о чём говоришь. Абсолютно. Не вижу смысла тут о чём то рассуждать.
>>1758933 >Такой большой, а двачами пользоваться не научился Так самокритично. А теперь перечитай ещё раз ветку триолога. Если ты не он, то какого чёрта ты отвечал на посты, в которых я задавал вопросы ему?
Большую ёбу от эйрбаса (A380) так-то тоже списывают. Авиаперевозки изменились, возить пачками в охулиард паксов через международные ёба-терминалы стало невыгодно.
>>1759106 И тем не менее, символичен именно выбор картинки, ведь что кресты, что 747 - оба подходят под определение >Популярная "рабочая лошадка" уже много лет и обоих потихоньку списывают на свалку.
>>1758910 Тем, что это типобезопасно, с борроу чекером и куртизанками чел. Раст и есть C с навороченными типами. Отказ от всех подобных плюх — это именно продуманное решение, к которому приводит идеология explicit over implicit. Какое нибудь наследование и уж тем более интерфейсы, позволяющие регулировать поля — это вот нихуя не zero cost abstraction (первый тащит динамеческий диспатч с виртуальными таблицами и прочим, а второй это всё + ещё кучу метаинформации, с которой можно чуть ли не исходники восстанавливать как в джаве/шарпе/обжс).
>>1759123 >можно с макросами Единственное что меня смущает. Неужели нет нормальных способов определить структуру, которая по полям полностью соответствует другой структуре или дополняет её обычным способом? Они просто обязаны запилить что-то подобное, я так щитаю.
Да и трейты, которые могут обращаться к свойствам очень бы не помешали.
>>1759285 Можно и внутри макроса создавать структуры, но если они не все одинаковые будут, то там начинается ебля с :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`.
>>1759285 >Да и трейты, которые могут обращаться к свойствам очень бы не помешали. Я в том же сообщении писал чому их нет >интерфейсы, позволяющие регулировать поля — это вот нихуя не zero cost abstraction (первый тащит динамеческий диспатч с виртуальными таблицами и прочим, а второй это всё + ещё кучу метаинформации, с которой можно чуть ли не исходники восстанавливать как в джаве/шарпе/обжс). из вариантов — макачить на этих самых процедурных макросах в которых можно прям ручками писать в AST, но это тоже костыли не хуже уровня плюсовых SFINAE/итд. Но хоть появились не случайно, лол.
>>1759326 >>1759333 >>1759336 Спасибо. У меня просто ооп мозга. Понимаю, что плодить 10 одинаковых структур без наследования это мрак и дурной подход, но с трудом представляю как это сделать по другому. Буду пытаться ковырять по вашим примерам.
>>1759339 >без наследования это мрак и дурной подход Ну так сделай своё наследование, если так уж приспичило. Тебе ничего не мешает это сделать, но и также можешь сделать это, как анон >>1759336 говорит.
>>1759336 >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
>>1759564 Ты будешь думать что твой код делает одно. А кто то напишет функцию с именем от чего у тебя совсем другое наворотится. Прям в лучших традициях препроцессора Си
>>1759878 А, кстати, можно делать несколько impl блоков на одну структуру. Так что если различий структурных нет, только методы отличаются, то после макроса делаешь
>>1759918 Что? Там вместо f64 используется f32 (на что и указывает type_name). В макросе можно f64 сделать алиасом для любого типа и этот алиас будет действовать и за пределами макроса.
>>1759921 А нормальные примеры ты будешь потом ручками проверять, вслед за ансейфом, еще и все макросы, все использования макросов, и все использования имен использующихся в макросах.
>>1759926 Да, раст жалуется, что твой новый тип f64 не соответствует именованию типов принятому в растокоде (с большой буквы, КамелКэйс). Можно поставить #[allow(non_camel_case_types)] в макросе и варнинг уйдёт.
>>1759926 Ну а как по воему макросы должны работать в байтойобском языке? Написал такой макросик с ассемблером чтобы подхачить стек, переопределил всё что нужно, а компилятор такой — иди-ка ты нахуй, другалёчек, тут низя какать в AST? Это же Раст а не не хачилелиспы.
>>1759939 > Баюс-баюс > 1234.9_f64 Ну да, а если убрать суффикс, то замены даже не заметишь, потому что у раста есть неявные преобразования у числовых литералов. Шикарный способ выстрелить себе в ногу.
>>1759942 > Неявные типы в литералах Rust, сделанные для удобства; фиксится добавлением типа к литералу. > Неявные преобразования чисел (и булей) в C; не фиксится ничем.
>>1759949 О, вы из 80-х? Нам тут в 2к20 линтеры завезли для такого, можно даже PR-ы автоматически заворачивать если там что-то не так.
>>1760025 > This is a duplicate of the already fixed #73609 >It seems like this bug somehow slipped into beta :/ Это называется перестановочки в мозилле. Зато эффективные кобанчики денех с нон профит прожектов сэкономили))0
>>1760064 > It seems like this bug somehow slipped into beta :/ Он slipped не просто в бэту, а в релизную версию 1.45. И нашёл баг какой-то хуй из стэковерфлоу. Что смешно версия 1.45.1 даже ещё не вышла, а те кто по какой-то причине будут конпелировать на 1.45 получат потенциальные UB и без ансейфов с колянами.
>>1760068 Если поставить в начале use core::f64;, то заорёт. Хуй их знает зачем они разрешили переопределять типы из prelude (т.е. типы автоматически импортирующиеся в каждой программе в расте).
>>1760073 Да. Нагадить могут компилятор, сгенерировав говно вместо кода (как в баге выше), крейты, апи стандартной библиотеки, которые могут иногда выдавать UB если не повезёт [1], операционная система, железо.
>>1760066 Видимо с с беты ничего такого не нашли и выпустили, типичное дело. Тащемта, даже гуглы с эплами переодически пропускают вещи и более детские ошибки с их-то ебическими бюджетами и уровнями QA, вспомнить всякие экраны с пинами который можно обойти через камеру/нотификейшены или как фб месяц назад и ещё неделю назад ронял 3/4 приложений в мире из-за того, что у них в SDK не было проверок на nil. >И нашёл баг какой-то хуй из стэковерфлоу Ну так 80% багов всегда находят юзеры а не разработчики.
>>1760073 Конечно, оно у тебя даже в какой нибудь джаве (или, проти господи, хачкеле) может вылезти.
>>1760070 Скорее всего там вообще никаких проверок на эту тему и нет, т.к. не было кейса когда до такой хуйни неумышленно кто-то додумался.
>>1760082 > Скорее всего там вообще никаких проверок на эту тему и нет, т.к. не было кейса когда до такой хуйни неумышленно кто-то додумался. В целом это сделано специально чтобы можно было добавлять новые элементы в prelude без поломки обратной совместимости. Но ведь можно было хотя бы элементарные типы запретить переопределять.
Знаю основы C/C++/немного жабы, учусь в этом направлении. Хочу сам для себя для души попробовать Rust. Но не хочу ограничиваться одной консолью, возникает вопрос, можно ли написать GUI или хотя бы работать с ВЕБ-ятиной без жопоебли? На сколько это реализовано для удобства программиста?
>>1760094 > можно ли написать GUI или хотя бы работать с ВЕБ-ятиной без жопоебли Нет, и нет (если речь про фронтэнд). Всё сырое в альфа (или пре-альфа) состоянии. Если речь про бэкэнд, то можно попробовать. Сам балуюсь с graphql [1] на расте и выходит ничо так. Но всё равно сыровато.
>>1760082 >Конечно, оно у тебя даже в какой нибудь джаве (или, проти господи, хачкеле) может вылезти.
Не может. Только если это будет динамическая либа, написанная на небезопасных языках вроде С или С++, и там будет эдж кейс, который наебнет прогу, но не сам код на джаве/хачкеле
>работать с ВЕБ-ятиной без жопоебли? Нельзя, только с поёбкой в сраку, причём если это бэк — то всё равно тормозить всё будет IO+база, а если фронт — ну просто земля тебе пухом.
>Но не хочу ограничиваться одной консолью Ну так и не ограничивайся, тебя в этом не один язык не ограничит.
>На сколько это реализовано для удобства программиста? На 0. Это язык дле ебли байтиков, с кучей анальных ограничений чтобы отлавливать максимальное кол-во косяков в компайлтайме. Для удобства программиста есть языки вроде питона/руби/шарпа/свифта/котлина/итд.
>Хочу сам для себя для души попробовать Rust. Чтобы попробовать его "для души" надо хотя бы пару лет поотлавливать сегфолты в каких нибудь плюсах, чтобы понимать почему раст сделан вот так и почему это лучше, иначе ты просто нихуя не поймёшь и забьёшь поборовшись с компилятором пару вечеров.
>>1760099 Ага, не может такого быть, как и утечек памяти которые даже на этих языках как-то появляются и всего остального. А учитывая что та же жава сейчас выходит каждые пол года (а не как раньше раз в 10 лет, 9 из которых — это обкатка 1,5 новых "фич") и туда уже пихают почти всё, что есть в этих ваших модных языках — я бы на твоём месте свечку так не держал.
>>1760064 Мм, линтер с искусственным интеллектом? Он прямо все 30кк строк каждый раз проверит на предмет что твой коммит не изменит семантику какого то макроса?
>>1760106 >Утечка памяти это как бы не UB А я сказал обратное?
>>1760113 Чтобы проверить, все ли литералы написаны с явным типом он может, и для этого никакого интеллекта не нужно, хотя тебе твоего почему-то не хватило.
>>1760114 А в чём предъява-то? Ну выпустили версию с багом и выпустили, ты в этом находишь какой-то сакральный смысл? Или у тебя в жс мире принято прыгать на новый релиз сразу после выхода, а не сидеть в проде на LTS?
>>1760121 >обратную совместимость по-моему везде больше проблем приносит Да не по твоему, оно так и есть по факту, причём оно так везде — и в промышленной области, где есть вот такое говно как плюсы/джава/кобол и ты будешь на нём писать потому что уже написаны хуйлионы строк, и в научной (где есть какая-то конъюнктура и тебя будут поливать говном а если ты ещё и не 0 в ней, то запишут в плоскоземельщики и предадут анафеме нахуй на неправильное мнение, например — если что-то пёрнешь про истерию с потеплением), и в социальной (совки и прочая ортодоксия), и везде.
>>1760121 В макросах эта проблема выражается в перенятом из плюсовских макросов namespace clash (что особенно весело если название модуля в области видимости макроса совпадает с названием крейта из которого макросу нужно взять пару типов).
>>1760125 >А в чём предъява-то? В том что кто то возьмет язык потому что его разрекламировали как безопасный, а потом у него боинг упадет а ему такие - ну а чо, у фейсбука сайт тоже падал ))
>>1760151 > >самая последняя версия компилятора))0 Ну вот и возьмут версию 1.45 вместо последней, лел. К тому же у раста ЛТС версий нет. Любая версия кроме последней - неподдерживаемая.
> Each Rust release is tested against all crates on crates.io - including running their tests - and none were affected. А вот это мне понравилось. Даже и не знал.
>>1760237 Если только на винапи или winrt (современный аналог винапи начиная с виндовс 8 или 10). Только для них есть адекватные биндинги. Ну ещё немного гтк. Всё остальное в (пре-)альфа состоянии.
>>1761433 И сломать все вызовы функций со сторонних модулей, которые ожидают стринг, а не твоё говно? Это тебе не С++ хеадеры. Тут такая замена сработает только внутри одного файла.
>thread 'main' panicked at 'attempt to add with overflow Почему это не проверяется на этапе компиляции? и как побороть кстати? я решил не терять интерес и не вникать в тонкости - сразу в бой, а тут такое и как дальше с этим быть непонятно
>>1761493 > Почему это не проверяется на этапе компиляции? Возможно проверяется. Хороший оптимизатор вполне может выкинуть все вычисления и оставить в мейне только вызов паники.
>>1761496 Это переполняется arg: i32. Если поставить меньше циклов, то работает. А как это поправить, сделать проверку на размер i32? Это получается что у меня программа может упасть в неожиданных местах? Бред
>>1761496 Ну у тебя arg в функции slow постоянно увеличивается, так что паника будет либо в пятой, либо в седьмой строке. Либо где-то вместо плюса должен быть минус, либо вместо i32 нужно использовать i128 (или какой-нибудь BigInt, если и 128 бит не хватает).
>>1761497 > Это получается что у меня программа может упасть в неожиданных местах? В релизной версии не упадёт, а выдаст мусор (там проверок на переполнение нет).
>>1761493 > Почему это не проверяется на этапе компиляции? Лол. Я хотел посоветовать ему использовать константные функции, но вместо этого нашёл баг в компиляторе, где раст иногда не проверят переменные на переполнение в константах.
>>1761767 Я как бы не тот, кто спрашивал. А тот проект имеет последний коммит в 2016 году и реализован на ещё тогдашних костыльных макросах, которые в современном расте не работают.
>>1761874 Чтобы при переполнении этот int равнялся int_max или -int_max, как вообще задетектить переполнение чтобы прога не упала? Это жизненно необходимо
>>1761895 overflowing_add по сути аналогичен оператору +, только ещё возвращет булево значение которое указывает на переполнение и не паникует в дебаг-билдах.
>>1761886 Но это всё равно какой-то пиздец. Получается, я не могу гарантировать, что внешние данные всегда поместятся в такой промежуток чтобы прога не упала. Получается всегда надо их клампить
>>1761893 Не, спасибо, это тестовый пример который я переписал из js. Проверяю, как работает асинк в жс если интересно асинк однопоточный, slow выполнится перед fast в любом случае
>>1761918 > Получается, я не могу гарантировать, что внешние данные всегда поместятся в такой промежуток чтобы прога не упала. Это во всех яп так. Только в жс не 32 бита, а 52, лол. > в жс если интересно асинк однопоточный, slow выполнится перед fast в любом случае В расте поточность задаётся перед вызовом функции (либо при инициализации реактора, если используешь стандартный оператор await).
>>1761918 Ты не поверишь, но для этого придумали типы данных. Т.е. никто в здравом уме не работает с сырыми цифрами, если нужен диапазон. Более того, если ты просто клампаешь, тебе вообще пофиг на то что пользователь вводил выходит?
Аноны, я тут что подумал. Помните, почему выстрелил x86? Во многом потому, что почти сразу была альтернативная реализация, не было лочки на одного вендора. Есть некие спеки, набор команд, есть варианты этого дела в кремнии от 2-3 производителей. Если посмотреть на конпеляторы, то там наблюдается похожее: есть спеки жабы и пара реализаций, есть стандарт и куча реализаций сей/плюсов, у питона есть стандарт и всякие juthon/nuitka. А у раста спеков + альтернативной реализации нет, только rfc и сразу код, нахуй. С одной стороны это плюс, так как снижает градус бюрократизма и ускоряет внедрение новых фич, а с другой - отпугивает крупных игроков, которым не хочется попадать в зависимость от того, какие гормоны сейчас пьёт кучка лгбт-шизиков. Я хз, как решить эту проблему, не снижая скорости разработки, но как-то вот так. Ещё я боюсь, что с выкристаллизовыванием центрального комитета у раста может получиться как у питона, когда, например, бюрократы наверху придумали фичу "for/else", а обычные программеры сперва не поняли как ей пользоваться, а потом не поняли зачем.
Потому что устройство IBM PC было практически не запатентованым и достаточно было сделать альтернативную реализацию биоса, что бы любой мог из имеющихся в магазинах деталек клепать клоны.
Так то и моторолла 68к выпускалась хуевой тучей производителей по всему миру.
Затем, за счет изысканий интела в микроархитектуре были похоронены RISC-архитектуры, кроме ARM, которая тоже вовремя включилась в изыскания по микроархитектурам.
>Потому что устройство IBM PC было практически не запатентованым и достаточно было сделать альтернативную реализацию биоса, что бы любой мог из имеющихся в магазинах деталек клепать клоны.
И да, если бы IBM запатентовал бы полностью свою пеку, а коммодор не запатентовал амигу - то история могла бы пойти по-другому, у амиги полноценный шиндовс с окнами и полноцветная графика со спрайтами и прочим 2д-ускорением вместо CGA еще в 83 году была.
>>1762006 Забей. Раст это хобби, которое работает только в файрфоксе или в качестве баловства используется в малочисленных проектах. Жто хобби превратится в инструмент версии 1.0 только лет через 30, и то при условии, что на его развитие на забьют как забили на какой нибудь руби.
>>1762037 Сисярп не позиционировал себя как замену плюсам, а только как замену жабе, при этом развиваться он начал в 2000-х, когда самой жабе было 5 лет. Т. е. ты сравниваешь конкуренцию с 35+ летним языком (потому что плюсы это развитие сишки, а не проект с нуля), с конкуренцией с 5ти летним языком.
>>1762024 Ты меня не опроверг, в любом случае, спрос на PC был именно благодаря наличию альтернатив - не было боязни оказаться у разбитого корыта из-за того, что единственный производитель решил свернуть не туда. А уже альтернативы были благодаря открытости. Раст же вроде бы и открыт, но пока не имеет ни альтернативных имплементаций, ни какого либо стандарта, на основе которого они могли бы появиться - во многом из-за высокой скорости выхода новых версий с новыми фичами, которые тут же начинают использоваться сторонними крейтами. Вот, например, захочет Oracle выпустить Enterprise Rust версии 1.45, когда на дворе давно будет 1.50 - есть сейчас какой-то способ ограничить версии используемых крейтов, типа "версия 0.77 крейта foo не работает с этой версией раста, используйте 0.74", ну и автоматом брать не выше 0.74, если стоит ✡ ?
>>1762090 Что не так, сычуш? Первые стандарты C++ были мало отличимы по синиаксису от С, их трудно было различать. Твой раст изначально пилился шизиком на коленке и не имел общего синтаксиса с плюсами или сишкой
>>1762089 > поставить минимальную версию В том и дело, что есть зависимость, зависимость зависимости, зависимость зависимости зависимости и так далее. Что-то уже использует фичи позднее 1.45, что-то нет. Нужно, чтобы ты просто пишешь foo = "✡", а cargo уже всё разрулил. Х.з., возможно эта проблема надуманная. Но главная проблема - что разработкой раста рулит мозилла и кучка истеричных пидарасов, а крупные вендоры пока принюхиваются, но прямо не участвуют - она остаётся.
>>1761924 >>1761929 Да, если подумать то в любом случае надо проверять данные. Если в релизе не падает от такого - то ок. Жалко что стак трейс не пишет.
А есть вариант, чтобы fast не ждала выполнения slow? Мне казалось, что синтаксис языка специально придуман чтобы самостоятельно разбивать на потоки, такое бывает вообще?)
>>1762104 > А есть вариант, чтобы fast не ждала выполнения slow? Мне казалось, что синтаксис языка специально придуман чтобы самостоятельно разбивать на потоки, такое бывает вообще?) Ты не совсем понимаешь смысл асинхронщины. Асинхронные функции просто позволяют писать асинхронный код как синхронный. Проще говоря после каждого вызова await функция автоматом возвращает результат в самый верх рантайму (в твоём случае рантайм - это функция block_on) и тот ждёт когда результат доступен и продолжает выполнение функции с того момента где она остановилась. Вот и всё. Всё остальное делается только средствами самого рантайма.
>>1762105 Тогда slow не вызовется совсем. У раста асинхронные функции ленивые - при вызове они просто инициализируют память, а запускаются только при вызове await.
>>1762108 Правда сам рантайм block_on однопоточный (он выполняется только в текущем потоке), так что разницы скорее всего не будет. Тебе нужен будет более крутой рантайм с несколькими потоками, например async-std или tokio.
>>1762099 1. Случайно у себя в фейсбуке/вк называешь пидарасов пидарасами, а нигеров нигерами. 2. Какой-то озорник находит твой гитхаб/линкдин и стучит куда надо. 3. Тебя вносят в специальный список тех, кому запрещено пользоваться растом. Т.е. дома-то ты сможешь им пользоваться, но захочешь написать приложение на расте - и тебя забанят в маркетах согласно лицензии.
>>1762113 >3. Тебя вносят в специальный список тех, кому запрещено пользоваться растом. Т.е. дома-то ты сможешь им пользоваться, но захочешь написать приложение на расте - и тебя забанят в маркетах согласно лицензии.
Ну так это не только раст ожидает но и отстальные отрасли. Свободное общество потребления закрывают, если ты еще не понял, будет полтора миллиардера - илитария, рабы и вот как раз небинарные вахтеры-вертухаи, с помощью которых илита будет править быдлорабами.
>>1762166 Рокет буквально в ближайшее время перекатывается на ветку 0.5, которая будет асинхронной и будет компилироваться на стейбл компайлере. Зависимость есть, брат жив.
Аноны, такое дело: перевёл часть проекта на асинхронщину, функций и вызовов там дохуя - нашёл уже 2 места, где забыл добавить await. Как бы сделать так, чтобы код не конпелировался, если обнаруживаются такие вот висящие вызовы?
>>1769668 А разве предупреждения нету? Трейт Future помечен как must-use, т.е. должно быть предупреждение от компилятора. Можно предупреждение превратить в ошибку поставив #![deny(unused_must_use)] в начало, но случайно обойти его будет просто например сделав.
let a = async_fun();
и забыв вызвать a.await (что в свою очередь сгенерирует другое предупреждение, что a не используется).
>>1772912 > ленивость вычислений Программа не пишется, а сразу объявляется написанной. Фактическое формирование кода программы должно происходить при первом непосредственном обращении к ней, но поскольку никто не обращается, код тоже не формируется.
>>1757247 После прочтения про polysemy, мне он видится охуенной заменой джаве. Пишешь императивный код, все возможные эффекты описываешь в сигнатуре функций, нереально удобный мокинг для юнит тестов и тд. >>1757253 > Вообще - язык-полигон для перспективных математических фич без определённых задач. Т.к. начальное коммьюнити и основные концепты - математические, это привлекает и других людей, знакомых с матаном. Для любителей мотематики есть кок, агда, идрис и куча других языков со своей теорией типов.
>>1773423 хуяк хуяк и в продакшен это про ноду. А джава это AbstractSingletonBeanFactoryManager, что хаскель и способен заменить своей более крутой теорией типов.
>>1773515 И нахуя тратить годы на то, чтобы вырастить челов которые могут съебнуть и надо инвестировать тонны нефти в других по новой? Легче взять любую попсовую технологию и ебашить код прямо на проде, лол.
https://github.com/tildeio/helix Ну что, аноны. Пик хипстерства настал, по-моему. Осталось на этом запустить рельсы и можно будет пересажиать раби-макак на раст, лул.
>>1774653 >Легче взять любую попсовую технологию и ебашить код прямо на проде, лол.
Все так и делают: Архитектура жава-приложения: 1. договариваемся к американской компанией, что сделаем софт за половину стоимости. 2. нанимаем сотни индусов русских студентов за ЖРАТ. 3. лепим невменяемое говно из жавовских опенсорсных быдлиотек, сдобренное говнокодом студентов под управлением виабушных акхикектогов. 4. слегка проябываем дедлан, поэтому в конце добиваем код хаками, лишь бы запустилось (тем более выясняется, что акхитектогы напроектировали неудобную и нерабочую хуйню, зато по умным книжкам, которых они начиталсь). 5. ???? 6. Единоразовый PROFIT 7. Заклюючаем договора поддержки и сажаем на поддержку в 3 раза больше жавообезьян, чем было на разработке (оно и понятно, написать хуйню легко, а вот как потом её сопровождать?). 8. Дополнительный PROFIT в течение многих лет.
>>1775833 Оно везде так. ДЕЛАЕМ ХУЯК ХУЯК ОЙ Я ТУТ ВАМ НОВУЮ ФИЧУ ПРИНЁС ЗА 2 ДНЯ ДО РЕЛИЗА НУЖНА БЫЛА ВЧЕРА БЛЯ ПОЦАНЫ ДЕДЛАЙН ПРОЕБАЛИ А ХУЛИ ТАК ЛОГАЕТ СУКА А ЭТИ ДЕСЯТЬ ФИЧ ДОЛГО ДЕЛАТЬ? ДОЛГО? ЗНАЧИТ ВЫКАТЫВАЕМ ИХ ЗАВТРА
>>1776843 Скорее всего уже никогда. Там кучу людей с работы выгнали, чтобы мозилловская СОЕ_эсса могла себе зарплату поднять, а то 2.5 миллиона слишком мало для приличного человека (хотя вангую что в 2019 году, отчёт по которому скоро выйдет, там будет уже за 3 миллиона).
>>1776955 Заглянул в их мини-список и увидел это: http://https://talentdirectory.mozilla.org > Manish Goregaokar Это тот чувак который так торопился замержить пулл-реквест с заменой блек-/вайт- листов в основную ветку, что несколько раз (лол) замержил ещё до ревью (так что пришлось откатить).
>>1776984 Их гитлер — это, собственно, CEO, которой мало 2,5kk$. Капиталист, классовый враг жи. Правда быть врагом с кем-то вне твиттора и тамблера внезапна бывает ниприятна.
>>1777101 Увы, больно это говорить, но в плюсы. Раст не факт, что взлетит, а если и взлетит, то подвинет плюсы в их сфере минимум через лет 15, а то и 20. Но если тебе для души, а не для вката в индустрию, то раст вполне норм.
>>1777174 Из гугла был контрибьютор без права мержить пулл-реквесты в ветку. А этот в тот день именно мержами пулл-реквестов и занимался - у них там всё полу-автоматизировано.
поцоны, какие перспективы работы с раст в мск? Есть опыт два года на Си для мк и полтора года си шарп (ну и оттарабанил норм уник по специальности). Нравится область применения раста и сам язык. Если начну учить его сейчас, есть ли перспективы норм трудоустройства в мск? hh расстраивает просто и че по зп? спасибо
>>1756693 (OP) У кого-то осталась фото рабочего стола которого постили в одном из тредов. Там был повернут вертикально монитор, мышка лоджитек вертикальная. Ламповая, но не могу найти. Скиньте пожалуйста у кого есть