Этого треда уже нет.
Это копия, сохраненная 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
23 Кб, 209x208
Язык, который существует уже не один год. Язык, который заинтересовал меня из-за скорости выполнения, кроссплатформа, безопасности и возможности делать вещи как в высокоуровневых языках (ООП, мощные макросы, даже не знаю, как сказать). И вот у меня к вам вопрос: как думаете, он сможет вытеснить жаву? Почему?
Также открываем здесь его обсуждение, с возможностью отвечать на ответы.
Также открываем здесь его обсуждение, с возможностью отвечать на ответы.
>>956909 (OP)
Что можно сделать на расте чего нельзя на С?
Что можно сделать на расте чего нельзя на С?
>>956916
Слишком толсто
Слишком толсто
>>956909 (OP)
D - пизже.
D - пизже.
>>956915
Наверное, только потому, что мне идеология компиляции нравится больше, чем какая-то виртуальная машина, хоть она в конечном счете имеет нехилую оптимизацию. LLVM уже не мало так платформ покрыл. Еще, жава много памяти ест, если сравнить с аналогичной программой на C/C++/Rust/томуподобное
Наверное, только потому, что мне идеология компиляции нравится больше, чем какая-то виртуальная машина, хоть она в конечном счете имеет нехилую оптимизацию. LLVM уже не мало так платформ покрыл. Еще, жава много памяти ест, если сравнить с аналогичной программой на C/C++/Rust/томуподобное
>>956954
Посмотрите на этого эксперта сделавшего laba10.exe
В реальности от наследования больше проблем чем пользы.
Посмотрите на этого эксперта сделавшего laba10.exe
В реальности от наследования больше проблем чем пользы.
>>956916
Слишком много заебств в расте с видами указателей и механизмом владения. На джаве писать намного проще и как следствие намного легче найти людей, которые её знают. Там где используется джава производительность всех устраивает и получаем, что раст нахуй там не нужен. Проблемы создает, а бонусы преподносит слишком маленькие. Нет, я очень рад этому языку. Наконец-то появилась альтернатива мерзким плюсам, но вот только с ними он и может конкурировать. Более высокоуровневые языки он не потеснит никогда.
Слишком много заебств в расте с видами указателей и механизмом владения. На джаве писать намного проще и как следствие намного легче найти людей, которые её знают. Там где используется джава производительность всех устраивает и получаем, что раст нахуй там не нужен. Проблемы создает, а бонусы преподносит слишком маленькие. Нет, я очень рад этому языку. Наконец-то появилась альтернатива мерзким плюсам, но вот только с ними он и может конкурировать. Более высокоуровневые языки он не потеснит никогда.
>>956969
В Си надо быть крайне внимательным, работая с памятью, указателями и т.п. Так и стараются. Тем не менее, человеческий фактор всегда допускал там ошибки. Здесь (в расте) ты либо будешь послан нахуй компилятором, либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
В Си надо быть крайне внимательным, работая с памятью, указателями и т.п. Так и стараются. Тем не менее, человеческий фактор всегда допускал там ошибки. Здесь (в расте) ты либо будешь послан нахуй компилятором, либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
>>956962
В реальности люди комбинируют несколько подходов исходя из задачи.
В реальности люди комбинируют несколько подходов исходя из задачи.
>>956967
А если через пару годиков под раст будет множество либ под любые нужды? Примерно как сейчас в жаве... В конце концов, там свои фичи, тут свои и время изучения не сильно разное
А если через пару годиков под раст будет множество либ под любые нужды? Примерно как сейчас в жаве... В конце концов, там свои фичи, тут свои и время изучения не сильно разное
bamp
>>956946
ООП местячковый мем в снг.
ООП местячковый мем в снг.
Наследование - ничто, миксины - всё.
>>956976
И чем это лучше сегфолта? Исключения хоть можно обрабатывать?
> либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
И чем это лучше сегфолта? Исключения хоть можно обрабатывать?
533 Кб, 1600x1200
На самом деле рыночку действительно нужен инструмент который позволит создавать кросплатформенные решения с низким оверхедом по производительности/памяти и без сборщика мусора, но на котором смогут писать миллионы лемингов за дёшево.
Что нового предлагает Rust, для решения этих проблем?
Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Без этих метрик нет смысла что-то обсуждать?
Я уверен, что раст тоже найдёт свою нишу, но однозначно это будет на Ынтерпрайз или web бэкэнд. Возмно, системщина и узкопрофильная прикладуха,возможно ембед, но не ололо контроллеры, а линукс борды. Но для эмбеда нужна спрос и поддержка корпораций, что врядли
Что нового предлагает Rust, для решения этих проблем?
Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Без этих метрик нет смысла что-то обсуждать?
Я уверен, что раст тоже найдёт свою нишу, но однозначно это будет на Ынтерпрайз или web бэкэнд. Возмно, системщина и узкопрофильная прикладуха,возможно ембед, но не ололо контроллеры, а линукс борды. Но для эмбеда нужна спрос и поддержка корпораций, что врядли
>>957136
Реальные тесты производительности? Ну это уже по каждой конкретной задаче. Вот тут видим, что на бенчмарках( не отображают реальный мир), раст выигрывает c++ в 6/9 тестов
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp. Не забывай, что для раста не написано много ключевых оптимизаций, что есть у крестов, но вот растовская система типов позволит в будущем реализовать более агрессивные оптимизации, которые не возможны на c/c++, да и с каждым обновлением LLVM раст становится всё лучше.
Таких точно нет, всё же на расте никто не пишет, лол. Позволю себе с дивана предположить, что раст в этом лучше т.к. большинство ошибок с++, которые приходится постоянно дебажить, находятся в расте на этапе компиляции. Возможно, если ты йоба-сеньйор с 20+ годами опыта плюсов, то ты не заметишь разницы в скорости разработки, но вот во всех остальных случаях, полагаю, раст сделает c/c++
>Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Реальные тесты производительности? Ну это уже по каждой конкретной задаче. Вот тут видим, что на бенчмарках( не отображают реальный мир), раст выигрывает c++ в 6/9 тестов
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp. Не забывай, что для раста не написано много ключевых оптимизаций, что есть у крестов, но вот растовская система типов позволит в будущем реализовать более агрессивные оптимизации, которые не возможны на c/c++, да и с каждым обновлением LLVM раст становится всё лучше.
>сравнения сложности разработки,
Таких точно нет, всё же на расте никто не пишет, лол. Позволю себе с дивана предположить, что раст в этом лучше т.к. большинство ошибок с++, которые приходится постоянно дебажить, находятся в расте на этапе компиляции. Возможно, если ты йоба-сеньйор с 20+ годами опыта плюсов, то ты не заметишь разницы в скорости разработки, но вот во всех остальных случаях, полагаю, раст сделает c/c++
>>956909 (OP)
Компилятор не поддерживает Windows XP (хотя вроде может исполняться, но с какими-то ключами), хотя поддержка "Embedded Industry" (в ваших банкоматах и прочих) есть до 2019 года.
Анон кидал ссылки на веб-серверы, крайне там что-то все уныло.
Мне интересно, в такой модели памяти - память в долгоживущем приложение не будет фрагментироваться?
Нет. Тут даже Го не смог. Джава это сформировавшиеся индустрия, ее даже засахаренные скала и котлины потеснить не могут, хотя те на jvm.
>кроссплатформа
Компилятор не поддерживает Windows XP (хотя вроде может исполняться, но с какими-то ключами), хотя поддержка "Embedded Industry" (в ваших банкоматах и прочих) есть до 2019 года.
>скорости выполнения
Анон кидал ссылки на веб-серверы, крайне там что-то все уныло.
Мне интересно, в такой модели памяти - память в долгоживущем приложение не будет фрагментироваться?
>вытеснить жаву? Почему?
Нет. Тут даже Го не смог. Джава это сформировавшиеся индустрия, ее даже засахаренные скала и котлины потеснить не могут, хотя те на jvm.
>>956912
На С в теории можно все, не зря же в нее компилятся большинство скриптовых языков. Другое дело что создать что-то большее чем драйвер на одном только С врятли получится, а даже если и получится то поддерживать это будет пиздецово. А в расте главная фишка что он безопасен и он строг к синтаксису - т.е. у всех будет более менее одинаковый код и при том гарантированно безопасный, что поможет избежать обсеров как с OpenSSL, когда выяснилось что весь мир годами пользовался дырявым софтом.
На С в теории можно все, не зря же в нее компилятся большинство скриптовых языков. Другое дело что создать что-то большее чем драйвер на одном только С врятли получится, а даже если и получится то поддерживать это будет пиздецово. А в расте главная фишка что он безопасен и он строг к синтаксису - т.е. у всех будет более менее одинаковый код и при том гарантированно безопасный, что поможет избежать обсеров как с OpenSSL, когда выяснилось что весь мир годами пользовался дырявым софтом.
>>957260
Сложнее C++ в принципе сложно сделать. В язык накидали фич не для решения конкретных проблем, а выбрали их рандомно, что вылилось в плохой дизайн языка.
Сложнее C++ в принципе сложно сделать. В язык накидали фич не для решения конкретных проблем, а выбрали их рандомно, что вылилось в плохой дизайн языка.
>>956941
Там есть множественное наследование поведения — не реализации. То есть интерфейсов — не классов.
Там есть множественное наследование поведения — не реализации. То есть интерфейсов — не классов.
>>957136
Ну уж точно не "миллионы леммингов и дешево". Rust сложнее С++, там как раз фишка в том, что сложность разменивается на стабильность.
>Что нового предлагает Rust, для решения этих проблем?
Ну уж точно не "миллионы леммингов и дешево". Rust сложнее С++, там как раз фишка в том, что сложность разменивается на стабильность.
>>956932
пример притянут за яйца. любой школьник знает, что эта строка лежит в read-only секции. да и компилятор будет ругаться на каст сonst char к char
короче иди нахуй. сажи треду
пример притянут за яйца. любой школьник знает, что эта строка лежит в read-only секции. да и компилятор будет ругаться на каст сonst char к char
короче иди нахуй. сажи треду
>>957310
два чая
два чая
>>957310
Не рандомно. Каждое решение там вполне осознанное и обдуманное. Другое дело, что их вообще не надо было принимать. Или делать минималистичную сишку с классами или пилить новый язык.
>а выбрали их рандомно
Не рандомно. Каждое решение там вполне осознанное и обдуманное. Другое дело, что их вообще не надо было принимать. Или делать минималистичную сишку с классами или пилить новый язык.
>>957510
Так сделали десятки ебанатов, но взлетел почему-то С++. А теперь поучи датчанина делать языки.
Так сделали десятки ебанатов, но взлетел почему-то С++. А теперь поучи датчанина делать языки.
>>957553
Да блять просто очередная перделка на гихабе, как laba.exe студентов.
А преподносят как готовый продукт.
Насколько я знаю, они его переписывают потому, что архитектура стала не поддерживаемая (казалось бы причем тут гибкость раст).
Да блять просто очередная перделка на гихабе, как laba.exe студентов.
А преподносят как готовый продукт.
Насколько я знаю, они его переписывают потому, что архитектура стала не поддерживаемая (казалось бы причем тут гибкость раст).
>>957585
Да дохуя на самом деле, но к сегодняшнему дню это всё либо осталось в музеях, либо пилится на коленке каким-нибудь Куртисом Ярвином или Терри Дэвисом. Хотя впрочем IBM всё ещё поддерживает z/OS.
>А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.
Да дохуя на самом деле, но к сегодняшнему дню это всё либо осталось в музеях, либо пилится на коленке каким-нибудь Куртисом Ярвином или Терри Дэвисом. Хотя впрочем IBM всё ещё поддерживает z/OS.
>>957610
GNU/Linux идеальная ОСь, BSD годная альтернатива. Остальное просто ненужно.
GNU/Linux идеальная ОСь, BSD годная альтернатива. Остальное просто ненужно.
>>957611
Нужно, просто ты об этом не знаешь: http://www.loper-os.org/?p=284
>Остальное просто ненужно.
Нужно, просто ты об этом не знаешь: http://www.loper-os.org/?p=284
>>957610
Потому что надо дрова из ОС выкинуть нахуй. Пусть железячники все хардварно реализуют с простым интерфейсом. Все равно и так блобы везде. Так пусть тот блоб на железе крутиться с простым стандартным интерфейсом наружу. Тогда можно будет для кучи устройств использовать один драйвер по спецификации.
>но к сегодняшнему дню это всё либо осталось в музеях
Потому что надо дрова из ОС выкинуть нахуй. Пусть железячники все хардварно реализуют с простым интерфейсом. Все равно и так блобы везде. Так пусть тот блоб на железе крутиться с простым стандартным интерфейсом наружу. Тогда можно будет для кучи устройств использовать один драйвер по спецификации.
>>957621
Годная идея. PostScript в принтерах был шагом в правильном направлении.
Годная идея. PostScript в принтерах был шагом в правильном направлении.
>>957616
зачем нужен виндоус у которого нет экосистемы? На котором до сих пор мертвым грузом лежит дохуя (50%) легаси? Единственное за что их можно уважать за то что форсят переход на новые железки.
Видео драйвер интела из-за легаси пидарастии раздут с 1 мб до 200, в 200 раз больше необходимого, пиздец.
МакОСь хоть и для пидарасов, но сбалансирована, имеет нормальную щель, работает без бсодов.
зачем нужен виндоус у которого нет экосистемы? На котором до сих пор мертвым грузом лежит дохуя (50%) легаси? Единственное за что их можно уважать за то что форсят переход на новые железки.
Видео драйвер интела из-за легаси пидарастии раздут с 1 мб до 200, в 200 раз больше необходимого, пиздец.
МакОСь хоть и для пидарасов, но сбалансирована, имеет нормальную щель, работает без бсодов.
>>957602
Популярность С++ гарантирует, что с твоим подходом что-то не то. И довольно банальное - обратно-совместимое решение победило. Из тех времен живо 3 языка, это С, С++ и Objective C. Угадай, почему.
Популярность С++ гарантирует, что с твоим подходом что-то не то. И довольно банальное - обратно-совместимое решение победило. Из тех времен живо 3 языка, это С, С++ и Objective C. Угадай, почему.
>>957647
В голос с дауна.
Экосистема это когда в системе не дублируется одно и то-же и четко разделено что за что отвечает.
Виндовс 20 лет не чистилось от говна, вместо того чтобы это сделать добавляют %фичи% и велосипеды чтобы они работали.
Одинаковые названия программ, драйвера по 300 метров для звуковух и видео, три встроеных браузера и двое меню настроек на покушать.
>легаси и есть экосистема, тупой ты уебок
>и да, это оскорбление
В голос с дауна.
Экосистема это когда в системе не дублируется одно и то-же и четко разделено что за что отвечает.
Виндовс 20 лет не чистилось от говна, вместо того чтобы это сделать добавляют %фичи% и велосипеды чтобы они работали.
Одинаковые названия программ, драйвера по 300 метров для звуковух и видео, три встроеных браузера и двое меню настроек на покушать.
>>957657
Ты бредишь, Митя. Экосистема - это экологическая система, почитай, что такое экология. Это когда куча животных, едят друг друга и срут, но система при этом стабильна, потому что все в балансе.
Ты бредишь, Митя. Экосистема - это экологическая система, почитай, что такое экология. Это когда куча животных, едят друг друга и срут, но система при этом стабильна, потому что все в балансе.
>>957660
А шиндовс не стабильна и не нужна согласно http://www.loper-os.org/?p=284
шиндовс обсирается на первом же правиле, так что хватит за них топить Пыня.
> друга и срут, но система при этом стабильна, потому что все в балансе.
А шиндовс не стабильна и не нужна согласно http://www.loper-os.org/?p=284
шиндовс обсирается на первом же правиле, так что хватит за них топить Пыня.
>>957631
Популярность продукта в массах — это показатель только его доступности для широкой аудитории.
Это как сравнить айфоны с кучей говна на андроиде — первые по статистике занимают всего-то 10-15% рынка. Только вот незадача, из этих 85-90% только треть превышают отметку в 200$, а отметку в 500$ ещё треть от этой трети.
Вот и думай почему говно для тупорылых макак вроде го, пхп (и 1с в странах снг) стреляет. То же и с плюсами — худобедно любой дебил осиливает хэловорд, падающий через раз с сегфолтом — зато осилил жи!
Популярность продукта в массах — это показатель только его доступности для широкой аудитории.
Это как сравнить айфоны с кучей говна на андроиде — первые по статистике занимают всего-то 10-15% рынка. Только вот незадача, из этих 85-90% только треть превышают отметку в 200$, а отметку в 500$ ещё треть от этой трети.
Вот и думай почему говно для тупорылых макак вроде го, пхп (и 1с в странах снг) стреляет. То же и с плюсами — худобедно любой дебил осиливает хэловорд, падающий через раз с сегфолтом — зато осилил жи!
>>957684
Ты сам довольно тупорылый, если мобильные ос в принципе занимают какое-то место в твоей голове. А языка лучше С++ в своей нише объективно нет. Вообще. Никак. Ни разу. Поэтому умнейшие люди планеты пишут свои продукты на нем, с нуля и до сих пор.
Ты сам довольно тупорылый, если мобильные ос в принципе занимают какое-то место в твоей голове. А языка лучше С++ в своей нише объективно нет. Вообще. Никак. Ни разу. Поэтому умнейшие люди планеты пишут свои продукты на нем, с нуля и до сих пор.
>>957770
Ты домен какаой-та толе на плюсах писали раньше потому что небыли альтернативы. От слова совсем. Либо Ява, либо говно вроде D со сборщиком.
Ты домен какаой-та толе на плюсах писали раньше потому что небыли альтернативы. От слова совсем. Либо Ява, либо говно вроде D со сборщиком.
Есть у кого-нибудь опыт использования Rust в production? Часто занимаюсь "узкими" местами в веб приложениях, сейчас все на плюсах, но давно посматриваю в сторону Rust, хотелось бы узнать о опыте использования в реальных проектах?
>>957873
Что ты там увидеть ожидаешь-то? Плюсовикам (как и вообще всем, кто не занимался каким нибудь хачкеллем, в котором компилятор так же ебет за попытки сделать хуйню) переучиваться очень больно. Иде уровня студии нет, но хуитка для редакторов с нормальным (не уровня тегов из вима и прочей еле работающей хуйни) автокомплитом и подсветкой ошибок из компилятора есть, хотя и альфа, которая собирается только через три анальных кольца. Можешь почитать истории от челиков из дропбокса - https://www.reddit.com/r/rust/comments/4adabk/the_epic_story_of_dropboxs_exodus_from_the_amazon/
Что ты там увидеть ожидаешь-то? Плюсовикам (как и вообще всем, кто не занимался каким нибудь хачкеллем, в котором компилятор так же ебет за попытки сделать хуйню) переучиваться очень больно. Иде уровня студии нет, но хуитка для редакторов с нормальным (не уровня тегов из вима и прочей еле работающей хуйни) автокомплитом и подсветкой ошибок из компилятора есть, хотя и альфа, которая собирается только через три анальных кольца. Можешь почитать истории от челиков из дропбокса - https://www.reddit.com/r/rust/comments/4adabk/the_epic_story_of_dropboxs_exodus_from_the_amazon/
>>957886
продакшен.
продакшен.
>>957839
Я к тому откуда могут быть утечки, если это раст. Значит unsafe. Хотя я помню что в каких то версиях раста все таки могли происходить утечки даже без ансейфа, когда паника запускалась другой в панике, но я посчитал что это прям обосраться какое исключение.
Я к тому откуда могут быть утечки, если это раст. Значит unsafe. Хотя я помню что в каких то версиях раста все таки могли происходить утечки даже без ансейфа, когда паника запускалась другой в панике, но я посчитал что это прям обосраться какое исключение.
>>958080
Хотя подожди. Проверка типов в языке с зависимыми типами может быть неразрешимой. Тогда нахуя оно надо?
А вот типы высшего порядка (да-да, те самые родненькие аппликативные функторы, стрелки и монады) были бы полезнее. Я правильно понимаю, что их можно эмулировать трейтами с ассоциированными типами?
Хотя подожди. Проверка типов в языке с зависимыми типами может быть неразрешимой. Тогда нахуя оно надо?
А вот типы высшего порядка (да-да, те самые родненькие аппликативные функторы, стрелки и монады) были бы полезнее. Я правильно понимаю, что их можно эмулировать трейтами с ассоциированными типами?
>>958050
Да, утечки есть, но я про то что ты как дауненок написал.
Кто так пишет? Это пиздец просто.
Да, утечки есть, но я про то что ты как дауненок написал.
>unsafe юзали
Кто так пишет? Это пиздец просто.
>>957112
Там нет исключений, но есть особая система типов. Т.е. функция всегда что-то возвращает. Но это может быть что-то (Some), а может быть ничто (None). Или например может быть некий результат или некая ошибка, что уже как бы является аналогом исключения
Там нет исключений, но есть особая система типов. Т.е. функция всегда что-то возвращает. Но это может быть что-то (Some), а может быть ничто (None). Или например может быть некий результат или некая ошибка, что уже как бы является аналогом исключения
>>958329
Правильно писать NSA.
Ты еще скажи что у раста уязвимостей нет, только что говорили что нет утечек, теперь это.
Правильно писать NSA.
Ты еще скажи что у раста уязвимостей нет, только что говорили что нет утечек, теперь это.
>>958335
Если код пишет не си-обезьяна на ансейфах — то ни одной сишной точно не будет. Ты кстати забыл главный опус растотредов — memory leaks is memory safe, пидар.
Если код пишет не си-обезьяна на ансейфах — то ни одной сишной точно не будет. Ты кстати забыл главный опус растотредов — memory leaks is memory safe, пидар.
>>958335
Если руки кривые то ты утечку и в языке с GC сможешь сделать. От утечек тебя ни один язык полностью не убережет, так что думать головой все равно придется. Зато память в расте безопасная, без уязвимостей.
Если руки кривые то ты утечку и в языке с GC сможешь сделать. От утечек тебя ни один язык полностью не убережет, так что думать головой все равно придется. Зато память в расте безопасная, без уязвимостей.
>>957819
А как по-твоему писать ОСь, которая должна взаимодействовать с железом без unsafe'ов?
А как по-твоему писать ОСь, которая должна взаимодействовать с железом без unsafe'ов?
>>958602
Например, так же, как в некоторых ОС давно зделоли.
А именно, написан препроцессор для Сишки, который на каждом шаге проверяет, не собрался ли драйвер поделить, скажем, на ноль.
У драйвера своя область стека, все данные он видит только на чтение.
Собрался поделить на ноль - ну тогда значит KernExitThread(-1) и едем дальше.
Например, так же, как в некоторых ОС давно зделоли.
А именно, написан препроцессор для Сишки, который на каждом шаге проверяет, не собрался ли драйвер поделить, скажем, на ноль.
У драйвера своя область стека, все данные он видит только на чтение.
Собрался поделить на ноль - ну тогда значит KernExitThread(-1) и едем дальше.
>>958683
Я в работе современных (да и старых) ОСей не шарю, но на днях читал про прерывания. Что например если была попытка поделить на ноль, что будет вызвано такое-то прерывание. Где-то в памяти есть таблица (с адресами функций?), которые должны обрабатывать подобные случаи. И не всегда же надо тупо выходить. По крайней мере, родительский процесс должен знать, за что убили ребенка
Я в работе современных (да и старых) ОСей не шарю, но на днях читал про прерывания. Что например если была попытка поделить на ноль, что будет вызвано такое-то прерывание. Где-то в памяти есть таблица (с адресами функций?), которые должны обрабатывать подобные случаи. И не всегда же надо тупо выходить. По крайней мере, родительский процесс должен знать, за что убили ребенка
>>958680
Второкурсник ворвался в тред.
Второкурсник ворвался в тред.
>>958694
Да, это для обыкновенных процессов.
А в ядре ОС возникнет неисправимая ошибка во время выполнения, синий экранчик, у продвинутых чёрный.
Но в общем, не забивай себе этим голову, в роиссе на эти знания (очень ценные, ахаха) спроса всё равно нет.
Да, это для обыкновенных процессов.
А в ядре ОС возникнет неисправимая ошибка во время выполнения, синий экранчик, у продвинутых чёрный.
Но в общем, не забивай себе этим голову, в роиссе на эти знания (очень ценные, ахаха) спроса всё равно нет.
>>960919
Звучит неприлично.
Звучит неприлично.
Очередной долбоёбский тред где эксперты уровня laba2 спорят обо всём, до чего дотянутся.
>>961320
Есть в виде модулей к не очень популярным языкам. Я же говорю будущее, а не настоящее.
Есть в виде модулей к не очень популярным языкам. Я же говорю будущее, а не настоящее.
>>960575
Лет через 10 так, причём в совсем другом виде, а не то говно сейчас. Посмотри на циклон и раст - такая же разница.
Лет через 10 так, причём в совсем другом виде, а не то говно сейчас. Посмотри на циклон и раст - такая же разница.
>>963997
Emacs самая лучшая IDE для любого языка.
Emacs самая лучшая IDE для любого языка.
>>958680
Ну и к чему тогда твой вскукарек, различия жабы и смоллтока незначительны. Во втором только рефлексия продвинутей.
Ну и к чему тогда твой вскукарек, различия жабы и смоллтока незначительны. Во втором только рефлексия продвинутей.
>>956909 (OP)
Друзья, я пытаюсь разобраться в возможностях языка.
Конкретно интересует асинхронное программирование, наткнулся на какие-то фьючеры, но они реализованы отдельной библиотекой, это как может вообще работать?
Ну в смысле, вот есть либа для общения с SQL сервером, но она же ничего про либу с фьючерами не знает, и как тогда это общение в код с фьючерами инкорпорировать?
Друзья, я пытаюсь разобраться в возможностях языка.
Конкретно интересует асинхронное программирование, наткнулся на какие-то фьючеры, но они реализованы отдельной библиотекой, это как может вообще работать?
Ну в смысле, вот есть либа для общения с SQL сервером, но она же ничего про либу с фьючерами не знает, и как тогда это общение в код с фьючерами инкорпорировать?
>>964028
Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
>и как тогда это общение в код с фьючерами инкорпорировать?
Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
>>964219
А это законно вообще?
>Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
А это законно вообще?
Если раст пилят как более безопасную замену C++, значит в нем не должно быть проблем при написании гуишного софта?
>>964473
Новые гуевины шлепают только на мобилках со своими хост-языками, а десктопное легаси и без того вроде работает (хотя тот же гном вроде как по кусочкам, как и новый движок лисы переписывают на растяпу? но это неточно).
>2к17
>геи
Новые гуевины шлепают только на мобилках со своими хост-языками, а десктопное легаси и без того вроде работает (хотя тот же гном вроде как по кусочкам, как и новый движок лисы переписывают на растяпу? но это неточно).
>>964473
Есть разные биндинги под существующие либы
Например, https://www.youtube.com/watch?v=hLR8R0Zl0yY
Есть разные биндинги под существующие либы
Например, https://www.youtube.com/watch?v=hLR8R0Zl0yY
>>964464
Значит на попытке написать scgi приложение я сосну?
Вроде tokio позволяет оче просто писать асинхронный сервер.
>В манямирке
Значит на попытке написать scgi приложение я сосну?
Вроде tokio позволяет оче просто писать асинхронный сервер.
>>964586
Я вообще мимо проходил(из го треда), сорян, помочь не могу.
Я вообще мимо проходил(из го треда), сорян, помочь не могу.
1,3 Мб, 1920x1080
>>965804
>>965807
Полгода для раста это много. Сейчас как-то так.
https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
>>965807
Полгода для раста это много. Сейчас как-то так.
https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
>>965824
Они допилили асинхронный сервер (он полноценный или какая-то заглушка еще)?
Они допилили асинхронный сервер (он полноценный или какая-то заглушка еще)?
bump
112 Кб, 800x755
Поясните за racer. Хуй с ним он не может в макросы. Но какого хуя он даже обычные крейты не может нормально обработать?
Взял kiss3d и рейсеру вообще похуй. Он ничего не дополняет.
Взял kiss3d и рейсеру вообще похуй. Он ничего не дополняет.
>>971901
RLS натяни, работает через тот же рейсер, только с ошибками из компилятора на лету и анализирует крейты.
Плагин для intellij кстати, уже даже с макросами работает — криво и косо, но навигирует уже около них (в дислокации +- 10-20 строк, лул).
RLS натяни, работает через тот же рейсер, только с ошибками из компилятора на лету и анализирует крейты.
Плагин для intellij кстати, уже даже с макросами работает — криво и косо, но навигирует уже около них (в дислокации +- 10-20 строк, лул).
>>956909 (OP)
Не взлетит.
>>957136
Последнее не подрузамевает мозг, а равно ручной гарбейжинг, а значит без певрого не возможно второе.
>Rust
Не взлетит.
>>957136
>без сборщика мусора
>миллионы макак
Последнее не подрузамевает мозг, а равно ручной гарбейжинг, а значит без певрого не возможно второе.
>>972199
Не так, габейджинг вообще не потребуется, потому что код будет написан безопасно либо не скомпилится.
>а равно ручной гарбейжинг
Не так, габейджинг вообще не потребуется, потому что код будет написан безопасно либо не скомпилится.
>>972282
Ну так прочитай книжку и пойми как надо делать что бы компилилось.
>this. Так что без автосборщика мусора никуда.
Ну так прочитай книжку и пойми как надо делать что бы компилилось.
Вообще конечно расту нужны нормальные средства разработки. И вроде как они активно пилятся. Подождем, посмотрим, потому что сейчас, все что связано с растом находится в "earliest alpha stage of development".
12 Кб, 798x122
Так и живем.
бамп
>>972282
Ну как бы Rust не позиционируется как замена для джавы.
Хотя, мне кажется это возможно, если создать правильные годные абстракции.
Раст нужен там, где нужно создать хороший годный код который создаст хороший годный бинарник, который будет хорошо годно выполнятся.
Тнз тырпрайз, заточен под создание проектов максимальной сложности путем задействования минимально квалифицированных трудовых ресурсов.
Совсем другая область.
>Ну и дохуя тырпрайза перекатилось на него?
Ну как бы Rust не позиционируется как замена для джавы.
Хотя, мне кажется это возможно, если создать правильные годные абстракции.
Раст нужен там, где нужно создать хороший годный код который создаст хороший годный бинарник, который будет хорошо годно выполнятся.
Тнз тырпрайз, заточен под создание проектов максимальной сложности путем задействования минимально квалифицированных трудовых ресурсов.
Совсем другая область.
>>972459
Мне кажется раст будет ультрагоден для создания осей и низкоуровенего софта, т.е. там, где сейчас С и С++.
Мне кажется раст будет ультрагоден для создания осей и низкоуровенего софта, т.е. там, где сейчас С и С++.
>>972568
Пистон это набор либ, а не движок. Если верить описанию с https://github.com/amethyst/amethyst/wiki/Other-Game-Engines-in-Rust
Пистон это набор либ, а не движок. Если верить описанию с https://github.com/amethyst/amethyst/wiki/Other-Game-Engines-in-Rust
>>972485
Но оно говно пока что. Что-то годное сделают когда раст станет массовым.
Но оно говно пока что. Что-то годное сделают когда раст станет массовым.
>>972679
Быстрее плюсов.
Хотя ирл однохуйственно перекомпиливается только 1 модуль, и на минимальной конфигурации мбп 2016 весь цикл компиляции-тестов проходит быстро, если ты не меняешь весь проект и зависимости вместе взятые за раз. И в отличие от го с быстрой компиляцией, тут при отсутствии ансейфа дебаггер действительно нинужин.
Быстрее плюсов.
Хотя ирл однохуйственно перекомпиливается только 1 модуль, и на минимальной конфигурации мбп 2016 весь цикл компиляции-тестов проходит быстро, если ты не меняешь весь проект и зависимости вместе взятые за раз. И в отличие от го с быстрой компиляцией, тут при отсутствии ансейфа дебаггер действительно нинужин.
>>972725
Дебагер не нужен? Быстрая конпеляция не нужна? Ты всю хуйню пишешь без ошибок с первого раза?
Дебагер не нужен? Быстрая конпеляция не нужна? Ты всю хуйню пишешь без ошибок с первого раза?
>>972728
Ты даун который мой пост не прочитал.
Но да, с его системой типов и статическим анализом он в своём каноническом юзкейсе рили не нужен. Разве что с пошаговой поддержкой IDE для изучения чужого кода прикольно было бы.
Ты даун который мой пост не прочитал.
Но да, с его системой типов и статическим анализом он в своём каноническом юзкейсе рили не нужен. Разве что с пошаговой поддержкой IDE для изучения чужого кода прикольно было бы.
>>972731
http://paste.org.ru/?57pxj7
Как быть если случится примерно такая история? Как раст меня от этого защищает?
http://paste.org.ru/?57pxj7
Как быть если случится примерно такая история? Как раст меня от этого защищает?
>>972739
В го дебагер не нужен потому что
1) Быстрее въебать принт и переконпелить
2) Если ты поймаешь панику ты получишь четкий стектрейс
В го дебагер не нужен потому что
1) Быстрее въебать принт и переконпелить
2) Если ты поймаешь панику ты получишь четкий стектрейс
>>972740
В расте он не нужен потому что:
а) Если не пытаться руками завалить код — он не разыминует висячий указатель/нульпоинтер/итд.
б) Стектрейс в дебаг-билде в любом языке избыточен, вась.
В расте он не нужен потому что:
а) Если не пытаться руками завалить код — он не разыминует висячий указатель/нульпоинтер/итд.
б) Стектрейс в дебаг-билде в любом языке избыточен, вась.
>>972741
По твоему кто-то специально стреляет себе в ногу? Нет, блять, это говно всплывает в проде когда ты этого меньше всего ожидаешь. Система типов никогда в жизни не научит тебя не совершать ошибок, которые вызовут у твоих клиентов жопную боль. Может ты и не сможешь поделить попугаев на тараканов, но вот вместо одного бесплатного попугая выдать чуть более 9000 - легко.
По твоему кто-то специально стреляет себе в ногу? Нет, блять, это говно всплывает в проде когда ты этого меньше всего ожидаешь. Система типов никогда в жизни не научит тебя не совершать ошибок, которые вызовут у твоих клиентов жопную боль. Может ты и не сможешь поделить попугаев на тараканов, но вот вместо одного бесплатного попугая выдать чуть более 9000 - легко.
>>972743
Кукаретик, еще раз тебе повторяю, что 99% ошибок это ошибки бизнес логики, а не разыменования указателей.
Кукаретик, еще раз тебе повторяю, что 99% ошибок это ошибки бизнес логики, а не разыменования указателей.
>>972746
В высокоуровенных языках вроде явы, где их и нет. А так, открой свежий список CVE, посмотри как там дела с 1%.
В высокоуровенных языках вроде явы, где их и нет. А так, открой свежий список CVE, посмотри как там дела с 1%.
>>972744
Она поможет мне ковыряться в говне из байтов без стрельбы в анал и гонок данных. Давай заводи демагогию по новой.
Она поможет мне ковыряться в говне из байтов без стрельбы в анал и гонок данных. Давай заводи демагогию по новой.
>>972736
Ты о чём?
Ты о чём?
413 Кб, 1060x700
>>972459
А вот тут, кстати, у меня вопрос возник. Где почитать именно про приемы проектирования на Rust - с примерами неудачных решений, разбором полетов и т.д. По классическому ООП такой литературы завались, а тут куда копать? Ну или хотя бы исходники какого-нибудь годного проекта средней сложности посоветуйте.
>если создать правильные годные абстракции
А вот тут, кстати, у меня вопрос возник. Где почитать именно про приемы проектирования на Rust - с примерами неудачных решений, разбором полетов и т.д. По классическому ООП такой литературы завались, а тут куда копать? Ну или хотя бы исходники какого-нибудь годного проекта средней сложности посоветуйте.
>>972679
cargo check
cargo check
>>972833
Предположу, что скорее всего нигде, кроме исходников чужих проектов. Советую сначала погуглить, а если найдешь- вбросить сюда.
>Где почитать именно про приемы проектирования на Rust
Предположу, что скорее всего нигде, кроме исходников чужих проектов. Советую сначала погуглить, а если найдешь- вбросить сюда.
>>972849
>>972833
https://github.com/rust-unofficial/patterns
От авторов знаменитой "learn rust by writing too many lists". Хотя там большинство контента всё ещё только TODO без описания (:
Проекты смотри где нибудь на https://github.com/kud1ing/awesome-rust
Где-то кстати видел компилятор хаскеля на расте, тоже можешь глянуть, лул.
А вообще, вся кор-тима раста работает над серво, и половина над токио — посмотри на них если хочешь кода из первых рук.
>>972833
https://github.com/rust-unofficial/patterns
От авторов знаменитой "learn rust by writing too many lists". Хотя там большинство контента всё ещё только TODO без описания (:
Проекты смотри где нибудь на https://github.com/kud1ing/awesome-rust
Где-то кстати видел компилятор хаскеля на расте, тоже можешь глянуть, лул.
А вообще, вся кор-тима раста работает над серво, и половина над токио — посмотри на них если хочешь кода из первых рук.
>>972464
1)Примеры ымбыдеда на вашем расте есть?
2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
1)Примеры ымбыдеда на вашем расте есть?
2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
>>974065
1) Гугол открой;
2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты. Сравни на том же реддите активность доски раста с досками плюсов и си вместе взятыми.
1) Гугол открой;
2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты. Сравни на том же реддите активность доски раста с досками плюсов и си вместе взятыми.
>>974726
А не тот ли это шизик, что срет в го треде?
>2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты.
А не тот ли это шизик, что срет в го треде?
>>974730
Это ты у него узнавай.
Это ты у него узнавай.
>>974065
Патамушто с неадекватами неохота разговаривать, норм чуваки все в гиттере да ирц пасутся
>тред, который мертвее треда полувекового С
Патамушто с неадекватами неохота разговаривать, норм чуваки все в гиттере да ирц пасутся
>>976239
Надо было делать print << ln
Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
Надо было делать print << ln
Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
>>976245
Иди нахуй за этим ублюдским говном в плюсы. Я реально рад, что сделали человеческое printf-like форматирование.
Так это и не окамл, дружок. Тут восклицательный знак (тем более справа от идентификатора, хз с чего ты про мутабельность рот открыл — мутабельно передать что-то можно только явно с mut) означает макрос, местный синтаксис разыменования указателей от си был унаследован, если ты не заметил.
>Надо было делать print << ln
Иди нахуй за этим ублюдским говном в плюсы. Я реально рад, что сделали человеческое printf-like форматирование.
>Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
Так это и не окамл, дружок. Тут восклицательный знак (тем более справа от идентификатора, хз с чего ты про мутабельность рот открыл — мутабельно передать что-то можно только явно с mut) означает макрос, местный синтаксис разыменования указателей от си был унаследован, если ты не заметил.
>>976237
Зачем оправдываться? Тут два стула - либо используй макросы, либо зависимые типы. Причем раст, похоже, будет видеть на обоих.
Ладно-ладно, есть третий стул - разбирать строку формата в рантайме и обрабатывать ошибку. Но для этого есть runtime-fmt
Зачем оправдываться? Тут два стула - либо используй макросы, либо зависимые типы. Причем раст, похоже, будет видеть на обоих.
Ладно-ладно, есть третий стул - разбирать строку формата в рантайме и обрабатывать ошибку. Но для этого есть runtime-fmt
>>976259
Я раньше думал, что вывод имеет отношения к монадам, а тут вон че. Поясни, пожалуйста.
Я раньше думал, что вывод имеет отношения к монадам, а тут вон че. Поясни, пожалуйста.
>>976318
Но я хочу чтобы было AbstractSingletonProxyFactoryBean чтобы объединять данные с функциями
Но я хочу чтобы было AbstractSingletonProxyFactoryBean чтобы объединять данные с функциями
>>976317
Похоже на go лол
Похоже на go лол
>>974065
Проблемы /pr
Потому что абсолютное большинство тредов языкача - это холивары и баттхерты, например есть го тред, но там куча неадеквата.
>2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
Проблемы /pr
Потому что абсолютное большинство тредов языкача - это холивары и баттхерты, например есть го тред, но там куча неадеквата.
В общем не вижу никакой разницы с С++ кроме примитивного ооп, конструкции match и опущенных {} (вау), да ещё уебанцкие сокращения ключевых слов и имён в стандартой библиотеке
Выглядит как язык от васяна где вся логика построена по желанию его левой пятки
Для деклоративного петушения со статической типизацией лучше взять Haskell, для навороченного синтаксиса Perl 6
Выглядит как язык от васяна где вся логика построена по желанию его левой пятки
Для деклоративного петушения со статической типизацией лучше взять Haskell, для навороченного синтаксиса Perl 6
>>976345
Что-то ты забыл про главное отличие - систему типов Rust. Я и про lifetimes/borrowing, и про гарантированную на уровне системы типов потокобезопасность (вне unsafe), и про проверку типов в дженериках на этапе их создания а не на этапе инициализации. А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
И да, модули. В 2к17 инклудить хедеры вместо нормального импорта модулей - очень странно если честно. Это по сравнению с прочим мелочь, но всё-таки.
Что-то ты забыл про главное отличие - систему типов Rust. Я и про lifetimes/borrowing, и про гарантированную на уровне системы типов потокобезопасность (вне unsafe), и про проверку типов в дженериках на этапе их создания а не на этапе инициализации. А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
И да, модули. В 2к17 инклудить хедеры вместо нормального импорта модулей - очень странно если честно. Это по сравнению с прочим мелочь, но всё-таки.
>>976363
Вот только не надо это сложное для понимания уг тащить в Rust.
Сейчас это нормальный язык, Haskell к услугам тех, кто желает дрочить на монады/теоркат и теорию типов.
>А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
Вот только не надо это сложное для понимания уг тащить в Rust.
Сейчас это нормальный язык, Haskell к услугам тех, кто желает дрочить на монады/теоркат и теорию типов.
>>976366
Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
>>957444
Схрена ли оно компилируется тогда?
ЛЮБОЙ ШКОЛЬНИК ЗНАЕТ
@
РАЗРАБОТЧИКИ КОМПИЛЯТОРА НЕ ЗНАЮТ
>пример притянут за яйца. любой школьник знает
Схрена ли оно компилируется тогда?
ЛЮБОЙ ШКОЛЬНИК ЗНАЕТ
@
РАЗРАБОТЧИКИ КОМПИЛЯТОРА НЕ ЗНАЮТ
>>976388
Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею. Разумеется, дело может быть во мне, но для себя я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust. Для таких вещей есть Haskell и незачем засирать другой язык.
просто хаскеллисты хуеют от своего рантайма и хотят свои убер-абстракции, которые и сами не понимают, но при этом хотят efficiency раста
>Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею. Разумеется, дело может быть во мне, но для себя я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust. Для таких вещей есть Haskell и незачем засирать другой язык.
просто хаскеллисты хуеют от своего рантайма и хотят свои убер-абстракции, которые и сами не понимают, но при этом хотят efficiency раста
>>976345
Ты сам только что показал что опущен только ты, лол. В расте много где опускаются обычные скобки, но все выражения (кроме однострочных результатов паттерн матчинга) делятся фигурными.
Жеманный, не не пались, не знаешь же. После си и плюсов с atoi(), ftol() ntohl() и друзьями в расте просто AbstractSingletonProxyFactoryBean-ы какие-то
>>976388
Братан, вот поясни мне за эти функторы — а нахуя?
Я мб тупой слишком, но из пояснений в гугле понял столько же, сколько про монады — что это моноид в категории эндофункторов, ахуенно.
Сейчас у нас есть что-то между плюсами и сишкой — с композицией и tagget-unions вместо наследования, простым синтаксисом (дада), все очень явно, модули и так далее.
Короче, качественный кусок инженерного говна, если цитировать одного йоба-математика. На нем с некоторой сноровкой, конечно могут спокойно писать васяны вроде меня у которых никогда не было пар теорката или они нихуя не понели, в общем-то, примерно 95% программистов на си и плюсах.
А еще есть тот же ATS, в котором зависимые типы где-то даже видел коммент в стиле "правильно сделанный раст" и все прочее, на котором с комментария того же йоба-математика скорость написания кода в лучшем случае "400 строк за неделю". Карл, вот что такого дадут эти зависимые типы практичному языку, а не йобе от епонца, у которого в культуре высшее просветление — аутировать смотря на сакуру?
>опущенных {} (вау)
Ты сам только что показал что опущен только ты, лол. В расте много где опускаются обычные скобки, но все выражения (кроме однострочных результатов паттерн матчинга) делятся фигурными.
>стандартой библиотеке
Жеманный, не не пались, не знаешь же. После си и плюсов с atoi(), ftol() ntohl() и друзьями в расте просто AbstractSingletonProxyFactoryBean-ы какие-то
>>976388
Братан, вот поясни мне за эти функторы — а нахуя?
Я мб тупой слишком, но из пояснений в гугле понял столько же, сколько про монады — что это моноид в категории эндофункторов, ахуенно.
Сейчас у нас есть что-то между плюсами и сишкой — с композицией и tagget-unions вместо наследования, простым синтаксисом (дада), все очень явно, модули и так далее.
Короче, качественный кусок инженерного говна, если цитировать одного йоба-математика. На нем с некоторой сноровкой, конечно могут спокойно писать васяны вроде меня у которых никогда не было пар теорката или они нихуя не понели, в общем-то, примерно 95% программистов на си и плюсах.
А еще есть тот же ATS, в котором зависимые типы где-то даже видел коммент в стиле "правильно сделанный раст" и все прочее, на котором с комментария того же йоба-математика скорость написания кода в лучшем случае "400 строк за неделю". Карл, вот что такого дадут эти зависимые типы практичному языку, а не йобе от епонца, у которого в культуре высшее просветление — аутировать смотря на сакуру?
>>976511
Cи делали 100 лет назад, в С++ этого уже нет за редким исключением, писать fn вместо function даже не каждая обоссанная обёртка для JS себе позволит. Можно было использовать define или вообще function x = x раз уж match влепили. Для серьёзного языка с ориентацией на безопасность это абсолютно неприемлимо, даже переменные так называть нельзя.
Cи делали 100 лет назад, в С++ этого уже нет за редким исключением, писать fn вместо function даже не каждая обоссанная обёртка для JS себе позволит. Можно было использовать define или вообще function x = x раз уж match влепили. Для серьёзного языка с ориентацией на безопасность это абсолютно неприемлимо, даже переменные так называть нельзя.
>>976538
>>976539
Ебать жеманного бомбонуло.
>>976529
Дык их и нет в расте, здеся у нас аффинные типы.
Линейные типы (по моему скромному пониманию, хз чо там по математической правильности) позволяют использовать объект только из одного места и запрещают копировать на него ссылки. В расте это называется владением.
В аффинной типизации есть возможность использовать объект не только из одного места. В сухом остатке, это грубо говоря есть заимствование.
>>976539
Ебать жеманного бомбонуло.
>>976529
Дык их и нет в расте, здеся у нас аффинные типы.
Линейные типы (по моему скромному пониманию, хз чо там по математической правильности) позволяют использовать объект только из одного места и запрещают копировать на него ссылки. В расте это называется владением.
В аффинной типизации есть возможность использовать объект не только из одного места. В сухом остатке, это грубо говоря есть заимствование.
Ёпт, на сколько всего отвечать придётся
>>976505
Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?
Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.
Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
>>976511
На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.
Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.
Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
>>976505
>Представь себе, прежде чем ответить, я загуглил и честно попытался понять. Не смог сделать этого даже на интуитивном уровне, т.е. не уловил идею.
Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?
> я сделал вывод, что это достаточно сложно для понимания программиста, привыкшего к императивным языкам, к числу которых относится Rust
Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.
> Для таких вещей есть Haskell и незачем засирать другой язык
Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
>>976511
>Братан, вот поясни мне за эти функторы — а нахуя?
На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.
Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.
> Карл, вот что такого дадут эти зависимые типы практичному языку
Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
Ёпт, на сколько всего отвечать придётся
>>976505
Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?
Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.
Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
>>976511
На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.
Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.
Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
>>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 (которая :?).
Братан, можно было просто:
а) Сделать impl Display for Vec<Box<Yoba>> и всё;
б) Использовать дебажную форматировку в println (которая :?).
>>976573
Ну я вот щас ничего не понял. Ты точно не стебешься? ->, -> -> - это что?
1. ООП все, кто связан с программированием, знают
2. В начальном приближении большинство концепций ООП можно объяснить сравнительно просто, можно это как-то постепенно изучать, а, когда на тебя обрушивается ворох стрелок и звездочек, это кажется сложным.
Разумеется, сказывается императивный бэкграунд и стереотипы об ФП. Плюс не совсем понятно, а нахуя это нужно, я понимаю конечно, что ты в обратку можешь сказать, что так можно и на голом С или asm писать и вообще отказаться от прогресса, но, повторюсь, зачем эти кайнды нужны я так для себя и не уяснил. Наверное, это красиво, но для меня отдает дрочевом и излишней наукообразностью.
>>976588
>>976573
>>976575
>>976577
Чет проиграл если честно.
>На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> , то параметра должно быть два, и так далее. Разве это настолько сложно?
Ну я вот щас ничего не понял. Ты точно не стебешься? ->, -> -> - это что?
>Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.
1. ООП все, кто связан с программированием, знают
2. В начальном приближении большинство концепций ООП можно объяснить сравнительно просто, можно это как-то постепенно изучать, а, когда на тебя обрушивается ворох стрелок и звездочек, это кажется сложным.
Разумеется, сказывается императивный бэкграунд и стереотипы об ФП. Плюс не совсем понятно, а нахуя это нужно, я понимаю конечно, что ты в обратку можешь сказать, что так можно и на голом С или asm писать и вообще отказаться от прогресса, но, повторюсь, зачем эти кайнды нужны я так для себя и не уяснил. Наверное, это красиво, но для меня отдает дрочевом и излишней наукообразностью.
>>976588
>>976573
>>976575
>>976577
Чет проиграл если честно.
>>976573
Ну если смогут норм внедрить эти кайнды в язык и объяснить так, чтобы понял человек, который на хаскелле только факториалы писал, то я ничего против не имею, возможно это годная вещь действительно.
>Тут у вас на глазах происходят крутейшие вещи - высокоуровневые абстракции, которые раньше ассоциировались с очень высокоуровневыми языками, теперь можно (или скоро можно будет использовать) в системной разработке, причём вся "магия" происходит на этапе компиляции, т. е. никакого ущерба производительности нет. А вы включаете режим утёнка, мол, с этим я не знаком, не надо этим засирать язык. Как прогресс-то двигать, не пробуя новые абстракции?
Ну если смогут норм внедрить эти кайнды в язык и объяснить так, чтобы понял человек, который на хаскелле только факториалы писал, то я ничего против не имею, возможно это годная вещь действительно.
>>976602
Это парсер съел звёздочки. Смотри короче ссылку на pastebin, я не ебу как эти звёздочки вставлять сюда.
> ->, -> -> - это что?
Это парсер съел звёздочки. Смотри короче ссылку на pastebin, я не ебу как эти звёздочки вставлять сюда.
>>976602
Те же монады и функторы нормально без кайндов не реализовать. Зачем нужны монады и функторы и попытался вкратце объяснить выше. В общем всё сводится к тому чтобы писать более обобщённый код.
>Плюс не совсем понятно, а нахуя это нужно
Те же монады и функторы нормально без кайндов не реализовать. Зачем нужны монады и функторы и попытался вкратце объяснить выше. В общем всё сводится к тому чтобы писать более обобщённый код.
>>976602
Ну можно конечно какой-то другой синтаксис придумать, без стрелочек со звёздочками. Стрелочки здесь потому что те самые дженерики которыми мы каждый день пользуемся с точки зрения того же Haskell - функция над типом. Ну то есть когда мы пишем тип вроде List<Int> мы как бы вызваем (в compile-time, разумеется) функцию List с параметром Int.
Ну можно конечно какой-то другой синтаксис придумать, без стрелочек со звёздочками. Стрелочки здесь потому что те самые дженерики которыми мы каждый день пользуемся с точки зрения того же Haskell - функция над типом. Ну то есть когда мы пишем тип вроде List<Int> мы как бы вызваем (в compile-time, разумеется) функцию List с параметром Int.
Я не понял насчёт параллелизма, он что реальные потоки создаёт? А корутины где?
В http://rurust.github.io/rust_book_ru полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
В http://rurust.github.io/rust_book_ru полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
>>976821
И что в ней странного?
Все так всегда делают.
Ты что реально слабоумный дебил?
Не завезли, ибо сложно и нужон сложный рантайм.
Заместо есть tokio и фьючерзы.
>полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
И что в ней странного?
Все так всегда делают.
>Я не понял насчёт параллелизма, он что реальные потоки создаёт?
Ты что реально слабоумный дебил?
>А корутины где?
Не завезли, ибо сложно и нужон сложный рантайм.
Заместо есть tokio и фьючерзы.
>>976827
А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
>>976834
Асинхронно.
Через tokio либу.
Но с такими вопросами, лично тебе, никак.
Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
Архитектура ПК - ассемблер - си.
Да и не для раста то-же нужно.
>А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
Асинхронно.
Через tokio либу.
Но с такими вопросами, лично тебе, никак.
Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
Архитектура ПК - ассемблер - си.
Да и не для раста то-же нужно.
>>957174
Не в 6/9 а в 3/9, при этом сливает Си в 8/9,
что какбы говорит нам о качестве кода на плюсах в этих бенчмарках.
Не в 6/9 а в 3/9, при этом сливает Си в 8/9,
что какбы говорит нам о качестве кода на плюсах в этих бенчмарках.
>>976827
Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.
>>976836
Сразу видно теоретика.
>>976842
Так с++ довольно выразителен, если сравнивать с джавой или го.
>И что в ней странного?
>Все так всегда делают.
Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.
>>976836
>
>Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
>Архитектура ПК - ассемблер - си.
Сразу видно теоретика.
>>976842
>Там выразительность на уровне С++
Так с++ довольно выразителен, если сравнивать с джавой или го.
>>957308
А теперь приведи пруфы того, что Rust делает гарантированно безопасный код.
А теперь приведи пруфы того, что Rust делает гарантированно безопасный код.
>>976821
Он не слышали про количество ядер прост
Он не слышали про количество ядер прост
>>976851
Любой недурак, знает, что плодить потоков больше чем ядер ЕСТЬ смысл в определенных задачах.
И потому проводит тесты производительности в разных конфигурациях.
Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.
>Да просто любой дурак знает, что плодить больше потоков, чем ядер, нет смысла, особенно для вычислений. То, что все так делают не говорит о том, что это правильно.
Любой недурак, знает, что плодить потоков больше чем ядер ЕСТЬ смысл в определенных задачах.
И потому проводит тесты производительности в разных конфигурациях.
>Сразу видно теоретика.
Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.
>>976602
Сижу на програмаче, следовательно я связан с программированием. я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные), следовательно это твое утверждение ложно.
>ООП все, кто связан с программированием, знают
Сижу на програмаче, следовательно я связан с программированием. я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные), следовательно это твое утверждение ложно.
>>976908
Первая посылка ложна, ты не связан с программированием. Ты хлебаешь борщи и участвуешь в срачах.
Первая посылка ложна, ты не связан с программированием. Ты хлебаешь борщи и участвуешь в срачах.
>>976908
Ты как минимум очень ограниченный человек, который имеет ноль интереса к своей профессии. К программированию ты действительно имеешь мало отношения, ибо не имеешь понятия о концепциях, принятых в большинстве современных языков, даже если они чем-то плохи.
Ты как минимум очень ограниченный человек, который имеет ноль интереса к своей профессии. К программированию ты действительно имеешь мало отношения, ибо не имеешь понятия о концепциях, принятых в большинстве современных языков, даже если они чем-то плохи.
>>976908
То, что ты не писал с ООП подходом, что кстати сомнительно, еще не означает, что ты не знаешь ООП.
Тем более, что ты
И минимум что-то читал тут о ООП.
Увы, но твои аргументы инвалид, и логический вывод мягко говоря сломан.
Что косвенно свидетельствует о твоей недалекости в целом, и в отношении процедурных\функциональных языков в частности.
>я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные)
То, что ты не писал с ООП подходом, что кстати сомнительно, еще не означает, что ты не знаешь ООП.
Тем более, что ты
>Сижу на програмаче
И минимум что-то читал тут о ООП.
>следовательно это твое утверждение ложно
Увы, но твои аргументы инвалид, и логический вывод мягко говоря сломан.
Что косвенно свидетельствует о твоей недалекости в целом, и в отношении процедурных\функциональных языков в частности.
25 Кб, 1173x878
Карго превращает каждый проект в локальное хранилище всех существующих либ раста, а в конце обязатльно что-то ломается
>>977055
Это издержки любой централизованной иuild системы.
Я как вижу эти зеленые надписи про downloading-compiling, так сразу чувство, что сейчас начнется какая-то мясорубка с кишками и кровью, больно это напоминает руби, а я в свое время наебался с последним, когда для запуска одного скрипта нужна тысяча гемов ну или хз сколько и что-то всегда ломается. При этом я был не разработчиком, но конечным пользователем тех скриптов и с того времени руби для меня - ругательство.
Это издержки любой централизованной иuild системы.
Я как вижу эти зеленые надписи про downloading-compiling, так сразу чувство, что сейчас начнется какая-то мясорубка с кишками и кровью, больно это напоминает руби, а я в свое время наебался с последним, когда для запуска одного скрипта нужна тысяча гемов ну или хз сколько и что-то всегда ломается. При этом я был не разработчиком, но конечным пользователем тех скриптов и с того времени руби для меня - ругательство.
>>977055
Лучше, конечно, тащить все зависимости в проект и устраивать кровь с кишками с помощью вендоринга, а потом сидеть по 5 лет на старой версии библиотеки, которая течет и работает хромая.
Лучше, конечно, тащить все зависимости в проект и устраивать кровь с кишками с помощью вендоринга, а потом сидеть по 5 лет на старой версии библиотеки, которая течет и работает хромая.
>>977098
Карго безальтернативно устанавливается в $HOME/.cargo, так пускай складывает либы в ./cargo/lib как rlib.so.1.2.1, а не компилит для каждого проекта по 200 мб
Карго безальтернативно устанавливается в $HOME/.cargo, так пускай складывает либы в ./cargo/lib как rlib.so.1.2.1, а не компилит для каждого проекта по 200 мб
>>977106
Это растц релейтед проблема.
Это растц релейтед проблема.
>>977098
Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
>>977055
https://github.com/AngryLawyer/rust-sdl2
Вот это получилось собрать на
cargo-0.17.0-nightly (f9e5481 2017-03-03)
rustc 1.16.0 (30cf806ef 2017-03-10)
Ну хотя бы SDL работает, можно попробовать что-то сложнее факториала сделать
https://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мб винчестеров, этого не понять.
>Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
>А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
Стократно плюсую.
Жаль, линуксоидам застрявшим во временах 2мб винчестеров, этого не понять.
>>977204
>>977211
Написал хуйню @ сам себе приплюсовал.
В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Но гоферу не понять.
Хотя гау то же делает с своей GOPATH, у явы каждый пакетный менеджер тащит миллиард зависимостей для себя, в дотнете как в расте, а у динамикопитушков вообще каждый проект — своё хранилище зависимостей.
>>977211
Написал хуйню @ сам себе приплюсовал.
В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Но гоферу не понять.
Хотя гау то же делает с своей GOPATH, у явы каждый пакетный менеджер тащит миллиард зависимостей для себя, в дотнете как в расте, а у динамикопитушков вообще каждый проект — своё хранилище зависимостей.
>>977221
Растц может зафейлиться если ему подсунут rlib'у с той же версией что надо, но скомпилированную растц недельной давности.
Растц может зафейлиться если ему подсунут rlib'у с той же версией что надо, но скомпилированную растц недельной давности.
>>977106
Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
>>977222
Ну, в том же окамле такая же хуйня — но всё сделано в одном хранилище, как предлагает анон выше. Просто попробуй попользоваться такой хуйнёй.
Ну, в том же окамле такая же хуйня — но всё сделано в одном хранилище, как предлагает анон выше. Просто попробуй попользоваться такой хуйнёй.
>>977223
Эти проблемы вроде решает guix
Эти проблемы вроде решает guix
>>977221
Это ты себя имеешь ввиду, или что?
Речь о rust е идет вообще-то.
Тогда все ок.
>Но гоферу не понять.
Это ты себя имеешь ввиду, или что?
Речь о rust е идет вообще-то.
>В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Тогда все ок.
>>977223
А это не норм нефига.
Нафуфик оно так сделано?
Зависимости должны лежать рядом с конкретным проектом.
>Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
А это не норм нефига.
Нафуфик оно так сделано?
Зависимости должны лежать рядом с конкретным проектом.
У меня вопрос, а можно ли на винде да, да сделать так, чтобы все устанавливалось не в юзерскую директорию, а куда скажешь, например, в c:\rust.
>>977253
https://github.com/rust-lang-nursery/rustup.rs/#working-with-custom-toolchains-and-local-builds
Ну ещё посмотри первый пункт в разделе про переменные среды.
https://github.com/rust-lang-nursery/rustup.rs/#working-with-custom-toolchains-and-local-builds
Ну ещё посмотри первый пункт в разделе про переменные среды.
>>977416
В том что какой-то петушок лезет из своего говно-свинарника с ахуительными советами по архитектуре.
В том что какой-то петушок лезет из своего говно-свинарника с ахуительными советами по архитектуре.
37 Кб, 524x483
Почему элемент енума в match не компилится без &?
Говорит
Item::A => 'A',
^^^^^^^ expected &Item, found enum `Item`
= note: expected type `&Item`
found type `Item`
Говорит
Item::A => 'A',
^^^^^^^ expected &Item, found enum `Item`
= note: expected type `&Item`
found type `Item`
>>977504
Наверно потому что &self.world?
Наверно потому что &self.world?
>>978136
Мне вообще вся твоя затея с Enum-ом тут не нравится.
Может лучше сделать trait Cell с методом test() и передавать туда разные реализации этих cell?
https://doc.rust-lang.org/1.0.0-beta/book/static-and-dynamic-dispatch.html#dynamic-dispatch
Мне вообще вся твоя затея с 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 это вообще самое лучшее, что есть в расте вообще, и лучший из менеджеров зависимостей.
Это одна из проблем хаскеля. Там уже и stackage завезли из-за этого, но выглядит это как снепшоты hackage периодические. Как если бы crates.io снепшотили весь целиком и проекты переезжали с одного снепшота на другой. Без этого вообще ад, сегодня компилируется, а завтра майнтайнер мелколибы сломал совместимость на какой-нибудь FreeBSD и сам не заметил.
С cargo есть гарантия, что любой снепшот проекта с какого-нибудь github можно собрать, причем любую его версию, именно с теми библиотеками, с которыми он разрабатывался.
cargo это вообще самое лучшее, что есть в расте вообще, и лучший из менеджеров зависимостей.
По поводу того, что зависимости хранятся в каждом проекте отдельно.
ИМХО, эту проблему нужно решать по аналогии с ccache. Пусть все остается как есть, но еще будет незаметный для юзера кеш, куда будет все собранное складироваться, если нужно линковаться в местный билд симлинком. Малоиспользуемые библиотеки пусть вычищаются. Если симлинк из-за этого сломался, можно и пересобрать. В Rust же пилят инкрементальную компиляцию, у нее кеш будет не глобальный ли случайно?
ИМХО, эту проблему нужно решать по аналогии с ccache. Пусть все остается как есть, но еще будет незаметный для юзера кеш, куда будет все собранное складироваться, если нужно линковаться в местный билд симлинком. Малоиспользуемые библиотеки пусть вычищаются. Если симлинк из-за этого сломался, можно и пересобрать. В Rust же пилят инкрементальную компиляцию, у нее кеш будет не глобальный ли случайно?
>>978213
Принцип иммутабельности as is, чтобы что-то добавить, надо удалить и пересоздать. Все правильно.
>если бы crates.io снепшотили весь целиком
Принцип иммутабельности as is, чтобы что-то добавить, надо удалить и пересоздать. Все правильно.
MUTABLE BORROW
@
MUTABLE MORE THAN ONCE
Сколько не читай доки, ничего написать на этом языке не представляется возможным...
@
MUTABLE MORE THAN ONCE
Сколько не читай доки, ничего написать на этом языке не представляется возможным...
>>978789
Для больше чем 1 мутабельной ссылки есть синхронизационные примитивы, или ансейф, если ты самый умный.
Для больше чем 1 мутабельной ссылки есть синхронизационные примитивы, или ансейф, если ты самый умный.
>>978136
необязательно именовать поля, можно просто Player(PlayerData), доставать данные - как из кортежа (х.0)
>способ покруче
необязательно именовать поля, можно просто Player(PlayerData), доставать данные - как из кортежа (х.0)
>>978789
На Х-ле есть даже специальный блог пост для тех, кто язык как бы осилил, но вообще не вдупляет как написать приложение. Может и для раста такой завезли, поищи.
Хотя самый нормальный совет - читай исходники других проектов.
>ничего написать на этом языке не представляется возможным
На Х-ле есть даже специальный блог пост для тех, кто язык как бы осилил, но вообще не вдупляет как написать приложение. Может и для раста такой завезли, поищи.
Хотя самый нормальный совет - читай исходники других проектов.
82 Кб, 815x859
>>978961
Как сделать swap или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
Как сделать swap или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
>>978996
Не похоже на хорошую практику, даже Pos(i32,i32) с 0,1 вместо x,y как-то стрёмно смотрится
Не похоже на хорошую практику, даже Pos(i32,i32) с 0,1 вместо x,y как-то стрёмно смотрится
>>979224
fn swap<T>(a: T, b: T) -> (Pos, Pos) { (b, a) }
Использовать так:
let (src, dst) = swap(src, dst);
Работать будет с чем угодно. Не благодари.
Клонировать и так можно через .clone().
А так — просто вынеси self.get() из матча в переменную.
Вообще, нужно сделать руководство для нюфагов на картинках — я хз как еще заимствование объяснять.
>Как сделать swap
fn swap<T>(a: T, b: T) -> (Pos, Pos) { (b, a) }
Использовать так:
let (src, dst) = swap(src, dst);
Работать будет с чем угодно. Не благодари.
>или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
Клонировать и так можно через .clone().
А так — просто вынеси self.get() из матча в переменную.
Вообще, нужно сделать руководство для нюфагов на картинках — я хз как еще заимствование объяснять.
>>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 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
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.
>>981738
Ну вот сам себе ответил. Не сделают.
Хотя ты всегда можешь сделать язык компилирующийся в раст (или хотя бы бэкэнд к хаскелю).
>вкусовщина
Ну вот сам себе ответил. Не сделают.
Хотя ты всегда можешь сделать язык компилирующийся в раст (или хотя бы бэкэнд к хаскелю).
>>981734
Плез, в божественном синтаксис охуенен.
Плез, в божественном синтаксис охуенен.
>>981734
Ах да, меня смущает эта задротская зацикленность не неважных вещах.
как будто код только и занимается этим и небо и Аллах и тепловая смерть Вселенной зависят от этой оптимизации, в которой говорится в комментариях к релизу.
Ах да, меня смущает эта задротская зацикленность не неважных вещах.
>some unnecessary run-time parsing
как будто код только и занимается этим и небо и Аллах и тепловая смерть Вселенной зависят от этой оптимизации, в которой говорится в комментариях к релизу.
>>981748
А ты хотел чтобы они тебе каждые 6 недель ахуенные релизы выкатывали? Такой цикл разработки нужен для вылизвания существующего кода.
А так там вообще куча всего что давно нужно было исправить — синтаксис инициализации структур, синтаксис констант, в стабильный карго наконец-то внесли фьючи, стэктрейсы помещаются в 1 экран.
а с этой новой хуиткой, не тратящей время на парсинг ип, можно писать убер быстрые сканеры диапазонов ип для локалхоста, ну чо ты
А ты хотел чтобы они тебе каждые 6 недель ахуенные релизы выкатывали? Такой цикл разработки нужен для вылизвания существующего кода.
А так там вообще куча всего что давно нужно было исправить — синтаксис инициализации структур, синтаксис констант, в стабильный карго наконец-то внесли фьючи, стэктрейсы помещаются в 1 экран.
а с этой новой хуиткой, не тратящей время на парсинг ип, можно писать убер быстрые сканеры диапазонов ип для локалхоста, ну чо ты
>>982031
C тоже в него компилится. А в гнутом компилире компилится в их GIMPLE.
C тоже в него компилится. А в гнутом компилире компилится в их GIMPLE.
>>982031
Ходят слухи, что благодаря своей охуенной системе типов Rust теоретически может предоставлять LLVM информацию, которая позволит производить всякие продвинутые оптимизации. Так что с развитием и Rust, и LLVM вполне возможно, что Rust станет в местами быстрее сишечки/крестов.
Ходят слухи, что благодаря своей охуенной системе типов Rust теоретически может предоставлять LLVM информацию, которая позволит производить всякие продвинутые оптимизации. Так что с развитием и Rust, и LLVM вполне возможно, что Rust станет в местами быстрее сишечки/крестов.
LLVM - это хайпнутое г и он никогда не будет быстрее гцц или даже Borland C++
Может, за счет убер-системы (которая просто хитро переносит часть рантайма на время компиляции) он будет где-то быстрее С или плюсов, но это лишь частные случаи, где-то и Hsakell быстрее С, такие кейсы любят находить фанбои того или иного языка, но общая картина всегда будет такой, что языки более высокого уровня медленнее С/С++.
Может, за счет убер-системы (которая просто хитро переносит часть рантайма на время компиляции) он будет где-то быстрее С или плюсов, но это лишь частные случаи, где-то и Hsakell быстрее С, такие кейсы любят находить фанбои того или иного языка, но общая картина всегда будет такой, что языки более высокого уровня медленнее С/С++.
>>982152
Потому что высокоуровневость и скорость разработки всегда меняется на скорость выполнения.
На пыхе ты можешь за 20 минут что-то высрать даже будучи учеником пятого класса, но скорость будет меньше, чем у правильно написанного кода на С, решающего аналогичную задачу.
Потому что высокоуровневость и скорость разработки всегда меняется на скорость выполнения.
На пыхе ты можешь за 20 минут что-то высрать даже будучи учеником пятого класса, но скорость будет меньше, чем у правильно написанного кода на С, решающего аналогичную задачу.
>>982155
Причем тут пхп? Я думал мы ллвм и гцц сравниваем. И гцц далеко не везде обгоняет ллвм/цланг.
Что-то мешает компилятору высокоуровневого языка высрать такой же машинный код который высирает гцц?
Причем тут пхп? Я думал мы ллвм и гцц сравниваем. И гцц далеко не везде обгоняет ллвм/цланг.
> высокоуровневость
Что-то мешает компилятору высокоуровневого языка высрать такой же машинный код который высирает гцц?
А нахуй нужны эти кланги, ЛЛВМ?
Есть гцц, уже довольно давно. Какой смысл в этой херне?
Есть гцц, уже довольно давно. Какой смысл в этой херне?
>>982179
Для нового языка проще запилить фронт для llvm, чем пилить новый компилятор с нуля
Для нового языка проще запилить фронт для llvm, чем пилить новый компилятор с нуля
>>982179
Подальше от Штульмана.
Подальше от Штульмана.
>>982135
Ну он уже местами быстрее судя по базовым тестам.
Ну он уже местами быстрее судя по базовым тестам.
>>982151
Тогда почему кланг уже разъебывает гцц?
http://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=1
Тогда почему кланг уже разъебывает гцц?
http://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=1
>>982157
Если говорить про php подобные, машинный код можно сделать только если вставить в бинарник интерпретатор целиком
Если говорить про php подобные, машинный код можно сделать только если вставить в бинарник интерпретатор целиком
>>982151
Ору с тебя. LLVM IR не высокоуровневее чем IR GCC (не помню как там он называется). Вся разница в том что инфраструктура LLVM более современная, универсальная и лишённая некоторых легаси-косяков GCC.
Ещё раз, для тупеньких: LLVM IR - не высокоуровневый язык. Изначально вся инфраструктура Clang + LLVM вообще создавалась для компиляции C, и уже потом LLVM стали использовать как бэкенд для других языков.
Ору с тебя. LLVM IR не высокоуровневее чем IR GCC (не помню как там он называется). Вся разница в том что инфраструктура LLVM более современная, универсальная и лишённая некоторых легаси-косяков GCC.
Ещё раз, для тупеньких: LLVM IR - не высокоуровневый язык. Изначально вся инфраструктура Clang + LLVM вообще создавалась для компиляции C, и уже потом LLVM стали использовать как бэкенд для других языков.
>>982205
Найти пример, где кто-то кого-то разъебывает всегда можно.
Например, самый быстрый сервер статических файлов написан вроде на D или Haskell, но это не значит, что в целом эти языки быстрее С (язык с GC в принципе не может быть быстрее языка с ручным управлением памятью).
>>982283
Высокоуровневый язык - это Rust.
LLVM - это просто высер. Для хипстеров штучка, понимаешь? Поигрался, м.б. написал свой компилятор для своей джавы, где вместо слова class будет хуй и тип не перед, а после идентификатора.
>Тогда почему кланг уже разъебывает гцц?
Найти пример, где кто-то кого-то разъебывает всегда можно.
Например, самый быстрый сервер статических файлов написан вроде на D или Haskell, но это не значит, что в целом эти языки быстрее С (язык с GC в принципе не может быть быстрее языка с ручным управлением памятью).
>>982283
Высокоуровневый язык - это Rust.
LLVM - это просто высер. Для хипстеров штучка, понимаешь? Поигрался, м.б. написал свой компилятор для своей джавы, где вместо слова class будет хуй и тип не перед, а после идентификатора.
Да кстати Rust - это тоже высер для хипстеров, что видно даже по лого. Это для тех, кто хочет почувствовать себя ололо-инжинером, который манипулирует байтиками и управляет памятью через ансейф, но который при этом не осилил C/C++.
>>982343
Охуеть, какой - то чухан мало того, что несёт какой-то бред, да еще использует слово "хипстер", как оскорбление. Ты, блядь, и хипстера поди не видел в своём залупинске, а туда же. Аргументации 0 (ноль), компетенции 0 (ноль), а лозунгов и пафоса на серьезных щщах на весь тред хватит.
Охуеть, какой - то чухан мало того, что несёт какой-то бред, да еще использует слово "хипстер", как оскорбление. Ты, блядь, и хипстера поди не видел в своём залупинске, а туда же. Аргументации 0 (ноль), компетенции 0 (ноль), а лозунгов и пафоса на серьезных щщах на весь тред хватит.
>>982357
А какая тебе нужна аргументация, если весь механизм владения-заимствования - это подпорка для скорбных умом, у которых на языках с ручным управлением памятью будут утечки. Этим товарищам на джаве бы писать, но они хотят ощутить себя системными архитекторами и вот для них придумали эту игрушку.
А какая тебе нужна аргументация, если весь механизм владения-заимствования - это подпорка для скорбных умом, у которых на языках с ручным управлением памятью будут утечки. Этим товарищам на джаве бы писать, но они хотят ощутить себя системными архитекторами и вот для них придумали эту игрушку.
>>982345
Никакой хипстер не осилит раст, это вообще язык не для людей. С++ немного проще из-за мутабельности и слабой типизации, пока не дойдёшь до шаблонов, которые тоже не для людей и никто их не понимает полностью.
Никакой хипстер не осилит раст, это вообще язык не для людей. С++ немного проще из-за мутабельности и слабой типизации, пока не дойдёшь до шаблонов, которые тоже не для людей и никто их не понимает полностью.
>>982362
Что в нем сложного?
Понял заимствование, смарт-указатели и все.
Проще, чем ловить секфолты.
Так сложно вставить слово mut, да?
Слабая типизация создает только проблемы.
>это вообще язык не для людей
Что в нем сложного?
Понял заимствование, смарт-указатели и все.
Проще, чем ловить секфолты.
> С++ немного проще из-за мутабельности
Так сложно вставить слово mut, да?
>слабой типизации
Слабая типизация создает только проблемы.
В расте синтаксис ебанутый и отягощенный и совсем не однородный. Да и разве не было языков с линейными типами уже? Чем раст лучше них?
>>982343
Но там не один пример, а целая кипа примеров, где гцц сосет. Так что уж просто это скорее тенденция, чем исключение.
Но там не один пример, а целая кипа примеров, где гцц сосет. Так что уж просто это скорее тенденция, чем исключение.
>>982360
Эта игрушка по скорости ни чем не уступает крестам, но при этом меморисейф, что является ключевой килер фичей.
>вот для них придумали эту игрушку.
Эта игрушка по скорости ни чем не уступает крестам, но при этом меморисейф, что является ключевой килер фичей.
>>982371
Блять, додик, что ты вообще делаешь в программировании? Это тоже самое , что shared, unique и weak указатели.
Блять, додик, что ты вообще делаешь в программировании? Это тоже самое , что shared, unique и weak указатели.
>>982357
Хипстер - это как раз тот, кто с умным видом втыкает в "современные технологии". Примеры говна, которое любит хипстота - это Scala (и обязательно с экстенсивным использованием scalaz), кложа и т.д. При этом ладно бы они действительно что-то в этом понимали, а то большей частью скидывают друг другу статьи на хабре "как функциональное программирование помогло нашей компании".
И Rust примерно для таких, кто хочет играться с байтиками, но на сях без секфолтов не может hello world написать.
>>982388
Ахахаха.
>>982385
Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Обычно в таких примерах просто специально оставляют простор для оптимизации и потом говорят, что их (язык, компилятор) быстрее.
Хипстер - это как раз тот, кто с умным видом втыкает в "современные технологии". Примеры говна, которое любит хипстота - это Scala (и обязательно с экстенсивным использованием scalaz), кложа и т.д. При этом ладно бы они действительно что-то в этом понимали, а то большей частью скидывают друг другу статьи на хабре "как функциональное программирование помогло нашей компании".
И Rust примерно для таких, кто хочет играться с байтиками, но на сях без секфолтов не может hello world написать.
>>982388
>Эта игрушка по скорости ни чем не уступает крестам
Ахахаха.
>>982385
Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Обычно в таких примерах просто специально оставляют простор для оптимизации и потом говорят, что их (язык, компилятор) быстрее.
>>982395
Мы придумали проблему а теперь будем с ней бороться.
>Это тоже самое , что shared, unique и weak указатели.
Мы придумали проблему а теперь будем с ней бороться.
>>982424
Ты где толстый рантайм у раста увидел-то?
Ты где толстый рантайм у раста увидел-то?
>>982362
Ну ты-то явно ни Rust и C++ дальше хелловорода не знаешь. Как будто в Rust нет мутабельности, лол.
Ну ты-то явно ни Rust и C++ дальше хелловорода не знаешь. Как будто в Rust нет мутабельности, лол.
>>982360
Ох уж это раздутое чсв. Все такие охуенные, код сразу без ошибок пишут. Статическая типизация им не нужна, потому что зачем нам типобезопасность, мы и так код правильный пишем. Система владений-заимствований нам не нужна, потому что зачем нам безопасность работы с памятью, мы и так код правильный пишем. Охуеть просто, иди подойди к зеркалу и подрочи на себя, раз ты такой охуенный кодер.
Ох уж это раздутое чсв. Все такие охуенные, код сразу без ошибок пишут. Статическая типизация им не нужна, потому что зачем нам типобезопасность, мы и так код правильный пишем. Система владений-заимствований нам не нужна, потому что зачем нам безопасность работы с памятью, мы и так код правильный пишем. Охуеть просто, иди подойди к зеркалу и подрочи на себя, раз ты такой охуенный кодер.
>>982343
Я тебе сейчас секрет открою, но везде так делают потому что:
а) Компактнее записывать модификаторы (вместо всяких const out int hui просто var hui);
б) Легче и быстрее парить;
в) Лаконичнее живёт с выводом типов.
Даже в твоём говне так это работает.
>>982463
Жеманный опять трет топит, луль.
>и тип не перед, а после идентификатора.
Я тебе сейчас секрет открою, но везде так делают потому что:
а) Компактнее записывать модификаторы (вместо всяких const out int hui просто var hui);
б) Легче и быстрее парить;
в) Лаконичнее живёт с выводом типов.
Даже в твоём говне так это работает.
>>982463
>в говнище вообще нет возможности контролировать указатели, нету и проблемы, кококо
Жеманный опять трет топит, луль.
>>982495
Ага, а потом годами выскребают зеродеи.
Ага, а потом годами выскребают зеродеи.
>>982345
Дело не в осилил или не осилил C/C++, а в том что работать с Rust тупо приятнее (не говоря уже о том что безопаснее). Это касается как самого языка (клёвая система типов, нормальный match, if/match as expression, модули, гигиенические макросы и т. д.), так и инфраструктуры (нормальный пакетный менеджер, например). Если есть возможность использовать инструмент который использовать приятнее, то что в этом плохого, м?
Дело не в осилил или не осилил C/C++, а в том что работать с Rust тупо приятнее (не говоря уже о том что безопаснее). Это касается как самого языка (клёвая система типов, нормальный match, if/match as expression, модули, гигиенические макросы и т. д.), так и инфраструктуры (нормальный пакетный менеджер, например). Если есть возможность использовать инструмент который использовать приятнее, то что в этом плохого, м?
>>982343
LLVM - это охуенно мощная инфраструктура, в разработку которой было положено дохуища человекочасов. И сейчас LLVM гораздо более зрелая и удобная в использовании система, чем GCC. Начиная с того что LLVM легче расширяется и имеет более внятный дизайн и заканчивая тем что у LLVM в принципе есть внятная документация.
Скажем если кому-то нужен компилятор той же сишки для кастомного процессора (и это не выдуманная мной задача), то самый адекватный вариант - скачать сорцы LLVM, открыть документацию по написанию бэкендов к LLVM и сесть писать бэкенд. Документация вполне ок, хотя информации конечно меньше чем для написания фронтендов.
LLVM - это охуенно мощная инфраструктура, в разработку которой было положено дохуища человекочасов. И сейчас LLVM гораздо более зрелая и удобная в использовании система, чем GCC. Начиная с того что LLVM легче расширяется и имеет более внятный дизайн и заканчивая тем что у LLVM в принципе есть внятная документация.
Скажем если кому-то нужен компилятор той же сишки для кастомного процессора (и это не выдуманная мной задача), то самый адекватный вариант - скачать сорцы LLVM, открыть документацию по написанию бэкендов к LLVM и сесть писать бэкенд. Документация вполне ок, хотя информации конечно меньше чем для написания фронтендов.
>>982509
Ты самое главное забыл — LLVM лицензирована MIT, а не ЖоПаеЛью, и Шульман со своими юристами не придёт к тебе если ты решишь продавать и распространять свой софт не открывая исходников.
Ты самое главное забыл — LLVM лицензирована MIT, а не ЖоПаеЛью, и Шульман со своими юристами не придёт к тебе если ты решишь продавать и распространять свой софт не открывая исходников.
>>982500
ставлю тип после идентификатора, законом не запрещено, парсить на 95% быстрее и легче
ставлю тип после идентификатора, законом не запрещено, парсить на 95% быстрее и легче
>>982514
Иди лучше к жавадаунам, они до сих пор пишут 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>());
Скоро у пайка начнется деменция и в говне настанут такие же темные времена.
>>982517
Охуенно же.
>AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());
Охуенно же.
>>982527
Нет, и в ближайшие 3-4 года до жявы 10 не предвидится.
Нет, и в ближайшие 3-4 года до жявы 10 не предвидится.
>>982377
Двачую этого.
Двачую этого.
>>982377
Ну был и есть ATS. Официальный саппорт и форум на епонском, доков 0, только примеры факториалов, на языке писать без выдрачивания теорката нереально (он куда сложнее хачкеля, больше похож на теоремпрувер чем на яп) — тайная военная разработка страны восходящего солнца. Теперь как сам думаешь, чем?
Ну был и есть ATS. Официальный саппорт и форум на епонском, доков 0, только примеры факториалов, на языке писать без выдрачивания теорката нереально (он куда сложнее хачкеля, больше похож на теоремпрувер чем на яп) — тайная военная разработка страны восходящего солнца. Теперь как сам думаешь, чем?
>>982517
Тебе видать какие-то нехорошие жабисты попались, когда еще маленьким был, вот и осталась фобия хотя если судить по тому что пишешь, тот еще джуниор. Можешь показать на проекте в гитхабе, за какие места тебя трогало?
Тебе видать какие-то нехорошие жабисты попались, когда еще маленьким был, вот и осталась фобия хотя если судить по тому что пишешь, тот еще джуниор. Можешь показать на проекте в гитхабе, за какие места тебя трогало?
>>982563
Помню помню, этот язык с нескушными идентификаторами вроде viewt@ype и с различным цветовым кодированием разных категорий кода.
Даже порывался учить, но по модулю ебанутости автора не дотянул.
Помню помню, этот язык с нескушными идентификаторами вроде viewt@ype и с различным цветовым кодированием разных категорий кода.
Даже порывался учить, но по модулю ебанутости автора не дотянул.
>>982675
Каноничные - да, но надо же орать, что не хипстор и что твоя технологие неебаться инжынерная и ты прямо байтики ксоришь и у тебя все на указателях, естественно, умных, а еще иммутабельность и вообще.
Каноничные - да, но надо же орать, что не хипстор и что твоя технологие неебаться инжынерная и ты прямо байтики ксоришь и у тебя все на указателях, естественно, умных, а еще иммутабельность и вообще.
>>982675
Я скажу больше, у каждого свои представления о каноничных хипстерах. Границы определяемого расширяются с изменением определяющего. Вот у нас в компании, уж настолько настолько хипстерский народ (разной временной градации от протохипстеров с зеркалками до постхипстеров с подворотами итп, а все туда же - нет, да всплывет жалоба на хипстеров. Хоть ультрафильтр заводи.
Я скажу больше, у каждого свои представления о каноничных хипстерах. Границы определяемого расширяются с изменением определяющего. Вот у нас в компании, уж настолько настолько хипстерский народ (разной временной градации от протохипстеров с зеркалками до постхипстеров с подворотами итп, а все туда же - нет, да всплывет жалоба на хипстеров. Хоть ультрафильтр заводи.
48 Кб, 1699x484
Не могу понять, как вернуть введенный с клавиатуры код в срез и вернуть его из функции mesinput. Лучший ли это способ вообще - возвращать ввод с клавиатуры в качестве среза, чтобы потом отправить его через tcp? Код пикрелейтед.
>>986142
Этой какой-то цпп с синтаксисом раста. С кучей ошибок и, как результат, даже не скомпилируется.
Этой какой-то цпп с синтаксисом раста. С кучей ошибок и, как результат, даже не скомпилируется.
>>986286
Это новый стиль жеманного, постить код в скриншоте и не реагировать на ответы, выше посмотри.
У нас тут вместо треда какая-то игра в мафию, только вместо мафии жеманный, лул.
Это новый стиль жеманного, постить код в скриншоте и не реагировать на ответы, выше посмотри.
У нас тут вместо треда какая-то игра в мафию, только вместо мафии жеманный, лул.
>>963997
>>964005
Нахрена вам IDE, долбоёбы? Код пишут с помощью рук и мозга в первую очередь. Если проект насколько запутан, что в нём нельзя ориентироваться без IDE - это говнокод, который надо выкинуть нахуй. Собирать нужно в консоли, текстовых редакторов с подсветкой для раста предостаточно, во многих даже автокомплит и линтинг есть.
>>964005
Нахрена вам IDE, долбоёбы? Код пишут с помощью рук и мозга в первую очередь. Если проект насколько запутан, что в нём нельзя ориентироваться без IDE - это говнокод, который надо выкинуть нахуй. Собирать нужно в консоли, текстовых редакторов с подсветкой для раста предостаточно, во многих даже автокомплит и линтинг есть.
>>986603
Ебать жеманного прорвало.
У говна иде того же качества, что сейчас у раста. а плагин для жидеи кстате лучше гогланда, или как минимум его билда месячной давности
Ебать жеманного прорвало.
У говна иде того же качества, что сейчас у раста. а плагин для жидеи кстате лучше гогланда, или как минимум его билда месячной давности
>>986460
Да тут пол-треда, если не больше - "жеманные". Как мимо пройти и не зайти, поглумиться.
Да тут пол-треда, если не больше - "жеманные". Как мимо пройти и не зайти, поглумиться.
>>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? В офф. документации, не объяснен доступным языком этот момент.
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, тебе же компилятор прямо написал.
Читай файл в успешной ветке матча, и замени p на pa, тебе же компилятор прямо написал.
>>989233
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 при этом должен возвращать одинаковые по типу значения, но как это сделать, я не знаю.
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 при этом должен возвращать одинаковые по типу значения, но как это сделать, я не знаю.
>>989345
https://play.rust-lang.org/?gist=78cdf63a1d850b61ea2a5c909547c065&version=stable&backtrace=1 match версия. Ветки match обрабатываются без проблем, потому что обе возвращают нихуя.
https://doc.rust-lang.org/book/if-let.html тут подробнее про if let
https://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
Мало того что код говняный (из-за ублюдского синтаксиста, твоей вины нет), так ещё падучий.
>>989321
Ты что больной?
Запускай свою хуйню в цикле и выходи в ветке ok, а в альтернативной выводи сообщение об ошибке.
Иначе ты просто уйдешь в рекурсию. И вообще, какой придурок может рекурсивно вызывать main, сколько живу а такого наверное не видел.
> Err(_) => main()
Ты что больной?
Запускай свою хуйню в цикле и выходи в ветке ok, а в альтернативной выводи сообщение об ошибке.
Иначе ты просто уйдешь в рекурсию. И вообще, какой придурок может рекурсивно вызывать main, сколько живу а такого наверное не видел.
>>989709
Юзаю плагин для eclipse, все вполне нормально автокомплитится.
Юзаю плагин для eclipse, все вполне нормально автокомплитится.
>>989496
Ору бля.
В говне такое тоже не сложно делается, расслабься.
>челик пытается открыть файл которого нет
>потом вызывает эту функцию (причём точку взода) бесконечно
Ору бля.
В говне такое тоже не сложно делается, расслабься.
>>989709
Плагин для идеи уже в отличном состоянии — всё, от рефакторингов до автокомплита и линтинга с отслеживанием лайфтаймов уже есть (только вложенные макросы парсить не умеет), скоро даже дебуггер даже будет.
Алсо, есть RLS если не хочешь жаваподелий, с примерно тем же функционалом (но вообще не работает с макросами и анализов, нужно поебаться с настройкой и у линтера явно меньше).
Плагин для идеи уже в отличном состоянии — всё, от рефакторингов до автокомплита и линтинга с отслеживанием лайфтаймов уже есть (только вложенные макросы парсить не умеет), скоро даже дебуггер даже будет.
Алсо, есть RLS если не хочешь жаваподелий, с примерно тем же функционалом (но вообще не работает с макросами и анализов, нужно поебаться с настройкой и у линтера явно меньше).
>>989716
Такое можно сделать почти на любом языке, нужны только кривые руки, ничего более.
>В говне такое тоже не сложно делается, расслабься.
Такое можно сделать почти на любом языке, нужны только кривые руки, ничего более.
>>989712
Я знаю, что использовать рекурсивный вызов функции является злом, но никак не могу понять как сделать так, чтобы при неверном вводе предлагалось ввести текст заново, а не делать panic.
Я знаю, что использовать рекурсивный вызов функции является злом, но никак не могу понять как сделать так, чтобы при неверном вводе предлагалось ввести текст заново, а не делать panic.
>>990074
https://doc.rust-lang.org/book/guessing-game.html самый древний туториал по расту как раз это и объясняет.
https://doc.rust-lang.org/book/guessing-game.html самый древний туториал по расту как раз это и объясняет.
>>990074
Я же вроде написал - делай это в цикле и выходи с него при успехе.
Я же вроде написал - делай это в цикле и выходи с него при успехе.
281 Кб, 1312x585
Помогите с TOML. Пытаюсь выполнить cargo build и выдает couldn`t parse as TOML. Насколько я понял файл TOML сгенерирован самим cargo для одной из зависимостей. В чем проблема? В cargo самой программы в [dependencies] только строка hyper="*".
>>992960
Да нет, долбоёб, он твоим больным мозгом генерируется. Сначала ты стёк переполнял рекурсией входной точки, теперь в заголовки конфигово томла пихашь куски кода.
Да нет, долбоёб, он твоим больным мозгом генерируется. Сначала ты стёк переполнял рекурсией входной точки, теперь в заголовки конфигово томла пихашь куски кода.
>>957553
иди нахуй со своим NT-говном и миниксом с овердохуя сисколлов. в редоксе ровно 31 сисколла, там даже сокеты через open создаются, как файлы. больше не нужно.
иди нахуй со своим NT-говном и миниксом с овердохуя сисколлов. в редоксе ровно 31 сисколла, там даже сокеты через open создаются, как файлы. больше не нужно.
>>992978
Ну так это ты и есть, лол.
Минутка грамотности: генерируются .lock файлы, а не томлы, ti obosralsya.
Ну так это ты и есть, лол.
Минутка грамотности: генерируются .lock файлы, а не томлы, ti obosralsya.
>>993197
И зачем нам помогать тебе заниматься фистингом?
И зачем нам помогать тебе заниматься фистингом?
72 Кб, 768x596
>>993197
зависимости на библиотеки нужно добавлять в Cargo.toml своего проекта, cargo install ставит некоторые програмки типа rustfmt и плагинов под cargo, но не либы
зависимости на библиотеки нужно добавлять в Cargo.toml своего проекта, cargo install ставит некоторые програмки типа rustfmt и плагинов под cargo, но не либы
>>956909 (OP)
Друзья, раст мертв при рождении , переходите лучше в Golang тред, пока не поздно!
Друзья, раст мертв при рождении , переходите лучше в Golang тред, пока не поздно!
>>993454
golang
идеальный язык для вебмакак. что в голанге хорошего, это то, что он простой и что в нем искоробки forkjoin
golang
>gc
>дженериков нет
>мутексы не связаны с данными, которые они охраняют
>проброс ошибок по стеку анальная мука
>неюзабелен для написания драйверов
>нет паттерн матчинга
>система типов какая-то параша
>компилятор не может доказать отсутствие одновременного доступа к не-атомным данным
>код сложнее хеловорлда на голанге похож на вырвиглазный кал
>...
идеальный язык для вебмакак. что в голанге хорошего, это то, что он простой и что в нем искоробки forkjoin
>>993505
Ваше мнение очень важно для нас
Ваше мнение очень важно для нас
От раста будет профит, если мне хочется ради фана васянить свою 2D rpg на нём, а не на сях?
>>994322
На питоне или жсе нахуячь. В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой (которая очень нужна в твоей 2д залупе). а вообще, иди ешь торты.
На питоне или жсе нахуячь. В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой (которая очень нужна в твоей 2д залупе). а вообще, иди ешь торты.
80 Кб, 1920x1080
>>994326
То, что мне и нужно.
HelloWorld готов, теперь можно и изъёбствами языка обмазаться.
>В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой
То, что мне и нужно.
HelloWorld готов, теперь можно и изъёбствами языка обмазаться.
>>994340
пишу в свободное время игрушку поигратся на вулкане на расте, раст таки заебись, советую
пишу в свободное время игрушку поигратся на вулкане на расте, раст таки заебись, советую
Аноны, кто учит раст, радуйтесь, у вас есть cargo - сама охуенная система сборки и управления зависимостями, сеьёзно. Я тут вкатываюсь в кложу, язык для своих целей ящитаю годный, писать на нём приятно, но вот сборка это ад, по сравнению с растаманским cargo и даже питонячьим setuptools. У меня всё.
>>994514
И чем он лучше lein?
И чем он лучше lein?
>>994514
На большинстве статически типизированых языков сборка это ад. Либо у тебя длиннющие и неудобные makefile.am, либо cmakefiles.txt, где забываешь уже через полгода что для чего инклудил. В мире java это хотя бы имеет более человеческое лицо, спасибо jetbrains за труды.
На большинстве статически типизированых языков сборка это ад. Либо у тебя длиннющие и неудобные makefile.am, либо cmakefiles.txt, где забываешь уже через полгода что для чего инклудил. В мире java это хотя бы имеет более человеческое лицо, спасибо jetbrains за труды.
>>994516
Жява-энтерпрайз-оверинжиниред-говнище.
>>994514
Ты как нибудь с окамлом поиграйся. Поверь, это пожалуй самый ахуительно собирающийся язык.
>>994603
При чём тут статика-то, долбоёб? Это у всех компилируемых языков с легасиговном вместо системы сборки такая проблема.
В тех же плюсах (священное поприще легасиговна) дохуя билд систем вроде Qbs и meson, которые по большому счёту не сильно-то и уступают cargo.
Жява-энтерпрайз-оверинжиниред-говнище.
>>994514
Ты как нибудь с окамлом поиграйся. Поверь, это пожалуй самый ахуительно собирающийся язык.
>>994603
При чём тут статика-то, долбоёб? Это у всех компилируемых языков с легасиговном вместо системы сборки такая проблема.
В тех же плюсах (священное поприще легасиговна) дохуя билд систем вроде Qbs и meson, которые по большому счёту не сильно-то и уступают cargo.
>>994603
Ну я пока для упражнений из K&R накатал скрипт на петоне который генерирует ниндзя-файл. Очень удобно и прозрачно, вообще в последнее время часто вместо систем сборки использую самописные скрипты, потому что мне нравится полностью контроллировать процесс сборки. Вот в leiningen я не чувствую что я вообще что-то контроллирую, какая-то непонятная медленная не работающая так как мне нужно магия. Попробую в Boot вкатиться, говорят, он получше.
Ну я пока для упражнений из K&R накатал скрипт на петоне который генерирует ниндзя-файл. Очень удобно и прозрачно, вообще в последнее время часто вместо систем сборки использую самописные скрипты, потому что мне нравится полностью контроллировать процесс сборки. Вот в leiningen я не чувствую что я вообще что-то контроллирую, какая-то непонятная медленная не работающая так как мне нужно магия. Попробую в Boot вкатиться, говорят, он получше.
>>994656
Вот огромная проблема всех этих крестовых билд-систем в том, что нет какого-то единого репозитория пакетов, как в расте. Так что или клади зависимости в git submodules, или довольствуйся теми пакетами, которые есть в репозитории используемой билд-системы, или сам упаковывай пакеты, или я не знаю что ещё. В расте же сделали сразу по-человечески, и это охуенно.
Вот огромная проблема всех этих крестовых билд-систем в том, что нет какого-то единого репозитория пакетов, как в расте. Так что или клади зависимости в 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()
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()
5 Кб, 527x47
Что это за хрень получается? Компилятор говорил, что для &&{integer} нет оператора ==, добавил две звёздочки - работает. Ничего не понял.
>>1001734
Мудило с картинками, ты опять на связь выходишь?
Наверно потому что звездочка перед идентификатором означает разыменование указателя/ссылки.
Мудило с картинками, ты опять на связь выходишь?
>что для &&{integer} нет оператора ==, добавил две звёздочки - работает
Наверно потому что звездочка перед идентификатором означает разыменование указателя/ссылки.
>>1002746
ллвм на цпп. растц на расте
ллвм на цпп. растц на расте
>>1003334
Потому что ты - спермовор у спермы свой особенный и единственный линкер и набор библиотек (всякая символы для системных вызовов, динамические библиотеки и прочая хуйня без которой ты буквально хэловорд не соберешь).
Он собственно требуется всеми известными мне компиляторами (врде д, пони, окамла). Разве что го-велосипедисты написали свой, который срет бинарями хэловордов по 10 мб на которых любой дизасемблер падает с ООМ.
Потому что ты - спермовор у спермы свой особенный и единственный линкер и набор библиотек (всякая символы для системных вызовов, динамические библиотеки и прочая хуйня без которой ты буквально хэловорд не соберешь).
Он собственно требуется всеми известными мне компиляторами (врде д, пони, окамла). Разве что го-велосипедисты написали свой, который срет бинарями хэловордов по 10 мб на которых любой дизасемблер падает с ООМ.
>>1003436
>>1003376
Да мне это тоже нравится, братишка.
>>1003376
>который срёт бинарями хэловордов по 10 мб
>и хуй тебе а не нормальный dead code elimination, будем бить по рукам за неиспользованные импорты
>хуй тебе а не link time optimization, profile guided optimization, межпроцедурный анализ и всё остальное, прямо или косвенно требующее поддержки линкера
Да мне это тоже нравится, братишка.
Поржал с вас.
Мимо эйфеле-господин
Мимо эйфеле-господин
Поржал с эйфеле-го-раст борщехлёбов.
Мимо-цпп-боярен
Мимо-цпп-боярен
>>1005400
Ну да, не то что в расте. Можно пельмени сварить там, или чай заварить, пока всё линукется - разработчик никогда не останется голодным
Ну да, не то что в расте. Можно пельмени сварить там, или чай заварить, пока всё линукется - разработчик никогда не останется голодным
>>1005753
Ты бы ещё рассказал ему что си имеет текстовый препроцессор, каждый раз заново парсит все инклуды и просто не укладывается в какой нибудь LL(1) с лукапом в 1 символ как его говно, а расту для чека каждого лайфтайма нужно обходить графы всех затронутых функций и объектов для каждой хуитки и заниматься прочим статическим анализом.
>>1005490
Тем временем, в говне из модуля функции, структуры и (!) переменные (!) импортируются по регистру первой, сука, буквы. Повар, какого хуя ты вообще рот открываешь?
>И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.
Ты бы ещё рассказал ему что си имеет текстовый препроцессор, каждый раз заново парсит все инклуды и просто не укладывается в какой нибудь LL(1) с лукапом в 1 символ как его говно, а расту для чека каждого лайфтайма нужно обходить графы всех затронутых функций и объектов для каждой хуитки и заниматься прочим статическим анализом.
>>1005490
Тем временем, в говне из модуля функции, структуры и (!) переменные (!) импортируются по регистру первой, сука, буквы. Повар, какого хуя ты вообще рот открываешь?
Бляя, растоблядки, объясните мне, в чём разница между immutable variable и const?
Всякие пидоры на стэковерфлоу пишут "НУ ТИП ЭТ ТЫ ПРИВЫК К С++!!!))) В РАСТЕ ВСЁ ПО-ДРУГОМУ!))) ПЕРЕМЕННЫЕ ТИПА НЕ МЕНЯЮТСЯ))"
Какого хуя, если variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени. Какого хуя всё так тупо?
Всякие пидоры на стэковерфлоу пишут "НУ ТИП ЭТ ТЫ ПРИВЫК К С++!!!))) В РАСТЕ ВСЁ ПО-ДРУГОМУ!))) ПЕРЕМЕННЫЕ ТИПА НЕ МЕНЯЮТСЯ))"
Какого хуя, если variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени. Какого хуя всё так тупо?
>>1008074
Если бы Страуструп стал женщиной и его отымел Милнер, то вместо C++ появился бы Rust.
В общем, я что сказать хотел... Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
Если бы Страуструп стал женщиной и его отымел Милнер, то вместо C++ появился бы Rust.
В общем, я что сказать хотел... Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
>>1008074
const в расте — это как дефайн в сях, просто подставляемое значение.
И var в русте нет, здесь только let, шо как бы намекает дебилам как ты.
const в расте — это как дефайн в сях, просто подставляемое значение.
И var в русте нет, здесь только let, шо как бы намекает дебилам как ты.
>>1008108
Все ML-и дохлые, к сожалению, даже окамл, который хз сколько лет развивают. Он сейчас только с точки зрения научного интереса тыканья палочкой.
Д — я надеюсь когда нибудь его зотя бы до состояния раста допилят, языку десять лет а он сырой как твоя мать на концерте Маликова.
>Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
Все ML-и дохлые, к сожалению, даже окамл, который хз сколько лет развивают. Он сейчас только с точки зрения научного интереса тыканья палочкой.
Д — я надеюсь когда нибудь его зотя бы до состояния раста допилят, языку десять лет а он сырой как твоя мать на концерте Маликова.
>>1008134
Он релизнулся раньше чем ты родился, так с того времни никуда не сдвинувшись с SML 97, куда там.
Если хочется ML-я — тут есть окамл который хотя бы развивается, и куча трупов.
Он релизнулся раньше чем ты родился, так с того времни никуда не сдвинувшись с SML 97, куда там.
Если хочется ML-я — тут есть окамл который хотя бы развивается, и куча трупов.
>>1008134
Ну кроме окамла ещё F#, но там больше шарпа в смысле парадигмы (хотя сексуальные хачкель операторы вида <><[][——€•^`>> на месте).
Ну кроме окамла ещё F#, но там больше шарпа в смысле парадигмы (хотя сексуальные хачкель операторы вида <><[][——€•^`>> на месте).
>>1008074
Распространённое заблуждение. Слово "переменная" пришло из математики, где никакого изменения во времени оно не означает. Оно означает что значение может меняться в зависимости от исходных данных (то есть, по-нашему, от запуска к запуску). А вот "константа" в математике - это то, что не меняется вообще никогда, с любыми исходными данными. Собственно, const в Rust это как раз значение известное на этапе компиляции, тогда как значение переменной вычисляется уже в рантайме.
> variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени
> во времени
Распространённое заблуждение. Слово "переменная" пришло из математики, где никакого изменения во времени оно не означает. Оно означает что значение может меняться в зависимости от исходных данных (то есть, по-нашему, от запуска к запуску). А вот "константа" в математике - это то, что не меняется вообще никогда, с любыми исходными данными. Собственно, const в Rust это как раз значение известное на этапе компиляции, тогда как значение переменной вычисляется уже в рантайме.
>>1016135
Вот да. А меняться во времени это уже к реактивному программированию.
Вот да. А меняться во времени это уже к реактивному программированию.
>>1017854
Нормально.
Нормально.
>>957819
Но как же, господа, ведь математически докококазана безопасность.
Но как же, господа, ведь математически докококазана безопасность.
>>1018496
Нет никакого другого тырпрайза.
Ты бы пообщался с тырпрайз работниками из штатов.
Поголовно всем на все посрать. Свиноматки в декрете работающие(системным аналитоком) из дома и нехреа непонимающие в происходящем.
Жрущие во время митинга по скайпу и успокаивающие там же ребенка.
Индусы (настоящие американцы).
И прочие прелести.
Здоровому человеку в этом всем говне делать нечего.
>У тебя какой-то галлерный руснявый тырпрайз.
Нет никакого другого тырпрайза.
Ты бы пообщался с тырпрайз работниками из штатов.
Поголовно всем на все посрать. Свиноматки в декрете работающие(системным аналитоком) из дома и нехреа непонимающие в происходящем.
Жрущие во время митинга по скайпу и успокаивающие там же ребенка.
Индусы (настоящие американцы).
И прочие прелести.
Здоровому человеку в этом всем говне делать нечего.
>>958602
Можно поместить себя в клетку и так прятаться от собаки, а можно собаку поместить в клетку.
Можно поместить себя в клетку и так прятаться от собаки, а можно собаку поместить в клетку.
>>1019277
Не знаю, занимаемся промышленной разработкой небольшой командой и ус не дуем. Решения выбираем прагматично, код пишем рационально, не полагаясь на карго-макакинг.
Не знаю, занимаемся промышленной разработкой небольшой командой и ус не дуем. Решения выбираем прагматично, код пишем рационально, не полагаясь на карго-макакинг.
>>1019384
И причем тут энтерпрайз?
Доход поровну делите?
>занимаемся промышленной разработкой небольшой командой
И причем тут энтерпрайз?
>занимаемся
Доход поровну делите?
>>1020631
Не, я конечно допускал, что две буквы могут к подрыву привести, но всё же, рассматривал больше как теоретическую возможность, всё же /зк.
Приятно удивлён
Не, я конечно допускал, что две буквы могут к подрыву привести, но всё же, рассматривал больше как теоретическую возможность, всё же /зк.
Приятно удивлён
>>961111
Не совсем, Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность). Как бы Rust не старался, плюсы еще долгое время будут жить, а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй. Но, на данный момент, язык дико молодой и, как следствие, сырой.
Не совсем, Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность). Как бы Rust не старался, плюсы еще долгое время будут жить, а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй. Но, на данный момент, язык дико молодой и, как следствие, сырой.
>>1021225
Ты чё сука ты чё. Раст популярнее и популярнее с каждым днем: вот новость недавняя, даже оракл выпустил приблуды для изолированных контейнеров:
https://github.com/oracle/crashcart
https://github.com/oracle/railcar
Глянуть в код, увидеть - та еще параша, а я зык выбран из соображений - поиграться
Ты чё сука ты чё. Раст популярнее и популярнее с каждым днем: вот новость недавняя, даже оракл выпустил приблуды для изолированных контейнеров:
https://github.com/oracle/crashcart
https://github.com/oracle/railcar
Глянуть в код, увидеть - та еще параша, а я зык выбран из соображений - поиграться
>>1020983
Не осилил лайфтаймы. Есть по ним вменяемый тутор?
>Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность)
Не осилил лайфтаймы. Есть по ним вменяемый тутор?
>>1020983
Давно бы уже пошла, если это было бы проблемой.
>а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй
Давно бы уже пошла, если это было бы проблемой.
>>1021632
Есть. Называется практика и ебля в жопу с компилером.
Есть. Называется практика и ебля в жопу с компилером.
Есть такой теоретический вопрос. Посмотрел стандартную библиотеку раста, а там нет даже либ для http. Вопрос, как реализуют такие библиотеки, в теории. Используют какие то либы операционной системы, или как то по другому?
>>1024575
Говорят системе открыть сокет пишут туда
Говорят системе открыть сокет пишут туда
Заебала долгая компиляция. Как я понял, в расте нет аналогов объектных файлов из цепепе, когда вношу любое изменение - проект пересобирается полностью. У меня 17к строк в проекте (большая часть - сгенированные биндинги opengl), компиляция занимает секунд 15.
Похоже, придется перекатываться на кресты.
Похоже, придется перекатываться на кресты.
>>1024721
Охуеть теперь. Я и по 2 минуты ждал постоянно потому что в движке было много объектых файлов и пека слабый.
Охуеть теперь. Я и по 2 минуты ждал постоянно потому что в движке было много объектых файлов и пека слабый.
112 Кб, 200x440
>>1025182
Ржавый?
Ржавый?
Чому на расте так мало проектов пилятся? С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow, а с другой стороны работы на нём нет и положительных тенденций нет
>>1034290
Очень недружелюбный язык для вкатывания, поэтому просто нет тонны всяких "бот для телеграма на %языкнэйм%"
Очень недружелюбный язык для вкатывания, поэтому просто нет тонны всяких "бот для телеграма на %языкнэйм%"
>>1034290
Это значит только то, что он вызывает больше всего вопросов.
Завезли бы корутины.
>С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow
Это значит только то, что он вызывает больше всего вопросов.
>так мало проектов
Завезли бы корутины.
>>1034439
Нет, это они опрос проводили. https://insights.stackoverflow.com/survey/2017
Стекфул корутин, как в Го, не-бу-дет. Копают в сторону стеклесс и асунк/ашаит.
> Это значит только то, что он вызывает больше всего вопросов.
Нет, это они опрос проводили. https://insights.stackoverflow.com/survey/2017
> Завезли бы корутины.
Стекфул корутин, как в Го, не-бу-дет. Копают в сторону стеклесс и асунк/ашаит.
>>1034577
Ах лол.
Любимый в смысле на нем не программируют, но что-то слышали.
>Нет, это они опрос проводили.
Ах лол.
Любимый в смысле на нем не программируют, но что-то слышали.
>>1034290
Каких это проектов там мало? Каждый Вася Жопин не пилит свой веб фреймворк и бот для телеграма умеющие нихуя?
Каких это проектов там мало? Каждый Вася Жопин не пилит свой веб фреймворк и бот для телеграма умеющие нихуя?
>>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
Ну, это замечательно.
Учитывая, что в категории Programming Languages в том же опросе, раста нет вообще.
То есть им не пользуются от слова совсем.
А кучка шизиков на нем кодящих хочет кодить и дальше, что как бы закономерно.
>Болезный?
>> 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
Так тебе программы писать или лабу2 конпелировать?
мимо скала-боярин
> компиляция занимает секунд 15.
Так тебе программы писать или лабу2 конпелировать?
мимо скала-боярин
>>1035337
Напейсание лаб ныне кличут TDD.
Напейсание лаб ныне кличут TDD.
>>1024721
В анус себе перекатись, блять, начинают кодить на Visual Studio и начинаются ебаться в жопу и думать, что компилятор сам по себе выполняет функционал makefile
В анус себе перекатись, блять, начинают кодить на Visual Studio и начинаются ебаться в жопу и думать, что компилятор сам по себе выполняет функционал makefile
>>1035337
Причем тут лаба, долбоёб?
На крестах есть инкрементальная сборка, крупный проект первый раз может собираться несколько минут, а потом, когда вносишь изменение в несколько файлов, проект пересобирается уже за пару секунд, т.к. собираются только затронутые объектные файлы. А в расте такого нет, если у тебя в проекте 1000 файлов, а ты изменил 2, при сборке будет собираться полностью.
>>1035358
Какая visual studio, какие makefile, ты чем там объебался?
Я так-то под линуксом сижу и юзаю cmake/clang.
Причем тут лаба, долбоёб?
На крестах есть инкрементальная сборка, крупный проект первый раз может собираться несколько минут, а потом, когда вносишь изменение в несколько файлов, проект пересобирается уже за пару секунд, т.к. собираются только затронутые объектные файлы. А в расте такого нет, если у тебя в проекте 1000 файлов, а ты изменил 2, при сборке будет собираться полностью.
>>1035358
Какая visual studio, какие makefile, ты чем там объебался?
Я так-то под линуксом сижу и юзаю cmake/clang.
>>1035947
Да, действительно ебу дал, на rust нет инкрементной сборки.
Охуеть, это какой-нибудь проект уровня хрома после каждого патча целый день собирать? Как жить-то?
Да, действительно ебу дал, на rust нет инкрементной сборки.
Охуеть, это какой-нибудь проект уровня хрома после каждого патча целый день собирать? Как жить-то?
>>1035958
Делить проект на крейты и жить как белый человек с модульной архитектурой кода, а не заниматься напейсанием индусских монолитных кусков говна на миллионы строк, как это помогли делать миллионам макакусов K&R. Открой исходники серво и посмотри как это делается.
Вообще, ты даже до гугла похоже не добрался — там есть инкрементальная компиляция https://internals.rust-lang.org/t/incremental-compilation-beta/4721 , другое дело что это не плюсы в которых её 2 десятилетия пейсали (и которая точно так же как раньше не работает при изменении предкомпилированных или просто везде используемых заголовков), и пока по умолчанию она не включается.
Делить проект на крейты и жить как белый человек с модульной архитектурой кода, а не заниматься напейсанием индусских монолитных кусков говна на миллионы строк, как это помогли делать миллионам макакусов K&R. Открой исходники серво и посмотри как это делается.
Вообще, ты даже до гугла похоже не добрался — там есть инкрементальная компиляция https://internals.rust-lang.org/t/incremental-compilation-beta/4721 , другое дело что это не плюсы в которых её 2 десятилетия пейсали (и которая точно так же как раньше не работает при изменении предкомпилированных или просто везде используемых заголовков), и пока по умолчанию она не включается.
>>1035947
У тебя там цмейк сам собирать научился, без бэкэнда, поешавший?
Вот с этого особо орнул. Ты там как, пользуешься сборками трехлетней давности, или сам собираешь? Я вот представляю уже, как ты после каждого релиза тащишь себе релизную ветку и билдишь ллвм со шлангом по 12 часов с ИНКРЕМЕНТАЛЬНОЙ компеляцией, и ору
>Я так-то под линуксом сижу и юзаю cmake/clang.
У тебя там цмейк сам собирать научился, без бэкэнда, поешавший?
>под линуксом
>clang
Вот с этого особо орнул. Ты там как, пользуешься сборками трехлетней давности, или сам собираешь? Я вот представляю уже, как ты после каждого релиза тащишь себе релизную ветку и билдишь ллвм со шлангом по 12 часов с ИНКРЕМЕНТАЛЬНОЙ компеляцией, и ору
>>1038418
Сложно.
Сложно.
>>977091
А как без системы управления пакетами? Это показатель современного языка. Без этого, это какой-то каменный век.
А как без системы управления пакетами? Это показатель современного языка. Без этого, это какой-то каменный век.
>>956909 (OP)
А нахрена? Rust он крут. Я не думаю, что нужно ставить вопрос именно так. Java все равно будет жить ещё долго, как и сраное php. Ведь его куча говнокода в Ынтерпрайзе. Ну и пусть варятся в собственном соку.
>как думаете, он сможет вытеснить жаву? Почему?
А нахрена? Rust он крут. Я не думаю, что нужно ставить вопрос именно так. Java все равно будет жить ещё долго, как и сраное php. Ведь его куча говнокода в Ынтерпрайзе. Ну и пусть варятся в собственном соку.
Ананасы кто-нибудь работает над ии?
Стоит подучивать что-нибудь по этому параллельно с веб макакетством или все тщетно, если конкретно этим не занимаешься?
Стоит подучивать что-нибудь по этому параллельно с веб макакетством или все тщетно, если конкретно этим не занимаешься?
>>1041669
t.безработный студент
t.безработный студент
>>1043540
Все работают над ИИ.
Все работают над ИИ.
>>1046994
Потому что это не ООП, люди подгоняют возможности Rust под тугое воображение ооп-ретрограда.
> своеобразное ООП
Потому что это не ООП, люди подгоняют возможности Rust под тугое воображение ооп-ретрограда.
>>1047013
Что ты подразумеваешь под ООП? Если первым словом в ответе на этот вопрос будет "наследование", то сразу иди нахуй.
Что ты подразумеваешь под ООП? Если первым словом в ответе на этот вопрос будет "наследование", то сразу иди нахуй.
>>1047113
Ну ты и лох, какое наследование, все знают что ООП - это когда можно методы через точечку вызывать и ИДЕ тебе автодополнение предлагает.
Ну ты и лох, какое наследование, все знают что ООП - это когда можно методы через точечку вызывать и ИДЕ тебе автодополнение предлагает.
>>1047113
Абстрактную фабрику абстрактных фабрик энтерпрайз фасолин.
Абстрактную фабрику абстрактных фабрик энтерпрайз фасолин.
>>1047541
Ну вообще говоря так и есть. ООП это всего лишь паттерн управления стейтом, когда стейт лежит рядом с функциями для их обработки в одном контейнере, а программа состоит из кучи таких контейнеров.
Ну вообще говоря так и есть. ООП это всего лишь паттерн управления стейтом, когда стейт лежит рядом с функциями для их обработки в одном контейнере, а программа состоит из кучи таких контейнеров.
>>1047779
Нет, ООП и императивное программирование это ортогональные понятия.
> ООП это всего лишь паттерн управления стейтом
Нет, ООП и императивное программирование это ортогональные понятия.
>>1047829
Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
>>1047855
Незнаком с ним. Да и моё утверждение верно для любого мейнстримного языка, будь то Java или C#.
>>1047896
Замени в своей фразе "стейт" на "данные" и получишь более-менее точное определение.
На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта.
Незнаком с ним. Да и моё утверждение верно для любого мейнстримного языка, будь то Java или C#.
>>1047896
Замени в своей фразе "стейт" на "данные" и получишь более-менее точное определение.
На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта.
>>1047909
Я что-то тебя не понял.
Присваивание полей в конструкторе, используется как гарантия того чтобы не было полуготовых объектов, т.е. таких объектов, которые будучи инициализированными, не дают собой полноценно пользоваться. Стейт от этого вообще никуда не девается.
Мимопрохожий.
> На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта
Я что-то тебя не понял.
Присваивание полей в конструкторе, используется как гарантия того чтобы не было полуготовых объектов, т.е. таких объектов, которые будучи инициализированными, не дают собой полноценно пользоваться. Стейт от этого вообще никуда не девается.
Мимопрохожий.
>>1047896
ООП это подход при котором отправитель сообщения и адресат никак несвязанны и независят друг от друга, а оба зависят от сообщения.
Суть в переносе связи между модулями на сообщения.
В c# это происходит через интерфейсы.
В с++ через абстрактные классы. (система типов плюсов/джавы превращают ООП в скотское безумие)
>Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
ООП это подход при котором отправитель сообщения и адресат никак несвязанны и независят друг от друга, а оба зависят от сообщения.
Суть в переносе связи между модулями на сообщения.
В c# это происходит через интерфейсы.
В с++ через абстрактные классы. (система типов плюсов/джавы превращают ООП в скотское безумие)
>>1047896
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.
ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.
То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.
ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.
По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
>>1048620
>>1048620
Определись наконец, Эрланг ООП или нет?
>ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки
>>1048620
>но никогда не видел ОО-ориентрованых програм на функциональных языках
Определись наконец, Эрланг ООП или нет?
>>1048620
Всего 2, фунциональное и логическое это частный случай декларативного программирования.
Всего 2, фунциональное и логическое это частный случай декларативного программирования.
>>1047779
Да хуйня какая-то, всё время прошу показать мне пример и объяснить почему это "ООП" а не сахар для процедурщины (я про вызов через точку). Вон в D можно обычные функции через точку вызывать, ну типа foo(a, b) и a.foo(b) - одно и то же. И шо, резко стало ООП? Да нет, нихуя. Вот объясните мне, где в вызове foo(a, b) стейт, а где не стейт. И почему оба аргумента не могут быть "стейтами".
Да хуйня какая-то, всё время прошу показать мне пример и объяснить почему это "ООП" а не сахар для процедурщины (я про вызов через точку). Вон в D можно обычные функции через точку вызывать, ну типа foo(a, b) и a.foo(b) - одно и то же. И шо, резко стало ООП? Да нет, нихуя. Вот объясните мне, где в вызове foo(a, b) стейт, а где не стейт. И почему оба аргумента не могут быть "стейтами".
>>1048620
Два чая этому господину
> ООП в современном виде - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры
Два чая этому господину
>>1049454
Хватит разговаривать с голосами в голове. О каком "синтаксисе конкретного языка" ты говоришь?
Хватит разговаривать с голосами в голове. О каком "синтаксисе конкретного языка" ты говоришь?
>>1049565
Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Что ж, полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). В расте есть куда более адекватный способ переопределения поведения - ad-hoc полиморфизм. Собственно говоря, он есть и в Haskell. Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Что ж, полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). В расте есть куда более адекватный способ переопределения поведения - ad-hoc полиморфизм. Собственно говоря, он есть и в Haskell. Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
>>1049606
Суть ооп - полиморфизм, инкапсуляция, наследование.
Ясно.
> Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме?
Суть ооп - полиморфизм, инкапсуляция, наследование.
> Что ж,
> ненужная хуйня (по той причине что
> ненужная хуйня)
Ясно.
>>1049616
Ну вот и получается, неследование не нужно, полиморфизм в классических ОО-языках опирается на наследование и потому не нужен.
Что касается инкапсуляции, то её можно рассматривать как сокрытие данных (такая трактовка описывается как неверная в русскоязычной и как одна из допустимых в англоязычной) - и тогда это довольно скучно, полно языков не поддерживающих сокрытие данных, но при это считающихся вполне пригодных для написания ОО-кода; или же можно трактовать инкапсуляцию как механизм "упаковывания" данных и кода, с ним работающего. Тогда опять-таки вопрос, во-первых, о чём речь идёт когда говорят об ОО-подходе в C (где ни наследования, ни полиморфизма, ни полноценной инкапсуляции); во-вторых, что делать с пресловутой проблемой бумаги и пера - paper.write(pen) или pen.write(paper)? Ну и в любом случае инкапсуляция (в смысле "упаковки") выглядит именно как незначительная надстройка над процедурщиной, сопровождающаяся как правило соответствующим сахарком.
>Суть ооп - полиморфизм, инкапсуляция, наследование.
Ну вот и получается, неследование не нужно, полиморфизм в классических ОО-языках опирается на наследование и потому не нужен.
Что касается инкапсуляции, то её можно рассматривать как сокрытие данных (такая трактовка описывается как неверная в русскоязычной и как одна из допустимых в англоязычной) - и тогда это довольно скучно, полно языков не поддерживающих сокрытие данных, но при это считающихся вполне пригодных для написания ОО-кода; или же можно трактовать инкапсуляцию как механизм "упаковывания" данных и кода, с ним работающего. Тогда опять-таки вопрос, во-первых, о чём речь идёт когда говорят об ОО-подходе в C (где ни наследования, ни полиморфизма, ни полноценной инкапсуляции); во-вторых, что делать с пресловутой проблемой бумаги и пера - paper.write(pen) или pen.write(paper)? Ну и в любом случае инкапсуляция (в смысле "упаковки") выглядит именно как незначительная надстройка над процедурщиной, сопровождающаяся как правило соответствующим сахарком.
>>1049412
Эрланг это язык программирования. Возможно это сложно понять, но язык и "парадигма" - не одно и то же. Если честно, я не знаю какую часть Эрланга занимают акторы, никогда с ним не работал. Но, например, тот код что я видел и писал на Акке (именно работу с акторами), функциональным назвать невозможно, а вот ОО - вполне.
>>1049414
Ты прочитай документ по ссылке, не ленись, ума наберись.
Эрланг это язык программирования. Возможно это сложно понять, но язык и "парадигма" - не одно и то же. Если честно, я не знаю какую часть Эрланга занимают акторы, никогда с ним не работал. Но, например, тот код что я видел и писал на Акке (именно работу с акторами), функциональным назвать невозможно, а вот ОО - вполне.
>>1049414
Ты прочитай документ по ссылке, не ленись, ума наберись.
>>1049606
Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.
ad-hoc полиформизм - не true полиформизм. True - параметрический.
Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.
Это значит лишь то, что элементы ООП проникли в функциональщину, ОО языки несут в себе примесь функциональщины, при этом никто не считает их функциональными.
Доябываться до заказчика, пока не будет ясно какая система должна получится в итоге. Получив представление строишь наиболее очевидную (предсказуемую, скучную) систему.
>полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня).
Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.
> адекватный способ переопределения поведения - ad-hoc полиморфизм.
ad-hoc полиформизм - не true полиформизм. True - параметрический.
> почему это "ООП" а не сахар для процедурщины
Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.
> Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
Это значит лишь то, что элементы ООП проникли в функциональщину, ОО языки несут в себе примесь функциональщины, при этом никто не считает их функциональными.
> что делать с пресловутой проблемой бумаги и пера
Доябываться до заказчика, пока не будет ясно какая система должна получится в итоге. Получив представление строишь наиболее очевидную (предсказуемую, скучную) систему.
> наследование - ненужная хуйня
Бтв, с этим не согласен. Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом. Только не надо пихать во все поля наследование. Это скальпель для построения иерархии типов, yj в жизни обычно хватает молотка в виде пары десятков заезженных паттернов.
>>1050038
Я и не говорил, что полиморфизм не нужен. Я лишь сказал, что тот полиморфизм, о котором обычно идёт речь в котексте ООП (т.е. полиморфизм подтипов) и который завязан на другой "столп" ООП - наследование - не нужен. Против ad-hoc и параметрического полиморфизма ничего не имею, даже наоборот, считаю что это очень нужные концепции. Только вот когда говорят о полиморфизме в контексте ООП обычно имеют ввиду не дженерики и не трейты/тайпклассы.
Я же говорил про способ переопределения поведения для разных типов. Параметрический полиморфизм позволяет лишь определить одно поведение для разных типов, а не разные поведения для разных типов.
Так, а вот это уже интересно. До сих пор в треде никто inversion of control не упоминал. В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.
>>1050047
И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?
И зачем оно в реальной жизни может понадобиться? Точнее, в каких ситуациях оно может быть удобнее, чем подход того же Rust?
> Полиморфизм подтипов - частный случай полиформизма. Доказывать, что общее не нужно из-за частного - маняврирование.
Я и не говорил, что полиморфизм не нужен. Я лишь сказал, что тот полиморфизм, о котором обычно идёт речь в котексте ООП (т.е. полиморфизм подтипов) и который завязан на другой "столп" ООП - наследование - не нужен. Против ad-hoc и параметрического полиморфизма ничего не имею, даже наоборот, считаю что это очень нужные концепции. Только вот когда говорят о полиморфизме в контексте ООП обычно имеют ввиду не дженерики и не трейты/тайпклассы.
> ad-hoc полиформизм - не true полиформизм. True - параметрический.
Я же говорил про способ переопределения поведения для разных типов. Параметрический полиморфизм позволяет лишь определить одно поведение для разных типов, а не разные поведения для разных типов.
> Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.
Так, а вот это уже интересно. До сих пор в треде никто inversion of control не упоминал. В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.
>>1050047
>Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом.
И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?
> Это скальпель для построения иерархии типов
И зачем оно в реальной жизни может понадобиться? Точнее, в каких ситуациях оно может быть удобнее, чем подход того же Rust?
>>1050047
И да, diamon inheritance - не единственная проблема наследования. Другая проблема состоит в железобетонности иерархий типов, построенных наследовании, другими словами - в том что они очень плохо расширяемы.
И да, 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 - это позволит избежать переписывания старого кода и заняться расширением.
Именно так. На мой взгляд, разночтения происходят из-за двух вещей:
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 полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
>>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 - это позволит избежать переписывания старого кода и заняться расширением.
Именно так. На мой взгляд, разночтения происходят из-за двух вещей:
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 полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
>>1051235
Так отлично, а что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
Ну, всё то же самое можно сделать с помощью trait objects. Ну то есть принцип тот же, только без наследования реализации, только наследование поведения.
Ну для этого нужна поддержка рантайм-рефлексии, это хак)
> Взяли и выпилили множественное наследование, лол
Так отлично, а что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
> Выборка Human из Unit возможна из-за наличия иерархии типов
Ну, всё то же самое можно сделать с помощью trait objects. Ну то есть принцип тот же, только без наследования реализации, только наследование поведения.
> Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение.
Ну для этого нужна поддержка рантайм-рефлексии, это хак)
>>1052018
Я непойму, ты хочешь чтобы я тебе википедию перерассказал, или что???
https://ru.wikipedia.org/wiki/Ромбовидное_наследование#.D0.A0.D0.B5.D1.88.D0.B5.D0.BD.D0.B8.D1.8F
Ок, давай тогда будем говорить что наследование не нужно в расте. А если ты не растаман, и у тебя нет trait objects, тогда что? Речь явно о наследовании в ООП в целом. Бтв, согласен с тобой, что наследование не столп, или точнее 'столп' в кавычках. Но это не значит, что оно концептуально ненужно.
Хак, это или фича - вопрос, конечно, интересный. Однако, параметрический полиформизм - true именно потому что включает, но не ограничивается ad-hoc полиформизмом. ad-hoc полиформизм не true по той же самой причине.
> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
Я непойму, ты хочешь чтобы я тебе википедию перерассказал, или что???
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
Добавлю, в случая кода множественного наследования, вооще нет, то тогда класс расширяется через примеси, интерфейсы, и т.п.
>> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?
Добавлю, в случая кода множественного наследования, вооще нет, то тогда класс расширяется через примеси, интерфейсы, и т.п.
>>1052142
Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.
>>1052064
Так ты то говоришь что проблему diamond inheritance решили, выпилив множественное наследование, то кидаешь ссылку на список хаков которые кое-как решают эту проблему, и все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.
Ну мне кроме сишки в голову не приходит языков без поддержки динамического диспатчинга. Никто не мешает сделать всё тоже самое на тех же Java и C#. Ну да, кое-где нет интерфейсов как отдельной сущности (в C++ например) и там придётся использовать "наследование" как механизм языка, но при этом по-хорошему все равно надо наследовать не реализацию, а только поведение (как это у крестовиков, pure virtual inheritance?).
Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.
>>1052064
Так ты то говоришь что проблему diamond inheritance решили, выпилив множественное наследование, то кидаешь ссылку на список хаков которые кое-как решают эту проблему, и все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.
> А если ты не растаман, и у тебя нет trait objects, тогда что?
Ну мне кроме сишки в голову не приходит языков без поддержки динамического диспатчинга. Никто не мешает сделать всё тоже самое на тех же Java и C#. Ну да, кое-где нет интерфейсов как отдельной сущности (в C++ например) и там придётся использовать "наследование" как механизм языка, но при этом по-хорошему все равно надо наследовать не реализацию, а только поведение (как это у крестовиков, pure virtual inheritance?).
>>1052159
А что делать с интерпретируемыми языками, опирающимися на duck typing, такими как ruby, в которых, в mixin'ах, реализация не отделяется от поведения?
По моему скромному мнению, множественное наследование не нужно. Однако, есть языки где ситуацию с что делать когда одиночным наследованием не обойтись решили вот так, через 'хаки', если угодно. Этот ответ показался мне неполным, т.к. есть и другая категория языков - где мн. наследование выпилили, там я допонил чуть-чуть.
Как из всего этого вытекает вопрос о том, что наследование вообще не нужно, чучхе не понимать.
---
Я с тобой согласен в том, что связи удобнее описывать не через наследование. С другой стороны, по Барбаре Лисков иерархия классов упрощает проверку наличия этих связей, и в этом и есть ценность наследования.
> По-хорошему все равно надо наследовать не реализацию, а только поведение
А что делать с интерпретируемыми языками, опирающимися на duck typing, такими как ruby, в которых, в mixin'ах, реализация не отделяется от поведения?
> все равно непонятно в каких ситуациях это лучше чем отказаться от наследования вообще и вместо этого использовать интерфейсы/трейты/тайпклассы.
По моему скромному мнению, множественное наследование не нужно. Однако, есть языки где ситуацию с что делать когда одиночным наследованием не обойтись решили вот так, через 'хаки', если угодно. Этот ответ показался мне неполным, т.к. есть и другая категория языков - где мн. наследование выпилили, там я допонил чуть-чуть.
Как из всего этого вытекает вопрос о том, что наследование вообще не нужно, чучхе не понимать.
---
> Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.
Я с тобой согласен в том, что связи удобнее описывать не через наследование. С другой стороны, по Барбаре Лисков иерархия классов упрощает проверку наличия этих связей, и в этом и есть ценность наследования.
А вот и внезапный бамп растотреду!
Объясните мне, аноны:
https://github.com/sfackler/rust-postgres/blob/d374641ecb584bb668fa8e7a10d0f593a5c35ca2/src/io.rs#L24
Строки 29-36, почему в match не указаны неймспейсы? Почему не MaybeSslStream::SslStream? Там ведь нет use.
Объясните мне, аноны:
https://github.com/sfackler/rust-postgres/blob/d374641ecb584bb668fa8e7a10d0f593a5c35ca2/src/io.rs#L24
Строки 29-36, почему в match не указаны неймспейсы? Почему не MaybeSslStream::SslStream? Там ведь нет use.
>>1055130
А нахуя ты смотришь какой-то коммит трёхлетней давности? Сейчас такое не скомпилируется.
А нахуя ты смотришь какой-то коммит трёхлетней давности? Сейчас такое не скомпилируется.
>>1055216
Наткнулся на код и даже не заметил, что это древний коммит, лол.
Наткнулся на код и даже не заметил, что это древний коммит, лол.
То, что полиморфизм — один из столпов ООПа, еще не значит что сам полиморфизм имеет какое-то отношение к ООП. В функциональных языках полиморфизма таки больше.
Тред утонул или удален.
Это копия, сохраненная 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
Это копия, сохраненная 7 сентября 2017 года.
Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее
Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.