>>1062380 (OP)

Зачем нужен раст, когда есть молодежный кристал?

>>1062391
GC

>>1062391
Ну и
> The project is in alpha stage: we are still tweaking the language and standard library.

В чем его преимущества перед ноджс?

>>1062432
Ну ноджс это детские очки. Можно надеть на себя, будет глупо выглядеть, оптическими свойствами не обладает, но можно честно сказать "я ношу очки".
Раст это гугл-глас с нейроинтерфейсом.

>>1062432
В том, что для nodejs нативные модули пишутся не на говноязыках, а на годноте. Npm давно использует rust у как средство улучшения developer experience

Пилю маленький игорь на сабже, полет нормальный.

>>1062583
На чем пишутся модули, на C или JS (хочу понять что ты называешь годнотой)? Каким образом NPM использует Rust, это ты сам придумал?

>>1062704
https://www.youtube.com/watch?v=GCsxYAxw3JQ

>>1062704
Вместо C можно (нужно) использовать Rust

>>1062380 (OP)
Объясните, зачем в раст добавили сишное говно - строки cstring? Почему нельзя было просто взять и сделать язык без наследия далекого прошлого?

>>1062819
>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.
Очевидный интероп.

>>1062821
>интероп
Ну и кому он еще нужен?

>>1062825
Всем кто пишет проекты сложнее laba3.exe
Биндинги к сишным либам по твоему получаются магическим образом?

https://github.com/ctjhoa/rust-learning

Так-с, чего молчим? Никто не хочет абстракции с нулевой стоимостью?

>>1062380 (OP)
Есть расширение для VS17 или лучше расширение для VS code адекватное для компиляции и отладки?

>>1062380 (OP)
Интересный язык. Правда, сложно заставить себя писать именно на расте, а не на Си с растовским синтаксисом.

>>1063814
Это нормальная история при перекате на новый язык.

Насколько ржавчина надежна/безопасна? Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром? Или все, что написано на чистом расте, гарантированно корректно?

>>1064450
> Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром?
Можно.
Но к безопасности и надежности это отношения не имеет.

>>1062434
Rust это Google Cardboard

Насмотрелся роликов на ютубе про безопасный Раст. Начал писать. Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями. Да и вообще поймал себя на том, что слишком часто я использую эти "опасные" операции. Либо надо полностью менять ментальность, либо одно из двух.

>>1064685
Ну ты придумал. Окошки на винде открывать.
Возьми Qt ил Gtk или что попроще.

>>1064685
Пипец, если ты собираешься стать программистом, тебя столько разочарований ждет. Лучше займись чем-то другим.

>>1064469
>Можно.
А небольшой пример такого кода где найти?

>Но к безопасности и надежности это отношения не имеет.
Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.

>>1064708
>А небольшой пример такого кода где найти?
Херачиш унсейф.


>Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
Надежность\безопасность ЯП\среды, и реализованного на этом ЯП кода - вещи разные.

Безопасна ли машина с подушкой безопасности? - безопасна.
Безопасно ли врезаться в столб на скорость 200км в час с не пристегнутыми ремнями?

>>1064710
Да даже с престегнутым и с рабочей подушкой безопасности так себе идея. Но фанатикам не объяснить.

> Купили как-то суровым сибирским лесорубам японскую бензопилу.
> Собрались в кружок лесорубы, решили ее испытать.
> Завели ее, подсунули ей деревце.
> «Вжик» — сказала японская пила.
> «У, бля...» — сказали лесорубы.
> Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
> «Ух, бля!» — сказали лесорубы.
> Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
> «Ух ты, бля!!» — сказали лесорубы.
> Подсунули ей железный лом. «КРЯК!» — сказала пила.
> «Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами…

>>1064707
И что же конкретно тебя разочаровало?

>>1064798
А я тут причем?

>>1064715
>Но фанатикам не объяснить.
Да то не фанатик, а просто ребенок, который мало чего в этом самом программировании понимает.

>>1064806
Мне на секунду показалось, что ты исходя из своего опыта это заявляешь.

>>1064690
Ты думаешь, они какое-то другое виндовз апи там используют?

>>1064856
Ну да, из опыта.
Из наблюдений, здравого смысла, и выводов.

Многим молодым людям, программирование видится чем-то очень интересным, особенным. Они видят написание кода как интересную задачу, создание чего-то красивого, идеального.

Но в реальности, это неблагодарный, монотонный, тяжёлый труд, по созданию комка костылей склеенных соплями.
Нет красоты, нет консистентности, нет идеальности. Есть бесконечный копипаст и забагованные текущие либы.

Костыльность и неидеальность нужно принять как должное.
А если такого органичного принятия нет, человек будет страдать, всю жизнь быть может.

>>1064798
>И что же конкретно тебя разочаровало?
IT как таковое. Качество людей в нем работающих.
Не переношу бракоделов, профанов, и самодуров. Нет уважения к своему труду.

А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.

>>1064685
> Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями.
Ты явно преувеличиваешь.
Насколько я помню, винапи вполне элементарно.
Даже на ассемблере беспроблемно окошечки создавать.

>>1064857
Только что компилил проект на виртуалке с виндой. крейт winapi прекрасно сконпелился.

>>1064865
Там во всех областях. Красоту нужно уметь видеть, это субъективная история. Если ты не видишь её, то это не значит что её не видят другие.

А что касатеся "шахтеров", то что в этом удивительного? Профессия новая, особенно на постсоветском пространстве.

>>1064866
В расте вызов сишной функции и передача raw поинтеров считается опасным кодом.

>>1064708
Ну я в этом вашем расте не силен, но насколько я помню он гарантирует безопасность памяти. Однако утечки памяти можно множеством способов устроить. Например, накостылить бесконечный цикл. От такой рукожопости ни один яп не убережет.

>>1064916
Можно всё.

Бред уровня запрета ЦП. Избежать ошибок можно только одним способом - не быть криворуким дауном. Для этого не надо создавать ещё один бесполезный язык и говорить, что он лучше C/CXX.

>>1070417
> Избежать ошибок можно только одним способом - не быть криворуким дауном
Работает только в проектах уровня лаба1.

>>1064971
Ты не понимаешь что такое "утечка памяти".

>>1070417
Пиши на ассемблере, хуле ты как не мужик.

>>1070417
> не быть криворуким дауном
Аюсолютно каждый программист криворукий даун в той или иной степени. Поэтому лучше пользоваться языком который позволит автоматически избегать определённого класса ошибок.

>>1070417
Все ошибаются.

>>1070417
На любое обвинение у сибляди есть универсальный ответ - "криворукость". Этим сиблядь как-бы намекает, что что все вокруг криворуки - т.е. сотрудники микрософта и интеля, пишущие кривые драйвера и библиотеки, прыщебляди, пишущие дырявое ведро своей системы вот уже не первый десяток лет, просто другие сибляди из соседнего подвала полусвовковой шаражки, в которой сиблядь работает. А вот сама сиблядь - сука граф Шарль Ожье де Бац де Кастельмор д’Артаньян среди педерастов, владеющий техникой левитации, предсказания будущего и написания небыдлокода на сишке. К сожалению, простым смертным едва ли не удастся увидеть творения сенсея, так и будут они работать с глючным говном криворуких интелевских и микросовтовских инжеренов, внезапно падающим от какого-нибудь buffer overflow, несмотря на зиллионы человекочасов, проёбанных на его тестирование и отладку.

>>1072056
Сагу то за что прилепил, ирод?

>>1072062
паприколу

>>1072066
> #[allow(шутник_дохуя)]

>>1070429
Утечка памяти это когда память проебывается все больше и больше по мере работы программы. Что не так?

>>1080623
Внешне оно выглядит так. Но к твоему циклу не имеет никакого отношения.

>>1064971
Утечка - это если к динамической памяти нет вообще никакого способа обратиться. Если же ты никогда не теряешь ссылки, то всегда сможешь увидеть в отладчике странный вектор на миллиард элементов или типа того. Т.е., память просто избыточно выделяется, а не утекает.

>>1062434
Раст это хипстерские очки с розовыми стеклами.

>>1080928
С хуя бы? Розовые стекла в хачкеле, например. С дырочками.

>>1072056
>граф Шарль Ожье де Бац де Кастельмор д’Артаньян
Сука орнул с поста. Но идика ты нахуй, все заебись на С написано и у интела и у прыщеблядей, прыщикс вообще самое лучшее что создавали за последние десятки лет программисты. Единственное в чем я с тобой согласен это про майкрософт, там действительно пиздецовые дауны на С так наговнокодили что пиздец.

>>1080931
График уязвимостей в ядре покажи-ка?

>>1081013
Я хуй знает я не слежу за графиками, ибо какой от этого толк? Даже если там и у прыщикса больше чем у спермы, то толко потмоу что прыщикс разрабатывают в сотни раз больше людей чем сперму, и еще учитывай что в сперме намеренно делются уязвимости для различных спец. служб, как недавно было с атаками шифровальщиков которые использовали уязвимости сделанные специально для АНБ.

>>1080897
Ну согласен, с циклом плохой пример пусть это будет рекурсия.
>>1080914
>Т.е., память просто избыточно выделяется, а не утекает.
Это и называется утечка, когда в память выделяется, но обратно не высвобождается.

>>1081398
Если память используется, то это не утечка.

>>1081583
Чет ты сочиняешь уже
Утечка памяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.

>>1081637
Мань, че ты тупенький такой? Сам же пастишь:
> неконтролируемого уменьшения объёма
Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить. Но если ты проебал указатель, то есть физически освободить сама программа её уже не может, это как раз "неконтролируемое" уменьшение.

>>1081649
Кек, то что ты пытаешься втереть вообще не существенно. Даже если в теории ты можешь контролировать разбухшую память, но в программе такое поведение не предусмотрено, то это все равно будет утечкой. О чем ты пытаешься кукарекнуть уже относится к безопасности памяти, то, от чего раст защищает в 100 и 100 случаев если не врубать unsafe.

>>1081762
>раст
>врубать unsafe

so laba1.rs

>>1062380 (OP)
Чо там с const generics? HKT до 2.0 не появятся, я так понял а тогда уже и голанх 2 подъедет со своими дженериками

У раста есть какой-то казуальный режим для плебса, который пишет на питоне и JS?

>>1083135
Go

>>1083135
Раст это инструмент для решения задач имеющий определенный набор характеристик. Если тебе нужна простота, то действительно, возьми го.

Ваще не одупляю, почему люди вспоминают о го в контексте раста и наоборот. Языки вообще никак не связаны.

Мне кажется как казуальный раст нужно упоминать кристал. Только там вроде пока мультитрединг внятный не сделали.

>>1083450
>простота
простота != легкость (в изучении)

>>1081637
>неконтролируемого
Из твоей же вики:
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]

>>1084307
Короче, отличие в том, что с утечкой памяти сделать уже нихуя, а утечки `пространства` можно попытаться избежать грамотным проектированием

>>1081649
>Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить.

Речь шла о менеджет языке я так понимаю. Изначально.
Так вот, в менеджет коде, у тебя нет "на нее указателей", они есть у среды выполнения(необязательно), так что по этому пунку - сие есть утечка.

Дальше, давай разберем тобой написанное, ты тут сам выдумаешь значения терминов, фантазер, тебе лет то сколько?
Какая в жопу разница, есть указатель, или нет, если память не освобождается там, где должна?

С таки то подходом после закрытия приложения память все равно освободится так что утечки нет1111)))))))

Иди сделай бочку, реатрд.

>>1084307
>space leak is released, but later than expected.
Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?

>>1084693
Уже 10 раз объяснили:
> A space leak occurs when a computer program uses more memory than necessary.
Если память жрется больше чем надо, никогда не чистится, то это не утечка памяти. А space leak. "программа жрет много памяти потому что хуевый алгоритм". Называй как хочешь.

Языки с гц могут течь, например, если гц делает reference count.

>>1084713
>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.
Ты сам себе противоречишь.

>>1084822
вы заебали со своей памятью. лучше бы по теме что-нибудь писали

>>1085354
Например?
Я пилю игрушку, например. Две недели пытался завести её на андроиде, но нихуя не вышло. Плюнул, пилю под декстоп пока.

>>1084693
>Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
Утечка памяти.

>>1085442
Как пытался завести? Я тоже хочу написать игру.

Какие есть для Rust веб-фреймворки?

Так короче растоблядки. У вас есть минута чтоб пояснит ьмне чем ваш раст лучше golang или D?

не пишу ни на одном из этих языков, но очень желаю смерти с++

>>1086357
В Ди есть гарбедж коллектор, а в Ржавом не нужен из-за передачи ownership'а и прочих плюшек.
Голанг не имеет такой развитой системы макросов.

>>1086358
А как в ржавом тогда ресурсы особождаются? Время же недетерминированно становится. Например, если удаляется какой-то сложный объект который влечет за собой кучу деаллокейтов ? В то время как в языке с GC, это удалится потом и не вызовет задержки программы.

>>1086462
Время каждого ресурса определено статически с помощью системы типов.

>>1086357
Гарбадж коллектор, долбоёб, неужели не очевидно?

>>1086569
Долбоебина, может сначала бы прочитал дальнейшие посты, прежде чем высирать тут что-то?

>>1086471
>Время каждого ресурса определено статически с помощью системы типов.
Вот это действительно хорошо заделали. А пример можешь привести? А то меня всё время смущало, вот вроде бы скорость, детерминированность, безопасность, а как освобождать глубоко вложенную структуру, так и мало того кто последний тот и ебётся, так и ещё свалится с запросто. Тут вообще комбо получается: переполнение стека, да ещё и в деструкторе.
мимо другой анон

кто-нибудь из присутствующих пробовал писать игрушки на расте с использованием piston или amethyst? если да, то отпишитесь как полет

>>1086996
>Вот это действительно хорошо заделали. А пример можешь привести?
Фак. Написал длинную телегу и куда-то не туда нажал.
На каждый объект в Расте может быть либо одна ссылка, через которую объект можно менять, либо сколько угодно read-only. Кроме того, ссылка не может жить дольше, чем объект, на который она ссылается. Передача же не по ссылке - это аналог std::move в плюсах.

Это позволяет удостовериться, что как только переменная вышла из своей области видимости, её можно смело удалять, не оставив никаких висячих указателей.

Система не идеальна, и для некоторых вещей нужен unsafe-блок, который позволяет использовать обыкновенные указатели. В таком случае на программисте лежит ответственность сделать так, чтобы в интерфейсе поддерживался инвариант из начала поста.

>>1087937
Мы с тобой побеседовали хорошо, жаль что про разное только. Изначально анон поинтересовался за финализацию и детерменированность времени на неё. Ну например для структуры N = Z | S N реализованной на, пусть будет, Arc сложность деструкции линейна по времени, а в наивной реализации ещё и по стековой памяти. Для структур же более ветвистых - сложность только растёт. Добавив что если используется какой-то абстрактный типаж, то о времени деструкции сказать вообще вряд ли что-то возможно не рассматривая весь код. И если ресурсом пользовались несколько потоков, то освобождать её предстоит последнему, чем могут быть неприятно удивлены апологеты сборки мусора. Вот я и подумал было, услышав про статическое определение времени каждого ресурса, что решается именно эта проблема.

>>1062584
Что пилишь, анонче?

Какая-то смесь Python, C++, не?

>>1088181
Если точнее, то haskell и c++

>>1088155
Я просто мимо проходил, лол

Использование Arc - это перенос гарантий из статики в рантайм, т.е. компилятор тут ничем не поможет, увы. А многопоточность чисто на борровинге будет максимальным пердолингом.

>>1088250

Ну вон тот же rayon как сделан. Гарантированно безопасные unsafe блоки заэнкапсулированы внутри, а апи чисто safe

>>1086357
>чем ваш раст лучше golang или D
Всем лучше.
Какой вопрос - такой ответ

>>1088326
Таки верно. Можно считать, что он на ступень эволюции выше (на 2 выше go)

>>1088159
Что-то типа кликера.

>>1086996
Лучше всего посмотреть любую презентацию про Rust. Вот натолкнулся на очередную youtu .be/oIikwmeGVYY
Вполне ничего

Питонисту тяжело будет в раст вкатиться?

>>1092990
Если кроме пиздона ты ничего больше не видел, вероятно сложновато.

>>1092990
Все равно вкатывайся. Материалы хорошие. Узнаешь основы функциональщины, типизации.

>>1088326
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.

Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.

Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.

Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?

Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?

>>1094060
>И один хер придётся использовать небезопасные блоки кода
1. Почему придется?
Стейтмент так себе.

>невозможностью реализовать добрую половину привычных структур данных
Все там можно.

>вещи пусть и порочные, но глубоко привычные
Ты так говоришь, как будто что-то хорошее.

>Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
Создавался как то, что должно было появиться, но вместо чего появился С++.

>>1094144
>Стейтмент так себе.
>Все там можно.

Вот продемонстрируй мне двусвязный список, руками, а не из коробки или же дерево где дочерняя ветвь хранит ссылку на родителя, и я пристыженный уйду. Нет, я допускаю что можно всё организовать в массив и в структуре хранить индексы запроместо указателей, но былой стремительностью такой подход уже не похвастается.

>Ты так говоришь, как будто что-то хорошее.
Я вроде ж указал на заведумую порочность. Другое дело, что сторонние-то функции далеко не все реентерабельны. Заодно поясните, я наткнулся раз на демку в которой рисуются красные квадраты, как GL адаптировали? Ну я о том, что в два потока не порисуешь ведь - хуета получится, стало бы либо монитором защищать либо передавать обёртку, но тут-то надо же хранить где-то флаг пользует её кто-то или нет.

>>1094175
>но былой стремительностью такой подход уже не похвастается
Храните в HashMap, кто вам запрещает-то?..

>>1094175
>либо монитором защищать либо передавать обёртку
либо EnterCriticalSection() и затем LeaveCriticalSection()

>>1094175
http://bluss.github.io/ixlist/target/doc/ixlist/struct.List.html

>>1094185
>Храните в HashMap, кто вам запрещает-то?..
Ты про какой-то волшебный HashMap в котором сложность доступа к элементу не O (ln(n)) и даже меньше константной сложности проверки индекса и обращения к элементу в массиве? Не очень тебя понял по-видимому.

>>1094522
>instead of pointers we use indices into a backing vector
Впрочем, ты уговорил. Подход немного непривычный, не самый шустрый, но вполне обоснованный при данных условиях.

>>1094186
>EnterCriticalSection
Ну она ж аргумент принимает? Где-то хранить его надо между вызовами, ведь не каждый поток в свою критическую секцию заходит.

>>1094060
>он для каких задач и для какой аудитории вообще изобретался?
Наркоман? На их сайт зайти и прочитать не можешь? Пиздец, вот вроде пишет человек пост: длинный, грамотным русским языком, вопросы всякие вполне обоснованные задает... а потом в самом конце берет ушат собачьего дерьма, выливает на себя и начинает ногами дрыгать: "я в дерьме! я говно ем!" - пиздец, нахуй так жить-то?

>>1094060
>И один хер придётся использовать небезопасные блоки кода

Не нужно. Нужно использовать новую парадигму, а не свои привычные костыли из c++

>>1094175
Не знаю как там у вас в двусвязных, но обычный односвязный предназначен для того, чтобы быть на heap и быть полностью персистентным, либо туплоподобным и иметь известную длину, запечатленную в типе.

>>1094584
>волшебный HashMap
Да, выжирающий сотни памяти, он перестраивает хеш-индекс во время работы и даёт почти мгновенный доступ к данным.

>>EnterCriticalSection
>Ну она ж аргумент принимает?
Она переключает режим выполнения, чтобы работал только вызвавший её поток, а потом другая функция его возвращает в тот же режим как было. Всё это костыли, естественно.

>>1094599
>ушат собачьего дерьма, в дерьме, говно ем
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.

>>1094702
>Не нужно.
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?

>>1094774
>почти мгновенный доступ к данным
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.

>Она переключает режим выполнения, чтобы работал только вызвавший её поток
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.

>>1062432
>>1086357
В чём преимущество перфоратора перед дрелью? Дрели перед перфоратором?
>>1064931
Как ты думаешь, для чего вообще в расте придумали "опасный код"?
>>1070417
То что создание новых языков и переписывание всего под них приводит к убыткам это правда. Но так же правда и то, что поддержка и развитие легасей крайне дорогое, без особой надежды на улучшение ситуации в будущем.
>>1083135
Пиши без использования ссылок. Копируй/клонируй всегда и везде.

>>1094943
>Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини?
Увы, ты промахнулся.

Кстати, позволю себе замечание по поводу содержания остального поста. Что ты, блядь, хочешь-то от нас от них?! Тебе, блядь, дали язык, на котором можно писать чуть ли не в функциональном стиле с ебаной кучей статических проверок без гц и быть на 10-15% медленее си. Тебе дали возможность писать на си с нескучным синтаксисом и тем же тулингом, когда эти 10-15% тебя не устраивают или когда компилятор анально насилует тебя в жопу. Вместо того, чтобы возрадоваться и поблагодарить Бога за это, ты приходишь в этот итт тред и начинаешь лечить про то, что хэшмапы медленные. Сука, блядь, так хули тебе надо-то?!

>>1095018
Он из тех кто против и ищет подтверждения своим убеждениям.

>>1095018
Сможет ли Раст обогнать С после всех оптимизаций?

>>1095099
Да. Пиздуй контрибьютить в llvm и rustc.

>>1095018
>Сука, блядь, так хули тебе надо-то?!
Ты прям срузу с козырей. Потолковать хочу за всякие нюансы, попиздеть по большей части для души. Сама система типов, и правда не может не вызывать восхищения. Вот мне и интересно является ли она во всей своей чистоте и ортогональности практичной и достаточной для какого-либо маломальски серьёзного промышленного проекта. И как адаптируются традиционные подходы в переложении на неё. И какие подобная адаптация может скрывать за собой опасности.
Вот и интересуюсь.
Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах, кто-то и окажется готов поделиться мнением. Указать на какую-либо избыточность или недостаточность языка или одного из его элементов, посетовать на те случаи где они заебались бороться с borrow checker'ом и где наоборот он их сильно выручил. Хватает ли им скорости хэшмапов или приходится использовать unsafe. В одиночку это было бы в любом случае гораздо сложнее, а тут целый тред по языку создан.

>>1095340
>Сама система типов, и правда не может не вызывать восхищения.
Ага! Я так и знал, что ты мазохист, содомит и бдсм-извращенец, бгг.

> или приходится использовать unsafe
This.

Я не пишу на расте, но еще в прошлом посте написал про си с нескучным синтаксисом. Ансейф - это не какой-то смертный грех, это просто способ не пиздовать в си, а писать сишный код прямо тут же, в расте. Тайпчекер же нужен не ради самого себя, а для гарантий. Там, где ты можешь (думаешь, что можешь) предоставить эти гарантии сам, можно его выключить. Если тебе нужны не простые хэшмапы, а WOW SO HASHMAP 2000% BONUS CRITICAL SPEED ACHIEVEMNT UNLOCKED BAYTOŒB PWND, то ты просто берешь и пишешь их без задней мысли. Главное, как всегда, изолировать это говно и тестировать это говно. Тут, блядь, нет какого-то "АХАХАХ ВОТ Я ВАМ ГОВОРИЛ АНСЕЙФ ВЕЗДЕ ТАЙПЧЕКЕР СОСНУЛ РАСТ НИНУЖОН)))00", - он изначально таким и задумывался, блядь. Это не баг, это фича.


Ну и это.
> Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах
> 2ch.hk
> серьёзное ПО, участвуют в крупных проектах
> 2ch.hk

>>1095350
Ты какой-то странный. Нет ничего плохого в IE6 если твой завод физически отрезан от внешнего мира. А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза.

Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости, отсюда растут ноги NIH.

>>1095392
>А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза
Необразованный безмозглый дегенерат.
Иди в /ra/ чтобы тебя там хоороошенькго обоссали. Я даже начинать не буду.

>Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости
Стандартное объяснения почему компаниянейм создала пиздатый продуктнейм - "нас заебало стороннее легаси говно и нам пришлось сделать свое."

>Нет ничего плохого в IE6
>Ты какой-то странный.
Сук пиздос.

>что переписывают чаще в процессе глубокого изучения
Да блядь просто берешь и создаешь нужный тебе функционал.
90% всего уже есть в стандартной библиотеке. А если нет, то на помойку этот язык.

>>1095422
Я не он но ты хуйю несешь. LED в 10 раз экономичнее и глаза от него не устают. У меня вся квартира ими обмазана. Профит от LED настолько очевиден что его не заметил только полный слепец.

>>1095508
Да причём тут экономичность. Вдруг мне просто нравится тёплый ламповый свет? Люди даже камины дома сооружают, на дровах, Карл. У того буйного проблемы с подбором аналогий, всё что я хотел сказать. Я даже не понял что он хотел сказать своими длиннопостами, какие-то разрозненные бессистемные аргументы без тезиса и вывода.

>>1095508
Речь о спектре излучения, але.

>>1095584
>>1095572
Это я к тому, что профит от использования LED с головой перекрывает лампы накаливания. Тоже самое с использованием легаси.

>>1095645
Ну не знаю. libpng тоже переписываешь каждый раз? Везде биндинги, везде FFI. Это тоже легаси? Как бы зачем переписывать то что вылизывалось чуть ли не десятилетия?

>>1095422
Я сказал, что не собираюсь обучать подобного дебила. Иди в /ra/.

>>1095572
>Вдруг мне просто нравится тёплый ламповый свет?
1. Есть лед с Ra 95-98, даже лучше чем у ламп накаливания.
2. Необучаемый, думает, что лед лампы не могут светить теплым светом?

>мне просто нравится
Заебись.
А ничего, что речь шла о ЭКОНОМИЧЕСКОЙ ЦЕЛЕСООБРАЗНОСТИ, а не о том, что какой-то пизде нравится, или не нравится?
Тебе никто не запрещает хоть дуговыми лампами освещаться хоть свечами, хоть газовыми светильниками.

>Я даже не понял что он хотел сказать своими длиннопостами
>многабукаф нипонятно
>слишком длинно111
>я ничего не понял но все равно напишу какуйнибудьзхуйню вместо того чтобы расспросить о непонятных мне вещах.
>ведь я такой умный я все знаю

>У того буйного
>Ты какой-то буйный
Задеваю твою женскую гордость?
Мужчина не должен привлекать к себе внимание, если ему нечего сказать.

>>1095584
>Речь о спектре излучения, але.
А что спектр излучения?
А ты среднюю дисперсию посчитал для спектра солнца\лампы накаливания и солнца\LED ?

>>1095678
>>1095681
Я уже понял что в /ra/ лишний раз лучше не заходить. Что ты так орёшь-то? Сам небось своими светодиодами барыжишь? Экономическая целесообразность как раз таки очень спорная, светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит, а электричества на всю стоимость лампы не сэкономит.

>>1095690
>светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит,
А вот это пиздеж. На LED лампы одна лишь гарантия 2 года. Стоит они 100рублей примерно. Охуеть как дорого.

>>1095690
1. Ты пишешь как манерный гей.
2. Даже относительно дорогие леды даже если допустить их малый срок службы, окупаются за счет стоимости электричества. Разница, внезапно, десятикратная.
А так то у меня 10$ LG с 2013 года в ванне светит.

>>1095700
Чем тебе не угодили геи?

>>1095701
>Чем тебе не угодили геи?
Все в порядке с геями, только мы тут RUST обсуждаем, а не женские чувства косметику и наряды.
Для геев есть /ga/.

fn yoba () {
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

>>1095805
Просто ты долбоеб.
https://play.rust-lang.org/?gist=66dde1409bcd0bcd9c646a3c1bd497b0&version=stable

>>1095812
Но про долбоеба это же не точно?

>>1095815
Судя по тому что ты пытаешься assert_eq юзать в качестве условия, точно.

>>1095817
Да я полчаса назад начал его тыкать.

>>1095818
Значит ты пиздец зеленый, раз не знаешь что такое assert.

>>1095820
В Go такого нет.
Как у вас получить последний эелемент слайса?

>>1095822
Ага, по-даунски как в го

>>1095645
Ты просто мастер хуевых аналогий. Иди линукс переписывай.

>>1095715
rc?

>>1095347
>Это еще не факт. Без тестов говорить не о чем.
Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.

>код с указателями на сишечке
Если ты пропустил скучное предисловие, то там сравнивали с go и d. И на них это будет вполне себе безопасно. Давай, заяви про GC и пойдём по второму кругу.

>влияет на производительность на порядок больше способа связывания
Заявление слишком сильное и категоричное, жаль только что не для всех случаев верное. А именно для случаев в которых выделение и освобождение памяти явление относительно редкое, а обращение к объекту - частое. Но тут соглашусь, нужно исходить из задач.

>может оказаться как минимум громоздким и страшным
А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.

>Для крит важного кода, вроде realtime систем, есть ассемблер
Не, ну а как же абстракции с нулевой стоимостью? А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".

>о чем тут собственного говорить и размышлять
Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.


>>1095382
Не, ну а где собираются серьёзные системные программисты как не на двощах. В Mozilla Research что ль, скажешь тоже. А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет, прям хоть в петлю завязывайся. Вроде как вот тебе интрумент для создания красивого правильного, но нерабочего кода, а вот для чтоб работало, но через хуй колено. Всё ж развивается ПО, развиваются трансляторы, языки нескучные появляются, может и заебенят такое что все охуеют.
А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.

>>1095846
Я нубас просто, не расскажешь подробнее?

>>1095863
Чувак, прочитай растбук для начала - они гораздо лучше меня все объяснят.

>>1095860
>А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет
Щито? Ты его мессаджа не понял, видимо.

> интрумент для создания красивого правильного, но нерабочего кода
Ээ... Щито?

> а вот для чтоб работало, но через хуй колено
Чего блядь?

> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать
Ээ... Так как бы "такое количество ограничений как в ржавом" как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни. У меня такое чувство, что тебе тоже надо посоветовать прочитать растбук.

> гарантии тотальности
Ээ, расскажешь, как через афинные типы делать тоталити чек?

>>1095860
>Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
Вместо тестов дезассемблировать?

> то там сравнивали с go и d. И на них это будет вполне себе безопасно
Ну и на расте будет безопасно.

>Заявление слишком сильное и категоричное
Это ты его так просто чувсвуешь.

>Но тут соглашусь, нужно исходить из задач.
Ну вот и славно.

>А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.

>Не, ну а как же абстракции с нулевой стоимостью?
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.

>А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.

>Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
Нет, увольте.

>А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
Ну, раз так все просто, возьми и сделай.

>>1062380 (OP)
Пишут ли уже игори на расте?

>>1095845
Это не я начал.

>>1095822
https://play.rust-lang.org/?gist=1b7ce5c87de05e0733759e8a7936f382&version=stable
unwrap() нужен потому что последнего элемента в общем случае может и не быть, поэтому ты получаешь Option<T>. В продакшн коде менять на expect или паттерн матчинг

>>1095915
Пишут мелкие поделки всякие. Наркоманы пилят amethyst. ggez для 2д норм. piston очевидный.

Ебанутся, оказывается String это не str. Вы там совсем ебанулись, аллё?

>>1096000
Ебануться, оказывается масссив это не слайс. Вы там совсем ебанулись, аллё?

>>1095870
>Ты его мессаджа не понял, видимо.
Да вроде бы понял, но судя по количеству "Щито" в ответе - немного по-своему. Поясню. То что ты говоришь про тестирование и изолирование, в контексте вопроса использования небезопасного кода - безусловно правильно, только уж слишком универсально. Что-то в духе пиздато делай - пиздато будет. Также и сионист будет пояснять за с/спп, у меня, дескать, не течёт нихуя, я весь код изолирую, и ты так делай. Да не раз же в тредах было.

Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.

>как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни
Ты не путаешь причину и следствие? Мне казалось что изначально стояла задача создания системного языка для написания быстрого и безопасного кода, и отсутсвие циклических ссылок тут лишь средство. Подобным же средством могут выступать регионы в языках типа циклона, там наверняка много своей спецефичной поебени, но цели вроде бы те же. Только, пожалуй, совместить эти два подхода очень непросто.

>как через афинные типы делать тоталити чек
Тут я не матёрый дока нихуя, но что-то типа: на каждом шаге один элемент должен быть структурно меньше предыдущего. Есть же языки с подобным, даже императивные. Да и данные благодаря системе типов организуются древовидно в основном А выкинуть Rc<RefCell<什么>> так и вообще всё строго будет .


>>1095877
Ну ты прям громишь по всем пунктам. Спасибо за щеку не накидал ничего.

>>1096219
>я весь код изолирую
Ты хуйню какую-то несешь, скажу прямо. Если одну и ту же функциональность можно реализовать либо на си, либо в два раза быстрее, чем на си, в четыре раза надежнее и без серьезных потерь в производительности, то рационально выбрать второй вариант. Где второй вариант недоступен, там приходится выбирать первый. Количество таких мест надо минимизировать, сами места изолировать. Капитан очевидность, привет. При чем тут сионисты с крестоносцами и как можно "весь код изолировать" - хуй тебя знает.

> универсального формализма
> универсального
> формализма

> люди-то годами работают
Что-то из разряда "бля, ну научному методу уже 2 сотни лет в обед, хули до сих пор не открыли все законы природы" или скорее даже "бля, ну математике уже 2 тыщи лет в обед, хули до сих пор что-то там придумывают".

> Ты не путаешь причину и следствие?
Взаимные ссылки нужны, чтобы добавить ограничения в раст? Для диванного философа ты как-то хуевато с логикой дружишь.

> отсутсвие циклических ссылок тут лишь средство
Да я вроде обратного и не утверждал, не? Отсутствие побочных эффектов - тоже "лишь средство", например. Да и вообще программирование как деятельность - это "лишь средство". И чо? А циклические ссылки - это в любом случае code smell.

> на каждом шаге один элемент должен быть структурно меньше предыдущего
А афинные типы-то тут при чем? Тащем-то, сабтьюринговость достигается запретом явной рекурсии, например.

>>1095350
Можно сурс?

>>1096691
>Можно сурс?
Полея Увода

>>1096257
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.

>Для диванного философа ты как-то хуевато с логикой дружишь.
Причину и первопричину конечно же. К чему так остро острить.

>это в любом случае code smell
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?

>А афинные типы-то тут при чем?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?

>сабтьюринговость достигается запретом явной рекурсии, например
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:

function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}

На ATS, тоже что-то подобное встречалось.


>>1096318
>полной природы вычислительных систем с которыми мы работаем
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.

>Излишество синтаксиса - грех.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?

>>1088181
>>1088243
Если ещё точнее, то Haskell и C

>>1097510
>Ну вся эта полнота
Я речь веду о конкретной полноте, Господь-полноте.

>то глядишь и получим со временем некую заведомо детерминированную модель
Нельзя получить заведомо детерминированную модель в заведомо не детерминированном мире, только если ты не Господь.
Вон даже физики вероятностным распределением оперируют.

>>1097510
> Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций.
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.

> Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.

Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.

> Причину и первопричину конечно же.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.

> как быть с сущностями призванными соответствовать объектам предметной области
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.

> вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.

> не просто численный тип, а численный тип определённый как индекс, некоего массива?
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.

> тип на данные которого может быть всегда только одна ссылка
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.

> какие тут спецефичные проблемы?
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.

> А с неявной проще, или что ты имеешь в виду?
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".

Я пардон за задержку.

>>1097517
>Господь-полноте.
Повторюсь. Не нужно.


>>1097690
>зависит от предметной области, от бизнеса
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.

>Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области?
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.

>При чем тут это вообще? Не улавливаю, куда тебя понесло.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.

>values of values
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.

>ты же через афинные собрался делать тоталити чек
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.

>без кривых костылей вроде "decreases n"
Вкусовщина же. Да и универсальней на мой взгляд.

>>1102675
>корректность в более узком смылсе
Ну это не корректность, а просто более стронг гарантии компилятора. Ок.

> Не, я их рядом не ставил.
Ну ты же сам сказал: как быть с сущностями из домейна, рс с ними использовать или массивы, что-то такое. Я и отвечаю, что "сущности из домейна" и массивы (рс, классы, объекты, хэшмапы...) - это понятия разных уровней.

> В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое.
Я вообще не ебу, о чем ты. Кто тебе в расте запрещает это делать? Какие индексы, какие цифири?

> о преимуществах неизменяемых сущностей над изменяемыми
Нет, не об этом. Посмотри целиком. Алсо, повторюсь с прошлого поста: «Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.» Так что за "конкретные объекты"?

> я лишь пожалел что до меня не сделали
Блядь, я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют. Ты, очевидно, другого мнения, - вот я у тебя и спрашиваю (уже три поста подряд), как ты через афинные типы собрался делать тоталити чек.

> Вкусовщина же. Да и универсальней на мой взгляд.
Натуральный счетчик универсальней рекурсии? Ну, гхм.

>>1102675
>>Господь-полноте.
>Повторюсь. Не нужно.

Повторяю, для детерминированной модели отражающей реальный мир - нужно.

Конечно, ты можешь построить какую угодно модель для чего угодно, но толку от нее, если она не работает?

А чтобы полностью детерминированная модель работала, тебе нужна Господь-полная система.

>>1102797
Вот мы вроде бы и оба на русском пишем, а понимания больше не становится нихуя.

>Я вообще не ебу, о чем ты.
Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок. Их и предполагалось эмулировать через индексы.

>Кто тебе в расте запрещает это делать?
Компилятор запрещает, кто же ещё. По прежнему о той же попытке эмуляции.

>Так что за "конкретные объекты"?
Я, наверное, очень хуёво умею свою мысль донести. Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру, изменяемую или нет. Которую, да, предполагается хранить в этой же самой структуре, например.

>я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют
>Ты, очевидно, другого мнения
Как можно было придти к такому выводу? Я, вроде, сказал про "такое количество ограничений". Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.

>Натуральный счетчик универсальней рекурсии?
Наверняка не скажу, но там и для структурной деконструкции тоже что-то имеется. Ну и взаиморекурсивные вызовы, аккерманы с фибоначами, всё в примерах и рассматривается. Это ли не универсальность?

До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.


>>1102839
Я примерно понял о чём ты. Но тут-то наиболее важнен практический аспект: модель она на то и модель что позволяет абстрагироваться от несущественных в определённом контексте деталей. Не стоит же вопрос целиком весь мир эмулировать.
А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?

Заебали сопли по забору размазывать.
Вот вам ваш двусвязный список из стандратной либы: https://doc.rust-lang.org/src/alloc/linked_list.rs.html#46-51

>>1103142
>Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок.
При чем тут это? Ты написал, что в си можно указатели на структуру передавать в процедуры и не бояться, что туда придет что-то другое, а в расте динамическая типизация. Я и отвечаю: вообще не ебу, о чем ты.

> Компилятор запрещает, кто же ещё.
Не запрещает. Берешь и передаешь.

> Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру
Ну, и ты выше писал, что в расте этих "конкретных объектов" нет, и тебе приходится пользоваться числами и строками. Я тебе еще 2 поста назад сказал, что в расте есть структуры, больше ничего не надо. Теперь выясняется, что ты структуры и имел в виду. Шта.

> Как можно было придти к такому выводу?
Да ты заебал:
>> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
> Ээ, расскажешь, как через афинные типы делать тоталити чек?
>> Тут я не матёрый дока нихуя, но что-то типа: ...

> Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
Ой блядь, ну и нахуя ты об этом тогда вообще пиздеть начал? Ой, все, иди нахуй.

> Это ли не универсальность?
Ну так ты не про универсальность как таковую говорил. Ты утверждал, что "Да и универсальней на мой взгляд". Теперь выясняется, что ты это опять просто от балды спизданул. Пиздос. Нахуй так жить.

> До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
linrec p o f g <=> h x: if p x then o x else g(h(f x)), как-то так. Соответственно, можно иметь разные комбинаторы для разных случаев (и даже с разными типами, в том числе и для unbound рекурсии), а "decreases n" хендлить на уровне обычной системы (зависимых) типов. Комбинаторы - joy, тотальность - charity, например.

>>1103221
И че?

>>1103229
Безопасность подаётся как основная фича языка. А тут, чтобы написать банальный связанный список, потребовалось три десятка раз её подавлять. Боюсь представить, что творится в ентерпрайз коде. Иными словами, основная идея раста разбивается при выходе в реальный мир.

>>1103236
Мудила, ты часто реализуешь низкоуровневые структуры данных в бизнес коде?
Один раз написал и пользуешься во всем проекте. А это вообще в std. Хуле тебе надо-то?

>>1103236
Ща бы думать, что мутабельный список вещь банальная.
Тут как раз отлично отделены безопасные вещи и используя этот список, ты всегда в безопасности.
Вопросы скорее к твоему коду и задумке, если тебе приходится делать unsafe вне библиотек.

>>1103225
Вот как приведённых тобой моих высказываний "могли бы сделать..." и "я не матёрый дока нихуя" можно вывести "ты через афинные типы собрался делать тоталити чек"? Пользуясь аффинной логикой, наверное.

Ну и:
>Да ты заебал
>Ой, все, иди нахуй
>Нахуй так жить
наконец-то пошла конструктивная риторика, сплошные опровержения в чистом виде. Ещё чуть-чуть и сможем воочию лицезреть как рождается истина, в муках выплёвываемая из уродливого влагалища спора. И тут либо я писать нормально не умею, либо ты - читать. Хуй с ним, будет желание, как поправишь нервишки, пересмотри ветку от начала, чтоб не драть почём зря фразы из контекста, а нет - да и в рот её ебать.

>>1103346
Ожидаемо. Я пробегаю глазами релевантные места по всему диалогу перед каждым своим ответом, а ты много пиздишь о том, в чем не шаришь, и идешь нахуй. Это интернеты, добро пожаловать снова.

>>1103142
>А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Абсолютно любая программа.
Чтобы оценить всю принципиальную, а не потенциальную, ограниченность и неполноту, достаточно написать любую сколь нибудь реальную программу, и дать ее юзерам.

Ненужно много теоретизировать, достаточно простейшей практики, блядь. Прости Господи, любому живому человеку, кроме женщин разве что, должно быть понятно, как работает мир. Достаточно в детстве достаточно близко с природой взаимодействовать, получать синяки и прочие травмы.

Любой мат аппарат описывающий реальный мир включает в себя понятие шума и ошибки.
"Шум" - это нечто, от чего нельзя избавится принципиально.

От чего все эти хасхели, и прочие безумные идеи относительно доказтельности вычислений - полнейший бред.
Если мы может доказать, валидность вычисления, то мы фактически УЖЕ его совершили, то есть нам никакая программа ненужна вовсе, все уже посчитано.

Более того, практическое мышление\работа\программирование, не требует доказательств. Можно потратить всю жизнь на выведение доказательств, поиска зависимости в дробной части числа Pi, а можно без задней мысли решать инженерные проблемы.

>>1103709
Ну хаскель-то как раз про вполне себе практичные вещи, хотя изначально для них и не предназначался.

мимо

>>1083507
Хуль тут все кристал вспоминают? Рубисты что ли?
Кристал сдох уже совсем, увы.

>>1103996
>что самое сложное вы уже написали на расте?
хеллоу ворд

>>1062380 (OP)
Сап, есть архив тредов?

>>1104264
Гудбай ворлд.

>>1062380 (OP)
Решил к вам вкатиться и ставлю ентон самый раст. А чего у него такая инсталяха мелкая то?

>>1106168
Если ты про rustup то он тебе доставит нужную версию компилятора.

>>1106240
Сочувствую братишка, тут либо пердолинг с сертификатами (не факт что поможет) либо обход прокси сервера.

Двочь, покажи пример как захуярить на расте аналог горутин типа go someFunc()

Спасибо.

>>1106431
https://rustbyexample.com/std_misc/threads.html
Учти, горутины != потоки.

>>1106431
Поищи либы, гороутины выпелили из базового раста.

>>1106431
В смысле green threads. Так эта шняга правильно называется.

>>1106485

>>1106311
Хз, это уже 2 разных провайдера, падазритльна

>>1106444
>>1106485
>>1106486
>>1106530
Спасибо, пацаны, разобрался. Хотя и не так, как в го (там удобнее).

Еще такой момент, у меня есть одна libcore.c для встраиваемых устройств (С99). Но этот ебучий гугл по запросу `rust cffi example` подсовывает мне `calling rust from python` и подобное. Дайте, пожалуйста, пример или ссылку как вызвать из раста условный void hello(){printf("hello\n");}

>>1106431
https://doc.rust-lang.org/book/first-edition/ffi.html

Поясните, почему этот ваш раст гуглится вместе с идрисом, агдой? Он что с зависимыми типами?

>>1106977
Пример запроса в студию.

>>1106965
Код 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.

>>1106989
Ага, вкурил. А как мне -llibcore передать расту?

>>1106991
http://doc.crates.io/build-script.html

>>1106992
Спасибо

>>1087937
Ну и чем это лучше C?

>>1094144
Cpp -- общемировой стандарт с самым большим комьюнити, базой знаний, сумасшедшей кроссплатформенностью.

Зачем вообще плодить сущности, если они отличается какими-то там ссылками?

>>1111575
Гребаные гуманитарии, вон из профессии.

>>1111578
Давайте на ассемблере писать, зачем плодить сущности))00)

>>1111575
>>1111578
https://www.youtube.com/watch?v=ksirw1v5gXk

>>1111584
Но зачем придумывать точно такой же язык?
На ассемблере и пишут то, что нельзя написать на С.
На ассемблере нельзя писать переносимый код.

>>1111594
>Но зачем придумывать точно такой же язык?
Никто и не придумывает точно такой же язык. Просто ты либо тупенький, либо жирненький-зелененький.

>На ассемблере нельзя писать переносимый код.
А на си - типобезопасный, и что?

Иди тролли в другом месте.

>>1111595

Типобезопасность != без ошибок.

Зато такие языки всегда будут неэффективными=)

>>1111925
> такие языки всегда будут неэффективными
скажи это расту

А типобезопасность расслабит голову на 99%, оставив место для действительно важных вещей, логики например.

>>1111578
Потому что c++ тридцатилетний ворох костылей и замечательных решений.

>>1062380 (OP)
Как сделать итератор по &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]

>>1070417
Навскидку, если ты скомпилируешь что-то на языке Dafny, то оно заработает без косяков.

>>1113004
Навскидку, ты и Hello World не напишешь на Dafny. Лол, потому что НЕВОЗМОЖНО

>>1112555
Как включить эту штуку глобально, чтобы не пихать в каждый файл?

>>1113058
Ок, завезли method Main, походу становится можно писать standalone applications.

>>1113138
> пикрелейтед
Просто у туземцев есть дигри по комплюктер сцайенс, так что параметрический полиморфизм они и называют параметрическим полиморфизмом, а инопланетных джава-макак делают вид, что не понимают.

>>1113211
Если бы это было так, цены бы туземцам не было. Но увы.

>>1113211
Это у промышленных макак называется параметрическим полиморфизмом, а в академии это статический полиморфизм.

>>1113213
Увы.

>>1113248
А вот и настоящий, риал-ворлд туземец подъехал, лол.

>>1113453
Просвещайтесь https://en.wikipedia.org/wiki/Polymorphism_(computer_science)#Static_and_dynamic_polymorphism

>>1113484
Статик — это C++ костыли, а оригинальный параметрический полиморфизм из ML 70-ых годов.

>>1113484
> Static polymorphism typically occurs in ad hoc polymorphism and parametric polymorphism, whereas dynamic polymorphism is usual for subtype polymorphism.
Почему ты настолько тупой, что даже текст по собственной ссылке прочитать не можешь?

>>1113596
Щас бы спорить с быдлом о дефинициях. Но давай, мне интересно посмотреть, как ты будешь вертеться, объясняя мне, где я не прав.

>>1113586
Но в ML вычисление параметризованного типа происходит точно так же как и специализация шаблона с крестах - во время компиляции, вот почему терминологически static polymorphism более удачен даже если не вспоминать про ad hoc полиморфизм - с тайпклассами или рабоче-крестьянски.

>>1113684
Он не имеет смысла, потому что это низкоуровневая деталь, а не суть, к тому же там все статик.

Как же вы заебали со своим нытьем. Уебывайте в хаскель тред нахуй.

>>1113705
>Различие языков по динамической и статической типизации не имеет смысла, это низкоуровневая деталь

>>1113681
Перечитай свои же посты. Потом иди sicp изучай.

>>1113807
Зарепортил за жирный троллинг тупостью.

Зачем нужен раст, когда есть пиздатый голенг?

>>1113959
1) гц
2) нет дженериков

>>1113960
Зачем ты назвал преимущества го?

>>1113973
Если в твоем случае это преимущества, то тебе раст не нужен.

>>1113960
>1) гц
в расте нет гц

>>1114454
Жирный, очевидно были приведены пункты которые в определенных ситуациях являются недостатками голенга.

>>1114455
>пределенных ситуациях являются недостатками голенга.
а, ну ок.

>>1116277
> ORM
> Язык без какого-либо намека на ооп, с полностью функциональной системой типов.

>>1116569
Шо сказать то хотел?

>>1116569
> полностью функциональной системой типов.
Это как? Просвети. Бывают, значит, не полностью функциональные, а бывают совсем не функциональные, так? Накидай-ка примерчиков всех трех.

>>1116655
Функциональные в смысле те, что использующиеся в языках, традиционно называющихся функциональными.
То есть алгебраические типы данных с хаскеллевыми тайпклассами.

>>1117648
Ну и как это противоречит идеи ORM?

>>1117787
Да никак. Этот >>1117648 нахватался разных умных слов и пытается их комбинировать.

>>1116277
>Асинк делоть
ОТКРЫЛ ВКЛАДКУ https://tokio.rs
@
ПРИМЕР НА ИНДЕКСНОЙ
@
.unwrap();
@
.unwrap();
@
.UNWRAP();
@
ЗАКРЫЛ ВКЛАДКУ

>>1117939
Прикинь, программирование оно такое. Дохуя где могут быть ошибки.
Конечно try {} catch () {} наше все, да?

>>1117952
Получше чем
.похуй();
.похуй();
.забей();

>>1117953
Мань, ну че ты как маленький. В main пока нельзя пользоваться ?try!(). Поэтому в примерах юзают unwrap().
В настоящем коде это будет либо прокинуто наверх через ? либо expect()

>>1117953
охуеть
.похуй()
.похуй()
.забей()
.наБлядстве(пукнуть);

>>1117961
Ну если ты так пишешь код, то кто тебе в этом виноват?

>>1117971
Че? Что в этом плохого?

>>1117987
Зачем вы постите несмешное?

>>1117787
В определении ORM. Хотя сама библиотека адекватна и ORM можно упомянуть, чтобы хотя-бы пояснить назначение библиотеки (аналог ORM-ов из ваших ооп-языков)

>>1117939
А как по-твоему должен асинк работать? Поменяешь на andThen в продакшене и поедешь

>>1118156
Ну так в чем проблема-то?
> 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) который вариант енама?

>>1121314
Пример полноценный покажи.

>>1121317
Какой пример? Вопрос самодостаточен, можешь вообще читать только последние два предложения.
Вкратце, Стив Клабник мне ответил, что Some это есть функция, которая возвращает Option. А как тогда выглядит собственно сам Some, именно вариант, не функция? То есть let hueta = Some(5), какой тип у hueta? Просто Option<i32>? То есть я не могу просто так взять и без паттерн матчинга понять, что содержится в хуете.
Это касается так же и всех остальных енамов.
По ходу, это просто такое у них устройство на низком уровне.
Но все равно как-то мутно для меня это всё

>>1121319
Палю лайфпхак: https://play.rust-lang.org/?gist=ed3c4a40f28e2b8e9e4a7782a1c8211e&version=stable

>>1121323
Дык я об этом и говорю.
Если и обоих вариантов, иу Some, и у None общий тип - то выходит блядь простым смертным недоступно узнать разницу между ними на уровне имплементации самих енамов. Все что нам дают - возможность сравнивать и матчить. Я все правильно всосал?

>>1121326
В этом и заключается главный смысл.
Ты обязан тем или иным образом обработать разные варианты енума.
map точно так же внутри себя делает паттерн матчинг

match option {
Some(x) => f(x),
None => None,
}

>>1121328
На огороде бузина.
Ты ответил не совсем на то, о чем я спрашивал.
Ватевер, принцип я вкурил, а дальше буду адаптироваться.

>>1121332
Ну в общем случае енумы это tagged union
[tag, max(enum_variant)]
В случае Option используется NULL для None и указатель на данные иначе.

>>1121314
>>1121319
Ты путаешь конструктор типа и тип. Алсо, ты немного путаешь рантайм и компайлтайм.

Спросил в треде про Пщ, спрошу и здесь. Знатоки Rust, расскажите, пожалуйста, что в Rust есть хорошего, и что плохого.

>>1126612
Мне интересно мнение прошаренных людей, которые уже как следует изучили Rust и могут описать все или почти все его недостатки.

>>1127088
Основной недостаток - взрыв мозга при первой встрече с борроу-чекером и вообще писать, "как на других языках", не получается. Ну то есть, читай, порог вхождения высоковат.

>>1081347
Ох уж эти манямиры прыщеблядей.

>>1127822
Почему недостатоток? Это же киллер-фича, пересмотр сложившейся традиции построения ЯП.

>>1128431
Глупо конечно это отрицать. Но так же глупо отрицать то, что в это надо въехать. Хотя мне кажется многие через чур драматизируют по этому поводу, система владения в русте достаточно простая, раз в нее смогла за день въехать такая жс/го макака как я.

>>1128458
Да это те же пойнтеры, только компилятор с ними очень строгий: или кто-то один пишет, или все читают. По сути компилятор тебя и обучает.

Сидел, читал доки по Rust - на первый взгляд, такой толковый язык. Полез смотреть разные заказы/вакансии по нему - и почти нигде ничего.
Грустно.
Пока что Rust - это, похоже, язык-мем.

Для каких задач раст хорошо подходит, а для каких его лучше не использовать?

>>1130201
Для задач где го недостаточно выразительный, всякие джавы/сисярпы/хаскели медленные и прожорливые, с/с++ недостаточно простые и безопасные.

>>1130816
Расскажи примеры таких задач, анон, плз.

>>1130839
Скажем делаешь ты игру. У игры есть очень четкое требование — успевать всю хуйню сделать за 16мс, чтобы ты получил свои 60фпс. А голанг может тебе хуйню сборку мусора на 10мс.

Плюс рано или позно тебя заебет копипастить слайс-трикс и код в целом, потому что нет дженериков.

>>1130201
Переписали на нем с джавы софтину, которая 24/365 крутилась на cortex-a5 256mb ram. Теперь переписываем с C код для cortex-m4 128kb sram.
Сначала было непросто понять, что хочет компилятор и борроу-чекер, теперь придрочились. Во втором случае еще и с сетапом/инициализацией пришлось повозиться (то что пилит japaric нам не подошло).
Еще можешь глянуть Макса Лапшина на highload++, он для камер на ARMv5 пилит чото.

>>1130860
И как тебе раст после сишки?
>>1130840
Дело в дженериках и gc?

>>1131144
Еще дело в более выразительной системе типов и возможности писать безопасный многопоточный код.

Каналы и горутины это конечно хорошо, но они ни капли не спасают от того что рантайм го может тебе крашануть приложение из-за небезопасного доступа к map.

>>1131184
Т.е. Rust лучше Go?

>>1131193
В многих аспектах да.
За это приходится платишь более высокой сложностью вкатывания, более медленной компиляцией и пока что меньшим размером коммьюнити. Впрочем, раст моложе и вангую что через 3-5 лет он будет так же популярен как и го в своей нише.

>>1131193
https://play.golang.org/p/6Aft5JuiVc4
Попробуй такое же сделать расте.

>>1131214
Знать бы ещё что эта хуета делает.

>>1131253
Эта хуета показывает что го никак тебя не защищает от проблем многопоточного кода. В данном случае я спокойно могу иметь несколько ссылок на хэш-таблицу и модифицировать её в разных тредах, при этом закономерно получая фатальную ошибку которая никак не ловится.

>>1131253
В том то и проблема го, что многие го программисты(читай бывшие скриптомакаки) не понимают, что этот код работает не правило и такого не должно быть.

>>1131542
Почему проблема? Это заявленная фича. Скриптомакакам должно быть легко вкатываться и индусить код во блага хозяина.

Котоны нубасы, чего вам не хватает для того чтобы вкатится в раст?

>>1132080
Стандарта или хотя бы кс-грамматики.

>>1132103
Нахуя тебе стандарт?

>>1132108
Предлагаешь читать очередную воду для вкатывальщиков?

>>1132115
Возьми programming rust. Воды очень мало и вообще очень хорошая книжка.

>>1132118
>programming rust
Pages: 622

>>1132121
Да, там пол книжки про стандартную либу и как с её помощью решать задачи. При этом написано хорошо, а не в стиле референса.

>>1132123
Ну что ж, посмотрю. Вообще я поковырял палкой их справку, довольно интересный яп.

>>1132129
Можешь начать с оф. книжки. Она короткая и по делу.

>>1132622
Ну во первых вакансии уже появляются. А во вторых, хочешь работы, учи пхп.