Языку программирования Rust исполнилось 10 лет

что не так

Да всё так, просто иные считают цпп эталоном мощного и выразительного языка, вот и всё.

раньше умру чем дойдут руки пробовать Раст, т.к. Плюсы более чем устраивают и нравятся, а времени под всё не хватает

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

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

до(включая во время) Python'а чё у пациента(коллеги) в анамнезе - какие языки ; оси ; «эвЭмЭ»

т.е если Питон первый язык то rust отличное направление

если же Питон после ..... то хм хм уж лучше elm\erlang\gleam да даже с/c++/zig

ибо у rust аура хуже pl/i ( :--| )

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

Или просто впустую угробишь своё время....

Да много чего, в том числе жабоскрипт и цпп, просто конкретно к нам он попал как питонщик.

Вот это вряд ли.

заменил слово на букву Ха более литературным вариантом

что пилит гугл на замену плюсам?

Carbon

для полноты

что в ржавчине особо любо (коллеге)?!

время не зависит от того чем ты его заёмёшь

Понял. Отвечаю на ваш вопрос: MSVC + MSSQL. Причем у заказчика по MSVC ни одного программиста, MSSQL - на объектах для которых писался софт отсутствует от слова совсем, все остальные ИС на этих объектах с которыми в том числе очень плотная интеграция у разрабатываемой системы робили на firebird. Т.е. полная инородность для конторы. А всё произошло из-за того, что одному в принципе хорошему человеку и хорошему специалисту в своей области, дали порулить тем в чём он хоть и разбирается, но разбирается весьма поверхностно.

100%

время не зависит от того чем ты его заёмёшь

«И чО??» ©

Не о физике речь... О предложении «профукать"своё личное время своей личной жизни на какую-то, лично тебе не нужную, хрень ради сомнительной и не очевидной перспективы „вырасти как профессионал“...

считают цпп эталоном мощного и выразительного языка, вот и всё

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

   // ....
   foo(b); // Ошибка компиляции
   foo(static_cast<A&>(b)); // Всё в порядке
   // ....

Мощно и выразительно? Вполне!

откуда априорная уверенность в упущенной повидле?

опыт только из узбеков?!

Нет, узбек, опыт не только из тебя и твоей любимой «повидлы».

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

Определим «нормальное ООП» как ООП на обобщённых функциях. Тогда у нас есть один язык с нормальным ООП. И вы его знаете.

хоть я и Дубровский но ведь ты не маша что бы обижать узбеков повидло!

Ява? Это же ява? Ведь ява же?

По существу есть что сказать?.. Пустобольство твоё мне не интересно...

Определим «нормальное ООП» как ООП на обобщённых функциях.

ОО - это «обьектно ориентрованное». то есть представление программы как набора обьектов. причем тут а «обобщенные функции»?

причем тут а «обобщенные функции»?

При том, что они делают ООП нормальным, полноценным и развитым, а не калечными костылями на замыканиях-переростках.

Почти. Дальний родственник. Через Гая Стиля породнились.

эти что ли?

https://ru.wikipedia.org/wiki/%D0%9E%D0%B1%D0%BE%D0%B1%D1%89%D1%91%D0%BD%D0%BD%D0%B0%D1%8F_%D1%84%D1%83%D0%BD%D0%BA%D1%86%D0%B8%D1%8F

Ну ты еще черепа начни этим ООП измерять для оценки полноценности.

Вы почти угадали. Но не совсем: https://en.wikipedia.org/wiki/Generic_function

Заметьте! Не я это предложил!

держи в курсе - жаль что ты не можешь не желаешь по существу и сей диалог для тебя nil

Как это один? Тут Обобщённое программирование их немного больше чем один указано. Чатгопота вообще с козырей зашла - рассказала про шаблоны C++ :D

При том, что они делают ООП нормальным, полноценным и развитым, а не калечными костылями на замыканиях-переростках.

Вы забыли добавить, что это в вашей палате так считают. А что доктор говорит? Это вот «нормальное и полноценное» ООП сейчас с нами в одной комнате да?

Вы почти угадали. Но не совсем: https://en.wikipedia.org/wiki/Generic_function

И все равно больше чем один язык на такое способен. Посмотрите в сторону Objective-C - там можно посылать сообщения вообще неизвестно кому, даже nil. Объекты и их свойства на лету в рантайм можно собирать.

Мимо. Всё мимо.

Посмотрите в сторону Objective-C - там можно посылать сообщения вообще неизвестно кому

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

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

При чем тут ООП?

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

А всё произошло из-за того, что одному в принципе хорошему человеку и хорошему специалисту в своей области, дали порулить тем в чём он хоть и разбирается, но разбирается весьма поверхностно.

Le classic. Проект без архитектора. Периодически вижу драмы вида «Ну, мы решили делать все на ЯП-name и его стеке потому что наша команда разработчиков знает только его. Обезъян, подскажи что теперь делать?».

И вы его знаете.

Две скобки этому регистранту.

Отсюда видно, что всё, что может ООП на сообщениях, может и ООП на обобщённых функциях.

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

откуда априорная уверенность в упущенной повидле?

От того, что «проба нового языка» только ради пробы это пустая трата времени. Ну попробовали вы... и через 5 минут забыли о нём, т.е. вы потратили своё время впустую.

забавно как постфактум артикулируются априорные посылки

и это несколько меняет объём первично огульности

и так в с е г д а

жаль что тривиум исключён из общеобра

Хотите стагнировать → не имею ни права, ни намерения вам это запрещать.

Ну, мы решили делать все на ЯП-name и его стеке потому что наша команда разработчиков знает только его.

Знакомая тема. И оно бывает как хорошо, потому что альтернативы это «теже сбоку», так и плохо, когда инструменты не подходят по тем или иным причинам. Мой пример это как раз вариант когда инструменты не подходят по всем причинам. И если в части девелоперов это ещё не такая уж большая проблема, изучат и MSVC, то в части отсутствия MSSQL это уже попадание на бабки в виде закупок лицензий.

Дядь, вы трезвый?

Вы историю явы знаете? Это вот совсем не про неё.

Да я в принципе до сих пор не понимаю разницы между «правильным» и «неправильным» ООП, если честно. Мне и в луа и в раст хватает «ООП». Отлично все оформляется в объект и используется. Удобно, просто.

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

он на лако-красочном предприятии банки закупоривает.

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

то есть не будет в одной области видимости функций(методов) с одним именем, у которых два разных списка параметров, по типу.

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

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

Самурай без меча подобен самураю с мечом, но только без меча.