Rust vs C++

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

0

0

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

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

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

Сообщение от COKPOWEHEU а дизайнер - только скрипты

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

Сообщение от COKPOWEHEU Обоснования будут или как обычно?

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

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

Сообщение от COKPOWEHEU Прочитать аргументацию и опровергнуть ее не получилось, поэтому решили повторить свое высказывание,

Да нет у тебя никакой аргументации. В принципе нету. Есть непонимание элементарных основ специальности.

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

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

Сообщение от COKPOWEHEU Вот к чему здесь JIT вообще?

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

1

0

0

Сообщение от locm Вы реально считаете что IDE бесполезны при обучении и непременно начинать нужно с make?

Нет, я так не считаю и не утверждаю. Я утверждаю что крайне полезно знать низкий уровень - как именно IDE вызывает компилятор и с какими флагами. Самый простой способ для этого - make. А уж чем пользоваться в повседневной жизни - личное дело каждого.

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

И еще раз: на Питоне у них это получается, на более низкоуровневых языках - нет. Даже если забыть про причину, у нас есть хотя бы факт.

Сообщение от Fulcrum_013 Если дизайнер пишет логику - то все сливай воду это алес приплыли.

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

Сообщение от Fulcrum_013 Да элементарные основания - нету во всей этой шелл-шняге классического для софта триумверата ввод-процесс-вывод.

Как это нет? Куда делись?

Сообщение от Fulcrum_013 Да нет у тебя никакой аргументации. В принципе нету. Есть непонимание элементарных основ специальности.

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

Сообщение от Fulcrum_013 Человек же в любом случае будет концентрироваться на локальных оптимизациях

А теперь перечитайте ту часть моего поста, с которой вы начали отвечать. Напомню:

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

0

Сообщение от COKPOWEHEU А теперь перечитайте ту часть моего поста, с которой вы начали отвечать. Напомню:

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

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

Сообщение от COKPOWEHEU В реальности же это совершенно обычная, более того, необходимая ситуация. И к каким-то кошмарным последствиям "почему-то" не приводит.

В реальности это во первых полный бред. А в главных полный фейл. Дизайнер не имеет для этого необходимых знаний. Вообще работа дизайнера - это наполнение данными датапака, а никак не разработка кода игровых механик.

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

Сообщение от COKPOWEHEU И еще раз: на Питоне у них это получается, на более низкоуровневых языках - нет. Даже если забыть про причину, у нас есть хотя бы факт.

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

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

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

0

Сообщение от Fulcrum_013 GC помеха любому реалтайму особенно в вопросах управления оборудованием. По определению реалтайма и по определению отказоустойчивых систем.

Я все-таки попытаюсь объяснить так, чтобы было понятно.

Включаем два прерывания по таймеру.
Первое - высокоуровневое - на него вешаем цикл управления.
Второе - низкоуровневое - на него вешаем GC.

В такой схеме GC никак не может помешать основному циклу.

0

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

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

Сообщение от vantfiles В такой схеме GC никак не может помешать основному циклу.

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

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

Сообщение от COKPOWEHEU Как это нет? Куда делись?

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

0

0

0

Какие еще перезагрузки? Это вам не винды.
Если я говорю - десятилетиями, это означает именно оно.

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

0

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

Сообщение от vantfiles И даже в голову не может придти, что может быть иначе, правда?

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

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

Сообщение от vantfiles Да, по учебнику.

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

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

Сообщение от vantfiles А вам видимо в вузе это вот все изложили

В АСУТП очень долго напоминали. Да кстати обесточивание машзала запитанного от двух линий одна из которых от собственной ТЭЦ там единственная причина перезапуска софта. В том числе и софта моей разработки.

0

То есть такой фактор как удобство и скорость разработки (разумеется при гарантии отсутствия отказов) вы игнорируете.
Еще хочу упрекнуть в неспортивных приемах дискуссии. 100Вт вы заметили, а 60КВт игнорировали. Зачем-то ссылаетесь на в/о... Я АСУ-шник по этому самому в/о.

Вашу позицию понял. Дальнейший диспут считаю контрконструктивным.

0

Сообщение от vantfiles Зачем-то ссылаетесь на в/о... Я АСУ-шник по этому самому в/о.

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

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

Сообщение от vantfiles а 60КВт игнорировали.

Разница не бльшая. Особенно если это насосы/вентиляторы. Примерно такими делами как понимаю управляете? Ну это банально вангую на основании разброса мощности приводов.

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

Сообщение от vantfiles То есть такой фактор как удобство и скорость разработки

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

Сообщение от vantfiles разумеется при гарантии отсутствия отказов

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

0

аминь

0

Сообщение от vantfiles аминь

Да будет так (перевод с латыни)

0

Сообщение от Fulcrum_013 При наличии динамического перераспределения, мусоросборника, JIT и прочих прелестей явы

Это никогда не закончится...

Я не использую яву. На яве свет клином не сошелся. Но JIT и динамическую память - вполне.

0

Сообщение от vantfiles Я не использую яву. На яве свет клином не сошелся. Но JIT и динамическую память - вполне.

Да какая разница - ява шарп и т.п. - это все та же Симула-67 с досыпанным сахарком. Главное - что все эти JIT GC и т.д. анахронизмы - и полностью морально устарело по состоянию на 1967-ой год и диверсия в плане реалтайму.

Сообщение от vantfiles Это никогда не закончится...

Ну а не надо пытаться лезть за пределы вашей зоны компетентности, а тем более что то подрасказать в этом плане, я же вам не пытаюсь рассказывать как каскады регуляторов строить. Задача специалистов АСУ - определение характеристик объекта управления и построение схем непосредственной регуляции приводов - т.е. другими словами мозжечка и нервов системы управления. А построение "мозга" системы - это таки задача программистов. Еще в 90-х из всех кафедр АСУТПиП выделии кафедры ВТиПМ именно потому что подготовить специалистов способных делать и то и другое не удастся - слишком разнонаправленная подготовка нужна особенно в плане математики.
То что у вас там было что то про программирование больше чем у остальных непрограммистов - то только для того чтобы могли с программистами на одном языке разговаривать, точно так же как у нас ТАУ было именно для этого. Т.е. если смотредь даже по должностным инструкциям отделов АСУТП ваше в/о банально не дает вам допуска к разработке софта реального времени, точно так же как мое в/о не дает мне допуска к проектированию систем непосредственной регуляции приводов и т.д.

0

В 2020 году уже всем очевидно, что С++ устарел и не может предложить ничего для решения задач, которые стоят перед программистами будущего. Rust пока лучшая попытка решить проблему бесполезности С++ в настоящем и будущем. Будущее за интерпретируемыми языками, а не древним мусором, созданном 40 лет назад.

0

Сообщение от IamLost то С++ устарел и не может предложить ничего для решения задач, которые стоят перед программистами будущего.

Пруф будет?

Сообщение от IamLost Rust пока лучшая попытка решить проблему бесполезности С++ в настоящем и будущем.

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

Сообщение от IamLost Будущее за интерпретируемыми языками, а не древним мусором, созданном 40 лет назад.

Все что не нетив в ближайшем будущем начнет вымирать огромными темпами. Во первых оно не имеет современной кастомизируемой автоматики управления жизненным циклом, а соответсвенно ничем в плане управления ресурсами и взаимосвязями не отличается от языков 60-х . В главных - закон Мура давно перестал выполняться как для отдельно взятого ядра ( прирост производительности ядра за 8 лет не превысил 70%) так и для отдельно взятого процессора. При этом предел количества ядер, на которые имеет смысл распараллеливать, для подавляющего большинства задач давно превышен. Закон же Гейтса выполняется неукоснительно - тормознутость софта в следствие криворукости быдлоскриптеров удваивается каждые полтора года, а то и ежегодно.
Абсолютно очевидно что такими темпами одно из двух - или индустрия впадет в полный ступор, или полностью изживет неквалифицированных разрабов вместе с быдлоскриптами, которые как в пригодности к созданию высокоуровневых абстракций, так и в плане удобства разработки и скорости отладки, так и в плане производительности ниже днища.

0