Я знаю, что дропбокс дико страдал от питона

Они когда начинали - все было ок, но как только база кода разраслась, стало очень больно. Начали изобретать всяких роботов, которые бегают по коду и ищут баги

Ладно, че я тут говорю, у нас полбэка на пыхе вообще и вроде не жалуются
Так что я не удивлен, что поддерживать справляются и питон и все остальное

Но тут не берусь судить. По своему опыту скажу, что поддерживать код на питоне очень утомительно. В сумме с разработкой выходит ничуть не дешевле, чем на Java/Kotlin. Разумеется, если написать и выкинуть - питон рулит.

Я работал в стартапе с питоном фуллстеком годик
Было все так же примерно как на скале перед этим, разве что абстракций поменьше
С типами и этим всем основном доками справлялись, + были линтеры всякие

Поэтому не оч понимаю такого наезда :)

где-то видел доклад про переписывание части вашего бэка на Go

Так где наезд? мы питону учим физиков. Проблема в том, что основное достоинство питона - скорость разработки на старте. Как только этот старт пройден, он становится не дешевле жавы. А то и дороже

Там го и плюсы где прям быстро надо и мл крутить
Пыха - основная логика
А ща ещё завозят котлин на бэк

воу, jvm-ный kotlin?

Ну вот возможно зависит от опыта
Я работал с "прожжеными" питонистами, и как то было очень комфортно, даже в базе 5-6 летней давности

Ага

Ну так-то народ и на голом JS пишут и даже не на ES6. На мой взгляд, питон-то поприятнее будет

@happy_bracket Пока я ресёрчил аргументы в пользу своей точки зрения (кстати, я так и не понял, как мне в ФП добиться structured concurrency), я наткнулся на видео Венката, который объясняет это гораздо лучше, чем я бы смог: https://www.youtube.com/watch?v=QYBRifsWHD0.
Вот он говорит то же, что и я про паралелизм https://youtu.be/QYBRifsWHD0?t=2302. Справедливости ради, и циклы можно параллелить. Но есть огромная книга "Optimizing compilers for modern architectures", которая посвящена только теме паралеллизации императивного кода (то есть, в основном попытке понять, когда код можно параллелить или векторизовать, когда нет). Это я называю безумием. Там, где можно обойтись вызовом parallel, пишутся огромные тома.
Вот где он переходит на асинхронность: https://youtu.be/QYBRifsWHD0?t=2697. Слайда заключительного нет, но понятно, что там будет что-то типа "Structure of asynchronous imperative code is similar to structure of synchronous imperative code".
Ырыкс (и цепочка из flatMap, приправленная сахарком) хорош ровно до тех пор, пока нет ветвлений или циклом. Тогда не важно, как пайплан писать. Но только стоит делать асинхронно что-то сложное, так императивный код, который выглядит так же, как и синхронный - это манна небесная и при чтении кода и при написании. Добавил сюда cancellation и... Скажу сразу, не удивлюсь, если какой-нибудь аспирант сейчас пишет дисер на тему cancellation in FP.
Это два абсолютно разных стиля, оба со своими плюсами и минусами. Я не говорю, что на ФП нельзя писать асинхронщину, я говорю, что её писать не так удобно, как в императивщине. Так же, пример с распараллеливанием императивщины и необходимости использования полихедральщины для понимания, можно ли вообще параллелить в любом более-менее сложном случае, тогда как ФП с его иммутабельностью делают распаралелливание не проблемой, говорит не о том, что в императивщине нельзя писать паралельные программы. Просто это не так удобно.

Берут знаю как минимум пару ммо с серверами на java

о, и ты тут))0

Я тут год гдет

Показали стикерпак для важных переговоров (по мотивам не менее охуенного, но слишком серьезного t.me/addstickers/wfallacies):
https://t.me/addstickers/WannaCock

Раньше были цитаты