Языковая политика

Я имел в виду далеко не только питон а вообще языки программирования.

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

но почему???

В общем, у меня сложилось такое впечатление. Типизация выступает минимальной документацией; легче модифицировать код, например, если требуется превратить
interface I {
  foo;
  bar;
}
в
interface I {
  foo;
  bar;
  baz;
}
автодополнение работает, особенно при вызове методов через точку, что, в частности, улучшает discoverability. Если в каких-то ситуациях статическая типизация оказывается ограничительной, то на работе, может быть, это даже хорошо.

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

Mypy существует уже давно.

Я делал прямой запрос, чат ответил, что его код написан на Питоне.

Инфраструктура какая-то - почему бы и не на питоне. Я имею в виду, что "думает" он не питоном.

Специалист по ML точно не получится. Но и с Java тоже не получится.

Выиграйте какие-нибудь состязания на kaggle - глядишь, работодателя впечатлит. 

Питон незаменим конкретно для машинного обучения, потому что на нём реализованы фреймворки: PyTorch и TensorFlow. (Точнее, питоновский интерфейс оборачивает низкоуровневое "мясо" этих фреймворков) В машинном обучении программирование тривиально, на уровне скриптов: задал архитектуру, параметры обучения,  источник данных - и вперёд. Сложность не в программировании вообще и не в питоне в частности, а как раз в машинном обучении: архитектура, параметры обучения и - самое главное - данные. Специалист по ML должен как-то понимать, какой нужен датасет, чтобы получилась хорошая модель. Это особое мышление, непохожее на программирование.

Обучив модель, питон экспортирует её, и её можно использовать в приложениях. А для приложений питон не является мейнстримом, скорее C++.

Никогда не юзал MutationObserver-ы! Но, очевидно, они работают в другую сторону: реагируют на изменения DOM-а.

Потому что файлы проекта - это исходный код, который не попадает в браузер непосредственно, а предварительно преобразуется ("билдится") вместе с зависимостями в так называемый "бандл" - набор файлов, который хостится на сервере. Поэтому нужна по крайней мере команда "сбилдить".

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

В-третьих, при разработке могут использоваться утилиты. Например, eslint, который следит за стандартным форматированием кода. Хотя обычно линтер не приходится запускать руками: он используется через IDE или хуки гита.

Ну и гит - куда же без него.