Дякую за статтю.

Вражає.

Люди, бережіть руки! Користуйтесь ергономічними клавіатурами!

Так. Logi MX Ergo — рекомендую. Я якщо вдасться знайти з додатковою підставкою — взагалі ще краще (там 2 версії).

Оф. “The Book”, “The Rust Programming Language” від MIT (web.mit.edu/...​rust/html/book/index.html), “Rust By Example”, “Rust Language Cheat Sheet” (cheats.rs)

Також написав бекенд на rust — гарно и швидко працює — їсть зовсім трішки ресурсів. Зприводу виразності — згоден, вона дійсно допомагає, але як розробник php,js,ts скажу, що rust досить добре читається, коли звикаєш до великої кількості Generic.

Зараз — Blockchain. В 2023 (через менше ніж через 2 тижні) — Blockchain, WebAssembly, CLI Tools. Але насправді, хто може знати що принесе наступний рік.

Судячи з того, що ще десятеліття не пройшло, а мову вже люблять і впроваджують в ядрі Linux, а також Google пише на ній OC — буде все файно.

Дозвольте відповім.
1) ви вже самі дали відповідь на перше ;) запитання.
2) Так, підходить, оскільки складна логіка в більшій мірі залежить від архітектури, а ніж від мови як такої.

Так. див. “Memory safe languages” media.defense.gov/...​OFTWARE_MEMORY_SAFETY.PDF

Чи планується сертифікація накшталт OpenJS Certification and Training Programs?

У архитектуры долга быть не может. Архитектурный план или есть или его нет, или он правильный или нет.
А технический долг — это когда все работает как ожидается (всегда a+b=c ), но внутри могло бы выглядеть лучше, и порой даже должно выглядеть лучше если это основа для расширения будущего функционала.

Архитектура — это высокоуровневая часть проекта приложения, каркас, состоящий из деталей проекта (Buschman etal., 1996; Fowler, 2002; Bass Clements, Kazman 2003; Clementset al., 2003). Архитектуру также называют «архитектурой системы», «высокоуровневым проектом» и проектом высокого уровня«. Как правило, архитектуру описывают в единственном документе, называемом «спецификацией архитектуры» или «высокоуровневым проектом».

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

Хотел продолжить мысль, что «долг» также растет по причине того, что сам разработчик обучается пока пишет приложение — в начале он видит очень простой путь к созданию компонента — быстро, понятно, без лишнего залога на псевдо будущее. Но на 3-4м компоненте обнаруживает, что есть неявная (в начале) закономерность, и что есть смысл сделать немного по другому. И таким образом у нас появляется технический долг. А обучается он, потому что каждый следующий проект индивидуален — та же платформа, тот же framework, те же контролы, но другая суть, другая модель.