Rust vs C++

Кто-то писал на Rust? Стоит ли начинать учить? Насколько Rust хуже/лучше С++?

0

Сообщение от Fulcrum_013 Раст это вообще мертворожденная штука.

Сообщение от Fulcrum_013 Люди которые его лепят не понимают ни что хотят в итоге получить ни какие проблемы порешать.

Сообщение от Fulcrum_013 Все что не нетив в ближайшем будущем начнет вымирать огромными темпами.

Единственный вопрос:

Сообщение от Fulcrum_013 Пруф будет?

0

0

Сообщение от Fulcrum_013 Пруф будет?

Вы у меня спрашиваете? Так это же не я написал:

Сообщение от Fulcrum_013 Раст это вообще мертворожденная штука. Люди которые его лепят не понимают ни что хотят в итоге получить ни какие проблемы порешать.

Вот жду когда пруфы будут. Наверное, занимается непосредоственной разработкой Rust, раз такие речи толкает.

0

Сообщение от IamLost Наверное, занимается непосредоственной разработкой Rust, раз такие речи толкает

Хватило посмотреть одну из презентацию чтобы это понять. Вообще любой "убийца плюсов" - по определению мертворожден.
Реально похоронить плюсы сможет только такой же кардинальный ап плюсов которым, насколько кардинальным апом си были плюсы. Тока вот список того что требуется апнуть на сегодня на настолько кардинальный ап пока что не тянет, хотя и в очередной минорный досыпание сахару в синтаксис не уложится.

Добавлено через 1 минуту

Сообщение от IamLost архаичных технологий

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

Добавлено через 2 минуты

Сообщение от IamLost собранных по принципу "компота" не будет

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

0

Сообщение от Fulcrum_013 Архатчные технологии - это к примеру все что имеет GC.

У вас в голове такая классификация?

Сообщение от Fulcrum_013 Хватило посмотреть одну из презентацию чтобы это понять. Вообще любой "убийца плюсов" - по определению мертворожден.

Кто же его называет убийцей плюсов то? Я не уверен, но мне кажется, что разработчики раста его так никогда не позиционировали.

Сообщение от Fulcrum_013 Реально похоронить плюсы сможет только такой же кардинальный ап плюсов которым, насколько кардинальным апом си были плюсы.

Вы наверное не знаете, но кардинальный "ап" Си до плюсов уже лет 40 не может похоронить Си. Как писали так и пишут. Так что ваш пример - бессмысленен.

0

Сообщение от IamLost Как писали так и пишут

Ну не перевелись еще быдлокодеры в земле пиндосской. Там свои заморочки. Си фортран и ява - национальная гордость западного пиндостана. Теперя к ним еще шарп затесался. А плюсы и все остальные универсальные ООП языки - это европейцы.
При этом в энтерпрайзе легаси которое еще до плюсов родилось там тоже овердохрена и его не просто поддерживают но и расширяют.
Тут показательней другой факт - Керниган то и Ритчи во всю за плюсы всегда топили. Причем не просто топили, а исходником препроцессора для того чтобы первый транспиллер быстрее слепился со Страуструпом поделились.
Хотя бы потому что практически все на С еще в 70-х было на ООП парадигме, только без прямой поддержки принципов SOLID ядром языка - все это вручную костылить приходилось. Кстати то же самое касается и фортрана в 70-х.

Добавлено через 6 минут

Сообщение от IamLost У вас в голове такая классификация?

Это факт. GC для управления ресурсами и как следствие для ООП никакой автоматики не дает в принципе. Поэтому его и выбросили из всех ООП языков которые европейцы проектировали. Они это знали на примере симулы которая в европейских универах была ограничено распросстранена.
Гослинг который этих граблей не знал поймал их с истинно американским размахом. Хотя как можно было проектируя ООП язык не знать что делают GC абсолютно ненужным именно правила поведения взаимосвязей принятые в ООП малопонятно.
Ну при том что к примеру то же ФП которое там во всю че то протирает про римские цифры, но семимильными шагами движется таки в сторону ООП, то альтернативы ООП не будет в принципе.

Добавлено через 5 минут

Сообщение от IamLost Кто же его называет убийцей плюсов то?

Да это на всех заборах написано. Ну и презентацию их какую не посмотри - там все по принципу вот типа в плюсах такая вот охриненно проблема а мы ее такие молодцы вот так вот порешали.

0

Сообщение от Fulcrum_013 Да это на всех заборах написано.

Сильная аргументация. Прям реальным профессионалом своего дело повеяло.
У меня перед домом на асфальте кто-то написал вот эти строки:

И да, за интерпретацией будущее, кто бы что не говорил. В мире будущего никаких С++ и других архаичных технологий, собранных по принципу "компота" не будет.

Думаю не будем с этим спорить, примем как факт.

Сообщение от Fulcrum_013 Это факт.

О, да? Ну тогда то, что у меня перед домом на асфальте написано тоже будем считать фактом. Так победим.

Сообщение от Fulcrum_013 Ну не перевелись еще быдлокодеры в земле пиндосской.

Ох и тупые... Не то, что бывшие сотрудники украинских заводов про производству пластиковых бутылок, которые Rust(у) приписывают задачи, которые перед ним даже его разработчики не ставили.

0

Сообщение от IamLost О, да? Ну тогда то, что у меня перед домом на асфальте написано тоже будем считать фактом. Так победим.

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

Добавлено через 2 часа 17 минут

Сообщение от IamLost Ох и тупые...

Прямо как Гослинг. Так вседа бывает когда пытаются решать проблемы которые не существуют. К примеру ненужным GC делают именно правила взаимосвязей ООП а не что то другое. С ООП у них все как то слишком грустно. Поэтому о какой либо вменяемой автоматике можно забыть напрочь. Так что...

0

Fulcrum_013, а к Rust-то у вас какие претензии? У него нет GC, у него нет интерпретации, он точно так же как C++ компилируется в нативный код, использует аппаратный стек и т.д.

0

Сообщение от ablex а к Rust-то у вас какие претензии?

У него ко всем объектам этого мира одна претензия: этот объект не является С++.

0

Сообщение от ablex а к Rust-то у вас какие претензии?

Ну первое что в глаза бросается - наследования нет. Дальше можно не продолжать. Ребятки которые его лепят даже не пытаются ООП рассматривать аки оптимизацию модели акторов для частного случая нахождения оных акторов в одном процессе/адресном пространстве. Отсюда и поверхностный взгляд на вопрос аки инкапсуляция - наследование - полиморфизм, и какие то непонятные телодвижения в сторону чем то заменить. Результатом будет эпический фейл однозначно. Как понял из их писулек которые докой еще сложно назвать механизм замены - аггрегация с оборачиванием. Фейл будет в результате эпический как и у всех отказунов от наследования. содержит != является.

Добавлено через 11 минут
ablex, Т.е. создатели раста идут путем бездумного следования модным трендам неосилятов-евангелистов, а не формального доказательства целостности концепции, соответствия той или иной формальной модели и т.д. используемой в той или иной методологии проектирования и и.п. А языки так не делаются. Они либо делаются под методологию проектирования либо получается прокисший компот. Раст уже во всю смахивает на второе.

0

Сообщение от IamLost У него ко всем объектам этого мира одна претензия: этот объект не является С++.

Кстати так о птичках объектная модель у плюсов точно та же что у жабы, шарпа, Дельфы и т.д. только полноценная, а не обрезанная.
Вообще помнишь года три назад во всю хайпы были по поводу Entity System vs ООП а потом с этой ES все как то вдруг сдулись? А знаешь почему здулись? С одной стороны им доходчиво (настолько что даже они своим куцым умишкм в конце концов поняли) объяснили что оная ES - ни что иное как извращенный до полной неюзабельности паттерн "композит" и оное извращение давно известно ака "смалталковская модель объектов", коя в свою очередь есть ничто иное как кастрированная по самые небалуй симуловская модель объектов. А с другой полезли проблемы вызванные оным извращением, а именно то что нулевая связность между ентитями живущими в одном объекте явно недостаочна (именно по причине нулевой а не минимально достаточной связности это и есть извращение), а организация связности через задний проход существенно (до 1000x) бъет по производительности.
От тоже самое будет с любыми отказунами от наследования и т.д. неосилянтами базовых концепций, которые пытаются типа "улучшить" то что не понимают.

0

Сообщение от Fulcrum_013 Ну первое что в глаза бросается - наследования нет. Дальше можно не продолжать

Не особо знаком с rust, но знаю, что там есть traits, которые можно реализовывать для типов; т.е., как по мне, по сути это интерфейсы. Их можно использовать как для статической (a-la концепты в С++), так и для динамической дисперетчизации.
Наследования реализации нет, это да, но есть мнение, что оно не нужно)

0

ablex,
ну вот читайте что пишут:

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

Т.е. ориентируются на безграмотного неквалифицированного программиста, который бездумно юзает наследование только для типа переиспользования кода (по факту - пошлая процедурщина со словом class а не ООП), без четкого разделения зон ответственности сущностей, как предписывает методология, что оные риски исключает от слова совсем.
Т.е. делают они по большому счету не язык для профессионалов, а очередное средство подтирания задницы для быдлокодеров. Но как известно болезнь под названием недопонимание задачи не способен выличить никакой компилятор.

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

Добавлено через 6 минут

Сообщение от gray_fox Наследования реализации нет, это да, но есть мнение, что оно не нужно

Все подобные мнения - это не более чем хайп евангелистов которым до жути хочется попиарится и не более того.

Сообщение от gray_fox так и для динамической дисперетчизации

Ну вот только есть один момент - ни одно из этих костылей не решает проблемы с отношением "является".
При этом еще раз - средство избежания всех этих "ужасных проблем" - четкое разделение зон ответсвенности между сущностями. И это разделение есть ядро ООП методологии проектирования, ради которого собственно говоря все деление на сущности и затевалось. Если ориентироваться на мнение тех кто даже базовые принципы ООП не осилил, то о чем там может идти речь вообще? ООП это инструмент инженера и для непосвященных оно по определению смертельно.

0

Сообщение от Fulcrum_013 Ну вот только есть один момент - ни одно из этих костылей не решает проблемы с отношением "является".

Почему нет? Если тип реализует интерфейс (явно или нет, в rust или нет, не важно), разве это не является именно этим отношением между типом и интерфейсом? Какие там синтаксические конструкции для этого используются не важно.

Сообщение от Fulcrum_013 Все подобные мнения - это не более чем хайп евангелистов которым до жути хочнтся попиарится и не более того.

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

0

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

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

Добавлено через 4 минуты

Сообщение от gray_fox Тем не менее, такое наследование легко заменяется композицией и реализацией интерфейса (разве что писать буковок надо будет больше).

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

Добавлено через 5 минут
При этом ну ладно еще плюсы которые может быть обернутые вызова заинлайнят и композицию умеют статическую. Представьте себе к какому жопсу в плане производительности это приведет в манаджед?

0

Сообщение от Fulcrum_013 Не надо смотреть на наследование как на механизм переиспользования кода.

Так ведь отличие наследования реализации от реализации интерфейса (класса с одними лишь чисто виртуальными функциями в С++) как раз в дополнительном переиспользовании кода предка, разве нет?

Добавлено через 6 минут

Сообщение от Fulcrum_013 Представьте себе к какому жопсу в плане производительности это приведет в манаджед?

Понятия не имею, но тема вроде про С++ и rust.

0

Сообщение от gray_fox Так ведь отличие наследования реализации от реализации интерфейса (класса с одними лишь чисто виртуальными функциями в С++) как раз в дополнительном переиспользовании кода предка, разве нет?

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

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

Добавлено через 9 минут
gray_fox, НУ и в первую очередь средство разделения по вертикали на изолированные механизмы. Т.е. в общем то какой то механизм взаимодействия заприватили и никто в него больше не может вмешаться. Особенно актуально когда это механизм взаимодействия между двумя разными классами. Т.е. не все что промеж собой предки творят потомкам знать положено - детям до 16 как говорится. А с интерфейсами как и даже с фасадом вместо наследования?

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

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

Добавлено через 1 минуту
А получается оно так потому что что не возьми в ООП то и дает какие то свои архитектурные возможности. Поставь вместо него костыль - и возможности эти тю-тю.

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

Добавлено через 56 минут

Сообщение от gray_fox ак ведь отличие наследования реализации от реализации интерфейса

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

0

Сообщение от gray_fox Понятия не имею, но тема вроде про С++ и rust.

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

0

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

Добавлено через 3 минуты
IamLost, Еще раз - пробовать нужно быдлокодерам. Инженерам достаточно белго просмотреть мануал чтобы понять основные достоинства и недостатки того или иного языка. Касательно манаджед - достоинств нет, все недостатки Симулы на лицо.

Добавлено через 8 минут
gray_fox, Да кстати насчет производительности такого костыля вместо наследования. Декоратор любой виртуальный вызов превращает в пару вложенных виртуальных. Так что поимеем от этого вложение виртуальных вызовов на всю глубину иерархии, даже там где пользуется метод самого верхнего. Т.е прощай производительность от слова совсем.
При наследовании же вызов даже виртуального метода предка из метода потомка диспетчеризируется статически а значит может вообще инлайнится - т.е. любой виртуальный вызов остается просто виртуальным вызовом.
При этом проблему с является декоратор не решает - т.е. вместо предка потомка использовать нельзя. Во всяком случае без утиной типизации.

Добавлено через 1 час 30 минут

Сообщение от IamLost Да ему главное - написать.

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

0