HettЛысый дядькапропущено...

Я бы посмотрел, как команда набранных по объявлению вчерашних студентов пишет потрясающе гибкий, читабельный, поддерживаемый код на Scala. Golang для того и создавался, чтобы быть бесхитростным, как палка-копалка, что, безусловно, лишает пылкие умы свободы творчества, но позволяет оставаться инструментом для достижения поставленных перед проектом целей кратчайшим путем.

Отсутствие многих удобных вещей в go никак не гарантирует тот факт, что вчерашние студенты будут закладывать в приложение грамотную архитектуру. В конечном счете получится такая поделка, в которой еще сложнее разобраться.
Да нет же, в том и смысл подобной технологии - направлять пользователя в нужное русло. Пользователь, он как электрический ток, идет по пути наименьшего сопротивления, и в этом смысле, чем стандартней, чем более "по колее" - тем лучше. Java в этом плане столь же показательна: тупо, без вариантов, многословно (ну и чёрт бы с ним), но "как по книге" делать гораздо проще, чем изобретать. Энтерпрайз - это поточная реализация большого количества довольно тупых маленьких частных задач, и здесь чем меньше у разработчика вариантов выдумывать "архитектуру", тем лучше. У меня имеется довольно богатый опыт общения с питоном в качестве основы для корпоративных решений, и как многие (видимо, недалекие или малоопытные люди) "открывают" для себя питон и восторгаются открывающимися возможностями, я кричал от восторга, когда довелось после этого вести проект на Спринге - настолько стабильнее и управляемей получается структура приложения. Есть опыт участия в средней мощности проекте на голанге в качестве аутсорсера, и я скажу - это здорово: понятно, просто, адекватно, сложностей разбираться в чужом коде у меня не возникало, а вот в питоне с этим бывают проблемы. В питоне можно внедрить в класс-родитель новые свойства (а можно и перегрузить !!!! ты никогда не знаешь этого заранее) на этапе импорта класса-потомка и потом затрахаться с дебагом, потому что импорт происходит не всегда, а только в иф-ветке при наличии неких условий в файле настоек, которые твой коллега придумал в рамках решения своей задачи (это я еще не говорю, про то, что с помощью всей мощи интроспекции можно навесить хуков на какие угодно события, а ты потом выясняй, где же оно тормозит). Причем это делается в прикладном модуле, никто не перепиливает библиотечный код. Надо ли мне такой волюнтаризм - нафиг не надо.

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

HettНекоторые вещи описаны на уровне спецификаций, тот же JPA, но каким образом тут ява как ЯП?
Таким образом, что для питона таких спецификаций нет, а для джавы есть.

HettСпринг это фреймворк, а питон - это ЯП, как можно сравнивать совершенно разные вещи?
Я видел кучу попыток реализовать на питоне что-то похожее на фреймворк для корпоративных решений, все неудачные, тот же bluebrim давно и безнадежно мертв. Давай смотреть правде в глаза, питон - это Django, Flask и еще пара очень специфических вещей типа Keras. Любой проект хоть немного выходящий за рамки стандартного веб-сайта требует от команды разработчиков без конца изобретать велосипеды, например, лютым геморроем оборачивается хранение состояния объектов между запросами, ибо нормального стандартного механизма просто нет.

HettВ яве как будто нельзя. Тут вопрос уже к разработчикам, а не к ЯП.
При желании можно даже писюн сломать, вопрос в том, насколько тот или иной инструмент помогает выстрелить себе в ногу. Ты вызываешь метод, который может вызвать исключение. Java не позволит тебе отдать в продакшен код, в котором возможные исключения явно не обрабатываются, питон - да бога ради.

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