LINUX.ORG.RU

Немного новостей из мира Rust

 


1

4

Последние новости из мира Rust вкратце:

  1. Вышла новая стабильная версия Rust 1.74.0.
  2. Сформирована новая команда по работе над официальной спецификацией языка Rust и представлено их видение.
  3. Ferrocene (набор инструментов компилятора Rust для критически важных сред и систем безопасности) прошёл сертификацию и теперь официально соответствует требованиям ISO 26262 и IEC 61508 и полностью пригоден для использования в средах, критически важных для безопасности.
  4. Доступно видео с конференции EuroRust 2023.
  5. Microsoft вкладывает 10 миллионов долларов, чтобы сделать Rust языком 1-го класса в своих инженерных системах.

Перемещено maxcom из talks

★★★★★

Ответ на: комментарий от AntonyRF

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

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

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 2)
Ответ на: комментарий от AntonyRF

за исключением полиморфизма, в расте нужно прям точно указывать от куда метод вызывается - из условного типажа А или из типажа Б

Не понял, а это-то как противоречит полиморфизму? Или речь о том, что нет утиной типизации как в цпп?

unC0Rr ★★★★★
()
Ответ на: комментарий от AntonyRF

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

а что за проблемы с «наследованием» в классических OOП гуях??? там их просто нет. потому эти гуи и есть.

глубина наследования вообще не играет никакой роли, да будь она хоть 100. более того, чем эта глубина больше, тем вам пришлось писать меньше ручками.

не, ну если хочется немного больше «шевелить ручками» в гуях на несколько сот классов, написав их с нуля на всяких рустах и голангах - то флаг у руки. хотелось бы увидеть результат.

большее шевеление ручками имеет большой минус, кроме самого шевеления - такой код сложно модифицировать.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от thesis

Нормальные разрабы не ноют, а пишут код.

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

AntonyRF ★★★★
()
Ответ на: комментарий от rtxtxtrx

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

Тем не менее ты не привел аргументов, что с ООП все хорошо =)

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

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

во-первых, спорно, что можно красиво и компактно.

во-вторых, «если оно крякает, то оно - утка». то есть, если вы сделали «как в опп», без ооп, то это и есть ооп, только корявое.

alysnix ★★★
()
Ответ на: комментарий от alex1101

Раскрой что ты понимаешь под ООП, мамкин программист. Знаю я таких, обкурятся этими своими GoFами, а потом:

Ехал визитор через фактори,

Видит визитор, в фактори листенер.

Сунул визитер листенер в декоратор,

StackOverflowExeption цап.

anonymous
()
Ответ на: комментарий от bread

Рад за вас. Но ООП только ради полиморфизма и нужно.

И в чем проблема?! На ООП мир сошелся и ничего больше не существует?! =)

Если вернуться к расту, в котором нет ООП похожего на С++, то там есть статическая\динамическая диспетчеризация, мощные generic’и и enum’ы. Конечно, зависит от задачи, но у меня есть ощущение, что то как люди в 90% случаев используют полиморфизм, можно заменить просто Enum’ами в расте.

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

Тогда почему твой ООП обсирают все кому не лень?))

А есть что-то, что не обсирают?

но все они НЕВЕРНО реализовали ООП

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

тут как раз Microsoft решила вложиться в раст и сделать его языком №1 в своей шарашкиной конторе

С каких пор микрософт стал индикатором правильности решений?

Там то дядьки наверное лучше умеют сравнивать языки чем мужики с лора с непонятными достижениями =)

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

alex1101
()
Ответ на: комментарий от alysnix

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

rtxtxtrx ★★
()
Ответ на: комментарий от AntonyRF

На ООП мир сошелся и ничего больше не существует?!

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

alex1101
()
Ответ на: комментарий от AntonyRF

Тогда почему твой ООП обсирают все кому не лень?))

Люди и обсирают, и обсираются. Это обычное явление. Плюсы от раст-а в этом моменте не отличаются. Найдутся адепты и одного, и другого.

Холивар (ООП vs недоООП, Наследование vs Композиция) не стоит потраченных на него душевных сил.

pathfinder ★★★★
()
Ответ на: комментарий от unC0Rr

Не понял, а это-то как противоречит полиморфизму? Или речь о том, что нет утиной типизации как в цпп?

Я на плюсах писал чуток и что такое утиная типизация не знаю. НО, по-научному это тоже полиморфизм, но тут часто разрабы отказываются в это верить =)

AntonyRF ★★★★
()
Ответ на: комментарий от anonymous

Ехал визитор через фактори, Видит визитор, в фактори листенер.

это не ооп. это некие архитектурные принципы поверх ооп. придумай свои.

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

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

alysnix ★★★
()
Ответ на: комментарий от anonymous

Ну это джавопараша типичная. Такое можно созерцать только в C#, Java и… внезапно PHP. Я вообще никогда не задумывался какой паттерн и где мне применить, ну, наверное, потому что подходы применяемые в джаве не нужны в питоне, js, ruby и тд

rtxtxtrx ★★
()
Ответ на: комментарий от alysnix

глубина наследования вообще не играет никакой роли, да будь она хоть 100.

Вообще-то играет и достаточно сильно:

  • Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)
  • Нарушение принципов SOLID ведущих к повышенной связанности
  • Проблема ослабления инкапсуляции
  • Проблемы с тестированием
  • Сопровождение (вытекает из сильной связанности)

Ну собственно, это тоже самое что и случилось с ADA

В общем и целом, я хотел сказать что есть другие механизмы, которые отличны от того к чему ты привык. И далеко не факт что меньше кода всегда получается на С++, разве что в определенных сценариях. Можешь сам почитать критику ООП, особенно для С++, сравнить самостоятельно подходы\принцыпы разработки на расте и С++.

А так же, советую изучить вопрос глубже, я серьезно и без стеба и троллинга. Я не смогу тут выкинуть кучу примеров, процетировать кучу книг, чтобы выиграть интернет срач, а вот ты можешь самостоятельно для себя почитать статьи\книжки и поднять свой уровень знаний. Может даже ты потом останешься при своем мнении, а может что-то новое для себя узнаешь.

AntonyRF ★★★★
()
Ответ на: комментарий от AntonyRF

Тогда почему твой ООП обсирают все кому не лень?))

Либо ниасилили, либо попытались впихнуть туда, где не следует. Либо и то, и другое сразу (одно может запросто быть следствием другого).

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

А вот отсутствие оного выдавать за преимущество… Может вы еще и книги на старославянском при лучине читаете?

eao197 ★★★★★
()
Ответ на: комментарий от eao197

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

AntonyRF ★★★★
()
Ответ на: комментарий от eao197

лучше, чем не иметь: когда нужен – используешь, когда не нужен – не используешь

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

unC0Rr ★★★★★
()
Ответ на: комментарий от AntonyRF

А я про Rust особо и не пишу. Я пишу про ту чушь, которую тут на C++ пытаются навесить.

Ну и да, когда я смотрел на Rust, то не увидел там полноценного ООП в духе ООП для статически-типизированных языков (т.е. вся триада «наследование»/«инкапсуляция»/«полиморфизм», да еще статически проверяемая компилятором в компайл-тайм). Может что-то, конечно, поменялось, но сильно сомневаюсь.

eao197 ★★★★★
()
Ответ на: комментарий от rtxtxtrx

Я вообще никогда не задумывался какой паттерн и где мне применить, ну, наверное, потому что подходы применяемые в джаве не нужны в питоне, js, ruby и тд

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

bread
()
Ответ на: комментарий от unC0Rr

Ну вот в D стандарта нет, но там хочешь использовать ООП – используешь. Не хочешь – не используешь.

Тогда как в Eiffel или Java не хочешь использовать ООП и… И используешь ООП.

Про стандарт C++ – это отдельная песТня. Но судя по стартовому сообщению этой темы, Rust-оманы хотят нажить себе такие же приключения :)

eao197 ★★★★★
()
Ответ на: комментарий от AntonyRF

публикуется в научные журналы

Какие научные журналы? КАКИЕ В ЖОПУ НАУЧНЫЕ ЖУРНАЛЫ?
Наука - это, например, физика, и вот там чувак, который публикуется в журналах, потом разрабатывает графен, новые способы изготовления процов и крутейшие допустим светодиоды. И потом у нас везде солнечные батареи, обогреватели, дешевейшие быстрые холодные процы и огромные мониторы с отличной картинкой какого-нибудь невообразимо далекого космоса.
А эта вся сраная срань с «языками программирования» чем может похвастаться, покажи, пожалуйста, пальцем? «Утилизацией вычислительных мощностей»? «Быстрым выходом на рынок»? «Пологой кривой обучения хвостатых»? Сиреневыми волосами?

Лиспу их любимому вон лет 60 уже, просто напоминаю для полноты вброса.

thesis ★★★★★
()
Последнее исправление: thesis (всего исправлений: 3)
Ответ на: комментарий от bread

Паттерны в джаве - это как костыли, потому как в ней везде классы, ты просто не можешь объявить где-нибудь в глобальной области видимости функцию или переменную… нет множественного наследования. Лень расписывать. Гофовские паттерны нах не нужны. Просто какой-нибудь EventEmitter заменяет и PubSub и Observer. Не нужны фабрики так как ты можешь просто сам класс как аргумент передавать, не нужны билдеры и тп. Есть специфические какие-то вещи типа декораторов, а итераторы - часть языка. Просто для общего развития прочитал и забыл

rtxtxtrx ★★
()
Ответ на: комментарий от rtxtxtrx

Ну это джавопараша типичная.

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

bread
()
Ответ на: комментарий от bread

А теперь представь джавопарашу, но без средств ООП.

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

rtxtxtrx ★★
()
Ответ на: комментарий от AntonyRF

Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)

это вообще не проблема. верней, это проблема не ооп, если она существует. приведите примеры.

Нарушение принципов SOLID ведущих к повышенной связанности

как раз solid без ооп не реализовать. SOLID это целиком про ооп. а уж на C++ это делается легко. гуглим «SOLID С++»

Проблема ослабления инкапсуляции

не проблема. в с++ вы можете инкапсулировать как угодно.

Проблемы с тестированием

какого рода.

Сопровождение (вытекает из сильной связанности)

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

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

alysnix ★★★
()
Ответ на: комментарий от AntonyRF

Проблема хрупкости базовых классов (изменения в базовых классах ломают наследников)

А божечки, изменение фундамента ломает здание. Надо срочно всё переизобрести, а то как же так.

thesis ★★★★★
()
Ответ на: комментарий от eao197

Ferrocene, наверное хотели бы иметь базовую спецификацию, от которой отталкиваться, а не писать своё.

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

Dark_SavanT ★★★★★
()
Ответ на: комментарий от Dark_SavanT

Челики из ferrous уже свою успели сделать :))

Что-то мне кажется если бы они не сделали эту спеку то официальная команда бы не начала шевелится вообще в этом направлении. А то сейчас у них появился риск что спека от ferrous станет основной спекой и решили предотвратить такое)

pftBest ★★★★
()
Ответ на: комментарий от pftBest

посмотри видос сравнения полиморфизма между rust и с++

Посмотрел. У автора видоса специфическое восприятие термина «полиморфизм». Несколько ограниченное, как по мне.

В частности, вот такую схему его полиморфизм не подразумевает (если я правильно помню особенности traits в Rust-е):

class subscriber {
  virtual void cleanup() = 0;
public:
  virtual void subscribe() = 0;
  ...
};
...
class my_basic_subscriber : public subscriber {
  void subscribe() override {
    cleanup();
    some_actions();
  }
  ...
};
...
class specific_subscriber : public my_basic_subscriber {
  void cleanup() override { ... };

  void subscribe() override {
    my_basic_subscriber::subscribe(); // Тут будет вызван cleanup из specific_subscriber.
    additional_actions();
  }
  ...
};
eao197 ★★★★★
()
Ответ на: комментарий от eao197

Ну самое простое решение это не использовать такой паттерн потому что он нарушает инкапсуляцию :) Человек который писал класс my_basic_subscriber расчитывал что вызовет его метод cleanup а будет вызван совершенно другой метод который непонятно что сделает и может нарушить инварианты оригинального класса (например если дочерний cleanup не вызовет родительский cleanup). Или наоборот минимальные изменения в реализацию базового класса (например если мы уберем вызов cleanup в методе subscribe) могут поломать далекого наследника который в своей логике расчитывал что subscribe всегда вызовет cleanup. Это уже прямо явное нарушение инкапсуляции потому что приватная реализация базового класса не должна никак ломать сторонний код. Смотри википедию Fragile base class

Например в языке Kotlin который проектировали люди умнее меня и с большим опытом в ООП все классы по умолчанию final чтобы отказаться от этого патерна.

pftBest ★★★★
()
Ответ на: комментарий от eao197

Я бы за такое на ревью поругал, но тут уже написали почему.

В частности, вот такую схему его полиморфизм не подразумевает (если я правильно помню особенности traits в Rust-е):

Неа, прям так не напишешь, но оно и к лучшему. Полиморфизм в расте не реализуется средствами наследования, в расте используются Типажи и Дженерики для этого, ну и композиция конечно. Т.е. твой код можно представить так:

trait Subscriber {
    fn subscribe(&self) {
        println!("Хотя ты можешь иметь и общий код")
    }
}

struct MyBasicSubscriber;
struct SpecificSubscriber {
    basic_subscriber: MyBasicSubscriber,
}

impl Subscriber for MyBasicSubscriber {
    fn subscribe(&self) {
        println!("subscribed MyBasicSubscriber");
    }
}

impl Subscriber for SpecificSubscriber {
    fn subscribe(&self) {
        self.basic_subscriber.subscribe();
        println!("subscribed SpecificSubscriber");
    }
}

fn generic_subscribe<T: Subscriber>(t: T) {
    t.subscribe();
}

fn main() {
    let a = MyBasicSubscriber {};
    let b = SpecificSubscriber {
        basic_subscriber: MyBasicSubscriber {},
    };

    generic_subscribe(a);
    generic_subscribe(b);
}

AntonyRF ★★★★
()
Ответ на: комментарий от pftBest

вызов предкового метода, ничем не отличается от вызова функции из какого-то неймспейса.

и будут применимы ровно те же «возражения», что мол если кто-то испортит эту функцию так, как вы не ожидали, то у вас сломается ваш код. конечно сломается, только тут ооп вовсе не причем.

и нет тут никакого «нарушения инапсуляции», все нормально инкапсулировано, просто инкапсулированное поведение внешней функции нарушило некий контракт.

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

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alysnix

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

В случае когда мы пишем по нормальному через интерфейсы то контрактом является интерфейс. И этот интерфейс дает нам какие-то гарантии поведения для всех классов которые реализуют или используют этот интерфес.

А в случае когда мы разрешаем переопределять методы класса то контрактом является любая последовательность вызовов всех виртуальных методов этого класса. Как я уже приводил в пример что если убрать вызов cleanup из тела метода subscribe класса my_basic_subscriber то сломается класс specific_subscriber. Где описан этот контракт что метод subscribe обязан вызвать cleanup внутри? разве что в коментарии сверху или в документации на класс. Но это ведь внутренняя деталь реализации, почему это вдруг контрактом стало? Надо ли на все вызовы виртуальных функций писать контракт кто их будет вызывать и когда? Почему бы вместо этого не сделать отдельный интерфейс и описать контракт на него, а детали реалиции класса оставить скрытыми.

pftBest ★★★★
()
Ответ на: комментарий от pftBest

В случае когда мы пишем по нормальному через интерфейсы то контрактом является интерфейс. И этот интерфейс дает нам какие-то гарантии поведения для всех классов которые реализуют или используют этот интерфес.

то есть в русте имя метода является контрактом, а в с++ - нет??? имя функции не есть контракт. в примерах про «хрупкие классы» оно не меняется.

Где описан этот контракт что метод subscribe обязан вызвать cleanup внутри?

у вас в рустовом коде где записан хоть какой-то контракт на семантику? таких контрактов нет ни в с++, ни в русте. заголовок функции строго говоря им не является и вообще разговор о другом.

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

alysnix ★★★
()
Ответ на: комментарий от pftBest

наследование в с++ это штука семантически похожая на импорт модуля(в языке с модулями). наследуя класс, вы получаете доступ к его неприватным методам, и можете ими пользоваться. все какашки, что могут тут получиться, равно получатся и в импорте модулей в модуль.

то есть. пора или поднимать ор о хрупких модулях, и заканчивать этот цирк с «хрупкими классами»

alysnix ★★★
()
Последнее исправление: alysnix (всего исправлений: 1)
Ответ на: комментарий от alex1101

Предложи альтернативу ООП для большого и сложного софта. Костылить недоООП самому, как гномеры?

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

Virtuos86 ★★★★★
()