Api это не стена, это осознанный интерфейс со своими задачами.

Имхо конечно, но он сам по себе важен для взаимодействия с системой

Там много чего происходит:  валидация, логгирование, и куча других процессов.

Имхо конечно, но тут проблема будет в приложениях и различных клиент Стейт реализаций. Т.е. апи в любом случае в них нужно

Там нет пропасти. JS легкий язык. Я только в этом году пописал на Go и Rust. Не знаю с какого момента тебя вообще становится без разницы на чем писать

Все языки одинаковыми выглядят

В любом случае продуктивность при переключении серьезно падает

Недавно спрингбут пробовал, в итоге решал на путоне-джанге задачи раза в 3 быстрее.

Все таки путон по сравнению с Явой и плюсами намного читабельнее и ближе к ооп как отражению реального мира, имхо

Сейчас реализация API часто используется в качестве результата работы команды, ответственной за сервис. Это можно изменить на микрофронтенд со всеми нужными компонентами, формами и кнопочками в качестве результата работы. Да, API будет в случае разработки модульной системы. Это может быть просто пачка функций на питоне.

Ну, есть кеши, собственно, вот в каком-нибудь там Redis этот state и может быть...

Понятно, что в условиях когда у тебя 100500 контейнеров запущено, запросы будут попадать на разные...

В простом случае это может быть таблица в СУБД, под нагрузкой - отдельный instance Redis

Если настроено хранение кеша в оперативке, система не будет работать стабильно, разумеется.

Как много Джанго-разработчиков программируют на Rust?)

Будут ли люди, которые так считают, работать за те же деньги, что и Django-разработчики? Насколько их много на рынке вообще?)

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

В итоге выбор компонентов в чужой экосистеме будет основан исключительно на SO и звёздах на гитхабе.

Вообще, это достойно какой-то отдельной темы для флуда, наверное.

Различия между разработчиками (как «мини-архитектор») и программистами (как «мастер leetcode’а»).

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

На собеседованиях часто задают вопросы по алгоритмам (поэтому каждый разработчик получается немного программистом путём естественного отбора, это обычно приводит к фразам у разработчиков«рекрутинг сломан»).

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

Цена ошибки тоже разная: кривая реализация сложного алгоритма - это в конечном итоге неэффективное использование CPU и повышение стоимости владения системой; кривой выбор компонентов грозит отказу от использования системой, всё гораздо фатальнее в случае ошибки, накосячить с медленными алгоритмами дешевле чем накосячить с неправильно выбранными компонентами.

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

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

Да, ещё одно отличие:

Программист, когда хочет прокачаться, стать лучше, идёт изучать другие языки программирования и другие алгоритмы. Разработчик идёт изучать другие способы решения практических задач (он пробует не другие ЯП, а другие системы, которые иногда написаны на других ЯП).