Язык, который существует уже не один год. Язык, который заинтересовал меня из-за скорости выполнения, кроссплатформа, безопасности и возможности делать вещи как в высокоуровневых языках (ООП, мощные макросы, даже не знаю, как сказать). И вот у меня к вам вопрос: как думаете, он сможет вытеснить жаву? Почему?Также открываем здесь его обсуждение, с возможностью отвечать на ответы.
>>956909 (OP)Что можно сделать на расте чего нельзя на С?
Эмм, а с какого-такого он должен вытеснить Яву ?
>>956915А нахуй она нужна? Создавать яву было плохой идеейю
>>956916Два чаю, надо было продвигать Smalltalk.
>>956916Слишком толсто
>>956909 (OP)D - пизже.
>>956912Писать без сегфолтов например
>>956915Наверное, только потому, что мне идеология компиляции нравится больше, чем какая-то виртуальная машина, хоть она в конечном счете имеет нехилую оптимизацию. LLVM уже не мало так платформ покрыл. Еще, жава много памяти ест, если сравнить с аналогичной программой на C/C++/Rust/томуподобное
>>956909 (OP)>язык без наследования>сможет ли вытеснить жаву
>>956941А чем наследование на столько важно? Где например оно очень нужно?
>>956946Везде кроме laba1.exe
>>956954Посмотрите на этого эксперта сделавшего laba10.exeВ реальности от наследования больше проблем чем пользы.
>>956916Слишком много заебств в расте с видами указателей и механизмом владения. На джаве писать намного проще и как следствие намного легче найти людей, которые её знают. Там где используется джава производительность всех устраивает и получаем, что раст нахуй там не нужен. Проблемы создает, а бонусы преподносит слишком маленькие. Нет, я очень рад этому языку. Наконец-то появилась альтернатива мерзким плюсам, но вот только с ними он и может конкурировать. Более высокоуровневые языки он не потеснит никогда.
>>956932На Сишечке тоже можно писать без них
>>956969В Си надо быть крайне внимательным, работая с памятью, указателями и т.п. Так и стараются. Тем не менее, человеческий фактор всегда допускал там ошибки. Здесь (в расте) ты либо будешь послан нахуй компилятором, либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
>>956962В реальности люди комбинируют несколько подходов исходя из задачи.
>>956967А если через пару годиков под раст будет множество либ под любые нужды? Примерно как сейчас в жаве... В конце концов, там свои фичи, тут свои и время изучения не сильно разное
>>956978>А если через пару годиков под раст будет множество либ под любые нужды?
bamp
>>956969Многа букаф получится.
>>957064Как будто в пидарасте от кривого кода программа нормально работать будет.
>>956946ООП местячковый мем в снг.
Наследование - ничто, миксины - всё.
>>957076Меньше кода - легче рефакторить.
>>956976> либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоковИ чем это лучше сегфолта? Исключения хоть можно обрабатывать?
На самом деле рыночку действительно нужен инструмент который позволит создавать кросплатформенные решения с низким оверхедом по производительности/памяти и без сборщика мусора, но на котором смогут писать миллионы лемингов за дёшево.Что нового предлагает Rust, для решения этих проблем?Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?Без этих метрик нет смысла что-то обсуждать?Я уверен, что раст тоже найдёт свою нишу, но однозначно это будет на Ынтерпрайз или web бэкэнд. Возмно, системщина и узкопрофильная прикладуха,возможно ембед, но не ололо контроллеры, а линукс борды. Но для эмбеда нужна спрос и поддержка корпораций, что врядли
>>957136>fix>не ентерпрайз и не web back-end
>>957136>Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?Реальные тесты производительности? Ну это уже по каждой конкретной задаче. Вот тут видим, что на бенчмарках( не отображают реальный мир), раст выигрывает c++ в 6/9 тестов https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp. Не забывай, что для раста не написано много ключевых оптимизаций, что есть у крестов, но вот растовская система типов позволит в будущем реализовать более агрессивные оптимизации, которые не возможны на c/c++, да и с каждым обновлением LLVM раст становится всё лучше.>сравнения сложности разработки,Таких точно нет, всё же на расте никто не пишет, лол. Позволю себе с дивана предположить, что раст в этом лучше т.к. большинство ошибок с++, которые приходится постоянно дебажить, находятся в расте на этапе компиляции. Возможно, если ты йоба-сеньйор с 20+ годами опыта плюсов, то ты не заметишь разницы в скорости разработки, но вот во всех остальных случаях, полагаю, раст сделает c/c++
>>957174На расте операционную систему написали.
>>956909 (OP)>кроссплатформаКомпилятор не поддерживает Windows XP (хотя вроде может исполняться, но с какими-то ключами), хотя поддержка "Embedded Industry" (в ваших банкоматах и прочих) есть до 2019 года.>скорости выполненияАнон кидал ссылки на веб-серверы, крайне там что-то все уныло.Мне интересно, в такой модели памяти - память в долгоживущем приложение не будет фрагментироваться?>вытеснить жаву? Почему?Нет. Тут даже Го не смог. Джава это сформировавшиеся индустрия, ее даже засахаренные скала и котлины потеснить не могут, хотя те на jvm.
>>956967Помоему, они сделали язык сложнее чем С++
>>956912На С в теории можно все, не зря же в нее компилятся большинство скриптовых языков. Другое дело что создать что-то большее чем драйвер на одном только С врятли получится, а даже если и получится то поддерживать это будет пиздецово. А в расте главная фишка что он безопасен и он строг к синтаксису - т.е. у всех будет более менее одинаковый код и при том гарантированно безопасный, что поможет избежать обсеров как с OpenSSL, когда выяснилось что весь мир годами пользовался дырявым софтом.
>>957260Сложнее C++ в принципе сложно сделать. В язык накидали фич не для решения конкретных проблем, а выбрали их рандомно, что вылилось в плохой дизайн языка.
>>956941Там есть множественное наследование поведения — не реализации. То есть интерфейсов — не классов.
>>957136>Что нового предлагает Rust, для решения этих проблем?Ну уж точно не "миллионы леммингов и дешево". Rust сложнее С++, там как раз фишка в том, что сложность разменивается на стабильность.
>>956932пример притянут за яйца. любой школьник знает, что эта строка лежит в read-only секции. да и компилятор будет ругаться на каст сonst char к charкороче иди нахуй. сажи треду
>>957310два чая
>>957310>а выбрали их рандомноНе рандомно. Каждое решение там вполне осознанное и обдуманное. Другое дело, что их вообще не надо было принимать. Или делать минималистичную сишку с классами или пилить новый язык.
>>957510Так сделали десятки ебанатов, но взлетел почему-то С++. А теперь поучи датчанина делать языки.
>>957522>взлетел >почему-то
>>957194Proof?
>>957548http://redox-os.org
>>957551Мда очередная UNIX-like говнина, сколько их можно пилить...
>>957544Винда написана на си, ебанутый.
>>957553А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.>>957578Это к тому было, что и палка раз в год стреляет.
>>957553Да блять просто очередная перделка на гихабе, как laba.exe студентов.А преподносят как готовый продукт.Насколько я знаю, они его переписывают потому, что архитектура стала не поддерживаемая (казалось бы причем тут гибкость раст).
>>957522>но взлетел почему-то С++Популярность продукта ни разу не гарантирует его высокое качество.
>>956909 (OP)Дрявая хуета с утечками как и С++https://github.com/redox-os/redox/issues/855
>>957585>А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.Да дохуя на самом деле, но к сегодняшнему дню это всё либо осталось в музеях, либо пилится на коленке каким-нибудь Куртисом Ярвином или Терри Дэвисом. Хотя впрочем IBM всё ещё поддерживает z/OS.
>>957610GNU/Linux идеальная ОСь, BSD годная альтернатива. Остальное просто ненужно.
>>957611>Остальное просто ненужно. Нужно, просто ты об этом не знаешь: http://www.loper-os.org/?p=284
>>957610>но к сегодняшнему дню это всё либо осталось в музеяхПотому что надо дрова из ОС выкинуть нахуй. Пусть железячники все хардварно реализуют с простым интерфейсом. Все равно и так блобы везде. Так пусть тот блоб на железе крутиться с простым стандартным интерфейсом наружу. Тогда можно будет для кучи устройств использовать один драйвер по спецификации.
>>957611>Windows идеальная ОСь, macOS годная альтернатива. Остальное просто ненужно.
>>957621Годная идея. PostScript в принтерах был шагом в правильном направлении.
>>957616зачем нужен виндоус у которого нет экосистемы? На котором до сих пор мертвым грузом лежит дохуя (50%) легаси? Единственное за что их можно уважать за то что форсят переход на новые железки.Видео драйвер интела из-за легаси пидарастии раздут с 1 мб до 200, в 200 раз больше необходимого, пиздец.МакОСь хоть и для пидарасов, но сбалансирована, имеет нормальную щель, работает без бсодов.
>>957602Популярность С++ гарантирует, что с твоим подходом что-то не то. И довольно банальное - обратно-совместимое решение победило. Из тех времен живо 3 языка, это С, С++ и Objective C. Угадай, почему.
>>957621>блобы вездеНе везде>простой интерфейсОни его и сделали, можешь в обход всех либ юзать.
>>957628легаси и есть экосистема, тупой ты уебоки да, это оскорблениеиди нахуй заодно
>>957647>легаси и есть экосистема, тупой ты уебок>и да, это оскорблениеВ голос с дауна.Экосистема это когда в системе не дублируется одно и то-же и четко разделено что за что отвечает.Виндовс 20 лет не чистилось от говна, вместо того чтобы это сделать добавляют %фичи% и велосипеды чтобы они работали.Одинаковые названия программ, драйвера по 300 метров для звуковух и видео, три встроеных браузера и двое меню настроек на покушать.
>>957657Ты бредишь, Митя. Экосистема - это экологическая система, почитай, что такое экология. Это когда куча животных, едят друг друга и срут, но система при этом стабильна, потому что все в балансе.
>>957660> друга и срут, но система при этом стабильна, потому что все в балансе.А шиндовс не стабильна и не нужна согласно http://www.loper-os.org/?p=284шиндовс обсирается на первом же правиле, так что хватит за них топить Пыня.
>>957631Популярность продукта в массах — это показатель только его доступности для широкой аудитории.Это как сравнить айфоны с кучей говна на андроиде — первые по статистике занимают всего-то 10-15% рынка. Только вот незадача, из этих 85-90% только треть превышают отметку в 200$, а отметку в 500$ ещё треть от этой трети.Вот и думай почему говно для тупорылых макак вроде го, пхп (и 1с в странах снг) стреляет. То же и с плюсами — худобедно любой дебил осиливает хэловорд, падающий через раз с сегфолтом — зато осилил жи!
>>957684Ты сам довольно тупорылый, если мобильные ос в принципе занимают какое-то место в твоей голове. А языка лучше С++ в своей нише объективно нет. Вообще. Никак. Ни разу. Поэтому умнейшие люди планеты пишут свои продукты на нем, с нуля и до сих пор.
>>957770Ты домен какаой-та толе на плюсах писали раньше потому что небыли альтернативы. От слова совсем. Либо Ява, либо говно вроде D со сборщиком.
>>957792ДЦП
>>957609Они получается unsafe юзали?
>>957819>unsafe юзалиПиздец.
Есть у кого-нибудь опыт использования Rust в production? Часто занимаюсь "узкими" местами в веб приложениях, сейчас все на плюсах, но давно посматриваю в сторону Rust, хотелось бы узнать о опыте использования в реальных проектах?
>>957873Что ты там увидеть ожидаешь-то? Плюсовикам (как и вообще всем, кто не занимался каким нибудь хачкеллем, в котором компилятор так же ебет за попытки сделать хуйню) переучиваться очень больно. Иде уровня студии нет, но хуитка для редакторов с нормальным (не уровня тегов из вима и прочей еле работающей хуйни) автокомплитом и подсветкой ошибок из компилятора есть, хотя и альфа, которая собирается только через три анальных кольца. Можешь почитать истории от челиков из дропбокса - https://www.reddit.com/r/rust/comments/4adabk/the_epic_story_of_dropboxs_exodus_from_the_amazon/
>>957873>productionТо есть все остальное ты написал по-русски, а это слово перевести не смог?
>>957886продакшен.
>>957136>оверхедом по производительности/памяти и без сборщика мусора, но на котором смогут писать миллионы лемингов за дёшевоGo, у них даже символ языка похож на лемминга.>>957308Как же тогда оставлять закладки для спец служб?
>>957839Я к тому откуда могут быть утечки, если это раст. Значит unsafe. Хотя я помню что в каких то версиях раста все таки могли происходить утечки даже без ансейфа, когда паника запускалась другой в панике, но я посчитал что это прям обосраться какое исключение.
В расте же даже не зависимые типы. Как им пользоваться?
>>958080>даже не зависимые типыА что нужно, чтобы запилить в расте зависимые типы?
>>958080Хотя подожди. Проверка типов в языке с зависимыми типами может быть неразрешимой. Тогда нахуя оно надо?А вот типы высшего порядка (да-да, те самые родненькие аппликативные функторы, стрелки и монады) были бы полезнее. Я правильно понимаю, что их можно эмулировать трейтами с ассоциированными типами?
>>958050Да, утечки есть, но я про то что ты как дауненок написал.>unsafe юзалиКто так пишет? Это пиздец просто.
>>957112Там нет исключений, но есть особая система типов. Т.е. функция всегда что-то возвращает. Но это может быть что-то (Some), а может быть ничто (None). Или например может быть некий результат или некая ошибка, что уже как бы является аналогом исключения
>>958149А как надо было?
>>958210На С надо писать а не выебыватся.
>>958273У АНБ и без твоего корявого сишного говна забитого 0-day cve хватает.
>>958329Правильно писать NSA.Ты еще скажи что у раста уязвимостей нет, только что говорили что нет утечек, теперь это.
>>958335Если код пишет не си-обезьяна на ансейфах — то ни одной сишной точно не будет. Ты кстати забыл главный опус растотредов — memory leaks is memory safe, пидар.
>>958335Если руки кривые то ты утечку и в языке с GC сможешь сделать. От утечек тебя ни один язык полностью не убережет, так что думать головой все равно придется. Зато память в расте безопасная, без уязвимостей.
>>957819А как по-твоему писать ОСь, которая должна взаимодействовать с железом без unsafe'ов?
>>956921Smalltalk тоже использует виртуальную машину, школота.
>>958607Я знаю, первокурсник. Это не меняет того, что я написал.
>>958602Например, так же, как в некоторых ОС давно зделоли. А именно, написан препроцессор для Сишки, который на каждом шаге проверяет, не собрался ли драйвер поделить, скажем, на ноль.У драйвера своя область стека, все данные он видит только на чтение.Собрался поделить на ноль - ну тогда значит KernExitThread(-1) и едем дальше.
>>958683Я в работе современных (да и старых) ОСей не шарю, но на днях читал про прерывания. Что например если была попытка поделить на ноль, что будет вызвано такое-то прерывание. Где-то в памяти есть таблица (с адресами функций?), которые должны обрабатывать подобные случаи. И не всегда же надо тупо выходить. По крайней мере, родительский процесс должен знать, за что убили ребенка
>>958680Второкурсник ворвался в тред.
>>958694Да, это для обыкновенных процессов.А в ядре ОС возникнет неисправимая ошибка во время выполнения, синий экранчик, у продвинутых чёрный.Но в общем, не забивай себе этим голову, в роиссе на эти знания (очень ценные, ахаха) спроса всё равно нет.
Будущее за языками с HoTT.
>>960575С чем?
>>960918С гомотопиями.
>>960919Звучит неприлично.
>>956915он и не должен вытеснить джаву. это конкурент плюсам, алё
>>961111> это конкурент плюсамЖава с плюсами местами конкуренты.
Очередной долбоёбский тред где эксперты уровня laba2 спорят обо всём, до чего дотянутся.
>>960575Ты таких много знаешь?
>>961320Есть в виде модулей к не очень популярным языкам. Я же говорю будущее, а не настоящее.
>>960575Лет через 10 так, причём в совсем другом виде, а не то говно сейчас. Посмотри на циклон и раст - такая же разница.
Посоны, а где писать программы на русте?Там IDe кокая? Есть?
>>963997Emacs самая лучшая IDE для любого языка.
>>958680Ну и к чему тогда твой вскукарек, различия жабы и смоллтока незначительны. Во втором только рефлексия продвинутей.
>>963997JetBrains + Rust pluginVisual Studio Code + Rust plugin
>>956909 (OP)Друзья, я пытаюсь разобраться в возможностях языка.Конкретно интересует асинхронное программирование, наткнулся на какие-то фьючеры, но они реализованы отдельной библиотекой, это как может вообще работать?Ну в смысле, вот есть либа для общения с SQL сервером, но она же ничего про либу с фьючерами не знает, и как тогда это общение в код с фьючерами инкорпорировать?
>>964028> она же ничего про либу с фьючерами не знаетЗнает.
>>964028>и как тогда это общение в код с фьючерами инкорпорировать?Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
>>964219>Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.А это законно вообще?
>>964409В манямирке
Если раст пилят как более безопасную замену C++, значит в нем не должно быть проблем при написании гуишного софта?
>>964473На расте нет никаких проблем с гуи, т.к. нет гуи
>>964473>2к17>геиНовые гуевины шлепают только на мобилках со своими хост-языками, а десктопное легаси и без того вроде работает (хотя тот же гном вроде как по кусочкам, как и новый движок лисы переписывают на растяпу? но это неточно).
>>964536>геиМмм, а мой автокомплит в курсе трендов этого года.Гуи, конечно жи.
>>964536>растяпу?Это тоже интересный автокомплит, лол.
>>964473Есть разные биндинги под существующие либыНапример, https://www.youtube.com/watch?v=hLR8R0Zl0yY
>>964464>В манямирке Значит на попытке написать scgi приложение я сосну?Вроде tokio позволяет оче просто писать асинхронный сервер.
>>964586Я вообще мимо проходил(из го треда), сорян, помочь не могу.
>>957136Существуютhttps://www.techempower.com/benchmarks/#section=data-r13&hw=ph&test=plaintext&l=3vu6m7
>>965801Раст чуть быстрее джанги на питоне
>>965801И обрати внимание что многие с ошибками сыпяться (очень стабильный язык)
>>965804>>965807Полгода для раста это много. Сейчас как-то так.https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
>>965824Они допилили асинхронный сервер (он полноценный или какая-то заглушка еще)?
https://twitter.com/chasinglogic/status/850115493923086336
bump
Поясните за racer. Хуй с ним он не может в макросы. Но какого хуя он даже обычные крейты не может нормально обработать?Взял kiss3d и рейсеру вообще похуй. Он ничего не дополняет.
>>971901RLS натяни, работает через тот же рейсер, только с ошибками из компилятора на лету и анализирует крейты.Плагин для intellij кстати, уже даже с макросами работает — криво и косо, но навигирует уже около них (в дислокации +- 10-20 строк, лул).
Апну скрином с пруфцом работы RLS, кстати.
>>956909 (OP)>Rust Не взлетит.>>957136>без сборщика мусора>миллионы макакПоследнее не подрузамевает мозг, а равно ручной гарбейжинг, а значит без певрого не возможно второе.
>>972199>Не взлетит.Покаместь что взлетает.Не так сильно как хотелось бы конечно.
>>972199>а равно ручной гарбейжингНе так, габейджинг вообще не потребуется, потому что код будет написан безопасно либо не скомпилится.
>>972252>либо не скомпилится.this. Так что без автосборщика мусора никуда.>>972205Ну и дохуя тырпрайза перекатилось на него?
Че там с книжками? Кроме официальной сухой доки есть еще что-нибудь?
>>972282>this. Так что без автосборщика мусора никуда.Ну так прочитай книжку и пойми как надо делать что бы компилилось.
>>972282> дохуяА это сколько в цифрах?
Вообще конечно расту нужны нормальные средства разработки. И вроде как они активно пилятся. Подождем, посмотрим, потому что сейчас, все что связано с растом находится в "earliest alpha stage of development".
Так и живем.
бамп
>>972314> нормальные средства разработкиавтокомплит и навигация в emacs уже давно работает
>>972314Питушок, ты что-то упкстил?>>971909
>>972282>Ну и дохуя тырпрайза перекатилось на него?А нахуя на расте json в xml перегонять, если для таких задач есть ява?>>972284Rust by example, rustonomicon, rust essentials.
>>972282>Ну и дохуя тырпрайза перекатилось на него?Ну как бы Rust не позиционируется как замена для джавы.Хотя, мне кажется это возможно, если создать правильные годные абстракции.Раст нужен там, где нужно создать хороший годный код который создаст хороший годный бинарник, который будет хорошо годно выполнятся.Тнз тырпрайз, заточен под создание проектов максимальной сложности путем задействования минимально квалифицированных трудовых ресурсов.Совсем другая область.
>>972459Мне кажется раст будет ультрагоден для создания осей и низкоуровенего софта, т.е. там, где сейчас С и С++.
>>972464Уже же какую-то ось на расте запилили
>>972485Несколько.
>>972499>НесколькоЧто-то кроме редокс есть?
Да похуй на эти ваши ос. Лучше расскажите, кто-нибудь щупал аметист?
>>972558https://github.com/flosse/rust-os-comparison>>972563А ПИСТОН чем не устраивает?
>>972568Пистон это набор либ, а не движок. Если верить описанию с https://github.com/amethyst/amethyst/wiki/Other-Game-Engines-in-Rust
>>972485Но оно говно пока что. Что-то годное сделают когда раст станет массовым.
Как же он пиздецки медлено компилится.
>>972679Быстрее плюсов.Хотя ирл однохуйственно перекомпиливается только 1 модуль, и на минимальной конфигурации мбп 2016 весь цикл компиляции-тестов проходит быстро, если ты не меняешь весь проект и зависимости вместе взятые за раз. И в отличие от го с быстрой компиляцией, тут при отсутствии ансейфа дебаггер действительно нинужин.
>>972725Дебагер не нужен? Быстрая конпеляция не нужна? Ты всю хуйню пишешь без ошибок с первого раза?
>>972728Ты даун который мой пост не прочитал.Но да, с его системой типов и статическим анализом он в своём каноническом юзкейсе рили не нужен. Разве что с пошаговой поддержкой IDE для изучения чужого кода прикольно было бы.
>>972731Даун тут только ты, если думаешь что система типов спасает от ошибок.
>>972485>>972499А как можно пилить ось на языке с кучей экстерн депендов?
>>972731http://paste.org.ru/?57pxj7Как быть если случится примерно такая история? Как раст меня от этого защищает?
>>972725Да и в го дебаггер особо не нужен, во всяком случае мало кто им пользуется ибо его нет
>>972739В го дебагер не нужен потому что 1) Быстрее въебать принт и переконпелить2) Если ты поймаешь панику ты получишь четкий стектрейс
>>972737Не стрелять себе в ногу специально. А так в нём есть специальная деректива компилятора, ограничивающая рекурсию, если ты настолько больной.>>972733А ты походу считаешь что система типов это "инты, поинтеры и структуры".
>>972740В расте он не нужен потому что:а) Если не пытаться руками завалить код — он не разыминует висячий указатель/нульпоинтер/итд.б) Стектрейс в дебаг-билде в любом языке избыточен, вась.
>>972741По твоему кто-то специально стреляет себе в ногу? Нет, блять, это говно всплывает в проде когда ты этого меньше всего ожидаешь. Система типов никогда в жизни не научит тебя не совершать ошибок, которые вызовут у твоих клиентов жопную боль. Может ты и не сможешь поделить попугаев на тараканов, но вот вместо одного бесплатного попугая выдать чуть более 9000 - легко.
>>972743Кукаретик, еще раз тебе повторяю, что 99% ошибок это ошибки бизнес логики, а не разыменования указателей.
>>972746В высокоуровенных языках вроде явы, где их и нет. А так, открой свежий список CVE, посмотри как там дела с 1%.
>>972744Она поможет мне ковыряться в говне из байтов без стрельбы в анал и гонок данных. Давай заводи демагогию по новой.
>>972736Ты о чём?
>>972459>если создать правильные годные абстракцииА вот тут, кстати, у меня вопрос возник. Где почитать именно про приемы проектирования на Rust - с примерами неудачных решений, разбором полетов и т.д. По классическому ООП такой литературы завались, а тут куда копать? Ну или хотя бы исходники какого-нибудь годного проекта средней сложности посоветуйте.
>>972679cargo check
>>972833>Где почитать именно про приемы проектирования на RustПредположу, что скорее всего нигде, кроме исходников чужих проектов. Советую сначала погуглить, а если найдешь- вбросить сюда.
>>972849>>972833https://github.com/rust-unofficial/patternsОт авторов знаменитой "learn rust by writing too many lists". Хотя там большинство контента всё ещё только TODO без описания (:Проекты смотри где нибудь на https://github.com/kud1ing/awesome-rustГде-то кстати видел компилятор хаскеля на расте, тоже можешь глянуть, лул.А вообще, вся кор-тима раста работает над серво, и половина над токио — посмотри на них если хочешь кода из первых рук.
>>9724641)Примеры ымбыдеда на вашем расте есть?2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
>>9740651) Гугол открой;2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты. Сравни на том же реддите активность доски раста с досками плюсов и си вместе взятыми.
>>974726>2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты.А не тот ли это шизик, что срет в го треде?
>>974730Это ты у него узнавай.
>>972856>компилятор хаскеля на растенихуя ж себеlanguage-rust на хаскеле помню, а такого не видел
>>975583https://github.com/Marwes/haskell-compiler
>>974065>тред, который мертвее треда полувекового СПатамушто с неадекватами неохота разговаривать, норм чуваки все в гиттере да ирц пасутся
Оправдывайтесь почему нужно писать println! вместо println
>>976237Потому что в языке нету поддержки varargs, очевидно.
>>976239Надо было делать print << lnПрисутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
>>976245>print << ln
>>976245>Надо было делать print << lnИди нахуй за этим ублюдским говном в плюсы. Я реально рад, что сделали человеческое printf-like форматирование.>Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказываетсяТак это и не окамл, дружок. Тут восклицательный знак (тем более справа от идентификатора, хз с чего ты про мутабельность рот открыл — мутабельно передать что-то можно только явно с mut) означает макрос, местный синтаксис разыменования указателей от си был унаследован, если ты не заметил.
>>976237Зачем оправдываться? Тут два стула - либо используй макросы, либо зависимые типы. Причем раст, похоже, будет видеть на обоих.Ладно-ладно, есть третий стул - разбирать строку формата в рантайме и обрабатывать ошибку. Но для этого есть runtime-fmt
>>976259>сидеть
>>976259Я раньше думал, что вывод имеет отношения к монадам, а тут вон че. Поясни, пожалуйста.
Всё правильно сделал? Как-то печально это всё
>>976317Надо было просто println!("14");
>>976318Но я хочу чтобы было AbstractSingletonProxyFactoryBean чтобы объединять данные с функциями
>>976317Похоже на go лол
>>974065>2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С? Проблемы /prПотому что абсолютное большинство тредов языкача - это холивары и баттхерты, например есть го тред, но там куча неадеквата.
В общем не вижу никакой разницы с С++ кроме примитивного ооп, конструкции match и опущенных {} (вау), да ещё уебанцкие сокращения ключевых слов и имён в стандартой библиотекеВыглядит как язык от васяна где вся логика построена по желанию его левой пяткиДля деклоративного петушения со статической типизацией лучше взять Haskell, для навороченного синтаксиса Perl 6
>>976345Что-то ты забыл про главное отличие - систему типов Rust. Я и про lifetimes/borrowing, и про гарантированную на уровне системы типов потокобезопасность (вне unsafe), и про проверку типов в дженериках на этапе их создания а не на этапе инициализации. А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.И да, модули. В 2к17 инклудить хедеры вместо нормального импорта модулей - очень странно если честно. Это по сравнению с прочим мелочь, но всё-таки.
>>976363>А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.Вот только не надо это сложное для понимания уг тащить в Rust.Сейчас это нормальный язык, Haskell к услугам тех, кто желает дрочить на монады/теоркат и теорию типов.
>>976366Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
>>957444>пример притянут за яйца. любой школьник знаетСхрена ли оно компилируется тогда?ЛЮБОЙ ШКОЛЬНИК ЗНАЕТ@РАЗРАБОТЧИКИ КОМПИЛЯТОРА НЕ ЗНАЮТ
>>976388>Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"? Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею. Разумеется, дело может быть во мне, но для себя я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust. Для таких вещей есть Haskell и незачем засирать другой язык.просто хаскеллисты хуеют от своего рантайма и хотят свои убер-абстракции, которые и сами не понимают, но при этом хотят efficiency раста
>>976345>опущенных {} (вау)Ты сам только что показал что опущен только ты, лол. В расте много где опускаются обычные скобки, но все выражения (кроме однострочных результатов паттерн матчинга) делятся фигурными.>стандартой библиотекеЖеманный, не не пались, не знаешь же. После си и плюсов с atoi(), ftol() ntohl() и друзьями в расте просто AbstractSingletonProxyFactoryBean-ы какие-то>>976388Братан, вот поясни мне за эти функторы — а нахуя? Я мб тупой слишком, но из пояснений в гугле понял столько же, сколько про монады — что это моноид в категории эндофункторов, ахуенно. Сейчас у нас есть что-то между плюсами и сишкой — с композицией и tagget-unions вместо наследования, простым синтаксисом (дада), все очень явно, модули и так далее. Короче, качественный кусок инженерного говна, если цитировать одного йоба-математика. На нем с некоторой сноровкой, конечно могут спокойно писать васяны вроде меня у которых никогда не было пар теорката или они нихуя не понели, в общем-то, примерно 95% программистов на си и плюсах.А еще есть тот же ATS, в котором зависимые типы где-то даже видел коммент в стиле "правильно сделанный раст" и все прочее, на котором с комментария того же йоба-математика скорость написания кода в лучшем случае "400 строк за неделю". Карл, вот что такого дадут эти зависимые типы практичному языку, а не йобе от епонца, у которого в культуре высшее просветление — аутировать смотря на сакуру?
>>976511А мне еще можете пояснить что такое линейные типы.
>>976511Cи делали 100 лет назад, в С++ этого уже нет за редким исключением, писать fn вместо function даже не каждая обоссанная обёртка для JS себе позволит. Можно было использовать define или вообще function x = x раз уж match влепили. Для серьёзного языка с ориентацией на безопасность это абсолютно неприемлимо, даже переменные так называть нельзя.
>>976538двачую, тоже это резануло, есть же нормальные def, func
>>976538>>976539Ебать жеманного бомбонуло.>>976529Дык их и нет в расте, здеся у нас аффинные типы.Линейные типы (по моему скромному пониманию, хз чо там по математической правильности) позволяют использовать объект только из одного места и запрещают копировать на него ссылки. В расте это называется владением.В аффинной типизации есть возможность использовать объект не только из одного места. В сухом остатке, это грубо говоря есть заимствование.
>>976317Вектор объектов, компилитсяПодсветку не настроил ещё
Ёпт, на сколько всего отвечать придётся>>976505>Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею. Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?> я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится RustОпять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.> Для таких вещей есть Haskell и незачем засирать другой языкТут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?>>976511>Братан, вот поясни мне за эти функторы — а нахуя?На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.> Карл, вот что такого дадут эти зависимые типы практичному языкуВозможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
>>976573блять, оно потёрло мои звёздочкитам должно быть в одном месте * -> *в другом: * -> * -> *
>>976555Братан, можно было просто:а) Сделать impl Display for Vec<Box<Yoba>> и всё;б) Использовать дебажную форматировку в println (которая :?).
>>976573>>976575блядь, а это сложнее чем монады ебашитьпробую ещё раз&#42; -> &#42; в одном месте&#42; -> &#42; -> &#42; в другом
>>976573>>976575>>976577так, ладно: https://pastebin.com/DKCvJDP0
>>976573>На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> , то параметра должно быть два, и так далее. Разве это настолько сложно?Ну я вот щас ничего не понял. Ты точно не стебешься? ->, -> -> - это что?>Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.1. ООП все, кто связан с программированием, знают2. В начальном приближении большинство концепций ООП можно объяснить сравнительно просто, можно это как-то постепенно изучать, а, когда на тебя обрушивается ворох стрелок и звездочек, это кажется сложным.Разумеется, сказывается императивный бэкграунд и стереотипы об ФП. Плюс не совсем понятно, а нахуя это нужно, я понимаю конечно, что ты в обратку можешь сказать, что так можно и на голом С или asm писать и вообще отказаться от прогресса, но, повторюсь, зачем эти кайнды нужны я так для себя и не уяснил. Наверное, это красиво, но для меня отдает дрочевом и излишней наукообразностью.>>976588>>976573>>976575>>976577Чет проиграл если честно.
>>976573>Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?Ну если смогут норм внедрить эти кайнды в язык и объяснить так, чтобы понял человек, который на хаскелле только факториалы писал, то я ничего против не имею, возможно это годная вещь действительно.
>>976576>fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {Нихуя себе просто
>>976602> ->, -> -> - это что?Это парсер съел звёздочки. Смотри короче ссылку на pastebin, я не ебу как эти звёздочки вставлять сюда.
>>976602>Плюс не совсем понятно, а нахуя это нужноТе же монады и функторы нормально без кайндов не реализовать. Зачем нужны монады и функторы и попытался вкратце объяснить выше. В общем всё сводится к тому чтобы писать более обобщённый код.
>>976602Ну можно конечно какой-то другой синтаксис придумать, без стрелочек со звёздочками. Стрелочки здесь потому что те самые дженерики которыми мы каждый день пользуемся с точки зрения того же Haskell - функция над типом. Ну то есть когда мы пишем тип вроде List<Int> мы как бы вызваем (в compile-time, разумеется) функцию List с параметром Int.
Я не понял насчёт параллелизма, он что реальные потоки создаёт? А корутины где?В http://rurust.github.io/rust_book_ru полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
>>976821>полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика И что в ней странного?Все так всегда делают.>Я не понял насчёт параллелизма, он что реальные потоки создаёт?Ты что реально слабоумный дебил?>А корутины где?Не завезли, ибо сложно и нужон сложный рантайм.Заместо есть tokio и фьючерзы.
>>976827А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
>>976834>А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать? Асинхронно.Через tokio либу.Но с такими вопросами, лично тебе, никак.Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.Архитектура ПК - ассемблер - си.Да и не для раста то-же нужно.
>>957093Схуяли его меньше?Там выразительность на уровне С++ или хуже.
>>957174Не в 6/9 а в 3/9, при этом сливает Си в 8/9,что какбы говорит нам о качестве кода на плюсах в этих бенчмарках.
>>976827>И что в ней странного?>Все так всегда делают.Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.>>976836>>Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.>Архитектура ПК - ассемблер - си.Сразу видно теоретика.>>976842>Там выразительность на уровне С++Так с++ довольно выразителен, если сравнивать с джавой или го.
>>957308А теперь приведи пруфы того, что Rust делает гарантированно безопасный код.
>>976821Он не слышали про количество ядер прост
>>976851>Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.Любой недурак, знает, что плодить потоков больше чем ядер ЕСТЬ смысл в определенных задачах.И потому проводит тесты производительности в разных конфигурациях.>Сразу видно теоретика.Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.
>>976859>Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.Хотя нет.Оставайся тут пока.
>>957587>А преподносят как готовый продукт.Галоперидону выпей. СРОЧНО!
>>976602>ООП все, кто связан с программированием, знаютСижу на програмаче, следовательно я связан с программированием. я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные), следовательно это твое утверждение ложно.
>>976908Первая посылка ложна, ты не связан с программированием. Ты хлебаешь борщи и участвуешь в срачах.
>>976908Ты как минимум очень ограниченный человек, который имеет ноль интереса к своей профессии. К программированию ты действительно имеешь мало отношения, ибо не имеешь понятия о концепциях, принятых в большинстве современных языков, даже если они чем-то плохи.
>>976908>я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные)То, что ты не писал с ООП подходом, что кстати сомнительно, еще не означает, что ты не знаешь ООП.Тем более, что ты>Сижу на програмачеИ минимум что-то читал тут о ООП.>следовательно это твое утверждение ложноУвы, но твои аргументы инвалид, и логический вывод мягко говоря сломан.Что косвенно свидетельствует о твоей недалекости в целом, и в отношении процедурных\функциональных языков в частности.
>>976931>>976975>>977017)))
Карго превращает каждый проект в локальное хранилище всех существующих либ раста, а в конце обязатльно что-то ломается
>>977055Это издержки любой централизованной иuild системы.Я как вижу эти зеленые надписи про downloading-compiling, так сразу чувство, что сейчас начнется какая-то мясорубка с кишками и кровью, больно это напоминает руби, а я в свое время наебался с последним, когда для запуска одного скрипта нужна тысяча гемов ну или хз сколько и что-то всегда ломается. При этом я был не разработчиком, но конечным пользователем тех скриптов и с того времени руби для меня - ругательство.
>>977090не build системы а системы управления пакетами, сорри тупанул.
>>977055Лучше, конечно, тащить все зависимости в проект и устраивать кровь с кишками с помощью вендоринга, а потом сидеть по 5 лет на старой версии библиотеки, которая течет и работает хромая.
>>977098Карго безальтернативно устанавливается в $HOME/.cargo, так пускай складывает либы в ./cargo/lib как rlib.so.1.2.1, а не компилит для каждого проекта по 200 мб
>>977106Это растц релейтед проблема.
>>977098Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
>>977055https://github.com/AngryLawyer/rust-sdl2Вот это получилось собрать наcargo-0.17.0-nightly (f9e5481 2017-03-03)rustc 1.16.0 (30cf806ef 2017-03-10)Ну хотя бы SDL работает, можно попробовать что-то сложнее факториала сделать
>>977204>Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.>А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться. Стократно плюсую.Жаль, линуксоидам застрявшим во временах 2мб винчестеров, этого не понять.
>>977204>>977211Написал хуйню @ сам себе приплюсовал.В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.Но гоферу не понять.Хотя гау то же делает с своей GOPATH, у явы каждый пакетный менеджер тащит миллиард зависимостей для себя, в дотнете как в расте, а у динамикопитушков вообще каждый проект — своё хранилище зависимостей.
>>977221Растц может зафейлиться если ему подсунут rlib'у с той же версией что надо, но скомпилированную растц недельной давности.
>>977106Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
>>977222Ну, в том же окамле такая же хуйня — но всё сделано в одном хранилище, как предлагает анон выше. Просто попробуй попользоваться такой хуйнёй.
>>977223Эти проблемы вроде решает guix
>>977221>Но гоферу не понять.Это ты себя имеешь ввиду, или что?Речь о rust е идет вообще-то.>В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.Тогда все ок.
>>977223>Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд). А это не норм нефига.Нафуфик оно так сделано?Зависимости должны лежать рядом с конкретным проектом.
У меня вопрос, а можно ли на винде да, да сделать так, чтобы все устанавливалось не в юзерскую директорию, а куда скажешь, например, в c:\rust.
>>977253https://github.com/rust-lang-nursery/rustup.rs/#working-with-custom-toolchains-and-local-buildsНу ещё посмотри первый пункт в разделе про переменные среды.
>>977248Ну так они и лежат.
Какой тип принимает Vec::index?
>>977378Все индексы (массивов, векторов, хуекторов) в насте только в usize.
>>977389>настеВ расте, лул, простите меня, Насти.
>>977260>Ну так они и лежат. И в чем тогда проблема?
>>977416В том что какой-то петушок лезет из своего говно-свинарника с ахуительными советами по архитектуре.
Почему элемент енума в match не компилится без &?Говорит Item::A => 'A',^^^^^^^ expected &Item, found enum `Item` = note: expected type `&Item` found type `Item`
>>977504Наверно потому что &self.world?
>>977420Тебе уже всюду гоферы чудятся, параноик.К врачу сходи.
Так надо структуры в енуме хранить или есть способ покруче?
>>978136Мне вообще вся твоя затея с Enum-ом тут не нравится.Может лучше сделать trait Cell с методом test() и передавать туда разные реализации этих cell?https://doc.rust-lang.org/1.0.0-beta/book/static-and-dynamic-dispatch.html#dynamic-dispatch
>>977204Это одна из проблем хаскеля. Там уже и stackage завезли из-за этого, но выглядит это как снепшоты hackage периодические. Как если бы crates.io снепшотили весь целиком и проекты переезжали с одного снепшота на другой. Без этого вообще ад, сегодня компилируется, а завтра майнтайнер мелколибы сломал совместимость на какой-нибудь FreeBSD и сам не заметил.С cargo есть гарантия, что любой снепшот проекта с какого-нибудь github можно собрать, причем любую его версию, именно с теми библиотеками, с которыми он разрабатывался.cargo это вообще самое лучшее, что есть в расте вообще, и лучший из менеджеров зависимостей.
По поводу того, что зависимости хранятся в каждом проекте отдельно.ИМХО, эту проблему нужно решать по аналогии с ccache. Пусть все остается как есть, но еще будет незаметный для юзера кеш, куда будет все собранное складироваться, если нужно линковаться в местный билд симлинком. Малоиспользуемые библиотеки пусть вычищаются. Если симлинк из-за этого сломался, можно и пересобрать. В Rust же пилят инкрементальную компиляцию, у нее кеш будет не глобальный ли случайно?
>>978213>если бы crates.io снепшотили весь целикомПринцип иммутабельности as is, чтобы что-то добавить, надо удалить и пересоздать. Все правильно.
MUTABLE BORROW@MUTABLE MORE THAN ONCEСколько не читай доки, ничего написать на этом языке не представляется возможным...
>>978789Для больше чем 1 мутабельной ссылки есть синхронизационные примитивы, или ансейф, если ты самый умный.
>>978136>способ покрученеобязательно именовать поля, можно просто Player(PlayerData), доставать данные - как из кортежа (х.0)
>>978789>ничего написать на этом языке не представляется возможнымНа Х-ле есть даже специальный блог пост для тех, кто язык как бы осилил, но вообще не вдупляет как написать приложение. Может и для раста такой завезли, поищи.Хотя самый нормальный совет - читай исходники других проектов.
>>978961Как сделать swap или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
>>978996Не похоже на хорошую практику, даже Pos(i32,i32) с 0,1 вместо x,y как-то стрёмно смотрится
>>979224>Как сделать swapfn swap<T>(a: T, b: T) -> (Pos, Pos) { (b, a) }Использовать так:let (src, dst) = swap(src, dst);Работать будет с чем угодно. Не благодари.>или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?Клонировать и так можно через .clone().А так — просто вынеси self.get() из матча в переменную.Вообще, нужно сделать руководство для нюфагов на картинках — я хз как еще заимствование объяснять.
>>979263>Pos, Pos)Тоже на T заменить "для всего".
>>979263Не отвечай этому уебку пока он код не скинет нормально (энивэй твой свап это пиздос в его случае).
Sup, аноны, решил на расте чего-нибудь пописать. Очередной калькулятор не хочется, можете подкинуть идейку с гитхаба? Не прочь буду и покомиттить в рабочий проект
>What’s in 1.17.0 stable>The story of Rust 1.17.0 is mostly one of small, quality of life improvements. Дебилы блядь. Нет чтобы сразу сделать по нормальному как раньше было, до прихода багзиллы и крестоебов.Глядишь, к 2.0 может и нормальный синтаксис запилят и HKT завезут.
Нет, все же сказочные долбоебы>some unnecessary run-time parsingsome unnecessary run-time parsing блядь срать не снимая свитраSocketAddr and IpAddr have some new conversions as well. Previously, you may have written code like this:"127.0.0.1:3000".parse().unwrap() Now, you can writeSocketAddr::from(([127, 0, 0, 1], 3000)) // or even ([127, 0, 0, 1], 3000).into() This removes some unnecessary run-time parsing, and is roughly as readable, depending on your preferences.
>>981729Что тебя смущает?>>981727До багзиллы и крестов и хкт не было. а синтаксис в любом случае лучше чем в жачкелях
>>981734>лучше чем в жачкеляхniet вкусовщина
>>981738>вкусовщинаНу вот сам себе ответил. Не сделают.Хотя ты всегда можешь сделать язык компилирующийся в раст (или хотя бы бэкэнд к хаскелю).
>>981734Плез, в божественном синтаксис охуенен.
>>981734Ах да, меня смущает эта задротская зацикленность не неважных вещах.>some unnecessary run-time parsingкак будто код только и занимается этим и небо и Аллах и тепловая смерть Вселенной зависят от этой оптимизации, в которой говорится в комментариях к релизу.
>>981748А ты хотел чтобы они тебе каждые 6 недель ахуенные релизы выкатывали? Такой цикл разработки нужен для вылизвания существующего кода.А так там вообще куча всего что давно нужно было исправить — синтаксис инициализации структур, синтаксис констант, в стабильный карго наконец-то внесли фьючи, стэктрейсы помещаются в 1 экран.а с этой новой хуиткой, не тратящей время на парсинг ип, можно писать убер быстрые сканеры диапазонов ип для локалхоста, ну чо ты
Раст когда-нибудь обгонит С?
>>981914Он транслируется в LLVM байткод и обогнать C не может по определению.
>>982031C тоже в него компилится. А в гнутом компилире компилится в их GIMPLE.
>>982031Ходят слухи, что благодаря своей охуенной системе типов Rust теоретически может предоставлять LLVM информацию, которая позволит производить всякие продвинутые оптимизации. Так что с развитием и Rust, и LLVM вполне возможно, что Rust станет в местами быстрее сишечки/крестов.
LLVM - это хайпнутое г и он никогда не будет быстрее гцц или даже Borland C++Может, за счет убер-системы (которая просто хитро переносит часть рантайма на время компиляции) он будет где-то быстрее С или плюсов, но это лишь частные случаи, где-то и Hsakell быстрее С, такие кейсы любят находить фанбои того или иного языка, но общая картина всегда будет такой, что языки более высокого уровня медленнее С/С++.
>>982151> никогда не будет быстрееПочему?
>>982152Потому что высокоуровневость и скорость разработки всегда меняется на скорость выполнения.На пыхе ты можешь за 20 минут что-то высрать даже будучи учеником пятого класса, но скорость будет меньше, чем у правильно написанного кода на С, решающего аналогичную задачу.
>>982155Причем тут пхп? Я думал мы ллвм и гцц сравниваем. И гцц далеко не везде обгоняет ллвм/цланг.> высокоуровневостьЧто-то мешает компилятору высокоуровневого языка высрать такой же машинный код который высирает гцц?
А нахуй нужны эти кланги, ЛЛВМ?Есть гцц, уже довольно давно. Какой смысл в этой херне?
>>982179Для нового языка проще запилить фронт для llvm, чем пилить новый компилятор с нуля
>>982179Подальше от Штульмана.
>>982135Ну он уже местами быстрее судя по базовым тестам.
>>982151Тогда почему кланг уже разъебывает гцц?http://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=1
>>982157Если говорить про php подобные, машинный код можно сделать только если вставить в бинарник интерпретатор целиком
>>982151Ору с тебя. LLVM IR не высокоуровневее чем IR GCC (не помню как там он называется). Вся разница в том что инфраструктура LLVM более современная, универсальная и лишённая некоторых легаси-косяков GCC.Ещё раз, для тупеньких: LLVM IR - не высокоуровневый язык. Изначально вся инфраструктура Clang + LLVM вообще создавалась для компиляции C, и уже потом LLVM стали использовать как бэкенд для других языков.
>>982205>Тогда почему кланг уже разъебывает гцц?Найти пример, где кто-то кого-то разъебывает всегда можно.Например, самый быстрый сервер статических файлов написан вроде на D или Haskell, но это не значит, что в целом эти языки быстрее С (язык с GC в принципе не может быть быстрее языка с ручным управлением памятью).>>982283Высокоуровневый язык - это Rust.LLVM - это просто высер. Для хипстеров штучка, понимаешь? Поигрался, м.б. написал свой компилятор для своей джавы, где вместо слова class будет хуй и тип не перед, а после идентификатора.
Да кстати Rust - это тоже высер для хипстеров, что видно даже по лого. Это для тех, кто хочет почувствовать себя ололо-инжинером, который манипулирует байтиками и управляет памятью через ансейф, но который при этом не осилил C/C++.
>>982343Охуеть, какой - то чухан мало того, что несёт какой-то бред, да еще использует слово "хипстер", как оскорбление. Ты, блядь, и хипстера поди не видел в своём залупинске, а туда же. Аргументации 0 (ноль), компетенции 0 (ноль), а лозунгов и пафоса на серьезных щщах на весь тред хватит.
>>982357А какая тебе нужна аргументация, если весь механизм владения-заимствования - это подпорка для скорбных умом, у которых на языках с ручным управлением памятью будут утечки. Этим товарищам на джаве бы писать, но они хотят ощутить себя системными архитекторами и вот для них придумали эту игрушку.
>>982345Никакой хипстер не осилит раст, это вообще язык не для людей. С++ немного проще из-за мутабельности и слабой типизации, пока не дойдёшь до шаблонов, которые тоже не для людей и никто их не понимает полностью.
>>982362>это вообще язык не для людейЧто в нем сложного?Понял заимствование, смарт-указатели и все.Проще, чем ловить секфолты.> С++ немного проще из-за мутабельностиТак сложно вставить слово mut, да?>слабой типизацииСлабая типизация создает только проблемы.
>>982363>Что в нем сложного?Правила видимости непостижимы, например.
В расте синтаксис ебанутый и отягощенный и совсем не однородный. Да и разве не было языков с линейными типами уже? Чем раст лучше них?
>>982343Но там не один пример, а целая кипа примеров, где гцц сосет. Так что уж просто это скорее тенденция, чем исключение.
>>982360>вот для них придумали эту игрушку. Эта игрушка по скорости ни чем не уступает крестам, но при этом меморисейф, что является ключевой килер фичей.
>>982371Блять, додик, что ты вообще делаешь в программировании? Это тоже самое , что shared, unique и weak указатели.
>>982357Хипстер - это как раз тот, кто с умным видом втыкает в "современные технологии". Примеры говна, которое любит хипстота - это Scala (и обязательно с экстенсивным использованием scalaz), кложа и т.д. При этом ладно бы они действительно что-то в этом понимали, а то большей частью скидывают друг другу статьи на хабре "как функциональное программирование помогло нашей компании".И Rust примерно для таких, кто хочет играться с байтиками, но на сях без секфолтов не может hello world написать.>>982388>Эта игрушка по скорости ни чем не уступает крестамАхахаха.>>982385Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Обычно в таких примерах просто специально оставляют простор для оптимизации и потом говорят, что их (язык, компилятор) быстрее.
>>982360>Динамикодриснявая вебмакака не палится
>>982395>Это тоже самое , что shared, unique и weak указатели. Мы придумали проблему а теперь будем с ней бороться.
>>982424Ты где толстый рантайм у раста увидел-то?
>>982362Ну ты-то явно ни Rust и C++ дальше хелловорода не знаешь. Как будто в Rust нет мутабельности, лол.
>>982360Ох уж это раздутое чсв. Все такие охуенные, код сразу без ошибок пишут. Статическая типизация им не нужна, потому что зачем нам типобезопасность, мы и так код правильный пишем. Система владений-заимствований нам не нужна, потому что зачем нам безопасность работы с памятью, мы и так код правильный пишем. Охуеть просто, иди подойди к зеркалу и подрочи на себя, раз ты такой охуенный кодер.
>>982424>Ахахаха.Так и есть. У тебя врети что ли?>>982424>Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Повторюсь тут в 80% случаев ллвм нагибает гц.
>>982343>и тип не перед, а после идентификатора.Я тебе сейчас секрет открою, но везде так делают потому что:а) Компактнее записывать модификаторы (вместо всяких const out int hui просто var hui);б) Легче и быстрее парить;в) Лаконичнее живёт с выводом типов.Даже в твоём говне так это работает.>>982463>в говнище вообще нет возможности контролировать указатели, нету и проблемы, кококоЖеманный опять трет топит, луль.
>>982495Ага, а потом годами выскребают зеродеи.
>>982498>паритьпарситьох уж эти хипсторские вэйперы
>>982345Дело не в осилил или не осилил C/C++, а в том что работать с Rust тупо приятнее (не говоря уже о том что безопаснее). Это касается как самого языка (клёвая система типов, нормальный match, if/match as expression, модули, гигиенические макросы и т. д.), так и инфраструктуры (нормальный пакетный менеджер, например). Если есть возможность использовать инструмент который использовать приятнее, то что в этом плохого, м?
>>982343LLVM - это охуенно мощная инфраструктура, в разработку которой было положено дохуища человекочасов. И сейчас LLVM гораздо более зрелая и удобная в использовании система, чем GCC. Начиная с того что LLVM легче расширяется и имеет более внятный дизайн и заканчивая тем что у LLVM в принципе есть внятная документация.Скажем если кому-то нужен компилятор той же сишки для кастомного процессора (и это не выдуманная мной задача), то самый адекватный вариант - скачать сорцы LLVM, открыть документацию по написанию бэкендов к LLVM и сесть писать бэкенд. Документация вполне ок, хотя информации конечно меньше чем для написания фронтендов.
>>982509Ты самое главное забыл — LLVM лицензирована MIT, а не ЖоПаеЛью, и Шульман со своими юристами не придёт к тебе если ты решишь продавать и распространять свой софт не открывая исходников.
>>982500ставлю тип после идентификатора, законом не запрещено, парсить на 95% быстрее и легче
>>982512>ШульманШтульман* конешно
>>982514Иди лучше к жавадаунам, они до сих пор пишут AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());Скоро у пайка начнется деменция и в говне настанут такие же темные времена.
>>982517>AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());Охуенно же.
>>982517даже у жавадаунов уже var kek = ..., разве нет?
>>982527Так меньше символов и меньше оплата
>>982527Нет, и в ближайшие 3-4 года до жявы 10 не предвидится.
>>982377Двачую этого.
>>982377Ну был и есть ATS. Официальный саппорт и форум на епонском, доков 0, только примеры факториалов, на языке писать без выдрачивания теорката нереально (он куда сложнее хачкеля, больше похож на теоремпрувер чем на яп) — тайная военная разработка страны восходящего солнца. Теперь как сам думаешь, чем?
>>982517Тебе видать какие-то нехорошие жабисты попались, когда еще маленьким был, вот и осталась фобия хотя если судить по тому что пишешь, тот еще джуниор. Можешь показать на проекте в гитхабе, за какие места тебя трогало?
>>982563Помню помню, этот язык с нескушными идентификаторами вроде viewt@ype и с различным цветовым кодированием разных категорий кода.Даже порывался учить, но по модулю ебанутости автора не дотянул.
>>982424Каночные хипстеры пишут на Ruby и Java(coffe)script в Sublime Text/VIM.
>>982675Каноничные - да, но надо же орать, что не хипстор и что твоя технологие неебаться инжынерная и ты прямо байтики ксоришь и у тебя все на указателях, естественно, умных, а еще иммутабельность и вообще.
>>982675Я скажу больше, у каждого свои представления о каноничных хипстерах. Границы определяемого расширяются с изменением определяющего. Вот у нас в компании, уж настолько настолько хипстерский народ (разной временной градации от протохипстеров с зеркалками до постхипстеров с подворотами итп, а все туда же - нет, да всплывет жалоба на хипстеров. Хоть ультрафильтр заводи.
Не могу понять, как вернуть введенный с клавиатуры код в срез и вернуть его из функции mesinput. Лучший ли это способ вообще - возвращать ввод с клавиатуры в качестве среза, чтобы потом отправить его через tcp? Код пикрелейтед.
>>985871>Этот кодПиздец, я думал раст лучшая замена крестам, а тут та-же ебанная лапша.
>>986142Этой какой-то цпп с синтаксисом раста. С кучей ошибок и, как результат, даже не скомпилируется.
>>986144>>985871Додик, ошибки читай хоть.
>>986286Это новый стиль жеманного, постить код в скриншоте и не реагировать на ответы, выше посмотри. У нас тут вместо треда какая-то игра в мафию, только вместо мафии жеманный, лул.
>>963997>>964005Нахрена вам IDE, долбоёбы? Код пишут с помощью рук и мозга в первую очередь. Если проект насколько запутан, что в нём нельзя ориентироваться без IDE - это говнокод, который надо выкинуть нахуй. Собирать нужно в консоли, текстовых редакторов с подсветкой для раста предостаточно, во многих даже автокомплит и линтинг есть.
>>986603Ебать жеманного прорвало.У говна иде того же качества, что сейчас у раста. а плагин для жидеи кстате лучше гогланда, или как минимум его билда месячной давности
>>986460>и не реагировать на ответыТакие только со своим ЭКСПЕРТНЫМ мнением вкатываются, и с хуями в ротешнике молча выкатываются.>>986603>с помощью рук и мозга Как ты тогда его пишешь, если не обладаешь ни тем ни другим.
>>986607>Уряря толстую жопку порвало
>>986608
>>986609Типа маскот гау 2.0 — сусли-циклоп?Тонка
>>986460Да тут пол-треда, если не больше - "жеманные". Как мимо пройти и не зайти, поглумиться.
rust. sql embedded. sqlite. what?
>>988399Ты долбич?
Кто-нибудь может пояснить за обработку ошибок в Rust? Пытаюсь я к примеру открыть файл:let mut p = File::open("dat.txt");И пытаюсь обработать результат, чтобы при ошибке программа не прекращалась, а началась заново.match p { Ok(pa) => println!("{:?}",pa), Err(_) => main(),}И дальше я пытаюсь открыть файл и прочесть егоlet mut buffer = String::new();p.read_to_string(& mut buffer).expect("No reading");Но компилятор пишет:main.rs:34:10: 34:38 error: no method named `read_to_string` found for type `core::result::Result<std::fs::File, std::io::error::Error>` in the current scopeВопрос: match каким-либо образом преобразует тип переменной p? Если использовать unwrap(), то такой ошибки не возникает. Или я ошибся с самим применением match? В офф. документации, не объяснен доступным языком этот момент.
>>989218Читай файл в успешной ветке матча, и замени p на pa, тебе же компилятор прямо написал.
>>989233match p { Ok(pa) => pa.read_to_string(& mut buffer), Err(_) => main(),}Теперь такая ошибка:main.rs:27:2: 30:3 error: match arms have incompatible types:Насколько я понял match при этом должен возвращать одинаковые по типу значения, но как это сделать, я не знаю.
>>989218https://play.rust-lang.org/?gist=a61a2ab8d483ed120b9ff4bd6298f885&version=stable&backtrace=1
>>989339Спасибо за помощь.
>>989345https://play.rust-lang.org/?gist=78cdf63a1d850b61ea2a5c909547c065&version=stable&backtrace=1 match версия. Ветки match обрабатываются без проблем, потому что обе возвращают нихуя.https://doc.rust-lang.org/book/if-let.html тут подробнее про if let
>>989396Так даже лучше. Спасибо, что разъяснил.
>>989396>thread 'main' has overflowed its stack>fatal runtime error: stack overflow Мало того что код говняный (из-за ублюдского синтаксиста, твоей вины нет), так ещё падучий.
Добрейший вечерочек, уважаемые. Как там у вас с IDE в 2017 году?
>>989321> Err(_) => main()Ты что больной?Запускай свою хуйню в цикле и выходи в ветке ok, а в альтернативной выводи сообщение об ошибке.Иначе ты просто уйдешь в рекурсию. И вообще, какой придурок может рекурсивно вызывать main, сколько живу а такого наверное не видел.
>>989709Юзаю плагин для eclipse, все вполне нормально автокомплитится.
>>989496>челик пытается открыть файл которого нет>потом вызывает эту функцию (причём точку взода) бесконечноОру бля.В говне такое тоже не сложно делается, расслабься.
>>989709Плагин для идеи уже в отличном состоянии — всё, от рефакторингов до автокомплита и линтинга с отслеживанием лайфтаймов уже есть (только вложенные макросы парсить не умеет), скоро даже дебуггер даже будет.Алсо, есть RLS если не хочешь жаваподелий, с примерно тем же функционалом (но вообще не работает с макросами и анализов, нужно поебаться с настройкой и у линтера явно меньше).
>>989716>В говне такое тоже не сложно делается, расслабься. Такое можно сделать почти на любом языке, нужны только кривые руки, ничего более.
>>989712Я знаю, что использовать рекурсивный вызов функции является злом, но никак не могу понять как сделать так, чтобы при неверном вводе предлагалось ввести текст заново, а не делать panic.
>>990074https://doc.rust-lang.org/book/guessing-game.html самый древний туториал по расту как раз это и объясняет.
>>990074Я же вроде написал - делай это в цикле и выходи с него при успехе.
Помогите с TOML. Пытаюсь выполнить cargo build и выдает couldn`t parse as TOML. Насколько я понял файл TOML сгенерирован самим cargo для одной из зависимостей. В чем проблема? В cargo самой программы в [dependencies] только строка hyper="*".
>>992960Да нет, долбоёб, он твоим больным мозгом генерируется. Сначала ты стёк переполнял рекурсией входной точки, теперь в заголовки конфигово томла пихашь куски кода.
>>992973Шизик! Шизик!
>>957553иди нахуй со своим NT-говном и миниксом с овердохуя сисколлов. в редоксе ровно 31 сисколла, там даже сокеты через open создаются, как файлы. больше не нужно.
>>992960rm -rf ~/.cargo/registry сделай
>>992978Ну так это ты и есть, лол.Минутка грамотности: генерируются .lock файлы, а не томлы, ti obosralsya.
>>992960>>992991так стоп падажи ебана, ты что либу time пытаешься установить?
>>993001Да
>>993197И зачем нам помогать тебе заниматься фистингом?
>>993197зависимости на библиотеки нужно добавлять в Cargo.toml своего проекта, cargo install ставит некоторые програмки типа rustfmt и плагинов под cargo, но не либы
>>956909 (OP)Друзья, раст мертв при рождении , переходите лучше в Golang тред, пока не поздно!
>>993454golang>gc>дженериков нет>мутексы не связаны с данными, которые они охраняют>проброс ошибок по стеку анальная мука>неюзабелен для написания драйверов>нет паттерн матчинга>система типов какая-то параша >компилятор не может доказать отсутствие одновременного доступа к не-атомным данным>код сложнее хеловорлда на голанге похож на вырвиглазный кал>...идеальный язык для вебмакак. что в голанге хорошего, это то, что он простой и что в нем искоробки forkjoin
Не так уж много языков со столь уродским синтаксисом. Такой-то перл 21 века.
>>993505Ваше мнение очень важно для нас
>>993454
От раста будет профит, если мне хочется ради фана васянить свою 2D rpg на нём, а не на сях?
>>994322На питоне или жсе нахуячь. В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой (которая очень нужна в твоей 2д залупе). а вообще, иди ешь торты.
>>994326>В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкойТо, что мне и нужно.HelloWorld готов, теперь можно и изъёбствами языка обмазаться.
>>994340пишу в свободное время игрушку поигратся на вулкане на расте, раст таки заебись, советую
Аноны, кто учит раст, радуйтесь, у вас есть cargo - сама охуенная система сборки и управления зависимостями, сеьёзно. Я тут вкатываюсь в кложу, язык для своих целей ящитаю годный, писать на нём приятно, но вот сборка это ад, по сравнению с растаманским cargo и даже питонячьим setuptools. У меня всё.
>>994514gradle для кого сделали?
>>994514И чем он лучше lein?
>>994514На большинстве статически типизированых языков сборка это ад. Либо у тебя длиннющие и неудобные makefile.am, либо cmakefiles.txt, где забываешь уже через полгода что для чего инклудил. В мире java это хотя бы имеет более человеческое лицо, спасибо jetbrains за труды.
>>994516Жява-энтерпрайз-оверинжиниред-говнище.>>994514Ты как нибудь с окамлом поиграйся. Поверь, это пожалуй самый ахуительно собирающийся язык.>>994603При чём тут статика-то, долбоёб? Это у всех компилируемых языков с легасиговном вместо системы сборки такая проблема.В тех же плюсах (священное поприще легасиговна) дохуя билд систем вроде Qbs и meson, которые по большому счёту не сильно-то и уступают cargo.
>>994603Ну я пока для упражнений из K&R накатал скрипт на петоне который генерирует ниндзя-файл. Очень удобно и прозрачно, вообще в последнее время часто вместо систем сборки использую самописные скрипты, потому что мне нравится полностью контроллировать процесс сборки. Вот в leiningen я не чувствую что я вообще что-то контроллирую, какая-то непонятная медленная не работающая так как мне нужно магия. Попробую в Boot вкатиться, говорят, он получше.
>>994656Вот огромная проблема всех этих крестовых билд-систем в том, что нет какого-то единого репозитория пакетов, как в расте. Так что или клади зависимости в git submodules, или довольствуйся теми пакетами, которые есть в репозитории используемой билд-системы, или сам упаковывай пакеты, или я не знаю что ещё. В расте же сделали сразу по-человечески, и это охуенно.
>>994688Дык я не спорю, я это говорил к тому, что жто не статики проблема.Есть же кроме этого тягатели зависимостей с гитхаба по тегам и версиям.Скоро ещё мб осилят подход как в том же гредле — указывать источники зависимостей.
Бомбану во имя Аллаха.
Есть способ получше найти самое большое число из тех же цифр?let number: u64 = 9875543221; let mut chars = number.to_string().chars().collect::<Vec<char>>(); chars.sort_by(|a, b| b.cmp(a)); chars.into_iter().collect::<String>().parse::<u64>().unwrap()
>>1000296Определенно есть способ быстрее.Ты критерий лучшести задай.
Что это за хрень получается? Компилятор говорил, что для &&{integer} нет оператора ==, добавил две звёздочки - работает. Ничего не понял.
>>1001734Мудило с картинками, ты опять на связь выходишь?>что для &&{integer} нет оператора ==, добавил две звёздочки - работаетНаверно потому что звездочка перед идентификатором означает разыменование указателя/ссылки.
>>1001734https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.filter
Компилятор раста написан на С++?Фу, блять, какой позор.
>>1002746ллвм на цпп. растц на расте
>>1002746Первая версия была на окамле, потом все на нем самом же.
>>1003231Зачем тогда раст требует установленного MSVC++ ?
>>1003334Потому что ты - спермовор у спермы свой особенный и единственный линкер и набор библиотек (всякая символы для системных вызовов, динамические библиотеки и прочая хуйня без которой ты буквально хэловорд не соберешь).Он собственно требуется всеми известными мне компиляторами (врде д, пони, окамла). Разве что го-велосипедисты написали свой, который срет бинарями хэловордов по 10 мб на которых любой дизасемблер падает с ООМ.
>>1003376>го-велосипедисты написали свойВот это мне нравится.
>>1003436>>1003376>который срёт бинарями хэловордов по 10 мб>и хуй тебе а не нормальный dead code elimination, будем бить по рукам за неиспользованные импорты>хуй тебе а не link time optimization, profile guided optimization, межпроцедурный анализ и всё остальное, прямо или косвенно требующее поддержки линкераДа мне это тоже нравится, братишка.
Поржал с вас.Мимо эйфеле-господин
Поржал с эйфеле-го-раст борщехлёбов.Мимо-цпп-боярен
>>1003502Лучше жрать говно, чем обмазываться сишным дерьмом.
>>1004970Суть в том, что сишный линкер как раз таки заебись.
>>1005115>сишный линкер как раз таки заебись
>>971909snake_case, CamelCase, всё в куче, что за пиздец.
>>1005400Ну да, не то что в расте. Можно пельмени сварить там, или чай заварить, пока всё линукется - разработчик никогда не останется голодным
>>1005492Да в настах и сих дело не в линкере. И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.>>1005490snake_case для имен функций и переменных и CamelCase для типов и структур — самое лучшее сочетание евер.
>>1005753>И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.Ты бы ещё рассказал ему что си имеет текстовый препроцессор, каждый раз заново парсит все инклуды и просто не укладывается в какой нибудь LL(1) с лукапом в 1 символ как его говно, а расту для чека каждого лайфтайма нужно обходить графы всех затронутых функций и объектов для каждой хуитки и заниматься прочим статическим анализом.>>1005490Тем временем, в говне из модуля функции, структуры и (!) переменные (!) импортируются по регистру первой, сука, буквы. Повар, какого хуя ты вообще рот открываешь?
Бляя, растоблядки, объясните мне, в чём разница между immutable variable и const?Всякие пидоры на стэковерфлоу пишут "НУ ТИП ЭТ ТЫ ПРИВЫК К С++!!!))) В РАСТЕ ВСЁ ПО-ДРУГОМУ!))) ПЕРЕМЕННЫЕ ТИПА НЕ МЕНЯЮТСЯ))"Какого хуя, если variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени. Какого хуя всё так тупо?
>>1008074Если бы Страуструп стал женщиной и его отымел Милнер, то вместо C++ появился бы Rust.В общем, я что сказать хотел... Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
>>1008074const в расте — это как дефайн в сях, просто подставляемое значение.И var в русте нет, здесь только let, шо как бы намекает дебилам как ты.
>>1008108>Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.Все ML-и дохлые, к сожалению, даже окамл, который хз сколько лет развивают. Он сейчас только с точки зрения научного интереса тыканья палочкой.Д — я надеюсь когда нибудь его зотя бы до состояния раста допилят, языку десять лет а он сырой как твоя мать на концерте Маликова.
>>1008130>Все ML-и дохлыеPolyML недавно релизнулся. Правда, Юникод так и не завезли.
>>1008134Он релизнулся раньше чем ты родился, так с того времни никуда не сдвинувшись с SML 97, куда там.Если хочется ML-я — тут есть окамл который хотя бы развивается, и куча трупов.
>>1008134Ну кроме окамла ещё F#, но там больше шарпа в смысле парадигмы (хотя сексуальные хачкель операторы вида <><[][——€•^`>> на месте).
>>1008074> variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени> во времениРаспространённое заблуждение. Слово "переменная" пришло из математики, где никакого изменения во времени оно не означает. Оно означает что значение может меняться в зависимости от исходных данных (то есть, по-нашему, от запуска к запуску). А вот "константа" в математике - это то, что не меняется вообще никогда, с любыми исходными данными. Собственно, const в Rust это как раз значение известное на этапе компиляции, тогда как значение переменной вычисляется уже в рантайме.
>>1016135Вот да. А меняться во времени это уже к реактивному программированию.
Пока хуйтеры срут, оракл выкатил новую залупу на расте в опенсорс.
>>1017796Что конкретно?
>>1017832https://blogs.oracle.com/developers/three-new-open-source-container-utilities
>>1017854Нормально.
>>957819Но как же, господа, ведь математически докококазана безопасность.
>>972459У тебя какой-то галлерный руснявый тырпрайз.
>>1018496>У тебя какой-то галлерный руснявый тырпрайз.Нет никакого другого тырпрайза.Ты бы пообщался с тырпрайз работниками из штатов.Поголовно всем на все посрать. Свиноматки в декрете работающие(системным аналитоком) из дома и нехреа непонимающие в происходящем.Жрущие во время митинга по скайпу и успокаивающие там же ребенка.Индусы (настоящие американцы).И прочие прелести.Здоровому человеку в этом всем говне делать нечего.
>>958602Можно поместить себя в клетку и так прятаться от собаки, а можно собаку поместить в клетку.
>>1019277Не знаю, занимаемся промышленной разработкой небольшой командой и ус не дуем. Решения выбираем прагматично, код пишем рационально, не полагаясь на карго-макакинг.
>>1019384>занимаемся промышленной разработкой небольшой командойИ причем тут энтерпрайз?>занимаемсяДоход поровну делите?
>>1020115Тому що предназначение софта - аэрокосмическая промышленность.Ни.
>>1020240
>>1020240>Тому що Свиней давно в космос запускать начали?
>>1020631Не, я конечно допускал, что две буквы могут к подрыву привести, но всё же, рассматривал больше как теоретическую возможность, всё же /зк.Приятно удивлён
>>956931>пизже >GCобкекался
>>961111Не совсем, Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность). Как бы Rust не старался, плюсы еще долгое время будут жить, а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй. Но, на данный момент, язык дико молодой и, как следствие, сырой.
>>1020983Раст уже поржавел.
>>1021225Ты чё сука ты чё. Раст популярнее и популярнее с каждым днем: вот новость недавняя, даже оракл выпустил приблуды для изолированных контейнеров:https://github.com/oracle/crashcarthttps://github.com/oracle/railcarГлянуть в код, увидеть - та еще параша, а я зык выбран из соображений - поиграться
>>1020983>Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность)Не осилил лайфтаймы. Есть по ним вменяемый тутор?
>>1020983>а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуйДавно бы уже пошла, если это было бы проблемой.
>>1021632Есть. Называется практика и ебля в жопу с компилером.
Есть такой теоретический вопрос. Посмотрел стандартную библиотеку раста, а там нет даже либ для http. Вопрос, как реализуют такие библиотеки, в теории. Используют какие то либы операционной системы, или как то по другому?
>>1024575Говорят системе открыть сокет пишут туда
Заебала долгая компиляция. Как я понял, в расте нет аналогов объектных файлов из цепепе, когда вношу любое изменение - проект пересобирается полностью. У меня 17к строк в проекте (большая часть - сгенированные биндинги opengl), компиляция занимает секунд 15.Похоже, придется перекатываться на кресты.
>>1024721Охуеть теперь. Я и по 2 минуты ждал постоянно потому что в движке было много объектых файлов и пека слабый.
>>1024721Че ты понял? Че ты понял сука,тебе вьебать, а?
>>1025182Ржавый?
>>976573Фп-кун, ты еще тут?
Чому на расте так мало проектов пилятся? С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow, а с другой стороны работы на нём нет и положительных тенденций нет
>>1034290Очень недружелюбный язык для вкатывания, поэтому просто нет тонны всяких "бот для телеграма на %языкнэйм%"
>>1034290>С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflowЭто значит только то, что он вызывает больше всего вопросов.>так мало проектовЗавезли бы корутины.
>>1034439> Это значит только то, что он вызывает больше всего вопросов.Нет, это они опрос проводили. https://insights.stackoverflow.com/survey/2017> Завезли бы корутины.Стекфул корутин, как в Го, не-бу-дет. Копают в сторону стеклесс и асунк/ашаит.
>>1034577>Нет, это они опрос проводили.Ах лол.Любимый в смысле на нем не программируют, но что-то слышали.
>>1034290Каких это проектов там мало? Каждый Вася Жопин не пилит свой веб фреймворк и бот для телеграма умеющие нихуя?
>>1034753Как раз веб фреймворки по-моему и пилят. Не совсем понимаю зачем они нужны.
>>1034748Болезный?> For the second year in a row, Rust was the most loved programming language. This means that proportionally, more developers wanted to continue working with it than any other language.
>>1034766>Болезный?>> For the second year in a row, Rust was the most loved programming language. This means that proportionally, more developers wanted to continue working with it than any other language.Ну, это замечательно.Учитывая, что в категории Programming Languages в том же опросе, раста нет вообще.То есть им не пользуются от слова совсем.А кучка шизиков на нем кодящих хочет кодить и дальше, что как бы закономерно.
>>1034757Нативных альтернатив нет, но бизнесу всё равно выгоднее использовать асп.нет, а большинству и пхп сойдёт, так что задач нет.
>>1033011Давно не заходил, теперь тут
>>1024721> компиляция занимает секунд 15.Так тебе программы писать или лабу2 конпелировать?мимо скала-боярин
>>1035337Напейсание лаб ныне кличут TDD.
>>1024721В анус себе перекатись, блять, начинают кодить на Visual Studio и начинаются ебаться в жопу и думать, что компилятор сам по себе выполняет функционал makefile
>>1035337Причем тут лаба, долбоёб?На крестах есть инкрементальная сборка, крупный проект первый раз может собираться несколько минут, а потом, когда вносишь изменение в несколько файлов, проект пересобирается уже за пару секунд, т.к. собираются только затронутые объектные файлы. А в расте такого нет, если у тебя в проекте 1000 файлов, а ты изменил 2, при сборке будет собираться полностью.>>1035358Какая visual studio, какие makefile, ты чем там объебался?Я так-то под линуксом сижу и юзаю cmake/clang.
>>1035947Да, действительно ебу дал, на rust нет инкрементной сборки.Охуеть, это какой-нибудь проект уровня хрома после каждого патча целый день собирать? Как жить-то?
>>1035958Делить проект на крейты и жить как белый человек с модульной архитектурой кода, а не заниматься напейсанием индусских монолитных кусков говна на миллионы строк, как это помогли делать миллионам макакусов K&R. Открой исходники серво и посмотри как это делается.Вообще, ты даже до гугла похоже не добрался — там есть инкрементальная компиляция https://internals.rust-lang.org/t/incremental-compilation-beta/4721 , другое дело что это не плюсы в которых её 2 десятилетия пейсали (и которая точно так же как раньше не работает при изменении предкомпилированных или просто везде используемых заголовков), и пока по умолчанию она не включается.
>>1035947>Я так-то под линуксом сижу и юзаю cmake/clang.У тебя там цмейк сам собирать научился, без бэкэнда, поешавший?>под линуксом>clangВот с этого особо орнул. Ты там как, пользуешься сборками трехлетней давности, или сам собираешь? Я вот представляю уже, как ты после каждого релиза тащишь себе релизную ветку и билдишь ллвм со шлангом по 12 часов с ИНКРЕМЕНТАЛЬНОЙ компеляцией, и ору
>>1036282Поцчему трехлетней давности?мимо clang-5.0-господин под дебианом
Платиновый вопрос. Что за лафтаймы такие?
>>1038409Платиновый ответ: доку открой.
>>1038418Сложно.
>>977091А как без системы управления пакетами? Это показатель современного языка. Без этого, это какой-то каменный век.
>>956909 (OP)>как думаете, он сможет вытеснить жаву? Почему?А нахрена? Rust он крут. Я не думаю, что нужно ставить вопрос именно так. Java все равно будет жить ещё долго, как и сраное php. Ведь его куча говнокода в Ынтерпрайзе. Ну и пусть варятся в собственном соку.
>>1041669Да, Rust ОСОБЕННЫЙ. Как и ты, судя по тому, что и как пишешь.
Ананасы кто-нибудь работает над ии? Стоит подучивать что-нибудь по этому параллельно с веб макакетством или все тщетно, если конкретно этим не занимаешься?
>>1041669t.безработный студент
>>1043540Все работают над ИИ.
1. ООП в расте не нужен2. Он вытеснит не джаву, а C++
>>1046993Но там ведь есть своеобразное ООП
>>1046994> своеобразное ООППотому что это не ООП, люди подгоняют возможности Rust под тугое воображение ооп-ретрограда.
>>10469931) Нужен2) Вытеснит разве что из своей щеки
>>1047013Что ты подразумеваешь под ООП? Если первым словом в ответе на этот вопрос будет "наследование", то сразу иди нахуй.
>>1047113Ну ты и лох, какое наследование, все знают что ООП - это когда можно методы через точечку вызывать и ИДЕ тебе автодополнение предлагает.
>>1047113Абстрактную фабрику абстрактных фабрик энтерпрайз фасолин.
>>1047541Ну вообще говоря так и есть. ООП это всего лишь паттерн управления стейтом, когда стейт лежит рядом с функциями для их обработки в одном контейнере, а программа состоит из кучи таких контейнеров.
>>1047779> ООП это всего лишь паттерн управления стейтомНет, ООП и императивное программирование это ортогональные понятия.
>>1047829Любишь смоллтолк?
>>1047829Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
>>1047855Незнаком с ним. Да и моё утверждение верно для любого мейнстримного языка, будь то Java или C#.>>1047896Замени в своей фразе "стейт" на "данные" и получишь более-менее точное определение.На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта.
>>1047909> На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейтаЯ что-то тебя не понял.Присваивание полей в конструкторе, используется как гарантия того чтобы не было полуготовых объектов, т.е. таких объектов, которые будучи инициализированными, не дают собой полноценно пользоваться. Стейт от этого вообще никуда не девается. Мимопрохожий.
>>1047972Иммутабельность.
>>1048019ок, стейт ≠ иммутабельность, а ооп с фп имеют больше одной точки пересечения.
>>1047896>Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?ООП это подход при котором отправитель сообщения и адресат никак несвязанны и независят друг от друга, а оба зависят от сообщения. Суть в переносе связи между модулями на сообщения. В c# это происходит через интерфейсы. В с++ через абстрактные классы. (система типов плюсов/джавы превращают ООП в скотское безумие)
>>1047909стейт === данные
>>1048073> стейт === данные
>>1047896ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
>>1048620Боб Мартин залогинься.
>>1048620>ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки>>1048620>но никогда не видел ОО-ориентрованых програм на функциональных языкахОпределись наконец, Эрланг ООП или нет?
>>1048620Всего 2, фунциональное и логическое это частный случай декларативного программирования.
>>1047779Да хуйня какая-то, всё время прошу показать мне пример и объяснить почему это "ООП" а не сахар для процедурщины (я про вызов через точку). Вон в D можно обычные функции через точку вызывать, ну типа foo(a, b) и a.foo(b) - одно и то же. И шо, резко стало ООП? Да нет, нихуя. Вот объясните мне, где в вызове foo(a, b) стейт, а где не стейт. И почему оба аргумента не могут быть "стейтами".
>>1048620> ООП в современном виде - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедурыДва чая этому господину
>>1049419Рукалицо.Как концепция, может быть надстройкой над синтаксисом конкретного языка?
>>1049454Хватит разговаривать с голосами в голове. О каком "синтаксисе конкретного языка" ты говоришь?
>>1049417> foo(a, b) и a.foo(b)Полиморфизм.
>>1049526что?
>>1049542Во втором случае метод может быть переопределен.
>>1049565Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Что ж, полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). В расте есть куда более адекватный способ переопределения поведения - ad-hoc полиморфизм. Собственно говоря, он есть и в Haskell. Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
>>1049606> Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Суть ооп - полиморфизм, инкапсуляция, наследование.> Что ж,> ненужная хуйня (по той причине что> ненужная хуйня)Ясно.
>>1049616>Суть ооп - полиморфизм, инкапсуляция, наследование.Ну вот и получается, неследование не нужно, полиморфизм в классических ОО-языках опирается на наследование и потому не нужен.Что касается инкапсуляции, то её можно рассматривать как сокрытие данных (такая трактовка описывается как неверная в русскоязычной и как одна из допустимых в англоязычной) - и тогда это довольно скучно, полно языков не поддерживающих сокрытие данных, но при это считающихся вполне пригодных для написания ОО-кода; или же можно трактовать инкапсуляцию как механизм "упаковывания" данных и кода, с ним работающего. Тогда опять-таки вопрос, во-первых, о чём речь идёт когда говорят об ОО-подходе в C (где ни наследования, ни полиморфизма, ни полноценной инкапсуляции); во-вторых, что делать с пресловутой проблемой бумаги и пера - paper.write(pen) или pen.write(paper)? Ну и в любом случае инкапсуляция (в смысле "упаковки") выглядит именно как незначительная надстройка над процедурщиной, сопровождающаяся как правило соответствующим сахарком.
>>1049412Эрланг это язык программирования. Возможно это сложно понять, но язык и "парадигма" - не одно и то же. Если честно, я не знаю какую часть Эрланга занимают акторы, никогда с ним не работал. Но, например, тот код что я видел и писал на Акке (именно работу с акторами), функциональным назвать невозможно, а вот ОО - вполне.>>1049414Ты прочитай документ по ссылке, не ленись, ума наберись.
>>1049606>полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.> адекватный способ переопределения поведения - ad-hoc полиморфизм. ad-hoc полиформизм - не true полиформизм. True - параметрический.> почему это "ООП" а не сахар для процедурщиныПотому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.> Значит ли это, что программисты на Haskell постоянно используют ОО-подход?Это значит лишь то, что элементы ООП проникли в функциональщину, ОО языки несут в себе примесь функциональщины, при этом никто не считает их функциональными.> что делать с пресловутой проблемой бумаги и пера Доябываться до заказчика, пока не будет ясно какая система должна получится в итоге. Получив представление строишь наиболее очевидную (предсказуемую, скучную) систему.
> наследование - ненужная хуйняБтв, с этим не согласен. Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом. Только не надо пихать во все поля наследование. Это скальпель для построения иерархии типов, yj в жизни обычно хватает молотка в виде пары десятков заезженных паттернов.
>>1050038> Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.Я и не говорил, что полиморфизм не нужен. Я лишь сказал, что тот полиморфизм, о котором обычно идёт речь в котексте ООП (т.е. полиморфизм подтипов) и который завязан на другой "столп" ООП - наследование - не нужен. Против ad-hoc и параметрического полиморфизма ничего не имею, даже наоборот, считаю что это очень нужные концепции. Только вот когда говорят о полиморфизме в контексте ООП обычно имеют ввиду не дженерики и не трейты/тайпклассы.> ad-hoc полиформизм - не true полиформизм. True - параметрический.Я же говорил про способ переопределения поведения для разных типов. Параметрический полиморфизм позволяет лишь определить одно поведение для разных типов, а не разные поведения для разных типов.> Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.Так, а вот это уже интересно. До сих пор в треде никто inversion of control не упоминал. В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.>>1050047>Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом.И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?> Это скальпель для построения иерархии типовИ зачем оно в реальной жизни может понадобиться? Точнее, в каких ситуациях оно может быть удобнее, чем подход того же Rust?
>>1050047И да, diamon inheritance - не единственная проблема наследования. Другая проблема состоит в железобетонности иерархий типов, построенных наследовании, другими словами - в том что они очень плохо расширяемы.
>>1050670> И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?Взяли и выпилили множественное наследование, лол. Если мы говорим о java и его клонах типа c# <hidden_tags=trollface, sarcasm> :)</hidden_tags>.> иерархии типов> И зачем оно в реальной жизни может понадобиться?Кейсы по liskov substitution principle: приходит множество объектов и нужно выбрать такие что гарантируют implementation интерфейсов родителя. При этом у каждого объекта есть свое уникальное поведение. В реальной матрице это может быть игра-стратегия: пользователь выбирает ХуйПятьсот Unit'ов. Не снимая выделение, User нажимает ПКМ. Кавалеристы, пыхота начинают движение, реализовывая интерфейсы Human (Human < Unit). Выборка Human из Unit возможна из-за наличия иерархии типов, делая удобной фильтрацию ненужных выделенных инстансов, например инстансов Building (Building < Unit).> Другая проблема состоит в железобетонности иерархий типов, построенных наследовании, другими словами - в том что они очень плохо расширяемы.Я бы не сказал, что это проблема, это trade-off - выбор наиболее удобной реализации. Если класс предполагается расширять, то не надо наследоваться, давай воспользуемся Open/closed principle - это позволит избежать переписывания старого кода и заняться расширением. > В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.Именно так. На мой взгляд, разночтения происходят из-за двух вещей:1. Маркетологи учат программистов как нужно жить. ООП - это не про объектно-ориентированного кота, но про менеджмент зависимостей (модулей) в программе. 2. Реализуются идеи ООП по-разному. Мы уже выяснили, даже в функциональных языках есть формы полиформизма, но эти языки прежде всего остаются функциональными. А еще мы любим поговорить об особенностях реализации ООП на своем языке, но это не то, что отличает ООП от модульного программирования.> Параметрический полиморфизм позволяет лишь определить одно поведение для разных типов, а не разные поведения для разных типов.Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
>>1051235> Взяли и выпилили множественное наследование, лолТак отлично, а что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?> Выборка Human из Unit возможна из-за наличия иерархии типовНу, всё то же самое можно сделать с помощью trait objects. Ну то есть принцип тот же, только без наследования реализации, только наследование поведения.> Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение.Ну для этого нужна поддержка рантайм-рефлексии, это хак)
>>1052018> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?Я непойму, ты хочешь чтобы я тебе википедию перерассказал, или что??? https://ru.wikipedia.org/wiki/%D0%A0%D0%BE%D0%BC%D0%B1%D0%BE%D0%B2%D0%B8%D0%B4%D0%BD%D0%BE%D0%B5_%D0%BD%D0%B0%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5#.D0.A0.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F> всё то же самое можно сделать с помощью trait objectsОк, давай тогда будем говорить что наследование не нужно в расте. А если ты не растаман, и у тебя нет trait objects, тогда что? Речь явно о наследовании в ООП в целом. Бтв, согласен с тобой, что наследование не столп, или точнее 'столп' в кавычках. Но это не значит, что оно концептуально ненужно.> Ну для этого нужна поддержка рантайм-рефлексии, это хак)Хак, это или фича - вопрос, конечно, интересный. Однако, параметрический полиформизм - true именно потому что включает, но не ограничивается ad-hoc полиформизмом. ad-hoc полиформизм не true по той же самой причине.
>>1052064>> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?Добавлю, в случая кода множественного наследования, вооще нет, то тогда класс расширяется через примеси, интерфейсы, и т.п.
>>1052142Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.>>1052064Так ты то говоришь что проблему diamond inheritance решили, выпилив множественное наследование, то кидаешь ссылку на список хаков которые кое-как решают эту проблему, и все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.> А если ты не растаман, и у тебя нет trait objects, тогда что?Ну мне кроме сишки в голову не приходит языков без поддержки динамического диспатчинга. Никто не мешает сделать всё тоже самое на тех же Java и C#. Ну да, кое-где нет интерфейсов как отдельной сущности (в C++ например) и там придётся использовать "наследование" как механизм языка, но при этом по-хорошему все равно надо наследовать не реализацию, а только поведение (как это у крестовиков, pure virtual inheritance?).
>>1052159> По-хорошему все равно надо наследовать не реализацию, а только поведениеА что делать с интерпретируемыми языками, опирающимися на duck typing, такими как ruby, в которых, в mixin'ах, реализация не отделяется от поведения? > все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.По моему скромному мнению, множественное наследование не нужно. Однако, есть языки где ситуацию с что делать когда одиночным наследованием не обойтись решили вот так, через 'хаки', если угодно. Этот ответ показался мне неполным, т.к. есть и другая категория языков - где мн. наследование выпилили, там я допонил чуть-чуть.Как из всего этого вытекает вопрос о том, что наследование вообще не нужно, чучхе не понимать.---> Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.Я с тобой согласен в том, что связи удобнее описывать не через наследование. С другой стороны, по Барбаре Лисков иерархия классов упрощает проверку наличия этих связей, и в этом и есть ценность наследования.
А вот и внезапный бамп растотреду!Объясните мне, аноны:https://github.com/sfackler/rust-postgres/blob/d374641ecb584bb668fa8e7a10d0f593a5c35ca2/src/io.rs#L24Строки 29-36, почему в match не указаны неймспейсы? Почему не MaybeSslStream::SslStream? Там ведь нет use.
>>1055130А нахуя ты смотришь какой-то коммит трёхлетней давности? Сейчас такое не скомпилируется.
>>1055216Наткнулся на код и даже не заметил, что это древний коммит, лол.
То, что полиморфизм — один из столпов ООПа, еще не значит что сам полиморфизм имеет какое-то отношение к ООП. В функциональных языках полиморфизма таки больше.
Растаны, для раста есть что-нибудь по ИДИОМАТИЧНОМУ РАСТУ, типа как pep-8 для змия, желательно еще и с примерами, как надо а как нет?Или посоветуйте опенсорс проект на гитхабе, который написан КРАСИВО на расте.
>>1060441Вот это чтиво в свое время позабавило https://rust-lang-nursery.github.io/rust-clippy/master/index.htmlВообще странно слышать об "идиоматичном расте" в языке, который сидит на двух стульях (хаскель и c++)
>>1060441Юниксовые корутилы на расте, они небольшие, самое оно для вкуривания в языкhttps://github.com/uutils/coreutilsАлсо, redox для вроде бы самого серьезного из низкоуровнего раста, что на сегодня естьhttps://github.com/redox-osИ это: https://github.com/BurntSushi/ripgrepИдиоматичный раст по идее описан в the rust book и в rust by example.
>>1060441Главное не забывай каяться перед меньшинствами в комментах, кек.
Перекат мне запилил!
>>1062380 (OP) ПЕРЕКАТ >>1062380 (OP) ПЕРЕКАТ >>1062380 (OP) ПЕРЕКАТ >>1062380 (OP) ПЕРЕКАТ >>1062380 (OP) ПЕРЕКАТ >>1062380 (OP) ПЕРЕКАТ
