Вы видите копию треда, сохраненную 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Также открываем здесь его обсуждение, с возможностью отвечать на ответы.
Что можно сделать на расте чего нельзя на С?
Слишком толсто
D - пизже.
Наверное, только потому, что мне идеология компиляции нравится больше, чем какая-то виртуальная машина, хоть она в конечном счете имеет нехилую оптимизацию. LLVM уже не мало так платформ покрыл. Еще, жава много памяти ест, если сравнить с аналогичной программой на C/C++/Rust/томуподобное
Посмотрите на этого эксперта сделавшего laba10.exe
В реальности от наследования больше проблем чем пользы.
Слишком много заебств в расте с видами указателей и механизмом владения. На джаве писать намного проще и как следствие намного легче найти людей, которые её знают. Там где используется джава производительность всех устраивает и получаем, что раст нахуй там не нужен. Проблемы создает, а бонусы преподносит слишком маленькие. Нет, я очень рад этому языку. Наконец-то появилась альтернатива мерзким плюсам, но вот только с ними он и может конкурировать. Более высокоуровневые языки он не потеснит никогда.
В Си надо быть крайне внимательным, работая с памятью, указателями и т.п. Так и стараются. Тем не менее, человеческий фактор всегда допускал там ошибки. Здесь (в расте) ты либо будешь послан нахуй компилятором, либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
В реальности люди комбинируют несколько подходов исходя из задачи.
А если через пару годиков под раст будет множество либ под любые нужды? Примерно как сейчас в жаве... В конце концов, там свои фичи, тут свои и время изучения не сильно разное
ООП местячковый мем в снг.
> либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
И чем это лучше сегфолта? Исключения хоть можно обрабатывать?
Что нового предлагает Rust, для решения этих проблем?
Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Без этих метрик нет смысла что-то обсуждать?
Я уверен, что раст тоже найдёт свою нишу, но однозначно это будет на Ынтерпрайз или web бэкэнд. Возмно, системщина и узкопрофильная прикладуха,возможно ембед, но не ололо контроллеры, а линукс борды. Но для эмбеда нужна спрос и поддержка корпораций, что врядли
>Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Реальные тесты производительности? Ну это уже по каждой конкретной задаче. Вот тут видим, что на бенчмарках( не отображают реальный мир), раст выигрывает c++ в 6/9 тестов
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp. Не забывай, что для раста не написано много ключевых оптимизаций, что есть у крестов, но вот растовская система типов позволит в будущем реализовать более агрессивные оптимизации, которые не возможны на c/c++, да и с каждым обновлением LLVM раст становится всё лучше.
>сравнения сложности разработки,
Таких точно нет, всё же на расте никто не пишет, лол. Позволю себе с дивана предположить, что раст в этом лучше т.к. большинство ошибок с++, которые приходится постоянно дебажить, находятся в расте на этапе компиляции. Возможно, если ты йоба-сеньйор с 20+ годами опыта плюсов, то ты не заметишь разницы в скорости разработки, но вот во всех остальных случаях, полагаю, раст сделает c/c++
>кроссплатформа
Компилятор не поддерживает Windows XP (хотя вроде может исполняться, но с какими-то ключами), хотя поддержка "Embedded Industry" (в ваших банкоматах и прочих) есть до 2019 года.
>скорости выполнения
Анон кидал ссылки на веб-серверы, крайне там что-то все уныло.
Мне интересно, в такой модели памяти - память в долгоживущем приложение не будет фрагментироваться?
>вытеснить жаву? Почему?
Нет. Тут даже Го не смог. Джава это сформировавшиеся индустрия, ее даже засахаренные скала и котлины потеснить не могут, хотя те на jvm.
На С в теории можно все, не зря же в нее компилятся большинство скриптовых языков. Другое дело что создать что-то большее чем драйвер на одном только С врятли получится, а даже если и получится то поддерживать это будет пиздецово. А в расте главная фишка что он безопасен и он строг к синтаксису - т.е. у всех будет более менее одинаковый код и при том гарантированно безопасный, что поможет избежать обсеров как с OpenSSL, когда выяснилось что весь мир годами пользовался дырявым софтом.
Сложнее C++ в принципе сложно сделать. В язык накидали фич не для решения конкретных проблем, а выбрали их рандомно, что вылилось в плохой дизайн языка.
Там есть множественное наследование поведения — не реализации. То есть интерфейсов — не классов.
>Что нового предлагает Rust, для решения этих проблем?
Ну уж точно не "миллионы леммингов и дешево". Rust сложнее С++, там как раз фишка в том, что сложность разменивается на стабильность.
пример притянут за яйца. любой школьник знает, что эта строка лежит в read-only секции. да и компилятор будет ругаться на каст сonst char к char
короче иди нахуй. сажи треду
два чая
>а выбрали их рандомно
Не рандомно. Каждое решение там вполне осознанное и обдуманное. Другое дело, что их вообще не надо было принимать. Или делать минималистичную сишку с классами или пилить новый язык.
Так сделали десятки ебанатов, но взлетел почему-то С++. А теперь поучи датчанина делать языки.
Да блять просто очередная перделка на гихабе, как laba.exe студентов.
А преподносят как готовый продукт.
Насколько я знаю, они его переписывают потому, что архитектура стала не поддерживаемая (казалось бы причем тут гибкость раст).
>А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.
Да дохуя на самом деле, но к сегодняшнему дню это всё либо осталось в музеях, либо пилится на коленке каким-нибудь Куртисом Ярвином или Терри Дэвисом. Хотя впрочем IBM всё ещё поддерживает z/OS.
GNU/Linux идеальная ОСь, BSD годная альтернатива. Остальное просто ненужно.
>Остальное просто ненужно.
Нужно, просто ты об этом не знаешь: http://www.loper-os.org/?p=284
>но к сегодняшнему дню это всё либо осталось в музеях
Потому что надо дрова из ОС выкинуть нахуй. Пусть железячники все хардварно реализуют с простым интерфейсом. Все равно и так блобы везде. Так пусть тот блоб на железе крутиться с простым стандартным интерфейсом наружу. Тогда можно будет для кучи устройств использовать один драйвер по спецификации.
Годная идея. PostScript в принтерах был шагом в правильном направлении.
зачем нужен виндоус у которого нет экосистемы? На котором до сих пор мертвым грузом лежит дохуя (50%) легаси? Единственное за что их можно уважать за то что форсят переход на новые железки.
Видео драйвер интела из-за легаси пидарастии раздут с 1 мб до 200, в 200 раз больше необходимого, пиздец.
МакОСь хоть и для пидарасов, но сбалансирована, имеет нормальную щель, работает без бсодов.
Популярность С++ гарантирует, что с твоим подходом что-то не то. И довольно банальное - обратно-совместимое решение победило. Из тех времен живо 3 языка, это С, С++ и Objective C. Угадай, почему.
>легаси и есть экосистема, тупой ты уебок
>и да, это оскорбление
В голос с дауна.
Экосистема это когда в системе не дублируется одно и то-же и четко разделено что за что отвечает.
Виндовс 20 лет не чистилось от говна, вместо того чтобы это сделать добавляют %фичи% и велосипеды чтобы они работали.
Одинаковые названия программ, драйвера по 300 метров для звуковух и видео, три встроеных браузера и двое меню настроек на покушать.
Ты бредишь, Митя. Экосистема - это экологическая система, почитай, что такое экология. Это когда куча животных, едят друг друга и срут, но система при этом стабильна, потому что все в балансе.
> друга и срут, но система при этом стабильна, потому что все в балансе.
А шиндовс не стабильна и не нужна согласно http://www.loper-os.org/?p=284
шиндовс обсирается на первом же правиле, так что хватит за них топить Пыня.
Популярность продукта в массах — это показатель только его доступности для широкой аудитории.
Это как сравнить айфоны с кучей говна на андроиде — первые по статистике занимают всего-то 10-15% рынка. Только вот незадача, из этих 85-90% только треть превышают отметку в 200$, а отметку в 500$ ещё треть от этой трети.
Вот и думай почему говно для тупорылых макак вроде го, пхп (и 1с в странах снг) стреляет. То же и с плюсами — худобедно любой дебил осиливает хэловорд, падающий через раз с сегфолтом — зато осилил жи!
Ты сам довольно тупорылый, если мобильные ос в принципе занимают какое-то место в твоей голове. А языка лучше С++ в своей нише объективно нет. Вообще. Никак. Ни разу. Поэтому умнейшие люди планеты пишут свои продукты на нем, с нуля и до сих пор.
Ты домен какаой-та толе на плюсах писали раньше потому что небыли альтернативы. От слова совсем. Либо Ява, либо говно вроде D со сборщиком.
Что ты там увидеть ожидаешь-то? Плюсовикам (как и вообще всем, кто не занимался каким нибудь хачкеллем, в котором компилятор так же ебет за попытки сделать хуйню) переучиваться очень больно. Иде уровня студии нет, но хуитка для редакторов с нормальным (не уровня тегов из вима и прочей еле работающей хуйни) автокомплитом и подсветкой ошибок из компилятора есть, хотя и альфа, которая собирается только через три анальных кольца. Можешь почитать истории от челиков из дропбокса - https://www.reddit.com/r/rust/comments/4adabk/the_epic_story_of_dropboxs_exodus_from_the_amazon/
продакшен.
Я к тому откуда могут быть утечки, если это раст. Значит unsafe. Хотя я помню что в каких то версиях раста все таки могли происходить утечки даже без ансейфа, когда паника запускалась другой в панике, но я посчитал что это прям обосраться какое исключение.
Хотя подожди. Проверка типов в языке с зависимыми типами может быть неразрешимой. Тогда нахуя оно надо?
А вот типы высшего порядка (да-да, те самые родненькие аппликативные функторы, стрелки и монады) были бы полезнее. Я правильно понимаю, что их можно эмулировать трейтами с ассоциированными типами?
Да, утечки есть, но я про то что ты как дауненок написал.
>unsafe юзали
Кто так пишет? Это пиздец просто.
Там нет исключений, но есть особая система типов. Т.е. функция всегда что-то возвращает. Но это может быть что-то (Some), а может быть ничто (None). Или например может быть некий результат или некая ошибка, что уже как бы является аналогом исключения
Правильно писать NSA.
Ты еще скажи что у раста уязвимостей нет, только что говорили что нет утечек, теперь это.
Если код пишет не си-обезьяна на ансейфах — то ни одной сишной точно не будет. Ты кстати забыл главный опус растотредов — memory leaks is memory safe, пидар.
Если руки кривые то ты утечку и в языке с GC сможешь сделать. От утечек тебя ни один язык полностью не убережет, так что думать головой все равно придется. Зато память в расте безопасная, без уязвимостей.
А как по-твоему писать ОСь, которая должна взаимодействовать с железом без unsafe'ов?
Например, так же, как в некоторых ОС давно зделоли.
А именно, написан препроцессор для Сишки, который на каждом шаге проверяет, не собрался ли драйвер поделить, скажем, на ноль.
У драйвера своя область стека, все данные он видит только на чтение.
Собрался поделить на ноль - ну тогда значит KernExitThread(-1) и едем дальше.
Я в работе современных (да и старых) ОСей не шарю, но на днях читал про прерывания. Что например если была попытка поделить на ноль, что будет вызвано такое-то прерывание. Где-то в памяти есть таблица (с адресами функций?), которые должны обрабатывать подобные случаи. И не всегда же надо тупо выходить. По крайней мере, родительский процесс должен знать, за что убили ребенка
Второкурсник ворвался в тред.
Да, это для обыкновенных процессов.
А в ядре ОС возникнет неисправимая ошибка во время выполнения, синий экранчик, у продвинутых чёрный.
Но в общем, не забивай себе этим голову, в роиссе на эти знания (очень ценные, ахаха) спроса всё равно нет.
Звучит неприлично.
Есть в виде модулей к не очень популярным языкам. Я же говорю будущее, а не настоящее.
Лет через 10 так, причём в совсем другом виде, а не то говно сейчас. Посмотри на циклон и раст - такая же разница.
Emacs самая лучшая IDE для любого языка.
Ну и к чему тогда твой вскукарек, различия жабы и смоллтока незначительны. Во втором только рефлексия продвинутей.
Друзья, я пытаюсь разобраться в возможностях языка.
Конкретно интересует асинхронное программирование, наткнулся на какие-то фьючеры, но они реализованы отдельной библиотекой, это как может вообще работать?
Ну в смысле, вот есть либа для общения с SQL сервером, но она же ничего про либу с фьючерами не знает, и как тогда это общение в код с фьючерами инкорпорировать?
>и как тогда это общение в код с фьючерами инкорпорировать?
Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
>Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
А это законно вообще?
>2к17
>геи
Новые гуевины шлепают только на мобилках со своими хост-языками, а десктопное легаси и без того вроде работает (хотя тот же гном вроде как по кусочкам, как и новый движок лисы переписывают на растяпу? но это неточно).
Есть разные биндинги под существующие либы
Например, https://www.youtube.com/watch?v=hLR8R0Zl0yY
>В манямирке
Значит на попытке написать scgi приложение я сосну?
Вроде tokio позволяет оче просто писать асинхронный сервер.
Я вообще мимо проходил(из го треда), сорян, помочь не могу.
>>965807
Полгода для раста это много. Сейчас как-то так.
https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
Они допилили асинхронный сервер (он полноценный или какая-то заглушка еще)?
Взял kiss3d и рейсеру вообще похуй. Он ничего не дополняет.
RLS натяни, работает через тот же рейсер, только с ошибками из компилятора на лету и анализирует крейты.
Плагин для intellij кстати, уже даже с макросами работает — криво и косо, но навигирует уже около них (в дислокации +- 10-20 строк, лул).
>Rust
Не взлетит.
>>957136
>без сборщика мусора
>миллионы макак
Последнее не подрузамевает мозг, а равно ручной гарбейжинг, а значит без певрого не возможно второе.
>а равно ручной гарбейжинг
Не так, габейджинг вообще не потребуется, потому что код будет написан безопасно либо не скомпилится.
>this. Так что без автосборщика мусора никуда.
Ну так прочитай книжку и пойми как надо делать что бы компилилось.
>Ну и дохуя тырпрайза перекатилось на него?
Ну как бы Rust не позиционируется как замена для джавы.
Хотя, мне кажется это возможно, если создать правильные годные абстракции.
Раст нужен там, где нужно создать хороший годный код который создаст хороший годный бинарник, который будет хорошо годно выполнятся.
Тнз тырпрайз, заточен под создание проектов максимальной сложности путем задействования минимально квалифицированных трудовых ресурсов.
Совсем другая область.
Мне кажется раст будет ультрагоден для создания осей и низкоуровенего софта, т.е. там, где сейчас С и С++.
Пистон это набор либ, а не движок. Если верить описанию с https://github.com/amethyst/amethyst/wiki/Other-Game-Engines-in-Rust
Но оно говно пока что. Что-то годное сделают когда раст станет массовым.
Быстрее плюсов.
Хотя ирл однохуйственно перекомпиливается только 1 модуль, и на минимальной конфигурации мбп 2016 весь цикл компиляции-тестов проходит быстро, если ты не меняешь весь проект и зависимости вместе взятые за раз. И в отличие от го с быстрой компиляцией, тут при отсутствии ансейфа дебаггер действительно нинужин.
Дебагер не нужен? Быстрая конпеляция не нужна? Ты всю хуйню пишешь без ошибок с первого раза?
Ты даун который мой пост не прочитал.
Но да, с его системой типов и статическим анализом он в своём каноническом юзкейсе рили не нужен. Разве что с пошаговой поддержкой IDE для изучения чужого кода прикольно было бы.
http://paste.org.ru/?57pxj7
Как быть если случится примерно такая история? Как раст меня от этого защищает?
В го дебагер не нужен потому что
1) Быстрее въебать принт и переконпелить
2) Если ты поймаешь панику ты получишь четкий стектрейс
В расте он не нужен потому что:
а) Если не пытаться руками завалить код — он не разыминует висячий указатель/нульпоинтер/итд.
б) Стектрейс в дебаг-билде в любом языке избыточен, вась.
По твоему кто-то специально стреляет себе в ногу? Нет, блять, это говно всплывает в проде когда ты этого меньше всего ожидаешь. Система типов никогда в жизни не научит тебя не совершать ошибок, которые вызовут у твоих клиентов жопную боль. Может ты и не сможешь поделить попугаев на тараканов, но вот вместо одного бесплатного попугая выдать чуть более 9000 - легко.
Кукаретик, еще раз тебе повторяю, что 99% ошибок это ошибки бизнес логики, а не разыменования указателей.
В высокоуровенных языках вроде явы, где их и нет. А так, открой свежий список CVE, посмотри как там дела с 1%.
Она поможет мне ковыряться в говне из байтов без стрельбы в анал и гонок данных. Давай заводи демагогию по новой.
Ты о чём?
>если создать правильные годные абстракции
А вот тут, кстати, у меня вопрос возник. Где почитать именно про приемы проектирования на Rust - с примерами неудачных решений, разбором полетов и т.д. По классическому ООП такой литературы завались, а тут куда копать? Ну или хотя бы исходники какого-нибудь годного проекта средней сложности посоветуйте.
cargo check
>Где почитать именно про приемы проектирования на Rust
Предположу, что скорее всего нигде, кроме исходников чужих проектов. Советую сначала погуглить, а если найдешь- вбросить сюда.
>>972833
https://github.com/rust-unofficial/patterns
От авторов знаменитой "learn rust by writing too many lists". Хотя там большинство контента всё ещё только TODO без описания (:
Проекты смотри где нибудь на https://github.com/kud1ing/awesome-rust
Где-то кстати видел компилятор хаскеля на расте, тоже можешь глянуть, лул.
А вообще, вся кор-тима раста работает над серво, и половина над токио — посмотри на них если хочешь кода из первых рук.
1)Примеры ымбыдеда на вашем расте есть?
2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
1) Гугол открой;
2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты. Сравни на том же реддите активность доски раста с досками плюсов и си вместе взятыми.
>2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты.
А не тот ли это шизик, что срет в го треде?
Это ты у него узнавай.
>тред, который мертвее треда полувекового С
Патамушто с неадекватами неохота разговаривать, норм чуваки все в гиттере да ирц пасутся
Надо было делать print << ln
Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
>Надо было делать print << ln
Иди нахуй за этим ублюдским говном в плюсы. Я реально рад, что сделали человеческое printf-like форматирование.
>Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
Так это и не окамл, дружок. Тут восклицательный знак (тем более справа от идентификатора, хз с чего ты про мутабельность рот открыл — мутабельно передать что-то можно только явно с mut) означает макрос, местный синтаксис разыменования указателей от си был унаследован, если ты не заметил.
Зачем оправдываться? Тут два стула - либо используй макросы, либо зависимые типы. Причем раст, похоже, будет видеть на обоих.
Ладно-ладно, есть третий стул - разбирать строку формата в рантайме и обрабатывать ошибку. Но для этого есть runtime-fmt
Я раньше думал, что вывод имеет отношения к монадам, а тут вон че. Поясни, пожалуйста.
Но я хочу чтобы было AbstractSingletonProxyFactoryBean чтобы объединять данные с функциями
Похоже на go лол
>2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
Проблемы /pr
Потому что абсолютное большинство тредов языкача - это холивары и баттхерты, например есть го тред, но там куча неадеквата.
Выглядит как язык от васяна где вся логика построена по желанию его левой пятки
Для деклоративного петушения со статической типизацией лучше взять Haskell, для навороченного синтаксиса Perl 6
Что-то ты забыл про главное отличие - систему типов Rust. Я и про lifetimes/borrowing, и про гарантированную на уровне системы типов потокобезопасность (вне unsafe), и про проверку типов в дженериках на этапе их создания а не на этапе инициализации. А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
И да, модули. В 2к17 инклудить хедеры вместо нормального импорта модулей - очень странно если честно. Это по сравнению с прочим мелочь, но всё-таки.
>А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
Вот только не надо это сложное для понимания уг тащить в Rust.
Сейчас это нормальный язык, Haskell к услугам тех, кто желает дрочить на монады/теоркат и теорию типов.
Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
>пример притянут за яйца. любой школьник знает
Схрена ли оно компилируется тогда?
ЛЮБОЙ ШКОЛЬНИК ЗНАЕТ
@
РАЗРАБОТЧИКИ КОМПИЛЯТОРА НЕ ЗНАЮТ
>Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею. Разумеется, дело может быть во мне, но для себя я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust. Для таких вещей есть Haskell и незачем засирать другой язык.
просто хаскеллисты хуеют от своего рантайма и хотят свои убер-абстракции, которые и сами не понимают, но при этом хотят efficiency раста
>опущенных {} (вау)
Ты сам только что показал что опущен только ты, лол. В расте много где опускаются обычные скобки, но все выражения (кроме однострочных результатов паттерн матчинга) делятся фигурными.
>стандартой библиотеке
Жеманный, не не пались, не знаешь же. После си и плюсов с atoi(), ftol() ntohl() и друзьями в расте просто AbstractSingletonProxyFactoryBean-ы какие-то
>>976388
Братан, вот поясни мне за эти функторы — а нахуя?
Я мб тупой слишком, но из пояснений в гугле понял столько же, сколько про монады — что это моноид в категории эндофункторов, ахуенно.
Сейчас у нас есть что-то между плюсами и сишкой — с композицией и tagget-unions вместо наследования, простым синтаксисом (дада), все очень явно, модули и так далее.
Короче, качественный кусок инженерного говна, если цитировать одного йоба-математика. На нем с некоторой сноровкой, конечно могут спокойно писать васяны вроде меня у которых никогда не было пар теорката или они нихуя не понели, в общем-то, примерно 95% программистов на си и плюсах.
А еще есть тот же ATS, в котором зависимые типы где-то даже видел коммент в стиле "правильно сделанный раст" и все прочее, на котором с комментария того же йоба-математика скорость написания кода в лучшем случае "400 строк за неделю". Карл, вот что такого дадут эти зависимые типы практичному языку, а не йобе от епонца, у которого в культуре высшее просветление — аутировать смотря на сакуру?
Cи делали 100 лет назад, в С++ этого уже нет за редким исключением, писать fn вместо function даже не каждая обоссанная обёртка для JS себе позволит. Можно было использовать define или вообще function x = x раз уж match влепили. Для серьёзного языка с ориентацией на безопасность это абсолютно неприемлимо, даже переменные так называть нельзя.
>>976539
Ебать жеманного бомбонуло.
>>976529
Дык их и нет в расте, здеся у нас аффинные типы.
Линейные типы (по моему скромному пониманию, хз чо там по математической правильности) позволяют использовать объект только из одного места и запрещают копировать на него ссылки. В расте это называется владением.
В аффинной типизации есть возможность использовать объект не только из одного места. В сухом остатке, это грубо говоря есть заимствование.
>>976505
>Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею.
Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?
> я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust
Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.
> Для таких вещей есть Haskell и незачем засирать другой язык
Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
>>976511
>Братан, вот поясни мне за эти функторы — а нахуя?
На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.
Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.
> Карл, вот что такого дадут эти зависимые типы практичному языку
Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
>>976505
>Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею.
Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?
> я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust
Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.
> Для таких вещей есть Haskell и незачем засирать другой язык
Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
>>976511
>Братан, вот поясни мне за эти функторы — а нахуя?
На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.
Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.
> Карл, вот что такого дадут эти зависимые типы практичному языку
Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
блять, оно потёрло мои звёздочки
там должно быть в одном месте * -> *
в другом: * -> * -> *
Братан, можно было просто:
а) Сделать impl Display for Vec<Box<Yoba>> и всё;
б) Использовать дебажную форматировку в println (которая :?).
>На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> , то параметра должно быть два, и так далее. Разве это настолько сложно?
Ну я вот щас ничего не понял. Ты точно не стебешься? ->, -> -> - это что?
>Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
1. ООП все, кто связан с программированием, знают
2. В начальном приближении большинство концепций ООП можно объяснить сравнительно просто, можно это как-то постепенно изучать, а, когда на тебя обрушивается ворох стрелок и звездочек, это кажется сложным.
Разумеется, сказывается императивный бэкграунд и стереотипы об ФП. Плюс не совсем понятно, а нахуя это нужно, я понимаю конечно, что ты в обратку можешь сказать, что так можно и на голом С или asm писать и вообще отказаться от прогресса, но, повторюсь, зачем эти кайнды нужны я так для себя и не уяснил. Наверное, это красиво, но для меня отдает дрочевом и излишней наукообразностью.
>>976588
>>976573
>>976575
>>976577
Чет проиграл если честно.
>Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
Ну если смогут норм внедрить эти кайнды в язык и объяснить так, чтобы понял человек, который на хаскелле только факториалы писал, то я ничего против не имею, возможно это годная вещь действительно.
> ->, -> -> - это что?
Это парсер съел звёздочки. Смотри короче ссылку на pastebin, я не ебу как эти звёздочки вставлять сюда.
>Плюс не совсем понятно, а нахуя это нужно
Те же монады и функторы нормально без кайндов не реализовать. Зачем нужны монады и функторы и попытался вкратце объяснить выше. В общем всё сводится к тому чтобы писать более обобщённый код.
Ну можно конечно какой-то другой синтаксис придумать, без стрелочек со звёздочками. Стрелочки здесь потому что те самые дженерики которыми мы каждый день пользуемся с точки зрения того же Haskell - функция над типом. Ну то есть когда мы пишем тип вроде List<Int> мы как бы вызваем (в compile-time, разумеется) функцию List с параметром Int.
В http://rurust.github.io/rust_book_ru полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
>полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
И что в ней странного?
Все так всегда делают.
>Я не понял насчёт параллелизма, он что реальные потоки создаёт?
Ты что реально слабоумный дебил?
>А корутины где?
Не завезли, ибо сложно и нужон сложный рантайм.
Заместо есть tokio и фьючерзы.
А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
>А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
Асинхронно.
Через tokio либу.
Но с такими вопросами, лично тебе, никак.
Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
Архитектура ПК - ассемблер - си.
Да и не для раста то-же нужно.
Не в 6/9 а в 3/9, при этом сливает Си в 8/9,
что какбы говорит нам о качестве кода на плюсах в этих бенчмарках.
>И что в ней странного?
>Все так всегда делают.
Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.
>>976836
>
>Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
>Архитектура ПК - ассемблер - си.
Сразу видно теоретика.
>>976842
>Там выразительность на уровне С++
Так с++ довольно выразителен, если сравнивать с джавой или го.
А теперь приведи пруфы того, что Rust делает гарантированно безопасный код.
Он не слышали про количество ядер прост
>Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.
Любой недурак, знает, что плодить потоков больше чем ядер ЕСТЬ смысл в определенных задачах.
И потому проводит тесты производительности в разных конфигурациях.
>Сразу видно теоретика.
Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.
>ООП все, кто связан с программированием, знают
Сижу на програмаче, следовательно я связан с программированием. я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные), следовательно это твое утверждение ложно.
Первая посылка ложна, ты не связан с программированием. Ты хлебаешь борщи и участвуешь в срачах.
Ты как минимум очень ограниченный человек, который имеет ноль интереса к своей профессии. К программированию ты действительно имеешь мало отношения, ибо не имеешь понятия о концепциях, принятых в большинстве современных языков, даже если они чем-то плохи.
>я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные)
То, что ты не писал с ООП подходом, что кстати сомнительно, еще не означает, что ты не знаешь ООП.
Тем более, что ты
>Сижу на програмаче
И минимум что-то читал тут о ООП.
>следовательно это твое утверждение ложно
Увы, но твои аргументы инвалид, и логический вывод мягко говоря сломан.
Что косвенно свидетельствует о твоей недалекости в целом, и в отношении процедурных\функциональных языков в частности.
Это издержки любой централизованной иuild системы.
Я как вижу эти зеленые надписи про downloading-compiling, так сразу чувство, что сейчас начнется какая-то мясорубка с кишками и кровью, больно это напоминает руби, а я в свое время наебался с последним, когда для запуска одного скрипта нужна тысяча гемов ну или хз сколько и что-то всегда ломается. При этом я был не разработчиком, но конечным пользователем тех скриптов и с того времени руби для меня - ругательство.
Лучше, конечно, тащить все зависимости в проект и устраивать кровь с кишками с помощью вендоринга, а потом сидеть по 5 лет на старой версии библиотеки, которая течет и работает хромая.
Карго безальтернативно устанавливается в $HOME/.cargo, так пускай складывает либы в ./cargo/lib как rlib.so.1.2.1, а не компилит для каждого проекта по 200 мб
Это растц релейтед проблема.
Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
https://github.com/AngryLawyer/rust-sdl2
Вот это получилось собрать на
cargo-0.17.0-nightly (f9e5481 2017-03-03)
rustc 1.16.0 (30cf806ef 2017-03-10)
Ну хотя бы SDL работает, можно попробовать что-то сложнее факториала сделать
>Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
>А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
Стократно плюсую.
Жаль, линуксоидам застрявшим во временах 2мб винчестеров, этого не понять.
>>977211
Написал хуйню @ сам себе приплюсовал.
В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Но гоферу не понять.
Хотя гау то же делает с своей GOPATH, у явы каждый пакетный менеджер тащит миллиард зависимостей для себя, в дотнете как в расте, а у динамикопитушков вообще каждый проект — своё хранилище зависимостей.
Растц может зафейлиться если ему подсунут rlib'у с той же версией что надо, но скомпилированную растц недельной давности.
Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
Ну, в том же окамле такая же хуйня — но всё сделано в одном хранилище, как предлагает анон выше. Просто попробуй попользоваться такой хуйнёй.
Эти проблемы вроде решает guix
>Но гоферу не понять.
Это ты себя имеешь ввиду, или что?
Речь о rust е идет вообще-то.
>В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Тогда все ок.
>Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
А это не норм нефига.
Нафуфик оно так сделано?
Зависимости должны лежать рядом с конкретным проектом.
https://github.com/rust-lang-nursery/rustup.rs/#working-with-custom-toolchains-and-local-builds
Ну ещё посмотри первый пункт в разделе про переменные среды.
В том что какой-то петушок лезет из своего говно-свинарника с ахуительными советами по архитектуре.
Говорит
Item::A => 'A',
^^^^^^^ expected &Item, found enum `Item`
= note: expected type `&Item`
found type `Item`
Наверно потому что &self.world?
Мне вообще вся твоя затея с Enum-ом тут не нравится.
Может лучше сделать trait Cell с методом test() и передавать туда разные реализации этих cell?
https://doc.rust-lang.org/1.0.0-beta/book/static-and-dynamic-dispatch.html#dynamic-dispatch
Это одна из проблем хаскеля. Там уже и stackage завезли из-за этого, но выглядит это как снепшоты hackage периодические. Как если бы crates.io снепшотили весь целиком и проекты переезжали с одного снепшота на другой. Без этого вообще ад, сегодня компилируется, а завтра майнтайнер мелколибы сломал совместимость на какой-нибудь FreeBSD и сам не заметил.
С cargo есть гарантия, что любой снепшот проекта с какого-нибудь github можно собрать, причем любую его версию, именно с теми библиотеками, с которыми он разрабатывался.
cargo это вообще самое лучшее, что есть в расте вообще, и лучший из менеджеров зависимостей.
ИМХО, эту проблему нужно решать по аналогии с ccache. Пусть все остается как есть, но еще будет незаметный для юзера кеш, куда будет все собранное складироваться, если нужно линковаться в местный билд симлинком. Малоиспользуемые библиотеки пусть вычищаются. Если симлинк из-за этого сломался, можно и пересобрать. В Rust же пилят инкрементальную компиляцию, у нее кеш будет не глобальный ли случайно?
>если бы crates.io снепшотили весь целиком
Принцип иммутабельности as is, чтобы что-то добавить, надо удалить и пересоздать. Все правильно.
@
MUTABLE MORE THAN ONCE
Сколько не читай доки, ничего написать на этом языке не представляется возможным...
Для больше чем 1 мутабельной ссылки есть синхронизационные примитивы, или ансейф, если ты самый умный.
>способ покруче
необязательно именовать поля, можно просто Player(PlayerData), доставать данные - как из кортежа (х.0)
>ничего написать на этом языке не представляется возможным
На Х-ле есть даже специальный блог пост для тех, кто язык как бы осилил, но вообще не вдупляет как написать приложение. Может и для раста такой завезли, поищи.
Хотя самый нормальный совет - читай исходники других проектов.
Как сделать swap или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
Не похоже на хорошую практику, даже Pos(i32,i32) с 0,1 вместо x,y как-то стрёмно смотрится
>Как сделать swap
fn swap<T>(a: T, b: T) -> (Pos, Pos) { (b, a) }
Использовать так:
let (src, dst) = swap(src, dst);
Работать будет с чем угодно. Не благодари.
>или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
Клонировать и так можно через .clone().
А так — просто вынеси self.get() из матча в переменную.
Вообще, нужно сделать руководство для нюфагов на картинках — я хз как еще заимствование объяснять.
Не отвечай этому уебку пока он код не скинет нормально (энивэй твой свап это пиздос в его случае).
>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 parsing
some 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 write
SocketAddr::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.
>вкусовщина
Ну вот сам себе ответил. Не сделают.
Хотя ты всегда можешь сделать язык компилирующийся в раст (или хотя бы бэкэнд к хаскелю).
Плез, в божественном синтаксис охуенен.
Ах да, меня смущает эта задротская зацикленность не неважных вещах.
>some unnecessary run-time parsing
как будто код только и занимается этим и небо и Аллах и тепловая смерть Вселенной зависят от этой оптимизации, в которой говорится в комментариях к релизу.
А ты хотел чтобы они тебе каждые 6 недель ахуенные релизы выкатывали? Такой цикл разработки нужен для вылизвания существующего кода.
А так там вообще куча всего что давно нужно было исправить — синтаксис инициализации структур, синтаксис констант, в стабильный карго наконец-то внесли фьючи, стэктрейсы помещаются в 1 экран.
а с этой новой хуиткой, не тратящей время на парсинг ип, можно писать убер быстрые сканеры диапазонов ип для локалхоста, ну чо ты
C тоже в него компилится. А в гнутом компилире компилится в их GIMPLE.
Ходят слухи, что благодаря своей охуенной системе типов Rust теоретически может предоставлять LLVM информацию, которая позволит производить всякие продвинутые оптимизации. Так что с развитием и Rust, и LLVM вполне возможно, что Rust станет в местами быстрее сишечки/крестов.
Может, за счет убер-системы (которая просто хитро переносит часть рантайма на время компиляции) он будет где-то быстрее С или плюсов, но это лишь частные случаи, где-то и Hsakell быстрее С, такие кейсы любят находить фанбои того или иного языка, но общая картина всегда будет такой, что языки более высокого уровня медленнее С/С++.
Потому что высокоуровневость и скорость разработки всегда меняется на скорость выполнения.
На пыхе ты можешь за 20 минут что-то высрать даже будучи учеником пятого класса, но скорость будет меньше, чем у правильно написанного кода на С, решающего аналогичную задачу.
Причем тут пхп? Я думал мы ллвм и гцц сравниваем. И гцц далеко не везде обгоняет ллвм/цланг.
> высокоуровневость
Что-то мешает компилятору высокоуровневого языка высрать такой же машинный код который высирает гцц?
Есть гцц, уже довольно давно. Какой смысл в этой херне?
Для нового языка проще запилить фронт для llvm, чем пилить новый компилятор с нуля
Подальше от Штульмана.
Ну он уже местами быстрее судя по базовым тестам.
Тогда почему кланг уже разъебывает гцц?
http://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=1
Если говорить про php подобные, машинный код можно сделать только если вставить в бинарник интерпретатор целиком
Ору с тебя. LLVM IR не высокоуровневее чем IR GCC (не помню как там он называется). Вся разница в том что инфраструктура LLVM более современная, универсальная и лишённая некоторых легаси-косяков GCC.
Ещё раз, для тупеньких: LLVM IR - не высокоуровневый язык. Изначально вся инфраструктура Clang + LLVM вообще создавалась для компиляции C, и уже потом LLVM стали использовать как бэкенд для других языков.
>Тогда почему кланг уже разъебывает гцц?
Найти пример, где кто-то кого-то разъебывает всегда можно.
Например, самый быстрый сервер статических файлов написан вроде на D или Haskell, но это не значит, что в целом эти языки быстрее С (язык с GC в принципе не может быть быстрее языка с ручным управлением памятью).
>>982283
Высокоуровневый язык - это Rust.
LLVM - это просто высер. Для хипстеров штучка, понимаешь? Поигрался, м.б. написал свой компилятор для своей джавы, где вместо слова class будет хуй и тип не перед, а после идентификатора.
Охуеть, какой - то чухан мало того, что несёт какой-то бред, да еще использует слово "хипстер", как оскорбление. Ты, блядь, и хипстера поди не видел в своём залупинске, а туда же. Аргументации 0 (ноль), компетенции 0 (ноль), а лозунгов и пафоса на серьезных щщах на весь тред хватит.
А какая тебе нужна аргументация, если весь механизм владения-заимствования - это подпорка для скорбных умом, у которых на языках с ручным управлением памятью будут утечки. Этим товарищам на джаве бы писать, но они хотят ощутить себя системными архитекторами и вот для них придумали эту игрушку.
Никакой хипстер не осилит раст, это вообще язык не для людей. С++ немного проще из-за мутабельности и слабой типизации, пока не дойдёшь до шаблонов, которые тоже не для людей и никто их не понимает полностью.
>это вообще язык не для людей
Что в нем сложного?
Понял заимствование, смарт-указатели и все.
Проще, чем ловить секфолты.
> С++ немного проще из-за мутабельности
Так сложно вставить слово mut, да?
>слабой типизации
Слабая типизация создает только проблемы.
Но там не один пример, а целая кипа примеров, где гцц сосет. Так что уж просто это скорее тенденция, чем исключение.
>вот для них придумали эту игрушку.
Эта игрушка по скорости ни чем не уступает крестам, но при этом меморисейф, что является ключевой килер фичей.
Блять, додик, что ты вообще делаешь в программировании? Это тоже самое , что shared, unique и weak указатели.
Хипстер - это как раз тот, кто с умным видом втыкает в "современные технологии". Примеры говна, которое любит хипстота - это Scala (и обязательно с экстенсивным использованием scalaz), кложа и т.д. При этом ладно бы они действительно что-то в этом понимали, а то большей частью скидывают друг другу статьи на хабре "как функциональное программирование помогло нашей компании".
И Rust примерно для таких, кто хочет играться с байтиками, но на сях без секфолтов не может hello world написать.
>>982388
>Эта игрушка по скорости ни чем не уступает крестам
Ахахаха.
>>982385
Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Обычно в таких примерах просто специально оставляют простор для оптимизации и потом говорят, что их (язык, компилятор) быстрее.
>Это тоже самое , что shared, unique и weak указатели.
Мы придумали проблему а теперь будем с ней бороться.
Ты где толстый рантайм у раста увидел-то?
Ну ты-то явно ни Rust и C++ дальше хелловорода не знаешь. Как будто в Rust нет мутабельности, лол.
Ох уж это раздутое чсв. Все такие охуенные, код сразу без ошибок пишут. Статическая типизация им не нужна, потому что зачем нам типобезопасность, мы и так код правильный пишем. Система владений-заимствований нам не нужна, потому что зачем нам безопасность работы с памятью, мы и так код правильный пишем. Охуеть просто, иди подойди к зеркалу и подрочи на себя, раз ты такой охуенный кодер.
>и тип не перед, а после идентификатора.
Я тебе сейчас секрет открою, но везде так делают потому что:
а) Компактнее записывать модификаторы (вместо всяких const out int hui просто var hui);
б) Легче и быстрее парить;
в) Лаконичнее живёт с выводом типов.
Даже в твоём говне так это работает.
>>982463
>в говнище вообще нет возможности контролировать указатели, нету и проблемы, кококо
Жеманный опять трет топит, луль.
Ага, а потом годами выскребают зеродеи.
Дело не в осилил или не осилил C/C++, а в том что работать с Rust тупо приятнее (не говоря уже о том что безопаснее). Это касается как самого языка (клёвая система типов, нормальный match, if/match as expression, модули, гигиенические макросы и т. д.), так и инфраструктуры (нормальный пакетный менеджер, например). Если есть возможность использовать инструмент который использовать приятнее, то что в этом плохого, м?
LLVM - это охуенно мощная инфраструктура, в разработку которой было положено дохуища человекочасов. И сейчас LLVM гораздо более зрелая и удобная в использовании система, чем GCC. Начиная с того что LLVM легче расширяется и имеет более внятный дизайн и заканчивая тем что у LLVM в принципе есть внятная документация.
Скажем если кому-то нужен компилятор той же сишки для кастомного процессора (и это не выдуманная мной задача), то самый адекватный вариант - скачать сорцы LLVM, открыть документацию по написанию бэкендов к LLVM и сесть писать бэкенд. Документация вполне ок, хотя информации конечно меньше чем для написания фронтендов.
Ты самое главное забыл — LLVM лицензирована MIT, а не ЖоПаеЛью, и Шульман со своими юристами не придёт к тебе если ты решишь продавать и распространять свой софт не открывая исходников.
ставлю тип после идентификатора, законом не запрещено, парсить на 95% быстрее и легче
Иди лучше к жавадаунам, они до сих пор пишут AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());
Скоро у пайка начнется деменция и в говне настанут такие же темные времена.
>AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());
Охуенно же.
Нет, и в ближайшие 3-4 года до жявы 10 не предвидится.
Двачую этого.
Ну был и есть ATS. Официальный саппорт и форум на епонском, доков 0, только примеры факториалов, на языке писать без выдрачивания теорката нереально (он куда сложнее хачкеля, больше похож на теоремпрувер чем на яп) — тайная военная разработка страны восходящего солнца. Теперь как сам думаешь, чем?
Тебе видать какие-то нехорошие жабисты попались, когда еще маленьким был, вот и осталась фобия хотя если судить по тому что пишешь, тот еще джуниор. Можешь показать на проекте в гитхабе, за какие места тебя трогало?
Помню помню, этот язык с нескушными идентификаторами вроде viewt@ype и с различным цветовым кодированием разных категорий кода.
Даже порывался учить, но по модулю ебанутости автора не дотянул.
Каноничные - да, но надо же орать, что не хипстор и что твоя технологие неебаться инжынерная и ты прямо байтики ксоришь и у тебя все на указателях, естественно, умных, а еще иммутабельность и вообще.
Я скажу больше, у каждого свои представления о каноничных хипстерах. Границы определяемого расширяются с изменением определяющего. Вот у нас в компании, уж настолько настолько хипстерский народ (разной временной градации от протохипстеров с зеркалками до постхипстеров с подворотами итп, а все туда же - нет, да всплывет жалоба на хипстеров. Хоть ультрафильтр заводи.
Этой какой-то цпп с синтаксисом раста. С кучей ошибок и, как результат, даже не скомпилируется.
Это новый стиль жеманного, постить код в скриншоте и не реагировать на ответы, выше посмотри.
У нас тут вместо треда какая-то игра в мафию, только вместо мафии жеманный, лул.
>>964005
Нахрена вам IDE, долбоёбы? Код пишут с помощью рук и мозга в первую очередь. Если проект насколько запутан, что в нём нельзя ориентироваться без IDE - это говнокод, который надо выкинуть нахуй. Собирать нужно в консоли, текстовых редакторов с подсветкой для раста предостаточно, во многих даже автокомплит и линтинг есть.
Ебать жеманного прорвало.
У говна иде того же качества, что сейчас у раста. а плагин для жидеи кстате лучше гогланда, или как минимум его билда месячной давности
Да тут пол-треда, если не больше - "жеманные". Как мимо пройти и не зайти, поглумиться.
Ты долбич?
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? В офф. документации, не объяснен доступным языком этот момент.
Читай файл в успешной ветке матча, и замени p на pa, тебе же компилятор прямо написал.
match p {
Ok(pa) => pa.read_to_string(& mut buffer),
Err(_) => main(),
}
Теперь такая ошибка:
main.rs:27:2: 30:3 error: match arms have incompatible types:
Насколько я понял match при этом должен возвращать одинаковые по типу значения, но как это сделать, я не знаю.
https://play.rust-lang.org/?gist=78cdf63a1d850b61ea2a5c909547c065&version=stable&backtrace=1 match версия. Ветки match обрабатываются без проблем, потому что обе возвращают нихуя.
https://doc.rust-lang.org/book/if-let.html тут подробнее про if let
Так даже лучше. Спасибо, что разъяснил.
>thread 'main' has overflowed its stack
>fatal runtime error: stack overflow
Мало того что код говняный (из-за ублюдского синтаксиста, твоей вины нет), так ещё падучий.
> Err(_) => main()
Ты что больной?
Запускай свою хуйню в цикле и выходи в ветке ok, а в альтернативной выводи сообщение об ошибке.
Иначе ты просто уйдешь в рекурсию. И вообще, какой придурок может рекурсивно вызывать main, сколько живу а такого наверное не видел.
Юзаю плагин для eclipse, все вполне нормально автокомплитится.
>челик пытается открыть файл которого нет
>потом вызывает эту функцию (причём точку взода) бесконечно
Ору бля.
В говне такое тоже не сложно делается, расслабься.
Плагин для идеи уже в отличном состоянии — всё, от рефакторингов до автокомплита и линтинга с отслеживанием лайфтаймов уже есть (только вложенные макросы парсить не умеет), скоро даже дебуггер даже будет.
Алсо, есть RLS если не хочешь жаваподелий, с примерно тем же функционалом (но вообще не работает с макросами и анализов, нужно поебаться с настройкой и у линтера явно меньше).
>В говне такое тоже не сложно делается, расслабься.
Такое можно сделать почти на любом языке, нужны только кривые руки, ничего более.
Я знаю, что использовать рекурсивный вызов функции является злом, но никак не могу понять как сделать так, чтобы при неверном вводе предлагалось ввести текст заново, а не делать panic.
https://doc.rust-lang.org/book/guessing-game.html самый древний туториал по расту как раз это и объясняет.
Я же вроде написал - делай это в цикле и выходи с него при успехе.
Да нет, долбоёб, он твоим больным мозгом генерируется. Сначала ты стёк переполнял рекурсией входной точки, теперь в заголовки конфигово томла пихашь куски кода.
иди нахуй со своим NT-говном и миниксом с овердохуя сисколлов. в редоксе ровно 31 сисколла, там даже сокеты через open создаются, как файлы. больше не нужно.
Ну так это ты и есть, лол.
Минутка грамотности: генерируются .lock файлы, а не томлы, ti obosralsya.
И зачем нам помогать тебе заниматься фистингом?
зависимости на библиотеки нужно добавлять в Cargo.toml своего проекта, cargo install ставит некоторые програмки типа rustfmt и плагинов под cargo, но не либы
Друзья, раст мертв при рождении , переходите лучше в Golang тред, пока не поздно!
golang
>gc
>дженериков нет
>мутексы не связаны с данными, которые они охраняют
>проброс ошибок по стеку анальная мука
>неюзабелен для написания драйверов
>нет паттерн матчинга
>система типов какая-то параша
>компилятор не может доказать отсутствие одновременного доступа к не-атомным данным
>код сложнее хеловорлда на голанге похож на вырвиглазный кал
>...
идеальный язык для вебмакак. что в голанге хорошего, это то, что он простой и что в нем искоробки forkjoin
Ваше мнение очень важно для нас
На питоне или жсе нахуячь. В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой (которая очень нужна в твоей 2д залупе). а вообще, иди ешь торты.
>В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой
То, что мне и нужно.
HelloWorld готов, теперь можно и изъёбствами языка обмазаться.
пишу в свободное время игрушку поигратся на вулкане на расте, раст таки заебись, советую
И чем он лучше lein?
На большинстве статически типизированых языков сборка это ад. Либо у тебя длиннющие и неудобные makefile.am, либо cmakefiles.txt, где забываешь уже через полгода что для чего инклудил. В мире java это хотя бы имеет более человеческое лицо, спасибо jetbrains за труды.
Жява-энтерпрайз-оверинжиниред-говнище.
>>994514
Ты как нибудь с окамлом поиграйся. Поверь, это пожалуй самый ахуительно собирающийся язык.
>>994603
При чём тут статика-то, долбоёб? Это у всех компилируемых языков с легасиговном вместо системы сборки такая проблема.
В тех же плюсах (священное поприще легасиговна) дохуя билд систем вроде Qbs и meson, которые по большому счёту не сильно-то и уступают cargo.
Ну я пока для упражнений из K&R накатал скрипт на петоне который генерирует ниндзя-файл. Очень удобно и прозрачно, вообще в последнее время часто вместо систем сборки использую самописные скрипты, потому что мне нравится полностью контроллировать процесс сборки. Вот в leiningen я не чувствую что я вообще что-то контроллирую, какая-то непонятная медленная не работающая так как мне нужно магия. Попробую в Boot вкатиться, говорят, он получше.
Вот огромная проблема всех этих крестовых билд-систем в том, что нет какого-то единого репозитория пакетов, как в расте. Так что или клади зависимости в git submodules, или довольствуйся теми пакетами, которые есть в репозитории используемой билд-системы, или сам упаковывай пакеты, или я не знаю что ещё. В расте же сделали сразу по-человечески, и это охуенно.
Дык я не спорю, я это говорил к тому, что жто не статики проблема.
Есть же кроме этого тягатели зависимостей с гитхаба по тегам и версиям.
Скоро ещё мб осилят подход как в том же гредле — указывать источники зависимостей.
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()
Мудило с картинками, ты опять на связь выходишь?
>что для &&{integer} нет оператора ==, добавил две звёздочки - работает
Наверно потому что звездочка перед идентификатором означает разыменование указателя/ссылки.
ллвм на цпп. растц на расте
Потому что ты - спермовор у спермы свой особенный и единственный линкер и набор библиотек (всякая символы для системных вызовов, динамические библиотеки и прочая хуйня без которой ты буквально хэловорд не соберешь).
Он собственно требуется всеми известными мне компиляторами (врде д, пони, окамла). Разве что го-велосипедисты написали свой, который срет бинарями хэловордов по 10 мб на которых любой дизасемблер падает с ООМ.
>>1003376
>который срёт бинарями хэловордов по 10 мб
>и хуй тебе а не нормальный dead code elimination, будем бить по рукам за неиспользованные импорты
>хуй тебе а не link time optimization, profile guided optimization, межпроцедурный анализ и всё остальное, прямо или косвенно требующее поддержки линкера
Да мне это тоже нравится, братишка.
Мимо эйфеле-господин
Мимо-цпп-боярен
Ну да, не то что в расте. Можно пельмени сварить там, или чай заварить, пока всё линукется - разработчик никогда не останется голодным
>И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.
Ты бы ещё рассказал ему что си имеет текстовый препроцессор, каждый раз заново парсит все инклуды и просто не укладывается в какой нибудь LL(1) с лукапом в 1 символ как его говно, а расту для чека каждого лайфтайма нужно обходить графы всех затронутых функций и объектов для каждой хуитки и заниматься прочим статическим анализом.
>>1005490
Тем временем, в говне из модуля функции, структуры и (!) переменные (!) импортируются по регистру первой, сука, буквы. Повар, какого хуя ты вообще рот открываешь?
Всякие пидоры на стэковерфлоу пишут "НУ ТИП ЭТ ТЫ ПРИВЫК К С++!!!))) В РАСТЕ ВСЁ ПО-ДРУГОМУ!))) ПЕРЕМЕННЫЕ ТИПА НЕ МЕНЯЮТСЯ))"
Какого хуя, если variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени. Какого хуя всё так тупо?
Если бы Страуструп стал женщиной и его отымел Милнер, то вместо C++ появился бы Rust.
В общем, я что сказать хотел... Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
const в расте — это как дефайн в сях, просто подставляемое значение.
И var в русте нет, здесь только let, шо как бы намекает дебилам как ты.
>Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
Все ML-и дохлые, к сожалению, даже окамл, который хз сколько лет развивают. Он сейчас только с точки зрения научного интереса тыканья палочкой.
Д — я надеюсь когда нибудь его зотя бы до состояния раста допилят, языку десять лет а он сырой как твоя мать на концерте Маликова.
Он релизнулся раньше чем ты родился, так с того времни никуда не сдвинувшись с SML 97, куда там.
Если хочется ML-я — тут есть окамл который хотя бы развивается, и куча трупов.
Ну кроме окамла ещё F#, но там больше шарпа в смысле парадигмы (хотя сексуальные хачкель операторы вида <><[][——€•^`>> на месте).
> variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени
> во времени
Распространённое заблуждение. Слово "переменная" пришло из математики, где никакого изменения во времени оно не означает. Оно означает что значение может меняться в зависимости от исходных данных (то есть, по-нашему, от запуска к запуску). А вот "константа" в математике - это то, что не меняется вообще никогда, с любыми исходными данными. Собственно, const в Rust это как раз значение известное на этапе компиляции, тогда как значение переменной вычисляется уже в рантайме.
Вот да. А меняться во времени это уже к реактивному программированию.
Нормально.
Но как же, господа, ведь математически докококазана безопасность.
>У тебя какой-то галлерный руснявый тырпрайз.
Нет никакого другого тырпрайза.
Ты бы пообщался с тырпрайз работниками из штатов.
Поголовно всем на все посрать. Свиноматки в декрете работающие(системным аналитоком) из дома и нехреа непонимающие в происходящем.
Жрущие во время митинга по скайпу и успокаивающие там же ребенка.
Индусы (настоящие американцы).
И прочие прелести.
Здоровому человеку в этом всем говне делать нечего.
Можно поместить себя в клетку и так прятаться от собаки, а можно собаку поместить в клетку.
Не знаю, занимаемся промышленной разработкой небольшой командой и ус не дуем. Решения выбираем прагматично, код пишем рационально, не полагаясь на карго-макакинг.
>занимаемся промышленной разработкой небольшой командой
И причем тут энтерпрайз?
>занимаемся
Доход поровну делите?
Не, я конечно допускал, что две буквы могут к подрыву привести, но всё же, рассматривал больше как теоретическую возможность, всё же /зк.
Приятно удивлён
Не совсем, Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность). Как бы Rust не старался, плюсы еще долгое время будут жить, а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй. Но, на данный момент, язык дико молодой и, как следствие, сырой.
Ты чё сука ты чё. Раст популярнее и популярнее с каждым днем: вот новость недавняя, даже оракл выпустил приблуды для изолированных контейнеров:
https://github.com/oracle/crashcart
https://github.com/oracle/railcar
Глянуть в код, увидеть - та еще параша, а я зык выбран из соображений - поиграться
>Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность)
Не осилил лайфтаймы. Есть по ним вменяемый тутор?
>а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй
Давно бы уже пошла, если это было бы проблемой.
Есть. Называется практика и ебля в жопу с компилером.
Говорят системе открыть сокет пишут туда
Похоже, придется перекатываться на кресты.
Охуеть теперь. Я и по 2 минуты ждал постоянно потому что в движке было много объектых файлов и пека слабый.
Ржавый?
Очень недружелюбный язык для вкатывания, поэтому просто нет тонны всяких "бот для телеграма на %языкнэйм%"
>С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow
Это значит только то, что он вызывает больше всего вопросов.
>так мало проектов
Завезли бы корутины.
> Это значит только то, что он вызывает больше всего вопросов.
Нет, это они опрос проводили. https://insights.stackoverflow.com/survey/2017
> Завезли бы корутины.
Стекфул корутин, как в Го, не-бу-дет. Копают в сторону стеклесс и асунк/ашаит.
>Нет, это они опрос проводили.
Ах лол.
Любимый в смысле на нем не программируют, но что-то слышали.
Каких это проектов там мало? Каждый Вася Жопин не пилит свой веб фреймворк и бот для телеграма умеющие нихуя?
Болезный?
> 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.
>Болезный?
>> 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 в том же опросе, раста нет вообще.
То есть им не пользуются от слова совсем.
А кучка шизиков на нем кодящих хочет кодить и дальше, что как бы закономерно.
Нативных альтернатив нет, но бизнесу всё равно выгоднее использовать асп.нет, а большинству и пхп сойдёт, так что задач нет.
Давно не заходил, теперь тут
> компиляция занимает секунд 15.
Так тебе программы писать или лабу2 конпелировать?
мимо скала-боярин
Напейсание лаб ныне кличут TDD.
В анус себе перекатись, блять, начинают кодить на Visual Studio и начинаются ебаться в жопу и думать, что компилятор сам по себе выполняет функционал makefile
Причем тут лаба, долбоёб?
На крестах есть инкрементальная сборка, крупный проект первый раз может собираться несколько минут, а потом, когда вносишь изменение в несколько файлов, проект пересобирается уже за пару секунд, т.к. собираются только затронутые объектные файлы. А в расте такого нет, если у тебя в проекте 1000 файлов, а ты изменил 2, при сборке будет собираться полностью.
>>1035358
Какая visual studio, какие makefile, ты чем там объебался?
Я так-то под линуксом сижу и юзаю cmake/clang.
Да, действительно ебу дал, на rust нет инкрементной сборки.
Охуеть, это какой-нибудь проект уровня хрома после каждого патча целый день собирать? Как жить-то?
Делить проект на крейты и жить как белый человек с модульной архитектурой кода, а не заниматься напейсанием индусских монолитных кусков говна на миллионы строк, как это помогли делать миллионам макакусов K&R. Открой исходники серво и посмотри как это делается.
Вообще, ты даже до гугла похоже не добрался — там есть инкрементальная компиляция https://internals.rust-lang.org/t/incremental-compilation-beta/4721 , другое дело что это не плюсы в которых её 2 десятилетия пейсали (и которая точно так же как раньше не работает при изменении предкомпилированных или просто везде используемых заголовков), и пока по умолчанию она не включается.
>Я так-то под линуксом сижу и юзаю cmake/clang.
У тебя там цмейк сам собирать научился, без бэкэнда, поешавший?
>под линуксом
>clang
Вот с этого особо орнул. Ты там как, пользуешься сборками трехлетней давности, или сам собираешь? Я вот представляю уже, как ты после каждого релиза тащишь себе релизную ветку и билдишь ллвм со шлангом по 12 часов с ИНКРЕМЕНТАЛЬНОЙ компеляцией, и ору
Сложно.
А как без системы управления пакетами? Это показатель современного языка. Без этого, это какой-то каменный век.
>как думаете, он сможет вытеснить жаву? Почему?
А нахрена? Rust он крут. Я не думаю, что нужно ставить вопрос именно так. Java все равно будет жить ещё долго, как и сраное php. Ведь его куча говнокода в Ынтерпрайзе. Ну и пусть варятся в собственном соку.
Стоит подучивать что-нибудь по этому параллельно с веб макакетством или все тщетно, если конкретно этим не занимаешься?
t.безработный студент
Все работают над ИИ.
> своеобразное ООП
Потому что это не ООП, люди подгоняют возможности Rust под тугое воображение ооп-ретрограда.
Что ты подразумеваешь под ООП? Если первым словом в ответе на этот вопрос будет "наследование", то сразу иди нахуй.
Ну ты и лох, какое наследование, все знают что ООП - это когда можно методы через точечку вызывать и ИДЕ тебе автодополнение предлагает.
Абстрактную фабрику абстрактных фабрик энтерпрайз фасолин.
Ну вообще говоря так и есть. ООП это всего лишь паттерн управления стейтом, когда стейт лежит рядом с функциями для их обработки в одном контейнере, а программа состоит из кучи таких контейнеров.
> ООП это всего лишь паттерн управления стейтом
Нет, ООП и императивное программирование это ортогональные понятия.
Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
Незнаком с ним. Да и моё утверждение верно для любого мейнстримного языка, будь то Java или C#.
>>1047896
Замени в своей фразе "стейт" на "данные" и получишь более-менее точное определение.
На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта.
> На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта
Я что-то тебя не понял.
Присваивание полей в конструкторе, используется как гарантия того чтобы не было полуготовых объектов, т.е. таких объектов, которые будучи инициализированными, не дают собой полноценно пользоваться. Стейт от этого вообще никуда не девается.
Мимопрохожий.
>Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
ООП это подход при котором отправитель сообщения и адресат никак несвязанны и независят друг от друга, а оба зависят от сообщения.
Суть в переносе связи между модулями на сообщения.
В c# это происходит через интерфейсы.
В с++ через абстрактные классы. (система типов плюсов/джавы превращают ООП в скотское безумие)
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.
ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
>ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки
>>1048620
>но никогда не видел ОО-ориентрованых програм на функциональных языках
Определись наконец, Эрланг ООП или нет?
Всего 2, фунциональное и логическое это частный случай декларативного программирования.
Да хуйня какая-то, всё время прошу показать мне пример и объяснить почему это "ООП" а не сахар для процедурщины (я про вызов через точку). Вон в D можно обычные функции через точку вызывать, ну типа foo(a, b) и a.foo(b) - одно и то же. И шо, резко стало ООП? Да нет, нихуя. Вот объясните мне, где в вызове foo(a, b) стейт, а где не стейт. И почему оба аргумента не могут быть "стейтами".
> ООП в современном виде - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры
Два чая этому господину
Хватит разговаривать с голосами в голове. О каком "синтаксисе конкретного языка" ты говоришь?
Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Что ж, полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). В расте есть куда более адекватный способ переопределения поведения - ad-hoc полиморфизм. Собственно говоря, он есть и в Haskell. Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
> Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме?
Суть ооп - полиморфизм, инкапсуляция, наследование.
> Что ж,
> ненужная хуйня (по той причине что
> ненужная хуйня)
Ясно.
>Суть ооп - полиморфизм, инкапсуляция, наследование.
Ну вот и получается, неследование не нужно, полиморфизм в классических ОО-языках опирается на наследование и потому не нужен.
Что касается инкапсуляции, то её можно рассматривать как сокрытие данных (такая трактовка описывается как неверная в русскоязычной и как одна из допустимых в англоязычной) - и тогда это довольно скучно, полно языков не поддерживающих сокрытие данных, но при это считающихся вполне пригодных для написания ОО-кода; или же можно трактовать инкапсуляцию как механизм "упаковывания" данных и кода, с ним работающего. Тогда опять-таки вопрос, во-первых, о чём речь идёт когда говорят об ОО-подходе в C (где ни наследования, ни полиморфизма, ни полноценной инкапсуляции); во-вторых, что делать с пресловутой проблемой бумаги и пера - paper.write(pen) или pen.write(paper)? Ну и в любом случае инкапсуляция (в смысле "упаковки") выглядит именно как незначительная надстройка над процедурщиной, сопровождающаяся как правило соответствующим сахарком.
Эрланг это язык программирования. Возможно это сложно понять, но язык и "парадигма" - не одно и то же. Если честно, я не знаю какую часть Эрланга занимают акторы, никогда с ним не работал. Но, например, тот код что я видел и писал на Акке (именно работу с акторами), функциональным назвать невозможно, а вот ОО - вполне.
>>1049414
Ты прочитай документ по ссылке, не ленись, ума наберись.
>полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня).
Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.
> адекватный способ переопределения поведения - ad-hoc полиморфизм.
ad-hoc полиформизм - не true полиформизм. True - параметрический.
> почему это "ООП" а не сахар для процедурщины
Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.
> Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
Это значит лишь то, что элементы ООП проникли в функциональщину, ОО языки несут в себе примесь функциональщины, при этом никто не считает их функциональными.
> что делать с пресловутой проблемой бумаги и пера
Доябываться до заказчика, пока не будет ясно какая система должна получится в итоге. Получив представление строишь наиболее очевидную (предсказуемую, скучную) систему.
> наследование - ненужная хуйня
Бтв, с этим не согласен. Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом. Только не надо пихать во все поля наследование. Это скальпель для построения иерархии типов, yj в жизни обычно хватает молотка в виде пары десятков заезженных паттернов.
> Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.
Я и не говорил, что полиморфизм не нужен. Я лишь сказал, что тот полиморфизм, о котором обычно идёт речь в котексте ООП (т.е. полиморфизм подтипов) и который завязан на другой "столп" ООП - наследование - не нужен. Против ad-hoc и параметрического полиморфизма ничего не имею, даже наоборот, считаю что это очень нужные концепции. Только вот когда говорят о полиморфизме в контексте ООП обычно имеют ввиду не дженерики и не трейты/тайпклассы.
> ad-hoc полиформизм - не true полиформизм. True - параметрический.
Я же говорил про способ переопределения поведения для разных типов. Параметрический полиморфизм позволяет лишь определить одно поведение для разных типов, а не разные поведения для разных типов.
> Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.
Так, а вот это уже интересно. До сих пор в треде никто inversion of control не упоминал. В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.
>>1050047
>Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом.
И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?
> Это скальпель для построения иерархии типов
И зачем оно в реальной жизни может понадобиться? Точнее, в каких ситуациях оно может быть удобнее, чем подход того же Rust?
И да, diamon inheritance - не единственная проблема наследования. Другая проблема состоит в железобетонности иерархий типов, построенных наследовании, другими словами - в том что они очень плохо расширяемы.
> И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?
Взяли и выпилили множественное наследование, лол. Если мы говорим о 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 полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
> И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?
Взяли и выпилили множественное наследование, лол. Если мы говорим о 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 полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
> Взяли и выпилили множественное наследование, лол
Так отлично, а что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
> Выборка Human из Unit возможна из-за наличия иерархии типов
Ну, всё то же самое можно сделать с помощью trait objects. Ну то есть принцип тот же, только без наследования реализации, только наследование поведения.
> Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение.
Ну для этого нужна поддержка рантайм-рефлексии, это хак)
> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
Я непойму, ты хочешь чтобы я тебе википедию перерассказал, или что???
https://ru.wikipedia.org/wiki/Ромбовидное_наследование#.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
Так ты то говоришь что проблему diamond inheritance решили, выпилив множественное наследование, то кидаешь ссылку на список хаков которые кое-как решают эту проблему, и все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.
> А если ты не растаман, и у тебя нет trait objects, тогда что?
Ну мне кроме сишки в голову не приходит языков без поддержки динамического диспатчинга. Никто не мешает сделать всё тоже самое на тех же Java и C#. Ну да, кое-где нет интерфейсов как отдельной сущности (в C++ например) и там придётся использовать "наследование" как механизм языка, но при этом по-хорошему все равно надо наследовать не реализацию, а только поведение (как это у крестовиков, pure virtual inheritance?).
> По-хорошему все равно надо наследовать не реализацию, а только поведение
А что делать с интерпретируемыми языками, опирающимися на duck typing, такими как ruby, в которых, в mixin'ах, реализация не отделяется от поведения?
> все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.
По моему скромному мнению, множественное наследование не нужно. Однако, есть языки где ситуацию с что делать когда одиночным наследованием не обойтись решили вот так, через 'хаки', если угодно. Этот ответ показался мне неполным, т.к. есть и другая категория языков - где мн. наследование выпилили, там я допонил чуть-чуть.
Как из всего этого вытекает вопрос о том, что наследование вообще не нужно, чучхе не понимать.
---
> Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.
Я с тобой согласен в том, что связи удобнее описывать не через наследование. С другой стороны, по Барбаре Лисков иерархия классов упрощает проверку наличия этих связей, и в этом и есть ценность наследования.
Объясните мне, аноны:
https://github.com/sfackler/rust-postgres/blob/d374641ecb584bb668fa8e7a10d0f593a5c35ca2/src/io.rs#L24
Строки 29-36, почему в match не указаны неймспейсы? Почему не MaybeSslStream::SslStream? Там ведь нет use.
А нахуя ты смотришь какой-то коммит трёхлетней давности? Сейчас такое не скомпилируется.
Наткнулся на код и даже не заметил, что это древний коммит, лол.
Вы видите копию треда, сохраненную 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.