Ну линукс не нужен, а мак тем более.

С установкой под Linux проблем действительно нет. Там другая проблема в переходе со 2 версии на 3: очень много было создано полезных библиотек под 2 версию, которые до сих пор не были портированы, либо не созданы их аналоги. Т.е. выбор версии питона зависит от тех библиотек, которые вам нужны.

На винде тоже нет никаких проблем, конда работает. Проблема общепитоновская в том, что нет сборки, или создавай окружение на каждый мало-мальски сложный проект, или подбирай аккуратно что ты устанавливаешь в общую мусорку. В JS примерно та же фигня, там есть завсисимости проекта, но они устроены совершенно монструозным образом. Самое плохое, когда это python+JS в одном флаконе, как например для Jupyterlab.

Для человека, привыкшего к милому и комфортному maven/gradle, все это очень травматично.

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

установка окружения для питона равна сборке жирного джарника.

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

при этом непонятно что мешает сделать бандлер в питоне, но они вообще странные.

это вы про что? про scope=import? в каком это смысле автоматически?

я бы сказал, что и в мавене, и в градле dependency hell как был так и есть. все попытки что-то с ним сделать похожи на попытки приложить подорожник. причём в мавене всё декларативно, так что хоть как-то можно делать всякие enforce и вообще статический анализ (хотя контейнеры вроде spring boot или j2ee часто сводят это на нет).
вот мне и стало интересно что это за "лок версий"

не знаю что такое скоуп импорт. я про Gemfile.lock, yarn.lock и их аналоги в градл и мавене. в градле https://docs.gradle.org/current/userguide/dependency_locking.html

эммм. с точки зрения maven вроде надуманная проблема, да и в gradle решается указанием версий. или я чего-то не понял? по описанию очень похоже на scope=import в maven, только вывернутый наизнанку. вместо того, чтобы рулить версиями всех библиотек из всех источников, их просто фиксируют. это вроде не решает проблем конфликтных версий и не позволяет их выявить

видимо, если ты вдруг решил что твой язык не очень и сборка очень сложная, нужно попробовать ruby или python :) после этого и kotlin покажется конфеткой :)

если указывать верси  в ручную, то с точки зрения любой системы разрешения зависимостей проблема надуманная

Всем добрый день. Не подскажите может кто-то сталкивался. В котлине массивы это дженерик класс. В яве мы можем с помощью инстансоф проверить что объект принадлежит массиву какого то класса. К примеру: obj instanceof MyClass[]. Можно как то это провернуть в котлине?

obj is MyClass[]

В котлине можно писать MyClass[]?

Если не ошибаюсь, obj as Array<MyClass>

Ну так проблема в этом и есть. Теоретически, дженерик затрется и Array<MyClass> будет то же самое, что Array<OtherClass>

С другой стороны, Array<T> в котле это прямое представление джавового T[]

Не, так не хочет. Я попробовал написать функцию расширения для Object, но не знаю как тип передать, пока сделал что передаю пустой объект экземпляра класса, но это все такие костыли