Roman K

Тут надо конкретизировать вопрос по тому что есть Solution Architect, Enterprise Architect, Software Architect и System Architect (если я никого не забыл)

По пунктам:

1. Отличаются ли между своими стеками или это какое-то определенное направление?

Да и очень сильно

2. Какие задачи решают, чем отличаются от любого IT директора - руководителя?

Зависит от того какого типа архитектор. Ему ничто не мешает быть руководителем или тимлидом, а также абсолютно независимую роль играть.

3. Как происходит "коронация", нужно ли работать 10 и более лет на одном месте работы?

Устроиться на работу на данную должность

4. Их процент среди общей массы?

Ниже плинтуса. Точных цифр не скажу, но по памяти если даже в крупных аутсорсерах в штате их < 0.5%. В мире же в общем это считаные единицы на десятки, если не сотни тысяч специалистов

5. Есть ли диапазон ЗП архитектора?

Нет. Архитекторы получают столько на сколько договорятся и насколько себя оценивают. В любом случае на зарплаты ниже тимлида/CTO обычно смотреть попросту не интересно.

да. а в чем трудности?

Какие задачи решают на Rust

любые. Rust - язык общего назначения, применимый к большинству возможных задач. Rust достаточно высокоуровневый для написания на нем прикладного ПО и компилируется в достаточно эффективный машинный код, для применения в ядрах ОС, драйверах или embedded разработке. Так же Rust на сегодня имеет самый маленький размер при компиляции в wasm, что критично для использования в web. Я честно не знаю такой сферы, к которой бы не подошел Rust.
Единственной проблемой в применимости Rust я вижу недостаточную его распиаренность в РФ, что часто бывает самым важным критерием для "манагеров" и прочих людей принимающих решения о используемом стеке.

а какие на Golang

Golang тоже язык общего назначения, но имеющий ряд ограничений:
- Крайне тяжелый рантайм не дает возможность использовать его в wasm, embedded или компонентах ядра.
- Необходимость в сборке мусора опять таки ограничивает разработку для embedded или компонентов ядра.
- Отказ от llvm в качестве бэкенда компилятора ограничивает число целевых платформ.

Можно один заменить другим?

Rust спокойно заменяет Golang в любой возможной на последнем задаче, наоборот же иногда имеем ряд ограничений.

Вместо P.S.:
Golang скорее всего окажется более быстрым для прототипирования и быстрого старта. Однако отсутствие полиморфизма в любом виде (утиная типизация не в счет) и ограниченность одной парадигмой структурного программирования делает этот язык крайне дорогим в поддержке. Так же этому (и быстрому прототипированию и дорогой поддержке кода) способствует лютая ненависть создателей языка к принципу DRY.
Rust имеет такую редкую сегодня строгую типизацию, одним из нюансов которой являются концепции владения и заимствования (которые позволяют делать автоматическое управление памятью в compile time), что порождает с одной стороны высокий порог входа в технологию (что сглаживается человекопонятным выводом компилятора, если входящие умеют читать, что еще более редко встречается сегодня, чем строгая типизация), но так же удешевляет поддержку продукта длительное время. Так же надо понимать, что Rust не спасет от кривых рученок быдлокодеров (разве что они не смогут его освоить), так как при большом желании можно сделать и утечки памяти и дедлоки и гонки данных (хотя в Golang это все сделать на порядок проще).
Ну и надо не забывать, что много где присутствует hype-driven-development и Golang распиарен, а Rust нет.

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

>>> from urllib.parse import urlparse
>>> u = urlparse("postgres://admin:oocooSh7@postgres.host:5432/my_db")
>>> u.password
'oocooSh7'
>>> u.username
'admin'
>>> u.hostname
'postgres.host'
>>> u.port
5432
>>> u.path
'/my_db'
>>> us = urlparse("sqlite:///C:/Users/admin/site_db.sqlite3")
>>> us.path
'/C:/Users/admin/site_db.sqlite3'
>>> us.scheme
'sqlite'
>>>

Думаю дальше сами справитесь.

Сама идея появилась от того, что при циклировании питания, изнашивается HDD и в гораздо меньшей степени, конденсаторы в цепях фильтрации питания.

Так что если исключить из рассмотрения HDD (его нет) и конденсаторы (там теперь кругом твердотельные), пробоем с циклированием нет никаких.

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

Сначала нужно выучить Python, потом браться за Django.

Ну во-первых, querySelectorAll возвращает коллекцию NodeList а не массив, это важно понимать.
Во-вторых, у NodeList нет сеттера onclick в отличии от элементов, а следовательно Ваше присваивание туда функции просто не сработает.
В-третьих, не стоит пользоваться сеттерами вида oneventname, так как это чревато проблемами, используйте метод addEventListener
В-четвертых, querySelectorAll можно использовать не только на document, но и на элементах
В-пятых, в обработчик события приходит объект события в качестве аргумента, в котором есть свойство target - элемент на котором событие произошло

По-итогу:

function listener(event) {
  const target = event.target.closest('.app__item');
  target.querySelectorAll('.equalizer').forEach(
    elem => elem.style.display = 'block'
  );
  // так как дальнейшие клики будут гонять бесполезный цикл, то лучше отписаться
  target.removeEventListener('click', listener);
}
document.querySelectorAll('.app__item').forEach(
  item => item.addEventListener('click', listener)
);

alex4answ, процедурный стиль использует только понятия модель памяти, типы, инструкции, программа и подпрограмма.

Вот и всё. Никаких составных типов. Концепция "состояние" в коде никак не выражается. Держите её если хотите в голове либо в комментариях.

Никаких сущностей в коде. Держите из в голове или в комментариях.

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

Но это всё уже вводится в структурном программировании.

Процедурное программирование вводит модель памяти с понятиями стек и куча. Хотите сделать функцию в процедурной парадигме - вам придется оформить её в виде подпрограммы и вызывать её из другой. Причем понятия линковки нет, вы будете делать это используя адрес в куче, а какие-то данные, типа, аргументы, будете сами на стэк ложить, каждый раз при вызове подпрограммы "функция".
Ах, да, захотите функцию для сложения двух чисел, придется сделать ctrl-c, ctrl-v и в теле подпрограммы написать сложение двух кусков данных взятых со стека. Для разности - копируете код, в теле меняете инструкции. И так для каждой функции.

Да, понятия область видимости нет, придется его выражать в коде таким вот образом самостоятельно.

Ну, и поскольку ОС не даст лезть за пределы одного процесса, подпрограмму придется положить в сорцы выше, чем ваш код.

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

Дело в том, что о процедурной парадигме можно говорить только ретроспективно. В основном, процедурная парадигма это классический ассемблер.

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

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

Т.е. берёте вы современный компилятор / интерпретатор любого языка, пишете решение в один файл, не используете составные типы, а только интегрированные простые (если вы выбрали язык со строгой типизацией), не используете функции, а только операторы, как закончите, смотрите на код - вы решили задачу в рамках процедурной парадигмы.

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

А вот в языке с полной поддержкой процедурной парадигмы можно делать такие подпрограммы, которые косплеят функции, но возвращают несколько "аргументов", причем пишут прямо в память. Да и в принципе, в процедурной парадигме можно делать свой ABI, нет никаких стандартов, нет правил, ничто не истинно и всё дозволено.