Иначе, когда они станут миддлами, а миддл не будет развиваться дальше, они станут на одну ступень, и здесь может победить молодость, а не опыт.
Глупо рассматривать весь опыт разработчика в 3 абсолютные ступени и считать что вчерашний джун который проработал 1.5-2 года и стал мидлом вдруг встал на одну ступень с мидлом у которого 5-6 лет опыта. То что и того и другого упрощенно принято называть словом мидл не значит их эквивалентность. Уж про то что молодость будет преимуществом промолчу.
У виртуального потока есть свой стек, за счет этого как раз и имеем нормальный тред дамп
Согласен тут видимо меня немного занесло.
oracle делают что-то новое, когда в этом есть реальная необходимость и без этого никак, там ничего не хотят добавлять просто по приколу, например в лепешку разобьются, чтобы не добавить новое ключевое слово.
11->17 теперь в языке два switch с разной семантикой, + yield + record + sealed + permits + сломанная семантика get/set в records, + сам синтаксис records сломал весь стандартный привычный синтаксис. Все что вы пишите было актуально до 11 версии. Сейчас уже никто в лепешку не разбиваеться.
Сильно java упала в популярности из-за того, что в ней небыло асинхронщины на уровне языка?
Java популярна по причине того что исторически заняла финансовый сектор и успешно держит а не по причине качества, быстродействия или каких то фич языка. Там все обкатано и большой пул разработчиков а это главное.
в принципе по части самой vm java сильно лучше .net
Сильное заявление. А аргументы будут?
теперь вот оракл еще ее и сделан заново (graalvm)
Молодцы конечно, в .net с 2019 года AOT есть из коробки. Без установок дополнительных VM и прочего.
можно с другой стороны зайти: если вы делаете не прокси сервер, то сильно ли вы потеряете, если вместе с диском и базой зависнет еще и машина с приложением? ;) все равно есть какой-то пул потоков, типичный бекенд это oltp, нет никакого смысла пускать 5 тысяч клиентов на одну базу чтобы они все вместе ее грузили по чуть-чуть, эффективнее дать доступ только 50-и в один момент.
Да действительно, используются 200 потоков когда можно 8, обрабатываются запросы параллельно или пусть постоят в очереди. какая разница. Прилетело 1000 запросов и мы вывозим по кэшам базам и интеграциям обрабатывать их параллельно, не беда, пусть постоят в очереди для их же блага.
все что не содержит в себе synchronized работает хорошо, как-то особо катать там нечего.
Это конечно очень здорово что Вы сказали что все работает хорошо и тестить там нечего но я предпочту старый добрый метод опытной эксплуатации на больших проектах как показатель качества работы и ее зрелости.
лично я из своего опыта редко видел какие-то асинхронные подзадачи в коде
Все эти корутины и виртуальные потоки это история не столько про асинхронность сколько про эффективную утилизацию ресурсов давая возможность не блокировать потоки. Любой backend это практически одни IO операции.
сделали полноценные виртуальные потоки, как в го (с некоторыми минусами, но близко)
Что там общего с Go? В Go потоки не деляться на платформенные и виртуальные, там вся работа на уровне языка идет с горутинами. Горутины сделаны по stackful схеме, в Java виртуальные потоки по stackless. Горутины порождаются явно, и не нужно думать в любой точке кода в каком контексте мы работаем, потому что все работает на горутинах. На Java мы будем работать в неявном контексте. Ну разве что общее что и там и там поддержка со стороны рантайма.
Как бы по этому в C# и добавили сахар с async/await в 2012, потому что работы не очень много на него надо
И как итог, в C# 12 лет как пишут по новому а в Java все эти годы давились реактивщиной, или просто забивали на нужды разработчиков. В принципе можно было и другие проблемы также решать: нужен новый сборщик мусора? Подождите лет 20, зато мы выкатим самый модный.
вам сделали конфетку, а вы тянетесь по привычке к сухарику
Вот когда это все добро обкатают, внедрят поддержку на всех необходимых библиотеках, ни у кого ничего не отвалится или отвалиться и все починят, и когда это обкатается на больших проектах, вот тогда да, можно будет похвалить. Потому что на деле может оказаться, как часто бывает шило на мыло.
Трудно сказать насколько сильно нужна эта асинхронищина на беке, в том смысле что если у вас пару мест асинхронного вызова, то можно использовать апи, которое еще с java 8 было, не самое красивое, с нюансами, но работает.
Если это шутка то не очень понятная.
По этому может и с большим запозданием, но в java это сделано так как должно
Есть такое хорошее выражение "лучшее - враг хорошего". Может быть async/await это не идеальное решение, но это решение которое работало, работает и будет работать. В то время как другие ЯП (JS, TS, Swift, Kotlin, Python, Rust) скопировали не идеальное но рабочее решение и многие годы используют их в боевых проектах, в Java семь лет пытались сделать "лучшее" решение, которое еще не факт что себя оправдает. Хотя нет же, в Java все это время закрывали проблему реактивными библиотеками, там прям страх и ненависть в комплекте и стакан молока за вредность, но зато не async/await.
в java это сделано так как должно
только время покажет должное ли оно
вам не надо знать ни про какие async/await
Как показывает практика знать придется еще больше, но про другое
Смотря что мы решаем. Если наша задача оптимизировать большое количество IO операций с минимальными вычислениями на CPU то разница между одним и несколькими потоками уже не будет такой драматичной - большую часть времени задачи будет находиться в состоянии ожидания. Так как горутины в основном для этого и создавались (так как с вычислительными CPU операциями хорошо справляются и обычные потоки) то справедливо заметить что в данном контексте как раз горутины и async это решениям одной и той же проблемы, немного отличающимися но все равно довольно близкими методами. Если мы возьмем не питон а C# или Kotlin где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.
И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
public static void sleep(long millis) throws InterruptedException {
if (millis < 0) {
throw new IllegalArgumentException("timeout value is negative");
}
long nanos = MILLISECONDS.toNanos(millis);
ThreadSleepEvent event = beforeSleep(nanos);
try {
if (currentThread() instanceof VirtualThread vthread) {
vthread.sleepNanos(nanos);
} else {
sleep0(nanos);
}
} finally {
afterSleep(event);
}
}
Наверное, дело в каких-то оптимизациях хранения объектов в куче.
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи. Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого. Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем. Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Развивайте как глубину в своей области, так и ширину знаний. Например, Java-разработчику полезно изучить DevOps или основы UI-дизайна.
Технологии развиваются стремительно. Знание популярных инструментов, таких как Docker или Kubernetes, и новых языков программирования вроде Go или Rust, выделит вас среди других специалистов.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Умение объяснять сложные технические детали, работать в команде и понимать цели бизнеса ценится не меньше, чем знание фреймворков.
Для кого? Для джуна?
"Java Concurrency in Practice" — Брайан Гетц
Вот тут можно дискутировать насчет полезности LeetCode да и в целом способности решать алгоритмические задачки, но мое индивидуальное мнение - алгоритмы полезны, так как, если ты знаешь структуры данных и можешь их использовать в решении задач, то ты можешь чувствовать себя увереннее в разработке.
Отличные советы чтобы навичок все забросил. Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий. Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто. Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Бесшовный пользовательский опыт: Хотя микрофронтенды разрабатываются отдельно, пользователь воспринимает их как одно целое.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода. Читать такие переводы уже на физическом уровне больно.
Отличное знание Java Core и Java Concurrency. Понимание объектно-ориентированного программирования, знание особенностей при работе с ним в Java.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.
Выражу возможно непопулярное мнение но мне кажется что сейчас, для больших компаний и команд, роль тимлида - это уже рудимент. Намного адекватнее мне показался подход когда есть команда адекватного размера и менеджером с одной стороны и техлидом с другой. Каждый занимается своим делом и делает это эффективно. Очень малореально это - сидеть на всех стульях во всем успевать разбираться, со всеми общаться успевать, при этом не овертаймить и не выгорать.
Чтобы описать концепцию использования переменных для какого-нибудь нового языка программирования, сперва нужно разделить все переменные по их времени жизни на статические и локальные (автоматические):
Статические — это глобальные переменные, функции и типы данных к которым можно обратиться из любого другого участка кода или модуля. Статические переменные (объекты) создаются как правило в куче и сохраняют свое значение при выходе из блока кода, где были определены (т.е. после выхода из текущей области видимости).
Автоматические или локальные переменные, это аргументы функций и переменные в выражениях, которые создаются компилятором в автоматическом режиме как правило на стеке. Локальные и автоматические переменные доступные только изнутри того лексического контекста, в котором они были определены, а их значения уничтожаются при выходе из блока кода, где они были созданы.
Вот я выделил переменную в куче, занял память. Вот эта переменная она по вашей логике статическая или локальная? Если мы возьмем семантику C то окажется что она по Вашей классификации статическая а если семантику Rust то получается что локальная? Не самый лучший пример концепции для нового языка.
Есть много критериев подходящего кандидата, но не все они равноценные. Дипломы и сертификаты можно купить, домашние проекты — «позаимствовать» на гитхабе, а вот решение задач (особенно в реальном времени) сразу показывает, как человек мыслит и к каким алгоритмическим конструкциям он привык.
Можно сколько угодно себя убеждать что "волшебные" алгоритмические задачи решать все ваши проблемы с подбором и как будто бы показывают как человек мыслит, но реальность такова что такие задачи показывают только как человек решает... такие задачи, причем именно за ограниченное время.
У меня есть хороший пример на эту тему. Как то работал на двух разных проектах с двумя разрабами. Уровень говнокода написанного первым стал легендой. Человек просто не мог писать нормально, понятно, расширяемо и оптимально. Его код проще было полностью заново переписать чем пытаться модифицировать. Другой разраб, будучи мидлом, как то раз решил простейшую задачу по блокировке доступа к ресурсу, таким образом что про это хоть отдельную статью писать. Вместо добавления обычного флага и поля с датой, история вылилась в многопоточное решение с отдельным экзекутором и хитрыми механизмами разблокировок в стиле "машинного обучения". При этом все это работало плохо и в случае повторного доступа к странице - блокировало пользователя без возможности как то блокировку снять до таймаута. Решение было просто легендарное.
Что же объединяет этих двух разработчиков и зачем я про них написал? Они оба были победителями олимпиад по программированию и отлично решали алгоритмы. И наверняка бы прошли бы любые алгоритмически интервью на 5 с плюсом.
Понять как мыслит человек можно только поработав с этим человеком и посмотрев как он решает разноплановые задачи а все эти попытки через найти "серебряную пулю" через алгоритмические или system design интервью - просто самообман. Не залезете вы в голову человеку даже за 2 часа интервью. Максимум что можно сделать это построить его таким образом чтобы разноплановыми вопросами, размышлениями и небольшими задачами, пошатать собеседуемого и посмотреть что он действительно понимает а что заученно или подсмотрено, построить вопросы так чтобы сложно было дать шаблонный ответ. И прикинуть насколько все это подходит под ваш проект. А дальше только на испытательном смотреть.
Спасибо множеству британских и американских каналов и сайтов с уроками по произношению. Приятно осознавать что они существуют исключительно для России.
Вот честно говоря, прочитал статью и так и не понял о чем идет речь. Сначала:
Я к тому, что каждый понимает под чистым кодом что-то своё: для кого-то достаточно правильного именования и грамотной декомпозиции, а кто-то не видит чистого кода без полиморфизма и высокого уровня абстракции.
И получаеться что у нас нет предмета обсуждения, так как каждый под эти понимает свое. Но далее встречаеться:
Вопрос состоит в том, стоит ли выполнять абсолютно все правила в любом контексте.
Какие правила, если выше описано что каждый понимает свое?
Собственно, вопрос мой в том, насколько уместно соблюдать все сложные архитектурные правила чистого кода в каком-нибудь TODO приложении..
Мысль, которую я хочу донести, состоит в том, что не все задачи требуют соблюдения всех правил чистого кода.
Вроде бы говорили про философию а перешли к каким то уже конкретным правилам.
Всегда ли стоит добиваться максимальной абстракции? Обязательно ли функции должны быть короткими и выполнять одну задачу? Мой ответ: нет, не всегда. Однако замечу, что и выдавливать максимальную производительность из кода необходимо не всегда.
И вот здесь начинаешь подозревать что уже произошла подмена понятий. Вместо абстрактного философского понятия "чистый код", уже имеется в виду конкретно заветы Мартина, SOLID, паттерны и т.д.
Напишу свое мнение со своего опыта. Не стоит делать из паттернов, принципов и книг известных авторов религию. В моем понимании, чистый код - это код который понятен большинству разработчиков, устойчив к изменениям и надежен а не тот который формально что-то соблюдает. Второе, из определенного опыта связанного с геймдевом и огромным требованиям к производительности, могу заявить: можно писать хорошо и понятно, при этом производительно. Просто не нужно формализованные правила возведенные в религию напрямую отождествлять с понятием хорошего кода.
Честно говоря, я уже от восьмерки плакал. Чтобы так откровенно начать убивать язык - это надо постараться. Все молятся на "Чистый код" Мартина, но требования второй главы в 8 нарушены чуть более чем полностью.
Не могли бы уточнить к каким изменениям у Вас такие претензии?
Вы раз за разом рассказываете спецификацию "своими словами" при этом не можете на эту самую спецификацию сослаться. Сейчас пишите про "расплывчатое определение". Ссылаетесь на часть спецификации где просто есть слова "cached" и "registers".
Почему так сложно признать что на деле слабо понимаете как работает volatile?
Глупо рассматривать весь опыт разработчика в 3 абсолютные ступени и считать что вчерашний джун который проработал 1.5-2 года и стал мидлом вдруг встал на одну ступень с мидлом у которого 5-6 лет опыта. То что и того и другого упрощенно принято называть словом мидл не значит их эквивалентность.
Уж про то что молодость будет преимуществом промолчу.
Согласен тут видимо меня немного занесло.
11->17
теперь в языке два switch с разной семантикой, + yield + record + sealed + permits + сломанная семантика get/set в records, + сам синтаксис records сломал весь стандартный привычный синтаксис.
Все что вы пишите было актуально до 11 версии. Сейчас уже никто в лепешку не разбиваеться.
Java популярна по причине того что исторически заняла финансовый сектор и успешно держит а не по причине качества, быстродействия или каких то фич языка. Там все обкатано и большой пул разработчиков а это главное.
Сильное заявление. А аргументы будут?
Молодцы конечно, в .net с 2019 года AOT есть из коробки. Без установок дополнительных VM и прочего.
Да действительно, используются 200 потоков когда можно 8, обрабатываются запросы параллельно или пусть постоят в очереди. какая разница. Прилетело 1000 запросов и мы вывозим по кэшам базам и интеграциям обрабатывать их параллельно, не беда, пусть постоят в очереди для их же блага.
Это конечно очень здорово что Вы сказали что все работает хорошо и тестить там нечего но я предпочту старый добрый метод опытной эксплуатации на больших проектах как показатель качества работы и ее зрелости.
Все эти корутины и виртуальные потоки это история не столько про асинхронность сколько про эффективную утилизацию ресурсов давая возможность не блокировать потоки. Любой backend это практически одни IO операции.
Что там общего с Go? В Go потоки не деляться на платформенные и виртуальные, там вся работа на уровне языка идет с горутинами. Горутины сделаны по stackful схеме, в Java виртуальные потоки по stackless. Горутины порождаются явно, и не нужно думать в любой точке кода в каком контексте мы работаем, потому что все работает на горутинах. На Java мы будем работать в неявном контексте. Ну разве что общее что и там и там поддержка со стороны рантайма.
И как итог, в C# 12 лет как пишут по новому а в Java все эти годы давились реактивщиной, или просто забивали на нужды разработчиков. В принципе можно было и другие проблемы также решать: нужен новый сборщик мусора? Подождите лет 20, зато мы выкатим самый модный.
Вот когда это все добро обкатают, внедрят поддержку на всех необходимых библиотеках, ни у кого ничего не отвалится или отвалиться и все починят, и когда это обкатается на больших проектах, вот тогда да, можно будет похвалить. Потому что на деле может оказаться, как часто бывает шило на мыло.
Если это шутка то не очень понятная.
Есть такое хорошее выражение "лучшее - враг хорошего". Может быть async/await это не идеальное решение, но это решение которое работало, работает и будет работать. В то время как другие ЯП (JS, TS, Swift, Kotlin, Python, Rust) скопировали не идеальное но рабочее решение и многие годы используют их в боевых проектах, в Java семь лет пытались сделать "лучшее" решение, которое еще не факт что себя оправдает. Хотя нет же, в Java все это время закрывали проблему реактивными библиотеками, там прям страх и ненависть в комплекте и стакан молока за вредность, но зато не async/await.
только время покажет должное ли оно
Как показывает практика знать придется еще больше, но про другое
Смотря что мы решаем. Если наша задача оптимизировать большое количество IO операций с минимальными вычислениями на CPU то разница между одним и несколькими потоками уже не будет такой драматичной - большую часть времени задачи будет находиться в состоянии ожидания. Так как горутины в основном для этого и создавались (так как с вычислительными CPU операциями хорошо справляются и обычные потоки) то справедливо заметить что в данном контексте как раз горутины и async это решениям одной и той же проблемы, немного отличающимися но все равно довольно близкими методами. Если мы возьмем не питон а C# или Kotlin где неблокирующая асинхронность перекликается с параллелизмом то получим очень близкие решения.
И корутины и горутины решают одну и ту же задачу - легковесное управление большим числом асинхронных неблокирующих задач. То что там в реализации используется stackful подход вместо stackless не делает из автомобиля смартфон.
Нет никаких там дополнительных потоков, те же таски но на уровне JVM исполняемые платформенными потоками-носителями. Вся киллер фича Java подхода - это отсутствие необходимости явного этим управления. Для этого в коде буквально напиханы If-чики
Нет все проще. Если не ошибаюсь, в Java только к 2017 году проснулись и осознали что оказывается в современном яп нужна нормальная поддержка неблокирующей асинхронности. Можно было скопировать async/await который уже был отработан много лет но в Oracle решили стать нитакусиками и начали пилить свои идеи.
Как результат, в Kotlin корутины зарелизили в 2018 году а в Java виртуальные потоки увидели мир только через 6 лет после этого.
Итого мы сейчас в Java имеем виртуальные потоки, которые по факту те же корутины без особых преимуществ, только без необходимости писать async/await и пока что непонятно насколько эффективные в будущем.
Просто для сравнения: в C# async/await появился в 5.0 версии в 2012 году.
Получаем разрабы в стиле - слышал про многое, не знаю из этого толком ничего.
Для кого? Для джуна?
Отличные советы чтобы навичок все забросил.
Вот есть новичок. Ему итак сложно, он итак перегружен даже той базой знаний что требуется от него здесь и сейчас. А сейчас от него требуется изучить нормально язык программирования, текущие фреймворки, подходы, git, жизненный цикл разработки и т.д., чтобы он хотя бы смог самостоятельное работать и закрепиться в профессии, стать полноценным разрабом.
А Вы ему предлагаете дополнительно изучать Go, Rust, Docker, Kubernetes, многопоточку и учиться решать алгоритмы.
Ни в коем случае. Mock-собеседования выкладывают все кому не лень. Шанс нарваться на видео где кандидат несет ахинею а интервьюер его радостно поддерживает очень высокий.
Таких видео полно. Для начинающего, распознать где хорошо а где плохо не просто.
Тоже самое касается статей. Лучше всего для новичка - сделать упор на книги и официальные мануалы.
Большая просьба, после того как перевели статью гугл-переводчиком, ну хотя бы на разок, прочитайте ее сами или уж лучше просто выкладывайте ссылку на оригинал без всякого перевода.
Читать такие переводы уже на физическом уровне больно.
Неплохо так. Мне всегда казалось что найти senior который реально понимает Java Concurrency выше базового уровня - не простая задача сейчас. А тут мидлы еще и на отлично должны знать.
Выражу возможно непопулярное мнение но мне кажется что сейчас, для больших компаний и команд, роль тимлида - это уже рудимент. Намного адекватнее мне показался подход когда есть команда адекватного размера и менеджером с одной стороны и техлидом с другой. Каждый занимается своим делом и делает это эффективно. Очень малореально это - сидеть на всех стульях во всем успевать разбираться, со всеми общаться успевать, при этом не овертаймить и не выгорать.
Вот я выделил переменную в куче, занял память. Вот эта переменная она по вашей логике статическая или локальная? Если мы возьмем семантику C то окажется что она по Вашей классификации статическая а если семантику Rust то получается что локальная?
Не самый лучший пример концепции для нового языка.
Можно сколько угодно себя убеждать что "волшебные" алгоритмические задачи решать все ваши проблемы с подбором и как будто бы показывают как человек мыслит, но реальность такова что такие задачи показывают только как человек решает... такие задачи, причем именно за ограниченное время.
У меня есть хороший пример на эту тему. Как то работал на двух разных проектах с двумя разрабами. Уровень говнокода написанного первым стал легендой. Человек просто не мог писать нормально, понятно, расширяемо и оптимально. Его код проще было полностью заново переписать чем пытаться модифицировать. Другой разраб, будучи мидлом, как то раз решил простейшую задачу по блокировке доступа к ресурсу, таким образом что про это хоть отдельную статью писать. Вместо добавления обычного флага и поля с датой, история вылилась в многопоточное решение с отдельным экзекутором и хитрыми механизмами разблокировок в стиле "машинного обучения". При этом все это работало плохо и в случае повторного доступа к странице - блокировало пользователя без возможности как то блокировку снять до таймаута. Решение было просто легендарное.
Что же объединяет этих двух разработчиков и зачем я про них написал?
Они оба были победителями олимпиад по программированию и отлично решали алгоритмы.
И наверняка бы прошли бы любые алгоритмически интервью на 5 с плюсом.
Понять как мыслит человек можно только поработав с этим человеком и посмотрев как он решает разноплановые задачи а все эти попытки через найти "серебряную пулю" через алгоритмические или system design интервью - просто самообман.
Не залезете вы в голову человеку даже за 2 часа интервью. Максимум что можно сделать это построить его таким образом чтобы разноплановыми вопросами, размышлениями и небольшими задачами, пошатать собеседуемого и посмотреть что он действительно понимает а что заученно или подсмотрено, построить вопросы так чтобы сложно было дать шаблонный ответ. И прикинуть насколько все это подходит под ваш проект. А дальше только на испытательном смотреть.
Спасибо множеству британских и американских каналов и сайтов с уроками по произношению. Приятно осознавать что они существуют исключительно для России.
Вот честно говоря, прочитал статью и так и не понял о чем идет речь.
Сначала:
И получаеться что у нас нет предмета обсуждения, так как каждый под эти понимает свое. Но далее встречаеться:
Какие правила, если выше описано что каждый понимает свое?
Вроде бы говорили про философию а перешли к каким то уже конкретным правилам.
И вот здесь начинаешь подозревать что уже произошла подмена понятий. Вместо абстрактного философского понятия "чистый код", уже имеется в виду конкретно заветы Мартина, SOLID, паттерны и т.д.
Напишу свое мнение со своего опыта.
Не стоит делать из паттернов, принципов и книг известных авторов религию. В моем понимании, чистый код - это код который понятен большинству разработчиков, устойчив к изменениям и надежен а не тот который формально что-то соблюдает.
Второе, из определенного опыта связанного с геймдевом и огромным требованиям к производительности, могу заявить: можно писать хорошо и понятно, при этом производительно.
Просто не нужно формализованные правила возведенные в религию напрямую отождествлять с понятием хорошего кода.
Нет. Это решение абсолютно тех же проблем что и корутины, просто несколько другим способом.
Не могли бы уточнить к каким изменениям у Вас такие претензии?
Вы раз за разом рассказываете спецификацию "своими словами" при этом не можете на эту самую спецификацию сослаться. Сейчас пишите про "расплывчатое определение". Ссылаетесь на часть спецификации где просто есть слова "cached" и "registers".
Почему так сложно признать что на деле слабо понимаете как работает volatile?