Двач.hk не отвечает.
Вы видите копию треда, сохраненную 25 апреля 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 25 апреля 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Тред убийцы c++.
https://www.rust-lang.org
https://doc.rust-lang.org/book/
https://rustbyexample.com/
https://github.com/rust-unofficial/awesome-rust
Старый тред тонет тут >>956909 (OP)
https://www.rust-lang.org
https://doc.rust-lang.org/book/
https://rustbyexample.com/
https://github.com/rust-unofficial/awesome-rust
Старый тред тонет тут >>956909 (OP)
>>062391
GC
GC
>>062391
Ну и
Ну и
> The project is in alpha stage: we are still tweaking the language and standard library.
>>062432
Ну ноджс это детские очки. Можно надеть на себя, будет глупо выглядеть, оптическими свойствами не обладает, но можно честно сказать "я ношу очки".
Раст это гугл-глас с нейроинтерфейсом.
Ну ноджс это детские очки. Можно надеть на себя, будет глупо выглядеть, оптическими свойствами не обладает, но можно честно сказать "я ношу очки".
Раст это гугл-глас с нейроинтерфейсом.
>>062432
В том, что для nodejs нативные модули пишутся не на говноязыках, а на годноте. Npm давно использует rust у как средство улучшения developer experience
В том, что для nodejs нативные модули пишутся не на говноязыках, а на годноте. Npm давно использует rust у как средство улучшения developer experience
>>062583
На чем пишутся модули, на C или JS (хочу понять что ты называешь годнотой)? Каким образом NPM использует Rust, это ты сам придумал?
На чем пишутся модули, на C или JS (хочу понять что ты называешь годнотой)? Каким образом NPM использует Rust, это ты сам придумал?
>>062704
Вместо C можно (нужно) использовать Rust
Вместо C можно (нужно) использовать Rust
>>062380 (OP)
Объясните, зачем в раст добавили сишное говно - строки cstring? Почему нельзя было просто взять и сделать язык без наследия далекого прошлого?
Объясните, зачем в раст добавили сишное говно - строки cstring? Почему нельзя было просто взять и сделать язык без наследия далекого прошлого?
>>062819
Очевидный интероп.
>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.
Очевидный интероп.
>>062825
Всем кто пишет проекты сложнее laba3.exe
Биндинги к сишным либам по твоему получаются магическим образом?
Всем кто пишет проекты сложнее laba3.exe
Биндинги к сишным либам по твоему получаются магическим образом?
Так-с, чего молчим? Никто не хочет абстракции с нулевой стоимостью?
>>062380 (OP)
Есть расширение для VS17 или лучше расширение для VS code адекватное для компиляции и отладки?
Есть расширение для VS17 или лучше расширение для VS code адекватное для компиляции и отладки?
>>062380 (OP)
Интересный язык. Правда, сложно заставить себя писать именно на расте, а не на Си с растовским синтаксисом.
Интересный язык. Правда, сложно заставить себя писать именно на расте, а не на Си с растовским синтаксисом.
>>063814
Это нормальная история при перекате на новый язык.
Это нормальная история при перекате на новый язык.
113 Кб, 1190x1698Туториал о том как сделать игорь.
http://piston-tutorial.logdown.com/pages/table-of-contents
http://piston-tutorial.logdown.com/pages/table-of-contents
Насколько ржавчина надежна/безопасна? Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром? Или все, что написано на чистом расте, гарантированно корректно?
>>064450
Можно.
Но к безопасности и надежности это отношения не имеет.
> Можно ли, не открывая растономикон, написать сломанную программу с сегфолтами, переполнениями буфера и прочим добром?
Можно.
Но к безопасности и надежности это отношения не имеет.
>>062434
Rust это Google Cardboard
Rust это Google Cardboard
Насмотрелся роликов на ютубе про безопасный Раст. Начал писать. Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями. Да и вообще поймал себя на том, что слишком часто я использую эти "опасные" операции. Либо надо полностью менять ментальность, либо одно из двух.
>>064685
Пипец, если ты собираешься стать программистом, тебя столько разочарований ждет. Лучше займись чем-то другим.
Пипец, если ты собираешься стать программистом, тебя столько разочарований ждет. Лучше займись чем-то другим.
>>064469
А небольшой пример такого кода где найти?
Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
>Можно.
А небольшой пример такого кода где найти?
>Но к безопасности и надежности это отношения не имеет.
Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
>>064708
Херачиш унсейф.
Надежность\безопасность ЯП\среды, и реализованного на этом ЯП кода - вещи разные.
Безопасна ли машина с подушкой безопасности? - безопасна.
Безопасно ли врезаться в столб на скорость 200км в час с не пристегнутыми ремнями?
>А небольшой пример такого кода где найти?
Херачиш унсейф.
>Странный тезис. Код, который иногда падает с сегфолтом, сложно назвать надежным.
Надежность\безопасность ЯП\среды, и реализованного на этом ЯП кода - вещи разные.
Безопасна ли машина с подушкой безопасности? - безопасна.
Безопасно ли врезаться в столб на скорость 200км в час с не пристегнутыми ремнями?
>>064710
Да даже с престегнутым и с рабочей подушкой безопасности так себе идея. Но фанатикам не объяснить.
Да даже с престегнутым и с рабочей подушкой безопасности так себе идея. Но фанатикам не объяснить.
> Купили как-то суровым сибирским лесорубам японскую бензопилу.
> Собрались в кружок лесорубы, решили ее испытать.
> Завели ее, подсунули ей деревце.
> «Вжик» — сказала японская пила.
> «У, бля...» — сказали лесорубы.
> Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
> «Ух, бля!» — сказали лесорубы.
> Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
> «Ух ты, бля!!» — сказали лесорубы.
> Подсунули ей железный лом. «КРЯК!» — сказала пила.
> «Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами…
>>064715
Да то не фанатик, а просто ребенок, который мало чего в этом самом программировании понимает.
>Но фанатикам не объяснить.
Да то не фанатик, а просто ребенок, который мало чего в этом самом программировании понимает.
>>064856
Ну да, из опыта.
Из наблюдений, здравого смысла, и выводов.
Многим молодым людям, программирование видится чем-то очень интересным, особенным. Они видят написание кода как интересную задачу, создание чего-то красивого, идеального.
Но в реальности, это неблагодарный, монотонный, тяжёлый труд, по созданию комка костылей склеенных соплями.
Нет красоты, нет консистентности, нет идеальности. Есть бесконечный копипаст и забагованные текущие либы.
Костыльность и неидеальность нужно принять как должное.
А если такого органичного принятия нет, человек будет страдать, всю жизнь быть может.
>>064798
IT как таковое. Качество людей в нем работающих.
Не переношу бракоделов, профанов, и самодуров. Нет уважения к своему труду.
А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.
Ну да, из опыта.
Из наблюдений, здравого смысла, и выводов.
Многим молодым людям, программирование видится чем-то очень интересным, особенным. Они видят написание кода как интересную задачу, создание чего-то красивого, идеального.
Но в реальности, это неблагодарный, монотонный, тяжёлый труд, по созданию комка костылей склеенных соплями.
Нет красоты, нет консистентности, нет идеальности. Есть бесконечный копипаст и забагованные текущие либы.
Костыльность и неидеальность нужно принять как должное.
А если такого органичного принятия нет, человек будет страдать, всю жизнь быть может.
>>064798
>И что же конкретно тебя разочаровало?
IT как таковое. Качество людей в нем работающих.
Не переношу бракоделов, профанов, и самодуров. Нет уважения к своему труду.
А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.
>>064685
Ты явно преувеличиваешь.
Насколько я помню, винапи вполне элементарно.
Даже на ассемблере беспроблемно окошечки создавать.
> Чтобы открыть окошко в виндовз мне нужно вызвать с десяток unsafe функций с сырыми указателями.
Ты явно преувеличиваешь.
Насколько я помню, винапи вполне элементарно.
Даже на ассемблере беспроблемно окошечки создавать.
>>064857
Только что компилил проект на виртуалке с виндой. крейт winapi прекрасно сконпелился.
Только что компилил проект на виртуалке с виндой. крейт winapi прекрасно сконпелился.
>>064865
Там во всех областях. Красоту нужно уметь видеть, это субъективная история. Если ты не видишь её, то это не значит что её не видят другие.
А что касатеся "шахтеров", то что в этом удивительного? Профессия новая, особенно на постсоветском пространстве.
Там во всех областях. Красоту нужно уметь видеть, это субъективная история. Если ты не видишь её, то это не значит что её не видят другие.
А что касатеся "шахтеров", то что в этом удивительного? Профессия новая, особенно на постсоветском пространстве.
>>064708
Ну я в этом вашем расте не силен, но насколько я помню он гарантирует безопасность памяти. Однако утечки памяти можно множеством способов устроить. Например, накостылить бесконечный цикл. От такой рукожопости ни один яп не убережет.
Ну я в этом вашем расте не силен, но насколько я помню он гарантирует безопасность памяти. Однако утечки памяти можно множеством способов устроить. Например, накостылить бесконечный цикл. От такой рукожопости ни один яп не убережет.
>>064916
Можно всё.
Можно всё.
494 Кб, 1306x736Делаю игорь для дрочения хираганы. Зависимость есть, брат жив.
Бред уровня запрета ЦП. Избежать ошибок можно только одним способом - не быть криворуким дауном. Для этого не надо создавать ещё один бесполезный язык и говорить, что он лучше C/CXX.
>>070417
Работает только в проектах уровня лаба1.
> Избежать ошибок можно только одним способом - не быть криворуким дауном
Работает только в проектах уровня лаба1.
>>070417
Пиши на ассемблере, хуле ты как не мужик.
Пиши на ассемблере, хуле ты как не мужик.
>>070417
Аюсолютно каждый программист криворукий даун в той или иной степени. Поэтому лучше пользоваться языком который позволит автоматически избегать определённого класса ошибок.
> не быть криворуким дауном
Аюсолютно каждый программист криворукий даун в той или иной степени. Поэтому лучше пользоваться языком который позволит автоматически избегать определённого класса ошибок.
>>070417
Все ошибаются.
Все ошибаются.
>>070417
На любое обвинение у сибляди есть универсальный ответ - "криворукость". Этим сиблядь как-бы намекает, что что все вокруг криворуки - т.е. сотрудники микрософта и интеля, пишущие кривые драйвера и библиотеки, прыщебляди, пишущие дырявое ведро своей системы вот уже не первый десяток лет, просто другие сибляди из соседнего подвала полусвовковой шаражки, в которой сиблядь работает. А вот сама сиблядь - сука граф Шарль Ожье де Бац де Кастельмор д’Артаньян среди педерастов, владеющий техникой левитации, предсказания будущего и написания небыдлокода на сишке. К сожалению, простым смертным едва ли не удастся увидеть творения сенсея, так и будут они работать с глючным говном криворуких интелевских и микросовтовских инжеренов, внезапно падающим от какого-нибудь buffer overflow, несмотря на зиллионы человекочасов, проёбанных на его тестирование и отладку.
На любое обвинение у сибляди есть универсальный ответ - "криворукость". Этим сиблядь как-бы намекает, что что все вокруг криворуки - т.е. сотрудники микрософта и интеля, пишущие кривые драйвера и библиотеки, прыщебляди, пишущие дырявое ведро своей системы вот уже не первый десяток лет, просто другие сибляди из соседнего подвала полусвовковой шаражки, в которой сиблядь работает. А вот сама сиблядь - сука граф Шарль Ожье де Бац де Кастельмор д’Артаньян среди педерастов, владеющий техникой левитации, предсказания будущего и написания небыдлокода на сишке. К сожалению, простым смертным едва ли не удастся увидеть творения сенсея, так и будут они работать с глючным говном криворуких интелевских и микросовтовских инжеренов, внезапно падающим от какого-нибудь buffer overflow, несмотря на зиллионы человекочасов, проёбанных на его тестирование и отладку.
>>070429
Утечка памяти это когда память проебывается все больше и больше по мере работы программы. Что не так?
Утечка памяти это когда память проебывается все больше и больше по мере работы программы. Что не так?
>>064971
Утечка - это если к динамической памяти нет вообще никакого способа обратиться. Если же ты никогда не теряешь ссылки, то всегда сможешь увидеть в отладчике странный вектор на миллиард элементов или типа того. Т.е., память просто избыточно выделяется, а не утекает.
Утечка - это если к динамической памяти нет вообще никакого способа обратиться. Если же ты никогда не теряешь ссылки, то всегда сможешь увидеть в отладчике странный вектор на миллиард элементов или типа того. Т.е., память просто избыточно выделяется, а не утекает.
>>080928
С хуя бы? Розовые стекла в хачкеле, например. С дырочками.
С хуя бы? Розовые стекла в хачкеле, например. С дырочками.
>>072056
Сука орнул с поста. Но идика ты нахуй, все заебись на С написано и у интела и у прыщеблядей, прыщикс вообще самое лучшее что создавали за последние десятки лет программисты. Единственное в чем я с тобой согласен это про майкрософт, там действительно пиздецовые дауны на С так наговнокодили что пиздец.
>граф Шарль Ожье де Бац де Кастельмор д’Артаньян
Сука орнул с поста. Но идика ты нахуй, все заебись на С написано и у интела и у прыщеблядей, прыщикс вообще самое лучшее что создавали за последние десятки лет программисты. Единственное в чем я с тобой согласен это про майкрософт, там действительно пиздецовые дауны на С так наговнокодили что пиздец.
>>081013
Я хуй знает я не слежу за графиками, ибо какой от этого толк? Даже если там и у прыщикса больше чем у спермы, то толко потмоу что прыщикс разрабатывают в сотни раз больше людей чем сперму, и еще учитывай что в сперме намеренно делются уязвимости для различных спец. служб, как недавно было с атаками шифровальщиков которые использовали уязвимости сделанные специально для АНБ.
Я хуй знает я не слежу за графиками, ибо какой от этого толк? Даже если там и у прыщикса больше чем у спермы, то толко потмоу что прыщикс разрабатывают в сотни раз больше людей чем сперму, и еще учитывай что в сперме намеренно делются уязвимости для различных спец. служб, как недавно было с атаками шифровальщиков которые использовали уязвимости сделанные специально для АНБ.
>>081583
Чет ты сочиняешь уже
Утечка памяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.
Чет ты сочиняешь уже
Утечка памяти (англ. memory leak) — процесс неконтролируемого уменьшения объёма свободной оперативной или виртуальной памяти компьютера, связанный с ошибками в работающих программах, вовремя не освобождающих ненужные уже участки памяти, или с ошибками системных служб контроля памяти.
>>081637
Мань, че ты тупенький такой? Сам же пастишь:
Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить. Но если ты проебал указатель, то есть физически освободить сама программа её уже не может, это как раз "неконтролируемое" уменьшение.
Мань, че ты тупенький такой? Сам же пастишь:
> неконтролируемого уменьшения объёма
Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить. Но если ты проебал указатель, то есть физически освободить сама программа её уже не может, это как раз "неконтролируемое" уменьшение.
>>081649
Кек, то что ты пытаешься втереть вообще не существенно. Даже если в теории ты можешь контролировать разбухшую память, но в программе такое поведение не предусмотрено, то это все равно будет утечкой. О чем ты пытаешься кукарекнуть уже относится к безопасности памяти, то, от чего раст защищает в 100 и 100 случаев если не врубать unsafe.
Кек, то что ты пытаешься втереть вообще не существенно. Даже если в теории ты можешь контролировать разбухшую память, но в программе такое поведение не предусмотрено, то это все равно будет утечкой. О чем ты пытаешься кукарекнуть уже относится к безопасности памяти, то, от чего раст защищает в 100 и 100 случаев если не врубать unsafe.
>>062380 (OP)
Чо там с const generics? HKT до 2.0 не появятся, я так понял а тогда уже и голанх 2 подъедет со своими дженериками
Чо там с const generics? HKT до 2.0 не появятся, я так понял а тогда уже и голанх 2 подъедет со своими дженериками
У раста есть какой-то казуальный режим для плебса, который пишет на питоне и JS?
>>083135
Go
Go
>>083135
Раст это инструмент для решения задач имеющий определенный набор характеристик. Если тебе нужна простота, то действительно, возьми го.
Раст это инструмент для решения задач имеющий определенный набор характеристик. Если тебе нужна простота, то действительно, возьми го.
Ваще не одупляю, почему люди вспоминают о го в контексте раста и наоборот. Языки вообще никак не связаны.
Мне кажется как казуальный раст нужно упоминать кристал. Только там вроде пока мультитрединг внятный не сделали.
>>081637
Из твоей же вики:
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]
>неконтролируемого
Из твоей же вики:
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]
>>084307
Короче, отличие в том, что с утечкой памяти сделать уже нихуя, а утечки `пространства` можно попытаться избежать грамотным проектированием
Короче, отличие в том, что с утечкой памяти сделать уже нихуя, а утечки `пространства` можно попытаться избежать грамотным проектированием
>>081649
Речь шла о менеджет языке я так понимаю. Изначально.
Так вот, в менеджет коде, у тебя нет "на нее указателей", они есть у среды выполнения(необязательно), так что по этому пунку - сие есть утечка.
Дальше, давай разберем тобой написанное, ты тут сам выдумаешь значения терминов, фантазер, тебе лет то сколько?
Какая в жопу разница, есть указатель, или нет, если память не освобождается там, где должна?
С таки то подходом после закрытия приложения память все равно освободится так что утечки нет1111)))))))
Иди сделай бочку, реатрд.
>Если ты жрешь много памяти и у тебя есть на неё указатели, то это контролируемое уменьшение. Потому что ты всегда можешь её освободить.
Речь шла о менеджет языке я так понимаю. Изначально.
Так вот, в менеджет коде, у тебя нет "на нее указателей", они есть у среды выполнения(необязательно), так что по этому пунку - сие есть утечка.
Дальше, давай разберем тобой написанное, ты тут сам выдумаешь значения терминов, фантазер, тебе лет то сколько?
Какая в жопу разница, есть указатель, или нет, если память не освобождается там, где должна?
С таки то подходом после закрытия приложения память все равно освободится так что утечки нет1111)))))))
Иди сделай бочку, реатрд.
>>084307
Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
>space leak is released, but later than expected.
Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
>>084693
Уже 10 раз объяснили:
Если память жрется больше чем надо, никогда не чистится, то это не утечка памяти. А space leak. "программа жрет много памяти потому что хуевый алгоритм". Называй как хочешь.
Языки с гц могут течь, например, если гц делает reference count.
Уже 10 раз объяснили:
> A space leak occurs when a computer program uses more memory than necessary.
Если память жрется больше чем надо, никогда не чистится, то это не утечка памяти. А space leak. "программа жрет много памяти потому что хуевый алгоритм". Называй как хочешь.
Языки с гц могут течь, например, если гц делает reference count.
>>084713
Ты сам себе противоречишь.
>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.
Ты сам себе противоречишь.
>>085354
Например?
Я пилю игрушку, например. Две недели пытался завести её на андроиде, но нихуя не вышло. Плюнул, пилю под декстоп пока.
Например?
Я пилю игрушку, например. Две недели пытался завести её на андроиде, но нихуя не вышло. Плюнул, пилю под декстоп пока.
>>084693
Утечка памяти.
>Ну а к чему относить поведение которое не пробывает ссылки ( например язык с гц) но из-за ебанутого кода никогда не очищает накапливающуюся память?
Утечка памяти.
>>085442
Как пытался завести? Я тоже хочу написать игру.
Как пытался завести? Я тоже хочу написать игру.
Какие есть для Rust веб-фреймворки?
Так короче растоблядки. У вас есть минута чтоб пояснит ьмне чем ваш раст лучше golang или D?
не пишу ни на одном из этих языков, но очень желаю смерти с++
не пишу ни на одном из этих языков, но очень желаю смерти с++
>>086357
В Ди есть гарбедж коллектор, а в Ржавом не нужен из-за передачи ownership'а и прочих плюшек.
Голанг не имеет такой развитой системы макросов.
В Ди есть гарбедж коллектор, а в Ржавом не нужен из-за передачи ownership'а и прочих плюшек.
Голанг не имеет такой развитой системы макросов.
>>086358
А как в ржавом тогда ресурсы особождаются? Время же недетерминированно становится. Например, если удаляется какой-то сложный объект который влечет за собой кучу деаллокейтов ? В то время как в языке с GC, это удалится потом и не вызовет задержки программы.
А как в ржавом тогда ресурсы особождаются? Время же недетерминированно становится. Например, если удаляется какой-то сложный объект который влечет за собой кучу деаллокейтов ? В то время как в языке с GC, это удалится потом и не вызовет задержки программы.
>>086569
Долбоебина, может сначала бы прочитал дальнейшие посты, прежде чем высирать тут что-то?
Долбоебина, может сначала бы прочитал дальнейшие посты, прежде чем высирать тут что-то?
>>086471
Вот это действительно хорошо заделали. А пример можешь привести? А то меня всё время смущало, вот вроде бы скорость, детерминированность, безопасность, а как освобождать глубоко вложенную структуру, так и мало того кто последний тот и ебётся, так и ещё свалится с запросто. Тут вообще комбо получается: переполнение стека, да ещё и в деструкторе.
мимо другой анон
>Время каждого ресурса определено статически с помощью системы типов.
Вот это действительно хорошо заделали. А пример можешь привести? А то меня всё время смущало, вот вроде бы скорость, детерминированность, безопасность, а как освобождать глубоко вложенную структуру, так и мало того кто последний тот и ебётся, так и ещё свалится с запросто. Тут вообще комбо получается: переполнение стека, да ещё и в деструкторе.
мимо другой анон
кто-нибудь из присутствующих пробовал писать игрушки на расте с использованием piston или amethyst? если да, то отпишитесь как полет
>>086996
Фак. Написал длинную телегу и куда-то не туда нажал.
На каждый объект в Расте может быть либо одна ссылка, через которую объект можно менять, либо сколько угодно read-only. Кроме того, ссылка не может жить дольше, чем объект, на который она ссылается. Передача же не по ссылке - это аналог std::move в плюсах.
Это позволяет удостовериться, что как только переменная вышла из своей области видимости, её можно смело удалять, не оставив никаких висячих указателей.
Система не идеальна, и для некоторых вещей нужен unsafe-блок, который позволяет использовать обыкновенные указатели. В таком случае на программисте лежит ответственность сделать так, чтобы в интерфейсе поддерживался инвариант из начала поста.
>Вот это действительно хорошо заделали. А пример можешь привести?
Фак. Написал длинную телегу и куда-то не туда нажал.
На каждый объект в Расте может быть либо одна ссылка, через которую объект можно менять, либо сколько угодно read-only. Кроме того, ссылка не может жить дольше, чем объект, на который она ссылается. Передача же не по ссылке - это аналог std::move в плюсах.
Это позволяет удостовериться, что как только переменная вышла из своей области видимости, её можно смело удалять, не оставив никаких висячих указателей.
Система не идеальна, и для некоторых вещей нужен unsafe-блок, который позволяет использовать обыкновенные указатели. В таком случае на программисте лежит ответственность сделать так, чтобы в интерфейсе поддерживался инвариант из начала поста.
>>087937
Мы с тобой побеседовали хорошо, жаль что про разное только. Изначально анон поинтересовался за финализацию и детерменированность времени на неё. Ну например для структуры N = Z | S N реализованной на, пусть будет, Arc сложность деструкции линейна по времени, а в наивной реализации ещё и по стековой памяти. Для структур же более ветвистых - сложность только растёт. Добавив что если используется какой-то абстрактный типаж, то о времени деструкции сказать вообще вряд ли что-то возможно не рассматривая весь код. И если ресурсом пользовались несколько потоков, то освобождать её предстоит последнему, чем могут быть неприятно удивлены апологеты сборки мусора. Вот я и подумал было, услышав про статическое определение времени каждого ресурса, что решается именно эта проблема.
Мы с тобой побеседовали хорошо, жаль что про разное только. Изначально анон поинтересовался за финализацию и детерменированность времени на неё. Ну например для структуры N = Z | S N реализованной на, пусть будет, Arc сложность деструкции линейна по времени, а в наивной реализации ещё и по стековой памяти. Для структур же более ветвистых - сложность только растёт. Добавив что если используется какой-то абстрактный типаж, то о времени деструкции сказать вообще вряд ли что-то возможно не рассматривая весь код. И если ресурсом пользовались несколько потоков, то освобождать её предстоит последнему, чем могут быть неприятно удивлены апологеты сборки мусора. Вот я и подумал было, услышав про статическое определение времени каждого ресурса, что решается именно эта проблема.
>>088155
Я просто мимо проходил, лол
Использование Arc - это перенос гарантий из статики в рантайм, т.е. компилятор тут ничем не поможет, увы. А многопоточность чисто на борровинге будет максимальным пердолингом.
Я просто мимо проходил, лол
Использование Arc - это перенос гарантий из статики в рантайм, т.е. компилятор тут ничем не поможет, увы. А многопоточность чисто на борровинге будет максимальным пердолингом.
>>088250
Ну вон тот же rayon как сделан. Гарантированно безопасные unsafe блоки заэнкапсулированы внутри, а апи чисто safe
Ну вон тот же rayon как сделан. Гарантированно безопасные unsafe блоки заэнкапсулированы внутри, а апи чисто safe
>>088326
Таки верно. Можно считать, что он на ступень эволюции выше (на 2 выше go)
Таки верно. Можно считать, что он на ступень эволюции выше (на 2 выше go)
>>088159
Что-то типа кликера.
Что-то типа кликера.
>>086996
Лучше всего посмотреть любую презентацию про Rust. Вот натолкнулся на очередную youtu .be/oIikwmeGVYY
Вполне ничего
Лучше всего посмотреть любую презентацию про Rust. Вот натолкнулся на очередную youtu .be/oIikwmeGVYY
Вполне ничего
>>092990
Если кроме пиздона ты ничего больше не видел, вероятно сложновато.
Если кроме пиздона ты ничего больше не видел, вероятно сложновато.
>>092990
Все равно вкатывайся. Материалы хорошие. Узнаешь основы функциональщины, типизации.
Все равно вкатывайся. Материалы хорошие. Узнаешь основы функциональщины, типизации.
>>088326
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.
Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.
Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.
Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?
Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.
Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.
Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.
Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?
Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
>>088326
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.
Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.
Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.
Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?
Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
Ну вопрос конечно поставлен охуительно, да и вопрошающий ведёт себя несколько вызывающе, но в целом тут есть что сравнить. Даже хуй с ним, с изумительным синтаксисом напоминающим вэньянь с комментариями на фарси, тут-то и привыкнуть можно, люди на перле пишут и им заебись. Посмотрим на системы типов этих языков.
Что Д, что Го следуют в русле сложившейся традиции, где-то добавляя мокрописечности, где-то наоборот её убавляя, но в целом человек знакомый с каким-либо императивным языком может относительно легко пересесть на любой из них. Да, каждый из них требует сборщика мусора, и хотя Д позволяет использовать неотслеживаемые указатели, насколько я знаю, стандартная библиотека один чёрт не позволит отказаться он него.
Другое дело Раст, с его довольно сильными гарантиями, временем жизни переменной и и условным отсутствием глобального состояния. И тут человек решивший причаститься будет удивлён невозможностью реализовать добрую половину привычных структур данных. Часть из них конечно уже реализованны в стандартной библиотеке, некоторые можно найти у васянов, но рано или поздно придётся и своё что-то пилить, автореферентная структура частенько востребованна в нашем деле. И один хер придётся использовать небезопасные блоки кода лишаясь всех охуительных преимуществ. То есть при написании какого-то системного кода вся охуительность системы типов не используется, при написании же прикладного - выручает лишь в тривиальных случаях, в остальных же только усложняет жизнь.
Вся практическая выгода заключается лишь в возможности обойтись без GC, хотя как указали выше время удаления ресурса один хуй недетерминированно. При этом напомню система типов запрещает циклические структуры и изменяемые глобальные переменные - вещи пусть и порочные, но глубоко привычные; и при этом допускает: утечки ресурсов, невызов деструкторов, взаимоблокировки, переполнение целого. Я хуй его знает, это адекватной ценой считается?
Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
>>094060
1. Почему придется?
Стейтмент так себе.
Все там можно.
Ты так говоришь, как будто что-то хорошее.
Создавался как то, что должно было появиться, но вместо чего появился С++.
>И один хер придётся использовать небезопасные блоки кода
1. Почему придется?
Стейтмент так себе.
>невозможностью реализовать добрую половину привычных структур данных
Все там можно.
>вещи пусть и порочные, но глубоко привычные
Ты так говоришь, как будто что-то хорошее.
>Дополню вопрос: если отбросить инсинуации злопыхателей про попилы мозиловских денег, он для каких задач и для какой аудитории вообще изобретался?
Создавался как то, что должно было появиться, но вместо чего появился С++.
>>094144
Вот продемонстрируй мне двусвязный список, руками, а не из коробки или же дерево где дочерняя ветвь хранит ссылку на родителя, и я пристыженный уйду. Нет, я допускаю что можно всё организовать в массив и в структуре хранить индексы запроместо указателей, но былой стремительностью такой подход уже не похвастается.
Я вроде ж указал на заведумую порочность. Другое дело, что сторонние-то функции далеко не все реентерабельны. Заодно поясните, я наткнулся раз на демку в которой рисуются красные квадраты, как GL адаптировали? Ну я о том, что в два потока не порисуешь ведь - хуета получится, стало бы либо монитором защищать либо передавать обёртку, но тут-то надо же хранить где-то флаг пользует её кто-то или нет.
>Стейтмент так себе.
>Все там можно.
Вот продемонстрируй мне двусвязный список, руками, а не из коробки или же дерево где дочерняя ветвь хранит ссылку на родителя, и я пристыженный уйду. Нет, я допускаю что можно всё организовать в массив и в структуре хранить индексы запроместо указателей, но былой стремительностью такой подход уже не похвастается.
>Ты так говоришь, как будто что-то хорошее.
Я вроде ж указал на заведумую порочность. Другое дело, что сторонние-то функции далеко не все реентерабельны. Заодно поясните, я наткнулся раз на демку в которой рисуются красные квадраты, как GL адаптировали? Ну я о том, что в два потока не порисуешь ведь - хуета получится, стало бы либо монитором защищать либо передавать обёртку, но тут-то надо же хранить где-то флаг пользует её кто-то или нет.
>>094175
Храните в HashMap, кто вам запрещает-то?..
>но былой стремительностью такой подход уже не похвастается
Храните в HashMap, кто вам запрещает-то?..
>>094175
либо EnterCriticalSection() и затем LeaveCriticalSection()
>либо монитором защищать либо передавать обёртку
либо EnterCriticalSection() и затем LeaveCriticalSection()
>>094185
Ты про какой-то волшебный HashMap в котором сложность доступа к элементу не O (ln(n)) и даже меньше константной сложности проверки индекса и обращения к элементу в массиве? Не очень тебя понял по-видимому.
>>094522
Впрочем, ты уговорил. Подход немного непривычный, не самый шустрый, но вполне обоснованный при данных условиях.
>>094186
Ну она ж аргумент принимает? Где-то хранить его надо между вызовами, ведь не каждый поток в свою критическую секцию заходит.
>Храните в HashMap, кто вам запрещает-то?..
Ты про какой-то волшебный HashMap в котором сложность доступа к элементу не O (ln(n)) и даже меньше константной сложности проверки индекса и обращения к элементу в массиве? Не очень тебя понял по-видимому.
>>094522
>instead of pointers we use indices into a backing vector
Впрочем, ты уговорил. Подход немного непривычный, не самый шустрый, но вполне обоснованный при данных условиях.
>>094186
>EnterCriticalSection
Ну она ж аргумент принимает? Где-то хранить его надо между вызовами, ведь не каждый поток в свою критическую секцию заходит.
>>094060
Наркоман? На их сайт зайти и прочитать не можешь? Пиздец, вот вроде пишет человек пост: длинный, грамотным русским языком, вопросы всякие вполне обоснованные задает... а потом в самом конце берет ушат собачьего дерьма, выливает на себя и начинает ногами дрыгать: "я в дерьме! я говно ем!" - пиздец, нахуй так жить-то?
>он для каких задач и для какой аудитории вообще изобретался?
Наркоман? На их сайт зайти и прочитать не можешь? Пиздец, вот вроде пишет человек пост: длинный, грамотным русским языком, вопросы всякие вполне обоснованные задает... а потом в самом конце берет ушат собачьего дерьма, выливает на себя и начинает ногами дрыгать: "я в дерьме! я говно ем!" - пиздец, нахуй так жить-то?
>>094060
Не нужно. Нужно использовать новую парадигму, а не свои привычные костыли из c++
>И один хер придётся использовать небезопасные блоки кода
Не нужно. Нужно использовать новую парадигму, а не свои привычные костыли из c++
>>094175
Не знаю как там у вас в двусвязных, но обычный односвязный предназначен для того, чтобы быть на heap и быть полностью персистентным, либо туплоподобным и иметь известную длину, запечатленную в типе.
Не знаю как там у вас в двусвязных, но обычный односвязный предназначен для того, чтобы быть на heap и быть полностью персистентным, либо туплоподобным и иметь известную длину, запечатленную в типе.
>>094584
Да, выжирающий сотни памяти, он перестраивает хеш-индекс во время работы и даёт почти мгновенный доступ к данным.
Она переключает режим выполнения, чтобы работал только вызвавший её поток, а потом другая функция его возвращает в тот же режим как было. Всё это костыли, естественно.
>волшебный HashMap
Да, выжирающий сотни памяти, он перестраивает хеш-индекс во время работы и даёт почти мгновенный доступ к данным.
>>EnterCriticalSection
>Ну она ж аргумент принимает?
Она переключает режим выполнения, чтобы работал только вызвавший её поток, а потом другая функция его возвращает в тот же режим как было. Всё это костыли, естественно.
>>094599
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.
>>094702
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?
>>094774
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.
>ушат собачьего дерьма, в дерьме, говно ем
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.
>>094702
>Не нужно.
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?
>>094774
>почти мгновенный доступ к данным
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.
>Она переключает режим выполнения, чтобы работал только вызвавший её поток
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.
>>094599
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.
>>094702
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?
>>094774
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.
>ушат собачьего дерьма, в дерьме, говно ем
Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини? Многие были восхищены.
>>094702
>Не нужно.
Не буду иронизировать. Да и в целом посыл правильный, разве что код будет уже не "blazingly fast". Только один же чёрт придётся взаимодействовать с чужим кодом использующим старую костыльную парадигму. Ну и может это лично для меня слишком всё в новинку, но как-то слабо представляю как можно организовать какое-либо событийно ориентированное взаимодействие с таким подходом. То есть процедуры обратного вызова всякие, передачу сообщений. Как, например, вообще стандартным образом реализуется оконная система?
>>094774
>почти мгновенный доступ к данным
Мы, похоже, беседуем каждый о своём. Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель). Это даже без проверки индекса на выход из диапазона. Ты же после этого рассказываешь о наистремительнейшем HashMap, и я не понимаю что ты имеешь в виду. Вряд ли же предполагается что пусть сколь угодно хорошо оптимизированный алгоритм в котором количество сравнений зависит от общего количества элементов, превосходит по скорости алгоритм в котором сравнений максимум два для любой длинны.
>Она переключает режим выполнения, чтобы работал только вызвавший её поток
Так и есть. Я помню про функцию с таким названием из WinApi. Её закрывающая пара - LeaveCriticalSection. Даже если предполаголось что-то растоспецифичное с таким же именем, готов предположить что оно и работает подобным образом. Поправь меня если не так.
Так вот я о чём, чтобы переключить режим выполнения и вернуть в тот же режим как было, как ты варазился, она принимает по ссылке некую структуру. И тут вопрос где её расположить. Если в статической памяти то придётся использовать небезопасные блоки кода т.к. при входе и выходе в неё будет призводиться запись. Если же хранить её на стеке или как-то связать с объектом-обёрткой то опять же надо в глобальной переменной хранить флаг её инициализации иначе другой поток запросто получит копию в которую позже и войдёт асинхронно, но одновременно с предыдущим, распуская пиздой по рукавам те инварианты, что были заложенны авторами сторонней библиотеки написанной для экслюзивного использования на куда менее прогрессивном языке.
>>062432
>>086357
В чём преимущество перфоратора перед дрелью? Дрели перед перфоратором?
>>064931
Как ты думаешь, для чего вообще в расте придумали "опасный код"?
>>070417
То что создание новых языков и переписывание всего под них приводит к убыткам это правда. Но так же правда и то, что поддержка и развитие легасей крайне дорогое, без особой надежды на улучшение ситуации в будущем.
>>083135
Пиши без использования ссылок. Копируй/клонируй всегда и везде.
>>086357
В чём преимущество перфоратора перед дрелью? Дрели перед перфоратором?
>>064931
Как ты думаешь, для чего вообще в расте придумали "опасный код"?
>>070417
То что создание новых языков и переписывание всего под них приводит к убыткам это правда. Но так же правда и то, что поддержка и развитие легасей крайне дорогое, без особой надежды на улучшение ситуации в будущем.
>>083135
Пиши без использования ссылок. Копируй/клонируй всегда и везде.
>>094943
Увы, ты промахнулся.
Кстати, позволю себе замечание по поводу содержания остального поста. Что ты, блядь, хочешь-то от нас от них?! Тебе, блядь, дали язык, на котором можно писать чуть ли не в функциональном стиле с ебаной кучей статических проверок без гц и быть на 10-15% медленее си. Тебе дали возможность писать на си с нескучным синтаксисом и тем же тулингом, когда эти 10-15% тебя не устраивают или когда компилятор анально насилует тебя в жопу. Вместо того, чтобы возрадоваться и поблагодарить Бога за это, ты приходишь в этот итт тред и начинаешь лечить про то, что хэшмапы медленные. Сука, блядь, так хули тебе надо-то?!
>Не ты ли несколько тредов назад выкладывал фрагмент кинца от небезызвестного Паоло Пазолини?
Увы, ты промахнулся.
Кстати, позволю себе замечание по поводу содержания остального поста. Что ты, блядь, хочешь-то от нас от них?! Тебе, блядь, дали язык, на котором можно писать чуть ли не в функциональном стиле с ебаной кучей статических проверок без гц и быть на 10-15% медленее си. Тебе дали возможность писать на си с нескучным синтаксисом и тем же тулингом, когда эти 10-15% тебя не устраивают или когда компилятор анально насилует тебя в жопу. Вместо того, чтобы возрадоваться и поблагодарить Бога за это, ты приходишь в этот итт тред и начинаешь лечить про то, что хэшмапы медленные. Сука, блядь, так хули тебе надо-то?!
>>095018
Он из тех кто против и ищет подтверждения своим убеждениям.
Он из тех кто против и ищет подтверждения своим убеждениям.
>>095099
Да. Пиздуй контрибьютить в llvm и rustc.
Да. Пиздуй контрибьютить в llvm и rustc.
>>095018
Ты прям срузу с козырей. Потолковать хочу за всякие нюансы, попиздеть по большей части для души. Сама система типов, и правда не может не вызывать восхищения. Вот мне и интересно является ли она во всей своей чистоте и ортогональности практичной и достаточной для какого-либо маломальски серьёзного промышленного проекта. И как адаптируются традиционные подходы в переложении на неё. И какие подобная адаптация может скрывать за собой опасности.
Вот и интересуюсь.
Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах, кто-то и окажется готов поделиться мнением. Указать на какую-либо избыточность или недостаточность языка или одного из его элементов, посетовать на те случаи где они заебались бороться с borrow checker'ом и где наоборот он их сильно выручил. Хватает ли им скорости хэшмапов или приходится использовать unsafe. В одиночку это было бы в любом случае гораздо сложнее, а тут целый тред по языку создан.
>Сука, блядь, так хули тебе надо-то?!
Ты прям срузу с козырей. Потолковать хочу за всякие нюансы, попиздеть по большей части для души. Сама система типов, и правда не может не вызывать восхищения. Вот мне и интересно является ли она во всей своей чистоте и ортогональности практичной и достаточной для какого-либо маломальски серьёзного промышленного проекта. И как адаптируются традиционные подходы в переложении на неё. И какие подобная адаптация может скрывать за собой опасности.
Вот и интересуюсь.
Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах, кто-то и окажется готов поделиться мнением. Указать на какую-либо избыточность или недостаточность языка или одного из его элементов, посетовать на те случаи где они заебались бороться с borrow checker'ом и где наоборот он их сильно выручил. Хватает ли им скорости хэшмапов или приходится использовать unsafe. В одиночку это было бы в любом случае гораздо сложнее, а тут целый тред по языку создан.
55 Кб, 421x700>>094943
1. Это еще не факт. Без тестов говорить не о чем.
2. Сделай сначала свой код с указателями на сишечке нетекущим и хоть немного безопасным, а потом сравни скорость еще раз.
3. Модель выделения и освобождения памяти для твоего волшебного списка, влияет на производительность на порядок больше способа связывания.
Что приводит нас к пункту 4.
4. Имеет смысл о чем-то говорить сравнивая конкретные реализации. Есть серьезные подозрения, что код на сишечке, с тем же функционалом, может оказаться как минимум громоздким и страшным, а еще может и медленнее в итоге работать.
5. Для крит важного кода, вроде realtime систем, есть ассемблер. Та-же си не очень то тут работает.
6. Иди лучше мамке своей посетуй.
6.1 Поболтать оно конечно бывает интересно, но о чем тут собственного говорить и размышлять? Когда и так все ясно? А сама тема не стоит и выеденного яйца.
Мимо анон.
>Я изначально посетовал что обращение вида @list[index] будет медленнее чем ref^ (прямой указатель).
1. Это еще не факт. Без тестов говорить не о чем.
2. Сделай сначала свой код с указателями на сишечке нетекущим и хоть немного безопасным, а потом сравни скорость еще раз.
3. Модель выделения и освобождения памяти для твоего волшебного списка, влияет на производительность на порядок больше способа связывания.
Что приводит нас к пункту 4.
4. Имеет смысл о чем-то говорить сравнивая конкретные реализации. Есть серьезные подозрения, что код на сишечке, с тем же функционалом, может оказаться как минимум громоздким и страшным, а еще может и медленнее в итоге работать.
5. Для крит важного кода, вроде realtime систем, есть ассемблер. Та-же си не очень то тут работает.
6. Иди лучше мамке своей посетуй.
6.1 Поболтать оно конечно бывает интересно, но о чем тут собственного говорить и размышлять? Когда и так все ясно? А сама тема не стоит и выеденного яйца.
Мимо анон.
20 Мб, webm,1112x900, 4:00
>>094951
Ну, далеко не всегда.
Скажем даже так, в 2017 году это утверждение скорее всего ложно.
1. Идея переиспользования кода оказалась сильно переиспользована и неправильно понята. В реальности это вносит проблем иногда больше, чем решает. Почему?
- Стороннее решение не содержит специфического функционала или в нужном виде, что приводит к дополнительному коду, иногда весьма замысловатому, или еще хуже, изменениям\деформациям архитектуры.
- Стороннее решение представляет из себя черный ящик.
- Потребность в нужном функционале приводит к необходимости адаптации стороннего решения, создаются даже отдельные команды и подразделения дорабатывающие хуй знает какой чужой код. (а потом приходит озарение и пишут свое решение)
- Зависимость от третьих лиц со всеми прелестями - внезапными багами, брешами безопасности, несвоевременным обновлениями, и даже закладками\вирусами.
2. Все это как-то окупалось во времена, когда программист был редким и дорогим специалистом, а сам процесс был сложным в отсутствии продвинутых средств разработки и примитивности языков программирования. Сейчас ситуация кардинально другая. Дети учатся программировать с детского сада. Специалистов даже переизбыток. а новые современные средства и языки позволяют создавать код с повышенной эффективностью.
3. В 2017 году СКОРОСТЬ разработки выросла в разы, и это не просто для красивой циферки в версии и чтобы казаться современными молодежными, просто информация в мире стала перемещаться в сто раз быстрее чем в 2000 году, и в 1000 раз быстрее чем в 1980. Мир ускорился, нужны новые современные решения сейчас, еще вчера, неделю назад.
А кто-то IE6 поддерживать пытается, а потом из ЦРУ утекает эксплойт и останавливаются целые заводы в разных странах, потому что на них Windows XP стояла, блядь.
Легаси в 2017 - непозволительная роскошь.
Это как блядь лампочки накаливания вместо LED использовать.
>То что создание новых языков и переписывание всего под них приводит к убыткам это правда
Ну, далеко не всегда.
Скажем даже так, в 2017 году это утверждение скорее всего ложно.
1. Идея переиспользования кода оказалась сильно переиспользована и неправильно понята. В реальности это вносит проблем иногда больше, чем решает. Почему?
- Стороннее решение не содержит специфического функционала или в нужном виде, что приводит к дополнительному коду, иногда весьма замысловатому, или еще хуже, изменениям\деформациям архитектуры.
- Стороннее решение представляет из себя черный ящик.
- Потребность в нужном функционале приводит к необходимости адаптации стороннего решения, создаются даже отдельные команды и подразделения дорабатывающие хуй знает какой чужой код. (а потом приходит озарение и пишут свое решение)
- Зависимость от третьих лиц со всеми прелестями - внезапными багами, брешами безопасности, несвоевременным обновлениями, и даже закладками\вирусами.
2. Все это как-то окупалось во времена, когда программист был редким и дорогим специалистом, а сам процесс был сложным в отсутствии продвинутых средств разработки и примитивности языков программирования. Сейчас ситуация кардинально другая. Дети учатся программировать с детского сада. Специалистов даже переизбыток. а новые современные средства и языки позволяют создавать код с повышенной эффективностью.
3. В 2017 году СКОРОСТЬ разработки выросла в разы, и это не просто для красивой циферки в версии и чтобы казаться современными молодежными, просто информация в мире стала перемещаться в сто раз быстрее чем в 2000 году, и в 1000 раз быстрее чем в 1980. Мир ускорился, нужны новые современные решения сейчас, еще вчера, неделю назад.
А кто-то IE6 поддерживать пытается, а потом из ЦРУ утекает эксплойт и останавливаются целые заводы в разных странах, потому что на них Windows XP стояла, блядь.
Легаси в 2017 - непозволительная роскошь.
Это как блядь лампочки накаливания вместо LED использовать.
>>095340
Ага! Я так и знал, что ты мазохист, содомит и бдсм-извращенец, бгг.
This.
Я не пишу на расте, но еще в прошлом посте написал про си с нескучным синтаксисом. Ансейф - это не какой-то смертный грех, это просто способ не пиздовать в си, а писать сишный код прямо тут же, в расте. Тайпчекер же нужен не ради самого себя, а для гарантий. Там, где ты можешь (думаешь, что можешь) предоставить эти гарантии сам, можно его выключить. Если тебе нужны не простые хэшмапы, а WOW SO HASHMAP 2000% BONUS CRITICAL SPEED ACHIEVEMNT UNLOCKED BAYTOŒB PWND, то ты просто берешь и пишешь их без задней мысли. Главное, как всегда, изолировать это говно и тестировать это говно. Тут, блядь, нет какого-то "АХАХАХ ВОТ Я ВАМ ГОВОРИЛ АНСЕЙФ ВЕЗДЕ ТАЙПЧЕКЕР СОСНУЛ РАСТ НИНУЖОН)))00", - он изначально таким и задумывался, блядь. Это не баг, это фича.
Ну и это.
>Сама система типов, и правда не может не вызывать восхищения.
Ага! Я так и знал, что ты мазохист, содомит и бдсм-извращенец, бгг.
> или приходится использовать unsafe
This.
Я не пишу на расте, но еще в прошлом посте написал про си с нескучным синтаксисом. Ансейф - это не какой-то смертный грех, это просто способ не пиздовать в си, а писать сишный код прямо тут же, в расте. Тайпчекер же нужен не ради самого себя, а для гарантий. Там, где ты можешь (думаешь, что можешь) предоставить эти гарантии сам, можно его выключить. Если тебе нужны не простые хэшмапы, а WOW SO HASHMAP 2000% BONUS CRITICAL SPEED ACHIEVEMNT UNLOCKED BAYTOŒB PWND, то ты просто берешь и пишешь их без задней мысли. Главное, как всегда, изолировать это говно и тестировать это говно. Тут, блядь, нет какого-то "АХАХАХ ВОТ Я ВАМ ГОВОРИЛ АНСЕЙФ ВЕЗДЕ ТАЙПЧЕКЕР СОСНУЛ РАСТ НИНУЖОН)))00", - он изначально таким и задумывался, блядь. Это не баг, это фича.
Ну и это.
> Тут же наверняка есть люди что пишут на расте какое-то серьёзное ПО, участвуют в крупных проектах
> 2ch.hk
> серьёзное ПО, участвуют в крупных проектах
> 2ch.hk
>>095350
Ты какой-то странный. Нет ничего плохого в IE6 если твой завод физически отрезан от внешнего мира. А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза.
Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости, отсюда растут ноги NIH.
Ты какой-то странный. Нет ничего плохого в IE6 если твой завод физически отрезан от внешнего мира. А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза.
Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости, отсюда растут ноги NIH.
>>095392
Необразованный безмозглый дегенерат.
Иди в /ra/ чтобы тебя там хоороошенькго обоссали. Я даже начинать не буду.
Стандартное объяснения почему компаниянейм создала пиздатый продуктнейм - "нас заебало стороннее легаси говно и нам пришлось сделать свое."
Сук пиздос.
Да блядь просто берешь и создаешь нужный тебе функционал.
90% всего уже есть в стандартной библиотеке. А если нет, то на помойку этот язык.
>А лампочки накаливания имеют куда более естественный, близкий солнцу, спектр излучения, от них меньше устают глаза
Необразованный безмозглый дегенерат.
Иди в /ra/ чтобы тебя там хоороошенькго обоссали. Я даже начинать не буду.
>Лично моё мнение таково, что переписывают чаще в процессе глубокого изучения, а не ради насущной необходимости
Стандартное объяснения почему компаниянейм создала пиздатый продуктнейм - "нас заебало стороннее легаси говно и нам пришлось сделать свое."
>Нет ничего плохого в IE6
>Ты какой-то странный.
Сук пиздос.
>что переписывают чаще в процессе глубокого изучения
Да блядь просто берешь и создаешь нужный тебе функционал.
90% всего уже есть в стандартной библиотеке. А если нет, то на помойку этот язык.
>>095422
Я не он но ты хуйю несешь. LED в 10 раз экономичнее и глаза от него не устают. У меня вся квартира ими обмазана. Профит от LED настолько очевиден что его не заметил только полный слепец.
Я не он но ты хуйю несешь. LED в 10 раз экономичнее и глаза от него не устают. У меня вся квартира ими обмазана. Профит от LED настолько очевиден что его не заметил только полный слепец.
>>095508
Да причём тут экономичность. Вдруг мне просто нравится тёплый ламповый свет? Люди даже камины дома сооружают, на дровах, Карл. У того буйного проблемы с подбором аналогий, всё что я хотел сказать. Я даже не понял что он хотел сказать своими длиннопостами, какие-то разрозненные бессистемные аргументы без тезиса и вывода.
Да причём тут экономичность. Вдруг мне просто нравится тёплый ламповый свет? Люди даже камины дома сооружают, на дровах, Карл. У того буйного проблемы с подбором аналогий, всё что я хотел сказать. Я даже не понял что он хотел сказать своими длиннопостами, какие-то разрозненные бессистемные аргументы без тезиса и вывода.
>>095645
Ну не знаю. libpng тоже переписываешь каждый раз? Везде биндинги, везде FFI. Это тоже легаси? Как бы зачем переписывать то что вылизывалось чуть ли не десятилетия?
Ну не знаю. libpng тоже переписываешь каждый раз? Везде биндинги, везде FFI. Это тоже легаси? Как бы зачем переписывать то что вылизывалось чуть ли не десятилетия?
>>095572
1. Есть лед с Ra 95-98, даже лучше чем у ламп накаливания.
2. Необучаемый, думает, что лед лампы не могут светить теплым светом?
Заебись.
А ничего, что речь шла о ЭКОНОМИЧЕСКОЙ ЦЕЛЕСООБРАЗНОСТИ, а не о том, что какой-то пизде нравится, или не нравится?
Тебе никто не запрещает хоть дуговыми лампами освещаться хоть свечами, хоть газовыми светильниками.
Задеваю твою женскую гордость?
Мужчина не должен привлекать к себе внимание, если ему нечего сказать.
>Вдруг мне просто нравится тёплый ламповый свет?
1. Есть лед с Ra 95-98, даже лучше чем у ламп накаливания.
2. Необучаемый, думает, что лед лампы не могут светить теплым светом?
>мне просто нравится
Заебись.
А ничего, что речь шла о ЭКОНОМИЧЕСКОЙ ЦЕЛЕСООБРАЗНОСТИ, а не о том, что какой-то пизде нравится, или не нравится?
Тебе никто не запрещает хоть дуговыми лампами освещаться хоть свечами, хоть газовыми светильниками.
>Я даже не понял что он хотел сказать своими длиннопостами
>многабукаф нипонятно
>слишком длинно111
>я ничего не понял но все равно напишу какуйнибудьзхуйню вместо того чтобы расспросить о непонятных мне вещах.
>ведь я такой умный я все знаю
>У того буйного
>Ты какой-то буйный
Задеваю твою женскую гордость?
Мужчина не должен привлекать к себе внимание, если ему нечего сказать.
>>095584
А что спектр излучения?
А ты среднюю дисперсию посчитал для спектра солнца\лампы накаливания и солнца\LED ?
>Речь о спектре излучения, але.
А что спектр излучения?
А ты среднюю дисперсию посчитал для спектра солнца\лампы накаливания и солнца\LED ?
>>095678
>>095681
Я уже понял что в /ra/ лишний раз лучше не заходить. Что ты так орёшь-то? Сам небось своими светодиодами барыжишь? Экономическая целесообразность как раз таки очень спорная, светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит, а электричества на всю стоимость лампы не сэкономит.
>>095681
Я уже понял что в /ra/ лишний раз лучше не заходить. Что ты так орёшь-то? Сам небось своими светодиодами барыжишь? Экономическая целесообразность как раз таки очень спорная, светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит, а электричества на всю стоимость лампы не сэкономит.
>>095690
А вот это пиздеж. На LED лампы одна лишь гарантия 2 года. Стоит они 100рублей примерно. Охуеть как дорого.
>светодиоды стоят сильно дороже ламп накаливания, прослужит столько же, так же сгорит,
А вот это пиздеж. На LED лампы одна лишь гарантия 2 года. Стоит они 100рублей примерно. Охуеть как дорого.
>>095690
1. Ты пишешь как манерный гей.
2. Даже относительно дорогие леды даже если допустить их малый срок службы, окупаются за счет стоимости электричества. Разница, внезапно, десятикратная.
А так то у меня 10$ LG с 2013 года в ванне светит.
1. Ты пишешь как манерный гей.
2. Даже относительно дорогие леды даже если допустить их малый срок службы, окупаются за счет стоимости электричества. Разница, внезапно, десятикратная.
А так то у меня 10$ LG с 2013 года в ванне светит.
>>095701
Все в порядке с геями, только мы тут RUST обсуждаем, а не женские чувства косметику и наряды.
Для геев есть /ga/.
>Чем тебе не угодили геи?
Все в порядке с геями, только мы тут 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
>>095822
Ага, по-даунски как в го
Ага, по-даунски как в го
>>095347
Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
Если ты пропустил скучное предисловие, то там сравнивали с go и d. И на них это будет вполне себе безопасно. Давай, заяви про GC и пойдём по второму кругу.
Заявление слишком сильное и категоричное, жаль только что не для всех случаев верное. А именно для случаев в которых выделение и освобождение памяти явление относительно редкое, а обращение к объекту - частое. Но тут соглашусь, нужно исходить из задач.
А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
Не, ну а как же абстракции с нулевой стоимостью? А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
>>095382
Не, ну а где собираются серьёзные системные программисты как не на двощах. В Mozilla Research что ль, скажешь тоже. А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет, прям хоть в петлю завязывайся. Вроде как вот тебе интрумент для создания красивого правильного, но нерабочего кода, а вот для чтоб работало, но через хуй колено. Всё ж развивается ПО, развиваются трансляторы, языки нескучные появляются, может и заебенят такое что все охуеют.
А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
>Это еще не факт. Без тестов говорить не о чем.
Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
>код с указателями на сишечке
Если ты пропустил скучное предисловие, то там сравнивали с go и d. И на них это будет вполне себе безопасно. Давай, заяви про GC и пойдём по второму кругу.
>влияет на производительность на порядок больше способа связывания
Заявление слишком сильное и категоричное, жаль только что не для всех случаев верное. А именно для случаев в которых выделение и освобождение памяти явление относительно редкое, а обращение к объекту - частое. Но тут соглашусь, нужно исходить из задач.
>может оказаться как минимум громоздким и страшным
А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
>Для крит важного кода, вроде realtime систем, есть ассемблер
Не, ну а как же абстракции с нулевой стоимостью? А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
>о чем тут собственного говорить и размышлять
Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
>>095382
Не, ну а где собираются серьёзные системные программисты как не на двощах. В Mozilla Research что ль, скажешь тоже. А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет, прям хоть в петлю завязывайся. Вроде как вот тебе интрумент для создания красивого правильного, но нерабочего кода, а вот для чтоб работало, но через хуй колено. Всё ж развивается ПО, развиваются трансляторы, языки нескучные появляются, может и заебенят такое что все охуеют.
А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
>>095863
Чувак, прочитай растбук для начала - они гораздо лучше меня все объяснят.
Чувак, прочитай растбук для начала - они гораздо лучше меня все объяснят.
>>095860
Щито? Ты его мессаджа не понял, видимо.
Ээ... Щито?
Чего блядь?
Ээ... Так как бы "такое количество ограничений как в ржавом" как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни. У меня такое чувство, что тебе тоже надо посоветовать прочитать растбук.
Ээ, расскажешь, как через афинные типы делать тоталити чек?
>А вообще от твоего сообщения какой-то тоскливой холодной безысходностью за здорово веет
Щито? Ты его мессаджа не понял, видимо.
> интрумент для создания красивого правильного, но нерабочего кода
Ээ... Щито?
> а вот для чтоб работало, но через хуй колено
Чего блядь?
> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать
Ээ... Так как бы "такое количество ограничений как в ржавом" как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни. У меня такое чувство, что тебе тоже надо посоветовать прочитать растбук.
> гарантии тотальности
Ээ, расскажешь, как через афинные типы делать тоталити чек?
>>095860
Вместо тестов дезассемблировать?
Ну и на расте будет безопасно.
Это ты его так просто чувсвуешь.
Ну вот и славно.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.
Нет, увольте.
Ну, раз так все просто, возьми и сделай.
>Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
Вместо тестов дезассемблировать?
> то там сравнивали с go и d. И на них это будет вполне себе безопасно
Ну и на расте будет безопасно.
>Заявление слишком сильное и категоричное
Это ты его так просто чувсвуешь.
>Но тут соглашусь, нужно исходить из задач.
Ну вот и славно.
>А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.
>Не, ну а как же абстракции с нулевой стоимостью?
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.
>А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.
>Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
Нет, увольте.
>А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
Ну, раз так все просто, возьми и сделай.
>>095860
Вместо тестов дезассемблировать?
Ну и на расте будет безопасно.
Это ты его так просто чувсвуешь.
Ну вот и славно.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.
Нет, увольте.
Ну, раз так все просто, возьми и сделай.
>Я почти уверен. Да и дизассемблировать не так уж и сложно для проверки.
Вместо тестов дезассемблировать?
> то там сравнивали с go и d. И на них это будет вполне себе безопасно
Ну и на расте будет безопасно.
>Заявление слишком сильное и категоричное
Это ты его так просто чувсвуешь.
>Но тут соглашусь, нужно исходить из задач.
Ну вот и славно.
>А может и оказаться настолько охуительным что его в музей сдадут. Чего тут гадать-то.
Пока, еще ни одного такого решения в музей не сдали, так что, как сдадут, поднимешь тему еще раз.
>Не, ну а как же абстракции с нулевой стоимостью?
Нормально, не болеют, в церковь ходят, живут скромно но не бедствуют.
>А так тебя послушать получается что либо "runs blazingly fast", либо " prevents segfaults, and guarantees thread safety".
Любому здравомыслящему человеку, должно быть понятно, что общего решения быть в природе не может, но для некоторых случаев получается сделать и быстро и безопасно.
>Ну можно ещё попиздеть за мужеложцев и преимущества светодиодных ламп. Хуле ещё остаётся.
Нет, увольте.
>А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
Ну, раз так все просто, возьми и сделай.
>>062380 (OP)
Пишут ли уже игори на расте?
Пишут ли уже игори на расте?
>>095845
Это не я начал.
Это не я начал.
>>095822
https://play.rust-lang.org/?gist=1b7ce5c87de05e0733759e8a7936f382&version=stable
unwrap() нужен потому что последнего элемента в общем случае может и не быть, поэтому ты получаешь Option<T>. В продакшн коде менять на expect или паттерн матчинг
https://play.rust-lang.org/?gist=1b7ce5c87de05e0733759e8a7936f382&version=stable
unwrap() нужен потому что последнего элемента в общем случае может и не быть, поэтому ты получаешь Option<T>. В продакшн коде менять на expect или паттерн матчинг
>>095915
Пишут мелкие поделки всякие. Наркоманы пилят amethyst. ggez для 2д норм. piston очевидный.
Пишут мелкие поделки всякие. Наркоманы пилят amethyst. ggez для 2д норм. piston очевидный.
>>096000
Ебануться, оказывается масссив это не слайс. Вы там совсем ебанулись, аллё?
Ебануться, оказывается масссив это не слайс. Вы там совсем ебанулись, аллё?
>>095870
Да вроде бы понял, но судя по количеству "Щито" в ответе - немного по-своему. Поясню. То что ты говоришь про тестирование и изолирование, в контексте вопроса использования небезопасного кода - безусловно правильно, только уж слишком универсально. Что-то в духе пиздато делай - пиздато будет. Также и сионист будет пояснять за с/спп, у меня, дескать, не течёт нихуя, я весь код изолирую, и ты так делай. Да не раз же в тредах было.
Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.
Ты не путаешь причину и следствие? Мне казалось что изначально стояла задача создания системного языка для написания быстрого и безопасного кода, и отсутсвие циклических ссылок тут лишь средство. Подобным же средством могут выступать регионы в языках типа циклона, там наверняка много своей спецефичной поебени, но цели вроде бы те же. Только, пожалуй, совместить эти два подхода очень непросто.
Тут я не матёрый дока нихуя, но что-то типа: на каждом шаге один элемент должен быть структурно меньше предыдущего. Есть же языки с подобным, даже императивные. Да и данные благодаря системе типов организуются древовидно в основном А выкинуть Rc<RefCell<什么>> так и вообще всё строго будет .
>>095877
Ну ты прям громишь по всем пунктам. Спасибо за щеку не накидал ничего.
>Ты его мессаджа не понял, видимо.
Да вроде бы понял, но судя по количеству "Щито" в ответе - немного по-своему. Поясню. То что ты говоришь про тестирование и изолирование, в контексте вопроса использования небезопасного кода - безусловно правильно, только уж слишком универсально. Что-то в духе пиздато делай - пиздато будет. Также и сионист будет пояснять за с/спп, у меня, дескать, не течёт нихуя, я весь код изолирую, и ты так делай. Да не раз же в тредах было.
Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.
>как раз и нужно, чтобы избежать взаимных ссылок и подобной хуйни
Ты не путаешь причину и следствие? Мне казалось что изначально стояла задача создания системного языка для написания быстрого и безопасного кода, и отсутсвие циклических ссылок тут лишь средство. Подобным же средством могут выступать регионы в языках типа циклона, там наверняка много своей спецефичной поебени, но цели вроде бы те же. Только, пожалуй, совместить эти два подхода очень непросто.
>как через афинные типы делать тоталити чек
Тут я не матёрый дока нихуя, но что-то типа: на каждом шаге один элемент должен быть структурно меньше предыдущего. Есть же языки с подобным, даже императивные. Да и данные благодаря системе типов организуются древовидно в основном А выкинуть Rc<RefCell<什么>> так и вообще всё строго будет .
>>095877
Ну ты прям громишь по всем пунктам. Спасибо за щеку не накидал ничего.
>>096219
Ты хуйню какую-то несешь, скажу прямо. Если одну и ту же функциональность можно реализовать либо на си, либо в два раза быстрее, чем на си, в четыре раза надежнее и без серьезных потерь в производительности, то рационально выбрать второй вариант. Где второй вариант недоступен, там приходится выбирать первый. Количество таких мест надо минимизировать, сами места изолировать. Капитан очевидность, привет. При чем тут сионисты с крестоносцами и как можно "весь код изолировать" - хуй тебя знает.
Что-то из разряда "бля, ну научному методу уже 2 сотни лет в обед, хули до сих пор не открыли все законы природы" или скорее даже "бля, ну математике уже 2 тыщи лет в обед, хули до сих пор что-то там придумывают".
Взаимные ссылки нужны, чтобы добавить ограничения в раст? Для диванного философа ты как-то хуевато с логикой дружишь.
Да я вроде обратного и не утверждал, не? Отсутствие побочных эффектов - тоже "лишь средство", например. Да и вообще программирование как деятельность - это "лишь средство". И чо? А циклические ссылки - это в любом случае code smell.
А афинные типы-то тут при чем? Тащем-то, сабтьюринговость достигается запретом явной рекурсии, например.
>я весь код изолирую
Ты хуйню какую-то несешь, скажу прямо. Если одну и ту же функциональность можно реализовать либо на си, либо в два раза быстрее, чем на си, в четыре раза надежнее и без серьезных потерь в производительности, то рационально выбрать второй вариант. Где второй вариант недоступен, там приходится выбирать первый. Количество таких мест надо минимизировать, сами места изолировать. Капитан очевидность, привет. При чем тут сионисты с крестоносцами и как можно "весь код изолировать" - хуй тебя знает.
> универсального формализма
> универсального
> формализма
> люди-то годами работают
Что-то из разряда "бля, ну научному методу уже 2 сотни лет в обед, хули до сих пор не открыли все законы природы" или скорее даже "бля, ну математике уже 2 тыщи лет в обед, хули до сих пор что-то там придумывают".
> Ты не путаешь причину и следствие?
Взаимные ссылки нужны, чтобы добавить ограничения в раст? Для диванного философа ты как-то хуевато с логикой дружишь.
> отсутсвие циклических ссылок тут лишь средство
Да я вроде обратного и не утверждал, не? Отсутствие побочных эффектов - тоже "лишь средство", например. Да и вообще программирование как деятельность - это "лишь средство". И чо? А циклические ссылки - это в любом случае code smell.
> на каждом шаге один элемент должен быть структурно меньше предыдущего
А афинные типы-то тут при чем? Тащем-то, сабтьюринговость достигается запретом явной рекурсии, например.
57 Кб, 604x400>>096219
Такого формализма быть не может, в виду не Господь полной природы вычислительных систем с которыми мы работаем.
И даже если бы и Господь полная система была, формализмами она бы все равно не оперировала бы.
Раст - неплохой ЯП, двигающийся в правильном направлении, ЯП должен программиста дрючить, и бить по рукам за любое отступление от здравого смысла и единственного решения.
Правда, разрабы решили пихать в него слишком много языковых возможностей, что приведет к деградации и рабству.
Это собственно самый главный грех С++, попытка включить в себя все что только можно.
Специализация - благо.
Излишество синтаксиса - грех.
>Вот мне и взрустнулось маленько, вроде и двадцать первый век, а некоего универсального формализма для написания заведомо безопасных быстрых программ так и не появилось. Предвосхищая аргументы "Любому здравомыслящему человеку, должно быть понятно" и "возьми и сделай" замечу что я-то философствую с дивана, но люди-то годами работают, могли бы и расстораться.
Такого формализма быть не может, в виду не Господь полной природы вычислительных систем с которыми мы работаем.
И даже если бы и Господь полная система была, формализмами она бы все равно не оперировала бы.
Раст - неплохой ЯП, двигающийся в правильном направлении, ЯП должен программиста дрючить, и бить по рукам за любое отступление от здравого смысла и единственного решения.
Правда, разрабы решили пихать в него слишком много языковых возможностей, что приведет к деградации и рабству.
Это собственно самый главный грех С++, попытка включить в себя все что только можно.
Специализация - благо.
Излишество синтаксиса - грех.
>>096257
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Причину и первопричину конечно же. К чему так остро острить.
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:
function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}
На ATS, тоже что-то подобное встречалось.
>>096318
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
>Для диванного философа ты как-то хуевато с логикой дружишь.
Причину и первопричину конечно же. К чему так остро острить.
>это в любом случае code smell
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?
>А афинные типы-то тут при чем?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?
>сабтьюринговость достигается запретом явной рекурсии, например
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:
function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}
На ATS, тоже что-то подобное встречалось.
>>096318
>полной природы вычислительных систем с которыми мы работаем
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.
>Излишество синтаксиса - грех.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?
>>096257
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Причину и первопричину конечно же. К чему так остро острить.
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:
function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}
На ATS, тоже что-то подобное встречалось.
>>096318
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?
Ладно, убедил по большей части.
Аналогии про научный метод и математику, всё ж слишком уж широкие. Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций. Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
>Для диванного философа ты как-то хуевато с логикой дружишь.
Причину и первопричину конечно же. К чему так остро острить.
>это в любом случае code smell
Вот прям так и в любом? Я понимаю что для безопасного управлению памятью ацикличность очень удобна, но как быть с сущностями призванными соответствовать объектам предметной области, там: муж - жена, страна - столица, призывник - военкомат и прочие? В расте у нас выбор: либо rc, который также может приводить к утечкам (хотя и могли бы добавить механизм позволяющий ислючить перекрёстное владение, достаточно просто не настолько катострофически сложно), либо индексы. И с индексацией ещё одна проблема: чёрт с ней со скоростью, но мы, замечу пользуясь языком с весьма хардкорной типизацией, вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов. Ноль, "Иван Василиевич", 777 запромест какого-нибудь UserEntry. И тут псевдонимы типов спасают едва-едва. Хотя, я не уверен, можно в расте определить не просто численный тип, а численный тип определённый как индекс, некоего массива?
>А афинные типы-то тут при чем?
Я, кажется, не совсем понимаю что такое афинный тип. Мне казалось - это, коряво говоря, тип на данные которого может быть всегда только одна ссылка, поправь меня, пожалуйста. И если это всё чем он ограничевается, то какие тут спецефичные проблемы?
>сабтьюринговость достигается запретом явной рекурсии, например
А с неявной проще, или что ты имеешь в виду? Вот, на всякий случай код на дафне:
function Fac(n: int): int
decreases n
{
if n <= 0 then 1 else n * Fac(n - 1)
}
На ATS, тоже что-то подобное встречалось.
>>096318
>полной природы вычислительных систем с которыми мы работаем
Ну вся эта полнота интересна по большей части в своём лишь теоретическом аспекте, для практики же наоборот, чем её меньше - тем программа предсказуемей. Так сейчас достаточно редко используется правка машинного кода на лету, раньше же это не казалось чем-то уж таким. А раз уж от программы редко требуется что-то как принять данные, обработать их и выдать наружу (в самом широком смысле), то глядишь и получим со временем некую заведомо детерминированную модель.
>Излишество синтаксиса - грех.
Так-то да, но на фоне осальных монсров какие в расте сильно избыточные конструкции?
>>097510
Я речь веду о конкретной полноте, Господь-полноте.
Нельзя получить заведомо детерминированную модель в заведомо не детерминированном мире, только если ты не Господь.
Вон даже физики вероятностным распределением оперируют.
>Ну вся эта полнота
Я речь веду о конкретной полноте, Господь-полноте.
>то глядишь и получим со временем некую заведомо детерминированную модель
Нельзя получить заведомо детерминированную модель в заведомо не детерминированном мире, только если ты не Господь.
Вон даже физики вероятностным распределением оперируют.
>>097510
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.
Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".
> Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций.
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.
> Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.
Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.
> Причину и первопричину конечно же.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.
> как быть с сущностями призванными соответствовать объектам предметной области
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.
> вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.
> не просто численный тип, а численный тип определённый как индекс, некоего массива?
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.
> тип на данные которого может быть всегда только одна ссылка
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.
> какие тут спецефичные проблемы?
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.
> А с неявной проще, или что ты имеешь в виду?
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".
>>097510
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.
Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".
> Про написание корректного ПО выпущенны тонны различной литературы с наборами правил и рекомендаций.
Так уж и тонны? Все-таки ПО с доказательством корректности - это ОЧЕ узкая ниша, 95% софта это ненужно.
> Так что тут проблема лишь в том что они написанны на человеческом, а не на языке некоторой строгой формализации.
Так блядь, ты о чем говоришь-то? Сами доказательства пишутся на языке некоторой строгой формализации - на математическом языке они пишутся, теоремки там всякие, вот это все. Если ты пишешь компилятор и тебе нужно доказать его корректность, то ты, натурально, берешь и пишешь доказательство. Потом еще желательно как-то гарантировать, что твоя реализация твоему доказательству соответствует.
Если ты говоришь о "наборе правил и рекомендаций" по написанию корректного ПО, то тут никакой формализации быть не может, потому что само значение слова "корректное" зависит от предметной области, от бизнеса. Тут уже включается инженерный подход - в том числе скрумы-хуюмы, обратная связь, тестирование, да что угодно. Вот как гарантируют для некоторого значения слова "гарантируют", бгг, что самолет не упадет? С одной стороны - делают модель и формально доказывают, что оно вообще взлетит. С другой - тупо дублируют все системы и следуют хорошим инженерным практикам, дублируют людей, проверяют проверяющих, вот это все. Плюс все это происходит в расчете на долгие доходы, с огромными сроками и гигантскими бизнес-рисками, с относительно фиксированным планом и редким изменением требований. И эти гниды все равно падают.
> Причину и первопричину конечно же.
Бля, ну я не шарю в вашей философской фене, что написано - я то и читаю.
> как быть с сущностями призванными соответствовать объектам предметной области
Щито? Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области? Это просто пиздец, курсивом.
> вынужденны пользоваться числами, строками, да чем угодно вместо конкретных объектов
Ой блядь. Чувак, будет время - загугли на ютубе "values of values". Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.
> не просто численный тип, а численный тип определённый как индекс, некоего массива?
При чем тут это вообще? Не улавливаю, куда тебя понесло. В общем случае - это зависимые типы. Конкретно с индексами повыебывались в nim'е, емнип.
> тип на данные которого может быть всегда только одна ссылка
Ну, не одна, а ноль или одна. И не "ссылка на данные" (ссылок (иммутабельных) ты сколько угодно можешь на данные иметь), а само значение типа. Грубо говоря, в обычной логике мы принимаем как данность следствия типа x => x and x. В афинной - ты можешь только либо использовать в правой части букву из левой один раз, либо не использовать ни разу.
> какие тут спецефичные проблемы?
Я не знаю, это ты мне скажи - ты же через афинные собрался делать тоталити чек.
> А с неявной проще, или что ты имеешь в виду?
Ну если у тебя явная рекурсия запрещена, то ты как бы можешь ввести свои нескучные операторы рекурсии со своими нескучными типами, что позволит тебе обойтись без кривых костылей вроде "decreases n".
Я пардон за задержку.
>>097517
Повторюсь. Не нужно.
>>097690
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
Вкусовщина же. Да и универсальней на мой взгляд.
>>097517
>Господь-полноте.
Повторюсь. Не нужно.
>>097690
>зависит от предметной области, от бизнеса
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
>Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области?
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
>При чем тут это вообще? Не улавливаю, куда тебя понесло.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
>values of values
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
>ты же через афинные собрался делать тоталити чек
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
>без кривых костылей вроде "decreases n"
Вкусовщина же. Да и универсальней на мой взгляд.
Я пардон за задержку.
>>097517
Повторюсь. Не нужно.
>>097690
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
Вкусовщина же. Да и универсальней на мой взгляд.
>>097517
>Господь-полноте.
Повторюсь. Не нужно.
>>097690
>зависит от предметной области, от бизнеса
Ну во-первых и тут есть разнообразые решения в виде проверок, включая статические, пред/пост условий, инвариантов объекта, зависимых типов; но я всё же про корректность в более узком смылсе: безопасность при работе с памятью, отсутствие гонок - те вещи которые нам гарантируются в русте, ну и гарантии терменируемости, отсутствие взаимоблокировок и утечек - те, которых пока там нет.
>Блядь, ты понимаешь, что ты сейчас поставил на один уровень работу с памятью и моделирование предметной области?
Не, я их рядом не ставил. Я их как раз-таки противопоставил, подчеркнув что то, что хорошо и удобно для управления памятью, не всегда замечательно подходит для моделирования предметной области. И не нужно никакого пизцеца.
>При чем тут это вообще? Не улавливаю, куда тебя понесло.
Я о том, что используя индексацию мы маленько теряем преимущества статической типизации. В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое. С индексом, без как ты заметил зависимых типов, мы вновь открываем для себя эту область проблем - цифирь он и есть цифирь. Вырожденный и гротескный пример: выделяем вообще все объекты в одном, пускай будет, векторе, и работаем с ними через их индесы: получаем неудобный аналог языка динамической типизации, как по безопасности, так и по скорости.
>values of values
Не то видео, где патлач с маком заявляет о преимуществах неизменяемых сущностей над изменяемыми? Укажи минуту, если там что-то принципиально важное, что я упустил.
>ты же через афинные собрался делать тоталити чек
Вы мне явно приписываете подобные намерения, я лишь пожалел что до меня не сделали. И всё же какие-либо дополнительные проблемы тут мне сложно представить. Естественно, все вспомогательные предикаты должны не хоронить данные, а принимать их по неизменяемой ссылке.
>без кривых костылей вроде "decreases n"
Вкусовщина же. Да и универсальней на мой взгляд.
>>102675
Ну это не корректность, а просто более стронг гарантии компилятора. Ок.
Ну ты же сам сказал: как быть с сущностями из домейна, рс с ними использовать или массивы, что-то такое. Я и отвечаю, что "сущности из домейна" и массивы (рс, классы, объекты, хэшмапы...) - это понятия разных уровней.
Я вообще не ебу, о чем ты. Кто тебе в расте запрещает это делать? Какие индексы, какие цифири?
Нет, не об этом. Посмотри целиком. Алсо, повторюсь с прошлого поста: «Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.» Так что за "конкретные объекты"?
Блядь, я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют. Ты, очевидно, другого мнения, - вот я у тебя и спрашиваю (уже три поста подряд), как ты через афинные типы собрался делать тоталити чек.
Натуральный счетчик универсальней рекурсии? Ну, гхм.
>корректность в более узком смылсе
Ну это не корректность, а просто более стронг гарантии компилятора. Ок.
> Не, я их рядом не ставил.
Ну ты же сам сказал: как быть с сущностями из домейна, рс с ними использовать или массивы, что-то такое. Я и отвечаю, что "сущности из домейна" и массивы (рс, классы, объекты, хэшмапы...) - это понятия разных уровней.
> В тех же си, ди, го (наверное) мы можем определить тип как указатель на некую структуру, определить процедуры для работы с этим типом и не опасаться ошибочно передать этим процедурам что-то совершенно другое.
Я вообще не ебу, о чем ты. Кто тебе в расте запрещает это делать? Какие индексы, какие цифири?
> о преимуществах неизменяемых сущностей над изменяемыми
Нет, не об этом. Посмотри целиком. Алсо, повторюсь с прошлого поста: «Я не знаю, что такое "конкретные объекты". В расте есть структы, больше ничего не нужно.» Так что за "конкретные объекты"?
> я лишь пожалел что до меня не сделали
Блядь, я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют. Ты, очевидно, другого мнения, - вот я у тебя и спрашиваю (уже три поста подряд), как ты через афинные типы собрался делать тоталити чек.
> Вкусовщина же. Да и универсальней на мой взгляд.
Натуральный счетчик универсальней рекурсии? Ну, гхм.
>>102675
Повторяю, для детерминированной модели отражающей реальный мир - нужно.
Конечно, ты можешь построить какую угодно модель для чего угодно, но толку от нее, если она не работает?
А чтобы полностью детерминированная модель работала, тебе нужна Господь-полная система.
>>Господь-полноте.
>Повторюсь. Не нужно.
Повторяю, для детерминированной модели отражающей реальный мир - нужно.
Конечно, ты можешь построить какую угодно модель для чего угодно, но толку от нее, если она не работает?
А чтобы полностью детерминированная модель работала, тебе нужна Господь-полная система.
>>102797
Вот мы вроде бы и оба на русском пишем, а понимания больше не становится нихуя.
Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок. Их и предполагалось эмулировать через индексы.
Компилятор запрещает, кто же ещё. По прежнему о той же попытке эмуляции.
Я, наверное, очень хуёво умею свою мысль донести. Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру, изменяемую или нет. Которую, да, предполагается хранить в этой же самой структуре, например.
Как можно было придти к такому выводу? Я, вроде, сказал про "такое количество ограничений". Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
Наверняка не скажу, но там и для структурной деконструкции тоже что-то имеется. Ну и взаиморекурсивные вызовы, аккерманы с фибоначами, всё в примерах и рассматривается. Это ли не универсальность?
До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
>>102839
Я примерно понял о чём ты. Но тут-то наиболее важнен практический аспект: модель она на то и модель что позволяет абстрагироваться от несущественных в определённом контексте деталей. Не стоит же вопрос целиком весь мир эмулировать.
А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Вот мы вроде бы и оба на русском пишем, а понимания больше не становится нихуя.
>Я вообще не ебу, о чем ты.
Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок. Их и предполагалось эмулировать через индексы.
>Кто тебе в расте запрещает это делать?
Компилятор запрещает, кто же ещё. По прежнему о той же попытке эмуляции.
>Так что за "конкретные объекты"?
Я, наверное, очень хуёво умею свою мысль донести. Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру, изменяемую или нет. Которую, да, предполагается хранить в этой же самой структуре, например.
>я тебе говорю, что афинные типы к тоталити чеку никакого отношения не имеют
>Ты, очевидно, другого мнения
Как можно было придти к такому выводу? Я, вроде, сказал про "такое количество ограничений". Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
>Натуральный счетчик универсальней рекурсии?
Наверняка не скажу, но там и для структурной деконструкции тоже что-то имеется. Ну и взаиморекурсивные вызовы, аккерманы с фибоначами, всё в примерах и рассматривается. Это ли не универсальность?
До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
>>102839
Я примерно понял о чём ты. Но тут-то наиболее важнен практический аспект: модель она на то и модель что позволяет абстрагироваться от несущественных в определённом контексте деталей. Не стоит же вопрос целиком весь мир эмулировать.
А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Заебали сопли по забору размазывать.
Вот вам ваш двусвязный список из стандратной либы: 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
>>103142
При чем тут это? Ты написал, что в си можно указатели на структуру передавать в процедуры и не бояться, что туда придет что-то другое, а в расте динамическая типизация. Я и отвечаю: вообще не ебу, о чем ты.
Не запрещает. Берешь и передаешь.
Ну, и ты выше писал, что в расте этих "конкретных объектов" нет, и тебе приходится пользоваться числами и строками. Я тебе еще 2 поста назад сказал, что в расте есть структуры, больше ничего не надо. Теперь выясняется, что ты структуры и имел в виду. Шта.
Да ты заебал:
Ой блядь, ну и нахуя ты об этом тогда вообще пиздеть начал? Ой, все, иди нахуй.
Ну так ты не про универсальность как таковую говорил. Ты утверждал, что "Да и универсальней на мой взгляд". Теперь выясняется, что ты это опять просто от балды спизданул. Пиздос. Нахуй так жить.
linrec p o f g <=> h x: if p x then o x else g(h(f x)), как-то так. Соответственно, можно иметь разные комбинаторы для разных случаев (и даже с разными типами, в том числе и для unbound рекурсии), а "decreases n" хендлить на уровне обычной системы (зависимых) типов. Комбинаторы - joy, тотальность - charity, например.
>Промотай повыше. Весь разговор начался с вопроса создания взаиморекурсивных ссылок.
При чем тут это? Ты написал, что в си можно указатели на структуру передавать в процедуры и не бояться, что туда придет что-то другое, а в расте динамическая типизация. Я и отвечаю: вообще не ебу, о чем ты.
> Компилятор запрещает, кто же ещё.
Не запрещает. Берешь и передаешь.
> Давай считать что под "конкретными объектами" я понимал прямую ссылку на структуру
Ну, и ты выше писал, что в расте этих "конкретных объектов" нет, и тебе приходится пользоваться числами и строками. Я тебе еще 2 поста назад сказал, что в расте есть структуры, больше ничего не надо. Теперь выясняется, что ты структуры и имел в виду. Шта.
> Как можно было придти к такому выводу?
Да ты заебал:
>> А вообще при таком количестве ограничений как в ржавом, могли бы взаимные ссылки нормально сделать, и прочие писечки на манер гарантии тотальности.
> Ээ, расскажешь, как через афинные типы делать тоталити чек?
>> Тут я не матёрый дока нихуя, но что-то типа: ...
> Впрочем они всё ж скорее способствуют, чем препятствуют, но как конкретно сделать я сообщить не готов, да и не вызывался.
Ой блядь, ну и нахуя ты об этом тогда вообще пиздеть начал? Ой, все, иди нахуй.
> Это ли не универсальность?
Ну так ты не про универсальность как таковую говорил. Ты утверждал, что "Да и универсальней на мой взгляд". Теперь выясняется, что ты это опять просто от балды спизданул. Пиздос. Нахуй так жить.
> До кучи заинтересовал: покажи как выглядел бы примерно твой нескучный оператор рекурсии.
linrec p o f g <=> h x: if p x then o x else g(h(f x)), как-то так. Соответственно, можно иметь разные комбинаторы для разных случаев (и даже с разными типами, в том числе и для unbound рекурсии), а "decreases n" хендлить на уровне обычной системы (зависимых) типов. Комбинаторы - joy, тотальность - charity, например.
>>103229
Безопасность подаётся как основная фича языка. А тут, чтобы написать банальный связанный список, потребовалось три десятка раз её подавлять. Боюсь представить, что творится в ентерпрайз коде. Иными словами, основная идея раста разбивается при выходе в реальный мир.
Безопасность подаётся как основная фича языка. А тут, чтобы написать банальный связанный список, потребовалось три десятка раз её подавлять. Боюсь представить, что творится в ентерпрайз коде. Иными словами, основная идея раста разбивается при выходе в реальный мир.
>>103236
Мудила, ты часто реализуешь низкоуровневые структуры данных в бизнес коде?
Один раз написал и пользуешься во всем проекте. А это вообще в std. Хуле тебе надо-то?
Мудила, ты часто реализуешь низкоуровневые структуры данных в бизнес коде?
Один раз написал и пользуешься во всем проекте. А это вообще в std. Хуле тебе надо-то?
>>103236
Ща бы думать, что мутабельный список вещь банальная.
Тут как раз отлично отделены безопасные вещи и используя этот список, ты всегда в безопасности.
Вопросы скорее к твоему коду и задумке, если тебе приходится делать unsafe вне библиотек.
Ща бы думать, что мутабельный список вещь банальная.
Тут как раз отлично отделены безопасные вещи и используя этот список, ты всегда в безопасности.
Вопросы скорее к твоему коду и задумке, если тебе приходится делать unsafe вне библиотек.
>>103225
Вот как приведённых тобой моих высказываний "могли бы сделать..." и "я не матёрый дока нихуя" можно вывести "ты через афинные типы собрался делать тоталити чек"? Пользуясь аффинной логикой, наверное.
Ну и:
наконец-то пошла конструктивная риторика, сплошные опровержения в чистом виде. Ещё чуть-чуть и сможем воочию лицезреть как рождается истина, в муках выплёвываемая из уродливого влагалища спора. И тут либо я писать нормально не умею, либо ты - читать. Хуй с ним, будет желание, как поправишь нервишки, пересмотри ветку от начала, чтоб не драть почём зря фразы из контекста, а нет - да и в рот её ебать.
Вот как приведённых тобой моих высказываний "могли бы сделать..." и "я не матёрый дока нихуя" можно вывести "ты через афинные типы собрался делать тоталити чек"? Пользуясь аффинной логикой, наверное.
Ну и:
>Да ты заебал
>Ой, все, иди нахуй
>Нахуй так жить
наконец-то пошла конструктивная риторика, сплошные опровержения в чистом виде. Ещё чуть-чуть и сможем воочию лицезреть как рождается истина, в муках выплёвываемая из уродливого влагалища спора. И тут либо я писать нормально не умею, либо ты - читать. Хуй с ним, будет желание, как поправишь нервишки, пересмотри ветку от начала, чтоб не драть почём зря фразы из контекста, а нет - да и в рот её ебать.
>>103346
Ожидаемо. Я пробегаю глазами релевантные места по всему диалогу перед каждым своим ответом, а ты много пиздишь о том, в чем не шаришь, и идешь нахуй. Это интернеты, добро пожаловать снова.
Ожидаемо. Я пробегаю глазами релевантные места по всему диалогу перед каждым своим ответом, а ты много пиздишь о том, в чем не шаришь, и идешь нахуй. Это интернеты, добро пожаловать снова.
>>103142
Абсолютно любая программа.
Чтобы оценить всю принципиальную, а не потенциальную, ограниченность и неполноту, достаточно написать любую сколь нибудь реальную программу, и дать ее юзерам.
Ненужно много теоретизировать, достаточно простейшей практики, блядь. Прости Господи, любому живому человеку, кроме женщин разве что, должно быть понятно, как работает мир. Достаточно в детстве достаточно близко с природой взаимодействовать, получать синяки и прочие травмы.
Любой мат аппарат описывающий реальный мир включает в себя понятие шума и ошибки.
"Шум" - это нечто, от чего нельзя избавится принципиально.
От чего все эти хасхели, и прочие безумные идеи относительно доказтельности вычислений - полнейший бред.
Если мы может доказать, валидность вычисления, то мы фактически УЖЕ его совершили, то есть нам никакая программа ненужна вовсе, все уже посчитано.
Более того, практическое мышление\работа\программирование, не требует доказательств. Можно потратить всю жизнь на выведение доказательств, поиска зависимости в дробной части числа Pi, а можно без задней мысли решать инженерные проблемы.
>А вообще, нет ли у тебя примера достаточно доступного, чтоб мы могли оценить всю потенциальную ограниченность и неполноту?
Абсолютно любая программа.
Чтобы оценить всю принципиальную, а не потенциальную, ограниченность и неполноту, достаточно написать любую сколь нибудь реальную программу, и дать ее юзерам.
Ненужно много теоретизировать, достаточно простейшей практики, блядь. Прости Господи, любому живому человеку, кроме женщин разве что, должно быть понятно, как работает мир. Достаточно в детстве достаточно близко с природой взаимодействовать, получать синяки и прочие травмы.
Любой мат аппарат описывающий реальный мир включает в себя понятие шума и ошибки.
"Шум" - это нечто, от чего нельзя избавится принципиально.
От чего все эти хасхели, и прочие безумные идеи относительно доказтельности вычислений - полнейший бред.
Если мы может доказать, валидность вычисления, то мы фактически УЖЕ его совершили, то есть нам никакая программа ненужна вовсе, все уже посчитано.
Более того, практическое мышление\работа\программирование, не требует доказательств. Можно потратить всю жизнь на выведение доказательств, поиска зависимости в дробной части числа Pi, а можно без задней мысли решать инженерные проблемы.
>>103709
Ну хаскель-то как раз про вполне себе практичные вещи, хотя изначально для них и не предназначался.
мимо
Ну хаскель-то как раз про вполне себе практичные вещи, хотя изначально для них и не предназначался.
мимо
76 Кб, 1490x888Итак, самый важный вопрос: что самое сложное вы уже написали на расте? Показывайте гитхабики с писечками.
>>062380 (OP)
Сап, есть архив тредов?
Сап, есть архив тредов?
>>104264
Гудбай ворлд.
Гудбай ворлд.
>>062380 (OP)
Решил к вам вкатиться и ставлю ентон самый раст. А чего у него такая инсталяха мелкая то?
Решил к вам вкатиться и ставлю ентон самый раст. А чего у него такая инсталяха мелкая то?
>>106240
Сочувствую братишка, тут либо пердолинг с сертификатами (не факт что поможет) либо обход прокси сервера.
Сочувствую братишка, тут либо пердолинг с сертификатами (не факт что поможет) либо обход прокси сервера.
Двочь, покажи пример как захуярить на расте аналог горутин типа go someFunc()
Спасибо.
Спасибо.
100 Кб, 720x684>>106431
https://tokio.rs
https://github.com/carllerche/mio
>Двочь, покажи пример как захуярить на расте аналог горутин
https://tokio.rs
https://github.com/carllerche/mio
>>106311
Хз, это уже 2 разных провайдера, падазритльна
Хз, это уже 2 разных провайдера, падазритльна
>>106444
>>106485
>>106486
>>106530
Спасибо, пацаны, разобрался. Хотя и не так, как в го (там удобнее).
Еще такой момент, у меня есть одна libcore.c для встраиваемых устройств (С99). Но этот ебучий гугл по запросу `rust cffi example` подсовывает мне `calling rust from python` и подобное. Дайте, пожалуйста, пример или ссылку как вызвать из раста условный void hello(){printf("hello\n");}
>>106485
>>106486
>>106530
Спасибо, пацаны, разобрался. Хотя и не так, как в го (там удобнее).
Еще такой момент, у меня есть одна libcore.c для встраиваемых устройств (С99). Но этот ебучий гугл по запросу `rust cffi example` подсовывает мне `calling rust from python` и подобное. Дайте, пожалуйста, пример или ссылку как вызвать из раста условный void hello(){printf("hello\n");}
Поясните, почему этот ваш раст гуглится вместе с идрисом, агдой? Он что с зависимыми типами?
>>106977
Пример запроса в студию.
Пример запроса в студию.
>>106965
Код 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.
Код 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.
>>106965
Код 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.
Код 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.
>>106992
Спасибо
Спасибо
>>094144
Cpp -- общемировой стандарт с самым большим комьюнити, базой знаний, сумасшедшей кроссплатформенностью.
Зачем вообще плодить сущности, если они отличается какими-то там ссылками?
Cpp -- общемировой стандарт с самым большим комьюнити, базой знаний, сумасшедшей кроссплатформенностью.
Зачем вообще плодить сущности, если они отличается какими-то там ссылками?
>>111584
Но зачем придумывать точно такой же язык?
На ассемблере и пишут то, что нельзя написать на С.
На ассемблере нельзя писать переносимый код.
Но зачем придумывать точно такой же язык?
На ассемблере и пишут то, что нельзя написать на С.
На ассемблере нельзя писать переносимый код.
>>111594
Никто и не придумывает точно такой же язык. Просто ты либо тупенький, либо жирненький-зелененький.
А на си - типобезопасный, и что?
Иди тролли в другом месте.
>Но зачем придумывать точно такой же язык?
Никто и не придумывает точно такой же язык. Просто ты либо тупенький, либо жирненький-зелененький.
>На ассемблере нельзя писать переносимый код.
А на си - типобезопасный, и что?
Иди тролли в другом месте.
>>111925
скажи это расту
А типобезопасность расслабит голову на 99%, оставив место для действительно важных вещей, логики например.
> такие языки всегда будут неэффективными
скажи это расту
А типобезопасность расслабит голову на 99%, оставив место для действительно важных вещей, логики например.
>>111578
Потому что c++ тридцатилетний ворох костылей и замечательных решений.
Потому что c++ тридцатилетний ворох костылей и замечательных решений.
>>062380 (OP)
Как сделать итератор по &T?
Как сделать итератор по &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]
>>070417
Навскидку, если ты скомпилируешь что-то на языке Dafny, то оно заработает без косяков.
Навскидку, если ты скомпилируешь что-то на языке Dafny, то оно заработает без косяков.
>>112555
Как включить эту штуку глобально, чтобы не пихать в каждый файл?
Как включить эту штуку глобально, чтобы не пихать в каждый файл?
>>113058
Ок, завезли method Main, походу становится можно писать standalone applications.
Ок, завезли method Main, походу становится можно писать standalone applications.
>>113138
Просто у туземцев есть дигри по комплюктер сцайенс, так что параметрический полиморфизм они и называют параметрическим полиморфизмом, а инопланетных джава-макак делают вид, что не понимают.
> пикрелейтед
Просто у туземцев есть дигри по комплюктер сцайенс, так что параметрический полиморфизм они и называют параметрическим полиморфизмом, а инопланетных джава-макак делают вид, что не понимают.
>>113211
Это у промышленных макак называется параметрическим полиморфизмом, а в академии это статический полиморфизм.
Это у промышленных макак называется параметрическим полиморфизмом, а в академии это статический полиморфизм.
>>113484
Статик — это C++ костыли, а оригинальный параметрический полиморфизм из ML 70-ых годов.
Статик — это C++ костыли, а оригинальный параметрический полиморфизм из ML 70-ых годов.
>>113484
Почему ты настолько тупой, что даже текст по собственной ссылке прочитать не можешь?
> Static polymorphism typically occurs in ad hoc polymorphism and parametric polymorphism, whereas dynamic polymorphism is usual for subtype polymorphism.
Почему ты настолько тупой, что даже текст по собственной ссылке прочитать не можешь?
>>113596
Щас бы спорить с быдлом о дефинициях. Но давай, мне интересно посмотреть, как ты будешь вертеться, объясняя мне, где я не прав.
Щас бы спорить с быдлом о дефинициях. Но давай, мне интересно посмотреть, как ты будешь вертеться, объясняя мне, где я не прав.
>>113586
Но в ML вычисление параметризованного типа происходит точно так же как и специализация шаблона с крестах - во время компиляции, вот почему терминологически static polymorphism более удачен даже если не вспоминать про ad hoc полиморфизм - с тайпклассами или рабоче-крестьянски.
Но в ML вычисление параметризованного типа происходит точно так же как и специализация шаблона с крестах - во время компиляции, вот почему терминологически static polymorphism более удачен даже если не вспоминать про ad hoc полиморфизм - с тайпклассами или рабоче-крестьянски.
>>113684
Он не имеет смысла, потому что это низкоуровневая деталь, а не суть, к тому же там все статик.
Он не имеет смысла, потому что это низкоуровневая деталь, а не суть, к тому же там все статик.
Как же вы заебали со своим нытьем. Уебывайте в хаскель тред нахуй.
>>113705
>Различие языков по динамической и статической типизации не имеет смысла, это низкоуровневая деталь
>>113973
Если в твоем случае это преимущества, то тебе раст не нужен.
Если в твоем случае это преимущества, то тебе раст не нужен.
>>114454
Жирный, очевидно были приведены пункты которые в определенных ситуациях являются недостатками голенга.
Жирный, очевидно были приведены пункты которые в определенных ситуациях являются недостатками голенга.
43 Кб, 1024x576Бампусики.
Игори 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
>>116569
Шо сказать то хотел?
Шо сказать то хотел?
>>116569
Это как? Просвети. Бывают, значит, не полностью функциональные, а бывают совсем не функциональные, так? Накидай-ка примерчиков всех трех.
> полностью функциональной системой типов.
Это как? Просвети. Бывают, значит, не полностью функциональные, а бывают совсем не функциональные, так? Накидай-ка примерчиков всех трех.
>>116655
Функциональные в смысле те, что использующиеся в языках, традиционно называющихся функциональными.
То есть алгебраические типы данных с хаскеллевыми тайпклассами.
Функциональные в смысле те, что использующиеся в языках, традиционно называющихся функциональными.
То есть алгебраические типы данных с хаскеллевыми тайпклассами.
>>116277
ОТКРЫЛ ВКЛАДКУ https://tokio.rs
@
ПРИМЕР НА ИНДЕКСНОЙ
@
.unwrap();
@
.unwrap();
@
.UNWRAP();
@
ЗАКРЫЛ ВКЛАДКУ
>Асинк делоть
ОТКРЫЛ ВКЛАДКУ https://tokio.rs
@
ПРИМЕР НА ИНДЕКСНОЙ
@
.unwrap();
@
.unwrap();
@
.UNWRAP();
@
ЗАКРЫЛ ВКЛАДКУ
>>117939
Прикинь, программирование оно такое. Дохуя где могут быть ошибки.
Конечно try {} catch () {} наше все, да?
Прикинь, программирование оно такое. Дохуя где могут быть ошибки.
Конечно try {} catch () {} наше все, да?
>>117953
Мань, ну че ты как маленький. В main пока нельзя пользоваться ?try!(). Поэтому в примерах юзают unwrap().
В настоящем коде это будет либо прокинуто наверх через ? либо expect()
Мань, ну че ты как маленький. В main пока нельзя пользоваться ?try!(). Поэтому в примерах юзают unwrap().
В настоящем коде это будет либо прокинуто наверх через ? либо expect()
>>117987
Зачем вы постите несмешное?
Зачем вы постите несмешное?
>>117787
В определении ORM. Хотя сама библиотека адекватна и ORM можно упомянуть, чтобы хотя-бы пояснить назначение библиотеки (аналог ORM-ов из ваших ооп-языков)
В определении ORM. Хотя сама библиотека адекватна и ORM можно упомянуть, чтобы хотя-бы пояснить назначение библиотеки (аналог ORM-ов из ваших ооп-языков)
>>117939
А как по-твоему должен асинк работать? Поменяешь на andThen в продакшене и поедешь
А как по-твоему должен асинк работать? Поменяешь на andThen в продакшене и поедешь
>>118156
Ну так в чем проблема-то?
Ну так в чем проблема-то?
> 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) который вариант енама?
>>121317
Какой пример? Вопрос самодостаточен, можешь вообще читать только последние два предложения.
Вкратце, Стив Клабник мне ответил, что Some это есть функция, которая возвращает Option. А как тогда выглядит собственно сам Some, именно вариант, не функция? То есть let hueta = Some(5), какой тип у hueta? Просто Option<i32>? То есть я не могу просто так взять и без паттерн матчинга понять, что содержится в хуете.
Это касается так же и всех остальных енамов.
По ходу, это просто такое у них устройство на низком уровне.
Но все равно как-то мутно для меня это всё
Какой пример? Вопрос самодостаточен, можешь вообще читать только последние два предложения.
Вкратце, Стив Клабник мне ответил, что Some это есть функция, которая возвращает Option. А как тогда выглядит собственно сам Some, именно вариант, не функция? То есть let hueta = Some(5), какой тип у hueta? Просто Option<i32>? То есть я не могу просто так взять и без паттерн матчинга понять, что содержится в хуете.
Это касается так же и всех остальных енамов.
По ходу, это просто такое у них устройство на низком уровне.
Но все равно как-то мутно для меня это всё
>>121323
Дык я об этом и говорю.
Если и обоих вариантов, иу Some, и у None общий тип - то выходит блядь простым смертным недоступно узнать разницу между ними на уровне имплементации самих енамов. Все что нам дают - возможность сравнивать и матчить. Я все правильно всосал?
Дык я об этом и говорю.
Если и обоих вариантов, иу Some, и у None общий тип - то выходит блядь простым смертным недоступно узнать разницу между ними на уровне имплементации самих енамов. Все что нам дают - возможность сравнивать и матчить. Я все правильно всосал?
>>121326
В этом и заключается главный смысл.
Ты обязан тем или иным образом обработать разные варианты енума.
map точно так же внутри себя делает паттерн матчинг
match option {
Some(x) => f(x),
None => None,
}
В этом и заключается главный смысл.
Ты обязан тем или иным образом обработать разные варианты енума.
map точно так же внутри себя делает паттерн матчинг
match option {
Some(x) => f(x),
None => None,
}
>>121328
На огороде бузина.
Ты ответил не совсем на то, о чем я спрашивал.
Ватевер, принцип я вкурил, а дальше буду адаптироваться.
На огороде бузина.
Ты ответил не совсем на то, о чем я спрашивал.
Ватевер, принцип я вкурил, а дальше буду адаптироваться.
>>121332
Ну в общем случае енумы это tagged union
[tag, max(enum_variant)]
В случае Option используется NULL для None и указатель на данные иначе.
Ну в общем случае енумы это tagged union
[tag, max(enum_variant)]
В случае Option используется NULL для None и указатель на данные иначе.
Спросил в треде про Пщ, спрошу и здесь. Знатоки Rust, расскажите, пожалуйста, что в Rust есть хорошего, и что плохого.
>>126612
Мне интересно мнение прошаренных людей, которые уже как следует изучили Rust и могут описать все или почти все его недостатки.
Мне интересно мнение прошаренных людей, которые уже как следует изучили Rust и могут описать все или почти все его недостатки.
>>127088
Основной недостаток - взрыв мозга при первой встрече с борроу-чекером и вообще писать, "как на других языках", не получается. Ну то есть, читай, порог вхождения высоковат.
Основной недостаток - взрыв мозга при первой встрече с борроу-чекером и вообще писать, "как на других языках", не получается. Ну то есть, читай, порог вхождения высоковат.
>>081347
Ох уж эти манямиры прыщеблядей.
Ох уж эти манямиры прыщеблядей.
>>127822
Почему недостатоток? Это же киллер-фича, пересмотр сложившейся традиции построения ЯП.
Почему недостатоток? Это же киллер-фича, пересмотр сложившейся традиции построения ЯП.
>>128431
Глупо конечно это отрицать. Но так же глупо отрицать то, что в это надо въехать. Хотя мне кажется многие через чур драматизируют по этому поводу, система владения в русте достаточно простая, раз в нее смогла за день въехать такая жс/го макака как я.
Глупо конечно это отрицать. Но так же глупо отрицать то, что в это надо въехать. Хотя мне кажется многие через чур драматизируют по этому поводу, система владения в русте достаточно простая, раз в нее смогла за день въехать такая жс/го макака как я.
>>128458
Да это те же пойнтеры, только компилятор с ними очень строгий: или кто-то один пишет, или все читают. По сути компилятор тебя и обучает.
Да это те же пойнтеры, только компилятор с ними очень строгий: или кто-то один пишет, или все читают. По сути компилятор тебя и обучает.
Сидел, читал доки по Rust - на первый взгляд, такой толковый язык. Полез смотреть разные заказы/вакансии по нему - и почти нигде ничего.
Грустно.
Пока что Rust - это, похоже, язык-мем.
Грустно.
Пока что Rust - это, похоже, язык-мем.
>>130201
Для задач где го недостаточно выразительный, всякие джавы/сисярпы/хаскели медленные и прожорливые, с/с++ недостаточно простые и безопасные.
Для задач где го недостаточно выразительный, всякие джавы/сисярпы/хаскели медленные и прожорливые, с/с++ недостаточно простые и безопасные.
>>130839
Скажем делаешь ты игру. У игры есть очень четкое требование — успевать всю хуйню сделать за 16мс, чтобы ты получил свои 60фпс. А голанг может тебе хуйню сборку мусора на 10мс.
Плюс рано или позно тебя заебет копипастить слайс-трикс и код в целом, потому что нет дженериков.
Скажем делаешь ты игру. У игры есть очень четкое требование — успевать всю хуйню сделать за 16мс, чтобы ты получил свои 60фпс. А голанг может тебе хуйню сборку мусора на 10мс.
Плюс рано или позно тебя заебет копипастить слайс-трикс и код в целом, потому что нет дженериков.
>>130201
Переписали на нем с джавы софтину, которая 24/365 крутилась на cortex-a5 256mb ram. Теперь переписываем с C код для cortex-m4 128kb sram.
Сначала было непросто понять, что хочет компилятор и борроу-чекер, теперь придрочились. Во втором случае еще и с сетапом/инициализацией пришлось повозиться (то что пилит japaric нам не подошло).
Еще можешь глянуть Макса Лапшина на highload++, он для камер на ARMv5 пилит чото.
Переписали на нем с джавы софтину, которая 24/365 крутилась на cortex-a5 256mb ram. Теперь переписываем с C код для cortex-m4 128kb sram.
Сначала было непросто понять, что хочет компилятор и борроу-чекер, теперь придрочились. Во втором случае еще и с сетапом/инициализацией пришлось повозиться (то что пилит japaric нам не подошло).
Еще можешь глянуть Макса Лапшина на highload++, он для камер на ARMv5 пилит чото.
>>131144
Еще дело в более выразительной системе типов и возможности писать безопасный многопоточный код.
Каналы и горутины это конечно хорошо, но они ни капли не спасают от того что рантайм го может тебе крашануть приложение из-за небезопасного доступа к map.
Еще дело в более выразительной системе типов и возможности писать безопасный многопоточный код.
Каналы и горутины это конечно хорошо, но они ни капли не спасают от того что рантайм го может тебе крашануть приложение из-за небезопасного доступа к map.
>>131193
В многих аспектах да.
За это приходится платишь более высокой сложностью вкатывания, более медленной компиляцией и пока что меньшим размером коммьюнити. Впрочем, раст моложе и вангую что через 3-5 лет он будет так же популярен как и го в своей нише.
В многих аспектах да.
За это приходится платишь более высокой сложностью вкатывания, более медленной компиляцией и пока что меньшим размером коммьюнити. Впрочем, раст моложе и вангую что через 3-5 лет он будет так же популярен как и го в своей нише.
>>131253
Эта хуета показывает что го никак тебя не защищает от проблем многопоточного кода. В данном случае я спокойно могу иметь несколько ссылок на хэш-таблицу и модифицировать её в разных тредах, при этом закономерно получая фатальную ошибку которая никак не ловится.
Эта хуета показывает что го никак тебя не защищает от проблем многопоточного кода. В данном случае я спокойно могу иметь несколько ссылок на хэш-таблицу и модифицировать её в разных тредах, при этом закономерно получая фатальную ошибку которая никак не ловится.
>>131253
В том то и проблема го, что многие го программисты(читай бывшие скриптомакаки) не понимают, что этот код работает не правило и такого не должно быть.
В том то и проблема го, что многие го программисты(читай бывшие скриптомакаки) не понимают, что этот код работает не правило и такого не должно быть.
>>131542
Почему проблема? Это заявленная фича. Скриптомакакам должно быть легко вкатываться и индусить код во блага хозяина.
Почему проблема? Это заявленная фича. Скриптомакакам должно быть легко вкатываться и индусить код во блага хозяина.
>>132121
Да, там пол книжки про стандартную либу и как с её помощью решать задачи. При этом написано хорошо, а не в стиле референса.
Да, там пол книжки про стандартную либу и как с её помощью решать задачи. При этом написано хорошо, а не в стиле референса.
>>132123
Ну что ж, посмотрю. Вообще я поковырял палкой их справку, довольно интересный яп.
Ну что ж, посмотрю. Вообще я поковырял палкой их справку, довольно интересный яп.
>>132129
Можешь начать с оф. книжки. Она короткая и по делу.
Можешь начать с оф. книжки. Она короткая и по делу.
>>131144
Я джавист, и с джавы переписывать сложно только те части, где наследование и рефлексия.
Парни которые могут в сишку сказали, что есть некоторые сложности с хардкорной байтоеблей, поначалу тупо все в unsafe пихали а потом его минимизировали. Сейчас ансейф только там где риальне нужен (регистры там, dma всякое и обертки над сторонними либами), остальное проверяется борроу-чекером.
Я джавист, и с джавы переписывать сложно только те части, где наследование и рефлексия.
Парни которые могут в сишку сказали, что есть некоторые сложности с хардкорной байтоеблей, поначалу тупо все в unsafe пихали а потом его минимизировали. Сейчас ансейф только там где риальне нужен (регистры там, dma всякое и обертки над сторонними либами), остальное проверяется борроу-чекером.
>>132699
Спасибо конечно, но мне нужно сначала с синтаксисом разобраться.
Спасибо конечно, но мне нужно сначала с синтаксисом разобраться.
>>132734
Если в результате свой деятельности ты приходишь к выводу, что жс не лучший выбор. Например, ты можешь прийти к заключению, что типизация помогает решать множество проблем, ценой небольших ограничений.
Затем если ты уже используешь rust на бекэнде (см. diesel.rs), то вполне возможно, что фронтэнд на расте может быть вполне себе неплохой идеей. В конце концов гугловцы уже давным давно так делают с жавой.
Если в результате свой деятельности ты приходишь к выводу, что жс не лучший выбор. Например, ты можешь прийти к заключению, что типизация помогает решать множество проблем, ценой небольших ограничений.
Затем если ты уже используешь rust на бекэнде (см. diesel.rs), то вполне возможно, что фронтэнд на расте может быть вполне себе неплохой идеей. В конце концов гугловцы уже давным давно так делают с жавой.
>>132772
Если она тебе ну нужна, что ты вообще делаешь в расто-треде тогда?
> Например, ты можешь прийти к заключению,
Если она тебе ну нужна, что ты вообще делаешь в расто-треде тогда?
>>132785
Ты просто завидуешь.
Ты просто завидуешь.
>>134559
Всего этого нет в го.
> zero-cost abstractions
> move semantics
> guaranteed memory safety
> threads without data races
> trait-based generics
> pattern matching
> type inference
> minimal runtime
> efficient C bindings
Всего этого нет в го.
>>134570
А я вот пару недель назад начал вкатываться в Го, и меня настигло осознание, что программки с Gui на нём не напишешь. На ruste можно программки писать с окошками и кнопочками под винду?
А я вот пару недель назад начал вкатываться в Го, и меня настигло осознание, что программки с Gui на нём не напишешь. На ruste можно программки писать с окошками и кнопочками под винду?
>>134571
С чего бы не напишешь-то? Берешь биндинг к любому тулкиту и пишешь. С растом то же самое. Все делается через биндинги к тулкитам. Ну или можешь винапи заюзать, но только нахуя?
С чего бы не напишешь-то? Берешь биндинг к любому тулкиту и пишешь. С растом то же самое. Все делается через биндинги к тулкитам. Ну или можешь винапи заюзать, но только нахуя?
>>134580
О, спасиб. Действительно всё есть
https://github.com/cyndis/qmlrs
https://github.com/therecipe/qt
Просто петушня и го-треде сказала, что нет.
О, спасиб. Действительно всё есть
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.
>>146036
Я прям слышу смех всех этих "системных программистов", "инженеров", людей высокого полета (уровень разработки, где мне круд-макаке никогда не бывать) и у меня прям стыд какой-то берет. Это сейчас такой новый уровень? Куда делись те самые нудные бородочи из моей юности, которые бы не стали смеяться над пару строк кода с какого-то подобия пазлера и рандомных картинок?
Я прям слышу смех всех этих "системных программистов", "инженеров", людей высокого полета (уровень разработки, где мне круд-макаке никогда не бывать) и у меня прям стыд какой-то берет. Это сейчас такой новый уровень? Куда делись те самые нудные бородочи из моей юности, которые бы не стали смеяться над пару строк кода с какого-то подобия пазлера и рандомных картинок?
>>146039
В основном на пенсию. Некоторые продолжают ебать байты на сях в мокрософтах и редхатах, некоторые в эмбеде микроконтроллеры для новых стиралок electrolux ебут. Некоторые для автомобилей программы ЭБУ пишут уже нет: https://www.drive2.ru/b/466174514431001350/
В целом все системное по уже написано и нового никто не пишет, лишь сопровождают и дополняют новыми фичами.
>Куда делись те самые нудные бородочи из моей юности
В основном на пенсию. Некоторые продолжают ебать байты на сях в мокрософтах и редхатах, некоторые в эмбеде микроконтроллеры для новых стиралок electrolux ебут. Некоторые для автомобилей программы ЭБУ пишут уже нет: https://www.drive2.ru/b/466174514431001350/
В целом все системное по уже написано и нового никто не пишет, лишь сопровождают и дополняют новыми фичами.
>>146143
Заебись, еще один аргументик в сторону смерти кодерков. Алсо, буду теперь байтоблядей этой ссылкой траллить.
>Некоторые для автомобилей программы ЭБУ пишут уже нет: https://www.drive2.ru/b/466174514431001350/
Заебись, еще один аргументик в сторону смерти кодерков. Алсо, буду теперь байтоблядей этой ссылкой траллить.
Хуле вы разнылись. Охуенно же, когда полезные вещи с юморком подают. Это намного пизже, чем слушать жующего говно дауна.
>>146146
Ты б хоть почитал для начала. Этой ссылкой можно траллить разве что сервисы компьютерной диагностики двигателей.
>буду теперь байтоблядей этой ссылкой траллить
Ты б хоть почитал для начала. Этой ссылкой можно траллить разве что сервисы компьютерной диагностики двигателей.
1,2 Мб, 636x477>>146164
Хорошо рассказывает, только большую часть шуток я не понимаю, по крайней мере с чего ржёт зал.
Хорошо рассказывает, только большую часть шуток я не понимаю, по крайней мере с чего ржёт зал.
>>146184
В основном с того, что понимают боль, которую описывает спикер.
В основном с того, что понимают боль, которую описывает спикер.
>>146171
> За это отвечают сложные модели. Например одна из сложнейших и важнейших ее подсистем “модель температуры выпускных газов”. Именно она отвечает за механизмы ограничения мощности и дает опорные значения в механизмы обогащения состава для защиты компонентов. И эта модель в современных ЭБУ чрезвычайно сложна – она производит больше вычислений и имеет больше калибровочных данных, чем например весь мотек м800 во всех своих алгоритмах в принципе. Ее описание занимает 82 страницы мелкого текста. Сама она написана не людьми — исходный текст функции транслирован с ASCETа. Но это не значит, что все ее алгоритмы заданны прямыми физическими константами и формулами из физики – там все еще огромное количество эвристики. Огромное количество сложно формализуемых подгонов под ответ, для производителя это не представляет каких то проблем, поскольку одни и те же люди годами занимаются только ей, и они знают в ней все – как таковые задачи формализации там не стоят. Это даже не инженеры и не программисты — это прикладники с глубоким знанием термодинамики
>>146205
Вычислительные мощности и сложность систем управления постоянно растут. Хотя и исходя из общей тормознутости процесса эволюции электронных компонентов для автомобильной промышленности они делают это очень медленно, существует точка, когда пространство знаний о системе необходимое для ее настройки, начинает превышать возможности одного человеческого индивидуума * на время его жизни. Т.е. если скажем раньше у вас была система с объемом кода 32кб и за 2 месяца вы могли порезать ее в лапшу, и при наличии нужных инструментов и знаний сделать из этой лапши вполне себе удобоваримое блюдо. То вам не хватит и года, чтоб сделать то же самое с системой где объем кода 1мб – а это не современная система. Это система 15-ти летней давности. Что уж говорить о современных. Я пока вот не написал тут и 2-х страниц текста – а описание современной системы управления — 20 тысяч таких страниц. Мы давно уже пришли к тому, что современная система управления принципиально непознаваема в целом на уровне одного человека. Т.е. в мире просто нет ни одного человека, способного реализовать конечную задачу настройки такой системы в целом – это способен делать только лишь коллектив из специалистов, причем каждый должен быть специалистом именно в своей области и решать задачу настройки только для своей части вверенных ему алгоритмов.
Вычислительные мощности и сложность систем управления постоянно растут. Хотя и исходя из общей тормознутости процесса эволюции электронных компонентов для автомобильной промышленности они делают это очень медленно, существует точка, когда пространство знаний о системе необходимое для ее настройки, начинает превышать возможности одного человеческого индивидуума * на время его жизни. Т.е. если скажем раньше у вас была система с объемом кода 32кб и за 2 месяца вы могли порезать ее в лапшу, и при наличии нужных инструментов и знаний сделать из этой лапши вполне себе удобоваримое блюдо. То вам не хватит и года, чтоб сделать то же самое с системой где объем кода 1мб – а это не современная система. Это система 15-ти летней давности. Что уж говорить о современных. Я пока вот не написал тут и 2-х страниц текста – а описание современной системы управления — 20 тысяч таких страниц. Мы давно уже пришли к тому, что современная система управления принципиально непознаваема в целом на уровне одного человека. Т.е. в мире просто нет ни одного человека, способного реализовать конечную задачу настройки такой системы в целом – это способен делать только лишь коллектив из специалистов, причем каждый должен быть специалистом именно в своей области и решать задачу настройки только для своей части вверенных ему алгоритмов.
>>146205
>>146210
Алё, они там реверсят бинарники прошивок чтобы накручивать движки как захочется. Причём здесь обычная разработка софта из исходников? Неужели система впрыска бензина это блеать 20к страниц текста? Мне кажется производители довыёбываются, и в ход пойдёт какой-нибудь опенсорцный контроллер с открытыми исходниками. Единственное что сейчас этому препятствует это большое разнообразие моделей авто.
>>146210
Алё, они там реверсят бинарники прошивок чтобы накручивать движки как захочется. Причём здесь обычная разработка софта из исходников? Неужели система впрыска бензина это блеать 20к страниц текста? Мне кажется производители довыёбываются, и в ход пойдёт какой-нибудь опенсорцный контроллер с открытыми исходниками. Единственное что сейчас этому препятствует это большое разнообразие моделей авто.
>>146218
О, тут вот как раз Maxi подобных кодерков разъебывает:
https://rusefi.com/forum/viewtopic.php?f=8&t=1012&start=30
>кажется производители довыёбываются, и в ход пойдёт какой-нибудь опенсорцный контроллер с открытыми исходниками. Единственное что сейчас этому препятствует это большое разнообразие моделей авто.
О, тут вот как раз Maxi подобных кодерков разъебывает:
https://rusefi.com/forum/viewtopic.php?f=8&t=1012&start=30
>>146226
Чёт там неясно ещё кто кого разъёбывает. Обычный жир и разговор слепого с глухим.
Чёт там неясно ещё кто кого разъёбывает. Обычный жир и разговор слепого с глухим.
>>146218
Так речь о том, что хуй они там чего отреверсят и поймут, потому что современные алгоритмы управления двигателем - это хуйпойми какое автогенеренное говно с разными физматмоделями и прочей нечеткологикой. И привычных для говнотюнеров табличек "уоз" и "цикловое наполнение" которые можно крутить там нет -все на алгоритмах и сотнях параметров.
>>146230
Ну макси, конечно, тот еще жирный тролль, который промышляет быдлосборочками на январь 5 из пизженых исходников серийных прошивок, но тут он прав - кодерки без соответствующей теоретической базы по собственным представлениям и максимум - даташитам изобретают уже десятый по счету велосипед 80-х годов, когда весь мир уже в 21 веке.
>Алё, они там реверсят бинарники прошивок чтобы накручивать движки как захочется
Так речь о том, что хуй они там чего отреверсят и поймут, потому что современные алгоритмы управления двигателем - это хуйпойми какое автогенеренное говно с разными физматмоделями и прочей нечеткологикой. И привычных для говнотюнеров табличек "уоз" и "цикловое наполнение" которые можно крутить там нет -все на алгоритмах и сотнях параметров.
>>146230
Ну макси, конечно, тот еще жирный тролль, который промышляет быдлосборочками на январь 5 из пизженых исходников серийных прошивок, но тут он прав - кодерки без соответствующей теоретической базы по собственным представлениям и максимум - даташитам изобретают уже десятый по счету велосипед 80-х годов, когда весь мир уже в 21 веке.
>>146235
Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят? Ну нарушат нахуй никому ненужные экологические нормы, ну придётся каждый раз подкручивать, так как контроллер уже не самообучается на собранных с датчиков данных. Но ведь можно наваливать! Не ради этого ли всё?
Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят? Ну нарушат нахуй никому ненужные экологические нормы, ну придётся каждый раз подкручивать, так как контроллер уже не самообучается на собранных с датчиков данных. Но ведь можно наваливать! Не ради этого ли всё?
>>146237
В том то и дело, что нихуя у них толком не работает нормально:
https://rusefi.com/forum/viewforum.php?f=15
Они даже универсальный обработчик дпкв (это который шкив с зубьями у которого один зуб пропущен и магнитный датчик читает эти зубья-впадины, определяя таким образом угол поворота коленвала) не осилили и в сорцах у них вот такой вот пиздец:
https://github.com/rusefi/rusefi/tree/master/firmware/controllers/trigger/decoders
А детонацию они и вовсе не осилили, даже применив специализированную микросхему.
Да и сам код в принципе тоже охуенен - си с примесью плюсов в стиле си-с-классами, макролапша везде, зато гордо заявляют что не используют периферию микроконтроллера и с гордостью хуярят оверхеднутый код на програмных прерываниях и счетчике в цикле программы поверх ChibiOS. из-за чего у них в проекте ебический микроконтроллер STM32F469, который не реализует и доли функционала восьмибитного c509 из январей, у которого и периферия, и производительность в разы меньше.
>Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят? Ну нарушат нахуй никому ненужные экологические нормы, ну придётся каждый раз подкручивать, так как контроллер уже не самообучается на собранных с датчиков данных. Но ведь можно наваливать! Не ради этого ли всё?
В том то и дело, что нихуя у них толком не работает нормально:
https://rusefi.com/forum/viewforum.php?f=15
Они даже универсальный обработчик дпкв (это который шкив с зубьями у которого один зуб пропущен и магнитный датчик читает эти зубья-впадины, определяя таким образом угол поворота коленвала) не осилили и в сорцах у них вот такой вот пиздец:
https://github.com/rusefi/rusefi/tree/master/firmware/controllers/trigger/decoders
А детонацию они и вовсе не осилили, даже применив специализированную микросхему.
Да и сам код в принципе тоже охуенен - си с примесью плюсов в стиле си-с-классами, макролапша везде, зато гордо заявляют что не используют периферию микроконтроллера и с гордостью хуярят оверхеднутый код на програмных прерываниях и счетчике в цикле программы поверх ChibiOS. из-за чего у них в проекте ебический микроконтроллер STM32F469, который не реализует и доли функционала восьмибитного c509 из январей, у которого и периферия, и производительность в разы меньше.
>>146244
А, ты про тюхнеров серийных блоков с модельным принципом - нет, нихуя у них не работает - максимум на что хватает им мозгов - это сбросить параметры самообучения и зашить начальные карты (и то, это для отностительно старых мозгов, где еще присутсвовали начальные калибровки по-калькуляторному), после чего лох, отваливший им деньги пол дня наваливает, после чего прошивка свои калибровки восстанавливает и его тачка снова превращается в овощ, а если он её еще и затюнил - впуск/выпуск/турбина, то она вообще встает на прикол, потому что мозг от таких раскладов охуевает и отказывается крутить мотор, высветив чек. Туо потому что в ней нет таблиц калибровок, а НЕХ, в виде сотен выведенных матмоделей, пид-регуляторов и прочих нечетких логик, которые даже не людьми писались, а генерились машиной на основании данных от инженегров, проектировавших конретный двигатель и конкретный код затем еще и автоматически оптимизировался и дописывался машиной при доводке образца двигателя на диностенде. Ну типа как нейросеть обучают, только на выходе - код.
Поэтому для тюнинха вырезают штатный блок, переделывают проводку и ставят древнее говнецо вроде пресловутых 5-7 январей, у которых прошивка по принципу "калькулятор на фиксированных таблицах", или блоки вроде мотека и аема, которые суть те же калькуляторы.
>Я не очень в курсе, но разве не работают у кодерков эти самые велосипеды в точности как они хотят?
А, ты про тюхнеров серийных блоков с модельным принципом - нет, нихуя у них не работает - максимум на что хватает им мозгов - это сбросить параметры самообучения и зашить начальные карты (и то, это для отностительно старых мозгов, где еще присутсвовали начальные калибровки по-калькуляторному), после чего лох, отваливший им деньги пол дня наваливает, после чего прошивка свои калибровки восстанавливает и его тачка снова превращается в овощ, а если он её еще и затюнил - впуск/выпуск/турбина, то она вообще встает на прикол, потому что мозг от таких раскладов охуевает и отказывается крутить мотор, высветив чек. Туо потому что в ней нет таблиц калибровок, а НЕХ, в виде сотен выведенных матмоделей, пид-регуляторов и прочих нечетких логик, которые даже не людьми писались, а генерились машиной на основании данных от инженегров, проектировавших конретный двигатель и конкретный код затем еще и автоматически оптимизировался и дописывался машиной при доводке образца двигателя на диностенде. Ну типа как нейросеть обучают, только на выходе - код.
Поэтому для тюнинха вырезают штатный блок, переделывают проводку и ставят древнее говнецо вроде пресловутых 5-7 январей, у которых прошивка по принципу "калькулятор на фиксированных таблицах", или блоки вроде мотека и аема, которые суть те же калькуляторы.
>>146249
>>146252
Способствует зарождение стендапа в ИТ.
Конечно, взять старый язык и ржать над недостатками, это реально потолок интеллекта. Хотя если ты полез в системное программирование тебе так или иначе придется дружит с плюсами, с си и даже с ассемблером, чего смешного? Неужели непонятно что технологии идут и трудно новые парадигмы натунять на старый синтаксис не сломав все? В чем тут забава, это как смеяться над старой машиной и в противовес современной, которая была создана чтобы победить ту самую машину (кажется глупым это да? Но это тоже самое)??
Мол смотрите, мы делали язык убирающий недостатки С++ и смотрите у нас получилось - ну обосаца.
Я бы лучше послушал конфу о подводных камнях раста, что там может ждать и как это решать, чем конфу со смешными картинками, где в очередной раз побеждают динозавров индустрии, очередным поделием над llvm.
Это, имхо, уровень какого-то javascript (у меня не бомбит, не пофиг на С++, но просто где С++ а где раст, зачем они настраивают огромное комьюнити С++ против себя же?)
>>146252
>Чем он лучше плюсов?
Способствует зарождение стендапа в ИТ.
Конечно, взять старый язык и ржать над недостатками, это реально потолок интеллекта. Хотя если ты полез в системное программирование тебе так или иначе придется дружит с плюсами, с си и даже с ассемблером, чего смешного? Неужели непонятно что технологии идут и трудно новые парадигмы натунять на старый синтаксис не сломав все? В чем тут забава, это как смеяться над старой машиной и в противовес современной, которая была создана чтобы победить ту самую машину (кажется глупым это да? Но это тоже самое)??
Мол смотрите, мы делали язык убирающий недостатки С++ и смотрите у нас получилось - ну обосаца.
Я бы лучше послушал конфу о подводных камнях раста, что там может ждать и как это решать, чем конфу со смешными картинками, где в очередной раз побеждают динозавров индустрии, очередным поделием над llvm.
Это, имхо, уровень какого-то javascript (у меня не бомбит, не пофиг на С++, но просто где С++ а где раст, зачем они настраивают огромное комьюнити С++ против себя же?)
>>064865
Экономика сейчас такая что шахтеры и педиатры нахуй никому ненужны, хочешь выжить умей крутится.
>А сейчас, так вообще, шутка-ли. У знакомой на работе, один коллега раньше педиатром работал, другой - шахтером.
Экономика сейчас такая что шахтеры и педиатры нахуй никому ненужны, хочешь выжить умей крутится.
>>070417
Чтобы избежать ошибок нужен идеальный образец, а где ты его найдешь? Чтобы сделать скульптуру бабы тебе нужна баба которая будет позировать, без нее будет НЕХ.
>Избежать ошибок можно только одним способом - не быть криворуким дауном.
Чтобы избежать ошибок нужен идеальный образец, а где ты его найдешь? Чтобы сделать скульптуру бабы тебе нужна баба которая будет позировать, без нее будет НЕХ.
Когда у Мозиллы закончатся деньги из-за доминирования хромобраузеров, то кто будет оплачивать разработку этого языка?
>>083506
Связь в позиционировании как убийцы си.
Связь в позиционировании как убийцы си.
>>147009
Платов даст $250/мес.
Платов даст $250/мес.
>>147357
Нет. Надо английский.
Нет. Надо английский.
>>146773
Это не сортировка и не поиск и половине тестов он проигрывает, да и еще больше памяти потребляет. Убийца, мда...
Это не сортировка и не поиск и половине тестов он проигрывает, да и еще больше памяти потребляет. Убийца, мда...
28 Кб, 677x276>>147407
Если тебе нужно рационализировать почему тебе не нужен раст и почему C++ лучше/быстрее/надёжнее, то можешь просто вспомнить, что в России работы на расте не будет ближайшие N лет.
Если тебе нужно рационализировать почему тебе не нужен раст и почему C++ лучше/быстрее/надёжнее, то можешь просто вспомнить, что в России работы на расте не будет ближайшие N лет.
>>147410
Начнем с того, что это пиздеж. Работа уже есть.
Плюс, тебе никто не запрещает продвигать использование раста внутри компании. Другой вопрос, если ты безыдейное чмо. Тогда жри что дают и не выебывайся.
Начнем с того, что это пиздеж. Работа уже есть.
Плюс, тебе никто не запрещает продвигать использование раста внутри компании. Другой вопрос, если ты безыдейное чмо. Тогда жри что дают и не выебывайся.
140 Кб, 1920x1080>>147416
У тебя пикча отклеилась.
У тебя пикча отклеилась.
>>147415
Ну тогда становись начальником и впихивай раст сам.
Либо не еби мозг, пользуйся в личных целях, или для реализации того, на что благословение начальство ненужно (тулинг, утилиты, ...). Через пару лет вакансий однозначно будет больше.
Ну тогда становись начальником и впихивай раст сам.
Либо не еби мозг, пользуйся в личных целях, или для реализации того, на что благословение начальство ненужно (тулинг, утилиты, ...). Через пару лет вакансий однозначно будет больше.
>>147423
То, что решает задачу лучше старого инструмента.
Надеюсь ты ездишь на Ваз 2101, пользуешься холодильником "Зил" и ходишь в ватнике. Ведь будет непоследовательно пользоваться по жизни более совершенными вещами, оставаясь замшелым старпероуебком.
То, что решает задачу лучше старого инструмента.
Надеюсь ты ездишь на Ваз 2101, пользуешься холодильником "Зил" и ходишь в ватнике. Ведь будет непоследовательно пользоваться по жизни более совершенными вещами, оставаясь замшелым старпероуебком.
>>147422
Ты определись сначала со своей точкой зрения.
>пиздеж. Работа уже есть
>становись начальником и впихивай
>пользуйся в личных целях
>Через пару лет вакансий
Ты определись сначала со своей точкой зрения.
>>147427
Я со своей определился. Работа есть.
Человек сказал что
Раз человек хочет остаться в рашке, но при этом не заниматься наебакойнами, вариантов не так и много.
Я со своей определился. Работа есть.
Человек сказал что
> А что если я не хочу пилить блядские НаёбаКойны, вот просто из принципа?
Раз человек хочет остаться в рашке, но при этом не заниматься наебакойнами, вариантов не так и много.
>>147426
Но ведь Раст не решает. Его обещали как идентичную по производительности замену, а этого не произошло.
Но ведь Раст не решает. Его обещали как идентичную по производительности замену, а этого не произошло.
>>147432
"Работает охуенно быстро" != "производительность идентичная $хyuta"
При условии возраста компилятора производительность вполне неплохая и будет становится только лучше.
Лично для меня главные фичи расте это безопасность и выразительность.
"Работает охуенно быстро" != "производительность идентичная $хyuta"
При условии возраста компилятора производительность вполне неплохая и будет становится только лучше.
Лично для меня главные фичи расте это безопасность и выразительность.
>>147426
Если проводить аналогию, вместо ваза тебе предлагают бээмвэ с кожаными креслами, но мотором от скутера в 100 кубиков, который жрет по 1000 литров бензина на 100км, а на вопрос "а чо не едет-то?" начинают втирать, что скорость нинужна, динамика нинужна, у нас экология и вообще - у всех приличных людей маршруты до магазина и от дома рядом с работой, а на лишний бензин у всех деньги есть.
Но в плане автомобилей в реальности сложилось все иначе - автомобили стали быстрее, комфортнее, и экономичнее (с ресурсом только вот шляпа в 2000х пошла).
Языки же программирования развились так, что программисты отупели и школьник-за-отзiв, нахватавшийся по верхам всех фреймворков стал вместо нелепости и источника петросянских шуток на башорке полноправным участником рынка труда, программы по прежнему имеют те же функции что и в 80х-90х, но жрут больше памяти и требуют в миллион раз более быстрых процессоров и умудряются при этом тормозить.
>То, что решает задачу лучше старого инструмента.
>Надеюсь ты ездишь на Ваз 2101, пользуешься холодильником "Зил" и ходишь в ватнике. Ведь будет непоследовательно пользоваться по жизни более совершенными вещами, оставаясь замшелым старпероуебком.
Если проводить аналогию, вместо ваза тебе предлагают бээмвэ с кожаными креслами, но мотором от скутера в 100 кубиков, который жрет по 1000 литров бензина на 100км, а на вопрос "а чо не едет-то?" начинают втирать, что скорость нинужна, динамика нинужна, у нас экология и вообще - у всех приличных людей маршруты до магазина и от дома рядом с работой, а на лишний бензин у всех деньги есть.
Но в плане автомобилей в реальности сложилось все иначе - автомобили стали быстрее, комфортнее, и экономичнее (с ресурсом только вот шляпа в 2000х пошла).
Языки же программирования развились так, что программисты отупели и школьник-за-отзiв, нахватавшийся по верхам всех фреймворков стал вместо нелепости и источника петросянских шуток на башорке полноправным участником рынка труда, программы по прежнему имеют те же функции что и в 80х-90х, но жрут больше памяти и требуют в миллион раз более быстрых процессоров и умудряются при этом тормозить.
>>147479
В 80-90х само разнообразие программ, аппаратные возможности, возможности ОС, внешний вид, дизайн, юзабилити — всё это было крайне скудным. Всё разрабатывалось под железо, как ты любишь, большинство этого софта не дожило до сегодняшнего дня, так как оно всё негибкое, его проще сделать заново чем приспособить под новые реалии, в нём нет ни апи, ни скриптинга, ничего, тупо exe и фиксированный гуй.
Никакие школьники софт серьёзнее бота в телеграм или простой игры никогда не разрабатывали и не будут.
В 80-90х само разнообразие программ, аппаратные возможности, возможности ОС, внешний вид, дизайн, юзабилити — всё это было крайне скудным. Всё разрабатывалось под железо, как ты любишь, большинство этого софта не дожило до сегодняшнего дня, так как оно всё негибкое, его проще сделать заново чем приспособить под новые реалии, в нём нет ни апи, ни скриптинга, ничего, тупо exe и фиксированный гуй.
Никакие школьники софт серьёзнее бота в телеграм или простой игры никогда не разрабатывали и не будут.
>>147479
Какое-то убогое старперское мышление, с отрицанием очевидных фактов.
Просто открой любой сайт из 2000ых и любой современный сайт. Чуешь разницу? Или сравни турбо-дельфи и современных монстров из мира иде.
Ты можешь классно ехать на своей копейке, правда придется постоянно боятся того, что она тебе щас глушак в жопу вставит.
Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка. Стоимость и скорость разработки чаще важнее. Надежность полученного решения тоже часто важнее скорости.
Обычно, скорость реально важна в одном небольшом участке. И у раста есть все инструменты для того чтобы оптимизировать то, что важно.
Какое-то убогое старперское мышление, с отрицанием очевидных фактов.
Просто открой любой сайт из 2000ых и любой современный сайт. Чуешь разницу? Или сравни турбо-дельфи и современных монстров из мира иде.
Ты можешь классно ехать на своей копейке, правда придется постоянно боятся того, что она тебе щас глушак в жопу вставит.
Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка. Стоимость и скорость разработки чаще важнее. Надежность полученного решения тоже часто важнее скорости.
Обычно, скорость реально важна в одном небольшом участке. И у раста есть все инструменты для того чтобы оптимизировать то, что важно.
>Просто открой любой сайт из 2000ых и любой современный сайт.
Весит 100500 гб, тормозит на пекарнях 3-4 летней давности, куча аякса и свистелкоперделок, иформации - столько же.
> Или сравни турбо-дельфи и современных монстров из мира иде.
В старых хотя бы было было формошлепство и куча визардов, тогда действительно пилили инструменты для RAD, кое было не пустым звуком, современные монстры из мира IDE - это просто жрущие процессор и память блокноты. И вижалстудия и идея нынче - это сраные блокноты, зато с кучей фреймворков и прочей скриптопитушни, которую все равно надо хуячить руками. В ебаном делфи быстрее приложения разрабатывать, чем сейчас - нахуярь кучу конфигурационных файлов, внедри в систему сборки менеджер пакетов из интернета (экскаватор - и привет, работа встала, фреймворки не скачать, в го вообще пизданулись - внедрили в стандартязыка ссылки на гитхаб), нахуячь все руками с использованием сотен фреймворков.
> Скорость выполнения всего лишь один из факторов. При чем для подавляющего большинства разрабатываемого софта этот фактор идет в конце списка.
Оно и видно.
> Стоимость и скорость разработки чаще важнее.
И на выходе тормознутое говно и "64 гб corei5 хватит для запуска хеллоуворлда, а 128гб+corei7 - для запуска простого калькулятора - для инженерного нужен уже core i9 в разгоне или сервак с последними зионами".
> Надежность полученного решения тоже часто важнее скорости.
Угу, падение по причине Out-Of-Memory сюда же. Куча уязвимостей в скриптопараше - туда же. Вечный статус "бета" у большинства скриптопитушиных тулзов и постоянное ломание API и стандарта языка (привет, педон) - туда же.
>>147487
Обычно - тормоза складываются из синергии - там небольшой просос на абстракциях - тут гарбадж коллектор тупанул, там код криво отджитился, зддесь компилятор тупанул и все - пизда, калькулятор обычный с требованиями "i5+64GB ram".
>Обычно, скорость реально важна в одном небольшом участке.
Обычно - тормоза складываются из синергии - там небольшой просос на абстракциях - тут гарбадж коллектор тупанул, там код криво отджитился, зддесь компилятор тупанул и все - пизда, калькулятор обычный с требованиями "i5+64GB ram".
>>147508
Ну дык реалии таковы, что в конкурентной борьбе побеждает быстрейший, а не тот, кто дрочил на сях, как деды.
Ну дык реалии таковы, что в конкурентной борьбе побеждает быстрейший, а не тот, кто дрочил на сях, как деды.
>>147512
То же самое относится к сям. Тут маллок затупил, здесь на отъебись сделали лишь бы работало. Ой сегфолт. Извините.
То же самое относится к сям. Тут маллок затупил, здесь на отъебись сделали лишь бы работало. Ой сегфолт. Извините.
>>147513
Пока что в конкурентной борьбе победила посредственность и глобальное понижения качества как программистов так и конечного продукта.
Вот стараются диды, стараются, платформы для ваших говноязыков пидорят, что бы ваша параша хоть как-то работала толком, а вы тут хипстоту-отрицал из себя корчите, помрут вот диды, некому будет для вашей параши JVM и прочие LLVM и V8 писать а диды из интела уже нисмогут очередное поколение процессоров вам выдать и все - пизда вам котятки.
>Ну дык реалии таковы, что в конкурентной борьбе побеждает быстрейший
Пока что в конкурентной борьбе победила посредственность и глобальное понижения качества как программистов так и конечного продукта.
> кто дрочил на сях, как деды
Вот стараются диды, стараются, платформы для ваших говноязыков пидорят, что бы ваша параша хоть как-то работала толком, а вы тут хипстоту-отрицал из себя корчите, помрут вот диды, некому будет для вашей параши JVM и прочие LLVM и V8 писать а диды из интела уже нисмогут очередное поколение процессоров вам выдать и все - пизда вам котятки.
>>147522
У тебя какие-то комплексы. Любая индустрия проходит через этап когда в ней ебется только "илитка", а потом приходят казуалы. Вот только нормальные люди не рефлексируют на тему.
Люди как раз и придумывают альтернативы дедовским методам.
У тебя какие-то комплексы. Любая индустрия проходит через этап когда в ней ебется только "илитка", а потом приходят казуалы. Вот только нормальные люди не рефлексируют на тему.
Люди как раз и придумывают альтернативы дедовским методам.
>>147522
Если почитать /hw/, то в общем-то диды уже своё дело сделали по большому счёту. Там если убрать бонусы от новых техпроцессов ускорение самой архитектуры с каждым поколением порядка 5%. И такое продолжается уже почти 10 лет.
Алсо, взять питон, руби, там например не могут отрезать GIL по 20 лет. Ваши хвалёные диды.
Я видел как перезапиливают большой проект на плюсах. Дидовский код тысячами строк сносится как неактуальный/устаревший/ненужный. Новые плюсы это уже по сути другой язык и писать на нём нужно совершенно иначе. Алсо, дидов в проекте не было, сплошной молодняк, очень толковые ребята с охуенным знанием modern c++. И вот кстати раст они очень котируют. Один из них даже контрибьютит и в раст, и в llvm.
Короче я вот что скажу. Пиздёж это всё что раньше ничего не тормозило. Что диды такие охуенно незаменимые и что все отупели. То что вы там где-то установили IDE с тысячей плагинов от тысячи разных людей — это всё исключительно ваши проблемы.
Если почитать /hw/, то в общем-то диды уже своё дело сделали по большому счёту. Там если убрать бонусы от новых техпроцессов ускорение самой архитектуры с каждым поколением порядка 5%. И такое продолжается уже почти 10 лет.
Алсо, взять питон, руби, там например не могут отрезать GIL по 20 лет. Ваши хвалёные диды.
Я видел как перезапиливают большой проект на плюсах. Дидовский код тысячами строк сносится как неактуальный/устаревший/ненужный. Новые плюсы это уже по сути другой язык и писать на нём нужно совершенно иначе. Алсо, дидов в проекте не было, сплошной молодняк, очень толковые ребята с охуенным знанием modern c++. И вот кстати раст они очень котируют. Один из них даже контрибьютит и в раст, и в llvm.
Короче я вот что скажу. Пиздёж это всё что раньше ничего не тормозило. Что диды такие охуенно незаменимые и что все отупели. То что вы там где-то установили IDE с тысячей плагинов от тысячи разных людей — это всё исключительно ваши проблемы.
>>147528
Тащемта, наоборот (опустив изначальный этап - военные компании на охулиард денег исследуют кучу всего, что поом попадает к простым быдлам), - сначала хипстеры залетают на рынок, потом их медленно и печально сжирает крупняк, так было и с авиацией, и с автомобилями и из недавнего - с пекарнями. И остается илитка.
Придумывали - средства разработки 90х соревновались друг с другом дабы убрать ручной пердолинг, при этом все работало быстро. В 2000х заменили на петушение конфигов и написание кода руками в емаксе, конфигурацию проекта через командную строку ключами, как раз как у дидов из 70х-80х.
>Любая индустрия проходит через этап когда в ней ебется только "илитка", а потом приходят казуалы.
Тащемта, наоборот (опустив изначальный этап - военные компании на охулиард денег исследуют кучу всего, что поом попадает к простым быдлам), - сначала хипстеры залетают на рынок, потом их медленно и печально сжирает крупняк, так было и с авиацией, и с автомобилями и из недавнего - с пекарнями. И остается илитка.
> Люди как раз и придумывают альтернативы дедовским методам.
Придумывали - средства разработки 90х соревновались друг с другом дабы убрать ручной пердолинг, при этом все работало быстро. В 2000х заменили на петушение конфигов и написание кода руками в емаксе, конфигурацию проекта через командную строку ключами, как раз как у дидов из 70х-80х.
>>147534
Не на том уровне абстракции думаешь.
"Илитка" владеет толпой казуалов.
Ну почему рынок иде для рисования кода провалился, есть мысли?
Не на том уровне абстракции думаешь.
"Илитка" владеет толпой казуалов.
Ну почему рынок иде для рисования кода провалился, есть мысли?
>>147541
Потому что в моду вошли те самые "дидовские технологии" из юникса 70х, причем в плохом смысле этого слова. Под лозунгом "жму швабодка консоль зато бисплатна".
И хипстопетушня это успшно схавала, теперь, как и диды времен доса, приписывает пути, пердолит консольку и думает "ну я то быстрее дидов из 90х теперь код пишу".
Окститесь, дебилы, вы взяли у "дидов" самое худшее - то самое говно мамонта в качестве инструментов, только более тормознутое, и теперь кичитесь "ну мы-то саврименнее дидов". Нет, вы по второму разу жрете уже схаванное и высранное дидами говно. Только вот диды осознали это и в 90х родили RAD, удобные отладчики, генераторы кода. Вы же програмимируете в блокнотах, пишите дополнительно к коду кучу конфигов и билдскриптов (у дидов достаточно было нажать F5 и единственное что нужно было прописывать - это пути до новых хедеров/либок)
>Ну почему рынок иде для рисования кода провалился, есть мысли?
Потому что в моду вошли те самые "дидовские технологии" из юникса 70х, причем в плохом смысле этого слова. Под лозунгом "жму швабодка консоль зато бисплатна".
И хипстопетушня это успшно схавала, теперь, как и диды времен доса, приписывает пути, пердолит консольку и думает "ну я то быстрее дидов из 90х теперь код пишу".
Окститесь, дебилы, вы взяли у "дидов" самое худшее - то самое говно мамонта в качестве инструментов, только более тормознутое, и теперь кичитесь "ну мы-то саврименнее дидов". Нет, вы по второму разу жрете уже схаванное и высранное дидами говно. Только вот диды осознали это и в 90х родили RAD, удобные отладчики, генераторы кода. Вы же програмимируете в блокнотах, пишите дополнительно к коду кучу конфигов и билдскриптов (у дидов достаточно было нажать F5 и единственное что нужно было прописывать - это пути до новых хедеров/либок)
>>147550
Ты упускаешь один момент. Чтобы что-то собрать теперь не нужна IDE (лично мне такое охуенно пригождалось много раз, и ни разу импортирование в IDE не проходило как надо, зато из консольки собиралось на раз-два). И сборку теперь часто делает облако, куда в принципе IDE не накатишь.
Программирование в блокнотах это фича. Программирование вообще не должно содержать в себе машинную работу. Меньше кода — правильнее сделан ЯП. Кодогенерация это тот ещё пердолинг.
Ты упускаешь один момент. Чтобы что-то собрать теперь не нужна IDE (лично мне такое охуенно пригождалось много раз, и ни разу импортирование в IDE не проходило как надо, зато из консольки собиралось на раз-два). И сборку теперь часто делает облако, куда в принципе IDE не накатишь.
Программирование в блокнотах это фича. Программирование вообще не должно содержать в себе машинную работу. Меньше кода — правильнее сделан ЯП. Кодогенерация это тот ещё пердолинг.
>>147550
Хуйня какая-то. Я бы с удовольствием перекатился на инструмент, который решает за меня ебаные задачи. Но таких инструментов тупо нет. Может только блюпринты в игровых движках.
Хуйня какая-то. Я бы с удовольствием перекатился на инструмент, который решает за меня ебаные задачи. Но таких инструментов тупо нет. Может только блюпринты в игровых движках.
>>147550
Какие-то маняпроекции. Если ты пишешь в блокноте - то это твои личные проблемы. Сабж-то тут при чем?
>ы же програмимируете в блокнотах, пишите дополнительно к коду кучу конфигов и билдскриптов
Какие-то маняпроекции. Если ты пишешь в блокноте - то это твои личные проблемы. Сабж-то тут при чем?
188 Кб, 1048x796>>147625
Только ты у нас умница, носишься по тредам со своим детектором, ловя какого-то выдуманного шизика (когда на самом деле шизик это ты).
Что по расту - печаль. Печаль когда язык, созданный побеждать С++, по производительности и потреблению ресурсов "не хуже" чем С++.
Понятно, что производительность это вообще главная фича С/С++ иначе все давно писали бы на джавах или питонах. Но мне просто интересно, что там в расте так жрет и тормозит? Просто, я к чему, если окунуться в раст, то везде слышно про нулевую стоимость и всякие вундер-слова, но на деле все не так. Помню, самое забавное, когда раст за-релизили, на том сайте (с говно тестами) он был на уроне java (чуть быстрее), а ОЗУ жрал почти на ровне. Я, конечно понимаю, те бенчмарки это то еще подкрученное чудо , но выглядело забавно.
Второй вопрос, почему стремятся сделать языки максимально не похожими на си, но хотят чтобы он си при этом победил? Если раньше, все просто копипастили синтаксис си и это являлось успехом, то каким местом текущие поколение поняло - что надо максимально делать не комфортным перекат между языков? Ладно, вам повезло и вы кодите на одном языке, но это же не так, вам приходится переключать между языками и привычка одного сразу же начинает проявляться в другом языке (и наоборот)?
Я не беру в расчет тех людей, которые играют в языки, я именно про каждодневную работу, одна только позиция типов может вынести мозг, когда снова переключаешься.
Только ты у нас умница, носишься по тредам со своим детектором, ловя какого-то выдуманного шизика (когда на самом деле шизик это ты).
Что по расту - печаль. Печаль когда язык, созданный побеждать С++, по производительности и потреблению ресурсов "не хуже" чем С++.
Понятно, что производительность это вообще главная фича С/С++ иначе все давно писали бы на джавах или питонах. Но мне просто интересно, что там в расте так жрет и тормозит? Просто, я к чему, если окунуться в раст, то везде слышно про нулевую стоимость и всякие вундер-слова, но на деле все не так. Помню, самое забавное, когда раст за-релизили, на том сайте (с говно тестами) он был на уроне java (чуть быстрее), а ОЗУ жрал почти на ровне. Я, конечно понимаю, те бенчмарки это то еще подкрученное чудо , но выглядело забавно.
Второй вопрос, почему стремятся сделать языки максимально не похожими на си, но хотят чтобы он си при этом победил? Если раньше, все просто копипастили синтаксис си и это являлось успехом, то каким местом текущие поколение поняло - что надо максимально делать не комфортным перекат между языков? Ладно, вам повезло и вы кодите на одном языке, но это же не так, вам приходится переключать между языками и привычка одного сразу же начинает проявляться в другом языке (и наоборот)?
Я не беру в расчет тех людей, которые играют в языки, я именно про каждодневную работу, одна только позиция типов может вынести мозг, когда снова переключаешься.
>>147809
Чего блядь?
Высер твой не читал, разумеется.
>Только ты у нас умница, носишься по тредам со своим детектором, ловя какого-то выдуманного шизика
Чего блядь?
Высер твой не читал, разумеется.
>>147809
http://c-faq.com/decl/spiral.anderson.html
Почитай, например, "Дизайн и эволюция С++" где сам Страуструп говорит от том, что он бы и сделал по человечески (как в паскале), но без совместимости с си нихуя не взлетело бы.
http://c-faq.com/decl/spiral.anderson.html
Почитай, например, "Дизайн и эволюция С++" где сам Страуструп говорит от том, что он бы и сделал по человечески (как в паскале), но без совместимости с си нихуя не взлетело бы.
>>147809
"Раст не хуже C++" потому что сравнивается g++ и llvm. Если сравнивать clang и rust, то будет паритет.
"Раст не хуже C++" потому что сравнивается g++ и llvm. Если сравнивать clang и rust, то будет паритет.
Народ, поясните, как сделать safe обертку над c_void? Все, что находил - про указатели на функции. Вот пример - fn glBufferData(target: GLenum, size: GLsizeiptr, data: const GLvoid, usage: GLenum). Что вместо data передавать в обертке?
И вообще, что за хуйня тут у вас с постингом? Я с Вьетнама, не могу ничего писать, приходится через прокси заходить? При этом именно с рашкованского?
Блять, еще и указатель(звездочка) пропадает!
Наверное не так выразился - как передать что-то, либо null pointer? Понимаю, что надо как-то юзать Option, но как? За Растом третий день, нравится, сука)))
>>149682
А расте принципиально нет null пойнтеров. Я уже плохо помню опенгл, там точно есть случай как в data нужно null передать? Тогда или option, или отдельную функцию сделать, без параметра data.
А расте принципиально нет null пойнтеров. Я уже плохо помню опенгл, там точно есть случай как в data нужно null передать? Тогда или option, или отдельную функцию сделать, без параметра data.
>>149799
Там такое на каждом шагу. Там еще есть эпичный
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glVertexAttribPointer.xhtml
Ну и да, вот почему никто не умеет гуглить?
https://stackoverflow.com/questions/24191249/working-with-c-void-in-an-ffi
>там точно есть случай как в 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
>>149824
Бля, я даже сначала не поверил.
> 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);
Бля, я даже сначала не поверил.
>>149826
А чего, решили просто не изобретать велосипед, в старом опенгл (который под видюхи первого поколения, которые еще даже без t&L были и где геометрия софтово считалась) была уже функция с подходящими параметрами, вот и изменили смысл одного параметра - теперь это не пойнтер на реальные вершины в RAM, а оффсет в BufferObject(который теперь и в VRAM может быть).
>Бля, я даже сначала не поверил.
А чего, решили просто не изобретать велосипед, в старом опенгл (который под видюхи первого поколения, которые еще даже без t&L были и где геометрия софтово считалась) была уже функция с подходящими параметрами, вот и изменили смысл одного параметра - теперь это не пойнтер на реальные вершины в RAM, а оффсет в BufferObject(который теперь и в VRAM может быть).
>>149824
Спасибо за попытку помочь, но это немного не то. Хочется сырые указатели спрятать в обертку, а передавать что-то типа 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. Не могу сообразить, можно ли и как сделать это с другими типами.
Спасибо за попытку помочь, но это немного не то. Хочется сырые указатели спрятать в обертку, а передавать что-то типа 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. Не могу сообразить, можно ли и как сделать это с другими типами.
>>149838
Это понятно, но unsafe можно спрятать в обертку, в которую передавать ссылку на что-то. Но что делать, когда это "что-то" может быть null?
Например, ссылки на callback функции передаются так:
fn glfwSetKeyCallback(window: *const GLFWwindow, cbfun: Option<GLFWkeyfun>) -> Option<GLFWkeyfun>;
Если поставить вместо Option<GLFWkeyfun> None - передастся null, и преобразовывать ничего не нужно.
Это понятно, но 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, а потом в указатель!
>>149848
https://github.com/gfx-rs/gfx/blob/b7d88cadc890474d161940ac8f78c1dfbe33b65b/src/backend/gl/src/info.rs#L115
> Млять, там же еще и двойной указатель на GLchar! Значит надо массив str еще как-то преобразовывать в массив CString, а потом в указатель!
https://github.com/gfx-rs/gfx/blob/b7d88cadc890474d161940ac8f78c1dfbe33b65b/src/backend/gl/src/info.rs#L115
>>149849
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()
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()
>>149851
Не, это наоборот.
Уже нашел тут: 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, хочется сделать обертку один в один, но безопасную. Понятно, что можно готовые биндинги взять, но хочется понять, как сделать самому.
Не, это наоборот.
Уже нашел тут: 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, хочется сделать обертку один в один, но безопасную. Понятно, что можно готовые биндинги взять, но хочется понять, как сделать самому.
>>149855
Удачи, чо, безопасную сделать. С учетом того что опенгл вполне себе умеет в ноги стрелять самостоятельно.
>хочется сделать обертку один в один, но безопасную.
>OpenGL
>State-Based API
>Еще и асинхронное
>У которого вызов GAPI != выполнение действия
Удачи, чо, безопасную сделать. С учетом того что опенгл вполне себе умеет в ноги стрелять самостоятельно.
Возьми уже https://github.com/gfx-rs/gfx и не еби никому мозг.
>>149858
Я же написал, что FFI изучаю. Ежу понятно, что проще и лучше взять готовое. Но что если мне понадобится функция из либы, для которой нет растовых оберток?
Я же написал, что FFI изучаю. Ежу понятно, что проще и лучше взять готовое. Но что если мне понадобится функция из либы, для которой нет растовых оберток?
>>149857
Но весь прикол в том, что о том что что то полетит ты не узнаешь пока не дернешь glGetError. Причем GAPI по своей сути устроено так что нужно совершать определенный магический порядок действий и это само по себе делает его ну вообще нихуя не безопасным. Прикола добавляет то, что еще и каждый вендор по-разному считает правильным порядок действий. В реальных гл рендерах такое обилие костылей и подпорок из серии (анализируем код вендора, ага вот тут мы кор-фичу не используем она забагованная, зато берем ровно ту же ARB(EXT) потому что она на этой конкретной видюхе робит нормуль), что забудь просто свои маняфантазии о безопасном в растовом смысле. Опенгл - это худший пистолет для выстрелов в ногу с которым когда либо кому-либо приходилось работать.
>Безопасную в растовом смысле. Типа если что полетит, то точно в unsafe.
Но весь прикол в том, что о том что что то полетит ты не узнаешь пока не дернешь glGetError. Причем GAPI по своей сути устроено так что нужно совершать определенный магический порядок действий и это само по себе делает его ну вообще нихуя не безопасным. Прикола добавляет то, что еще и каждый вендор по-разному считает правильным порядок действий. В реальных гл рендерах такое обилие костылей и подпорок из серии (анализируем код вендора, ага вот тут мы кор-фичу не используем она забагованная, зато берем ровно ту же ARB(EXT) потому что она на этой конкретной видюхе робит нормуль), что забудь просто свои маняфантазии о безопасном в растовом смысле. Опенгл - это худший пистолет для выстрелов в ногу с которым когда либо кому-либо приходилось работать.
>>149858
КроссAPI рендер они запилили, а КроссShaderLanguage - хуй, еби атрибуты с юниформами сам. Хоть бы трупак Nvidia CG реанимировали, чтоле.
КроссAPI рендер они запилили, а КроссShaderLanguage - хуй, еби атрибуты с юниформами сам. Хоть бы трупак Nvidia CG реанимировали, чтоле.
>>149864
Да знаю я эти "фичи" GL, на крестах намаялся с ним. Просто хочу понять, как это правильно сделать в Расте. GL только как подопытный кролик, выбран именно потому, что там указатель на указателе, отлов всяких ошибок и т.д. Чтобы лучше понять растовые сырые указатели, короче.
Да знаю я эти "фичи" GL, на крестах намаялся с ним. Просто хочу понять, как это правильно сделать в Расте. GL только как подопытный кролик, выбран именно потому, что там указатель на указателе, отлов всяких ошибок и т.д. Чтобы лучше понять растовые сырые указатели, короче.
>>149857
Алсо, с тем же успехом можешь glFnish() на каждый вызов любой функции OpenGL дергать, на экране будет ~3-4fps, но иначе никакой безопасности ты не получишь.
>Безопасную в растовом смысле. Типа если что полетит, то точно в unsafe.
Алсо, с тем же успехом можешь glFnish() на каждый вызов любой функции OpenGL дергать, на экране будет ~3-4fps, но иначе никакой безопасности ты не получишь.
>>149867
В GL в основном не указатели, а БИНДЫ, АЙДИ И БЛЯДСКИЕ МОЛЧАЛИВЫЕ ОШИБКИ.
>Да знаю я эти "фичи" GL, на крестах намаялся с ним. Просто хочу понять, как это правильно сделать в Расте. GL только как подопытный кролик, выбран именно потому, что там указатель на указателе, отлов всяких ошибок и т.д. Чтобы лучше понять растовые сырые указатели, короче.
В GL в основном не указатели, а БИНДЫ, АЙДИ И БЛЯДСКИЕ МОЛЧАЛИВЫЕ ОШИБКИ.
>>149869
Один хрен для Линукса лучше ничего не придумали. Вулкан еще сыроват, как мне кажется, да и адовый он какой-то. А указатели там таки есть, вон в glShaderSource аж двойной на GLchar и указатель на GLvoid
Один хрен для Линукса лучше ничего не придумали. Вулкан еще сыроват, как мне кажется, да и адовый он какой-то. А указатели там таки есть, вон в glShaderSource аж двойной на GLchar и указатель на GLvoid
>>149870
Указатели там все же по своему прямому назначению используются - передача и прием массивов данных и с ними как раз в опенгл проблем нет, не там ты заморачиваешься. А вот со стейт-бейсед парашей и одновременной асинхронностью при этом - вполне себе как раз есть и именно они делают опенгл небезопасным по дефолту. По сути нормальная прослойка безопасности над опенглом - это такой уже почти графический двиг получится.
Указатели там все же по своему прямому назначению используются - передача и прием массивов данных и с ними как раз в опенгл проблем нет, не там ты заморачиваешься. А вот со стейт-бейсед парашей и одновременной асинхронностью при этом - вполне себе как раз есть и именно они делают опенгл небезопасным по дефолту. По сути нормальная прослойка безопасности над опенглом - это такой уже почти графический двиг получится.
>>149879
Это технические вопросы, книжек по ним куча написано и к теме не относится. Вопрос был как передать(абстрагируемся уже от GL) параметры в такую функцию: void func(char ✶✶x, void ✶y), где "y" может быть null, а может и не быть, в Расте, чтобы сырые указатели наружу не торчали?
Это технические вопросы, книжек по ним куча написано и к теме не относится. Вопрос был как передать(абстрагируемся уже от GL) параметры в такую функцию: void func(char ✶✶x, void ✶y), где "y" может быть null, а может и не быть, в Расте, чтобы сырые указатели наружу не торчали?
>>149883
Короче, как для нее такую обертку сделать - fn func(x: тип1, y: тип2) {
unsafe { func(преобразование x в двойной пойнтер на char, преобразование y в пойнтер на void или null) }
}
Короче, как для нее такую обертку сделать - fn func(x: тип1, y: тип2) {
unsafe { func(преобразование x в двойной пойнтер на char, преобразование y в пойнтер на void или null) }
}
>>149883
Как раз указатели - это именно что технические вопросы, а стайт-бейсед параша и асинхронность - овпросы концептуальные.
Как раз указатели - это именно что технические вопросы, а стайт-бейсед параша и асинхронность - овпросы концептуальные.
>>149889
Я сделал Option<&c_void>, т.к. это больше всего похоже на void ✶. None передается как null. Но теперь непонятно, как в Some засунуть вектор/срез/массив. Box пихать оверхед ведь? Короче, так понимаю, без сырых указателей в интерфейсе не обойтись?
Я сделал 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);
>>149901
Как раз только что эту функцию и нашел))) Она, кажись, дает ответ на мой вопрос:
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);
}
}
Как раз только что эту функцию и нашел))) Она, кажись, дает ответ на мой вопрос:
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);
}
}
>>149908
Понятно, конечно, что она копии будет делать для каждого типа, но можно ведь заинлайнить.
Понятно, конечно, что она копии будет делать для каждого типа, но можно ведь заинлайнить.
>>149910
там автор в коментарии сверху пометку зделал, что небезопасно, фиксми.
По нормальному, конечно, безопасный биндинг ты не сделаешь, потому что glVertexAttribPointer сведет все усилия на нет, по прежнему позволяя стрелять в ногу загрузив буфердатой один тип, а в glVertexAttribPointer заявив другой.
там автор в коментарии сверху пометку зделал, что небезопасно, фиксми.
По нормальному, конечно, безопасный биндинг ты не сделаешь, потому что glVertexAttribPointer сведет все усилия на нет, по прежнему позволяя стрелять в ногу загрузив буфердатой один тип, а в glVertexAttribPointer заявив другой.
>>149914
Кстати, автор цитируемого биндинга таки соснул с glVertexAttribPointer, у него там неполная реализация.
Кстати, автор цитируемого биндинга таки соснул с glVertexAttribPointer, у него там неполная реализация.
>>149914
Ну тут уже никуда не деться, на любом языке, нужно в высокоуровневое что-то оборачивать, типа меша.
Ну тут уже никуда не деться, на любом языке, нужно в высокоуровневое что-то оборачивать, типа меша.
>>149924
ну так о том и речь, что безопасные биндинги чтобы API 1к1 сделать не получится, придется писать свои движок рендера/фреймворк и.т.д
На выходе получится что то вроде такого, то бишь уже некий фрейморк-недодвижок:
https://github.com/glium/glium
>Ну тут уже никуда не деться, на любом языке, нужно в высокоуровневое что-то оборачивать, типа меша.
ну так о том и речь, что безопасные биндинги чтобы API 1к1 сделать не получится, придется писать свои движок рендера/фреймворк и.т.д
На выходе получится что то вроде такого, то бишь уже некий фрейморк-недодвижок:
https://github.com/glium/glium
>>149918
Я что-то не вижу причин, почему не написать такую же обобщенную vertex_attrib_pointer
Он, походу, пытался сделать, чтобы в функцию константу неправильную не передали, я так понимаю?
Я что-то не вижу причин, почему не написать такую же обобщенную vertex_attrib_pointer
Он, походу, пытался сделать, чтобы в функцию константу неправильную не передали, я так понимаю?
>>149928
Мы, наверное, как-то по разному безопасность Раста понимаем. Он ведь не может в логическую безопасность. То, что ты разные буфера засунешь вместо одного и того же, разве это проблема Раста, а не твоя? Ведь по правилам Раста эти функции будут безопасными, т.к. он обязан только следить за владением и валидностью переменных.
Мы, наверное, как-то по разному безопасность Раста понимаем. Он ведь не может в логическую безопасность. То, что ты разные буфера засунешь вместо одного и того же, разве это проблема Раста, а не твоя? Ведь по правилам Раста эти функции будут безопасными, т.к. он обязан только следить за владением и валидностью переменных.
>>149930
1) Два вида использования функции - "по-старому", когда в ней задается и формат аттрибутов вершин и их источник, при этом формат и поинтер - два независимых параметра функции и первый задает интерпретацию второго.
"По-новому" - когда в пойнтер передается число, означающее оффсет для прибинженого буфера.
2) Придется вводить в библиотеку новые типы данных и отвечать за их корректность и безопасность:
При этом не сломав пользователю возможность использования собственных уютных типов данных.
3) Array of Struct.
>Я что-то не вижу причин, почему не написать такую же обобщенную 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.
>>149928
И таки функция fn(x: &T) все же безопаснее fn(x: *const T), если она не должна принимать null.
И таки функция fn(x: &T) все же безопаснее fn(x: *const T), если она не должна принимать null.
>>149933
Так по факту он не следит ни за владением ни за валидностью, потому что на связке glBufferData/glVertexAttribPointer вся эта валидность превращается в тыкву. И не разные буфера, а один и тот же, просто заливать я его буду как f32, а вершинный аттрибут настрою как GL_UNSIGNED_INT_10F_11F_11F_REV, потому что в опенгле эти понятия какбы разделены - буфер - этоо просто нетипизированное хранилище байтов с флагами использования, а его интерпретация в типах данных начинается в glVertexAttribPointer (и других функциях, если речь про текстуры и ssbo).
Так по факту он не следит ни за владением ни за валидностью, потому что на связке glBufferData/glVertexAttribPointer вся эта валидность превращается в тыкву. И не разные буфера, а один и тот же, просто заливать я его буду как f32, а вершинный аттрибут настрою как GL_UNSIGNED_INT_10F_11F_11F_REV, потому что в опенгле эти понятия какбы разделены - буфер - этоо просто нетипизированное хранилище байтов с флагами использования, а его интерпретация в типах данных начинается в glVertexAttribPointer (и других функциях, если речь про текстуры и ssbo).
>>149940
Понял, про что ты, но немножко безопасности все равно получить можно - ты не сможешь залить null вместо массива данных буфера.
Понял, про что ты, но немножко безопасности все равно получить можно - ты не сможешь залить null вместо массива данных буфера.
>>149942
Это корректная операция с точки зрения опенгл, если что и ты только что урезал функционал OpenGL и лишил меня возможности создавать пустой буфер.
>Понял, про что ты, но немножко безопасности все равно получить можно - ты не сможешь залить null вместо массива данных буфера.
Это корректная операция с точки зрения опенгл, если что и ты только что урезал функционал OpenGL и лишил меня возможности создавать пустой буфер.
По идее все эти данные уходят в опенгл напрямую из файлов. То есть их не нужно перепаковывать. А значит апи можно сделать таким, чтобы оно принимало просто нетипизированный блоб. Для ручного же формирования сделать либо дополнительную функцию с родным форматом для раста, либо функции-энкодеры, пакующие такие блобы.
>>149944
И вообще, зачем нужен пустой VBO? Может и туплю, но как-то не приходилось иметь дело с таким.
И вообще, зачем нужен пустой VBO? Может и туплю, но как-то не приходилось иметь дело с таким.
>>149955
glBufferData - означает "Создай мне буфер такого то размера в байтах и с таким то типом использования. Если поинтер не нулл - то еще и данные по этому поинтеру побайтно туда скопируй, при повторном вызове - удали старый буфер и создай новый".
Для изменения данных в буфере служат уже glMapBuffer (вот тут, к слову, тоже интересно как на расте выкручиваться) и glBufferSubData.
https://www.khronos.org/opengl/wiki/Buffer_Object#Data_Specification
Я хочу использовать, скажем, формат COLLADA или https://www.khronos.org/gltf/(они вообще текстовые, есличто), а твои байты в тыкву превратятся, если я их на платформу с другой endiannes перенесу.
и получишь тот же самый небезопасный поинтер.
То есть опять все сводится к "недодвижок поверх"
>А пустой массив Раста не будет пустым буфером в GL?
glBufferData - означает "Создай мне буфер такого то размера в байтах и с таким то типом использования. Если поинтер не нулл - то еще и данные по этому поинтеру побайтно туда скопируй, при повторном вызове - удали старый буфер и создай новый".
Для изменения данных в буфере служат уже glMapBuffer (вот тут, к слову, тоже интересно как на расте выкручиваться) и glBufferSubData.
https://www.khronos.org/opengl/wiki/Buffer_Object#Data_Specification
> По идее все эти данные уходят в опенгл напрямую из файлов.
Я хочу использовать, скажем, формат COLLADA или https://www.khronos.org/gltf/(они вообще текстовые, есличто), а твои байты в тыкву превратятся, если я их на платформу с другой endiannes перенесу.
> А значит апи можно сделать таким, чтобы оно принимало просто нетипизированный блоб.
и получишь тот же самый небезопасный поинтер.
> Для ручного же формирования сделать либо дополнительную функцию с родным форматом для раста, либо функции-энкодеры
То есть опять все сводится к "недодвижок поверх"
>>149958
У меня есть система частиц, хочу на компуте шейдерах их пидорасить, например.
>И вообще, зачем нужен пустой VBO?
У меня есть система частиц, хочу на компуте шейдерах их пидорасить, например.
up
>>150026
Ой, ладно, не доебывайся со своей хуйней.
Первый с++ компилятор вообще просто был набором макросов для си компилятора.
Ой, ладно, не доебывайся со своей хуйней.
Первый с++ компилятор вообще просто был набором макросов для си компилятора.
>>150027
Есть более интересные и неочевидные несовместимости, я лишь указал на самую очевидную.
Наглый пиздеж.
Есть более интересные и неочевидные несовместимости, я лишь указал на самую очевидную.
>Первый с++ компилятор вообще просто был набором макросов для си компилятора.
Наглый пиздеж.
>>150051
Оки. Лень думать было как правильно.
Оки. Лень думать было как правильно.
>>150384
UPD
Субъективно, отмороженный стиль ключевых слов и операторов. Фн члн лет и64 пук.
Кстати как насчёт общего стайл гайда как в петоне?
UPD
Субъективно, отмороженный стиль ключевых слов и операторов. Фн члн лет и64 пук.
Кстати как насчёт общего стайл гайда как в петоне?
>>146143
Хуита полная. Скидываю инсаидерскую инфу. Сеча в ЕБУ стоит автосар, да там много кодогенерации, но только чтобы писать задачками изолированными друг от друга, а в окошечках накидиывать и описывать связи. Работы дахуища, начиная от новомодных датчиков. лидаров, камер, систем автопилота и сапорта водител, инфотеймента. Потом в перспективе будем пилить инфроструктру для сапорта автопилота и машины. Типа маячок сообщает, когда ёмобилю заводить мотор на светофоре Работы очень дахуя. Раст - щенок, т.к. требует серьёзной стандартизации и перепиливания огромного пласта уже готовых тулов. Но для некритичной мистемщины и прикладной хуеты вполне-вполне. Подождём 20го стандарта, имхо плюсы быстрее допилят.
Хуита полная. Скидываю инсаидерскую инфу. Сеча в ЕБУ стоит автосар, да там много кодогенерации, но только чтобы писать задачками изолированными друг от друга, а в окошечках накидиывать и описывать связи. Работы дахуища, начиная от новомодных датчиков. лидаров, камер, систем автопилота и сапорта водител, инфотеймента. Потом в перспективе будем пилить инфроструктру для сапорта автопилота и машины. Типа маячок сообщает, когда ёмобилю заводить мотор на светофоре Работы очень дахуя. Раст - щенок, т.к. требует серьёзной стандартизации и перепиливания огромного пласта уже готовых тулов. Но для некритичной мистемщины и прикладной хуеты вполне-вполне. Подождём 20го стандарта, имхо плюсы быстрее допилят.
>>150393
Есть книжка про стайлгайд, еще не дописанная. Есть rustfmt.
Мы хуярим в продакшн, и нам платят.
Есть книжка про стайлгайд, еще не дописанная. Есть rustfmt.
Мы хуярим в продакшн, и нам платят.
Пацаны чё делать? Нубас кароч, с чего начать учить: си или не терять время и сразу rust? Стоит ли учить си и программы на нем делать некоторое время перед тем как освоить rust? Может потребоваться с микроконтроллерами работать. Из языков знаю Питон. Инб4 уже учу CS, алгоритмы, архитектуру эвм, и другие важные темы.
>>153200
Легче будет понять только unsafe Rust. А так, для понимания Rust куда более пригодны знания Haskell, нежели C.
Легче будет понять только unsafe Rust. А так, для понимания Rust куда более пригодны знания Haskell, нежели C.
>>153330
А, понятно, спасибо.
А, понятно, спасибо.
>>153330
С микроконтроллерами на раст как обстоят дела?
С микроконтроллерами на раст как обстоят дела?
>>153200
Ты ошибся разделом.
Если ты не знаешь си, то тебе тут вообще нечего делать, скажем прямо.
>>153330
Для понимания Rust знания х-ля если не бесполезны, то как минимум совершенно опциональны. А вот без стандартной базы этот ребенок просто потеряется. Об этом, кстати, написано в самом растбуке:
>времени на изучение хочется сэкономить.
Ты ошибся разделом.
>Думаю зная си легче будет понять rust
Если ты не знаешь си, то тебе тут вообще нечего делать, скажем прямо.
>>153330
>для понимания 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 лет.
-Но в то же время ООП в расте слабее, чем кривое оное в плюсах.
-Про вакансии на расте всё ясно и так.
+/-Высокий порог вхождения.
З.Ы. Сам трогал раст палкой с большого расстояния, поэтому приглашаю анонов писавших что-то хорошее, годное на сабже.
>>153610
Как тебе такой аргумент:
работа на расте = команда профи, которая не боится пробовать новое, а проект достаточно нов, чтобы ты смог превратить егов легаси.
работа на крестах = бородатое говно с птушниками, уровня "С++ за 21 день".
Как тебе такой аргумент:
работа на расте = команда профи, которая не боится пробовать новое, а проект достаточно нов, чтобы ты смог превратить егов легаси.
работа на крестах = бородатое говно с птушниками, уровня "С++ за 21 день".
>>153611
Если говорить именно о работе, то вероятность найти вакансию на расте +-нуль.тем более в рашке
Плюсы же постепенно сдают позиции и случайных людей там всё меньше. Судя по однокурсникам большинство собирается вкатывается либо в джаба тырпрайз, либо в веб клепать формочки.
Ну и ясен хуй я червепидор, который ещё не работал и выёбывается, куда без этого.
>работа на расте = команда профи.
Если говорить именно о работе, то вероятность найти вакансию на расте +-нуль.тем более в рашке
Плюсы же постепенно сдают позиции и случайных людей там всё меньше. Судя по однокурсникам большинство собирается вкатывается либо в джаба тырпрайз, либо в веб клепать формочки.
Ну и ясен хуй я червепидор, который ещё не работал и выёбывается, куда без этого.
>>153617
Ну если ты червь пидор, то конечно ноль, о чем разговор.
Но сам подумай, кто захочет начинать новый проект на крестах? Такое может произойти только в говноконторе с протухшими старперами в начальстве, типа яндекса.
Ну если ты червь пидор, то конечно ноль, о чем разговор.
Но сам подумай, кто захочет начинать новый проект на крестах? Такое может произойти только в говноконторе с протухшими старперами в начальстве, типа яндекса.
>>153593
Спасибо, анон, теперь однозначно буду учить си.
Спасибо, анон, теперь однозначно буду учить си.
118 Кб, 640x640>>153633
Пикрил.
Но вообще - рад за тебя, анончик, ты тут наверное самый успешный :3
>общелисп
>хипстота
Пикрил.
Но вообще - рад за тебя, анончик, ты тут наверное самый успешный :3
>>153610
В Русте другая система типов, куда более мощная и выразительная, которая к тому же куда лучше подходит для каждой буквы в SOLID.
>Но в то же время ООП в расте слабее, чем кривое оное в плюсах.
В Русте другая система типов, куда более мощная и выразительная, которая к тому же куда лучше подходит для каждой буквы в SOLID.
>>153639
Занятно. Банковская сфера это по идее ехала база данных по базе данных. Не проще купить оракле и забыть все проблемы? Что именно нужно разрабатывать на расте?
Занятно. Банковская сфера это по идее ехала база данных по базе данных. Не проще купить оракле и забыть все проблемы? Что именно нужно разрабатывать на расте?
>>153649
Хер знает. Жду пока бумажки местное министерство гастарбайтеров оформит. Безопасники запрещают рассказывать всякое.
Хер знает. Жду пока бумажки местное министерство гастарбайтеров оформит. Безопасники запрещают рассказывать всякое.
>>153648
В курсе. Но я про дефолтное ООП говорил, которое de facto доминирующая парадигма, а не ваши новомодные трейты хуеты, владение и move семантику.
В курсе. Но я про дефолтное ООП говорил, которое de facto доминирующая парадигма, а не ваши новомодные трейты хуеты, владение и move семантику.
>>153654
Топовый аргументов почему ретроград сопротивляется применению нового. Причём я такое где только не слышал, даже при переходе с питона 2 на 3.
>de facto доминирующая парадигма
Топовый аргументов почему ретроград сопротивляется применению нового. Причём я такое где только не слышал, даже при переходе с питона 2 на 3.
>>153656
Против всего старого, за всё новое.
Но большинство не лисповоды 500ка/нсек с эмиграцией в Норвегию, поэтому рассуждаю с позиции среднепрограмера который знает только ООП основанное на классах.
Против всего старого, за всё новое.
Но большинство не лисповоды 500ка/нсек с эмиграцией в Норвегию, поэтому рассуждаю с позиции среднепрограмера который знает только ООП основанное на классах.
На сколько сложно мне будет, если я типикал джуниор-фронтенд-петушок? Цель: есть идея одного десктоп софта с некоторой частью на бэке.
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 25 апреля 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Вы видите копию треда, сохраненную 25 апреля 2018 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.