И вот, по тем же данным Anandtech, нейромодулятор в Google Tensor, просто уничтожает всех. Например, в области обработки естественного языка, превосходство над конкурентами трехкратное. И это разница в несколько поколений.
А если верить этим ребятам, то превосходство всё еще вплоть до трехкратного, но уже в другую сторону. А вот например цитата из сравнения anandtech:
"...it’s to be noted that the workloads on the Tensor run via NNAPI, while other phones are optimised to run through the respective chip vendor’s libraries, such as Qualcomm’s SNPE, Samsung’s EDEN, or MediaTek’s Neuron – unfortunately only the Apple variant is lacking CoreML acceleration, thus we should expect lower scores on the A15".
То есть даже сравнивать tensor с A15 рановато. Мало того, в среднем по больнице tensor уступает и snapdragon 888. По мне так основная фича пикселя - отсутствие вендорских поделий. Ну и камера хороша.
Тоже самое и с процессорами, очень редко бывает когда нагружается какой-то отдельный вычислительный блок, например, только одно мощное ядро.
Поэтому реальный тест на прочность процессора происходит когда одновременно происходят вычисления совершенно разного типа, и соответственно нагрузка идет на всю систему на кристалле, а не только на CPU или GPU. Это и называется гетерогенными вычислениями.
а вот это - откровенная манипуляция. По факту приложения работают настолько быстро, насколько они упираются в боттлнек производительности на каком-то виде нагрузок, и ускорение других компонентов обычно не дает сколь угодно значимого прироста. Наглядные примеры отлично видны например на сравнении разных CPU в играх - пока боттлнек в GPU, разница в пределах 1% FPS.
В общем, автор в очередной раз продеманстрировал столь искусное жонглирование фактами, на которое не решился даже вендор. Браво!
К сожалению или к счастью panic-safety всё же требуется от любой корректной библиотеки
а компилятор этого требует? В смысле "скомпилирует ли код, не удовлетворяющий panic safety"? Так или иначе, тривиальность мува сильно упрощает задачу (а точнее, отсутствие необходимости поддерживать исключение/панику при муве).
А преимущество Rust в том, что для каждой unsafe функции в её документации есть раздел "Safety" и требования там простые и ясные.
так речь же не об использовании unsafe функций, а о написании unsafe кода. Там с гарантиями всё намного хитрее, и стандарта, по которому можно было бы перепроверить код, попросту не существует.
но в основном всё-таки при выяснении что в Rust UB, а что нет ты удивляешься, когда узнаёшь, что что-то не является UB, а в плюсах, к сожалению, наоборот.
это всё круто, учитывая что состав UB rust зависит от llvm, поведение миддленда которого по большей части определяется стандартом плюсов...
И не за счет ли отсутствия стандарта как такового у Rust-а?
ну раст не умеет ни в исключения, ни в нетривиальный мув, поэтому логика контейнера очень сильно упрощается. А еще в расте считается, что всё что safe и скомпилилось не содержит UB. Правда, для реализации полноценного буфера понадобится unsafe, а там гарантий практически нет...
Заметьте, я всегда, во всех этих тредах в первую очередь ругаюсь на фрактальную непознаваемость языка, на уймы UB, и так далее
на UB ругаются все. Просто одни ругаются на то, что у них нет рантайм проверок на каждом шагу, а другие бесятся что компилятор делает какие-то там предположения когда они весьма вальяжно работают с памятью.
а не на то, что, условно, find_if неюзабельный, потому что там надо создавать отдельный объект (причём вне функции, function-local class не может быть аргументом шаблона до C++11, как мы все, конечно, помним) или обмазываться динозаврами из std::bind1st какими-нибудь
ну конкретно с find_if вроде либо использовали функцию, а-ля find_if(.., isspace), либо писали циклом.
Ну, один проект (личный), увы, на кутях со всеми вытекающими с наследованием от QObject и управлением памятью через голый new и иерархии
ну так new только для QObject иерархии и нужен, с передачей владения, т.е. просто так удалить не забудешь...
Все кодовые базы, с которыми я работал до 11, спокойно юзали boost::shared_ptr и не парились
то у нас торговый бот, которому лишняя микросекунда вечность, то пофиг на рефкаунтинг... Хех.
При этом это добавляет интересных вещей в язык. Например, объяснять, почему плохо делать T getFoo() { T foo; ...; return std::move(foo); } мне приходилось.
блин вы сравните последствия move вместо copy elision с одной стороны и выбором между копированием и выделением в куче с передачей по указателю с другой...
Треды, мьютексы и локи де-факто были всегда
не всегда переносимые
Folding expressions, constexpr, етц? По моим грубым прикидкам большинство программистов на C++ этим всем не пользуется, и вполне оправданно.
ну как, редко, но доводится, и как раз эти штуки сокращают код весьма мощно, а зачастую еще и время компиляции.
Spaceship? Опять недоделка — вместо рефлексии для описания произвольных функций выкатили это (и, кстати, тоже с весёлыми подводными камнями)
не "вместо" ведь... Просто пока рефлексия не готова, а потребность существует. А этот подводный камень не имеет отношения к spaceship, там разница именно в симметричности операторов в с++20+. Что кстати тоже сокращает код. Могли бы мб сделать явный квалификатор для этого, но их уже и так много...
Я боюсь, что рефлексии будет недостаточно по куче разных причин
ну для задач типа "сериализуй эту структуру с политикой по умолчанию" более чем хватит.
Мне не понравилось, слишком много надо держать в голове в сравнении с другими языками, типа с#, жава, котлин, питон.
на жаве/котлине не писал, а вот на питоне довелось, и там надо держать в голове больше, чем в плюсах. Как минимум - типы переменных/аргументов. Да, вроде как не беспокоишься о лайфтаймах, но почти любая опечатка ловится только в рантайме. Спасибо, я лучше на плюсах буду писать, нервы дороже.
вы, наверное, не очень давно работаете, извините
что-то около 6-7 лет, наверно не очень давно, да. За выслугу лет еще не награждали.
непредвиденные отказы есть всегда, как только программа попадает в б-м массовые руки пользователей
а если я бекенд разрабатываю, то кто есть пользователь? А если ошибки бывают, но в большинстве чисто логические, которые были бы допущены и в других языках?
забавно, меня обвиняли в фанатизме и AMD, и intel, и apple, и NVIDIA... И из этой четверки у меня есть акции трех компаний, кроме как раз intel. Такой фанат синих, ага
Сравнивая топовые десктопы становится понятно что к чему как раз.
вы пытаетесь оценить энергопотребление в разных режимах работы даже для десктопных процов. Залочьте процы на одинаковых частотах и сравните техпроцесс по перф/ватт.
Опять фанатские передергивания. Речь идет про реальные замеры. 240 против 140 это реально замеренные во время бенчмарков.
Да что вы говорите. То-то последний топовый интел жрет 240 ватт, там где топовый амд жрет 140.
а вас не смущает что вы сами завели речь про ноутбуки, и теперь приводите в пример десктопные процы? Я говорил про условные 5800U vs 1185G7, где ноуты на AMD сильно троттлятся при питании от батареи чтобы дольше держать заряд. Не забывайте пожалуйста, что сравнивая характеристики процов вы иногда сравниваете их в разных режимах работы
Далее конкретно про десктопные процы. Топовый 5950X жрет до 165 Вт, 12900K до 240 Вт, то есть примерно на 40% больше энергии. Вот только он в таком режиме и выдает, в зависимости от теста, на 20-30% больше перфа, что в силу нелинейности перфа от энергопотребления вполне укладывается в сравнимую энергоэффективность.
Я бы сказал, что для систем охлаждения, рассчитанных на эти процессоры, отвести что 140, что 240 ватт тепла особой проблемы не составит
мне кажется вы немного переоцениваете системы охлаждения. Слабые воздушные кулеры обычно расчитаны на отведение 100W, топовые рассеивают порядка 180W от консьюмерского чипа (200+ для серверных процов, т.к. там отводится с большей площади). Т.е. с 5950X справится даже не самая крупная воздушка. А вот чтобы отвести 240W с i9 понадобится 360mm AIO в хорошо проветриваемом корпусе, и он будет работать на пределе.
Забавное наблюдение: из-за падения спроса на топовые intel в пользу AMD, 360mm AIO подешевели раза в полтора-два относительно пары лет назад.
А то, что интелу удалось (без оглядки на ваттаж) уместить в 8 ядер производительность 16 — это впечатляет.
в 16 ядер же, 8P+8E. То, что восемь из них названы "efficiency", не значит, что ими можно пренебречь. Да, у них ниже частоты на 1.2 ГГц, но из-за нелинейной зависимости перфа от частот разница с большим ядром - процентов 10-15. Полагаю, даже эти E-cores молотят на уровне ryzen'овских.
Нет, конечно. Но это пример, призванный иллюстрировать, чем непредсказанные во время разработки, но пойманные во время выполнения ошибки лучше непойманных.
Но так как мы таки их обсуждаем, то этот частный случай как-то тут не к месту рассматривать, ИМХО.
Вы как-то очень избирательно решаете рассматривать или не рассматривать частные случаи. Начинает даже казаться, что критерием является поддержка аргументом вашей точки зрения. Но давайте всё-таки попробуем провести объективную ревизию того, что мы можем игнорировать, а что - нет.
Вот вы описали все ужасы порчи памяти, а я продемонстрировал, как некорректная обработка ошибки может усугубить её последствия. Это гипотетические worst case scenario, основанные на предположениях о конкретном поведении конкретного кода. В целом можно игнорировать, верно?
Далее, вы утверждали диагностируемые ошибки строго лучше UB. С этим я не спорю. Но вы так же утверждали что это улучшает надежность системы, с чем я не согласен по тому определению надежности, которое я привел выше. Почему это частный случай и его не имеет смысл рассматривать?
Если язык позволяет вам выразить рефкаунт, то это уже не язык с одними лишь иммутабельными объектами, только и всего.
Я ж говорю не про язык, а про компилятор/рантайм. Рефкаунт может служить лишь как оптимизация копирования, применимая для всех иммутабельных объектов. Но я всё еще не понимаю к чему это всё. Изначально я утверждал, что в функциональных языках более строгие контракты и можно добиться более строгих гарантий. Если вы пытаетесь спорить с этим утверждением, то я не могу понять как ваши аргументы его опровергают.
так как вы можете судить об ошибках, если ни на чем, кроме плюсов не пишете?
давайте еще раз. Вот вы в комментах к теме, посвященной си и с++, утверждаете, что понимаете состояние дел с++, на котором вы не писали лет 20, лучше, чем человек, который только на них и пишет, аргументируя это тем, что вышеупомянутый не пишет на других языках? Всех эпитетов моего лексикона не хватит для описания абсурдности этого утверждения.
Неужели мои аргументы так похожи на стандартное олдфаговское нытьё из C++98 или 03?
да, слово в слово. Ну или на нытьё студентов, которые хотят учиться программировать по питону вместо с++...
От 50 до 800 kLOC.
странно ловить описываемые вами проблемы (а их вы с учетом других дискуссий перечислили немало) в проектах таких масштабах с совеременными плюсами...
ХЗ, в чём современность измерять, но практически каждая фишка из современных плюсов есть
"Современность" кода это же не ачивка в стиме, важно не сколько единичных фич заиспользовано, а насколько хорошо ими покрыт код. Например "какой процент аллокаций через new/delete", "как часто аргументы передаются по указателю" и всё в таком духе.
Например?
мув семантика по сути дала адекватный способ передавать владение объектами не по сырому указателю (auto_ptr не в счет т.к. он сравнительно редко использовался и с ним свои нюансы). Ввели shared_ptr/unique_ptr, они как раз покрывают критикуемые вами кейсы. Асинхронное программирование сильно упростилось за счет лямбд, thread, mutex, и lock'ов.
Ну, да, появился operator<=>, но подсчёт хеша, дебаговый вывод, сериализацию в жсон, беготню по деревьям, вложенные optional и прочее всё равно приходится писать руками. Сравните с deriving (Show, Generic, Hashable, ToJSON, FromJSON)
Я согласен, что чем короче/проще код, тем сложнее спрятать в нём ошибку. Собственно, на этом моя аргументация и сторится - код на с++ действительно стал короче и проще. А ваша позиция - "по сути ничего не поменялось". Так тогда возникает закономерный вопрос - ваше мнение изменится если скажем в с++ появится рефлексия?
А то, что я пытаюсь сказать — это что диагностируемые ошибки лучше недиагностируемых и скрытых.
В общем случае да, я говорю про частный - когда задача не диагностировать ошибку, а предотвратить её возникновение. По крайней мере я понимаю "надежность ПО" именно как отсутствие непредвиденных отказов.
Это деталь реализации, при обсуждении операционной (или денотационной, неважно) семантики про подобное вспоминать не имеет смысла.
я лишь утверждал что любой иммутабельный объект можно передать по копии, даже если для этого придется заложить рефкаунтинг под капот. Не надо пожалуйста заводить спор а потом говорить что парировать ваши аргументы в нём не имеет смысла.
Вы изначально начали говорить, что в ФП за счёт иммутабельности что-то там происходит
не происходит, а гарантируется
... и что вот если на плюсах писать в чистом иммутабельном стиле с передачей объектов по значению, то с лайфтаймами и скоупами будет хорошо. Я говорю, что нет, не будет (хотя бы потому, что на C++ нельзя написать нетривиальную программу в иммутабельном стиле с передачей объектов по значению).
Примечательно, что чип T2 устанавливается на всех компьютерах Mac с процессорами Intel, выпущенных с 2018 года, но с «окирпичиванием» после обновления до macOS Monterey столкнулись также владельцы устройств 2015 года выпуска
Неа, не отличается. На C++20 писать в прод мне не приходилось, но на C++17 — вполне.
расскажите подробнее. Сколько, объем проекта, какого размера команда, насколько там современный код?
Или в вашей версии C++20 что-то принципиально поменялось по части гарантий со стороны языка?
начиная с с++11 появляется всё больше инструментов, позволяющих решать задачи быстрее и надежнее. Кодобаза на новых плюсах будет в среднем в разы лаконичнее и надежнее её старого аналога.
То, что нет никаких гарантий распечатывания всех ошибок памяти.
скорее гарантируют чем нет. По крайней мере я не знаю сценарий, способный обмануть санитайзер.
Я уж не говорю о логистических проблемах сборки всех зависимостей с санитайзерами, о повышенном потреблении ресурсов
я говорю про юнит-тесты. В них запуск под санитайзерами оправдан в подавляющем большинстве случаев.
... о том, что некоторые ошибки проявляются только сильно спустя время, и так далее.
и в условном шарпе таких ошибок, не сразу проявляющихся, конечно же не бывает?
Почему неприменим-то?
Если хотите поспорить на тему "почему языки с GC не применимы в latency-critical системах" можете перейти в эту статью
500-ка — это не то же самое, что «мы тут рассчитали какую-то ерунду и вернули её», не так ли?
я пытаюсь доказать что ошибки обоих видов могут вести к довольно-таки неприятным последствиям. Вы же пытаетесь доказать что гипотетическая программа A на языке X, содержащая ошибку W, обязательно обработает эту ошибку хуже гипотетической программы B на языке Y. Совершенно игнорируя тот факт что это зависит не от языков X vs Y, а от программ A vs B. И я уже объяснил почему язык B не поможет предотвратить ошибку W сколь угодно лучше языка A.
Давайте если продолжать спор, то вы не будете пытаться доказать что-то заведомо абсурдное.
Нет, я хочу, чтобы вы определились, понимаете ли вы, как работает чистое ФП (и не предлагали рефкаунты под капотом), или же не понимаете (и не пытались сказать, что ФП — это семантически C++, где всё pass-by-value).
во-первых, GC в функциональных языках по-вашему на пыльце фей работает? Там такие же счетчики ссылок под капотом. Во-вторых, вы придираетесь к той части, которая мне безынтересна. Мой аргумент состоял в том, что за счет более жестких контрактов в ФП можно обеспечить некоторые дополнительные гарантии. Ваши контраргументы это не опровергают... и вообще непонятно зачем они.
Но дальше-то что? Тех интервью сразу покажет, кто есть кто
проблема не в том, что шарлатан пробьется до тех ревью, а в том, что человек с хорошим легитимным резюме будет отсеиваться на этапах, которые проходит фейк резюме с отсылками на порнографию и рикролл. Что в очередной раз демонстрирует насколько плохо средний HR справляется с работой
А если верить этим ребятам, то превосходство всё еще вплоть до трехкратного, но уже в другую сторону. А вот например цитата из сравнения anandtech:
"...it’s to be noted that the workloads on the Tensor run via NNAPI, while other phones are optimised to run through the respective chip vendor’s libraries, such as Qualcomm’s SNPE, Samsung’s EDEN, or MediaTek’s Neuron – unfortunately only the Apple variant is lacking CoreML acceleration, thus we should expect lower scores on the A15".
То есть даже сравнивать tensor с A15 рановато. Мало того, в среднем по больнице tensor уступает и snapdragon 888. По мне так основная фича пикселя - отсутствие вендорских поделий. Ну и камера хороша.
а вот это - откровенная манипуляция. По факту приложения работают настолько быстро, насколько они упираются в боттлнек производительности на каком-то виде нагрузок, и ускорение других компонентов обычно не дает сколь угодно значимого прироста. Наглядные примеры отлично видны например на сравнении разных CPU в играх - пока боттлнек в GPU, разница в пределах 1% FPS.
В общем, автор в очередной раз продеманстрировал столь искусное жонглирование фактами, на которое не решился даже вендор. Браво!
а компилятор этого требует? В смысле "скомпилирует ли код, не удовлетворяющий panic safety"? Так или иначе, тривиальность мува сильно упрощает задачу (а точнее, отсутствие необходимости поддерживать исключение/панику при муве).
так речь же не об использовании unsafe функций, а о написании unsafe кода. Там с гарантиями всё намного хитрее, и стандарта, по которому можно было бы перепроверить код, попросту не существует.
это всё круто, учитывая что состав UB rust зависит от llvm, поведение миддленда которого по большей части определяется стандартом плюсов...
ну раст не умеет ни в исключения, ни в нетривиальный мув, поэтому логика контейнера очень сильно упрощается. А еще в расте считается, что всё что safe и скомпилилось не содержит UB. Правда, для реализации полноценного буфера понадобится unsafe, а там гарантий практически нет...
мне понравилась та часть рекламы, когда для проговаривания текста запустили не кортану, а гугл ассистента
на UB ругаются все. Просто одни ругаются на то, что у них нет рантайм проверок на каждом шагу, а другие бесятся что компилятор делает какие-то там предположения когда они весьма вальяжно работают с памятью.
ну конкретно с find_if вроде либо использовали функцию, а-ля
find_if(.., isspace), либо писали циклом.ну так new только для QObject иерархии и нужен, с передачей владения, т.е. просто так удалить не забудешь...
то у нас торговый бот, которому лишняя микросекунда вечность, то пофиг на рефкаунтинг... Хех.
блин вы сравните последствия move вместо copy elision с одной стороны и выбором между копированием и выделением в куче с передачей по указателю с другой...
не всегда переносимые
ну как, редко, но доводится, и как раз эти штуки сокращают код весьма мощно, а зачастую еще и время компиляции.
не "вместо" ведь... Просто пока рефлексия не готова, а потребность существует. А этот подводный камень не имеет отношения к spaceship, там разница именно в симметричности операторов в с++20+. Что кстати тоже сокращает код. Могли бы мб сделать явный квалификатор для этого, но их уже и так много...
ну для задач типа "сериализуй эту структуру с политикой по умолчанию" более чем хватит.
на жаве/котлине не писал, а вот на питоне довелось, и там надо держать в голове больше, чем в плюсах. Как минимум - типы переменных/аргументов. Да, вроде как не беспокоишься о лайфтаймах, но почти любая опечатка ловится только в рантайме. Спасибо, я лучше на плюсах буду писать, нервы дороже.
что-то около 6-7 лет, наверно не очень давно, да. За выслугу лет еще не награждали.
а если я бекенд разрабатываю, то кто есть пользователь? А если ошибки бывают, но в большинстве чисто логические, которые были бы допущены и в других языках?
спасибо за уточнение, проверил, там:
"In the aggregate scores, an E-core is roughly 54-64% of a P-core, however this percentage can go as high as 65-73%"
забавно, меня обвиняли в фанатизме и AMD, и intel, и apple, и NVIDIA... И из этой четверки у меня есть акции трех компаний, кроме как раз intel. Такой фанат синих, ага
вы пытаетесь оценить энергопотребление в разных режимах работы даже для десктопных процов. Залочьте процы на одинаковых частотах и сравните техпроцесс по перф/ватт.
берем игровую материнку, включаем PBO, разгоняем, замеряем, не?
а вас не смущает что вы сами завели речь про ноутбуки, и теперь приводите в пример десктопные процы? Я говорил про условные 5800U vs 1185G7, где ноуты на AMD сильно троттлятся при питании от батареи чтобы дольше держать заряд. Не забывайте пожалуйста, что сравнивая характеристики процов вы иногда сравниваете их в разных режимах работы
Далее конкретно про десктопные процы. Топовый 5950X жрет до 165 Вт, 12900K до 240 Вт, то есть примерно на 40% больше энергии. Вот только он в таком режиме и выдает, в зависимости от теста, на 20-30% больше перфа, что в силу нелинейности перфа от энергопотребления вполне укладывается в сравнимую энергоэффективность.
мне кажется вы немного переоцениваете системы охлаждения. Слабые воздушные кулеры обычно расчитаны на отведение 100W, топовые рассеивают порядка 180W от консьюмерского чипа (200+ для серверных процов, т.к. там отводится с большей площади). Т.е. с 5950X справится даже не самая крупная воздушка. А вот чтобы отвести 240W с i9 понадобится 360mm AIO в хорошо проветриваемом корпусе, и он будет работать на пределе.
Забавное наблюдение: из-за падения спроса на топовые intel в пользу AMD, 360mm AIO подешевели раза в полтора-два относительно пары лет назад.
в 16 ядер же, 8P+8E. То, что восемь из них названы "efficiency", не значит, что ими можно пренебречь. Да, у них ниже частоты на 1.2 ГГц, но из-за нелинейной зависимости перфа от частот разница с большим ядром - процентов 10-15. Полагаю, даже эти E-cores молотят на уровне ryzen'овских.
Вы как-то очень избирательно решаете рассматривать или не рассматривать частные случаи. Начинает даже казаться, что критерием является поддержка аргументом вашей точки зрения. Но давайте всё-таки попробуем провести объективную ревизию того, что мы можем игнорировать, а что - нет.
Вот вы описали все ужасы порчи памяти, а я продемонстрировал, как некорректная обработка ошибки может усугубить её последствия. Это гипотетические worst case scenario, основанные на предположениях о конкретном поведении конкретного кода. В целом можно игнорировать, верно?
Далее, вы утверждали диагностируемые ошибки строго лучше UB. С этим я не спорю. Но вы так же утверждали что это улучшает надежность системы, с чем я не согласен по тому определению надежности, которое я привел выше. Почему это частный случай и его не имеет смысл рассматривать?
Я ж говорю не про язык, а про компилятор/рантайм. Рефкаунт может служить лишь как оптимизация копирования, применимая для всех иммутабельных объектов. Но я всё еще не понимаю к чему это всё. Изначально я утверждал, что в функциональных языках более строгие контракты и можно добиться более строгих гарантий. Если вы пытаетесь спорить с этим утверждением, то я не могу понять как ваши аргументы его опровергают.
давайте еще раз. Вот вы в комментах к теме, посвященной си и с++, утверждаете, что понимаете состояние дел с++, на котором вы не писали лет 20, лучше, чем человек, который только на них и пишет, аргументируя это тем, что вышеупомянутый не пишет на других языках? Всех эпитетов моего лексикона не хватит для описания абсурдности этого утверждения.
полагаю затем же, зачем он назвался "Lorde Edge" из Trolheim'а
deleted
да, слово в слово. Ну или на нытьё студентов, которые хотят учиться программировать по питону вместо с++...
странно ловить описываемые вами проблемы (а их вы с учетом других дискуссий перечислили немало) в проектах таких масштабах с совеременными плюсами...
"Современность" кода это же не ачивка в стиме, важно не сколько единичных фич заиспользовано, а насколько хорошо ими покрыт код. Например "какой процент аллокаций через new/delete", "как часто аргументы передаются по указателю" и всё в таком духе.
мув семантика по сути дала адекватный способ передавать владение объектами не по сырому указателю (auto_ptr не в счет т.к. он сравнительно редко использовался и с ним свои нюансы). Ввели shared_ptr/unique_ptr, они как раз покрывают критикуемые вами кейсы. Асинхронное программирование сильно упростилось за счет лямбд, thread, mutex, и lock'ов.
Я согласен, что чем короче/проще код, тем сложнее спрятать в нём ошибку. Собственно, на этом моя аргументация и сторится - код на с++ действительно стал короче и проще. А ваша позиция - "по сути ничего не поменялось". Так тогда возникает закономерный вопрос - ваше мнение изменится если скажем в с++ появится рефлексия?
А "условного торгового бота" тоже я выдумал?
В общем случае да, я говорю про частный - когда задача не диагностировать ошибку, а предотвратить её возникновение. По крайней мере я понимаю "надежность ПО" именно как отсутствие непредвиденных отказов.
я лишь утверждал что любой иммутабельный объект можно передать по копии, даже если для этого придется заложить рефкаунтинг под капот. Не надо пожалуйста заводить спор а потом говорить что парировать ваши аргументы в нём не имеет смысла.
не происходит, а гарантируется
почему нельзя написать то?
начиная с них был чип T1
расскажите подробнее. Сколько, объем проекта, какого размера команда, насколько там современный код?
начиная с с++11 появляется всё больше инструментов, позволяющих решать задачи быстрее и надежнее. Кодобаза на новых плюсах будет в среднем в разы лаконичнее и надежнее её старого аналога.
скорее гарантируют чем нет. По крайней мере я не знаю сценарий, способный обмануть санитайзер.
я говорю про юнит-тесты. В них запуск под санитайзерами оправдан в подавляющем большинстве случаев.
и в условном шарпе таких ошибок, не сразу проявляющихся, конечно же не бывает?
Если хотите поспорить на тему "почему языки с GC не применимы в latency-critical системах" можете перейти в эту статью
я пытаюсь доказать что ошибки обоих видов могут вести к довольно-таки неприятным последствиям. Вы же пытаетесь доказать что гипотетическая программа A на языке X, содержащая ошибку W, обязательно обработает эту ошибку хуже гипотетической программы B на языке Y. Совершенно игнорируя тот факт что это зависит не от языков X vs Y, а от программ A vs B. И я уже объяснил почему язык B не поможет предотвратить ошибку W сколь угодно лучше языка A.
Давайте если продолжать спор, то вы не будете пытаться доказать что-то заведомо абсурдное.
во-первых, GC в функциональных языках по-вашему на пыльце фей работает? Там такие же счетчики ссылок под капотом. Во-вторых, вы придираетесь к той части, которая мне безынтересна. Мой аргумент состоял в том, что за счет более жестких контрактов в ФП можно обеспечить некоторые дополнительные гарантии. Ваши контраргументы это не опровергают... и вообще непонятно зачем они.
проблема не в том, что шарлатан пробьется до тех ревью, а в том, что человек с хорошим легитимным резюме будет отсеиваться на этапах, которые проходит фейк резюме с отсылками на порнографию и рикролл. Что в очередной раз демонстрирует насколько плохо средний HR справляется с работой