Rust vs C++

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

0

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

1

Сообщение от Fulcrum_013 ТУда уже концепты и наследование подвезли?

А ты без ООП дер*ма, как я вижу, жить не можешь)

0

Сообщение от IamLost Что изменится в 2021?

Год начнётся с новогодних каникул, самое время начать изучать новый язык.

1

Сообщение от Curry Год начнётся с новогодних каникул, самое время начать изучать новый язык.

На новогодних каникулах нужно новогодничать и каникулить, а не С++ изучать)

0

Сообщение от Usaga На новогодних каникулах нужно новогодничать и каникулить

Попеременно, я же так и нарисовал.

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

Сообщение от Fulcrum_013 ТУда уже концепты ... подвезли?

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

0

Сообщение от Curry идея проверять наличие у подставляемого типа конкретных методов, вместо проверки принадлежности его к трейту (или интерфейсу) порочна

Почему?

0

Мне тоже интересно. На самом деле довольно удобно было бы оперировать типами у которых, скажем, есть свойство ID и не важно в одной они иерархии или нет.

0

Сообщение от korvin_ Почему?

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

Сообщение от Usaga На самом деле довольно удобно было бы оперировать типами у которых, скажем, есть свойство ID и не важно в одной они иерархии или нет.

Архинеправильно мыслите, товарищ!
ID - это просто ID - имя такое, и разные люди могут вложить в него разный смысл. А вам же нужно не просто a ID, а совершенно конкретный the ID, который должен быть описан в классе/интерфейсе/трейте и его то и указывать в качестве ограничения типа.

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

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

Сообщение от Curry и не важно в одной они иерархии или нет.

Если наследование только от одной сущности, то плохо. Но даже в C# интерфейсы же есть. И если вы хотите пользоваться в обобщённой функции ID-ом, то вы подразумеваете у этого ID-а определённые возможности, которые и следует отразить в трейте/интерфейсе ... И, тогда можно пользоваться типами из разной иерархии, но, всё же поддерживающих такой ID, который вам нужен.

0

Сообщение от Curry А в rust обобщённые типы и так типизируются трейтами.

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

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

Сообщение от Curry Потому что тип с которым мы собираемся работать должен быть, допустим, итерируемым, или сериализируемым,

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

0

Сообщение от Fulcrum_013 Т.е. у раста и шаблонов то нет оказывается а под видом них дженерики?

У rust нет ключевого слова template. Эти плюсовые template и есть разновидность дженериков.
Или объясните как вы понимаете разницу.

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

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

0

Сообщение от Curry У rust нет ключевого слова template. Эти плюсовые template и есть разновидность дженериков. Или объясните как вы понимаете разницу.

У шаблонов утиная типизация и adhock полиморфизм. Дженерики же не более чем обертка над void*.

Сообщение от Curry На плюсах можно иметь класс реализующий нужный нам функционал, а все типы с кем мы будем работать должны быть производными И от этого класса

Это касается исключительно динамического полиморфизма. Механизм же шаблонов дает статический ad-hoc полиморфизм. А для него нужна как раз утиная типизация.

0

Сообщение от Curry Архинеправильно мыслите, товарищ! ID - это просто ID - имя такое, и разные люди могут вложить в него разный смысл. А вам же нужно не просто a ID, а совершенно конкретный the ID, который должен быть описан в классе/интерфейсе/трейте и его то и указывать в качестве ограничения типа.

Так никто разным людям не запретит вкладывать разный смысл в одно и то же свойство одного и того же класса. Один посмотрит на ID как на уникальный идентификатор, а второй запишет туда количество товара на складе. Тут класс\интерфейс\трейт ничего не изменит. А так, утиная типизация во всей красе. У "сущности" должно быть ID. Если есть ID, значит это сущность. Этот подход на ура работает в TypeScript. И это то, чего мне иногда не хватает в C#. А оказывается, что это архинеправильно...

0

Сообщение от Usaga И это то, чего мне иногда не хватает в C#

Я вот вам искренне поражаюсь - и того вам не хватает в шарпе и того, а так за него грудью на амбразуру бросаетесь. А в плюсах это все есть.

0

Fulcrum_013, я очень рад, что в плюсах есть что-то, чего нет в шарпе. Но практичности языка это особо не умаляет. В плюсах тоже нет некоторых вещей, которые есть в шарпе (и в некоторых других языках), которые мне очень полезны. И что дальше?

0

Сообщение от Curry Не должен, это плохой дизайн.

Пример - шаблон Property поражден от аргумента шаблона (назовем это Store)выполняющего хранение/установку/возврат данных.
при наличии у Store метода Set класс Property должен иметь все мутабельные операторы которые подходят для хранимого типа.
При наличии у Store метода Change эти мутабельные операторы должны работать уже по другому.
При наличии методов Inc и Dec уже совсем по третьему.
при отсутствии же медов установки/чтения но наличии статических констант соответсвующим именем он дожен вызвать указанные в этих константах методы содержащего класса. Для Get и Set при этом должен определить а эти константы вообще адреса методов или адреса полей и для полей в операторах осуществить непосредственно установку/чтение полей.
Т.е. другими словами - осуществить полную подстройку под тот тип который передан в качестве аргумента.
И эта подстройка как раз осуществляется условным включением/выключением через концепты операторов/выбором варианта работы оператора через constexpr if
По другому будет действительно очень плохой дизайн, заставляющий и вариантов BaseStore написать под все сочитания нужных вариантов и помнить от какого Base породить конкретный стор и такую же простыню вариантов Property и точно так же вручную следить чтобы BaseStore совпало с оборачивающим вариантом Property

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

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

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

0

Сообщение от Fulcrum_013 Например? GC? Его выбросили сознательно в виду абсолютной бесполезности. Свойств? На самом деле их нет в шарпе.

А вам не пофигу?

0

Сообщение от Usaga А вам не пофигу?

Ну вы же говорите что в плюсах чего то нет что есть в шарпе. Интересно чего же кроме того что абсолютно неюзабельно?

Сообщение от Usaga Но практичности языка это особо не умаляет

Окромя того что напрочь лишает его какой либо годной для ООП автоматики и подстройки кода к другому коду

0

Сообщение от Fulcrum_013 У шаблонов утиная типизация

Что, по моему мнению абсолютное зло. Не хотите на js покодить?

Сообщение от Fulcrum_013 Дженерики же не более чем обертка над void*.

А это абсурд.

Сообщение от Usaga Так никто разным людям не запретит вкладывать разный смысл в одно и то же свойство одного и того же класса.

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

Сообщение от Fulcrum_013 И эта подстройка как раз осуществляется условным включением/выключением через концепты операторов/выбором варианта работы оператора через constexpr if По другому будет действительно очень плохой дизайн, заставляющий и вариантов BaseStore написать под все сочитания нужных вариантов

Так у вас и так получается туча вариантов под все constexpr if.
Странно что вы стали ратовать за дизайн прямо противоположный ООП. Введение корневой сущности реализующий требуемые функции (в ООП методы), это и есть описание алгебры над сущностями. А утиная типизация в духе сишных макросов, там тоже можно сочинять выражения с функциями, и какие варианты этих функций потом окажутся видимым в месте применения макроса, такие и использовать. И объектов не надо. Зашибись дизайн.

0

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

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

В Java SWT есть много виджетов, которые имеют метод getText, но они не реализуют какой-нибудь интерфейс HasText { getText() }, что делать в таком случае? Допустим, реализовали бы, какой-то свой, а в Swing — свой. Формально — разные интерфейсы, фактически — один. Как их вместе использовать? Писать свои обёртки/имплементации трейтов на каждый класс? Так себе занятие. А если ещё и для корректной имплементации нужен доступ к приватным полям?

Сообщение от Curry Набор функций может совпасть для другого типа где функции с тем же именем будут иметь другой смысл.

А могут иметь тот же смысл. Как тогда поступать? Предложишь авторам всех библиотек, которые ты используешь в своём проекте, имплементировать твои интерфейсы/трейты? Или сам будешь писать кучу обёрток/псевдоимплементаций?

Добавлено через 48 секунд

Сообщение от Curry Эти плюсовые template и есть разновидность дженериков.

Нет. Совсем нет.

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

Сообщение от Curry Кроме того, если механизм работы с обобщёным типом поменяют, допустим, для выполнения такого же действия понадобиться ещё функция, то придётся и в концепты вносить изменения, лишняя зависимость.

А если трейт/интерфейс поменяют, то его имплементациям не придётся менять свой код? Точно так же придётся, в чём разница?

0

Сообщение от Curry Так у вас и так получается туча вариантов под все constexpr if. Странно что вы стали ратовать за дизайн прямо противоположный ООП. Введение корневой сущности реализующий требуемые функции (в ООП методы), это и есть описание алгебры над сущностями. А утиная типизация в духе сишных макросов, там тоже можно сочинять выражения с функциями, и какие варианты этих функций потом окажутся видимым в месте применения макроса, такие и использовать. И объектов не надо. Зашибись дизайн.

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

Добавлено через 6 минут
т.е. иерархия получается базовое хранилище(которое занимается исключительно обеспечением доступа к значению) - кастомизируемое поведение (определяет как осуществялть ту или иную операцию чтения/записи) - натянутые по верху операторы.
Суть ее как раз в том чтобы не переписывать для типа каждого свойства которое по сути является полем содержащего класса, всю простыню операторов, а сделать только несколько функций которые дают именно логику установки и чтения значения, а вся простыня подходящих как к обертываемуму типу значения так и указанному набору геттеров/сеттеров шаблон сгенерировал автоматически, и при этом этот сгенерированный набор был бы известен в компайлтайме.

0