Алексей

однако неопределенные поведения мы либо обрабатывали исключениями, либо как-то логично обрабатывали входные параметры операндов (obj1 + obj2). А как же тут обрабатывается?

А вот не поверите, есть два вида программистов: те, которые считают, что хорошо замалчивать ошибки, и те, кто УЖЕ так больше не считает. Есть даже статьи на Хабре, которые рассказывают, какой JS хороший и "надежный". Считать замалчивание ошибок надежностью - имхо это значит не стать (пока что) программистом. От ошибок можно уметь восстанавливаться, но замалчивать их нельзя.
В качестве примера посмотрите на архитектурные подходы в Эрланге. Прям погуглите по словам "erlang let it crash". Этот подход, поддерживаемый концепцией процесса в Эрланге, говорит, что тот код, который не может дальше нормально выполняться, должен "упасть". А мы напишем другой код, который будет следить за работой основного, и в случае нештатных ситуаций будет предпринимать необходимые действия (например, перезапускать процесс).
Да хотя что далеко ходить, концепция исключений в более популярных языках также есть способ научиться жить с ошибками, не бояться их генерировать, и уметь их обрабатывать там, где это возможно и удобно. Это первое.

Второе: JS это язык со слабой типизацией. Это такая штука, которая позволяет написать 1 + "1" и безо всяких перегрузок в стиле C++ транслятор сам приведёт какой-то из аргументов к такому типу, чтобы операцию можно было выполнить. Вы сейчас просто в большом удивлении от того, что это возможно и кому-то такое могло прийти в голову (вы из плюсов пришли, да?). Кстати, в PHP почти то же самое. Только правила преобразований другие немного. (Кстати, почитайте об операторах == и === в JS, узнаете много удивительного, если еще не сталкивались).

Ведь браузерные движки написаны на С++, а значит все это JS-дело определено на уровне С++, мне интересно какие внутренности определяют такое поведение.

Никакие внутренности не определяют это поведение. Все эти случаи либо явно описаны в стандарте JS и их просто реализуют в соответствии со стандартом, либо реализуют так, чтобы реализации были максимально совместимыми. Тут можете почитать про typeof null, возвращающий "object" - по сути один большой баг, который теперь поддерживают, чтобы не сломать совместимость.

Из-за этих мелочей в JS минимум системности и логичности. Этим языком правит совместимость, а не логика. Почему он такой, какой есть, вам уже ответили.

Писать свою
Джанго админка не предназначена для использования не администраторами

На нормальном проекте должна быть инфраструктура с галпом/вебпаком. Если вам самим лень в таком копаться, погуглите готовые генераторы yeoman с angular+webpack/gulp. Жизнь сразу станет проще и веселее.

import os

if os.listdir(path):
    #Есть файлы
else:
    #Нет файлов

У каждого инструмента своё назначение. Все мы слышали расхожие фразы про забивание гвоздей микроскопом и колку орехов молотом. Основная фишка Django - быстрая и простая разработка. Многопоточность же сама по себе не простая, а в Python и подавно. Поэтому Django однопоточный и синхронный. Всё в нём проектировалось с учётом последовательного выполнения и попытка применять параллельное приведёт к проблемам. Можно использовать его исполнение в многопроцесной среде, но это вопрос уже не к Django, а к среде исполнения. Например, к uWSGI. Почитать о динамическом выделении воркеров в uWSGI можно здесь. В самом Django же надо стараться делать так, чтобы вьюхи максимально быстро отдавали результат. Правильнее их проектировать так, чтобы длительные и блокирующиеся операции можно было переложить на Celery. Если же задача именно держать долго и упорно коннект с клиентом, то лучше посмотреть в сторону асинхронных фреймворков Tornado, aiohttp или Gevent.

setInterval(function() {
  db.write({  }); // пишем в базу каждую секунду
}, 1000);

я пользовался var_dump

Альтернативы:
- pprint
- repr
- print vars(someObj)
-

from inspect import getmembers
from pprint import pprint
pprint(getmembers(someObj))

cppreference

Появление сообщений в чате реализировано через $compile.

Зачем? Намного практичнее использовать старый добрый ngRepeat. Так можно потом виртуальные скролы прикрутить какие-нибудь и т.д. Разделение ответственности короче.

А то что вы описываете это jquery-стайл.

Для защиты от XSS просто используйте $sanitize.

Стандартный curses, либо более высокоуровневый urwid

Пакеты Джавы и сборки Дотнета - это про модули в терминах крупной структуры приложения, они тут не при чем.
Речь идет о модулях на уровне программного кода.
Хотите примерно понять как это будет выглядеть - посмотрите, например, на юниты в Паскале. Это примерно и есть то, что хотят получить в конечном счёте - возможность по-человечески, на уровне языка, объявлять интерфейсы модулей, подключать их друг к другу, следить за зависимостями между модулями (разве что модули C++ вроде как не привязываются к единице компиляции, в отличие от юнитов Паскаля).
Сейчас в C++ это достигается большим хаком на уровне препроцессора (а не компилятора языка), называющимся include-файлы. Этот механизм, основанный на правиле "много объявлений, одно определение", унаследован из Си, и по сути представляет собой замену отсутствующей возможности передавать метаданные от одной единицы компиляции к другой при сборке проекта. С помощью инклудов вы напихиваете в один файл ВСЕ, что может потребоваться компилятору. По факту выливается в то, что бОльшая часть единицы компиляции после обработки препроцессором - это содержимое инклуд-файлов. И всё это обрабатывается компилятором каждый раз заново (в каждой единице компиляции). В Си это еще куда ни шло, но в плюсах, где многие библиотеки содержат тяжелый шаблонный код, это становится совсем печальным. Помимо этого, сама работа с инклудами - это непростая практика, и если следовать ей неверно, особенно новичкам, они могут получить от компилятора удивительнейшие ошибки. За примером далеко ходить не надо - попробуйте в большом проекте не ставить защиту от множественного инклуда.
Вся эта препроцессорная магия красоты и прозрачности языку не добавляет. Пока в других языках пишут "package foobar" и "import foobar", мы пишем "#pragma once" или даже "#ifndef FOOBAR_H ...". Уже грустно как-то становится.

Вышесказанное в одно предложение: модули хотят сделать настоящими, вместо имитации средствами препроцессора.