Двач.hk не отвечает.
Вы видите копию треда, сохраненную 7 сентября 2017 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
23 Кб, 209x208
Rust #956909 В конец треда | Веб
Язык, который существует уже не один год. Язык, который заинтересовал меня из-за скорости выполнения, кроссплатформа, безопасности и возможности делать вещи как в высокоуровневых языках (ООП, мощные макросы, даже не знаю, как сказать). И вот у меня к вам вопрос: как думаете, он сможет вытеснить жаву? Почему?
Также открываем здесь его обсуждение, с возможностью отвечать на ответы.
Dmitry #2 #956912
>>956909 (OP)
Что можно сделать на расте чего нельзя на С?
#3 #956915
Эмм, а с какого-такого он должен вытеснить Яву ?
Dmitry #4 #956916
>>956915
А нахуй она нужна? Создавать яву было плохой идеейю
270 Кб, 1024x768
#5 #956921
>>956916
Два чаю, надо было продвигать Smalltalk.
#6 #956922
>>956916
Слишком толсто
#7 #956931
>>956909 (OP)
D - пизже.
4 Кб, 361x193
#8 #956932
>>956912
Писать без сегфолтов например
#9 #956937
>>956915
Наверное, только потому, что мне идеология компиляции нравится больше, чем какая-то виртуальная машина, хоть она в конечном счете имеет нехилую оптимизацию. LLVM уже не мало так платформ покрыл. Еще, жава много памяти ест, если сравнить с аналогичной программой на C/C++/Rust/томуподобное
513 Кб, 657x516
#10 #956941
>>956909 (OP)

>язык без наследования


>сможет ли вытеснить жаву

#11 #956946
>>956941
А чем наследование на столько важно? Где например оно очень нужно?
#12 #956954
>>956946
Везде кроме laba1.exe
#13 #956962
>>956954
Посмотрите на этого эксперта сделавшего laba10.exe
В реальности от наследования больше проблем чем пользы.
#14 #956967
>>956916
Слишком много заебств в расте с видами указателей и механизмом владения. На джаве писать намного проще и как следствие намного легче найти людей, которые её знают. Там где используется джава производительность всех устраивает и получаем, что раст нахуй там не нужен. Проблемы создает, а бонусы преподносит слишком маленькие. Нет, я очень рад этому языку. Наконец-то появилась альтернатива мерзким плюсам, но вот только с ними он и может конкурировать. Более высокоуровневые языки он не потеснит никогда.
#15 #956969
>>956932
На Сишечке тоже можно писать без них
#16 #956976
>>956969
В Си надо быть крайне внимательным, работая с памятью, указателями и т.п. Так и стараются. Тем не менее, человеческий фактор всегда допускал там ошибки. Здесь (в расте) ты либо будешь послан нахуй компилятором, либо при работе программы будет так называемая паника, которая убивает работающую программу или просто один из ее потоков
#17 #956977
>>956962
В реальности люди комбинируют несколько подходов исходя из задачи.
#18 #956978
>>956967
А если через пару годиков под раст будет множество либ под любые нужды? Примерно как сейчас в жаве... В конце концов, там свои фичи, тут свои и время изучения не сильно разное
28 Кб, 500x369
#19 #956982
>>956978

>А если через пару годиков под раст будет множество либ под любые нужды?

#20 #957014
bamp
#21 #957064
>>956969
Многа букаф получится.
#22 #957076
>>957064
Как будто в пидарасте от кривого кода программа нормально работать будет.
#23 #957078
>>956946
ООП местячковый мем в снг.
#24 #957085
Наследование - ничто, миксины - всё.
#25 #957093
>>957076
Меньше кода - легче рефакторить.
#26 #957112
>>956976

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


И чем это лучше сегфолта? Исключения хоть можно обрабатывать?
533 Кб, 1600x1200
#27 #957136
На самом деле рыночку действительно нужен инструмент который позволит создавать кросплатформенные решения с низким оверхедом по производительности/памяти и без сборщика мусора, но на котором смогут писать миллионы лемингов за дёшево.

Что нового предлагает Rust, для решения этих проблем?
Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?
Без этих метрик нет смысла что-то обсуждать?

Я уверен, что раст тоже найдёт свою нишу, но однозначно это будет на Ынтерпрайз или web бэкэнд. Возмно, системщина и узкопрофильная прикладуха,возможно ембед, но не ололо контроллеры, а линукс борды. Но для эмбеда нужна спрос и поддержка корпораций, что врядли
#28 #957139
>>957136

>fix


>не ентерпрайз и не web back-end

#29 #957174
>>957136

>Сущесвтуют ли реальные тесты производительности, сравнения сложности разработки, etc?


Реальные тесты производительности? Ну это уже по каждой конкретной задаче. Вот тут видим, что на бенчмарках( не отображают реальный мир), раст выигрывает c++ в 6/9 тестов
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp. Не забывай, что для раста не написано много ключевых оптимизаций, что есть у крестов, но вот растовская система типов позволит в будущем реализовать более агрессивные оптимизации, которые не возможны на c/c++, да и с каждым обновлением LLVM раст становится всё лучше.

>сравнения сложности разработки,


Таких точно нет, всё же на расте никто не пишет, лол. Позволю себе с дивана предположить, что раст в этом лучше т.к. большинство ошибок с++, которые приходится постоянно дебажить, находятся в расте на этапе компиляции. Возможно, если ты йоба-сеньйор с 20+ годами опыта плюсов, то ты не заметишь разницы в скорости разработки, но вот во всех остальных случаях, полагаю, раст сделает c/c++
Dmitry #30 #957194
>>957174
На расте операционную систему написали.
#31 #957257
>>956909 (OP)

>кроссплатформа


Компилятор не поддерживает Windows XP (хотя вроде может исполняться, но с какими-то ключами), хотя поддержка "Embedded Industry" (в ваших банкоматах и прочих) есть до 2019 года.

>скорости выполнения


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

>вытеснить жаву? Почему?


Нет. Тут даже Го не смог. Джава это сформировавшиеся индустрия, ее даже засахаренные скала и котлины потеснить не могут, хотя те на jvm.
#32 #957260
>>956967
Помоему, они сделали язык сложнее чем С++
#33 #957308
>>956912
На С в теории можно все, не зря же в нее компилятся большинство скриптовых языков. Другое дело что создать что-то большее чем драйвер на одном только С врятли получится, а даже если и получится то поддерживать это будет пиздецово. А в расте главная фишка что он безопасен и он строг к синтаксису - т.е. у всех будет более менее одинаковый код и при том гарантированно безопасный, что поможет избежать обсеров как с OpenSSL, когда выяснилось что весь мир годами пользовался дырявым софтом.
#34 #957310
>>957260
Сложнее C++ в принципе сложно сделать. В язык накидали фич не для решения конкретных проблем, а выбрали их рандомно, что вылилось в плохой дизайн языка.
#35 #957357
>>956941
Там есть множественное наследование поведения — не реализации. То есть интерфейсов — не классов.
#36 #957363
>>957136

>Что нового предлагает Rust, для решения этих проблем?


Ну уж точно не "миллионы леммингов и дешево". Rust сложнее С++, там как раз фишка в том, что сложность разменивается на стабильность.
sage #37 #957444
>>956932
пример притянут за яйца. любой школьник знает, что эта строка лежит в read-only секции. да и компилятор будет ругаться на каст сonst char к char
короче иди нахуй. сажи треду
#38 #957501
>>957310
два чая
#39 #957510
>>957310

>а выбрали их рандомно


Не рандомно. Каждое решение там вполне осознанное и обдуманное. Другое дело, что их вообще не надо было принимать. Или делать минималистичную сишку с классами или пилить новый язык.
#40 #957522
>>957510
Так сделали десятки ебанатов, но взлетел почему-то С++. А теперь поучи датчанина делать языки.
17 Кб, 300x257
#41 #957544
>>957522

>взлетел


>почему-то

#42 #957548
>>957194
Proof?
#44 #957553
>>957551
Мда очередная UNIX-like говнина, сколько их можно пилить...
#45 #957578
>>957544
Винда написана на си, ебанутый.
#46 #957585
>>957553
А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.
>>957578
Это к тому было, что и палка раз в год стреляет.
#47 #957587
>>957553
Да блять просто очередная перделка на гихабе, как laba.exe студентов.
А преподносят как готовый продукт.
Насколько я знаю, они его переписывают потому, что архитектура стала не поддерживаемая (казалось бы причем тут гибкость раст).
#48 #957602
>>957522

>но взлетел почему-то С++


Популярность продукта ни разу не гарантирует его высокое качество.
#49 #957609
>>956909 (OP)
Дрявая хуета с утечками как и С++
https://github.com/redox-os/redox/issues/855
#50 #957610
>>957585

>А какие ещё есть варианты? Либо юникс-говнина, либо NT-сперма.


Да дохуя на самом деле, но к сегодняшнему дню это всё либо осталось в музеях, либо пилится на коленке каким-нибудь Куртисом Ярвином или Терри Дэвисом. Хотя впрочем IBM всё ещё поддерживает z/OS.
#51 #957611
>>957610
GNU/Linux идеальная ОСь, BSD годная альтернатива. Остальное просто ненужно.
#52 #957616
>>957611

>Остальное просто ненужно.


Нужно, просто ты об этом не знаешь: http://www.loper-os.org/?p=284
#53 #957621
>>957610

>но к сегодняшнему дню это всё либо осталось в музеях


Потому что надо дрова из ОС выкинуть нахуй. Пусть железячники все хардварно реализуют с простым интерфейсом. Все равно и так блобы везде. Так пусть тот блоб на железе крутиться с простым стандартным интерфейсом наружу. Тогда можно будет для кучи устройств использовать один драйвер по спецификации.
#54 #957623
>>957611

>Windows идеальная ОСь, macOS годная альтернатива. Остальное просто ненужно.

#55 #957627
>>957621
Годная идея. PostScript в принтерах был шагом в правильном направлении.
Dmitry #56 #957628
>>957616
зачем нужен виндоус у которого нет экосистемы? На котором до сих пор мертвым грузом лежит дохуя (50%) легаси? Единственное за что их можно уважать за то что форсят переход на новые железки.
Видео драйвер интела из-за легаси пидарастии раздут с 1 мб до 200, в 200 раз больше необходимого, пиздец.
МакОСь хоть и для пидарасов, но сбалансирована, имеет нормальную щель, работает без бсодов.
#57 #957631
>>957602
Популярность С++ гарантирует, что с твоим подходом что-то не то. И довольно банальное - обратно-совместимое решение победило. Из тех времен живо 3 языка, это С, С++ и Objective C. Угадай, почему.
Dmitry #58 #957632
>>957621

>блобы везде


Не везде

>простой интерфейс


Они его и сделали, можешь в обход всех либ юзать.
#59 #957647
>>957628
легаси и есть экосистема, тупой ты уебок
и да, это оскорбление
иди нахуй заодно
Dmitry #60 #957657
>>957647

>легаси и есть экосистема, тупой ты уебок


>и да, это оскорбление


В голос с дауна.
Экосистема это когда в системе не дублируется одно и то-же и четко разделено что за что отвечает.
Виндовс 20 лет не чистилось от говна, вместо того чтобы это сделать добавляют %фичи% и велосипеды чтобы они работали.
Одинаковые названия программ, драйвера по 300 метров для звуковух и видео, три встроеных браузера и двое меню настроек на покушать.
#61 #957660
>>957657
Ты бредишь, Митя. Экосистема - это экологическая система, почитай, что такое экология. Это когда куча животных, едят друг друга и срут, но система при этом стабильна, потому что все в балансе.
#62 #957663
>>957660

> друга и срут, но система при этом стабильна, потому что все в балансе.


А шиндовс не стабильна и не нужна согласно http://www.loper-os.org/?p=284
шиндовс обсирается на первом же правиле, так что хватит за них топить Пыня.
#63 #957684
>>957631
Популярность продукта в массах — это показатель только его доступности для широкой аудитории.

Это как сравнить айфоны с кучей говна на андроиде — первые по статистике занимают всего-то 10-15% рынка. Только вот незадача, из этих 85-90% только треть превышают отметку в 200$, а отметку в 500$ ещё треть от этой трети.

Вот и думай почему говно для тупорылых макак вроде го, пхп (и 1с в странах снг) стреляет. То же и с плюсами — худобедно любой дебил осиливает хэловорд, падающий через раз с сегфолтом — зато осилил жи!
#64 #957770
>>957684
Ты сам довольно тупорылый, если мобильные ос в принципе занимают какое-то место в твоей голове. А языка лучше С++ в своей нише объективно нет. Вообще. Никак. Ни разу. Поэтому умнейшие люди планеты пишут свои продукты на нем, с нуля и до сих пор.
#65 #957792
>>957770
Ты домен какаой-та толе на плюсах писали раньше потому что небыли альтернативы. От слова совсем. Либо Ява, либо говно вроде D со сборщиком.
93 Кб, 1111x597
#66 #957813
>>957792
ДЦП
#67 #957819
>>957609
Они получается unsafe юзали?
#68 #957839
>>957819

>unsafe юзали


Пиздец.
#69 #957873
Есть у кого-нибудь опыт использования Rust в production? Часто занимаюсь "узкими" местами в веб приложениях, сейчас все на плюсах, но давно посматриваю в сторону Rust, хотелось бы узнать о опыте использования в реальных проектах?
#70 #957883
>>957873
Что ты там увидеть ожидаешь-то? Плюсовикам (как и вообще всем, кто не занимался каким нибудь хачкеллем, в котором компилятор так же ебет за попытки сделать хуйню) переучиваться очень больно. Иде уровня студии нет, но хуитка для редакторов с нормальным (не уровня тегов из вима и прочей еле работающей хуйни) автокомплитом и подсветкой ошибок из компилятора есть, хотя и альфа, которая собирается только через три анальных кольца. Можешь почитать истории от челиков из дропбокса - https://www.reddit.com/r/rust/comments/4adabk/the_epic_story_of_dropboxs_exodus_from_the_amazon/
#71 #957886
>>957873

>production


То есть все остальное ты написал по-русски, а это слово перевести не смог?
#72 #957892
>>957886
продакшен.
#73 #957944
>>957136

>оверхедом по производительности/памяти и без сборщика мусора, но на котором смогут писать миллионы лемингов за дёшево


Go, у них даже символ языка похож на лемминга.
>>957308
Как же тогда оставлять закладки для спец служб?
#74 #958050
>>957839
Я к тому откуда могут быть утечки, если это раст. Значит unsafe. Хотя я помню что в каких то версиях раста все таки могли происходить утечки даже без ансейфа, когда паника запускалась другой в панике, но я посчитал что это прям обосраться какое исключение.
#75 #958080
В расте же даже не зависимые типы. Как им пользоваться?
#76 #958129
>>958080

>даже не зависимые типы


А что нужно, чтобы запилить в расте зависимые типы?
#77 #958132
>>958080
Хотя подожди. Проверка типов в языке с зависимыми типами может быть неразрешимой. Тогда нахуя оно надо?
А вот типы высшего порядка (да-да, те самые родненькие аппликативные функторы, стрелки и монады) были бы полезнее. Я правильно понимаю, что их можно эмулировать трейтами с ассоциированными типами?
#78 #958149
>>958050
Да, утечки есть, но я про то что ты как дауненок написал.

>unsafe юзали


Кто так пишет? Это пиздец просто.
#79 #958165
>>957112
Там нет исключений, но есть особая система типов. Т.е. функция всегда что-то возвращает. Но это может быть что-то (Some), а может быть ничто (None). Или например может быть некий результат или некая ошибка, что уже как бы является аналогом исключения
#80 #958210
>>958149
А как надо было?
Dmitry #81 #958273
>>958210
На С надо писать а не выебыватся.
#82 #958329
>>958273
У АНБ и без твоего корявого сишного говна забитого 0-day cve хватает.
Dmitry #83 #958335
>>958329
Правильно писать NSA.
Ты еще скажи что у раста уязвимостей нет, только что говорили что нет утечек, теперь это.
#84 #958337
>>958335
Если код пишет не си-обезьяна на ансейфах — то ни одной сишной точно не будет. Ты кстати забыл главный опус растотредов — memory leaks is memory safe, пидар.
#85 #958359
>>958335
Если руки кривые то ты утечку и в языке с GC сможешь сделать. От утечек тебя ни один язык полностью не убережет, так что думать головой все равно придется. Зато память в расте безопасная, без уязвимостей.
#86 #958602
>>957819
А как по-твоему писать ОСь, которая должна взаимодействовать с железом без unsafe'ов?
#87 #958607
>>956921
Smalltalk тоже использует виртуальную машину, школота.
#88 #958680
>>958607
Я знаю, первокурсник. Это не меняет того, что я написал.
#89 #958683
>>958602
Например, так же, как в некоторых ОС давно зделоли.
А именно, написан препроцессор для Сишки, который на каждом шаге проверяет, не собрался ли драйвер поделить, скажем, на ноль.
У драйвера своя область стека, все данные он видит только на чтение.
Собрался поделить на ноль - ну тогда значит KernExitThread(-1) и едем дальше.
#90 #958694
>>958683
Я в работе современных (да и старых) ОСей не шарю, но на днях читал про прерывания. Что например если была попытка поделить на ноль, что будет вызвано такое-то прерывание. Где-то в памяти есть таблица (с адресами функций?), которые должны обрабатывать подобные случаи. И не всегда же надо тупо выходить. По крайней мере, родительский процесс должен знать, за что убили ребенка
#91 #958756
>>958680
Второкурсник ворвался в тред.
#92 #958815
>>958694
Да, это для обыкновенных процессов.
А в ядре ОС возникнет неисправимая ошибка во время выполнения, синий экранчик, у продвинутых чёрный.
Но в общем, не забивай себе этим голову, в роиссе на эти знания (очень ценные, ахаха) спроса всё равно нет.
#93 #960575
Будущее за языками с HoTT.
#94 #960918
>>960575
С чем?
#95 #960919
>>960918
С гомотопиями.
#96 #960926
>>960919
Звучит неприлично.
#97 #961111
>>956915
он и не должен вытеснить джаву. это конкурент плюсам, алё
#98 #961142
>>961111

> это конкурент плюсам


Жава с плюсами местами конкуренты.
#99 #961147
Очередной долбоёбский тред где эксперты уровня laba2 спорят обо всём, до чего дотянутся.
#100 #961320
>>960575
Ты таких много знаешь?
#101 #961476
>>961320
Есть в виде модулей к не очень популярным языкам. Я же говорю будущее, а не настоящее.
#102 #961504
>>960575
Лет через 10 так, причём в совсем другом виде, а не то говно сейчас. Посмотри на циклон и раст - такая же разница.
#103 #963997
Посоны, а где писать программы на русте?
Там IDe кокая? Есть?
#104 #964000
>>963997
Emacs самая лучшая IDE для любого языка.
#105 #964001
>>958680
Ну и к чему тогда твой вскукарек, различия жабы и смоллтока незначительны. Во втором только рефлексия продвинутей.
#106 #964005
>>963997
JetBrains + Rust plugin
Visual Studio Code + Rust plugin
#107 #964028
>>956909 (OP)
Друзья, я пытаюсь разобраться в возможностях языка.

Конкретно интересует асинхронное программирование, наткнулся на какие-то фьючеры, но они реализованы отдельной библиотекой, это как может вообще работать?
Ну в смысле, вот есть либа для общения с SQL сервером, но она же ничего про либу с фьючерами не знает, и как тогда это общение в код с фьючерами инкорпорировать?
#108 #964118
>>964028

> она же ничего про либу с фьючерами не знает


Знает.
#109 #964219
>>964028

>и как тогда это общение в код с фьючерами инкорпорировать?


Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.
#110 #964409
>>964219

>Пишешь обычный код, только с типажами из futures на выходе @ спавнишь свою хуйню в готовом ивентлупе из tokio или своём самописном @ утилизируешь все ядра, пьёшь смуззи в старбаксе и ссышь на гоферов.



А это законно вообще?
#111 #964464
>>964409
В манямирке
#112 #964473
Если раст пилят как более безопасную замену C++, значит в нем не должно быть проблем при написании гуишного софта?
#113 #964520
>>964473
На расте нет никаких проблем с гуи, т.к. нет гуи
#114 #964536
>>964473

>2к17


>геи


Новые гуевины шлепают только на мобилках со своими хост-языками, а десктопное легаси и без того вроде работает (хотя тот же гном вроде как по кусочкам, как и новый движок лисы переписывают на растяпу? но это неточно).
#115 #964537
>>964536

>геи


Ммм, а мой автокомплит в курсе трендов этого года.
Гуи, конечно жи.
#116 #964539
>>964536

>растяпу?


Это тоже интересный автокомплит, лол.
#117 #964541
>>964473
Есть разные биндинги под существующие либы
Например, https://www.youtube.com/watch?v=hLR8R0Zl0yY
#118 #964586
>>964464

>В манямирке


Значит на попытке написать scgi приложение я сосну?
Вроде tokio позволяет оче просто писать асинхронный сервер.
#119 #964587
>>964586
Я вообще мимо проходил(из го треда), сорян, помочь не могу.
#121 #965804
>>965801
Раст чуть быстрее джанги на питоне
#122 #965807
>>965801
И обрати внимание что многие с ошибками сыпяться (очень стабильный язык)
1,3 Мб, 1920x1080
#123 #965824
>>965804
>>965807
Полгода для раста это много. Сейчас как-то так.
https://www.techempower.com/benchmarks/previews/round14/#section=data-r14&hw=ph&test=plaintext
#124 #965838
>>965824
Они допилили асинхронный сервер (он полноценный или какая-то заглушка еще)?
#126 #968788
bump
112 Кб, 800x755
#127 #971901
Поясните за racer. Хуй с ним он не может в макросы. Но какого хуя он даже обычные крейты не может нормально обработать?
Взял kiss3d и рейсеру вообще похуй. Он ничего не дополняет.
#128 #971905
>>971901
RLS натяни, работает через тот же рейсер, только с ошибками из компилятора на лету и анализирует крейты.

Плагин для intellij кстати, уже даже с макросами работает — криво и косо, но навигирует уже около них (в дислокации +- 10-20 строк, лул).
568 Кб, 2880x1800
#129 #971909
Апну скрином с пруфцом работы RLS, кстати.
#130 #972199
>>956909 (OP)

>Rust


Не взлетит.

>>957136

>без сборщика мусора


>миллионы макак


Последнее не подрузамевает мозг, а равно ручной гарбейжинг, а значит без певрого не возможно второе.
#131 #972205
>>972199

>Не взлетит.


Покаместь что взлетает.
Не так сильно как хотелось бы конечно.
#132 #972252
>>972199

>а равно ручной гарбейжинг


Не так, габейджинг вообще не потребуется, потому что код будет написан безопасно либо не скомпилится.
#133 #972282
>>972252

>либо не скомпилится.


this. Так что без автосборщика мусора никуда.

>>972205
Ну и дохуя тырпрайза перекатилось на него?
#134 #972284
Че там с книжками? Кроме официальной сухой доки есть еще что-нибудь?
#135 #972310
>>972282

>this. Так что без автосборщика мусора никуда.


Ну так прочитай книжку и пойми как надо делать что бы компилилось.
#136 #972312
>>972282

> дохуя


А это сколько в цифрах?
#137 #972314
Вообще конечно расту нужны нормальные средства разработки. И вроде как они активно пилятся. Подождем, посмотрим, потому что сейчас, все что связано с растом находится в "earliest alpha stage of development".
12 Кб, 798x122
#138 #972329
Так и живем.
#139 #972330
бамп
#140 #972351
>>972314

> нормальные средства разработки


автокомплит и навигация в emacs уже давно работает
#141 #972354
>>972314
Питушок, ты что-то упкстил?
>>971909
#142 #972360
>>972282

>Ну и дохуя тырпрайза перекатилось на него?


А нахуя на расте json в xml перегонять, если для таких задач есть ява?
>>972284
Rust by example, rustonomicon, rust essentials.
#143 #972459
>>972282

>Ну и дохуя тырпрайза перекатилось на него?


Ну как бы Rust не позиционируется как замена для джавы.
Хотя, мне кажется это возможно, если создать правильные годные абстракции.

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

Тнз тырпрайз, заточен под создание проектов максимальной сложности путем задействования минимально квалифицированных трудовых ресурсов.
Совсем другая область.
#144 #972464
>>972459
Мне кажется раст будет ультрагоден для создания осей и низкоуровенего софта, т.е. там, где сейчас С и С++.
#145 #972485
>>972464
Уже же какую-то ось на расте запилили
#146 #972499
>>972485
Несколько.
#147 #972558
>>972499

>Несколько


Что-то кроме редокс есть?
#148 #972563
Да похуй на эти ваши ос. Лучше расскажите, кто-нибудь щупал аметист?
#149 #972568
>>972558
https://github.com/flosse/rust-os-comparison
>>972563
А ПИСТОН чем не устраивает?
#150 #972575
>>972568
Пистон это набор либ, а не движок. Если верить описанию с https://github.com/amethyst/amethyst/wiki/Other-Game-Engines-in-Rust
#151 #972583
>>972485
Но оно говно пока что. Что-то годное сделают когда раст станет массовым.
#152 #972679
Как же он пиздецки медлено компилится.
#153 #972725
>>972679
Быстрее плюсов.

Хотя ирл однохуйственно перекомпиливается только 1 модуль, и на минимальной конфигурации мбп 2016 весь цикл компиляции-тестов проходит быстро, если ты не меняешь весь проект и зависимости вместе взятые за раз. И в отличие от го с быстрой компиляцией, тут при отсутствии ансейфа дебаггер действительно нинужин.
#154 #972728
>>972725
Дебагер не нужен? Быстрая конпеляция не нужна? Ты всю хуйню пишешь без ошибок с первого раза?
#155 #972731
>>972728
Ты даун который мой пост не прочитал.

Но да, с его системой типов и статическим анализом он в своём каноническом юзкейсе рили не нужен. Разве что с пошаговой поддержкой IDE для изучения чужого кода прикольно было бы.
#156 #972733
>>972731
Даун тут только ты, если думаешь что система типов спасает от ошибок.
#157 #972736
>>972485
>>972499
А как можно пилить ось на языке с кучей экстерн депендов?
#158 #972737
>>972731
http://paste.org.ru/?57pxj7
Как быть если случится примерно такая история? Как раст меня от этого защищает?
#159 #972739
>>972725
Да и в го дебаггер особо не нужен, во всяком случае мало кто им пользуется ибо его нет
#160 #972740
>>972739
В го дебагер не нужен потому что
1) Быстрее въебать принт и переконпелить
2) Если ты поймаешь панику ты получишь четкий стектрейс
#161 #972741
>>972737
Не стрелять себе в ногу специально. А так в нём есть специальная деректива компилятора, ограничивающая рекурсию, если ты настолько больной.
>>972733
А ты походу считаешь что система типов это "инты, поинтеры и структуры".
#162 #972743
>>972740
В расте он не нужен потому что:
а) Если не пытаться руками завалить код — он не разыминует висячий указатель/нульпоинтер/итд.
б) Стектрейс в дебаг-билде в любом языке избыточен, вась.
#163 #972744
>>972741
По твоему кто-то специально стреляет себе в ногу? Нет, блять, это говно всплывает в проде когда ты этого меньше всего ожидаешь. Система типов никогда в жизни не научит тебя не совершать ошибок, которые вызовут у твоих клиентов жопную боль. Может ты и не сможешь поделить попугаев на тараканов, но вот вместо одного бесплатного попугая выдать чуть более 9000 - легко.
#164 #972746
>>972743
Кукаретик, еще раз тебе повторяю, что 99% ошибок это ошибки бизнес логики, а не разыменования указателей.
#165 #972747
>>972746
В высокоуровенных языках вроде явы, где их и нет. А так, открой свежий список CVE, посмотри как там дела с 1%.
#166 #972748
>>972744
Она поможет мне ковыряться в говне из байтов без стрельбы в анал и гонок данных. Давай заводи демагогию по новой.
#167 #972802
>>972736
Ты о чём?
413 Кб, 1060x700
#168 #972833
>>972459

>если создать правильные годные абстракции


А вот тут, кстати, у меня вопрос возник. Где почитать именно про приемы проектирования на Rust - с примерами неудачных решений, разбором полетов и т.д. По классическому ООП такой литературы завались, а тут куда копать? Ну или хотя бы исходники какого-нибудь годного проекта средней сложности посоветуйте.
#169 #972844
>>972679
cargo check
#170 #972849
>>972833

>Где почитать именно про приемы проектирования на Rust


Предположу, что скорее всего нигде, кроме исходников чужих проектов. Советую сначала погуглить, а если найдешь- вбросить сюда.
#171 #972856
>>972849
>>972833
https://github.com/rust-unofficial/patterns
От авторов знаменитой "learn rust by writing too many lists". Хотя там большинство контента всё ещё только TODO без описания (:

Проекты смотри где нибудь на https://github.com/kud1ing/awesome-rust
Где-то кстати видел компилятор хаскеля на расте, тоже можешь глянуть, лул.

А вообще, вся кор-тима раста работает над серво, и половина над токио — посмотри на них если хочешь кода из первых рук.
#172 #974065
>>972464
1)Примеры ымбыдеда на вашем расте есть?
2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?
#173 #974726
>>974065
1) Гугол открой;
2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты. Сравни на том же реддите активность доски раста с досками плюсов и си вместе взятыми.
#174 #974730
>>974726

>2) Потому что растотреды уже перекатов так 5 находятся под атакой жеманного, который просто топит спамом все адекватные посты.


А не тот ли это шизик, что срет в го треде?
#175 #974731
>>974730
Это ты у него узнавай.
#176 #975583
>>972856

>компилятор хаскеля на расте


нихуя ж себе
language-rust на хаскеле помню, а такого не видел
#178 #975592
>>974065

>тред, который мертвее треда полувекового С


Патамушто с неадекватами неохота разговаривать, норм чуваки все в гиттере да ирц пасутся
#179 #976237
Оправдывайтесь почему нужно писать println! вместо println
#180 #976239
>>976237
Потому что в языке нету поддержки varargs, очевидно.
#181 #976245
>>976239
Надо было делать print << ln
Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается
85 Кб, 1457x981
#182 #976250
>>976245

>print << ln

#183 #976257
>>976245

>Надо было делать print << ln


Иди нахуй за этим ублюдским говном в плюсы. Я реально рад, что сделали человеческое printf-like форматирование.

>Присутствие ! ассоциируется с мутабельностью которая вообще не при чём здесь как оказывается


Так это и не окамл, дружок. Тут восклицательный знак (тем более справа от идентификатора, хз с чего ты про мутабельность рот открыл — мутабельно передать что-то можно только явно с mut) означает макрос, местный синтаксис разыменования указателей от си был унаследован, если ты не заметил.
#184 #976259
>>976237
Зачем оправдываться? Тут два стула - либо используй макросы, либо зависимые типы. Причем раст, похоже, будет видеть на обоих.
Ладно-ладно, есть третий стул - разбирать строку формата в рантайме и обрабатывать ошибку. Но для этого есть runtime-fmt
#185 #976260
>>976259

>сидеть

#186 #976294
>>976259
Я раньше думал, что вывод имеет отношения к монадам, а тут вон че. Поясни, пожалуйста.
71 Кб, 481x857
#187 #976317
Всё правильно сделал? Как-то печально это всё
#188 #976318
>>976317
Надо было просто println!("14");
#189 #976320
>>976318
Но я хочу чтобы было AbstractSingletonProxyFactoryBean чтобы объединять данные с функциями
#190 #976321
>>976317
Похоже на go лол
#191 #976329
>>974065

>2)Почему "один из самых динамично развивающихся языков современности" в зыкаче имеет тред, который мертвее треда полувекового С?


Проблемы /pr
Потому что абсолютное большинство тредов языкача - это холивары и баттхерты, например есть го тред, но там куча неадеквата.
#192 #976345
В общем не вижу никакой разницы с С++ кроме примитивного ооп, конструкции match и опущенных {} (вау), да ещё уебанцкие сокращения ключевых слов и имён в стандартой библиотеке
Выглядит как язык от васяна где вся логика построена по желанию его левой пятки
Для деклоративного петушения со статической типизацией лучше взять Haskell, для навороченного синтаксиса Perl 6
#193 #976363
>>976345
Что-то ты забыл про главное отличие - систему типов Rust. Я и про lifetimes/borrowing, и про гарантированную на уровне системы типов потокобезопасность (вне unsafe), и про проверку типов в дженериках на этапе их создания а не на этапе инициализации. А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.
И да, модули. В 2к17 инклудить хедеры вместо нормального импорта модулей - очень странно если честно. Это по сравнению с прочим мелочь, но всё-таки.
#194 #976366
>>976363

>А в обозримом будущем надеюсь появятся зависимые типы, HKT и прочие вкусности.


Вот только не надо это сложное для понимания уг тащить в Rust.
Сейчас это нормальный язык, Haskell к услугам тех, кто желает дрочить на монады/теоркат и теорию типов.
#195 #976388
>>976366
Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?
#196 #976399
>>957444

>пример притянут за яйца. любой школьник знает


Схрена ли оно компилируется тогда?

ЛЮБОЙ ШКОЛЬНИК ЗНАЕТ
@
РАЗРАБОТЧИКИ КОМПИЛЯТОРА НЕ ЗНАЮТ
#197 #976505
>>976388

>Ты хоть знаешь что такое HKT или просто знаешь что это "что-то сложное из Haskell"?


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

просто хаскеллисты хуеют от своего рантайма и хотят свои убер-абстракции, которые и сами не понимают, но при этом хотят efficiency раста
#198 #976511
>>976345

>опущенных {} (вау)


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

>стандартой библиотеке


Жеманный, не не пались, не знаешь же. После си и плюсов с atoi(), ftol() ntohl() и друзьями в расте просто AbstractSingletonProxyFactoryBean-ы какие-то
>>976388
Братан, вот поясни мне за эти функторы — а нахуя?
Я мб тупой слишком, но из пояснений в гугле понял столько же, сколько про монады — что это моноид в категории эндофункторов, ахуенно.
Сейчас у нас есть что-то между плюсами и сишкой — с композицией и tagget-unions вместо наследования, простым синтаксисом (дада), все очень явно, модули и так далее.

Короче, качественный кусок инженерного говна, если цитировать одного йоба-математика. На нем с некоторой сноровкой, конечно могут спокойно писать васяны вроде меня у которых никогда не было пар теорката или они нихуя не понели, в общем-то, примерно 95% программистов на си и плюсах.
А еще есть тот же ATS, в котором зависимые типы где-то даже видел коммент в стиле "правильно сделанный раст" и все прочее, на котором с комментария того же йоба-математика скорость написания кода в лучшем случае "400 строк за неделю". Карл, вот что такого дадут эти зависимые типы практичному языку, а не йобе от епонца, у которого в культуре высшее просветление — аутировать смотря на сакуру?
#199 #976529
>>976511
А мне еще можете пояснить что такое линейные типы.
#200 #976538
>>976511
Cи делали 100 лет назад, в С++ этого уже нет за редким исключением, писать fn вместо function даже не каждая обоссанная обёртка для JS себе позволит. Можно было использовать define или вообще function x = x раз уж match влепили. Для серьёзного языка с ориентацией на безопасность это абсолютно неприемлимо, даже переменные так называть нельзя.
#201 #976539
>>976538
двачую, тоже это резануло, есть же нормальные def, func
#202 #976543
>>976538
>>976539
Ебать жеманного бомбонуло.
>>976529
Дык их и нет в расте, здеся у нас аффинные типы.
Линейные типы (по моему скромному пониманию, хз чо там по математической правильности) позволяют использовать объект только из одного места и запрещают копировать на него ссылки. В расте это называется владением.
В аффинной типизации есть возможность использовать объект не только из одного места. В сухом остатке, это грубо говоря есть заимствование.
71 Кб, 396x732
#203 #976555
>>976317
Вектор объектов, компилится
Подсветку не настроил ещё
#204 #976573
Ёпт, на сколько всего отвечать придётся

>>976505

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



Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.

На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?

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



Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.

> Для таких вещей есть Haskell и незачем засирать другой язык



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

>>976511

>Братан, вот поясни мне за эти функторы — а нахуя?



На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.

Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.

> Карл, вот что такого дадут эти зависимые типы практичному языку



Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
#204 #976573
Ёпт, на сколько всего отвечать придётся

>>976505

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



Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.

На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> *, то параметра должно быть два, и так далее. Разве это настолько сложно?

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



Опять-таки, так уж исторически сложилось, что функциональные языки опережают императивные в использовании более мощных систем типов. Но по факту, те же HKT к самой функциональщине не имеют прямого отношения и могут спокойно применяться в императивных языках.

> Для таких вещей есть Haskell и незачем засирать другой язык



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

>>976511

>Братан, вот поясни мне за эти функторы — а нахуя?



На самом деле определение функторов из ТК вообще не особо-то важно когда речь идёт об их применении в программировании. Функторы используют в программировании не из-за их значения в ТК, а потому что так уж случайно вышло, что под определение функтора совершенно естественным образом подпадают такие нужные в программировании вещи как списки и optional-значения (с монадами также). Так что функтор/монада - это с одной стороны интерфейс (набор признаков типа), с другой - паттерн (набор приёмов работы со _всеми_ типами которые реализуют данный интерфейс). Основная идея в том, что выделяя все эти функторы и монады как отдельную сущность, можно писать допустим какие-то функции-хелперы которые не знают ничего о конкретном типе, а знают лишь что этот тип реализует нужный интерфейс. Это позволяет местами писать более обобщённый, универсальный, абстрактный код.

Собственно, важно понимать, что в Rust уже используются техники, характерные для ФПшных монадок и функторов. Все вот этим методы типа or_else и прочее - это как раз оно. Суть в том, что сейчас в Rust всё это реализуется отдельно для каждого типа. А если выделить монады/функторы как отдельную сущность, то многие из этих методов можно будет реализовать один раз, обобщённо, для всех таких типов сразу.

> Карл, вот что такого дадут эти зависимые типы практичному языку



Возможность гарантировать отсутствие ошибок в рантайме на этапе компиляции. В общем-то, не хочешь - не используй, для большинства программ оно действительно будет излишним. Но там где любая ошибка может обойтись дорого, зависимые типы могут реально помочь, ящитаю.
#205 #976575
>>976573
блять, оно потёрло мои звёздочки
там должно быть в одном месте &#42; -> &#42;
в другом: &#42; -> &#42; -> &#42;
#206 #976576
>>976555
Братан, можно было просто:
а) Сделать impl Display for Vec<Box<Yoba>> и всё;
б) Использовать дебажную форматировку в println (которая :?).
#207 #976577
>>976573
>>976575

блядь, а это сложнее чем монады ебашить
пробую ещё раз
&#38;#42; -> &#38;#42; в одном месте
&#38;#42; -> &#38;#42; -> &#38;#42; в другом
#209 #976602
>>976573

>На самом деле в HKT нет вообще ничего сложного. Если очень грубо, HKT - это просто способ выразит общее свойство (интерфейс) не любого типа, а параметрического. То есть если тип имеет поряок (kind) -> , то у него обязательно должен быть параметр (другими словами, это обязательно должен быть generic-тип). Если порядок -> -> , то параметра должно быть два, и так далее. Разве это настолько сложно?


Ну я вот щас ничего не понял. Ты точно не стебешься? ->, -> ->
- это что?

>Как-то странно на людей влияет всё что хоть как-то связано с функциональщиной. Абстракций, которые за пять минут в гугле не особо-то поймёшь, хватает и в ООП, но как только пациент видит слово "монада", "функциональный", "Haskell", он заранее готовится к чему-то охуенно сложному, и если за 5 минут в гугле не понял суть, то мнение это лишь подкрепляется.


1. ООП все, кто связан с программированием, знают
2. В начальном приближении большинство концепций ООП можно объяснить сравнительно просто, можно это как-то постепенно изучать, а, когда на тебя обрушивается ворох стрелок и звездочек, это кажется сложным.

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

>>976588
>>976573
>>976575
>>976577
Чет проиграл если честно.
#210 #976607
>>976573

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


Ну если смогут норм внедрить эти кайнды в язык и объяснить так, чтобы понял человек, который на хаскелле только факториалы писал, то я ничего против не имею, возможно это годная вещь действительно.
#211 #976608
>>976576

>fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result {


Нихуя себе просто
#212 #976614
>>976602

> ->, -> -> - это что?



Это парсер съел звёздочки. Смотри короче ссылку на pastebin, я не ебу как эти звёздочки вставлять сюда.
#213 #976615
>>976602

>Плюс не совсем понятно, а нахуя это нужно



Те же монады и функторы нормально без кайндов не реализовать. Зачем нужны монады и функторы и попытался вкратце объяснить выше. В общем всё сводится к тому чтобы писать более обобщённый код.
#214 #976626
>>976602

Ну можно конечно какой-то другой синтаксис придумать, без стрелочек со звёздочками. Стрелочки здесь потому что те самые дженерики которыми мы каждый день пользуемся с точки зрения того же Haskell - функция над типом. Ну то есть когда мы пишем тип вроде List<Int> мы как бы вызваем (в compile-time, разумеется) функцию List с параметром Int.
#215 #976821
Я не понял насчёт параллелизма, он что реальные потоки создаёт? А корутины где?
В http://rurust.github.io/rust_book_ru полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика
#216 #976827
>>976821

>полно примеров где предлагают создавать по 10 тредов для вычислений, довольно странная практика


И что в ней странного?
Все так всегда делают.

>Я не понял насчёт параллелизма, он что реальные потоки создаёт?


Ты что реально слабоумный дебил?

>А корутины где?


Не завезли, ибо сложно и нужон сложный рантайм.
Заместо есть tokio и фьючерзы.
#217 #976834
>>976827
А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?
#218 #976836
>>976834

>А как без корутин например 100 одновременных HTTP запросов послать и обрабатывать?


Асинхронно.
Через tokio либу.

Но с такими вопросами, лично тебе, никак.

Прежде чем вкатываться в раст, нужно возыметь базовые знания вначале.
Архитектура ПК - ассемблер - си.
Да и не для раста то-же нужно.
#219 #976842
>>957093
Схуяли его меньше?
Там выразительность на уровне С++ или хуже.
#220 #976849
>>957174
Не в 6/9 а в 3/9, при этом сливает Си в 8/9,
что какбы говорит нам о качестве кода на плюсах в этих бенчмарках.
#221 #976851
>>976827

>И что в ней странного?


>Все так всегда делают.


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

>>976836

>


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


>Архитектура ПК - ассемблер - си.


Сразу видно теоретика.

>>976842

>Там выразительность на уровне С++


Так с++ довольно выразителен, если сравнивать с джавой или го.
#222 #976852
>>957308
А теперь приведи пруфы того, что Rust делает гарантированно безопасный код.
#223 #976858
>>976821
Он не слышали про количество ядер прост
#224 #976859
>>976851

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


Любой недурак, знает, что плодить потоков больше чем ядер ЕСТЬ смысл в определенных задачах.
И потому проводит тесты производительности в разных конфигурациях.

>Сразу видно теоретика.


Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.
#225 #976860
>>976859

>Пожалуй, шел бы ты нахуй, безмозглый шизик-тралль.


Хотя нет.
Оставайся тут пока.
#226 #976861
>>957587

>А преподносят как готовый продукт.


Галоперидону выпей. СРОЧНО!
#227 #976908
>>976602

>ООП все, кто связан с программированием, знают


Сижу на програмаче, следовательно я связан с программированием. я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные), следовательно это твое утверждение ложно.
#228 #976931
>>976908
Первая посылка ложна, ты не связан с программированием. Ты хлебаешь борщи и участвуешь в срачах.
#229 #976975
>>976908
Ты как минимум очень ограниченный человек, который имеет ноль интереса к своей профессии. К программированию ты действительно имеешь мало отношения, ибо не имеешь понятия о концепциях, принятых в большинстве современных языков, даже если они чем-то плохи.
#230 #977017
>>976908

>я не знаю ООП (ни единой секунды не писал на объектно-ориентрированном языке, только процедурные и фукнциональные)


То, что ты не писал с ООП подходом, что кстати сомнительно, еще не означает, что ты не знаешь ООП.
Тем более, что ты

>Сижу на програмаче


И минимум что-то читал тут о ООП.

>следовательно это твое утверждение ложно


Увы, но твои аргументы инвалид, и логический вывод мягко говоря сломан.
Что косвенно свидетельствует о твоей недалекости в целом, и в отношении процедурных\функциональных языков в частности.
#231 #977030
25 Кб, 1173x878
#232 #977055
Карго превращает каждый проект в локальное хранилище всех существующих либ раста, а в конце обязатльно что-то ломается
#233 #977090
>>977055
Это издержки любой централизованной иuild системы.
Я как вижу эти зеленые надписи про downloading-compiling, так сразу чувство, что сейчас начнется какая-то мясорубка с кишками и кровью, больно это напоминает руби, а я в свое время наебался с последним, когда для запуска одного скрипта нужна тысяча гемов ну или хз сколько и что-то всегда ломается. При этом я был не разработчиком, но конечным пользователем тех скриптов и с того времени руби для меня - ругательство.
#234 #977091
>>977090
не build системы а системы управления пакетами, сорри тупанул.
#235 #977098
>>977055
Лучше, конечно, тащить все зависимости в проект и устраивать кровь с кишками с помощью вендоринга, а потом сидеть по 5 лет на старой версии библиотеки, которая течет и работает хромая.
#236 #977106
>>977098
Карго безальтернативно устанавливается в $HOME/.cargo, так пускай складывает либы в ./cargo/lib как rlib.so.1.2.1, а не компилит для каждого проекта по 200 мб
#237 #977110
>>977106
Это растц релейтед проблема.
#238 #977204
>>977098
Вообще-то практика показывает, что лучше, т.к. это гарантирует сборку и запуск. Обновление либ - дело мейнтейнера проекта, если проект поддерживается, либы будут обновляться.
А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.
#239 #977208
>>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 работает, можно попробовать что-то сложнее факториала сделать
#240 #977211
>>977204

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


>А иначе твой проект завязывается на нечто от тебя не зависящее, либа может изменить интерфейс без обратной совместимости и твой проект сломается или просто со временем что-то перестанет собираться.



Стократно плюсую.
Жаль, линуксоидам застрявшим во временах 2мб винчестеров, этого не понять.
#241 #977221
>>977204
>>977211
Написал хуйню @ сам себе приплюсовал.
В нём можно указывать тянуть только определённую мажорную версии с минорными апдейтами, ничего не ломающими, либо вообще захардкодить одну.
Но гоферу не понять.

Хотя гау то же делает с своей GOPATH, у явы каждый пакетный менеджер тащит миллиард зависимостей для себя, в дотнете как в расте, а у динамикопитушков вообще каждый проект — своё хранилище зависимостей.
#242 #977222
>>977221
Растц может зафейлиться если ему подсунут rlib'у с той же версией что надо, но скомпилированную растц недельной давности.
#243 #977223
>>977106
Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).
#244 #977225
>>977222
Ну, в том же окамле такая же хуйня — но всё сделано в одном хранилище, как предлагает анон выше. Просто попробуй попользоваться такой хуйнёй.
#245 #977226
>>977223
Эти проблемы вроде решает guix
#246 #977247
>>977221

>Но гоферу не понять.


Это ты себя имеешь ввиду, или что?
Речь о rust е идет вообще-то.

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


Тогда все ок.
#247 #977248
>>977223

>Я вот уже представляю себе: собрал такой пару десятков проектов, и вместо того, чтобы иметь возможность просто удалить папочки с билдовым мусором сидишь и рыскаешь в ~/.cargo/lib, где каждой библиотеки по 4-12 штук (разной битности, версии релиза, вида линковки, всякой упоротой жуйни вроде pgo и тд).



А это не норм нефига.
Нафуфик оно так сделано?
Зависимости должны лежать рядом с конкретным проектом.
#248 #977253
У меня вопрос, а можно ли на винде да, да сделать так, чтобы все устанавливалось не в юзерскую директорию, а куда скажешь, например, в c:\rust.
#249 #977259
>>977253
https://github.com/rust-lang-nursery/rustup.rs/#working-with-custom-toolchains-and-local-builds

Ну ещё посмотри первый пункт в разделе про переменные среды.
#250 #977260
>>977248
Ну так они и лежат.
#251 #977378
Какой тип принимает Vec::index?
#252 #977389
>>977378
Все индексы (массивов, векторов, хуекторов) в насте только в usize.
#253 #977390
>>977389

>насте


В расте, лул, простите меня, Насти.
#254 #977416
>>977260

>Ну так они и лежат.


И в чем тогда проблема?
#255 #977420
>>977416
В том что какой-то петушок лезет из своего говно-свинарника с ахуительными советами по архитектуре.
37 Кб, 524x483
#256 #977504
Почему элемент енума в match не компилится без &?
Говорит
Item::A => 'A',
^^^^^^^ expected &Item, found enum `Item`
= note: expected type `&Item`
found type `Item`
#257 #977511
>>977504
Наверно потому что &self.world?
#258 #977606
>>977420
Тебе уже всюду гоферы чудятся, параноик.
К врачу сходи.
24 Кб, 497x334
#259 #978136
Так надо структуры в енуме хранить или есть способ покруче?
#260 #978212
>>978136
Мне вообще вся твоя затея с Enum-ом тут не нравится.

Может лучше сделать trait Cell с методом test() и передавать туда разные реализации этих cell?

https://doc.rust-lang.org/1.0.0-beta/book/static-and-dynamic-dispatch.html#dynamic-dispatch
#261 #978213
>>977204
Это одна из проблем хаскеля. Там уже и stackage завезли из-за этого, но выглядит это как снепшоты hackage периодические. Как если бы crates.io снепшотили весь целиком и проекты переезжали с одного снепшота на другой. Без этого вообще ад, сегодня компилируется, а завтра майнтайнер мелколибы сломал совместимость на какой-нибудь FreeBSD и сам не заметил.

С cargo есть гарантия, что любой снепшот проекта с какого-нибудь github можно собрать, причем любую его версию, именно с теми библиотеками, с которыми он разрабатывался.

cargo это вообще самое лучшее, что есть в расте вообще, и лучший из менеджеров зависимостей.
#262 #978214
По поводу того, что зависимости хранятся в каждом проекте отдельно.

ИМХО, эту проблему нужно решать по аналогии с ccache. Пусть все остается как есть, но еще будет незаметный для юзера кеш, куда будет все собранное складироваться, если нужно линковаться в местный билд симлинком. Малоиспользуемые библиотеки пусть вычищаются. Если симлинк из-за этого сломался, можно и пересобрать. В Rust же пилят инкрементальную компиляцию, у нее кеш будет не глобальный ли случайно?
#263 #978251
>>978213

>если бы crates.io снепшотили весь целиком


Принцип иммутабельности as is, чтобы что-то добавить, надо удалить и пересоздать. Все правильно.
#264 #978789
MUTABLE BORROW
@
MUTABLE MORE THAN ONCE

Сколько не читай доки, ничего написать на этом языке не представляется возможным...
#265 #978961
>>978789
Для больше чем 1 мутабельной ссылки есть синхронизационные примитивы, или ансейф, если ты самый умный.
#266 #978996
>>978136

>способ покруче


необязательно именовать поля, можно просто Player(PlayerData), доставать данные - как из кортежа (х.0)
#267 #978998
>>978789

>ничего написать на этом языке не представляется возможным


На Х-ле есть даже специальный блог пост для тех, кто язык как бы осилил, но вообще не вдупляет как написать приложение. Может и для раста такой завезли, поищи.
Хотя самый нормальный совет - читай исходники других проектов.
82 Кб, 815x859
#268 #979224
>>978961
Как сделать swap или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?
#269 #979227
>>978996
Не похоже на хорошую практику, даже Pos(i32,i32) с 0,1 вместо x,y как-то стрёмно смотрится
#270 #979263
>>979224

>Как сделать swap


fn swap<T>(a: T, b: T) -> (Pos, Pos) { (b, a) }
Использовать так:
let (src, dst) = swap(src, dst);
Работать будет с чем угодно. Не благодари.

>или хотя бы заставить set() работать в одной функции с get() чтобы можно было клонировать?


Клонировать и так можно через .clone().
А так — просто вынеси self.get() из матча в переменную.

Вообще, нужно сделать руководство для нюфагов на картинках — я хз как еще заимствование объяснять.
#271 #979264
>>979263

>Pos, Pos)


Тоже на T заменить "для всего".
#272 #979273
>>979263
Не отвечай этому уебку пока он код не скинет нормально (энивэй твой свап это пиздос в его случае).
#273 #981701
Sup, аноны, решил на расте чего-нибудь пописать. Очередной калькулятор не хочется, можете подкинуть идейку с гитхаба? Не прочь буду и покомиттить в рабочий проект
#274 #981727

>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 завезут.
#275 #981729
Нет, все же сказочные долбоебы

>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.
#276 #981734
>>981729
Что тебя смущает?
>>981727
До багзиллы и крестов и хкт не было. а синтаксис в любом случае лучше чем в жачкелях
#277 #981738
>>981734

>лучше чем в жачкелях


niet вкусовщина
#278 #981743
>>981738

>вкусовщина


Ну вот сам себе ответил. Не сделают.
Хотя ты всегда можешь сделать язык компилирующийся в раст (или хотя бы бэкэнд к хаскелю).
#279 #981747
>>981734
Плез, в божественном синтаксис охуенен.
#280 #981748
>>981734
Ах да, меня смущает эта задротская зацикленность не неважных вещах.

>some unnecessary run-time parsing


как будто код только и занимается этим и небо и Аллах и тепловая смерть Вселенной зависят от этой оптимизации, в которой говорится в комментариях к релизу.
#281 #981835
>>981748
А ты хотел чтобы они тебе каждые 6 недель ахуенные релизы выкатывали? Такой цикл разработки нужен для вылизвания существующего кода.

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

а с этой новой хуиткой, не тратящей время на парсинг ип, можно писать убер быстрые сканеры диапазонов ип для локалхоста, ну чо ты
#282 #981914
Раст когда-нибудь обгонит С?
#283 #982031
>>981914
Он транслируется в LLVM байткод и обогнать C не может по определению.
#284 #982070
>>982031
C тоже в него компилится. А в гнутом компилире компилится в их GIMPLE.
#285 #982135
>>982031
Ходят слухи, что благодаря своей охуенной системе типов Rust теоретически может предоставлять LLVM информацию, которая позволит производить всякие продвинутые оптимизации. Так что с развитием и Rust, и LLVM вполне возможно, что Rust станет в местами быстрее сишечки/крестов.
#286 #982151
LLVM - это хайпнутое г и он никогда не будет быстрее гцц или даже Borland C++
Может, за счет убер-системы (которая просто хитро переносит часть рантайма на время компиляции) он будет где-то быстрее С или плюсов, но это лишь частные случаи, где-то и Hsakell быстрее С, такие кейсы любят находить фанбои того или иного языка, но общая картина всегда будет такой, что языки более высокого уровня медленнее С/С++.
#287 #982152
>>982151

> никогда не будет быстрее


Почему?
#288 #982155
>>982152
Потому что высокоуровневость и скорость разработки всегда меняется на скорость выполнения.
На пыхе ты можешь за 20 минут что-то высрать даже будучи учеником пятого класса, но скорость будет меньше, чем у правильно написанного кода на С, решающего аналогичную задачу.
#289 #982157
>>982155
Причем тут пхп? Я думал мы ллвм и гцц сравниваем. И гцц далеко не везде обгоняет ллвм/цланг.

> высокоуровневость


Что-то мешает компилятору высокоуровневого языка высрать такой же машинный код который высирает гцц?
#290 #982179
А нахуй нужны эти кланги, ЛЛВМ?
Есть гцц, уже довольно давно. Какой смысл в этой херне?
#291 #982180
>>982179
Для нового языка проще запилить фронт для llvm, чем пилить новый компилятор с нуля
#292 #982181
>>982179
Подальше от Штульмана.
#293 #982202
>>982135
Ну он уже местами быстрее судя по базовым тестам.
#294 #982205
>>982151
Тогда почему кланг уже разъебывает гцц?
http://www.phoronix.com/scan.php?page=article&item=gcc7-clang4-jan&num=1
#295 #982218
>>982157
Если говорить про php подобные, машинный код можно сделать только если вставить в бинарник интерпретатор целиком
#296 #982283
>>982151
Ору с тебя. LLVM IR не высокоуровневее чем IR GCC (не помню как там он называется). Вся разница в том что инфраструктура LLVM более современная, универсальная и лишённая некоторых легаси-косяков GCC.
Ещё раз, для тупеньких: LLVM IR - не высокоуровневый язык. Изначально вся инфраструктура Clang + LLVM вообще создавалась для компиляции C, и уже потом LLVM стали использовать как бэкенд для других языков.
#297 #982343
>>982205

>Тогда почему кланг уже разъебывает гцц?


Найти пример, где кто-то кого-то разъебывает всегда можно.
Например, самый быстрый сервер статических файлов написан вроде на D или Haskell, но это не значит, что в целом эти языки быстрее С (язык с GC в принципе не может быть быстрее языка с ручным управлением памятью).

>>982283
Высокоуровневый язык - это Rust.
LLVM - это просто высер. Для хипстеров штучка, понимаешь? Поигрался, м.б. написал свой компилятор для своей джавы, где вместо слова class будет хуй и тип не перед, а после идентификатора.
#298 #982345
Да кстати Rust - это тоже высер для хипстеров, что видно даже по лого. Это для тех, кто хочет почувствовать себя ололо-инжинером, который манипулирует байтиками и управляет памятью через ансейф, но который при этом не осилил C/C++.
#299 #982357
>>982343
Охуеть, какой - то чухан мало того, что несёт какой-то бред, да еще использует слово "хипстер", как оскорбление. Ты, блядь, и хипстера поди не видел в своём залупинске, а туда же. Аргументации 0 (ноль), компетенции 0 (ноль), а лозунгов и пафоса на серьезных щщах на весь тред хватит.
#300 #982360
>>982357
А какая тебе нужна аргументация, если весь механизм владения-заимствования - это подпорка для скорбных умом, у которых на языках с ручным управлением памятью будут утечки. Этим товарищам на джаве бы писать, но они хотят ощутить себя системными архитекторами и вот для них придумали эту игрушку.
#301 #982362
>>982345
Никакой хипстер не осилит раст, это вообще язык не для людей. С++ немного проще из-за мутабельности и слабой типизации, пока не дойдёшь до шаблонов, которые тоже не для людей и никто их не понимает полностью.
#302 #982363
>>982362

>это вообще язык не для людей


Что в нем сложного?
Понял заимствование, смарт-указатели и все.
Проще, чем ловить секфолты.

> С++ немного проще из-за мутабельности


Так сложно вставить слово mut, да?

>слабой типизации


Слабая типизация создает только проблемы.
#303 #982371
>>982363

>Что в нем сложного?


Правила видимости непостижимы, например.
#304 #982377
В расте синтаксис ебанутый и отягощенный и совсем не однородный. Да и разве не было языков с линейными типами уже? Чем раст лучше них?
#305 #982385
>>982343
Но там не один пример, а целая кипа примеров, где гцц сосет. Так что уж просто это скорее тенденция, чем исключение.
#306 #982388
>>982360

>вот для них придумали эту игрушку.


Эта игрушка по скорости ни чем не уступает крестам, но при этом меморисейф, что является ключевой килер фичей.
#307 #982395
>>982371
Блять, додик, что ты вообще делаешь в программировании? Это тоже самое , что shared, unique и weak указатели.
#308 #982424
>>982357
Хипстер - это как раз тот, кто с умным видом втыкает в "современные технологии". Примеры говна, которое любит хипстота - это Scala (и обязательно с экстенсивным использованием scalaz), кложа и т.д. При этом ладно бы они действительно что-то в этом понимали, а то большей частью скидывают друг другу статьи на хабре "как функциональное программирование помогло нашей компании".
И Rust примерно для таких, кто хочет играться с байтиками, но на сях без секфолтов не может hello world написать.

>>982388

>Эта игрушка по скорости ни чем не уступает крестам


Ахахаха.

>>982385
Так можно взять почти любой яп с толстым рантаймом и сказать, что он пижже, потому что в некоторых случаях он будет оптимизировать решение. Обычно в таких примерах просто специально оставляют простор для оптимизации и потом говорят, что их (язык, компилятор) быстрее.
#309 #982432
>>982360

>Динамикодриснявая вебмакака не палится

#310 #982463
>>982395

>Это тоже самое , что shared, unique и weak указатели.


Мы придумали проблему а теперь будем с ней бороться.
#311 #982491
>>982424
Ты где толстый рантайм у раста увидел-то?
#312 #982492
>>982362
Ну ты-то явно ни Rust и C++ дальше хелловорода не знаешь. Как будто в Rust нет мутабельности, лол.
#313 #982495
>>982360
Ох уж это раздутое чсв. Все такие охуенные, код сразу без ошибок пишут. Статическая типизация им не нужна, потому что зачем нам типобезопасность, мы и так код правильный пишем. Система владений-заимствований нам не нужна, потому что зачем нам безопасность работы с памятью, мы и так код правильный пишем. Охуеть просто, иди подойди к зеркалу и подрочи на себя, раз ты такой охуенный кодер.
#314 #982497
>>982424

>Ахахаха.


Так и есть. У тебя врети что ли?
>>982424

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


Повторюсь тут в 80% случаев ллвм нагибает гц.
#315 #982498
>>982343

>и тип не перед, а после идентификатора.


Я тебе сейчас секрет открою, но везде так делают потому что:
а) Компактнее записывать модификаторы (вместо всяких const out int hui просто var hui);
б) Легче и быстрее парить;
в) Лаконичнее живёт с выводом типов.
Даже в твоём говне так это работает.
>>982463

>в говнище вообще нет возможности контролировать указатели, нету и проблемы, кококо



Жеманный опять трет топит, луль.
#316 #982499
>>982495
Ага, а потом годами выскребают зеродеи.
#317 #982500
>>982498

>парить


парсить
ох уж эти хипсторские вэйперы
#318 #982501
>>982345
Дело не в осилил или не осилил C/C++, а в том что работать с Rust тупо приятнее (не говоря уже о том что безопаснее). Это касается как самого языка (клёвая система типов, нормальный match, if/match as expression, модули, гигиенические макросы и т. д.), так и инфраструктуры (нормальный пакетный менеджер, например). Если есть возможность использовать инструмент который использовать приятнее, то что в этом плохого, м?
#319 #982509
>>982343
LLVM - это охуенно мощная инфраструктура, в разработку которой было положено дохуища человекочасов. И сейчас LLVM гораздо более зрелая и удобная в использовании система, чем GCC. Начиная с того что LLVM легче расширяется и имеет более внятный дизайн и заканчивая тем что у LLVM в принципе есть внятная документация.
Скажем если кому-то нужен компилятор той же сишки для кастомного процессора (и это не выдуманная мной задача), то самый адекватный вариант - скачать сорцы LLVM, открыть документацию по написанию бэкендов к LLVM и сесть писать бэкенд. Документация вполне ок, хотя информации конечно меньше чем для написания фронтендов.
#320 #982512
>>982509
Ты самое главное забыл — LLVM лицензирована MIT, а не ЖоПаеЛью, и Шульман со своими юристами не придёт к тебе если ты решишь продавать и распространять свой софт не открывая исходников.
#321 #982514
>>982500
ставлю тип после идентификатора, законом не запрещено, парсить на 95% быстрее и легче
20 Кб, 250x252
#322 #982515
>>982512

>Шульман


Штульман* конешно
#323 #982517
>>982514
Иди лучше к жавадаунам, они до сих пор пишут AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());

Скоро у пайка начнется деменция и в говне настанут такие же темные времена.
#324 #982525
>>982517

>AbstractSingletonProxyFactoryBean<Hui, Zalupa> kek = AbstractSingletonProxyFactoryBean<Hui, Zalupa>(new AbstractSingletonProxyFactoryBean<Hui, Zalupa>(), new AbstractSingletonProxyFactoryBean<Hui, Zalupa>());


Охуенно же.
#325 #982527
>>982517
даже у жавадаунов уже var kek = ..., разве нет?
#326 #982533
>>982527
Так меньше символов и меньше оплата
#327 #982551
>>982527
Нет, и в ближайшие 3-4 года до жявы 10 не предвидится.
#328 #982554
>>982377
Двачую этого.
#329 #982563
>>982377
Ну был и есть ATS. Официальный саппорт и форум на епонском, доков 0, только примеры факториалов, на языке писать без выдрачивания теорката нереально (он куда сложнее хачкеля, больше похож на теоремпрувер чем на яп) — тайная военная разработка страны восходящего солнца. Теперь как сам думаешь, чем?
#330 #982622
>>982517
Тебе видать какие-то нехорошие жабисты попались, когда еще маленьким был, вот и осталась фобия хотя если судить по тому что пишешь, тот еще джуниор. Можешь показать на проекте в гитхабе, за какие места тебя трогало?
#331 #982624
>>982563
Помню помню, этот язык с нескушными идентификаторами вроде viewt@ype и с различным цветовым кодированием разных категорий кода.

Даже порывался учить, но по модулю ебанутости автора не дотянул.
#332 #982675
>>982424
Каночные хипстеры пишут на Ruby и Java(coffe)script в Sublime Text/VIM.
#333 #982681
>>982675
Каноничные - да, но надо же орать, что не хипстор и что твоя технологие неебаться инжынерная и ты прямо байтики ксоришь и у тебя все на указателях, естественно, умных, а еще иммутабельность и вообще.
#334 #982732
>>982675
Я скажу больше, у каждого свои представления о каноничных хипстерах. Границы определяемого расширяются с изменением определяющего. Вот у нас в компании, уж настолько настолько хипстерский народ (разной временной градации от протохипстеров с зеркалками до постхипстеров с подворотами итп, а все туда же - нет, да всплывет жалоба на хипстеров. Хоть ультрафильтр заводи.
48 Кб, 1699x484
#335 #985871
Не могу понять, как вернуть введенный с клавиатуры код в срез и вернуть его из функции mesinput. Лучший ли это способ вообще - возвращать ввод с клавиатуры в качестве среза, чтобы потом отправить его через tcp? Код пикрелейтед.
3,6 Мб, webm, 480x360
#336 #986142
>>985871

>Этот код


Пиздец, я думал раст лучшая замена крестам, а тут та-же ебанная лапша.
#337 #986144
>>986142
Этой какой-то цпп с синтаксисом раста. С кучей ошибок и, как результат, даже не скомпилируется.
20 Кб, 835x107
#338 #986286
>>986144
>>985871
Додик, ошибки читай хоть.
#339 #986460
>>986286
Это новый стиль жеманного, постить код в скриншоте и не реагировать на ответы, выше посмотри.

У нас тут вместо треда какая-то игра в мафию, только вместо мафии жеманный, лул.
#340 #986603
>>963997
>>964005
Нахрена вам IDE, долбоёбы? Код пишут с помощью рук и мозга в первую очередь. Если проект насколько запутан, что в нём нельзя ориентироваться без IDE - это говнокод, который надо выкинуть нахуй. Собирать нужно в консоли, текстовых редакторов с подсветкой для раста предостаточно, во многих даже автокомплит и линтинг есть.
#341 #986606
>>986603
Ебать жеманного прорвало.
У говна иде того же качества, что сейчас у раста. а плагин для жидеи кстате лучше гогланда, или как минимум его билда месячной давности
#342 #986607
>>986460

>и не реагировать на ответы


Такие только со своим ЭКСПЕРТНЫМ мнением вкатываются, и с хуями в ротешнике молча выкатываются.

>>986603

>с помощью рук и мозга


Как ты тогда его пишешь, если не обладаешь ни тем ни другим.
#343 #986608
>>986607

>Уряря толстую жопку порвало

#345 #986611
>>986609
Типа маскот гау 2.0 — сусли-циклоп?
Тонка
#346 #986667
>>986460
Да тут пол-треда, если не больше - "жеманные". Как мимо пройти и не зайти, поглумиться.
#347 #988399
rust. sql embedded. sqlite. what?
#348 #988404
>>988399
Ты долбич?
#349 #989218
Кто-нибудь может пояснить за обработку ошибок в 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? В офф. документации, не объяснен доступным языком этот момент.
#350 #989233
>>989218
Читай файл в успешной ветке матча, и замени p на pa, тебе же компилятор прямо написал.
#351 #989321
>>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 при этом должен возвращать одинаковые по типу значения, но как это сделать, я не знаю.
#353 #989345
>>989339
Спасибо за помощь.
#354 #989396
>>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
#355 #989494
>>989396
Так даже лучше. Спасибо, что разъяснил.
#356 #989496
>>989396

>thread 'main' has overflowed its stack


>fatal runtime error: stack overflow


Мало того что код говняный (из-за ублюдского синтаксиста, твоей вины нет), так ещё падучий.
#357 #989709
Добрейший вечерочек, уважаемые. Как там у вас с IDE в 2017 году?
#358 #989712
>>989321

> Err(_) => main()


Ты что больной?
Запускай свою хуйню в цикле и выходи в ветке ok, а в альтернативной выводи сообщение об ошибке.
Иначе ты просто уйдешь в рекурсию. И вообще, какой придурок может рекурсивно вызывать main, сколько живу а такого наверное не видел.
#359 #989714
>>989709
Юзаю плагин для eclipse, все вполне нормально автокомплитится.
#360 #989716
>>989496

>челик пытается открыть файл которого нет


>потом вызывает эту функцию (причём точку взода) бесконечно


Ору бля.
В говне такое тоже не сложно делается, расслабься.
#361 #989722
>>989709
Плагин для идеи уже в отличном состоянии — всё, от рефакторингов до автокомплита и линтинга с отслеживанием лайфтаймов уже есть (только вложенные макросы парсить не умеет), скоро даже дебуггер даже будет.
Алсо, есть RLS если не хочешь жаваподелий, с примерно тем же функционалом (но вообще не работает с макросами и анализов, нужно поебаться с настройкой и у линтера явно меньше).
#362 #989810
>>989716

>В говне такое тоже не сложно делается, расслабься.


Такое можно сделать почти на любом языке, нужны только кривые руки, ничего более.
#363 #990074
>>989712
Я знаю, что использовать рекурсивный вызов функции является злом, но никак не могу понять как сделать так, чтобы при неверном вводе предлагалось ввести текст заново, а не делать panic.
#364 #990116
>>990074
https://doc.rust-lang.org/book/guessing-game.html самый древний туториал по расту как раз это и объясняет.
#365 #990136
>>990074
Я же вроде написал - делай это в цикле и выходи с него при успехе.
281 Кб, 1312x585
#366 #992960
Помогите с TOML. Пытаюсь выполнить cargo build и выдает couldn`t parse as TOML. Насколько я понял файл TOML сгенерирован самим cargo для одной из зависимостей. В чем проблема? В cargo самой программы в [dependencies] только строка hyper="*".
#367 #992973
>>992960
Да нет, долбоёб, он твоим больным мозгом генерируется. Сначала ты стёк переполнял рекурсией входной точки, теперь в заголовки конфигово томла пихашь куски кода.
#368 #992978
>>992973
Шизик! Шизик!
#369 #992990
>>957553
иди нахуй со своим NT-говном и миниксом с овердохуя сисколлов. в редоксе ровно 31 сисколла, там даже сокеты через open создаются, как файлы. больше не нужно.
#370 #992991
>>992960
rm -rf ~/.cargo/registry сделай
#371 #992998
>>992978
Ну так это ты и есть, лол.
Минутка грамотности: генерируются .lock файлы, а не томлы, ti obosralsya.
#372 #993001
>>992960
>>992991
так стоп падажи ебана, ты что либу time пытаешься установить?
#373 #993197
#374 #993323
>>993197
И зачем нам помогать тебе заниматься фистингом?
72 Кб, 768x596
#375 #993449
>>993197
зависимости на библиотеки нужно добавлять в Cargo.toml своего проекта, cargo install ставит некоторые програмки типа rustfmt и плагинов под cargo, но не либы
#376 #993454
>>956909 (OP)
Друзья, раст мертв при рождении , переходите лучше в Golang тред, пока не поздно!
#377 #993486
>>993454
golang

>gc


>дженериков нет


>мутексы не связаны с данными, которые они охраняют


>проброс ошибок по стеку анальная мука


>неюзабелен для написания драйверов


>нет паттерн матчинга


>система типов какая-то параша


>компилятор не может доказать отсутствие одновременного доступа к не-атомным данным


>код сложнее хеловорлда на голанге похож на вырвиглазный кал


>...


идеальный язык для вебмакак. что в голанге хорошего, это то, что он простой и что в нем искоробки forkjoin
#378 #993505
Не так уж много языков со столь уродским синтаксисом. Такой-то перл 21 века.
#379 #993598
>>993505
Ваше мнение очень важно для нас
5 Кб, 400x314
#380 #993872
#381 #994322
От раста будет профит, если мне хочется ради фана васянить свою 2D rpg на нём, а не на сях?
#382 #994326
>>994322
На питоне или жсе нахуячь. В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой (которая очень нужна в твоей 2д залупе). а вообще, иди ешь торты.
80 Кб, 1920x1080
#383 #994340
>>994326

>В расте ты будешь трахаться с заимствованием и всякой низкоуровенной отрисовкой


То, что мне и нужно.
HelloWorld готов, теперь можно и изъёбствами языка обмазаться.
#384 #994357
>>994340
пишу в свободное время игрушку поигратся на вулкане на расте, раст таки заебись, советую
#385 #994514
Аноны, кто учит раст, радуйтесь, у вас есть cargo - сама охуенная система сборки и управления зависимостями, сеьёзно. Я тут вкатываюсь в кложу, язык для своих целей ящитаю годный, писать на нём приятно, но вот сборка это ад, по сравнению с растаманским cargo и даже питонячьим setuptools. У меня всё.
#386 #994516
>>994514
gradle для кого сделали?
#387 #994593
>>994514
И чем он лучше lein?
#388 #994603
>>994514
На большинстве статически типизированых языков сборка это ад. Либо у тебя длиннющие и неудобные makefile.am, либо cmakefiles.txt, где забываешь уже через полгода что для чего инклудил. В мире java это хотя бы имеет более человеческое лицо, спасибо jetbrains за труды.
#389 #994656
>>994516
Жява-энтерпрайз-оверинжиниред-говнище.

>>994514
Ты как нибудь с окамлом поиграйся. Поверь, это пожалуй самый ахуительно собирающийся язык.

>>994603
При чём тут статика-то, долбоёб? Это у всех компилируемых языков с легасиговном вместо системы сборки такая проблема.

В тех же плюсах (священное поприще легасиговна) дохуя билд систем вроде Qbs и meson, которые по большому счёту не сильно-то и уступают cargo.
#390 #994687
>>994603
Ну я пока для упражнений из K&R накатал скрипт на петоне который генерирует ниндзя-файл. Очень удобно и прозрачно, вообще в последнее время часто вместо систем сборки использую самописные скрипты, потому что мне нравится полностью контроллировать процесс сборки. Вот в leiningen я не чувствую что я вообще что-то контроллирую, какая-то непонятная медленная не работающая так как мне нужно магия. Попробую в Boot вкатиться, говорят, он получше.
#391 #994688
>>994656
Вот огромная проблема всех этих крестовых билд-систем в том, что нет какого-то единого репозитория пакетов, как в расте. Так что или клади зависимости в git submodules, или довольствуйся теми пакетами, которые есть в репозитории используемой билд-системы, или сам упаковывай пакеты, или я не знаю что ещё. В расте же сделали сразу по-человечески, и это охуенно.
#392 #994712
>>994688
Дык я не спорю, я это говорил к тому, что жто не статики проблема.
Есть же кроме этого тягатели зависимостей с гитхаба по тегам и версиям.
Скоро ещё мб осилят подход как в том же гредле — указывать источники зависимостей.
#393 #996456
Бомбану во имя Аллаха.
#394 #1000296
Есть способ получше найти самое большое число из тех же цифр?

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()
#395 #1000343
>>1000296
Определенно есть способ быстрее.

Ты критерий лучшести задай.
5 Кб, 527x47
#396 #1001734
Что это за хрень получается? Компилятор говорил, что для &&{integer} нет оператора ==, добавил две звёздочки - работает. Ничего не понял.
#397 #1001903
>>1001734
Мудило с картинками, ты опять на связь выходишь?

>что для &&{integer} нет оператора ==, добавил две звёздочки - работает


Наверно потому что звездочка перед идентификатором означает разыменование указателя/ссылки.
#399 #1002746
Компилятор раста написан на С++?
Фу, блять, какой позор.
#400 #1002796
>>1002746
ллвм на цпп. растц на расте
#401 #1003231
>>1002746
Первая версия была на окамле, потом все на нем самом же.
#402 #1003334
>>1003231
Зачем тогда раст требует установленного MSVC++ ?
#403 #1003376
>>1003334
Потому что ты - спермовор у спермы свой особенный и единственный линкер и набор библиотек (всякая символы для системных вызовов, динамические библиотеки и прочая хуйня без которой ты буквально хэловорд не соберешь).

Он собственно требуется всеми известными мне компиляторами (врде д, пони, окамла). Разве что го-велосипедисты написали свой, который срет бинарями хэловордов по 10 мб на которых любой дизасемблер падает с ООМ.
#404 #1003436
>>1003376

>го-велосипедисты написали свой


Вот это мне нравится.
#405 #1003502
>>1003436
>>1003376

>который срёт бинарями хэловордов по 10 мб


>и хуй тебе а не нормальный dead code elimination, будем бить по рукам за неиспользованные импорты


>хуй тебе а не link time optimization, profile guided optimization, межпроцедурный анализ и всё остальное, прямо или косвенно требующее поддержки линкера


Да мне это тоже нравится, братишка.
#406 #1004765
Поржал с вас.

Мимо эйфеле-господин
#407 #1004857
Поржал с эйфеле-го-раст борщехлёбов.
Мимо-цпп-боярен
#408 #1004970
>>1003502
Лучше жрать говно, чем обмазываться сишным дерьмом.
#409 #1005115
>>1004970
Суть в том, что сишный линкер как раз таки заебись.
165 Кб, 512x512
#410 #1005400
>>1005115

>сишный линкер как раз таки заебись

#411 #1005490
>>971909
snake_case, CamelCase, всё в куче, что за пиздец.
sage #412 #1005492
>>1005400
Ну да, не то что в расте. Можно пельмени сварить там, или чай заварить, пока всё линукется - разработчик никогда не останется голодным
#413 #1005753
>>1005492
Да в настах и сих дело не в линкере. И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.

>>1005490
snake_case для имен функций и переменных и CamelCase для типов и структур — самое лучшее сочетание евер.
#414 #1005760
>>1005753

>И всякие gccgo от наличия нормального компоновщика е сильно проседает в скорости компиляции.


Ты бы ещё рассказал ему что си имеет текстовый препроцессор, каждый раз заново парсит все инклуды и просто не укладывается в какой нибудь LL(1) с лукапом в 1 символ как его говно, а расту для чека каждого лайфтайма нужно обходить графы всех затронутых функций и объектов для каждой хуитки и заниматься прочим статическим анализом.

>>1005490
Тем временем, в говне из модуля функции, структуры и (!) переменные (!) импортируются по регистру первой, сука, буквы. Повар, какого хуя ты вообще рот открываешь?
#415 #1008074
Бляя, растоблядки, объясните мне, в чём разница между immutable variable и const?
Всякие пидоры на стэковерфлоу пишут "НУ ТИП ЭТ ТЫ ПРИВЫК К С++!!!))) В РАСТЕ ВСЁ ПО-ДРУГОМУ!))) ПЕРЕМЕННЫЕ ТИПА НЕ МЕНЯЮТСЯ))"
Какого хуя, если variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени. Какого хуя всё так тупо?
#416 #1008108
>>1008074
Если бы Страуструп стал женщиной и его отымел Милнер, то вместо C++ появился бы Rust.
В общем, я что сказать хотел... Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.
#417 #1008128
>>1008074
const в расте — это как дефайн в сях, просто подставляемое значение.
И var в русте нет, здесь только let, шо как бы намекает дебилам как ты.
#418 #1008130
>>1008108

>Если тебе нужен ML, то юзай ML. Если нужен C++, то юзай D.


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

Д — я надеюсь когда нибудь его зотя бы до состояния раста допилят, языку десять лет а он сырой как твоя мать на концерте Маликова.
#419 #1008134
>>1008130

>Все ML-и дохлые


PolyML недавно релизнулся. Правда, Юникод так и не завезли.
#420 #1008166
>>1008134
Он релизнулся раньше чем ты родился, так с того времни никуда не сдвинувшись с SML 97, куда там.

Если хочется ML-я — тут есть окамл который хотя бы развивается, и куча трупов.
#421 #1008169
>>1008134
Ну кроме окамла ещё F#, но там больше шарпа в смысле парадигмы (хотя сексуальные хачкель операторы вида <><[][——€•^`>> на месте).
#422 #1016135
>>1008074

> variable - переводится как ПЕРЕМЕННАЯ, и дословно обозначает какие-то изменения во времени


> во времени



Распространённое заблуждение. Слово "переменная" пришло из математики, где никакого изменения во времени оно не означает. Оно означает что значение может меняться в зависимости от исходных данных (то есть, по-нашему, от запуска к запуску). А вот "константа" в математике - это то, что не меняется вообще никогда, с любыми исходными данными. Собственно, const в Rust это как раз значение известное на этапе компиляции, тогда как значение переменной вычисляется уже в рантайме.
#423 #1016139
>>1016135
Вот да. А меняться во времени это уже к реактивному программированию.
#424 #1017796
Пока хуйтеры срут, оракл выкатил новую залупу на расте в опенсорс.
#425 #1017832
>>1017796
Что конкретно?
#427 #1018061
>>1017854
Нормально.
#428 #1018493
>>957819
Но как же, господа, ведь математически докококазана безопасность.
#429 #1018496
>>972459
У тебя какой-то галлерный руснявый тырпрайз.
#430 #1019277
>>1018496

>У тебя какой-то галлерный руснявый тырпрайз.


Нет никакого другого тырпрайза.

Ты бы пообщался с тырпрайз работниками из штатов.
Поголовно всем на все посрать. Свиноматки в декрете работающие(системным аналитоком) из дома и нехреа непонимающие в происходящем.
Жрущие во время митинга по скайпу и успокаивающие там же ребенка.
Индусы (настоящие американцы).
И прочие прелести.

Здоровому человеку в этом всем говне делать нечего.
#431 #1019290
>>958602
Можно поместить себя в клетку и так прятаться от собаки, а можно собаку поместить в клетку.
#432 #1019384
>>1019277
Не знаю, занимаемся промышленной разработкой небольшой командой и ус не дуем. Решения выбираем прагматично, код пишем рационально, не полагаясь на карго-макакинг.
#433 #1020115
>>1019384

>занимаемся промышленной разработкой небольшой командой


И причем тут энтерпрайз?

>занимаемся


Доход поровну делите?
#434 #1020240
>>1020115
Тому що предназначение софта - аэрокосмическая промышленность.

Ни.
#435 #1020435
#436 #1020631
>>1020240

>Тому що


Свиней давно в космос запускать начали?
#437 #1020638
>>1020631
Не, я конечно допускал, что две буквы могут к подрыву привести, но всё же, рассматривал больше как теоретическую возможность, всё же /зк.

Приятно удивлён
#438 #1020838
>>956931

>пизже


>GC


обкекался
#439 #1020983
>>961111
Не совсем, Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность). Как бы Rust не старался, плюсы еще долгое время будут жить, а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй. Но, на данный момент, язык дико молодой и, как следствие, сырой.
#440 #1021225
>>1020983
Раст уже поржавел.
#441 #1021466
>>1021225
Ты чё сука ты чё. Раст популярнее и популярнее с каждым днем: вот новость недавняя, даже оракл выпустил приблуды для изолированных контейнеров:

https://github.com/oracle/crashcart
https://github.com/oracle/railcar

Глянуть в код, увидеть - та еще параша, а я зык выбран из соображений - поиграться
#442 #1021632
>>1020983

>Rust объединяет в себе положительные черты плюсов (контроль) и джавы (безопасность)


Не осилил лайфтаймы. Есть по ним вменяемый тутор?
#443 #1021847
>>1020983

>а вот Джава со своей виртуальной машиной и огромной прожорливостью, возможно, когда-то пойдет нахуй



Давно бы уже пошла, если это было бы проблемой.
#444 #1022032
>>1021632
Есть. Называется практика и ебля в жопу с компилером.
#445 #1024575
Есть такой теоретический вопрос. Посмотрел стандартную библиотеку раста, а там нет даже либ для http. Вопрос, как реализуют такие библиотеки, в теории. Используют какие то либы операционной системы, или как то по другому?
#446 #1024577
>>1024575
Говорят системе открыть сокет пишут туда
#447 #1024721
Заебала долгая компиляция. Как я понял, в расте нет аналогов объектных файлов из цепепе, когда вношу любое изменение - проект пересобирается полностью. У меня 17к строк в проекте (большая часть - сгенированные биндинги opengl), компиляция занимает секунд 15.
Похоже, придется перекатываться на кресты.
#448 #1024771
>>1024721
Охуеть теперь. Я и по 2 минуты ждал постоянно потому что в движке было много объектых файлов и пека слабый.
#449 #1025182
>>1024721
Че ты понял? Че ты понял сука,тебе вьебать, а?
112 Кб, 200x440
#450 #1025507
>>1025182
Ржавый?
#451 #1033011
>>976573
Фп-кун, ты еще тут?
#452 #1034290
Чому на расте так мало проектов пилятся? С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow, а с другой стороны работы на нём нет и положительных тенденций нет
#453 #1034291
>>1034290
Очень недружелюбный язык для вкатывания, поэтому просто нет тонны всяких "бот для телеграма на %языкнэйм%"
#454 #1034439
>>1034290

>С одной стороны он второй год подряд является самым "любимым" языком по версии StackOverflow


Это значит только то, что он вызывает больше всего вопросов.

>так мало проектов


Завезли бы корутины.
#455 #1034577
>>1034439

> Это значит только то, что он вызывает больше всего вопросов.


Нет, это они опрос проводили. https://insights.stackoverflow.com/survey/2017

> Завезли бы корутины.


Стекфул корутин, как в Го, не-бу-дет. Копают в сторону стеклесс и асунк/ашаит.
#456 #1034748
>>1034577

>Нет, это они опрос проводили.


Ах лол.
Любимый в смысле на нем не программируют, но что-то слышали.
#457 #1034753
>>1034290
Каких это проектов там мало? Каждый Вася Жопин не пилит свой веб фреймворк и бот для телеграма умеющие нихуя?
#458 #1034757
>>1034753
Как раз веб фреймворки по-моему и пилят. Не совсем понимаю зачем они нужны.
#459 #1034766
>>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.

#460 #1035038
>>1034766

>Болезный?


>> For the second year in a row, Rust was the most loved programming language. This means that proportionally, more developers wanted to continue working with it than any other language.



Ну, это замечательно.
Учитывая, что в категории Programming Languages в том же опросе, раста нет вообще.
То есть им не пользуются от слова совсем.
А кучка шизиков на нем кодящих хочет кодить и дальше, что как бы закономерно.
#461 #1035050
>>1034757
Нативных альтернатив нет, но бизнесу всё равно выгоднее использовать асп.нет, а большинству и пхп сойдёт, так что задач нет.
#462 #1035334
>>1033011
Давно не заходил, теперь тут
#463 #1035337
>>1024721

> компиляция занимает секунд 15.


Так тебе программы писать или лабу2 конпелировать?
мимо скала-боярин
#464 #1035355
>>1035337
Напейсание лаб ныне кличут TDD.
#465 #1035358
>>1024721
В анус себе перекатись, блять, начинают кодить на Visual Studio и начинаются ебаться в жопу и думать, что компилятор сам по себе выполняет функционал makefile
#466 #1035947
>>1035337
Причем тут лаба, долбоёб?
На крестах есть инкрементальная сборка, крупный проект первый раз может собираться несколько минут, а потом, когда вносишь изменение в несколько файлов, проект пересобирается уже за пару секунд, т.к. собираются только затронутые объектные файлы. А в расте такого нет, если у тебя в проекте 1000 файлов, а ты изменил 2, при сборке будет собираться полностью.
>>1035358
Какая visual studio, какие makefile, ты чем там объебался?
Я так-то под линуксом сижу и юзаю cmake/clang.
#467 #1035958
>>1035947
Да, действительно ебу дал, на rust нет инкрементной сборки.

Охуеть, это какой-нибудь проект уровня хрома после каждого патча целый день собирать? Как жить-то?
#468 #1036281
>>1035958
Делить проект на крейты и жить как белый человек с модульной архитектурой кода, а не заниматься напейсанием индусских монолитных кусков говна на миллионы строк, как это помогли делать миллионам макакусов K&R. Открой исходники серво и посмотри как это делается.

Вообще, ты даже до гугла похоже не добрался — там есть инкрементальная компиляция https://internals.rust-lang.org/t/incremental-compilation-beta/4721 , другое дело что это не плюсы в которых её 2 десятилетия пейсали (и которая точно так же как раньше не работает при изменении предкомпилированных или просто везде используемых заголовков), и пока по умолчанию она не включается.
#469 #1036282
>>1035947

>Я так-то под линуксом сижу и юзаю cmake/clang.


У тебя там цмейк сам собирать научился, без бэкэнда, поешавший?

>под линуксом


>clang


Вот с этого особо орнул. Ты там как, пользуешься сборками трехлетней давности, или сам собираешь? Я вот представляю уже, как ты после каждого релиза тащишь себе релизную ветку и билдишь ллвм со шлангом по 12 часов с ИНКРЕМЕНТАЛЬНОЙ компеляцией, и ору
#470 #1036538
>>1036282
Поцчему трехлетней давности?
мимо clang-5.0-господин под дебианом
#471 #1038409
Платиновый вопрос. Что за лафтаймы такие?
#472 #1038418
>>1038409
Платиновый ответ: доку открой.
#473 #1038496
>>1038418
Сложно.
#474 #1041667
>>977091
А как без системы управления пакетами? Это показатель современного языка. Без этого, это какой-то каменный век.
#475 #1041669
>>956909 (OP)

>как думаете, он сможет вытеснить жаву? Почему?



А нахрена? Rust он крут. Я не думаю, что нужно ставить вопрос именно так. Java все равно будет жить ещё долго, как и сраное php. Ведь его куча говнокода в Ынтерпрайзе. Ну и пусть варятся в собственном соку.
86 Кб, 326x413
#476 #1041813
>>1041669
Да, Rust ОСОБЕННЫЙ.

Как и ты, судя по тому, что и как пишешь.
#477 #1043540
Ананасы кто-нибудь работает над ии?
Стоит подучивать что-нибудь по этому параллельно с веб макакетством или все тщетно, если конкретно этим не занимаешься?
sage #478 #1043546
>>1041669
t.безработный студент
#479 #1043574
>>1043540
Все работают над ИИ.
#480 #1046993
1. ООП в расте не нужен
2. Он вытеснит не джаву, а C++
#481 #1046994
>>1046993
Но там ведь есть своеобразное ООП
#482 #1046996
>>1046994

> своеобразное ООП



Потому что это не ООП, люди подгоняют возможности Rust под тугое воображение ооп-ретрограда.
sage #483 #1047013
>>1046993
1) Нужен
2) Вытеснит разве что из своей щеки
#484 #1047113
>>1047013
Что ты подразумеваешь под ООП? Если первым словом в ответе на этот вопрос будет "наследование", то сразу иди нахуй.
#485 #1047541
>>1047113
Ну ты и лох, какое наследование, все знают что ООП - это когда можно методы через точечку вызывать и ИДЕ тебе автодополнение предлагает.
#486 #1047561
>>1047113
Абстрактную фабрику абстрактных фабрик энтерпрайз фасолин.
#487 #1047779
>>1047541
Ну вообще говоря так и есть. ООП это всего лишь паттерн управления стейтом, когда стейт лежит рядом с функциями для их обработки в одном контейнере, а программа состоит из кучи таких контейнеров.
#488 #1047829
>>1047779

> ООП это всего лишь паттерн управления стейтом


Нет, ООП и императивное программирование это ортогональные понятия.
#489 #1047855
>>1047829
Любишь смоллтолк?
#490 #1047896
>>1047829
Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?
#491 #1047909
>>1047855
Незнаком с ним. Да и моё утверждение верно для любого мейнстримного языка, будь то Java или C#.

>>1047896
Замени в своей фразе "стейт" на "данные" и получишь более-менее точное определение.
На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта.
#492 #1047972
>>1047909

> На практике это означает, что если у тебя в Java все поля - final, и ты присваиваешь их только в конструкторе, то это всё еще ООП, несмотря на отсутствие стейта



Я что-то тебя не понял.

Присваивание полей в конструкторе, используется как гарантия того чтобы не было полуготовых объектов, т.е. таких объектов, которые будучи инициализированными, не дают собой полноценно пользоваться. Стейт от этого вообще никуда не девается.

Мимопрохожий.
#493 #1048019
>>1047972
Иммутабельность.
#494 #1048030
>>1048019

ок, стейт ≠ иммутабельность, а ооп с фп имеют больше одной точки пересечения.
#495 #1048066
>>1047896

>Тогда что же такое ООП? И как оно соотносится с императивщиной и фп?


ООП это подход при котором отправитель сообщения и адресат никак несвязанны и независят друг от друга, а оба зависят от сообщения.
Суть в переносе связи между модулями на сообщения.
В c# это происходит через интерфейсы.
В с++ через абстрактные классы. (система типов плюсов/джавы превращают ООП в скотское безумие)
#496 #1048073
>>1047909
стейт === данные
1,5 Мб, 356x200
#497 #1048088
>>1048073

> стейт === данные

#498 #1048620
>>1047896
ООП - НЕ парадигма программирования. Парадигм программирования всего три. Подробнее здесь: http://wiki.c2.com/?ThereAreExactlyThreeParadigms.

То что подразумевают под ООП в современном мейнстримном виде (как в плюсах, джаве, питоне и т.д.) - не более чем тривиальная надстройка над старыми добрыми структурами, процедурами и указателями на процедуры. Об этом Вирт, Кей и другие говорили еще в 80-е, наверное.

ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки, и во многом именно о нем пишет небезызвестный Егор Бугаенко (http://www.yegor256.com/tag/oop.html) с чьими тезисами можно быть более или менее согласным, но как минимум познакомиться стоит. Можно сказать что такой подход это гуманитарщина, и быть при этом правым, но не нужно забывать что программы в первую очередь пишутся для людей, а значит способ их изложения и понимания имеет значение. Насколько легко представлять программу как множество объектов, взаимодействующих друг с другом - другой вопрос. Возможно другие способы эффективнее, возможно это вообще индивидуально.

По моему опыту ООП это способ структурирования именно императивных программ. Дело в том что я видел ОО-код на С, видел процедурный код на питоне с джавой, но никогда не видел ОО-ориентрованых програм на функциональных языках. Наверное это из-за того что объекты почти всегда инкапсулируют какое-то мутабельное состояние, иначе они превращаются просто в (параметризируемые) модули, а состояние в ФЯ обычно скрывается и обрабатывается не так, как и императивных.
#499 #1048624
>>1048620

Боб Мартин залогинься.
#500 #1049412
>>1048620

>ООП - определенный способ представления программы в голове, а следовательно и способ её структурирования в тексте. Именно его имел в виду Кей, в нем, как ни странно, суть Actor Model, а значит Эрланга и Акки



>>1048620

>но никогда не видел ОО-ориентрованых програм на функциональных языках



Определись наконец, Эрланг ООП или нет?
#501 #1049414
>>1048620
Всего 2, фунциональное и логическое это частный случай декларативного программирования.
#502 #1049417
>>1047779
Да хуйня какая-то, всё время прошу показать мне пример и объяснить почему это "ООП" а не сахар для процедурщины (я про вызов через точку). Вон в D можно обычные функции через точку вызывать, ну типа foo(a, b) и a.foo(b) - одно и то же. И шо, резко стало ООП? Да нет, нихуя. Вот объясните мне, где в вызове foo(a, b) стейт, а где не стейт. И почему оба аргумента не могут быть "стейтами".
#503 #1049419
>>1048620

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


Два чая этому господину
#504 #1049454
>>1049419
Рукалицо.
Как концепция, может быть надстройкой над синтаксисом конкретного языка?
#505 #1049480
>>1049454
Хватит разговаривать с голосами в голове. О каком "синтаксисе конкретного языка" ты говоришь?
#506 #1049526
>>1049417

> foo(a, b) и a.foo(b)


Полиморфизм.
#507 #1049542
>>1049526
что?
#508 #1049565
>>1049542
Во втором случае метод может быть переопределен.
#509 #1049606
>>1049565
Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме? Что ж, полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня). В расте есть куда более адекватный способ переопределения поведения - ad-hoc полиморфизм. Собственно говоря, он есть и в Haskell. Значит ли это, что программисты на Haskell постоянно используют ОО-подход?
#510 #1049616
>>1049606

> Ага, то есть всё-таки пришли к тому, что суть не в "записи с точкой" и тем что "данные лежат рядом с функциями", а в полиморфизме?


Суть ооп - полиморфизм, инкапсуляция, наследование.

> Что ж,


> ненужная хуйня (по той причине что


> ненужная хуйня)


Ясно.
#511 #1049638
>>1049616

>Суть ооп - полиморфизм, инкапсуляция, наследование.


Ну вот и получается, неследование не нужно, полиморфизм в классических ОО-языках опирается на наследование и потому не нужен.
Что касается инкапсуляции, то её можно рассматривать как сокрытие данных (такая трактовка описывается как неверная в русскоязычной и как одна из допустимых в англоязычной) - и тогда это довольно скучно, полно языков не поддерживающих сокрытие данных, но при это считающихся вполне пригодных для написания ОО-кода; или же можно трактовать инкапсуляцию как механизм "упаковывания" данных и кода, с ним работающего. Тогда опять-таки вопрос, во-первых, о чём речь идёт когда говорят об ОО-подходе в C (где ни наследования, ни полиморфизма, ни полноценной инкапсуляции); во-вторых, что делать с пресловутой проблемой бумаги и пера - paper.write(pen) или pen.write(paper)? Ну и в любом случае инкапсуляция (в смысле "упаковки") выглядит именно как незначительная надстройка над процедурщиной, сопровождающаяся как правило соответствующим сахарком.
#512 #1049689
>>1049412
Эрланг это язык программирования. Возможно это сложно понять, но язык и "парадигма" - не одно и то же. Если честно, я не знаю какую часть Эрланга занимают акторы, никогда с ним не работал. Но, например, тот код что я видел и писал на Акке (именно работу с акторами), функциональным назвать невозможно, а вот ОО - вполне.
>>1049414
Ты прочитай документ по ссылке, не ленись, ума наберись.
#513 #1050038
>>1049606

>полиморфизм подтипов - ненужная хуйня (по той причине что завязан на наследование, а наследование - ненужная хуйня).



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

> адекватный способ переопределения поведения - ad-hoc полиморфизм.



ad-hoc полиформизм - не true полиформизм. True - параметрический.

> почему это "ООП" а не сахар для процедурщины



Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.

> Значит ли это, что программисты на Haskell постоянно используют ОО-подход?



Это значит лишь то, что элементы ООП проникли в функциональщину, ОО языки несут в себе примесь функциональщины, при этом никто не считает их функциональными.

> что делать с пресловутой проблемой бумаги и пера



Доябываться до заказчика, пока не будет ясно какая система должна получится в итоге. Получив представление строишь наиболее очевидную (предсказуемую, скучную) систему.
#514 #1050047

> наследование - ненужная хуйня



Бтв, с этим не согласен. Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом. Только не надо пихать во все поля наследование. Это скальпель для построения иерархии типов, yj в жизни обычно хватает молотка в виде пары десятков заезженных паттернов.
#515 #1050670
>>1050038

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


Я и не говорил, что полиморфизм не нужен. Я лишь сказал, что тот полиморфизм, о котором обычно идёт речь в котексте ООП (т.е. полиморфизм подтипов) и который завязан на другой "столп" ООП - наследование - не нужен. Против ad-hoc и параметрического полиморфизма ничего не имею, даже наоборот, считаю что это очень нужные концепции. Только вот когда говорят о полиморфизме в контексте ООП обычно имеют ввиду не дженерики и не трейты/тайпклассы.

> ad-hoc полиформизм - не true полиформизм. True - параметрический.


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

> Потому что через сахар нельзя ввести инверсию flow of control, нужны новые определения, ООП - это и есть то определение.


Так, а вот это уже интересно. До сих пор в треде никто inversion of control не упоминал. В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.

>>1050047

>Наследование было ненужной хуйней из-за diamond inheritance; как проблему решили - стало годным инструментом.


И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?

> Это скальпель для построения иерархии типов


И зачем оно в реальной жизни может понадобиться? Точнее, в каких ситуациях оно может быть удобнее, чем подход того же Rust?
#516 #1050672
>>1050047
И да, diamon inheritance - не единственная проблема наследования. Другая проблема состоит в железобетонности иерархий типов, построенных наследовании, другими словами - в том что они очень плохо расширяемы.
#517 #1051235
>>1050670

> И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?



Взяли и выпилили множественное наследование, лол. Если мы говорим о java и его клонах типа c# <hidden_tags=trollface, sarcasm> :)</hidden_tags>.

> иерархии типов


> И зачем оно в реальной жизни может понадобиться?



Кейсы по liskov substitution principle: приходит множество объектов и нужно выбрать такие что гарантируют implementation интерфейсов родителя. При этом у каждого объекта есть свое уникальное поведение.

В реальной матрице это может быть игра-стратегия: пользователь выбирает ХуйПятьсот Unit'ов. Не снимая выделение, User нажимает ПКМ. Кавалеристы, пыхота начинают движение, реализовывая интерфейсы Human (Human < Unit). Выборка Human из Unit возможна из-за наличия иерархии типов, делая удобной фильтрацию ненужных выделенных инстансов, например инстансов Building (Building < Unit).

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



Я бы не сказал, что это проблема, это trade-off - выбор наиболее удобной реализации. Если класс предполагается расширять, то не надо наследоваться, давай воспользуемся Open/closed principle - это позволит избежать переписывания старого кода и заняться расширением.

> В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.



Именно так. На мой взгляд, разночтения происходят из-за двух вещей:

1. Маркетологи учат программистов как нужно жить. ООП - это не про объектно-ориентированного кота, но про менеджмент зависимостей (модулей) в программе.

2. Реализуются идеи ООП по-разному. Мы уже выяснили, даже в функциональных языках есть формы полиформизма, но эти языки прежде всего остаются функциональными. А еще мы любим поговорить об особенностях реализации ООП на своем языке, но это не то, что отличает ООП от модульного программирования.

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



Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
#517 #1051235
>>1050670

> И как же её решили (если мы всё-таки говорим про наследование реализации, а не наследование поведения через интерфейсы/трейты/тайпклассы)?



Взяли и выпилили множественное наследование, лол. Если мы говорим о java и его клонах типа c# <hidden_tags=trollface, sarcasm> :)</hidden_tags>.

> иерархии типов


> И зачем оно в реальной жизни может понадобиться?



Кейсы по liskov substitution principle: приходит множество объектов и нужно выбрать такие что гарантируют implementation интерфейсов родителя. При этом у каждого объекта есть свое уникальное поведение.

В реальной матрице это может быть игра-стратегия: пользователь выбирает ХуйПятьсот Unit'ов. Не снимая выделение, User нажимает ПКМ. Кавалеристы, пыхота начинают движение, реализовывая интерфейсы Human (Human < Unit). Выборка Human из Unit возможна из-за наличия иерархии типов, делая удобной фильтрацию ненужных выделенных инстансов, например инстансов Building (Building < Unit).

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



Я бы не сказал, что это проблема, это trade-off - выбор наиболее удобной реализации. Если класс предполагается расширять, то не надо наследоваться, давай воспользуемся Open/closed principle - это позволит избежать переписывания старого кода и заняться расширением.

> В таком случае, на мой взгляд, правильнее было бы, для ясности, не говорить об абстрактном ООП для которого у каждого своё определение (от "данные радом с функциями" и вызова через точку до обмена сообщениями между объектами), а использовать более чётко определённые термины - например, inversion of control. Тогда никаких разночтений не возникает.



Именно так. На мой взгляд, разночтения происходят из-за двух вещей:

1. Маркетологи учат программистов как нужно жить. ООП - это не про объектно-ориентированного кота, но про менеджмент зависимостей (модулей) в программе.

2. Реализуются идеи ООП по-разному. Мы уже выяснили, даже в функциональных языках есть формы полиформизма, но эти языки прежде всего остаются функциональными. А еще мы любим поговорить об особенностях реализации ООП на своем языке, но это не то, что отличает ООП от модульного программирования.

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



Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение. Впрочем, делать так скорее всего не надо. Излишние сложности с неочевидной выгодой.
#518 #1052018
>>1051235

> Взяли и выпилили множественное наследование, лол


Так отлично, а что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?

> Выборка Human из Unit возможна из-за наличия иерархии типов


Ну, всё то же самое можно сделать с помощью trait objects. Ну то есть принцип тот же, только без наследования реализации, только наследование поведения.

> Чисто технически это не так, параметрический полиформизм можно выродить в ad-hoc полиформизм, т.е. смотрим что за тип пришел и даем ему своё, уникальное поведение.


Ну для этого нужна поддержка рантайм-рефлексии, это хак)
#519 #1052064
>>1052018

> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?



Я непойму, ты хочешь чтобы я тебе википедию перерассказал, или что???

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 по той же самой причине.
#520 #1052142
>>1052064

>> что делать когда одиночным наследованием не обойтись, когда связи в системе сложнее?



Добавлю, в случая кода множественного наследования, вооще нет, то тогда класс расширяется через примеси, интерфейсы, и т.п.
#521 #1052159
>>1052142
Ну так я о том и говорю, что интерфейсами/трейтами/тайпклассами удобнее описывать связи в системе, так что наследование реализации не нужно.

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

> А если ты не растаман, и у тебя нет trait objects, тогда что?


Ну мне кроме сишки в голову не приходит языков без поддержки динамического диспатчинга. Никто не мешает сделать всё тоже самое на тех же Java и C#. Ну да, кое-где нет интерфейсов как отдельной сущности (в C++ например) и там придётся использовать "наследование" как механизм языка, но при этом по-хорошему все равно надо наследовать не реализацию, а только поведение (как это у крестовиков, pure virtual inheritance?).
#522 #1052198
>>1052159

> По-хорошему все равно надо наследовать не реализацию, а только поведение



А что делать с интерпретируемыми языками, опирающимися на duck typing, такими как ruby, в которых, в mixin'ах, реализация не отделяется от поведения?

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



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

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

---

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



Я с тобой согласен в том, что связи удобнее описывать не через наследование. С другой стороны, по Барбаре Лисков иерархия классов упрощает проверку наличия этих связей, и в этом и есть ценность наследования.
#523 #1055130
А вот и внезапный бамп растотреду!

Объясните мне, аноны:
https://github.com/sfackler/rust-postgres/blob/d374641ecb584bb668fa8e7a10d0f593a5c35ca2/src/io.rs#L24

Строки 29-36, почему в match не указаны неймспейсы? Почему не MaybeSslStream::SslStream? Там ведь нет use.
#524 #1055216
>>1055130
А нахуя ты смотришь какой-то коммит трёхлетней давности? Сейчас такое не скомпилируется.
#525 #1056011
>>1055216
Наткнулся на код и даже не заметил, что это древний коммит, лол.
#526 #1056839
То, что полиморфизм — один из столпов ООПа, еще не значит что сам полиморфизм имеет какое-то отношение к ООП. В функциональных языках полиморфизма таки больше.
Обновить тред
Двач.hk не отвечает.
Вы видите копию треда, сохраненную 7 сентября 2017 года.

Скачать тред: только с превью, с превью и прикрепленными файлами.
Второй вариант может долго скачиваться. Файлы будут только в живых или недавно утонувших тредах. Подробнее

Если вам полезен архив М.Двача, пожертвуйте на оплату сервера.
« /pr/В начало тредаВеб-версияНастройки
/a//b//mu//s//vg/Все доски