Зачем нужен раст, когда есть молодежный кристал?
GC
Ну и
> The project is in alpha stage: we are still tweaking the language and standard library.
В чем его преимущества перед ноджс?
Ну ноджс это детские очки. Можно надеть на себя, будет глупо выглядеть, оптическими свойствами не обладает, но можно честно сказать "я ношу очки".
Раст это гугл-глас с нейроинтерфейсом.
В том, что для nodejs нативные модули пишутся не на говноязыках, а на годноте. Npm давно использует rust у как средство улучшения developer experience
Пилю маленький игорь на сабже, полет нормальный.
На чем пишутся модули, на C или JS (хочу понять что ты называешь годнотой)? Каким образом NPM использует Rust, это ты сам придумал?
Вместо C можно (нужно) использовать Rust
Объясните, зачем в раст добавили сишное говно - строки cstring? Почему нельзя было просто взять и сделать язык без наследия далекого прошлого?
>This type serves the primary purpose of being able to safely generate a C-compatible string from a Rust byte slice or vector. An instance of this type is a static guarantee that the underlying bytes contain no interior 0 bytes and the final byte is 0.
Очевидный интероп.
>интероп
Ну и кому он еще нужен?
Всем кто пишет проекты сложнее laba3.exe
Биндинги к сишным либам по твоему получаются магическим образом?
Так-с, чего молчим? Никто не хочет абстракции с нулевой стоимостью?
Есть расширение для VS17 или лучше расширение для VS code адекватное для компиляции и отладки?
Интересный язык. Правда, сложно заставить себя писать именно на расте, а не на Си с растовским синтаксисом.
Это нормальная история при перекате на новый язык.
Туториал о том как сделать игорь.
http://piston-tutorial.logdown.com/pages/table-of-contents
http://piston-tutorial.logdown.com/pages/table-of-contents
Насколько ржавчина надежна/безопасна? Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром? Или все, что написано на чистом расте, гарантированно корректно?
> Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром?
Можно.
Но к безопасности и надежности это отношения не имеет.
Rust это Google Cardboard
Насмотрелся роликов на ютубе про безопасный Раст. Начал писать. Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями. Да и вообще поймал себя на том, что слишком часто я использую эти "опасные" операции. Либо надо полностью менять ментальность, либо одно из двух.
Ну ты придумал. Окошки на винде открывать.
Возьми Qt ил Gtk или что попроще.
Пипец, если ты собираешься стать программистом, тебя столько разочарований ждет. Лучше займись чем-то другим.
>Можно.
А небольшой пример такого кода где найти?
>Но к безопасности и надежности это отношения не имеет.
Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
>А небольшой пример такого кода где найти?
Херачиш унсейф.
>Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
Надежность\безопасность ЯП\среды, и реализованного на этом ЯП кода - вещи разные.
Безопасна ли машина с подушкой безопасности? - безопасна.
Безопасно ли врезаться в столб на скорость 200км в час с не пристегнутыми ремнями?
Да даже с престегнутым и с рабочей подушкой безопасности так себе идея. Но фанатикам не объяснить.
> Купили как-то суровым сибирским лесорубам японскую бензопилу.
> Собрались в кружок лесорубы, решили ее испытать.
> Завели ее, подсунули ей деревце.
> «Вжик» — сказала японская пила.
> «У, бля...» — сказали лесорубы.
> Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
> «Ух, бля!» — сказали лесорубы.
> Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
> «Ух ты, бля!!» — сказали лесорубы.
> Подсунули ей железный лом. «КРЯК!» — сказала пила.
> «Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами…
И что же конкретно тебя разочаровало?
А я тут причем?
>Но фанатикам не объяснить.
Да то не фанатик, а просто ребенок, который мало чего в этом самом программировании понимает.
Мне на секунду показалось, что ты исходя из своего опыта это заявляешь.
Ты думаешь, они какое-то другое виндовз апи там используют?
Ну да, из опыта.
Из наблюдений, здравого смысла, и выводов.
Многим молодым людям, программирование видится чем-то очень интересным, особенным. Они видят написание кода как интересную задачу, создание чего-то красивого, идеального.
Но в реальности, это неблагодарный, монотонный, тяжёлый труд, по созданию комка костылей склеенных соплями.
Нет красоты, нет консистентности, нет идеальности. Есть бесконечный копипаст и забагованные текущие либы.
Костыльность и неидеальность нужно принять как должное.
А если такого органичного принятия нет, человек будет страдать, всю жизнь быть может.
>И что же конкретно тебя разочаровало?
IT как таковое. Качество людей в нем работающих.
Не переношу бракоделов, профанов, и самодуров. Нет уважения к своему труду.
А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.
> Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями.
Ты явно преувеличиваешь.
Насколько я помню, винапи вполне элементарно.
Даже на ассемблере беспроблемно окошечки создавать.
Только что компилил проект на виртуалке с виндой. крейт winapi прекрасно сконпелился.
Там во всех областях. Красоту нужно уметь видеть, это субъективная история. Если ты не видишь её, то это не значит что её не видят другие.
А что касатеся "шахтеров", то что в этом удивительного? Профессия новая, особенно на постсоветском пространстве.
В расте вызов сишной функции и передача raw поинтеров считается опасным кодом.
Ну я в этом вашем расте не силен, но насколько я помню он гарантирует безопасность памяти. Однако утечки памяти можно множеством способов устроить. Например, накостылить бесконечный цикл. От такой рукожопости ни один яп не убережет.
Можно всё.
Делаю игорь для дрочения хираганы. Зависимость есть, брат жив.
Бред уровня запрета ЦП. Избежать ошибок можно только одним способом - не быть криворуким дауном. Для этого не надо создавать ещё один бесполезный язык и говорить, что он лучше C/CXX.
> Избежать ошибок можно только одним способом - не быть криворуким дауном
Работает только в проектах уровня лаба1.
Ты не понимаешь что такое "утечка памяти".
Пиши на ассемблере, хуле ты как не мужик.
> не быть криворуким дауном
Аюсолютно каждый программист криворукий даун в той или иной степени. Поэтому лучше пользоваться языком который позволит автоматически избегать определённого класса ошибок.
Все ошибаются.
На любое обвинение у сибляди есть универсальный ответ - "криворукость". Этим сиблядь как-бы намекает, что что все вокруг криворуки - т.е. сотрудники микрософта и интеля, пишущие кривые драйвера и библиотеки, прыщебляди, пишущие дырявое ведро своей системы вот уже не первый десяток лет, просто другие сибляди из соседнего подвала полусвовковой шаражки, в которой сиблядь работает. А вот сама сиблядь - сука граф Шарль Ожье де Бац де Кастельмор д’Артаньян среди педерастов, владеющий техникой левитации, предсказания будущего и написания небыдлокода на сишке. К сожалению, простым смертным едва ли не удастся увидеть творения сенсея, так и будут они работать с глючным говном криворуких интелевских и микросовтовских инжеренов, внезапно падающим от какого-нибудь buffer overflow, несмотря на зиллионы человекочасов, проёбанных на его тестирование и отладку.
Сагу то за что прилепил, ирод?
паприколу
> #[allow(шутник_дохуя)]
Утечка памяти это когда память проебывается все больше и больше по мере работы программы. Что не так?
Внешне оно выглядит так. Но к твоему циклу не имеет никакого отношения.
Утечка - это если к динамической памяти нет вообще никакого способа обратиться. Если же ты никогда не теряешь ссылки, то всегда сможешь увидеть в отладчике странный вектор на миллиард элементов или типа того. Т.е., память просто избыточно выделяется, а не утекает.
Раст это хипстерские очки с розовыми стеклами.
С хуя бы? Розовые стекла в хачкеле, например. С дырочками.
>граф Шарль Ожье де Бац де Кастельмор д’Артаньян
Сука орнул с поста. Но идика ты нахуй, все заебись на С написано и у интела и у прыщеблядей, прыщикс вообще самое лучшее что создавали за последние десятки лет программисты. Единственное в чем я с тобой согласен это про майкрософт, там действительно пиздецовые дауны на С так наговнокодили что пиздец.
График уязвимостей в ядре покажи-ка?
Я хуй знает я не слежу за графиками, ибо какой от этого толк? Даже если там и у прыщикса больше чем у спермы, то толко потмоу что прыщикс разрабатывают в сотни раз больше людей чем сперму, и еще учитывай что в сперме намеренно делются уязвимости для различных спец. служб, как недавно было с атаками шифровальщиков которые использовали уязвимости сделанные специально для АНБ.
Ну согласен, с циклом плохой пример пусть это будет рекурсия.
>Т.е., память просто избыточно выделяется, а не утекает.
Это и называется утечка, когда в память выделяется, но обратно не высвобождается.
Если память используется, то это не утечка.
Чет ты сочиняешь уже
Утечка памяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.
Мань, че ты тупенький такой? Сам же пастишь:
> неконтролируемого уменьшения объёма
Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить. Но если ты проебал указатель, то есть физически освободить сама программа её уже не может, это как раз "неконтролируемое" уменьшение.
Кек, то что ты пытаешься втереть вообще не существенно. Даже если в теории ты можешь контролировать разбухшую память, но в программе такое поведение не предусмотрено, то это все равно будет утечкой. О чем ты пытаешься кукарекнуть уже относится к безопасности памяти, то, от чего раст защищает в 100 и 100 случаев если не врубать unsafe.
>раст
>врубать unsafe
so laba1.rs
Чо там с const generics? HKT до 2.0 не появятся, я так понял а тогда уже и голанх 2 подъедет со своими дженериками
У раста есть какой-то казуальный режим для плебса, который пишет на питоне и JS?
Go
Раст это инструмент для решения задач имеющий определенный набор характеристик. Если тебе нужна простота, то действительно, возьми го.
Ваще не одупляю, почему люди вспоминают о го в контексте раста и наоборот. Языки вообще никак не связаны.
Мне кажется как казуальный раст нужно упоминать кристал. Только там вроде пока мультитрединг внятный не сделали.
>простота
простота != легкость (в изучении)
>неконтролируемого
Из твоей же вики:
A space leak occurs when a computer program uses more memory than necessary. In contrast to memory leaks, where the leaked memory is never released, the memory consumed by a space leak is released, but later than expected. [3]
Короче, отличие в том, что с утечкой памяти сделать уже нихуя, а утечки `пространства` можно попытаться избежать грамотным проектированием
>Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить.
Речь шла о менеджет языке я так понимаю. Изначально.
Так вот, в менеджет коде, у тебя нет "на нее указателей", они есть у среды выполнения(необязательно), так что по этому пунку - сие есть утечка.
Дальше, давай разберем тобой написанное, ты тут сам выдумаешь значения терминов, фантазер, тебе лет то сколько?
Какая в жопу разница, есть указатель, или нет, если память не освобождается там, где должна?
С таки то подходом после закрытия приложения память все равно освободится так что утечки нет1111)))))))
Иди сделай бочку, реатрд.
>space leak is released, but later than expected.
Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
Уже 10 раз объяснили:
> A space leak occurs when a computer program uses more memory than necessary.
Если память жрется больше чем надо, никогда не чистится, то это не утечка памяти. А space leak. "программа жрет много памяти потому что хуевый алгоритм". Называй как хочешь.
Языки с гц могут течь, например, если гц делает reference count.
>In contrast to memory leaks, where the leaked memory is never released, the memory consumed by a space leak is released, but later than expected.
Ты сам себе противоречишь.
вы заебали со своей памятью. лучше бы по теме что-нибудь писали
Например?
Я пилю игрушку, например. Две недели пытался завести её на андроиде, но нихуя не вышло. Плюнул, пилю под декстоп пока.
>Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
Утечка памяти.
Как пытался завести? Я тоже хочу написать игру.
Какие есть для Rust веб-фреймворки?
Так короче растоблядки. У вас есть минута чтоб пояснит ьмне чем ваш раст лучше golang или D?
не пишу ни на одном из этих языков, но очень желаю смерти с++
не пишу ни на одном из этих языков, но очень желаю смерти с++
В Ди есть гарбедж коллектор, а в Ржавом не нужен из-за передачи ownership'а и прочих плюшек.
Голанг не имеет такой развитой системы макросов.
А как в ржавом тогда ресурсы особождаются? Время же недетерминированно становится. Например, если удаляется какой-то сложный объект который влечет за собой кучу деаллокейтов ? В то время как в языке с GC, это удалится потом и не вызовет задержки программы.
Время каждого ресурса определено статически с помощью системы типов.
Гарбадж коллектор, долбоёб, неужели не очевидно?
Долбоебина, может сначала бы прочитал дальнейшие посты, прежде чем высирать тут что-то?
>Время каждого ресурса определено статически с помощью системы типов.
Вот это действительно хорошо заделали. А пример можешь привести? А то меня всё время смущало, вот вроде бы скорость, детерминированность, безопасность, а как освобождать глубоко вложенную структуру, так и мало того кто последний тот и ебётся, так и ещё свалится с запросто. Тут вообще комбо получается: переполнение стека, да ещё и в деструкторе.
мимо другой анон
кто-нибудь из присутствующих пробовал писать игрушки на расте с использованием piston или amethyst? если да, то отпишитесь как полет
>Вот это действительно хорошо заделали. А пример можешь привести?
Фак. Написал длинную телегу и куда-то не туда нажал.
На каждый объект в Расте может быть либо одна ссылка, через которую объект можно менять, либо сколько угодно read-only. Кроме того, ссылка не может жить дольше, чем объект, на который она ссылается. Передача же не по ссылке - это аналог std::move в плюсах.
Это позволяет удостовериться, что как только переменная вышла из своей области видимости, её можно смело удалять, не оставив никаких висячих указателей.
Система не идеальна, и для некоторых вещей нужен unsafe-блок, который позволяет использовать обыкновенные указатели. В таком случае на программисте лежит ответственность сделать так, чтобы в интерфейсе поддерживался инвариант из начала поста.
Мы с тобой побеседовали хорошо, жаль что про разное только. Изначально анон поинтересовался за финализацию и детерменированность времени на неё. Ну например для структуры N = Z | S N реализованной на, пусть будет, Arc сложность деструкции линейна по времени, а в наивной реализации ещё и по стековой памяти. Для структур же более ветвистых - сложность только растёт. Добавив что если используется какой-то абстрактный типаж, то о времени деструкции сказать вообще вряд ли что-то возможно не рассматривая весь код. И если ресурсом пользовались несколько потоков, то освобождать её предстоит последнему, чем могут быть неприятно удивлены апологеты сборки мусора. Вот я и подумал было, услышав про статическое определение времени каждого ресурса, что решается именно эта проблема.
Что пилишь, анонче?
Какая-то смесь Python, C++, не?
Если точнее, то haskell и c++
Я просто мимо проходил, лол
Использование Arc - это перенос гарантий из статики в рантайм, т.е. компилятор тут ничем не поможет, увы. А многопоточность чисто на борровинге будет максимальным пердолингом.
Ну вон тот же rayon как сделан. Гарантированно безопасные unsafe блоки заэнкапсулированы внутри, а апи чисто safe
>чем ваш раст лучше golang или D
Всем лучше.
Какой вопрос - такой ответ
Таки верно. Можно считать, что он на ступень эволюции выше (на 2 выше go)
Что-то типа кликера.
Лучше всего посмотреть любую презентацию про Rust. Вот натолкнулся на очередную youtu .be/oIikwmeGVYY
Вполне ничего
Питонисту тяжело будет в раст вкатиться?
Если кроме пиздона ты ничего больше не видел, вероятно сложновато.
Все равно вкатывайся. Материалы хорошие. Узнаешь основы функциональщины, типизации.
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.
Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.
Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.
Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?
Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
>И один хер придётся использовать небезопасные блоки кода
1. Почему придется?
Стейтмент так себе.
>невозможностью реализовать добрую половину привычных структур данных
Все там можно.
>вещи пусть и порочные, но глубоко привычные
Ты так говоришь, как будто что-то хорошее.
>Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
Создавался как то, что должно было появиться, но вместо чего появился С++.
>Стейтмент так себе.
>Все там можно.
Вот продемонстрируй мне двусвязный список, руками, а не из коробки или же дерево где дочерняя ветвь хранит ссылку на родителя, и я пристыженный уйду. Нет, я допускаю что можно всё организовать в массив и в структуре хранить индексы запроместо указателей, но былой стремительностью такой подход уже не похвастается.
>Ты так говоришь, как будто что-то хорошее.
Я вроде ж указал на заведумую порочность. Другое дело, что сторонние-то функции далеко не все реентерабельны. Заодно поясните, я наткнулся раз на демку в которой рисуются красные квадраты, как GL адаптировали? Ну я о том, что в два потока не порисуешь ведь - хуета получится, стало бы либо монитором защищать либо передавать обёртку, но тут-то надо же хранить где-то флаг пользует её кто-то или нет.
>но былой стремительностью такой подход уже не похвастается
Храните в HashMap, кто вам запрещает-то?..
>либо монитором защищать либо передавать обёртку
либо EnterCriticalSection() и затем LeaveCriticalSection()
>Храните в HashMap, кто вам запрещает-то?..
Ты про какой-то волшебный HashMap в котором сложность доступа к элементу не O (ln(n)) и даже меньше константной сложности проверки индекса и обращения к элементу в массиве? Не очень тебя понял по-видимому.
>instead of pointers we use indices into a backing vector
Впрочем, ты уговорил. Подход немного непривычный, не самый шустрый, но вполне обоснованный при данных условиях.
>EnterCriticalSection
Ну она ж аргумент принимает? Где-то хранить его надо между вызовами, ведь не каждый поток в свою критическую секцию заходит.
>он для каких задач и для какой аудитории вообще изобретался?
Наркоман? На их сайт зайти и прочитать не можешь? Пиздец, вот вроде пишет человек пост: длинный, грамотным русским языком, вопросы всякие вполне обоснованные задает... а потом в самом конце берет ушат собачьего дерьма, выливает на себя и начинает ногами дрыгать: "я в дерьме! я говно ем!" - пиздец, нахуй так жить-то?
>И один хер придётся использовать небезопасные блоки кода
Не нужно. Нужно использовать новую парадигму, а не свои привычные костыли из c++
Не знаю как там у вас в двусвязных, но обычный односвязный предназначен для того, чтобы быть на heap и быть полностью персистентным, либо туплоподобным и иметь известную длину, запечатленную в типе.
>волшебный HashMap
Да, выжирающий сотни памяти, он перестраивает хеш-индекс во время работы и даёт почти мгновенный доступ к данным.
>>EnterCriticalSection
>Ну она ж аргумент принимает?
Она переключает режим выполнения, чтобы работал только вызвавший её поток, а потом другая функция его возвращает в тот же режим как было. Всё это костыли, естественно.
>ушат собачьего дерьма, в дерьме, говно ем
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.
>Не нужно.
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?
>почти мгновенный доступ к данным
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.
>Она переключает режим выполнения, чтобы работал только вызвавший её поток
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.
В чём преимущество перфоратора перед дрелью? Дрели перед перфоратором?
Как ты думаешь, для чего вообще в расте придумали "опасный код"?
То что создание новых языков и переписывание всего под них приводит к убыткам это правда. Но так же правда и то, что поддержка и развитие легасей крайне дорогое, без особой надежды на улучшение ситуации в будущем.
Пиши без использования ссылок. Копируй/клонируй всегда и везде.
>Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини?
Увы, ты промахнулся.
Кстати, позволю себе замечание по поводу содержания остального поста. Что ты, блядь, хочешь-то от нас от них?! Тебе, блядь, дали язык, на котором можно писать чуть ли не в функциональном стиле с ебаной кучей статических проверок без гц и быть на 10-15% медленее си. Тебе дали возможность писать на си с нескучным синтаксисом и тем же тулингом, когда эти 10-15% тебя не устраивают или когда компилятор анально насилует тебя в жопу. Вместо того, чтобы возрадоваться и поблагодарить Бога за это, ты приходишь в этот итт тред и начинаешь лечить про то, что хэшмапы медленные. Сука, блядь, так хули тебе надо-то?!
Он из тех кто против и ищет подтверждения своим убеждениям.
Сможет ли Раст обогнать С после всех оптимизаций?
Да. Пиздуй контрибьютить в llvm и rustc.
>Сука, блядь, так хули тебе надо-то?!
Ты прям срузу с козырей. Потолковать хочу за всякие нюансы, попиздеть по большей части для души. Сама система типов, и правда не может не вызывать восхищения. Вот мне и интересно является ли она во всей своей чистоте и ортогональности практичной и достаточной для какого-либо маломальски серьёзного промышленного проекта. И как адаптируются традиционные подходы в переложении на неё. И какие подобная адаптация может скрывать за собой опасности.
Вот и интересуюсь.
Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах, кто-то и окажется готов поделиться мнением. Указать на какую-либо избыточность или недостаточность языка или одного из его элементов, посетовать на те случаи где они заебались бороться с borrow checker'ом и где наоборот он их сильно выручил. Хватает ли им скорости хэшмапов или приходится использовать unsafe. В одиночку это было бы в любом случае гораздо сложнее, а тут целый тред по языку создан.
>Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель).
1. Это еще не факт. Без тестов говорить не о чем.
2. Сделай сначала свой код с указателями на сишечке нетекущим и хоть немного безопасным, а потом сравни скорость еще раз.
3. Модель выделения и освобождения памяти для твоего волшебного списка, влияет на производительность на порядок больше способа связывания.
Что приводит нас к пункту 4.
4. Имеет смысл о чем-то говорить сравнивая конкретные реализации. Есть серьезные подозрения, что код на сишечке, с тем же функционалом, может оказаться как минимум громоздким и страшным, а еще может и медленнее в итоге работать.
5. Для крит важного кода, вроде realtime систем, есть ассемблер. Та-же си не очень то тут работает.
6. Иди лучше мамке своей посетуй.
6.1 Поболтать оно конечно бывает интересно, но о чем тут собственного говорить и размышлять? Когда и так все ясно? А сама тема не стоит и выеденного яйца.
Мимо анон.
>То что создание новых языков и переписывание всего под них приводит к убыткам это правда
Ну, далеко не всегда.
Скажем даже так, в 2017 году это утверждение скорее всего ложно.
1. Идея переиспользования кода оказалась сильно переиспользована и неправильно понята. В реальности это вносит проблем иногда больше, чем решает. Почему?
- Стороннее решение не содержит специфического функционала или в нужном виде, что приводит к дополнительному коду, иногда весьма замысловатому, или еще хуже, изменениям\деформациям архитектуры.
- Стороннее решение представляет из себя черный ящик.
- Потребность в нужном функционале приводит к необходимости адаптации стороннего решения, создаются даже отдельные команды и подразделения дорабатывающие хуй знает какой чужой код. (а потом приходит озарение и пишут свое решение)
- Зависимость от третьих лиц со всеми прелестями - внезапными багами, брешами безопасности, несвоевременным обновлениями, и даже закладками\вирусами.
2. Все это как-то окупалось во времена, когда программист был редким и дорогим специалистом, а сам процесс был сложным в отсутствии продвинутых средств разработки и примитивности языков программирования. Сейчас ситуация кардинально другая. Дети учатся программировать с детского сада. Специалистов даже переизбыток. а новые современные средства и языки позволяют создавать код с повышенной эффективностью.
3. В 2017 году СКОРОСТЬ разработки выросла в разы, и это не просто для красивой циферки в версии и чтобы казаться современными молодежными, просто информация в мире стала перемещаться в сто раз быстрее чем в 2000 году, и в 1000 раз быстрее чем в 1980. Мир ускорился, нужны новые современные решения сейчас, еще вчера, неделю назад.
А кто-то IE6 поддерживать пытается, а потом из ЦРУ утекает эксплойт и останавливаются целые заводы в разных странах, потому что на них Windows XP стояла, блядь.
Легаси в 2017 - непозволительная роскошь.
Это как блядь лампочки накаливания вместо LED использовать.
>Сама система типов, и правда не может не вызывать восхищения.
Ага! Я так и знал, что ты мазохист, содомит и бдсм-извращенец, бгг.
> или приходится использовать unsafe
This.
Я не пишу на расте, но еще в прошлом посте написал про си с нескучным синтаксисом. Ансейф - это не какой-то смертный грех, это просто способ не пиздовать в си, а писать сишный код прямо тут же, в расте. Тайпчекер же нужен не ради самого себя, а для гарантий. Там, где ты можешь (думаешь, что можешь) предоставить эти гарантии сам, можно его выключить. Если тебе нужны не простые хэшмапы, а WOW SO HASHMAP 2000% BONUS CRITICAL SPEED ACHIEVEMNT UNLOCKED BAYTOŒB PWND, то ты просто берешь и пишешь их без задней мысли. Главное, как всегда, изолировать это говно и тестировать это говно. Тут, блядь, нет какого-то "АХАХАХ ВОТ Я ВАМ ГОВОРИЛ АНСЕЙФ ВЕЗДЕ ТАЙПЧЕКЕР СОСНУЛ РАСТ НИНУЖОН)))00", - он изначально таким и задумывался, блядь. Это не баг, это фича.
Ну и это.
> Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах
> 2ch.hk
> серьёзное ПО, участвуют в крупных проектах
> 2ch.hk
Ты какой-то странный. Нет ничего плохого в IE6 если твой завод физически отрезан от внешнего мира. А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза.
Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости, отсюда растут ноги NIH.
>А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза
Необразованный безмозглый дегенерат.
Иди в /ra/ чтобы тебя там хоороошенькго обоссали. Я даже начинать не буду.
>Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости
Стандартное объяснения почему компаниянейм создала пиздатый продуктнейм - "нас заебало стороннее легаси говно и нам пришлось сделать свое."
>Нет ничего плохого в IE6
>Ты какой-то странный.
Сук пиздос.
>что переписывают чаще в процессе глубокого изучения
Да блядь просто берешь и создаешь нужный тебе функционал.
90% всего уже есть в стандартной библиотеке. А если нет, то на помойку этот язык.
Ты какой-то буйный. Сходи-ка на хуй на всякий случай.
Я не он но ты хуйю несешь. LED в 10 раз экономичнее и глаза от него не устают. У меня вся квартира ими обмазана. Профит от LED настолько очевиден что его не заметил только полный слепец.
Да причём тут экономичность. Вдруг мне просто нравится тёплый ламповый свет? Люди даже камины дома сооружают, на дровах, Карл. У того буйного проблемы с подбором аналогий, всё что я хотел сказать. Я даже не понял что он хотел сказать своими длиннопостами, какие-то разрозненные бессистемные аргументы без тезиса и вывода.
Речь о спектре излучения, але.
Это я к тому, что профит от использования LED с головой перекрывает лампы накаливания. Тоже самое с использованием легаси.
Ну не знаю. libpng тоже переписываешь каждый раз? Везде биндинги, везде FFI. Это тоже легаси? Как бы зачем переписывать то что вылизывалось чуть ли не десятилетия?
Я сказал, что не собираюсь обучать подобного дебила. Иди в /ra/.
>Вдруг мне просто нравится тёплый ламповый свет?
1. Есть лед с Ra 95-98, даже лучше чем у ламп накаливания.
2. Необучаемый, думает, что лед лампы не могут светить теплым светом?
>мне просто нравится
Заебись.
А ничего, что речь шла о ЭКОНОМИЧЕСКОЙ ЦЕЛЕСООБРАЗНОСТИ, а не о том, что какой-то пизде нравится, или не нравится?
Тебе никто не запрещает хоть дуговыми лампами освещаться хоть свечами, хоть газовыми светильниками.
>Я даже не понял что он хотел сказать своими длиннопостами
>многабукаф нипонятно
>слишком длинно111
>я ничего не понял но все равно напишу какуйнибудьзхуйню вместо того чтобы расспросить о непонятных мне вещах.
>ведь я такой умный я все знаю
>У того буйного
>Ты какой-то буйный
Задеваю твою женскую гордость?
Мужчина не должен привлекать к себе внимание, если ему нечего сказать.
>Речь о спектре излучения, але.
А что спектр излучения?
А ты среднюю дисперсию посчитал для спектра солнца\лампы накаливания и солнца\LED ?
Я уже понял что в /ra/ лишний раз лучше не заходить. Что ты так орёшь-то? Сам небось своими светодиодами барыжишь? Экономическая целесообразность как раз таки очень спорная, светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит, а электричества на всю стоимость лампы не сэкономит.
>светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит,
А вот это пиздеж. На LED лампы одна лишь гарантия 2 года. Стоит они 100рублей примерно. Охуеть как дорого.
1. Ты пишешь как манерный гей.
2. Даже относительно дорогие леды даже если допустить их малый срок службы, окупаются за счет стоимости электричества. Разница, внезапно, десятикратная.
А так то у меня 10$ LG с 2013 года в ванне светит.
Чем тебе не угодили геи?
>Чем тебе не угодили геи?
Все в порядке с геями, только мы тут RUST обсуждаем, а не женские чувства косметику и наряды.
Для геев есть /ga/.
fn yoba () {
let mut vc = vec![1, 2, 3];
let r0 = &mut vc[0];
let r1 = &mut vc[1];
}
Так, это вполне закономерно не компилируется. Хотя для разных полей структуры вполне канает. А какой тут правоверный способ получить изменяемые ссылки на заведомо разные элементы массива?
let mut vc = vec![1, 2, 3];
let r0 = &mut vc[0];
let r1 = &mut vc[1];
}
Так, это вполне закономерно не компилируется. Хотя для разных полей структуры вполне канает. А какой тут правоверный способ получить изменяемые ссылки на заведомо разные элементы массива?
Что за ебантизм этот ваш раст https://play.rust-lang.org/?gist=33c938daad857749a42b5add67732492&version=stable
Но про долбоеба это же не точно?
Судя по тому что ты пытаешься assert_eq юзать в качестве условия, точно.
Да я полчаса назад начал его тыкать.
Значит ты пиздец зеленый, раз не знаешь что такое assert.
В Go такого нет.
Как у вас получить последний эелемент слайса?
Ага, по-даунски как в го
Ты просто мастер хуевых аналогий. Иди линукс переписывай.
rc?
>Это еще не факт. Без тестов говорить не о чем.
Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
>код с указателями на сишечке
Если ты пропустил скучное предисловие, то там сравнивали с go и d. И на них это будет вполне себе безопасно. Давай, заяви про GC и пойдём по второму кругу.
>влияет на производительность на порядок больше способа связывания
Заявление слишком сильное и категоричное, жаль только что не для всех случаев верное. А именно для случаев в которых выделение и освобождение памяти явление относительно редкое, а обращение к объекту - частое. Но тут соглашусь, нужно исходить из задач.
>может оказаться как минимум громоздким и страшным
А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
>Для крит важного кода, вроде realtime систем, есть ассемблер
Не, ну а как же абстракции с нулевой стоимостью? А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
>о чем тут собственного говорить и размышлять
Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
Не, ну а где собираются серьёзные системные программисты как не на двощах. В Mozilla Research что ль, скажешь тоже. А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет, прям хоть в петлю завязывайся. Вроде как вот тебе интрумент для создания красивого правильного, но нерабочего кода, а вот для чтоб работало, но через хуй колено. Всё ж развивается ПО, развиваются трансляторы, языки нескучные появляются, может и заебенят такое что все охуеют.
А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
Я нубас просто, не расскажешь подробнее?
Чувак, прочитай растбук для начала - они гораздо лучше меня все объяснят.
>А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет
Щито? Ты его мессаджа не понял, видимо.
> интрумент для создания красивого правильного, но нерабочего кода
Ээ... Щито?
> а вот для чтоб работало, но через хуй колено
Чего блядь?
> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать
Ээ... Так как бы "такое количество ограничений как в ржавом" как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни. У меня такое чувство, что тебе тоже надо посоветовать прочитать растбук.
> гарантии тотальности
Ээ, расскажешь, как через афинные типы делать тоталити чек?
>Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
Вместо тестов дезассемблировать?
> то там сравнивали с go и d. И на них это будет вполне себе безопасно
Ну и на расте будет безопасно.
>Заявление слишком сильное и категоричное
Это ты его так просто чувсвуешь.
>Но тут соглашусь, нужно исходить из задач.
Ну вот и славно.
>А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.
>Не, ну а как же абстракции с нулевой стоимостью?
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.
>А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.
>Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
Нет, увольте.
>А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
Ну, раз так все просто, возьми и сделай.
Пишут ли уже игори на расте?
Это не я начал.
https://play.rust-lang.org/?gist=1b7ce5c87de05e0733759e8a7936f382&version=stable
unwrap() нужен потому что последнего элемента в общем случае может и не быть, поэтому ты получаешь Option<T>. В продакшн коде менять на expect или паттерн матчинг
Пишут мелкие поделки всякие. Наркоманы пилят amethyst. ggez для 2д норм. piston очевидный.
Ебанутся, оказывается String это не str. Вы там совсем ебанулись, аллё?
Ебануться, оказывается масссив это не слайс. Вы там совсем ебанулись, аллё?
>Ты его мессаджа не понял, видимо.
Да вроде бы понял, но судя по количеству "Щито" в ответе - немного по-своему. Поясню. То что ты говоришь про тестирование и изолирование, в контексте вопроса использования небезопасного кода - безусловно правильно, только уж слишком универсально. Что-то в духе пиздато делай - пиздато будет. Также и сионист будет пояснять за с/спп, у меня, дескать, не течёт нихуя, я весь код изолирую, и ты так делай. Да не раз же в тредах было.
Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.
>как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни
Ты не путаешь причину и следствие? Мне казалось что изначально стояла задача создания системного языка для написания быстрого и безопасного кода, и отсутсвие циклических ссылок тут лишь средство. Подобным же средством могут выступать регионы в языках типа циклона, там наверняка много своей спецефичной поебени, но цели вроде бы те же. Только, пожалуй, совместить эти два подхода очень непросто.
>как через афинные типы делать тоталити чек
Тут я не матёрый дока нихуя, но что-то типа: на каждом шаге один элемент должен быть структурно меньше предыдущего. Есть же языки с подобным, даже императивные. Да и данные благодаря системе типов организуются древовидно в основном А выкинуть Rc<RefCell<什么>> так и вообще всё строго будет .
Ну ты прям громишь по всем пунктам. Спасибо за щеку не накидал ничего.
>я весь код изолирую
Ты хуйню какую-то несешь, скажу прямо. Если одну и ту же функциональность можно реализовать либо на си, либо в два раза быстрее, чем на си, в четыре раза надежнее и без серьезных потерь в производительности, то рационально выбрать второй вариант. Где второй вариант недоступен, там приходится выбирать первый. Количество таких мест надо минимизировать, сами места изолировать. Капитан очевидность, привет. При чем тут сионисты с крестоносцами и как можно "весь код изолировать" - хуй тебя знает.
> универсального формализма
> универсального
> формализма
> люди-то годами работают
Что-то из разряда "бля, ну научному методу уже 2 сотни лет в обед, хули до сих пор не открыли все законы природы" или скорее даже "бля, ну математике уже 2 тыщи лет в обед, хули до сих пор что-то там придумывают".
> Ты не путаешь причину и следствие?
Взаимные ссылки нужны, чтобы добавить ограничения в раст? Для диванного философа ты как-то хуевато с логикой дружишь.
> отсутсвие циклических ссылок тут лишь средство
Да я вроде обратного и не утверждал, не? Отсутствие побочных эффектов - тоже "лишь средство", например. Да и вообще программирование как деятельность - это "лишь средство". И чо? А циклические ссылки - это в любом случае code smell.
> на каждом шаге один элемент должен быть структурно меньше предыдущего
А афинные типы-то тут при чем? Тащем-то, сабтьюринговость достигается запретом явной рекурсии, например.
>Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.
Такого формализма быть не может, в виду не Господь полной природы вычислительных систем с которыми мы работаем.
И даже если бы и Господь полная система была, формализмами она бы все равно не оперировала бы.
Раст - неплохой ЯП, двигающийся в правильном направлении, ЯП должен программиста дрючить, и бить по рукам за любое отступление от здравого смысла и единственного решения.
Правда, разрабы решили пихать в него слишком много языковых возможностей, что приведет к деградации и рабству.
Это собственно самый главный грех С++, попытка включить в себя все что только можно.
Специализация - благо.
Излишество синтаксиса - грех.
Можно сурс?
>Можно сурс?
Полея Увода
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
>Для диванного философа ты как-то хуевато с логикой дружишь.
Причину и первопричину конечно же. К чему так остро острить.
>это в любом случае code smell
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?
>А афинные типы-то тут при чем?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?
>сабтьюринговость достигается запретом явной рекурсии, например
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:
function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}
На ATS, тоже что-то подобное встречалось.
>полной природы вычислительных систем с которыми мы работаем
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.
>Излишество синтаксиса - грех.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?
Если ещё точнее, то Haskell и C
>Ну вся эта полнота
Я речь веду о конкретной полноте, Господь-полноте.
>то глядишь и получим со временем некую заведомо детерминированную модель
Нельзя получить заведомо детерминированную модель в заведомо не детерминированном мире, только если ты не Господь.
Вон даже физики вероятностным распределением оперируют.
> Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций.
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.
> Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.
Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.
> Причину и первопричину конечно же.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.
> как быть с сущностями призванными соответствовать объектам предметной области
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.
> вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.
> не просто численный тип, а численный тип определённый как индекс, некоего массива?
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.
> тип на данные которого может быть всегда только одна ссылка
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.
> какие тут спецефичные проблемы?
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.
> А с неявной проще, или что ты имеешь в виду?
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".
Я пардон за задержку.
>Господь-полноте.
Повторюсь. Не нужно.
>зависит от предметной области, от бизнеса
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
>Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области?
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
>При чем тут это вообще? Не улавливаю, куда тебя понесло.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
>values of values
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
>ты же через афинные собрался делать тоталити чек
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
>без кривых костылей вроде "decreases n"
Вкусовщина же. Да и универсальней на мой взгляд.
>Господь-полноте.
Повторюсь. Не нужно.
>зависит от предметной области, от бизнеса
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
>Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области?
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
>При чем тут это вообще? Не улавливаю, куда тебя понесло.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
>values of values
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
>ты же через афинные собрался делать тоталити чек
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
>без кривых костылей вроде "decreases n"
Вкусовщина же. Да и универсальней на мой взгляд.
>корректность в более узком смылсе
Ну это не корректность, а просто более стронг гарантии компилятора. Ок.
> Не, я их рядом не ставил.
Ну ты же сам сказал: как быть с сущностями из домейна, рс с ними использовать или массивы, что-то такое. Я и отвечаю, что "сущности из домейна" и массивы (рс, классы, объекты, хэшмапы...) - это понятия разных уровней.
> В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое.
Я вообще не ебу, о чем ты. Кто тебе в расте запрещает это делать? Какие индексы, какие цифири?
> о преимуществах неизменяемых сущностей над изменяемыми
Нет, не об этом. Посмотри целиком. Алсо, повторюсь с прошлого поста: «Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.» Так что за "конкретные объекты"?
> я лишь пожалел что до меня не сделали
Блядь, я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют. Ты, очевидно, другого мнения, - вот я у тебя и спрашиваю (уже три поста подряд), как ты через афинные типы собрался делать тоталити чек.
> Вкусовщина же. Да и универсальней на мой взгляд.
Натуральный счетчик универсальней рекурсии? Ну, гхм.
>>Господь-полноте.
>Повторюсь. Не нужно.
Повторяю, для детерминированной модели отражающей реальный мир - нужно.
Конечно, ты можешь построить какую угодно модель для чего угодно, но толку от нее, если она не работает?
А чтобы полностью детерминированная модель работала, тебе нужна Господь-полная система.
Вот мы вроде бы и оба на русском пишем, а понимания больше не становится нихуя.
>Я вообще не ебу, о чем ты.
Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок. Их и предполагалось эмулировать через индексы.
>Кто тебе в расте запрещает это делать?
Компилятор запрещает, кто же ещё. По прежнему о той же попытке эмуляции.
>Так что за "конкретные объекты"?
Я, наверное, очень хуёво умею свою мысль донести. Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру, изменяемую или нет. Которую, да, предполагается хранить в этой же самой структуре, например.
>я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют
>Ты, очевидно, другого мнения
Как можно было придти к такому выводу? Я, вроде, сказал про "такое количество ограничений". Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
>Натуральный счетчик универсальней рекурсии?
Наверняка не скажу, но там и для структурной деконструкции тоже что-то имеется. Ну и взаиморекурсивные вызовы, аккерманы с фибоначами, всё в примерах и рассматривается. Это ли не универсальность?
До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
Я примерно понял о чём ты. Но тут-то наиболее важнен практический аспект: модель она на то и модель что позволяет абстрагироваться от несущественных в определённом контексте деталей. Не стоит же вопрос целиком весь мир эмулировать.
А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Заебали сопли по забору размазывать.
Вот вам ваш двусвязный список из стандратной либы: https://doc.rust-lang.org/src/alloc/linked_list.rs.html#46-51
Вот вам ваш двусвязный список из стандратной либы: https://doc.rust-lang.org/src/alloc/linked_list.rs.html#46-51
>Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок.
При чем тут это? Ты написал, что в си можно указатели на структуру передавать в процедуры и не бояться, что туда придет что-то другое, а в расте динамическая типизация. Я и отвечаю: вообще не ебу, о чем ты.
> Компилятор запрещает, кто же ещё.
Не запрещает. Берешь и передаешь.
> Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру
Ну, и ты выше писал, что в расте этих "конкретных объектов" нет, и тебе приходится пользоваться числами и строками. Я тебе еще 2 поста назад сказал, что в расте есть структуры, больше ничего не надо. Теперь выясняется, что ты структуры и имел в виду. Шта.
> Как можно было придти к такому выводу?
Да ты заебал:
>> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
> Ээ, расскажешь, как через афинные типы делать тоталити чек?
>> Тут я не матёрый дока нихуя, но что-то типа: ...
> Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
Ой блядь, ну и нахуя ты об этом тогда вообще пиздеть начал? Ой, все, иди нахуй.
> Это ли не универсальность?
Ну так ты не про универсальность как таковую говорил. Ты утверждал, что "Да и универсальней на мой взгляд". Теперь выясняется, что ты это опять просто от балды спизданул. Пиздос. Нахуй так жить.
> До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
linrec p o f g <=> h x: if p x then o x else g(h(f x)), как-то так. Соответственно, можно иметь разные комбинаторы для разных случаев (и даже с разными типами, в том числе и для unbound рекурсии), а "decreases n" хендлить на уровне обычной системы (зависимых) типов. Комбинаторы - joy, тотальность - charity, например.
И че?
Безопасность подаётся как основная фича языка. А тут, чтобы написать банальный связанный список, потребовалось три десятка раз её подавлять. Боюсь представить, что творится в ентерпрайз коде. Иными словами, основная идея раста разбивается при выходе в реальный мир.
Мудила, ты часто реализуешь низкоуровневые структуры данных в бизнес коде?
Один раз написал и пользуешься во всем проекте. А это вообще в std. Хуле тебе надо-то?
Ща бы думать, что мутабельный список вещь банальная.
Тут как раз отлично отделены безопасные вещи и используя этот список, ты всегда в безопасности.
Вопросы скорее к твоему коду и задумке, если тебе приходится делать unsafe вне библиотек.
Вот как приведённых тобой моих высказываний "могли бы сделать..." и "я не матёрый дока нихуя" можно вывести "ты через афинные типы собрался делать тоталити чек"? Пользуясь аффинной логикой, наверное.
Ну и:
>Да ты заебал
>Ой, все, иди нахуй
>Нахуй так жить
наконец-то пошла конструктивная риторика, сплошные опровержения в чистом виде. Ещё чуть-чуть и сможем воочию лицезреть как рождается истина, в муках выплёвываемая из уродливого влагалища спора. И тут либо я писать нормально не умею, либо ты - читать. Хуй с ним, будет желание, как поправишь нервишки, пересмотри ветку от начала, чтоб не драть почём зря фразы из контекста, а нет - да и в рот её ебать.
Ожидаемо. Я пробегаю глазами релевантные места по всему диалогу перед каждым своим ответом, а ты много пиздишь о том, в чем не шаришь, и идешь нахуй. Это интернеты, добро пожаловать снова.
>А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Абсолютно любая программа.
Чтобы оценить всю принципиальную, а не потенциальную, ограниченность и неполноту, достаточно написать любую сколь нибудь реальную программу, и дать ее юзерам.
Ненужно много теоретизировать, достаточно простейшей практики, блядь. Прости Господи, любому живому человеку, кроме женщин разве что, должно быть понятно, как работает мир. Достаточно в детстве достаточно близко с природой взаимодействовать, получать синяки и прочие травмы.
Любой мат аппарат описывающий реальный мир включает в себя понятие шума и ошибки.
"Шум" - это нечто, от чего нельзя избавится принципиально.
От чего все эти хасхели, и прочие безумные идеи относительно доказтельности вычислений - полнейший бред.
Если мы может доказать, валидность вычисления, то мы фактически УЖЕ его совершили, то есть нам никакая программа ненужна вовсе, все уже посчитано.
Более того, практическое мышление\работа\программирование, не требует доказательств. Можно потратить всю жизнь на выведение доказательств, поиска зависимости в дробной части числа Pi, а можно без задней мысли решать инженерные проблемы.
Ну хаскель-то как раз про вполне себе практичные вещи, хотя изначально для них и не предназначался.
мимо
Итак, самый важный вопрос: что самое сложное вы уже написали на расте? Показывайте гитхабики с писечками.
Хуль тут все кристал вспоминают? Рубисты что ли?
Кристал сдох уже совсем, увы.
>что самое сложное вы уже написали на расте?
хеллоу ворд
Сап, есть архив тредов?
Гудбай ворлд.
Решил к вам вкатиться и ставлю ентон самый раст. А чего у него такая инсталяха мелкая то?
Если ты про rustup то он тебе доставит нужную версию компилятора.
HALP
Сочувствую братишка, тут либо пердолинг с сертификатами (не факт что поможет) либо обход прокси сервера.
Двочь, покажи пример как захуярить на расте аналог горутин типа go someFunc()
Спасибо.
Спасибо.
Поищи либы, гороутины выпелили из базового раста.
В смысле green threads. Так эта шняга правильно называется.
>Двочь, покажи пример как захуярить на расте аналог горутин
https://tokio.rs
https://github.com/carllerche/mio
Хз, это уже 2 разных провайдера, падазритльна
Спасибо, пацаны, разобрался. Хотя и не так, как в го (там удобнее).
Еще такой момент, у меня есть одна libcore.c для встраиваемых устройств (С99). Но этот ебучий гугл по запросу `rust cffi example` подсовывает мне `calling rust from python` и подобное. Дайте, пожалуйста, пример или ссылку как вызвать из раста условный void hello(){printf("hello\n");}
Поясните, почему этот ваш раст гуглится вместе с идрисом, агдой? Он что с зависимыми типами?
Пример запроса в студию.
Код https://gist.github.com/c5c26a52a9b6d62a0806302e45336311
Compiling rs v0.1.0 (file:///tmp/rs)
warning: found Rust type `str` in foreign module; consider using a `*const libc::c_char`
--> src/main.rs:5:17
|
5 | fn hello(args: &str) -> i32;
| ^^^^
|
= note: #[warn(improper_ctypes)] on by default
error: linking with `cc` failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/tmp/rs/target/debug/deps/rs-9ef286ba19a0c06c.rs0.rcgu.o" "-o" "/tmp/rs/target/debug/deps/rs-9ef286ba19a0c06c" "/tmp/rs/target/debug/deps/rs-9ef286ba19a0c06c.crate.allocator.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs" "-L" "/tmp/rs/target/debug/deps" "-L" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-l" "libcore" "-Wl,-Bstatic" "/tmp/rs/target/debug/deps/liblibc-e31c38359b6db9f2.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-40464829c57274f9.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-f71e4223e340827c.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-d2f67529073eb9a2.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-f30681a605447f35.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_system-a2342e3a41ff3ba5.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-254494cfc0585fad.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-8af72a5c90e6873a.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd_unicode-ef9957a2dc058c2e.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-8a31a4b0f6e25305.rlib" "/home/user/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-9dad24fd34e0d61c.rlib" "-Wl,-Bdynamic" "-l" "util" "-l" "util" "-l" "dl" "-l" "rt" "-l" "pthread" "-l" "pthread" "-l" "gcc_s" "-l" "c" "-l" "m" "-l" "rt" "-l" "pthread" "-l" "util" "-l" "util"
= note: /usr/sbin/ld: cannot find -llibcore
collect2: ошибка: выполнение ld завершилось с кодом возврата 1
error: aborting due to previous error
error: Could not compile `rs`.
To learn more, run the command again with --verbose.
Ага, вкурил. А как мне -llibcore передать расту?
Спасибо
Ну и чем это лучше C?
Cpp -- общемировой стандарт с самым большим комьюнити, базой знаний, сумасшедшей кроссплатформенностью.
Зачем вообще плодить сущности, если они отличается какими-то там ссылками?
Гребаные гуманитарии, вон из профессии.
Давайте на ассемблере писать, зачем плодить сущности))00)
Но зачем придумывать точно такой же язык?
На ассемблере и пишут то, что нельзя написать на С.
На ассемблере нельзя писать переносимый код.
>Но зачем придумывать точно такой же язык?
Никто и не придумывает точно такой же язык. Просто ты либо тупенький, либо жирненький-зелененький.
>На ассемблере нельзя писать переносимый код.
А на си - типобезопасный, и что?
Иди тролли в другом месте.
Типобезопасность != без ошибок.
Зато такие языки всегда будут неэффективными=)
> такие языки всегда будут неэффективными
скажи это расту
А типобезопасность расслабит голову на 99%, оставив место для действительно важных вещей, логики например.
Потому что c++ тридцатилетний ворох костылей и замечательных решений.
Как сделать итератор по &T?
Всех с NLL, посаны: https://github.com/rust-lang/rust/pull/46862
[CODE]
#![feature(nll)]
fn main() {
let mut v = vec![1,2,3];
v.push(v[0]);
v.push(v.len());
}
[/CODE]
[CODE]
#![feature(nll)]
fn main() {
let mut v = vec![1,2,3];
v.push(v[0]);
v.push(v.len());
}
[/CODE]
Навскидку, если ты скомпилируешь что-то на языке Dafny, то оно заработает без косяков.
Навскидку, ты и Hello World не напишешь на Dafny. Лол, потому что НЕВОЗМОЖНО
10/10 как же охуенно то.
Как включить эту штуку глобально, чтобы не пихать в каждый файл?
Ок, завезли method Main, походу становится можно писать standalone applications.
> пикрелейтед
Просто у туземцев есть дигри по комплюктер сцайенс, так что параметрический полиморфизм они и называют параметрическим полиморфизмом, а инопланетных джава-макак делают вид, что не понимают.
Если бы это было так, цены бы туземцам не было. Но увы.
Это у промышленных макак называется параметрическим полиморфизмом, а в академии это статический полиморфизм.
Увы.
А вот и настоящий, риал-ворлд туземец подъехал, лол.
Статик — это C++ костыли, а оригинальный параметрический полиморфизм из ML 70-ых годов.
> Static polymorphism typically occurs in ad hoc polymorphism and parametric polymorphism, whereas dynamic polymorphism is usual for subtype polymorphism.
Почему ты настолько тупой, что даже текст по собственной ссылке прочитать не можешь?
Щас бы спорить с быдлом о дефинициях. Но давай, мне интересно посмотреть, как ты будешь вертеться, объясняя мне, где я не прав.
Но в ML вычисление параметризованного типа происходит точно так же как и специализация шаблона с крестах - во время компиляции, вот почему терминологически static polymorphism более удачен даже если не вспоминать про ad hoc полиморфизм - с тайпклассами или рабоче-крестьянски.
Он не имеет смысла, потому что это низкоуровневая деталь, а не суть, к тому же там все статик.
Как же вы заебали со своим нытьем. Уебывайте в хаскель тред нахуй.
>Различие языков по динамической и статической типизации не имеет смысла, это низкоуровневая деталь
Перечитай свои же посты. Потом иди sicp изучай.
Зарепортил за жирный троллинг тупостью.
Зачем нужен раст, когда есть пиздатый голенг?
1) гц
2) нет дженериков
Зачем ты назвал преимущества го?
Если в твоем случае это преимущества, то тебе раст не нужен.
>1) гц
в расте нет гц
Жирный, очевидно были приведены пункты которые в определенных ситуациях являются недостатками голенга.
>пределенных ситуациях являются недостатками голенга.
а, ну ок.
Бампусики.
Игори 2д делоть https://github.com/ggez/ggez
Асинк делоть https://tokio.rs/
Веб бекэнд делоть http://rocket.rs/
Орм делоть http://diesel.rs/
Веб фронтэнд делоть https://github.com/DenisKolodin/yew
Игори 2д делоть https://github.com/ggez/ggez
Асинк делоть https://tokio.rs/
Веб бекэнд делоть http://rocket.rs/
Орм делоть http://diesel.rs/
Веб фронтэнд делоть https://github.com/DenisKolodin/yew
> ORM
> Язык без какого-либо намека на ооп, с полностью функциональной системой типов.
Шо сказать то хотел?
> полностью функциональной системой типов.
Это как? Просвети. Бывают, значит, не полностью функциональные, а бывают совсем не функциональные, так? Накидай-ка примерчиков всех трех.
Функциональные в смысле те, что использующиеся в языках, традиционно называющихся функциональными.
То есть алгебраические типы данных с хаскеллевыми тайпклассами.
Ну и как это противоречит идеи ORM?
Да никак. Этот нахватался разных умных слов и пытается их комбинировать.
>Асинк делоть
ОТКРЫЛ ВКЛАДКУ https://tokio.rs
@
ПРИМЕР НА ИНДЕКСНОЙ
@
.unwrap();
@
.unwrap();
@
.UNWRAP();
@
ЗАКРЫЛ ВКЛАДКУ
Прикинь, программирование оно такое. Дохуя где могут быть ошибки.
Конечно try {} catch () {} наше все, да?
Получше чем
.похуй();
.похуй();
.забей();
Мань, ну че ты как маленький. В main пока нельзя пользоваться ?try!(). Поэтому в примерах юзают unwrap().
В настоящем коде это будет либо прокинуто наверх через ? либо expect()
охуеть
.похуй()
.похуй()
.забей()
.наБлядстве(пукнуть);
Ну если ты так пишешь код, то кто тебе в этом виноват?
Че? Что в этом плохого?
Зачем вы постите несмешное?
В определении ORM. Хотя сама библиотека адекватна и ORM можно упомянуть, чтобы хотя-бы пояснить назначение библиотеки (аналог ORM-ов из ваших ооп-языков)
А как по-твоему должен асинк работать? Поменяешь на andThen в продакшене и поедешь
Ну так в чем проблема-то?
> This creates, in effect, a "virtual object database" that can be used from within the programming language
Поясните, почему работает шляпа вида
r.map(|x| Some)
Я так понимаю возвращает Some(x) и Some что-то в виде функтора. Но как отличить Some(5) который блядь функция от Some(5) который вариант енама?
r.map(|x| Some)
Я так понимаю возвращает Some(x) и Some что-то в виде функтора. Но как отличить Some(5) который блядь функция от Some(5) который вариант енама?
Пример полноценный покажи.
Какой пример? Вопрос самодостаточен, можешь вообще читать только последние два предложения.
Вкратце, Стив Клабник мне ответил, что Some это есть функция, которая возвращает Option. А как тогда выглядит собственно сам Some, именно вариант, не функция? То есть let hueta = Some(5), какой тип у hueta? Просто Option<i32>? То есть я не могу просто так взять и без паттерн матчинга понять, что содержится в хуете.
Это касается так же и всех остальных енамов.
По ходу, это просто такое у них устройство на низком уровне.
Но все равно как-то мутно для меня это всё
Дык я об этом и говорю.
Если и обоих вариантов, иу Some, и у None общий тип - то выходит блядь простым смертным недоступно узнать разницу между ними на уровне имплементации самих енамов. Все что нам дают - возможность сравнивать и матчить. Я все правильно всосал?
В этом и заключается главный смысл.
Ты обязан тем или иным образом обработать разные варианты енума.
map точно так же внутри себя делает паттерн матчинг
match option {
Some(x) => f(x),
None => None,
}
На огороде бузина.
Ты ответил не совсем на то, о чем я спрашивал.
Ватевер, принцип я вкурил, а дальше буду адаптироваться.
Ну в общем случае енумы это tagged union
[tag, max(enum_variant)]
В случае Option используется NULL для None и указатель на данные иначе.
Ты путаешь конструктор типа и тип. Алсо, ты немного путаешь рантайм и компайлтайм.
Спросил в треде про Пщ, спрошу и здесь. Знатоки Rust, расскажите, пожалуйста, что в Rust есть хорошего, и что плохого.
Мне интересно мнение прошаренных людей, которые уже как следует изучили Rust и могут описать все или почти все его недостатки.
Основной недостаток - взрыв мозга при первой встрече с борроу-чекером и вообще писать, "как на других языках", не получается. Ну то есть, читай, порог вхождения высоковат.
Ох уж эти манямиры прыщеблядей.
Почему недостатоток? Это же киллер-фича, пересмотр сложившейся традиции построения ЯП.
Глупо конечно это отрицать. Но так же глупо отрицать то, что в это надо въехать. Хотя мне кажется многие через чур драматизируют по этому поводу, система владения в русте достаточно простая, раз в нее смогла за день въехать такая жс/го макака как я.
Да это те же пойнтеры, только компилятор с ними очень строгий: или кто-то один пишет, или все читают. По сути компилятор тебя и обучает.
Сидел, читал доки по Rust - на первый взгляд, такой толковый язык. Полез смотреть разные заказы/вакансии по нему - и почти нигде ничего.
Грустно.
Пока что Rust - это, похоже, язык-мем.
Грустно.
Пока что Rust - это, похоже, язык-мем.
Для каких задач раст хорошо подходит, а для каких его лучше не использовать?
Для задач где го недостаточно выразительный, всякие джавы/сисярпы/хаскели медленные и прожорливые, с/с++ недостаточно простые и безопасные.
Расскажи примеры таких задач, анон, плз.
Скажем делаешь ты игру. У игры есть очень четкое требование — успевать всю хуйню сделать за 16мс, чтобы ты получил свои 60фпс. А голанг может тебе хуйню сборку мусора на 10мс.
Плюс рано или позно тебя заебет копипастить слайс-трикс и код в целом, потому что нет дженериков.
Переписали на нем с джавы софтину, которая 24/365 крутилась на cortex-a5 256mb ram. Теперь переписываем с C код для cortex-m4 128kb sram.
Сначала было непросто понять, что хочет компилятор и борроу-чекер, теперь придрочились. Во втором случае еще и с сетапом/инициализацией пришлось повозиться (то что пилит japaric нам не подошло).
Еще можешь глянуть Макса Лапшина на highload++, он для камер на ARMv5 пилит чото.
И как тебе раст после сишки?
Дело в дженериках и gc?
Еще дело в более выразительной системе типов и возможности писать безопасный многопоточный код.
Каналы и горутины это конечно хорошо, но они ни капли не спасают от того что рантайм го может тебе крашануть приложение из-за небезопасного доступа к map.
Т.е. Rust лучше Go?
В многих аспектах да.
За это приходится платишь более высокой сложностью вкатывания, более медленной компиляцией и пока что меньшим размером коммьюнити. Впрочем, раст моложе и вангую что через 3-5 лет он будет так же популярен как и го в своей нише.
Знать бы ещё что эта хуета делает.
Эта хуета показывает что го никак тебя не защищает от проблем многопоточного кода. В данном случае я спокойно могу иметь несколько ссылок на хэш-таблицу и модифицировать её в разных тредах, при этом закономерно получая фатальную ошибку которая никак не ловится.
В том то и проблема го, что многие го программисты(читай бывшие скриптомакаки) не понимают, что этот код работает не правило и такого не должно быть.
Почему проблема? Это заявленная фича. Скриптомакакам должно быть легко вкатываться и индусить код во блага хозяина.
Котоны нубасы, чего вам не хватает для того чтобы вкатится в раст?
Стандарта или хотя бы кс-грамматики.
Нахуя тебе стандарт?
Предлагаешь читать очередную воду для вкатывальщиков?
Возьми programming rust. Воды очень мало и вообще очень хорошая книжка.
>programming rust
Pages: 622
Да, там пол книжки про стандартную либу и как с её помощью решать задачи. При этом написано хорошо, а не в стиле референса.
Ну что ж, посмотрю. Вообще я поковырял палкой их справку, довольно интересный яп.
Можешь начать с оф. книжки. Она короткая и по делу.
Работы.
Ну во первых вакансии уже появляются. А во вторых, хочешь работы, учи пхп.
Я джавист, и с джавы переписывать сложно только те части, где наследование и рефлексия.
Парни которые могут в сишку сказали, что есть некоторые сложности с хардкорной байтоеблей, поначалу тупо все в unsafe пихали а потом его минимизировали. Сейчас ансейф только там где риальне нужен (регистры там, dma всякое и обертки над сторонними либами), остальное проверяется борроу-чекером.
Появляются. Но берут только сеньеров с опытом. Иногда мидлов.
А ты как хотел-то? Если хочешь чтобы тебя учили, выбирай го.
Я выбрал жс.
Спасибо конечно, но мне нужно сначала с синтаксисом разобраться.
а какой в этом смысл? зачем писать на расте то что можно написать на жс?
мимо
Если в результате свой деятельности ты приходишь к выводу, что жс не лучший выбор. Например, ты можешь прийти к заключению, что типизация помогает решать множество проблем, ценой небольших ограничений.
Затем если ты уже используешь rust на бекэнде (см. diesel.rs), то вполне возможно, что фронтэнд на расте может быть вполне себе неплохой идеей. В конце концов гугловцы уже давным давно так делают с жавой.
typescript
> Затем если ты уже используешь rust на бекэнде...
Типизация не нужна.
> Например, ты можешь прийти к заключению,
Если она тебе ну нужна, что ты вообще делаешь в расто-треде тогда?
Ебу твою мамашу.
Типичная жс макака.
Ты просто завидуешь.
>Если хочешь чтобы тебя учили, выбирай го.
Тогда зачем rust? В чем от него профит?
> zero-cost abstractions
> move semantics
> guaranteed memory safety
> threads without data races
> trait-based generics
> pattern matching
> type inference
> minimal runtime
> efficient C bindings
Всего этого нет в го.
А я вот пару недель назад начал вкатываться в Го, и меня настигло осознание, что программки с Gui на нём не напишешь. На ruste можно программки писать с окошками и кнопочками под винду?
С чего бы не напишешь-то? Берешь биндинг к любому тулкиту и пишешь. С растом то же самое. Все делается через биндинги к тулкитам. Ну или можешь винапи заюзать, но только нахуя?
О, спасиб. Действительно всё есть
https://github.com/cyndis/qmlrs
https://github.com/therecipe/qt
Просто петушня и го-треде сказала, что нет.
Таки раст смог ворваться в бастион асинхронных http богов
https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext
https://www.techempower.com/benchmarks/#section=data-r15&hw=ph&test=plaintext
Rust 1.24. В стейбл завезли инкрементную сборку и rustfmt.
https://www.youtube.com/watch?v=rTo2u13lVcQ
10/10 ржака
10/10 ржака
Монолог под вставку смешных картинок.
Конференции по программированию, которое мы заслужили.
Я прям слышу смех всех этих "системных программистов", "инженеров", людей высокого полета (уровень разработки, где мне круд-макаке никогда не бывать) и у меня прям стыд какой-то берет. Это сейчас такой новый уровень? Куда делись те самые нудные бородочи из моей юности, которые бы не стали смеяться над пару строк кода с какого-то подобия пазлера и рандомных картинок?
>Куда делись те самые нудные бородочи из моей юности
В основном на пенсию. Некоторые продолжают ебать байты на сях в мокрософтах и редхатах, некоторые в эмбеде микроконтроллеры для новых стиралок electrolux ебут. Некоторые для автомобилей программы ЭБУ пишут уже нет: https://www.drive2.ru/b/466174514431001350/
В целом все системное по уже написано и нового никто не пишет, лишь сопровождают и дополняют новыми фичами.
>Некоторые для автомобилей программы ЭБУ пишут уже нет: https://www.drive2.ru/b/466174514431001350/
Заебись, еще один аргументик в сторону смерти кодерков. Алсо, буду теперь байтоблядей этой ссылкой траллить.
Хуле вы разнылись. Охуенно же, когда полезные вещи с юморком подают. Это намного пизже, чем слушать жующего говно дауна.
>буду теперь байтоблядей этой ссылкой траллить
Ты б хоть почитал для начала. Этой ссылкой можно траллить разве что сервисы компьютерной диагностики двигателей.
Хорошо рассказывает, только большую часть шуток я не понимаю, по крайней мере с чего ржёт зал.
В основном с того, что понимают боль, которую описывает спикер.
> За это отвечают сложные модели. Например одна из сложнейших и важнейших ее подсистем “модель температуры выпускных газов”. Именно она отвечает за механизмы ограничения мощности и дает опорные значения в механизмы обогащения состава для защиты компонентов. И эта модель в современных ЭБУ чрезвычайно сложна – она производит больше вычислений и имеет больше калибровочных данных, чем например весь мотек м800 во всех своих алгоритмах в принципе. Ее описание занимает 82 страницы мелкого текста. Сама она написана не людьми — исходный текст функции транслирован с ASCETа. Но это не значит, что все ее алгоритмы заданны прямыми физическими константами и формулами из физики – там все еще огромное количество эвристики. Огромное количество сложно формализуемых подгонов под ответ, для производителя это не представляет каких то проблем, поскольку одни и те же люди годами занимаются только ей, и они знают в ней все – как таковые задачи формализации там не стоят. Это даже не инженеры и не программисты — это прикладники с глубоким знанием термодинамики
Вычислительные мощности и сложность систем управления постоянно растут. Хотя и исходя из общей тормознутости процесса эволюции электронных компонентов для автомобильной промышленности они делают это очень медленно, существует точка, когда пространство знаний о системе необходимое для ее настройки, начинает превышать возможности одного человеческого индивидуума * на время его жизни. Т.е. если скажем раньше у вас была система с объемом кода 32кб и за 2 месяца вы могли порезать ее в лапшу, и при наличии нужных инструментов и знаний сделать из этой лапши вполне себе удобоваримое блюдо. То вам не хватит и года, чтоб сделать то же самое с системой где объем кода 1мб – а это не современная система. Это система 15-ти летней давности. Что уж говорить о современных. Я пока вот не написал тут и 2-х страниц текста – а описание современной системы управления — 20 тысяч таких страниц. Мы давно уже пришли к тому, что современная система управления принципиально непознаваема в целом на уровне одного человека. Т.е. в мире просто нет ни одного человека, способного реализовать конечную задачу настройки такой системы в целом – это способен делать только лишь коллектив из специалистов, причем каждый должен быть специалистом именно в своей области и решать задачу настройки только для своей части вверенных ему алгоритмов.
Алё, они там реверсят бинарники прошивок чтобы накручивать движки как захочется. Причём здесь обычная разработка софта из исходников? Неужели система впрыска бензина это блеать 20к страниц текста? Мне кажется производители довыёбываются, и в ход пойдёт какой-нибудь опенсорцный контроллер с открытыми исходниками. Единственное что сейчас этому препятствует это большое разнообразие моделей авто.
>кажется производители довыёбываются, и в ход пойдёт какой-нибудь опенсорцный контроллер с открытыми исходниками. Единственное что сейчас этому препятствует это большое разнообразие моделей авто.
О, тут вот как раз Maxi подобных кодерков разъебывает:
https://rusefi.com/forum/viewtopic.php?f=8&t=1012&start=30
Чёт там неясно ещё кто кого разъёбывает. Обычный жир и разговор слепого с глухим.
У кого пердак горит, того и разъебывают.
>Алё, они там реверсят бинарники прошивок чтобы накручивать движки как захочется
Так речь о том, что хуй они там чего отреверсят и поймут, потому что современные алгоритмы управления двигателем - это хуйпойми какое автогенеренное говно с разными физматмоделями и прочей нечеткологикой. И привычных для говнотюнеров табличек "уоз" и "цикловое наполнение" которые можно крутить там нет -все на алгоритмах и сотнях параметров.
Ну макси, конечно, тот еще жирный тролль, который промышляет быдлосборочками на январь 5 из пизженых исходников серийных прошивок, но тут он прав - кодерки без соответствующей теоретической базы по собственным представлениям и максимум - даташитам изобретают уже десятый по счету велосипед 80-х годов, когда весь мир уже в 21 веке.
Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят? Ну нарушат нахуй никому ненужные экологические нормы, ну придётся каждый раз подкручивать, так как контроллер уже не самообучается на собранных с датчиков данных. Но ведь можно наваливать! Не ради этого ли всё?
>Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят? Ну нарушат нахуй никому ненужные экологические нормы, ну придётся каждый раз подкручивать, так как контроллер уже не самообучается на собранных с датчиков данных. Но ведь можно наваливать! Не ради этого ли всё?
В том то и дело, что нихуя у них толком не работает нормально:
https://rusefi.com/forum/viewforum.php?f=15
Они даже универсальный обработчик дпкв (это который шкив с зубьями у которого один зуб пропущен и магнитный датчик читает эти зубья-впадины, определяя таким образом угол поворота коленвала) не осилили и в сорцах у них вот такой вот пиздец:
https://github.com/rusefi/rusefi/tree/master/firmware/controllers/trigger/decoders
А детонацию они и вовсе не осилили, даже применив специализированную микросхему.
Да и сам код в принципе тоже охуенен - си с примесью плюсов в стиле си-с-классами, макролапша везде, зато гордо заявляют что не используют периферию микроконтроллера и с гордостью хуярят оверхеднутый код на програмных прерываниях и счетчике в цикле программы поверх ChibiOS. из-за чего у них в проекте ебический микроконтроллер STM32F469, который не реализует и доли функционала восьмибитного c509 из январей, у которого и периферия, и производительность в разы меньше.
>Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят?
А, ты про тюхнеров серийных блоков с модельным принципом - нет, нихуя у них не работает - максимум на что хватает им мозгов - это сбросить параметры самообучения и зашить начальные карты (и то, это для отностительно старых мозгов, где еще присутсвовали начальные калибровки по-калькуляторному), после чего лох, отваливший им деньги пол дня наваливает, после чего прошивка свои калибровки восстанавливает и его тачка снова превращается в овощ, а если он её еще и затюнил - впуск/выпуск/турбина, то она вообще встает на прикол, потому что мозг от таких раскладов охуевает и отказывается крутить мотор, высветив чек. Туо потому что в ней нет таблиц калибровок, а НЕХ, в виде сотен выведенных матмоделей, пид-регуляторов и прочих нечетких логик, которые даже не людьми писались, а генерились машиной на основании данных от инженегров, проектировавших конретный двигатель и конкретный код затем еще и автоматически оптимизировался и дописывался машиной при доводке образца двигателя на диностенде. Ну типа как нейросеть обучают, только на выходе - код.
Поэтому для тюнинха вырезают штатный блок, переделывают проводку и ставят древнее говнецо вроде пресловутых 5-7 январей, у которых прошивка по принципу "калькулятор на фиксированных таблицах", или блоки вроде мотека и аема, которые суть те же калькуляторы.
Чем он лучше плюсов?
→
>Чем он лучше плюсов?
Способствует зарождение стендапа в ИТ.
Конечно, взять старый язык и ржать над недостатками, это реально потолок интеллекта. Хотя если ты полез в системное программирование тебе так или иначе придется дружит с плюсами, с си и даже с ассемблером, чего смешного? Неужели непонятно что технологии идут и трудно новые парадигмы натунять на старый синтаксис не сломав все? В чем тут забава, это как смеяться над старой машиной и в противовес современной, которая была создана чтобы победить ту самую машину (кажется глупым это да? Но это тоже самое)??
Мол смотрите, мы делали язык убирающий недостатки С++ и смотрите у нас получилось - ну обосаца.
Я бы лучше послушал конфу о подводных камнях раста, что там может ждать и как это решать, чем конфу со смешными картинками, где в очередной раз побеждают динозавров индустрии, очередным поделием над llvm.
Это, имхо, уровень какого-то javascript (у меня не бомбит, не пофиг на С++, но просто где С++ а где раст, зачем они настраивают огромное комьюнити С++ против себя же?)
>у меня не бомбит
>А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.
Экономика сейчас такая что шахтеры и педиатры нахуй никому ненужны, хочешь выжить умей крутится.
>Избежать ошибок можно только одним способом - не быть криворуким дауном.
Чтобы избежать ошибок нужен идеальный образец, а где ты его найдешь? Чтобы сделать скульптуру бабы тебе нужна баба которая будет позировать, без нее будет НЕХ.
>Тред убийцы c++.
А ну ка скинте тесты скорости сортировки и поиска на с++ и расте?
Когда у Мозиллы закончатся деньги из-за доминирования хромобраузеров, то кто будет оплачивать разработку этого языка?
Связь в позиционировании как убийцы си.
Платов даст $250/мес.
Из языков знаю только русский, этого достаточно чтобы задрочить rust?
Нет. Надо английский.
Это не сортировка и не поиск и половине тестов он проигрывает, да и еще больше памяти потребляет. Убийца, мда...
Если тебе нужно рационализировать почему тебе не нужен раст и почему C++ лучше/быстрее/надёжнее, то можешь просто вспомнить, что в России работы на расте не будет ближайшие N лет.
Начнем с того, что это пиздеж. Работа уже есть.
Плюс, тебе никто не запрещает продвигать использование раста внутри компании. Другой вопрос, если ты безыдейное чмо. Тогда жри что дают и не выебывайся.
А что если я не хочу пилить блядские НаёбаКойны, вот просто из принципа?
Растики-пидорастики думают, что ихнее никомуненужно когда-то взлетит.
Топ кек!
Топ кек!
Ну тогда становись начальником и впихивай раст сам.
Либо не еби мозг, пользуйся в личных целях, или для реализации того, на что благословение начальство ненужно (тулинг, утилиты, ...). Через пару лет вакансий однозначно будет больше.
Сначала Борщ, теперь ПидоРаст.
Что же будет следующим хитом у сыночков-корзиночек?
Что же будет следующим хитом у сыночков-корзиночек?
То, что решает задачу лучше старого инструмента.
Надеюсь ты ездишь на Ваз 2101, пользуешься холодильником "Зил" и ходишь в ватнике. Ведь будет непоследовательно пользоваться по жизни более совершенными вещами, оставаясь замшелым старпероуебком.
>пиздеж. Работа уже есть
>становись начальником и впихивай
>пользуйся в личных целях
>Через пару лет вакансий
Ты определись сначала со своей точкой зрения.
Я со своей определился. Работа есть.
Человек сказал что
> А что если я не хочу пилить блядские НаёбаКойны, вот просто из принципа?
Раз человек хочет остаться в рашке, но при этом не заниматься наебакойнами, вариантов не так и много.
Но ведь Раст не решает. Его обещали как идентичную по производительности замену, а этого не произошло.
Кто обещал? Где ты видишь про "идентичную производительность"?
>runs blazingly fast
Чем производительность не идентична? Те же машинные типы с теми же граблями.
"Работает охуенно быстро" != "производительность идентичная $хyuta"
При условии возраста компилятора производительность вполне неплохая и будет становится только лучше.
Лично для меня главные фичи расте это безопасность и выразительность.
>То, что решает задачу лучше старого инструмента.
>Надеюсь ты ездишь на Ваз 2101, пользуешься холодильником "Зил" и ходишь в ватнике. Ведь будет непоследовательно пользоваться по жизни более совершенными вещами, оставаясь замшелым старпероуебком.
Если проводить аналогию, вместо ваза тебе предлагают бээмвэ с кожаными креслами, но мотором от скутера в 100 кубиков, который жрет по 1000 литров бензина на 100км, а на вопрос "а чо не едет-то?" начинают втирать, что скорость нинужна, динамика нинужна, у нас экология и вообще - у всех приличных людей маршруты до магазина и от дома рядом с работой, а на лишний бензин у всех деньги есть.
Но в плане автомобилей в реальности сложилось все иначе - автомобили стали быстрее, комфортнее, и экономичнее (с ресурсом только вот шляпа в 2000х пошла).
Языки же программирования развились так, что программисты отупели и школьник-за-отзiв, нахватавшийся по верхам всех фреймворков стал вместо нелепости и источника петросянских шуток на башорке полноправным участником рынка труда, программы по прежнему имеют те же функции что и в 80х-90х, но жрут больше памяти и требуют в миллион раз более быстрых процессоров и умудряются при этом тормозить.
В 80-90х само разнообразие программ, аппаратные возможности, возможности ОС, внешний вид, дизайн, юзабилити — всё это было крайне скудным. Всё разрабатывалось под железо, как ты любишь, большинство этого софта не дожило до сегодняшнего дня, так как оно всё негибкое, его проще сделать заново чем приспособить под новые реалии, в нём нет ни апи, ни скриптинга, ничего, тупо exe и фиксированный гуй.
Никакие школьники софт серьёзнее бота в телеграм или простой игры никогда не разрабатывали и не будут.
Какое-то убогое старперское мышление, с отрицанием очевидных фактов.
Просто открой любой сайт из 2000ых и любой современный сайт. Чуешь разницу? Или сравни турбо-дельфи и современных монстров из мира иде.
Ты можешь классно ехать на своей копейке, правда придется постоянно боятся того, что она тебе щас глушак в жопу вставит.
Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка. Стоимость и скорость разработки чаще важнее. Надежность полученного решения тоже часто важнее скорости.
Обычно, скорость реально важна в одном небольшом участке. И у раста есть все инструменты для того чтобы оптимизировать то, что важно.
>Просто открой любой сайт из 2000ых и любой современный сайт.
Весит 100500 гб, тормозит на пекарнях 3-4 летней давности, куча аякса и свистелкоперделок, иформации - столько же.
> Или сравни турбо-дельфи и современных монстров из мира иде.
В старых хотя бы было было формошлепство и куча визардов, тогда действительно пилили инструменты для RAD, кое было не пустым звуком, современные монстры из мира IDE - это просто жрущие процессор и память блокноты. И вижалстудия и идея нынче - это сраные блокноты, зато с кучей фреймворков и прочей скриптопитушни, которую все равно надо хуячить руками. В ебаном делфи быстрее приложения разрабатывать, чем сейчас - нахуярь кучу конфигурационных файлов, внедри в систему сборки менеджер пакетов из интернета (экскаватор - и привет, работа встала, фреймворки не скачать, в го вообще пизданулись - внедрили в стандартязыка ссылки на гитхаб), нахуячь все руками с использованием сотен фреймворков.
> Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка.
Оно и видно.
> Стоимость и скорость разработки чаще важнее.
И на выходе тормознутое говно и "64 гб corei5 хватит для запуска хеллоуворлда, а 128гб+corei7 - для запуска простого калькулятора - для инженерного нужен уже core i9 в разгоне или сервак с последними зионами".
> Надежность полученного решения тоже часто важнее скорости.
Угу, падение по причине Out-Of-Memory сюда же. Куча уязвимостей в скриптопараше - туда же. Вечный статус "бета" у большинства скриптопитушиных тулзов и постоянное ломание API и стандарта языка (привет, педон) - туда же.
Весит 100500 гб, тормозит на пекарнях 3-4 летней давности, куча аякса и свистелкоперделок, иформации - столько же.
> Или сравни турбо-дельфи и современных монстров из мира иде.
В старых хотя бы было было формошлепство и куча визардов, тогда действительно пилили инструменты для RAD, кое было не пустым звуком, современные монстры из мира IDE - это просто жрущие процессор и память блокноты. И вижалстудия и идея нынче - это сраные блокноты, зато с кучей фреймворков и прочей скриптопитушни, которую все равно надо хуячить руками. В ебаном делфи быстрее приложения разрабатывать, чем сейчас - нахуярь кучу конфигурационных файлов, внедри в систему сборки менеджер пакетов из интернета (экскаватор - и привет, работа встала, фреймворки не скачать, в го вообще пизданулись - внедрили в стандартязыка ссылки на гитхаб), нахуячь все руками с использованием сотен фреймворков.
> Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка.
Оно и видно.
> Стоимость и скорость разработки чаще важнее.
И на выходе тормознутое говно и "64 гб corei5 хватит для запуска хеллоуворлда, а 128гб+corei7 - для запуска простого калькулятора - для инженерного нужен уже core i9 в разгоне или сервак с последними зионами".
> Надежность полученного решения тоже часто важнее скорости.
Угу, падение по причине Out-Of-Memory сюда же. Куча уязвимостей в скриптопараше - туда же. Вечный статус "бета" у большинства скриптопитушиных тулзов и постоянное ломание API и стандарта языка (привет, педон) - туда же.
>Обычно, скорость реально важна в одном небольшом участке.
Обычно - тормоза складываются из синергии - там небольшой просос на абстракциях - тут гарбадж коллектор тупанул, там код криво отджитился, зддесь компилятор тупанул и все - пизда, калькулятор обычный с требованиями "i5+64GB ram".
Ну дык реалии таковы, что в конкурентной борьбе побеждает быстрейший, а не тот, кто дрочил на сях, как деды.
То же самое относится к сям. Тут маллок затупил, здесь на отъебись сделали лишь бы работало. Ой сегфолт. Извините.
>Ну дык реалии таковы, что в конкурентной борьбе побеждает быстрейший
Пока что в конкурентной борьбе победила посредственность и глобальное понижения качества как программистов так и конечного продукта.
> кто дрочил на сях, как деды
Вот стараются диды, стараются, платформы для ваших говноязыков пидорят, что бы ваша параша хоть как-то работала толком, а вы тут хипстоту-отрицал из себя корчите, помрут вот диды, некому будет для вашей параши JVM и прочие LLVM и V8 писать а диды из интела уже нисмогут очередное поколение процессоров вам выдать и все - пизда вам котятки.
У тебя какие-то комплексы. Любая индустрия проходит через этап когда в ней ебется только "илитка", а потом приходят казуалы. Вот только нормальные люди не рефлексируют на тему.
Люди как раз и придумывают альтернативы дедовским методам.
Если почитать /hw/, то в общем-то диды уже своё дело сделали по большому счёту. Там если убрать бонусы от новых техпроцессов ускорение самой архитектуры с каждым поколением порядка 5%. И такое продолжается уже почти 10 лет.
Алсо, взять питон, руби, там например не могут отрезать GIL по 20 лет. Ваши хвалёные диды.
Я видел как перезапиливают большой проект на плюсах. Дидовский код тысячами строк сносится как неактуальный/устаревший/ненужный. Новые плюсы это уже по сути другой язык и писать на нём нужно совершенно иначе. Алсо, дидов в проекте не было, сплошной молодняк, очень толковые ребята с охуенным знанием modern c++. И вот кстати раст они очень котируют. Один из них даже контрибьютит и в раст, и в llvm.
Короче я вот что скажу. Пиздёж это всё что раньше ничего не тормозило. Что диды такие охуенно незаменимые и что все отупели. То что вы там где-то установили IDE с тысячей плагинов от тысячи разных людей — это всё исключительно ваши проблемы.
>Любая индустрия проходит через этап когда в ней ебется только "илитка", а потом приходят казуалы.
Тащемта, наоборот (опустив изначальный этап - военные компании на охулиард денег исследуют кучу всего, что поом попадает к простым быдлам), - сначала хипстеры залетают на рынок, потом их медленно и печально сжирает крупняк, так было и с авиацией, и с автомобилями и из недавнего - с пекарнями. И остается илитка.
> Люди как раз и придумывают альтернативы дедовским методам.
Придумывали - средства разработки 90х соревновались друг с другом дабы убрать ручной пердолинг, при этом все работало быстро. В 2000х заменили на петушение конфигов и написание кода руками в емаксе, конфигурацию проекта через командную строку ключами, как раз как у дидов из 70х-80х.
Не на том уровне абстракции думаешь.
"Илитка" владеет толпой казуалов.
Ну почему рынок иде для рисования кода провалился, есть мысли?
>Ну почему рынок иде для рисования кода провалился, есть мысли?
Потому что в моду вошли те самые "дидовские технологии" из юникса 70х, причем в плохом смысле этого слова. Под лозунгом "жму швабодка консоль зато бисплатна".
И хипстопетушня это успшно схавала, теперь, как и диды времен доса, приписывает пути, пердолит консольку и думает "ну я то быстрее дидов из 90х теперь код пишу".
Окститесь, дебилы, вы взяли у "дидов" самое худшее - то самое говно мамонта в качестве инструментов, только более тормознутое, и теперь кичитесь "ну мы-то саврименнее дидов". Нет, вы по второму разу жрете уже схаванное и высранное дидами говно. Только вот диды осознали это и в 90х родили RAD, удобные отладчики, генераторы кода. Вы же програмимируете в блокнотах, пишите дополнительно к коду кучу конфигов и билдскриптов (у дидов достаточно было нажать F5 и единственное что нужно было прописывать - это пути до новых хедеров/либок)
Ты упускаешь один момент. Чтобы что-то собрать теперь не нужна IDE (лично мне такое охуенно пригождалось много раз, и ни разу импортирование в IDE не проходило как надо, зато из консольки собиралось на раз-два). И сборку теперь часто делает облако, куда в принципе IDE не накатишь.
Программирование в блокнотах это фича. Программирование вообще не должно содержать в себе машинную работу. Меньше кода — правильнее сделан ЯП. Кодогенерация это тот ещё пердолинг.
Хуйня какая-то. Я бы с удовольствием перекатился на инструмент, который решает за меня ебаные задачи. Но таких инструментов тупо нет. Может только блюпринты в игровых движках.
>ы же програмимируете в блокнотах, пишите дополнительно к коду кучу конфигов и билдскриптов
Какие-то маняпроекции. Если ты пишешь в блокноте - то это твои личные проблемы. Сабж-то тут при чем?
Вообще звучит как школьник, который не может осилить сосноль.
Только шизик в го-треде затих - как вот это тут вылезло. Кошмар.
Только ты у нас умница, носишься по тредам со своим детектором, ловя какого-то выдуманного шизика (когда на самом деле шизик это ты).
Что по расту - печаль. Печаль когда язык, созданный побеждать С++, по производительности и потреблению ресурсов "не хуже" чем С++.
Понятно, что производительность это вообще главная фича С/С++ иначе все давно писали бы на джавах или питонах. Но мне просто интересно, что там в расте так жрет и тормозит? Просто, я к чему, если окунуться в раст, то везде слышно про нулевую стоимость и всякие вундер-слова, но на деле все не так. Помню, самое забавное, когда раст за-релизили, на том сайте (с говно тестами) он был на уроне java (чуть быстрее), а ОЗУ жрал почти на ровне. Я, конечно понимаю, те бенчмарки это то еще подкрученное чудо , но выглядело забавно.
Второй вопрос, почему стремятся сделать языки максимально не похожими на си, но хотят чтобы он си при этом победил? Если раньше, все просто копипастили синтаксис си и это являлось успехом, то каким местом текущие поколение поняло - что надо максимально делать не комфортным перекат между языков? Ладно, вам повезло и вы кодите на одном языке, но это же не так, вам приходится переключать между языками и привычка одного сразу же начинает проявляться в другом языке (и наоборот)?
Я не беру в расчет тех людей, которые играют в языки, я именно про каждодневную работу, одна только позиция типов может вынести мозг, когда снова переключаешься.
>Только ты у нас умница, носишься по тредам со своим детектором, ловя какого-то выдуманного шизика
Чего блядь?
Высер твой не читал, разумеется.
>Чего блядь?
(когда на самом деле шизик это ты)
Шизик, угомонись
http://c-faq.com/decl/spiral.anderson.html
Почитай, например, "Дизайн и эволюция С++" где сам Страуструп говорит от том, что он бы и сделал по человечески (как в паскале), но без совместимости с си нихуя не взлетело бы.
"Раст не хуже C++" потому что сравнивается g++ и llvm. Если сравнивать clang и rust, то будет паритет.
Но ведь C++ не совместим с C.
В то время корректная си программа == с++ программа.
Народ, поясните, как сделать safe обертку над c_void? Все, что находил - про указатели на функции. Вот пример - fn glBufferData(target: GLenum, size: GLsizeiptr, data: const GLvoid, usage: GLenum). Что вместо data передавать в обертке?
И вообще, что за хуйня тут у вас с постингом? Я с Вьетнама, не могу ничего писать, приходится через прокси заходить? При этом именно с рашкованского?
Блять, еще и указатель(звездочка) пропадает!
Наверное не так выразился - как передать что-то, либо null pointer? Понимаю, что надо как-то юзать Option, но как? За Растом третий день, нравится, сука)))
А расте принципиально нет null пойнтеров. Я уже плохо помню опенгл, там точно есть случай как в data нужно null передать? Тогда или option, или отдельную функцию сделать, без параметра data.
>там точно есть случай как в data нужно null передать?
Там такое на каждом шагу. Там еще есть эпичный
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glVertexAttribPointer.xhtml
Ну и да, вот почему никто не умеет гуглить?
https://stackoverflow.com/questions/24191249/working-with-c-void-in-an-ffi
> pointer
> Specifies a offset of the first component of the first generic vertex attribute in the array
> glVertexAttribPointer(0, 3, GL_FLOAT, GL_FALSE, 3 ✶ sizeof(float), (void✶)0);
Бля, я даже сначала не поверил.
Null пойнтеры есть: https://doc.rust-lang.org/1.22.1/std/ptr/fn.null.html
>Бля, я даже сначала не поверил.
А чего, решили просто не изобретать велосипед, в старом опенгл (который под видюхи первого поколения, которые еще даже без t&L были и где геометрия софтово считалась) была уже функция с подходящими параметрами, вот и изменили смысл одного параметра - теперь это не пойнтер на реальные вершины в RAM, а оффсет в BufferObject(который теперь и в VRAM может быть).
Спасибо за попытку помочь, но это немного не то. Хочется сырые указатели спрятать в обертку, а передавать что-то типа Option. Сделал пока так, но это же оверхед:
pub fn shader_source(shader: GLuint, count: GLsizei, string: &str, length: Option<&[GLint]>) {
unsafe {
glShaderSource(shader, count, &CString::new(string).unwrap().as_ptr(),
if let Some(v) = length { v.as_ptr() } else { ptr::null() })
}
}
Просто C функции callback принимают в Option, и None воспринимаются как null. Не могу сообразить, можно ли и как сделать это с другими типами.
Только разыменовывать их можно только в unsafe коде.
Это понятно, но unsafe можно спрятать в обертку, в которую передавать ссылку на что-то. Но что делать, когда это "что-то" может быть null?
Например, ссылки на callback функции передаются так:
fn glfwSetKeyCallback(window: *const GLFWwindow, cbfun: Option<GLFWkeyfun>) -> Option<GLFWkeyfun>;
Если поставить вместо Option<GLFWkeyfun> None - передастся null, и преобразовывать ничего не нужно.
Кажется придумал:
fn glShaderSource(shader: GLuint, count: GLsizei, string: const const GLchar, length: Option<&c_void>);
- вроде как работает! Или какие-то косяки есть и можно лучше?
fn glShaderSource(shader: GLuint, count: GLsizei, string: const const GLchar, length: Option<&c_void>);
- вроде как работает! Или какие-то косяки есть и можно лучше?
Обертка теперь так выглядит:
pub fn shader_source(shader: GLuint, count: GLsizei, string: &str, length: Option<&c_void>) {
unsafe {
glShaderSource(shader, count, &CString::new(string).unwrap().as_ptr(), length)
}
}
pub fn shader_source(shader: GLuint, count: GLsizei, string: &str, length: Option<&c_void>) {
unsafe {
glShaderSource(shader, count, &CString::new(string).unwrap().as_ptr(), length)
}
}
Только как теперь, млять, ему безопасно массив длин в Some передать? Что-то не то все равно.
Млять, там же еще и двойной указатель на GLchar! Значит надо массив str еще как-то преобразовывать в массив CString, а потом в указатель!
> Млять, там же еще и двойной указатель на GLchar! Значит надо массив str еще как-то преобразовывать в массив CString, а потом в указатель!
https://github.com/gfx-rs/gfx/blob/b7d88cadc890474d161940ac8f78c1dfbe33b65b/src/backend/gl/src/info.rs#L115
let extensions = if version >= Version::new(3, 0, None, "") {
let num_exts = get_usize(gl, gl::NUM_EXTENSIONS) as gl::types::GLuint;
(0..num_exts)
.map(|i| unsafe { c_str_as_static_str(gl.GetStringi(gl::EXTENSIONS, i) as ✶const i8) })
.collect()
Не, это наоборот.
Уже нашел тут: https://github.com/servo/rust-opengles/blob/master/src/gl2.rs
pub fn shader_source(shader: GLuint, strings: &[&[u8]]) {
let pointers: Vec<const u8> = strings.iter().map(|string| (string).as_ptr()).collect();
let lengths: Vec<GLint> = strings.iter().map(|string| string.len() as GLint).collect();
unsafe {
glShaderSource(shader, pointers.len() as GLsizei,
pointers.as_ptr() as const const GLchar, lengths.as_ptr());
}
drop(lengths);
drop(pointers);
}
Но тут shader_source не идентична glShaderSource, а т.к. сейчас изучаю FFI, хочется сделать обертку один в один, но безопасную. Понятно, что можно готовые биндинги взять, но хочется понять, как сделать самому.
>хочется сделать обертку один в один, но безопасную.
>OpenGL
>State-Based API
>Еще и асинхронное
>У которого вызов GAPI != выполнение действия
Удачи, чо, безопасную сделать. С учетом того что опенгл вполне себе умеет в ноги стрелять самостоятельно.
Безопасную в растовом смысле. Типа если что полетит, то точно в unsafe.
Возьми уже https://github.com/gfx-rs/gfx и не еби никому мозг.
>
>>хочется сделать обертку один в один, но безопасную.
>>OpenGL
>>State-Based API
>>Еще и асинхронное
>>У которого вызов GAPI != выполнение действия
>Причем еще и молчит об ошибках до последнего
Я же написал, что FFI изучаю. Ежу понятно, что проще и лучше взять готовое. Но что если мне понадобится функция из либы, для которой нет растовых оберток?
>Безопасную в растовом смысле. Типа если что полетит, то точно в unsafe.
Но весь прикол в том, что о том что что то полетит ты не узнаешь пока не дернешь glGetError. Причем GAPI по своей сути устроено так что нужно совершать определенный магический порядок действий и это само по себе делает его ну вообще нихуя не безопасным. Прикола добавляет то, что еще и каждый вендор по-разному считает правильным порядок действий. В реальных гл рендерах такое обилие костылей и подпорок из серии (анализируем код вендора, ага вот тут мы кор-фичу не используем она забагованная, зато берем ровно ту же ARB(EXT) потому что она на этой конкретной видюхе робит нормуль), что забудь просто свои маняфантазии о безопасном в растовом смысле. Опенгл - это худший пистолет для выстрелов в ногу с которым когда либо кому-либо приходилось работать.
КроссAPI рендер они запилили, а КроссShaderLanguage - хуй, еби атрибуты с юниформами сам. Хоть бы трупак Nvidia CG реанимировали, чтоле.
Да знаю я эти "фичи" GL, на крестах намаялся с ним. Просто хочу понять, как это правильно сделать в Расте. GL только как подопытный кролик, выбран именно потому, что там указатель на указателе, отлов всяких ошибок и т.д. Чтобы лучше понять растовые сырые указатели, короче.
>Безопасную в растовом смысле. Типа если что полетит, то точно в unsafe.
Алсо, с тем же успехом можешь glFnish() на каждый вызов любой функции OpenGL дергать, на экране будет ~3-4fps, но иначе никакой безопасности ты не получишь.
>Да знаю я эти "фичи" GL, на крестах намаялся с ним. Просто хочу понять, как это правильно сделать в Расте. GL только как подопытный кролик, выбран именно потому, что там указатель на указателе, отлов всяких ошибок и т.д. Чтобы лучше понять растовые сырые указатели, короче.
В GL в основном не указатели, а БИНДЫ, АЙДИ И БЛЯДСКИЕ МОЛЧАЛИВЫЕ ОШИБКИ.
Один хрен для Линукса лучше ничего не придумали. Вулкан еще сыроват, как мне кажется, да и адовый он какой-то. А указатели там таки есть, вон в glShaderSource аж двойной на GLchar и указатель на GLvoid
Указатели там все же по своему прямому назначению используются - передача и прием массивов данных и с ними как раз в опенгл проблем нет, не там ты заморачиваешься. А вот со стейт-бейсед парашей и одновременной асинхронностью при этом - вполне себе как раз есть и именно они делают опенгл небезопасным по дефолту. По сути нормальная прослойка безопасности над опенглом - это такой уже почти графический двиг получится.
Это технические вопросы, книжек по ним куча написано и к теме не относится. Вопрос был как передать(абстрагируемся уже от GL) параметры в такую функцию: void func(char ✶✶x, void ✶y), где "y" может быть null, а может и не быть, в Расте, чтобы сырые указатели наружу не торчали?
Короче, как для нее такую обертку сделать - fn func(x: тип1, y: тип2) {
unsafe { func(преобразование x в двойной пойнтер на char, преобразование y в пойнтер на void или null) }
}
Как раз указатели - это именно что технические вопросы, а стайт-бейсед параша и асинхронность - овпросы концептуальные.
Я сделал Option<&c_void>, т.к. это больше всего похоже на void ✶. None передается как null. Но теперь непонятно, как в Some засунуть вектор/срез/массив. Box пихать оверхед ведь? Короче, так понимаю, без сырых указателей в интерфейсе не обойтись?
А вот где ты однозначно соснешь комбинаторным взрывом, попытавшись сделать БИЗАПАСНО, так это
void glBufferData(GLenum target,
GLsizeiptr size,
const GLvoid ✶ data,
GLenum usage);
Потому что количество типов данных, помещаемых в ✶data мало того, что дохуя велико, так еще и непосредственно сами типы данных, которые кастуются опенглом из этого буфера задается уже другой функции:
void glVertexAttribPointer( GLuint index,
GLint size,
GLenum type,
GLboolean normalized,
GLsizei stride,
const GLvoid ✶ pointer);
void glBufferData(GLenum target,
GLsizeiptr size,
const GLvoid ✶ data,
GLenum usage);
Потому что количество типов данных, помещаемых в ✶data мало того, что дохуя велико, так еще и непосредственно сами типы данных, которые кастуются опенглом из этого буфера задается уже другой функции:
void glVertexAttribPointer( GLuint index,
GLint size,
GLenum type,
GLboolean normalized,
GLsizei stride,
const GLvoid ✶ pointer);
>Короче, так понимаю, без сырых указателей в интерфейсе не обойтись?
Как видишь. Что касается вершинных аттрибутов, то тут и с DX и с опенглом и с вулканом ты все равно соснешь.
Как раз только что эту функцию и нашел))) Она, кажись, дает ответ на мой вопрос:
pub fn buffer_data<T>(target: GLenum, data: &[T], usage: GLenum) {
unsafe {
glBufferData(target,
(data.len() ✶ mem::size_of::<T>()) as GLsizeiptr,
data.as_ptr() as ✶const GLvoid,
usage);
}
}
Понятно, конечно, что она копии будет делать для каждого типа, но можно ведь заинлайнить.
там автор в коментарии сверху пометку зделал, что небезопасно, фиксми.
По нормальному, конечно, безопасный биндинг ты не сделаешь, потому что glVertexAttribPointer сведет все усилия на нет, по прежнему позволяя стрелять в ногу загрузив буфердатой один тип, а в glVertexAttribPointer заявив другой.
Кстати, автор цитируемого биндинга таки соснул с glVertexAttribPointer, у него там неполная реализация.
Ну тут уже никуда не деться, на любом языке, нужно в высокоуровневое что-то оборачивать, типа меша.
>Ну тут уже никуда не деться, на любом языке, нужно в высокоуровневое что-то оборачивать, типа меша.
ну так о том и речь, что безопасные биндинги чтобы API 1к1 сделать не получится, придется писать свои движок рендера/фреймворк и.т.д
На выходе получится что то вроде такого, то бишь уже некий фрейморк-недодвижок:
https://github.com/glium/glium
Я что-то не вижу причин, почему не написать такую же обобщенную vertex_attrib_pointer
Он, походу, пытался сделать, чтобы в функцию константу неправильную не передали, я так понимаю?
Мы, наверное, как-то по разному безопасность Раста понимаем. Он ведь не может в логическую безопасность. То, что ты разные буфера засунешь вместо одного и того же, разве это проблема Раста, а не твоя? Ведь по правилам Раста эти функции будут безопасными, т.к. он обязан только следить за владением и валидностью переменных.
>Я что-то не вижу причин, почему не написать такую же обобщенную vertex_attrib_pointer
1) Два вида использования функции - "по-старому", когда в ней задается и формат аттрибутов вершин и их источник, при этом формат и поинтер - два независимых параметра функции и первый задает интерпретацию второго.
"По-новому" - когда в пойнтер передается число, означающее оффсет для прибинженого буфера.
2) Придется вводить в библиотеку новые типы данных и отвечать за их корректность и безопасность:
> glVertexAttribPointer and glVertexAttribIPointer both take: GL_BYTE, GL_UNSIGNED_BYTE, GL_SHORT, GL_UNSIGNED_SHORT, GL_INT, and GL_UNSIGNED_INT
> glVertexAttribPointer also can take: GL_HALF_FLOAT, GL_FLOAT, GL_DOUBLE, GL_FIXED, GL_INT_2_10_10_10_REV, GL_UNSIGNED_INT_2_10_10_10_REV, and GL_UNSIGNED_INT_10F_11F_11F_REV.
При этом не сломав пользователю возможность использования собственных уютных типов данных.
3) Array of Struct.
И таки функция fn(x: &T) все же безопаснее fn(x: *const T), если она не должна принимать null.
Так по факту он не следит ни за владением ни за валидностью, потому что на связке glBufferData/glVertexAttribPointer вся эта валидность превращается в тыкву. И не разные буфера, а один и тот же, просто заливать я его буду как f32, а вершинный аттрибут настрою как GL_UNSIGNED_INT_10F_11F_11F_REV, потому что в опенгле эти понятия какбы разделены - буфер - этоо просто нетипизированное хранилище байтов с флагами использования, а его интерпретация в типах данных начинается в glVertexAttribPointer (и других функциях, если речь про текстуры и ssbo).
Понял, про что ты, но немножко безопасности все равно получить можно - ты не сможешь залить null вместо массива данных буфера.
>Понял, про что ты, но немножко безопасности все равно получить можно - ты не сможешь залить null вместо массива данных буфера.
Это корректная операция с точки зрения опенгл, если что и ты только что урезал функционал OpenGL и лишил меня возможности создавать пустой буфер.
По идее все эти данные уходят в опенгл напрямую из файлов. То есть их не нужно перепаковывать. А значит апи можно сделать таким, чтобы оно принимало просто нетипизированный блоб. Для ручного же формирования сделать либо дополнительную функцию с родным форматом для раста, либо функции-энкодеры, пакующие такие блобы.
А пустой массив Раста не будет пустым буфером в GL?
И вообще, зачем нужен пустой VBO? Может и туплю, но как-то не приходилось иметь дело с таким.
>А пустой массив Раста не будет пустым буфером в GL?
glBufferData - означает "Создай мне буфер такого то размера в байтах и с таким то типом использования. Если поинтер не нулл - то еще и данные по этому поинтеру побайтно туда скопируй, при повторном вызове - удали старый буфер и создай новый".
Для изменения данных в буфере служат уже glMapBuffer (вот тут, к слову, тоже интересно как на расте выкручиваться) и glBufferSubData.
https://www.khronos.org/opengl/wiki/Buffer_Object#Data_Specification
> По идее все эти данные уходят в опенгл напрямую из файлов.
Я хочу использовать, скажем, формат COLLADA или https://www.khronos.org/gltf/(они вообще текстовые, есличто), а твои байты в тыкву превратятся, если я их на платформу с другой endiannes перенесу.
> А значит апи можно сделать таким, чтобы оно принимало просто нетипизированный блоб.
и получишь тот же самый небезопасный поинтер.
> Для ручного же формирования сделать либо дополнительную функцию с родным форматом для раста, либо функции-энкодеры
То есть опять все сводится к "недодвижок поверх"
>И вообще, зачем нужен пустой VBO?
У меня есть система частиц, хочу на компуте шейдерах их пидорасить, например.
up
>В то время корректная си программа == с++ программа.
Нихуя.
Что нихуя?
int main() {
int class = 0;
return class;
}
Эта программа корректна в си, но некорректна в си++
Ой, ладно, не доебывайся со своей хуйней.
Первый с++ компилятор вообще просто был набором макросов для си компилятора.
Есть более интересные и неочевидные несовместимости, я лишь указал на самую очевидную.
>Первый с++ компилятор вообще просто был набором макросов для си компилятора.
Наглый пиздеж.
По твоему он не генерил код для сишного компилятора?
Генерил, но это не набор макросов, а полноценный транслятор в си.
Оки. Лень думать было как правильно.
Слишком сырой чтобы хуярить в продакшн. Не платят.
UPD
Субъективно, отмороженный стиль ключевых слов и операторов. Фн члн лет и64 пук.
Кстати как насчёт общего стайл гайда как в петоне?
Хуита полная. Скидываю инсаидерскую инфу. Сеча в ЕБУ стоит автосар, да там много кодогенерации, но только чтобы писать задачками изолированными друг от друга, а в окошечках накидиывать и описывать связи. Работы дахуища, начиная от новомодных датчиков. лидаров, камер, систем автопилота и сапорта водител, инфотеймента. Потом в перспективе будем пилить инфроструктру для сапорта автопилота и машины. Типа маячок сообщает, когда ёмобилю заводить мотор на светофоре Работы очень дахуя. Раст - щенок, т.к. требует серьёзной стандартизации и перепиливания огромного пласта уже готовых тулов. Но для некритичной мистемщины и прикладной хуеты вполне-вполне. Подождём 20го стандарта, имхо плюсы быстрее допилят.
Но раст как раз на уровне C++ и да C по скорости. Вон даже топ 1 по http-фреймворкам стал.
Ну и конечно вот сравнение с плюсами
Даже на синтетических тестах на одном уровне с крестами.
Есть книжка про стайлгайд, еще не дописанная. Есть rustfmt.
Мы хуярим в продакшн, и нам платят.
Пацаны чё делать? Нубас кароч, с чего начать учить: си или не терять время и сразу rust? Стоит ли учить си и программы на нем делать некоторое время перед тем как освоить rust? Может потребоваться с микроконтроллерами работать. Из языков знаю Питон. Инб4 уже учу CS, алгоритмы, архитектуру эвм, и другие важные темы.
Не стоит. Сразу учи раст.
Стоит. Сперва учи си.
Блин, помогите определиться. Думаю зная си легче будет понять rust, но с другой стороны времени на изучение хочется сэкономить.
Легче будет понять только unsafe Rust. А так, для понимания Rust куда более пригодны знания Haskell, нежели C.
А, понятно, спасибо.
С микроконтроллерами на раст как обстоят дела?
>времени на изучение хочется сэкономить.
Ты ошибся разделом.
>Думаю зная си легче будет понять rust
Если ты не знаешь си, то тебе тут вообще нечего делать, скажем прямо.
>для понимания Rust куда более пригодны знания Haskell, нежели C.
Для понимания Rust знания х-ля если не бесполезны, то как минимум совершенно опциональны. А вот без стандартной базы этот ребенок просто потеряется. Об этом, кстати, написано в самом растбуке:
>These properties make Rust suitable for programmers who have experience in languages like C and are looking for a safer alternative <...>
>This book is written for a reader who already knows how to program in at least one programming language.
Го дискас Rust vs C/C++?
Тезисно.
-Аргумент про безопасность понимаю, но судя по тому, что слышал, почти всё байтоёбство в расте делается в unsafe, где вся безопасность идёт на хуй. Да и зачастую байтоёбство как раз идёт в обход безопасности.
+Один пацык контрагументировал тем, что в C/C++ unsafe сплошной, тогда как в расте чётко выделен.
+В расте есть ФП и оно более человеческое чем в плюсах т.к. закладывалось изначально, а не прикручено через 25 лет.
-Но в то же время ООП в расте слабее, чем кривое оное в плюсах.
-Про вакансии на расте всё ясно и так.
+/-Высокий порог вхождения.
З.Ы. Сам трогал раст палкой с большого расстояния, поэтому приглашаю анонов писавших что-то хорошее, годное на сабже.
Тезисно.
-Аргумент про безопасность понимаю, но судя по тому, что слышал, почти всё байтоёбство в расте делается в unsafe, где вся безопасность идёт на хуй. Да и зачастую байтоёбство как раз идёт в обход безопасности.
+Один пацык контрагументировал тем, что в C/C++ unsafe сплошной, тогда как в расте чётко выделен.
+В расте есть ФП и оно более человеческое чем в плюсах т.к. закладывалось изначально, а не прикручено через 25 лет.
-Но в то же время ООП в расте слабее, чем кривое оное в плюсах.
-Про вакансии на расте всё ясно и так.
+/-Высокий порог вхождения.
З.Ы. Сам трогал раст палкой с большого расстояния, поэтому приглашаю анонов писавших что-то хорошее, годное на сабже.
Как тебе такой аргумент:
работа на расте = команда профи, которая не боится пробовать новое, а проект достаточно нов, чтобы ты смог превратить егов легаси.
работа на крестах = бородатое говно с птушниками, уровня "С++ за 21 день".
>работа на расте = команда профи.
Если говорить именно о работе, то вероятность найти вакансию на расте +-нуль.тем более в рашке
Плюсы же постепенно сдают позиции и случайных людей там всё меньше. Судя по однокурсникам большинство собирается вкатывается либо в джаба тырпрайз, либо в веб клепать формочки.
Ну и ясен хуй я червепидор, который ещё не работал и выёбывается, куда без этого.
Ну если ты червь пидор, то конечно ноль, о чем разговор.
Но сам подумай, кто захочет начинать новый проект на крестах? Такое может произойти только в говноконторе с протухшими старперами в начальстве, типа яндекса.
Спасибо, анон, теперь однозначно буду учить си.
Ок. Сам кем работаешь? Хотя бы стек/локацию?
Съебываю в Осло, работать на расте, общелиспе и прочей хипстоте.
Хуя ты модный. В какой сфере такой поехавший стек может пригодиться?
Ты не поверишь, но банковская.
>общелисп
>хипстота
Пикрил.
Но вообще - рад за тебя, анончик, ты тут наверное самый успешный :3
>Но в то же время ООП в расте слабее, чем кривое оное в плюсах.
В Русте другая система типов, куда более мощная и выразительная, которая к тому же куда лучше подходит для каждой буквы в SOLID.
Занятно. Банковская сфера это по идее ехала база данных по базе данных. Не проще купить оракле и забыть все проблемы? Что именно нужно разрабатывать на расте?
Хер знает. Жду пока бумажки местное министерство гастарбайтеров оформит. Безопасники запрещают рассказывать всякое.
В курсе. Но я про дефолтное ООП говорил, которое de facto доминирующая парадигма, а не ваши новомодные трейты хуеты, владение и move семантику.
>de facto доминирующая парадигма
Топовый аргументов почему ретроград сопротивляется применению нового. Причём я такое где только не слышал, даже при переходе с питона 2 на 3.
Против всего старого, за всё новое.
Но большинство не лисповоды 500ка/нсек с эмиграцией в Норвегию, поэтому рассуждаю с позиции среднепрограмера который знает только ООП основанное на классах.
На сколько сложно мне будет, если я типикал джуниор-фронтенд-петушок? Цель: есть идея одного десктоп софта с некоторой частью на бэке.
Будет очень сложно.
Че, пора тред перекатывать, да?
Да, пора
Шапку обновить или хуй с ней?
Если тебе не влом, то почему и не обновить
Да хуй знает че туда писать.
Предлагайте.
Перекат
https://www.rust-lang.org
https://doc.rust-lang.org/book/
https://rustbyexample.com/
https://github.com/rust-unofficial/awesome-rust
Старый тред тонет тут