https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo

мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.
Все же работа с памятью создает большую когнитивную нагрузку.
Возможно после этого можно переехать проще на ziglang. Он в чем то похож.
и к тому же позволяет интегрироваться с си(++).
но раст реально просто. не так ли?

Rust для элиты. С++ для середнячков. С для хардварщиков.

Здравствуйте, Разраб, Вы писали:

Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.

В первую очередь для программистов высокого уровня, с большим опытом C++.
Потому что они реально понимают все те проблемы, которые решает "borrow checker",
только явное преобразование типов (привет integer promotion), трейты Send/Sync,
нормальный менеджер пакетов, явная обработка ошибок и т.п. и т.д.

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

Р>Все же работа с памятью создает большую когнитивную нагрузку.
Р>Возможно после этого можно переехать проще на ziglang. Он в чем то похож.

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

Р>но раст реально просто. не так ли?

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

Здравствуйте, Zhendos, Вы писали:

Z>В первую очередь для программистов высокого уровня, с большим опытом C++.
Z>Потому что они реально понимают все те проблемы, которые решает "borrow checker",
Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.

Z>И имея большой опыт C++ такой человек может рассказать почему на примерах все эти фишки хороши
Скорее почему для этого нафиг не надо городить отдельный язык.

Здравствуйте, Zhendos, Вы писали:

Z>Здравствуйте, Разраб, Вы писали:

Z>только явное преобразование типов (привет integer promotion)

Что не так с integer promotion? Миллион try_convert_to на каждый чих не улучшают читаемость кода

Здравствуйте, CreatorCray, Вы писали:


CC>Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.

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

Здравствуйте, Разраб, Вы писали:

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

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
    if a.len() < b.len() { a } else { b }
}

Здравствуйте, rudzuk, Вы писали:

R>Я думаю, это прекрасный язык, с замечательным синтаксисом.

R>

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
R>    if a.len() < b.len() { a } else { b }
R>}

Не аргумент. Прочитав за 5 мин. вводную по аннотациям — вопросов не возникнет.

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

Здравствуйте, Shmj, Вы писали:

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

Работай, кто тебе мешает

Здравствуйте, rudzuk, Вы писали:

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

А деньги кто за это платить будет?

R>

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
R>    if a.len() < b.len() { a } else { b }
R>}

Пара недель практики — и синтаксис станет привычным и даже красивым.

>и не слишком усложнить написание логики

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

Здравствуйте, reversecode, Вы писали:

>>и не слишком усложнить написание логики

R>переводя с раста на плюсы
R>объем кода сокращается в два раза

и много ты с раста на плюсы перевел?

перевожу ли я мегатонны кода каждый день ? нет

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

Здравствуйте, reversecode, Вы писали:

R>перевожу ли я мегатонны кода каждый день ? нет

я попросил указать конкретное значение, а не пространные размышления про то что "это и так понятно"

Здравствуйте, T4r4sB, Вы писали:

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

Что именно ты тут называешь "измененип итерируемого контейнера"?

Здравствуйте, Разраб, Вы писали:

Р>https://youtu.be/AH4V4M7R88k?si=LKVfBKaqx9NXXiPo
Р>мне кажется rust хорошо для программистов среднего уровня, не владеющих C++.

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

Посмотрел видео и выделил некоторые моменты о которых говорит докладчик.

1. После Python, PHP, JavaScript мозги атрофируются. У тебя теряется ясность ума. (2:00)
2. Почитайте хорошие книги по математике, они написаны простым человеческим языком. И вспомните чему нас учили в институте. Конспекты, конспекты, толстые конспекты, бред. (2:50)
3. В программировании мы видим слишком много подходов, очень много философии. Процедурные, объектные, функциональные языки, скриптинг. (4:15)
4. Машина Тьюринга универсальный вычислитель. Это бензопила, которой можно отпилить себе части тела. Можно писать программы и всё будет работать, но проблема в том, что мы забываем, то что мы написали. (5:35)
5. Мы думаем, что мы гомо сапиенс (человек разумный), а на самом деле у нас проблемы с памятью. (6:53)
6. Вычитывайте свой код. Я вычитываю свой код три раза. А бывают люди вычитывают два раза. А бывают ни разу не вычитывают. (7:15)
...

С моей точки зрения он решает вот эту проблему.
Систематизация личной базы знаний по программированию в Zim

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

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

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

Для решения всяких проблем я завёл тему. Создание опытного функционала.

1. Например, всё программирование на английском, но не просто на английском, на английском, на котором думал программист, когда он это писал. Нет однозначных терминов, вы можете каждое понятие описать по-разному. Может быть это будет не скоро, может быть никогда, а может и скоро, но я собираюсь решить эту проблему с помощью LayerEditor. Это сотрёт грань между разговорными языками, только порядок будет иметь значения, а не то, что там написано в лексемах.

2. Или вот хотелось бы функционал как Расширенная Форма Бэкуса—Наура. Ведь докладчик он не инопланетянин, я столкнулся с такими же проблемами. Я хочу, чтобы можно написать какую-то форму в графическом виде для архитектуры, и потом просто её заполнять. В идеале ещё распознавать архитектуры в произвольном коде, чтобы из разного кода с помощью автоматического сравнения получать шаблоны РБНФ. Но именно в графическом виде, типа древовидных списков как для дурачка.

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

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

Жизнь программиста на каждом языке программирования важна. Не надо унижать фреймворки или мелкие библиотеки алгоритмов. Из любого мусора можно извлечь полезные знания или хотя бы мусор. Просто у программиста не будет такого волшебства, что он взял тот же Rust и такой раз, и стал из нубо джуна каким-нибудь сеньором помидором, причём в любой области программирования. Это всё сказки от маркетологов.

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

Обезьяна vs человека
https://www.youtube.com/watch?v=cPiDHXtM0VA

Здравствуйте, rudzuk, Вы писали:

R>Я думаю, это прекрасный язык, с замечательным синтаксисом.

R>

fn longest<'a>(a: &'a str, b: &'a str) -> &'a str {
R>    if a.len() < b.len() { a } else { b }
R>}

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

Здравствуйте, CreatorCray, Вы писали:

CC>Не, как раз С++ники с большим опытом понимают что тот геморрой, что создаёт ржавый подход, совершенно неоправдан ради решения проблемы, которая перед опытными С++никами и не стоИт вовсе.

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

Здравствуйте, CreatorCray, Вы писали:

CC>Что именно ты тут называешь "измененип итерируемого контейнера"?
Видимо речь о случаях, когда в процессе итерации по контейнеру в него добавляются или убираются элементы, что приводит к инвалидации итераторов, пропуску элементов или бесконечному росту. У меня такая проблема встречается при "быстром кодировании", когда, например, каждому элементу контейнера вызывается виртуальная функция, внутри которой может быть что угодно, например, удаление себя или добавление собратьев. При аккуратном подходе к архитектуре таких проблем почти не бывает.