>Что имеем:
У нас есть синтаксический сахар поверх джавы, немного ФП (удобные лямбды), корутины с асинхронщинной, DSL и многое другое.
В синтаксисе можно встретить много WTF-решений (как же без них), но в целом, плюсы перевешивают минусы. Так-то, во всех языках есть что-то что раздражает.
Параллельно jvm платформы пилятся kotlin-js (котлин для javascript) и kotlin-native (компилируемый в нативный код котлин), а возможность языка в DSL позволяет писать на HTML и CSS (типобезопасно), если кому-то это надо.
Котлин имеет полный интероп с джавой, от чего его не совсем корректно сравнивать его со scala.
>Хайп:
Язык был подкреплен гуглом в связки мобильной разработки, а с недавних пор рекомендован как основной язык для андроида, из-за чего начался рост популярности языка.
Также для языка был создан фонд, чтобы в случае покупки создателей не повторилась судьба с джавой. Вероятно условия гугла.
В связи с этим, котлин очень популярен в мобильной разработке, порой даже раздражает, что весь свежий контент пишут именно о телефонах. Но нужно помнить, котлин это та же джава и сейчас мы видим, многие фреймворки предлагают решения сразу на двух языках (как минимум пишут примеры, но в целом котлин имеет хороший интероп и так).
>Производительность.
Не забываем, что java (с JIT) одна из самых производительных платформ. Она делит топ 10 наравне с многими другими производительными платформами. Также у джавы хорошо оптимизированный драйвер базы данных, что видно по тестам.
https://www.techempower.com/benchmarks/#section=data-r18&hw=ph&test=query
Нередко именно база-данных является узким местом в веб-приложениях.
>Q: Котлин это что-то про разработку на андроиде?
A: Нет, не только. Объем разработки на JVM высок, но в основном где-то на галерах. Смотрим статистику:
https://www.jetbrains.com/ru-ru/lp/devecosystem-2019/kotlin/
>Q: ...кококо, котлин уничтожит джаву!
A: Нет. Котлин сильно завязан на джаву и не заменяет её, а скорее дополняет (как typescript дополняет javascript). Джаву никто и ничто не заменит в ближайшие 10-15 лет, у этого языка чрезвычайно огромный капитал написанного кода, поэтому переживать за неё не стоит. В любом случае конкуренция это хорошо, джава стала развиваться (попутно завозя годноту в байткод).
>Q: Стоит ли сразу вкатиться в котлин минуя джаву?
A: Нет. Не стоит. Есть точка зрения, что котлин позиционируется как "удобная/лучшая джава", подразумевая то, что ты хочешь писать на джаве, но более современно и практично. Да и глупо игнорировать джавоский мир, который является в топе по числу библиотек и решений, где тебе все равно придется погрузиться когда-то в его синтаксис.
>Q: Но если меня интересует только разработка под андроид, стоит ли вкатываться в джаву?
A: Стоит. Доки старого API на джаве, кодогенерация, байткод близкий к джаве. Ну и легаси, оно тоже на джаве.
>IDE - среда разработки.
Бесплатная community edition - обычно более чем достаточно (и работает шустро), но можете попробовать триал-версию.
https://www.jetbrains.com/idea/download/
>Официальный сайт и там же чтиво
https://kotlinlang.org/docs/reference/
>То же с переводом (на первый взгляд, ру-перевод впервые выглядит не заброшенным):
https://kotlinlang.ru/
>Котлин в примерах
https://play.kotlinlang.org/byExample/overview
>Koans
https://play.kotlinlang.org/koans/overview
>Try Kotlin (пробуй и кодь)
https://try.kotlinlang.org/
>Онлайн компилятор (вставить код или просто что-то потестить)
https://play.kotlinlang.org/
>Awesome (либы близкие к kotlin, но не стоит забывать про java решения)
https://kotlin.link/
или
https://github.com/KotlinBy/awesome-kotlin#libraries-frameworks-web
>kotlin для питонистов [eng]
https://github.com/Khan/kotlin-for-python-developers
>Telegram
В телеге есть чаты по котлину. Это полу-белорусское комьюнити, которое клонирует пачками чаты (раньше про джаву - JavaBy и KotlinBy в Gitter). Крайне не рекомендую посещать это рассадник из ЧСВ макак. В чатах лобызаются одни и те же лица и если ты им не понравишься (а ты им не понравишься) будут постоянно тебя подстрекать пассивной агрессией или принуждать к анальным правилам, которые они вспоминают только тогда, когда пишешь ты. Конечно, ты можешь терпеть и сидеть в этой помойке, но если не хочешь словить негатив и получить ложное представление о ру-комьюнити, не рекомендую посещать этих ребят. Лично видел как токсично слили пчела за расспрос про api java.
Если можешь в ангельский, лучше сразу нырнуть в слаку.
https://kotlinlang.org/community/#kotlin-online-resources
Но лично я рекомендую не заниматься херней в чатиках, а спрашивать сразу на StackOverflow, тем самым ты сразу поможешь тысячи другим пользователям (и себе в будущем, если забудешь):
https://stackoverflow.com/questions/tagged/kotlin
Там можно спрашивать даже банальные вещи (кроме неопределенных), они потом хорошо гугляться и превращаются в простой справочник. Серьезно, анон, прекращайте спрашивать на древних форумах, бестолковых чатах, и даже двачах. Если уж совсем плохо с английским и не можешь в переводчик, то там есть ру-язычная версия сайта, но это так себе идея
>РАЗНОЕ
>Шпаргалка по run, let, apply, also
https://pbs.twimg.com/media/EENzl8CWwAApP3W?format=png
или статья по теме
https://www.rockandnull.com/kotlin-let/
На практике, если точно не уверены, можно просто кликнуть и посмотреть исходник функции (игнорируя там контракты).
>Шпаргалка (общая)
https://simplecheatsheet.com/tag/kotlin-cheat-sheet/
>Контент
https://youtu.be/xH-RZ9YlxH0
Если вам нравится kotlin или java и вы умеете читать документацию сами, то можете просто кидать в тред годный контент, новости и прочее из мира jvm.
>Производительность.
>пишет про производительную жаву
Ну а про что еще писать, не про тормозной котлин с оверхедом по памяти же
Хочу написать свои заметки, которые порвут плеймаркет и принесут мне контракты на миллионы долларов.
> код сложно читать без знания всех тонкостей синтаксиса и семантики
Где-то я уже это слышал.
Потому что динамика. Тащемта, если бы он изначально не тягался со скриптоплеядой, то ни скала, ни котлин были бы нахуй не нужны.
А ещё если бы Одерски не дрочил дотти (скалу 3) 10 лет, то котлин был бы не нужен, а ещё если бы Страуструп не тащил бы полугнилой труп си, то джава была бы нинужна, а ещё если бы авторы джавы не дрочили бы по 5 лет обсуждая нужен ли вывод типов и ничего ли он не сломает — на жвм была бы только жава и даже C# был бы нахуй не нужон, а ещё если бы у бабушки был хуй...
Во-первых, когда её уже азвезли — уже была скала, причём с ещё большим количеством сахара и фич.
Во-вторых, бабушке пришили хуй. Вот блять буквально — у тебя есть выбор юзать нормальный статический язык, или дрочить на тс, временами страдая от того, что кишочки-то из жс, ты что выберешь? Страдать как лошки, пришитые яйцами к жс?
Экстеншен функциями. Зачастую там (в стандартной либе котлине) уже сделали такие фасады, где ты в одной строчке можешь сразу прочитать какой-нибудь каталог и тут же выбрать последнее название по фильтру. Или быстро построчно прочитать файл, через лямбду.
Именно фасады в питоне позволяют писать скрипты быстрее. Но фасады в питоне распространяются только на стандартную либу распространяются. А тут тебе подвластно переделать API любой из областей.
В JS столько тонкостей, особенно в node и его ивент лупе, что знаний (подводных камней) будет сравни С++. Питон тоже не блещет идеальным дизайном, из-за динамики приходится постоянно кодить через гугл. Потому что либо все по другому либо забы сигнатуру функции.
Но будем работать. Вкат близко.
Я имею в виду параллельно с общей информацией учить на примере спринга. Там же и синтаксис можно закрепить и тд.
Типа этого https://coursehunter.net/course/junior-java-razrabotchik-veb-prilozheniy-basejava
>>1750903
Так тебе интересен фронт или веб? Ссылка не о фронте, если что.
>учить на примере спринга
Учить язык по фреймворку - так себе затея, ничего не поймешь, да и костылей, усложняющих понимание, там достаточно. Но попробуй, если хочешь. а лучше не трать время и прочти какой-нибудь head first
Учить сразу кроссбраузерный jquery, вместо стандартного кривого DOM api (которое, напомню зумерам, работало через жопу между браузерами) это тогда еще выглядело вменяемо.
Другое дело зачем они в джаву лезут, когда у них там есть говно-нода с бестолковой асинхронной работой через эвент-луп.
Это равносильно тому, что ты построил будку песику и с таким успехом подался сразу в строители плотники.
>DOM != JS
Вот именно, у тебя в голове все перемешалось. То что ты считаешь жабаскриптом, на самом деле есть DOM API. Нельзя jquery заменить javascript - звучит глупо, да?
>отключать мозг и писать на JS исключительно копипастой из гугла.
Отключать мозг и сидя в комитете делать ебанутый API, который с трудом могли поддерживать браузеры, которые даже этого очень хотели.
Ты еще скажи что CSS весьма удачная и продуманная технология, а не высер людей, которые, наверное, уже лет 30 не писали код.
-Развитие другого поколения либ, больше ориентированных на синтаксис и DSL котлина чем джавы.
-Развитие мультиплатформны, в основном оборачивание сишных либ на манер синтаксиса и DSL котлина (например, как это делают сейчас с игровыми движками).
-Запуск построенной ракета для совместного полета на Альдебаран и создание там дружеского поселения с названием "NewSun Новая Надежда".
-Первая победа над землянами в войне за господством над галактикой.
-Распространение котлина среди жителей галактики Андромеда.
Потому что в котлине куча кейвордов совпадает с идентификаторами из библиотек. is - зарезервированное слово. Да и далеко за примером ходить не надо - на System.in котлин тоже выебнется. Почему? Потому что при парсинге исходника приоритет отдаётся сначала кейвордам, и уж потом - корректным идентификаторам. Ну и такую хуйню можно экранировать с помощью таких кавычек. Интересно, что в таких кавычках можно написать хоть идентификатор с пробелами, и можно объявить переменную с целым предложением в названии - прям как в SQL с двойными кавычками.
Я согласен с тобой, но почти в любом языке есть кейворды, которые никогда нельзя использовать в качестве идентификаторов, хоть по контексту и можно отличить, что есть что. Вообще, в теории котлин не виноват, что в не-котлиновских либах используются зарезервированные слова котлина, но всё-таки одной из целей его создания был нормальный интероп с джавой, а по факту нагородили кучу костылей.
>А написать парсер/лексер отличающий кейворд от метода/проперти
Я думаю это специфика всех компиляторов. Ты же не можешь и в классической джаве кейвордами переменные и методы называть, что тут ты хочешь?
Лучше бы они вместо "in" юзали ":", тут наверное питонодебилами хотели угодить. Что касается is - то обычно такие короткие имена в джава мире как раз не используют и меньше шанс попасть на переменную isinstance.
Какое UB. Что несешь. Сегодня все языки программирования используют контекстно-зависимую грамматику. И не только программирования. И у котлина и у джавы она втом числе тоже контекстно-зависима. Просто при реализации парсера\лексера положили хуй на то, чтобы чекать еще один контекст.
>>1756450
Код разбивается на токены. Из потока токенов строится AST. И во всем этом нет никакой сложности отделять кейворды от доступа к методу.
Он же не пишет на нем, а основатель стартапа.
Ты, надеюсь, различаешь приложения уровня джавы (где ценник соответствующий и требования к спецам), от контентного сайта, аля "визитка", уровня джанги?
Чтобы разрыть глубокую траншею, ты ищешь экскаваторщика, а чтобы посадить розы, тебе хватит и землекопа с лопатой. и вообще, тупо искать землекопа, среди экскаваторщиков
PS: котлин это статически типизированный язык, который стал уже достаточно простым по синтаксису и близким к динамическим языкам, не удивлюсь что в будущем появятся на нем CMS, ну и появиться класс программистов, которые будут на этом писать потому, как типизированная DSL позволяет делать вещи довольно гибкие и мощные вещи для людей, которые могут быть не очень знакомы с программированием. но ты скорее всего очередной залетный зумер и даже не поймешь этот поинт, поэтому, вот тебе мое мнение - коко, пук, пук
Эксперимент оказался не очень удачным, даже дошел до абсурда, когда в динамическом языки завозят хинты типов.
По сути динамические языки должны были стать мета программированием, но в реале они делают шаг назад к типизации, ибо давай по новой, миша, все хуйня!.
Вот только если статические языки можно упростить всякими var, let без потери функциональности, то хинты динамические языках мало того что портят читабельность, так еще и несут порой чисто декоративный характер.
Поэтому если уж и жрать говно, то возьмите хотя бы тайпскрипт. и да, у питухона ебанутые хинты, как всегда гений гвидо издрочился и для декларации нескольких типов придумал какую-то кривую жопу, когда уже существовали нормальные примеры с "палкой"
А в чем проблема то? А в том, что как только начинаешь писать код на динамических языках и выходишь за рамки стандартной упрощенной библиотеки, кода становится так же много как в статик языках. Его реально так же много, та же абстракция, те же слои, тот же легаси, та же энтропия кода.
И если в статическом языке, ты все равно еще прибит палками к типам, к классам и видишь куда что и с чем работает, то в динамическом языке ты начинаешь ходить как по минному полю, постоянно дебажа тонну говна и принтя состояния, или строча страницы документации, как это говно все работает и взаимодействует.
Ты в >>1751525 (OP) хотел запостить?
Что я должен гуглить? Магию в формальном языке? Или наличие сильного ИИ в лексере жс, который сам решает когда ставить точку запятой?
>Лол, ты даже не в курсе?
Я вкурсе, что ты долбоеб, приписывающий высшим силам все тебе непонятное. У тебя и ЭВМ наеврняка работает на Божьей благодати или усилиями эльфов.
Впрочем, нормальные люди на JS писать никогда не будут.
>приписывающий высшим силам все тебе непонятное.
Ты в курсе, что когда бородатые дядьки говорят "магия", они подразумевают UB или плавающую ошибку (что тоже по сути UB)?
>что ты долбоеб
Ты сейчас взял, с проецировал понятия о магии из традиционного мира, как представляешь его ты, на техническую область и оскорбил человека. Но на деле ты оскорбил себя потому, как это твоя проекция слова.
Ты понимаешь всю глубину своей некомпетентности, доходящую до такого абсурда? Ламер
> когда бородатые дядьки говорят "магия", они подразумевают UB или плавающую ошибку (что тоже по сути UB)?
Но ведь так обычно говорят про любое неявное или неочевидное поведение, даже если оно детерминировано и описано в документации. Хотя по сути да, настоящая магия - UB.
UB сишки, тоже в стандарте описано, но это не мешает поджигать пуканы. И никто при этом не кричит, о формальности и что это снова плохие программисты.
Если у тебя взрывается в руках плохо дизайнерская граната, это, конечно виноват солдат, а не то что в гранате не было предусмотрено предохранительного кольца и ударник рандомно срабатывает.
Хватит употреблять идеологию инфоцыган (или евангелистов языка), которые заглаживают неровности языка и спихивают ответственность на пользователя. Их суть впихнуть вам это говно. А вы потом как попугаи бегаете и кричите, что на самом деле язык хороший, это кругом одни плохие программисты.
Естественно со стороны это смотрится полнейшем бредом и естественно надо требовать, чтобы вам давали качественный продукт.
Неопределенное поведение, не является собственностью языка си. Сами UB си это частное в общем понятие. А само понятие распространяется даже до человеческого фактора.
Растаманы взяли и переобули термин под свои нужны, изнасиловав вам мозги, ибо надо было создать антагониста в лице С++ и похер, что у них там у сами херова туча сишных UB получилось, главное выдрессировать попугаев
>Неопределенное поведение, не является собственностью языка си. Сами UB си это частное в общем понятие. А само понятие распространяется даже до человеческого фактора.
Вся проблема С в том что он пытается быть системным языком при том что вся системщина там основана на UB начиная с "ну мы все понимаем, что число в указателе - это адрес в оперативке посему можно присваивать указателю целые числа".
https://www.youtube.com/watch?v=LJvEIjRBSDA
В создание языков, есть два типа людей, те которые видят в своем языке холст для творчества. И те кто хотя сделать инструмент для работы, чтобы практично и меньше мест где можно отстрелить себе яйца.
Написания языка, это натягивание технически-сложной совы, на глобус реальности. Только творческие гении делают это в пользу своего виденья мира и порой делают какие-то свое решения, то инженерные люди, делает максимально удобно для работы.
Является ли котлин таким инженерным языком? Частично, с большой натяжкой? да (могли бы и лучше). Но вот все остальные jvm языки (и некоторые llvm, лол), это просто реализации потребности тех или иных людей.
Я тоже хочу написать свой язык и мне как-то даже глубоко срать насколько он будет для вас удобен, я художник, я так вижу. Мне, ущербу, хоть как-то получиться в историю попасть.
Но, в этом абстрактном и философском говне, которое я на тебя высрал, есть определенные факты. Это то, что java и jvm - мощнейшая платформа и что котлин дает возможность писать поверх этого всего, при этом больше не писать на самой джаве кто 10 лет на ней писал, меня поймут.
https://soundcloud.com/podlodka/podlodka-167-kompilyatory
>кто 10 лет на ней писал, меня поймут.
Пишу больше 10 лет и не испытываю такого батхерта сейчас 50% кода у меня Джава, 50% Котлин.
Да Котлин местами поприятней, но не прям радикально. Особенно когда у тебя IDE которая умееет хорошо рефакторить и генерить код.
Когда пишешь на одной только джаве, то можно вообще никуда даже не смотреть, а шутить о том, какой кобол уродливый и что он стане никому ненужен. Но когда пощупал другие языки, то джава превращается в тыкву.
А когда пощупал ромбовидное наследование и то как рукожоно это реализовал Гвидо, начинаешь любить даже джаваскрипт
>Но когда пощупал другие языки, то джава превращается в тыкву.
Я "щупал" достаточно языков, поэтому прекрасно понимаю что везде свои компромиссы. Где-то многословность - тот же го по многословности перегонит джаву. Где-то перебор с сахаром - типа С# или питона где 100500 способов сделать одно и то же. Где-то мудреные концепции в которые надо постоянно держать в голове - типа раста или эликсира.
Поэтому-то я и отношусь спокойно к джаве - да не идеальный язык, зато много разных библиотек и фреймворков на все случаи жизни и хороший тулинг.
>многословность
Очень скользкий сейчас термин, изначально имелось ввиду, что для решения той или иной задачи требуется дернуть не мало объектов (например чтобы построчно файл прочитать). То есть, говорилось про объектный бойлерплейт, если ставить рядом с питоном, где стандартная библиотека местами покрытая удобными фасадами для новичков.
Сейчас под термином многословностью некоторые понимают "длинные" имена объектов или классов.
Го - эталон по бойлерплейту. Мне кажется, надо очень любить процедурное программирование, чтобы терпеть его.
C# - по сахару норм, но с решением о кроссплатформенности они опоздали лет на 10-15. Сейчас его синтаксис и сахар кажется устаревшими, даже ts кажется моднее и молодежнее.
Иногда спрашиваю джавистов и мне кажется котлин продолжает делать ряд ошибок, с моей точки зрения. У них котлин всегда что-то типа "норм, но не вау", то есть могло быть и лучше. И в этом и беда, котлин не стал завоевывать рынок бэкенда джавистов, как-то вяло и поздно стали пилить ktor, да и вообще могли бы полностью сделать фокус на либ-тулинг, у вас же там крутая DSL есть, простор для творчества. Но нет, понесло на эту мультиплатформу.
>как-то вяло и поздно стали пилить ktor
Мы как раз его используем - и самый его большой косяк для нас это отсутствие возможности как-то генерировать API spec.
Вот есть например Swagger - который при желании можно и к существующему API на базе Spring прикрутить и получить нормальное описание API которое можно отдать кому-то. А нам приходится на конфлюенсе API описывать.
>>1762943
Речь идет о бойлерплейт в первую очередь. Недостаток удобный утилити методов в стандартной библиотеке компенсируется апачем и гуавой StringUtils - хит всех времен и народов.
дальше можно смело учить котлин, прекрасный и изумительный язык, который убьет мерзкую жабу
JS - это язык огрызок, язык имитация, который тормозит даже в переборе DOM дерева. Еще немного и в веб ассембли завезут нормальные визуальные движки и про твой html, кривой css и убогий js забудут навсегда.
Про бэкенд я вообще молчу, даже жопаскрипт не заслужил такого говна как нода. Вроде как, даже сам автор признался в этом.
Котлин (и не только он, но всем насрать) дарит тебе возможность пилить веб на одном языке, в одном большом мульти-проекте, без компиляции жопаскрипта в жопоскрипт.
А если включить немного фантазии, то можно вообще пилить такие CMS системы, с такими возможностями плагино-писания, от которых будут шевелиться волосы на лобке!
Не обязательно на русском же. Но многих это оттолкнёт, да.
>>1763186
Бекграунд бывает разный, здесь я подразумеваю, когда при изучении нового языка уже не сидишь неделями с книжками, а можешь открыть официальный мануал, почитать чуток и уже через несколько дней писать почти так же, как на предыдущих языках.
>Не обязательно на русском же.
Да ну на каком еще? Как будто выучить английский, это как в магазин сходить. Понятно, что до уровня владения языком, когда читается так же комфортно как на родном, уйдет тонна человеко-ресурсов.
Если у меня от английского языка не пухла бы голова, я бы на ру борде и не сидел.
>уже зная инглиш на среднем уровне
В том то и дело, что его знать надо не на среднем уровне, а на уровне родного, так как материал и так сложный.
Это инфоцыгане на уровне "хи-хи, ха-ха" говорят что надо знать английский и переменные обзывать правильно, но это потом, сначала купите курс. А на деле, на английском тут все абсолютно.
Все это маня фантазии, типа "о, я хочу изучать программирование", но сначала я подтяну английский и математику. Не, реальность она другая, люди с разным уровнем владения и с разными плагинами переводчика в браузере, пытаются жрать этот кусок непосильного гранита, как бы кому не хотелось. И популярность обуславливается именно доступностью обучающего материала на родных языках (как минимум по началу). И только ленивое некомпетентное сообщество говорит, мол незачем переводить, читайте на английском.
ОФФТОП: в свое время на пхп форумах был популярен вопрос, какой движок выбрать для сайта, и очень частый ответ был - лучший движок, это тот который написал сам (самописный). И эти все местные высокомерные бараны лайкали такие ответы, мол, да, верно. Но представляешь как это соотносится к человеку, который только что сел изучать разработку и ищет лучший вариант для изучения, с тем чтобы сесть и написать свою CMS. Это абсурд (и некомпетентность комьюнити). Забавно, что полный перевод пхп либы появился тогда, когда сам пхп стал уже и не нужен (а на тот момент перевод даже был на бразильском диалекте).
Собственно, такой же абсурд, как на ру говорящих форумах, чатах или бордах, отправлять чела читать на английском и у этих людей даже не возникает вопроса, какого хера они тут на родном пиздят.
Ну не, не как родной. Сухие технические термины, которые один раз запомнил, и потом почти всё понятно, даже легче газет всяких читается, где все выёбываются знанием кучи книжных слов. Впрочем, от материала зависит, какой-нибудь Страуструп и на родном языке очень тяжело воспринимается.
Выжить как-то можно, но оч тяжко.
У нас с восприятием все нормально. Мы понимаем, что если ты пишешь публичное или доступное широкому кругу API у тебя должен быть способ адекватно это API описать.
Сейчас стандарт это OpenAPI (Swagger) и GraphQL. Swagger легко привязывается к любым JAX-RS сервисам будь то Spring или JEE. А вот ktor - хер и альтернатив они не предоставляют. Ебитесь с конфлюенсом или чем хотите.
Двоякое чувство осталось. Понятно что это врапперы и просто демонстрация DSL, но вот реального преимущество статической типизации я так и не почувствовал. А любой шаблонизатор типа pug вообще ложит всю эту конструкцию на лопатки.
У меня еще случился момент, когда чересчур умная идея, как-то прилепила не туда фигурную скобку и отформатировала код, и я понял, что случилось это в проекте с 100500 тегами, я бы больше офигел на моменте, где куда и что. похлеще чем когда потерял закрывающийся тег
Что касется css, так сейчас любая IDE поставляет и подсвечивает слова, писать сырой css получается даже быстрее и удобнее.
В общем, мне показалась эта фича как-то притянута за уши.
Уже написали https://spring.io/guides/gs/async-method/
Подскажите аналогичную и не такую требовательную иде для разработки приложений на андроид (язык, понятное дело, котлин)
https://github.com/TechEmpower/FrameworkBenchmarks/blob/ead55b0e33274a8e7cbdff39f7911da42eeaff09/frameworks/Dart/start/server.dart#L132
Только это говно спрятали в js под асинк/авейт, эти наоборот достали.
https://dart.dev/guides/language/evolution#dart-27
Как бы и интероп с джавой нахер не нужен. Ну, то есть, гордиться тем что можешь взять тырпрайзные либи, или что язык мог пофиксить костыли джавы, которых нет в других языках - такое себе.
А вот AOT компиляция, это уже интересно. я, конечно, понимаю что VM и число библиотек там в стабильном палеозое, но за то язык с чистого языка, а не прокси
Но ведь котлин как раз и создавался как сахарок для джавы, чтобы все эти тырпрайзные либы было не так больно юзать. И всё. Если котлин показался тебе одним из хипстерских язычков-убийц жс, которые просто в силу хипстерскости должны пытаться запускаться в браузере, то это не так.
Жава говно
Дарт гавно
Гавно гавно
Вам двачерам вообще угодить реально?
Возможно котлин достиг своего максимума?
Еще один вечный соискатель в петухоне?
Понимаешь, любой проект рано или поздно превращается в сложную херню. И нет больше языков и тулинга, которые помогут тебе в этом говне разобраться, чем есть в жабе.
Да, на петухоне или js ты быстро стартуешь и быстро получаешь результат.
На жабе ты едешь дальше и дольше.
И не потому что жаба хорошая, а просто нет альтернатив.
С++ и всякие ржавые языки, вообще не пригодны для тяжелой бизнес-логики. Ты с языком будешь бороться больше.
С# - да кому нужен вендор лок??
Го - да кому нужна кривая обертка над си, в которой нет даже стектрейса. Ты представляешь как большое приложение без стектрейса отлаживать? Или как писать гибкое приложение без дженериков? Блин, да там даже нельзя бесплатно получить букву в слове надо конвертить в руны, если ты не счастливый обладатель англ. языка
Нету больше кручи и мощнее чем джава, нет более удобнее и современная вариация чем котлин.
На пыхе есть symfony и zend/laminas, они серьезные и жабаподобные. А вот на питоне и жс как будто вообще нет ничего железобетонного энтерпрайзного, сплошная какая-то хуйня для заказного аутсорс клепания сайтов, или более узконаправленные легковесные микрофреймворки в которых только роутинг да обертка над реквестом и респонсом
Да, так и есть.
В реале, пхп в свое время дорос до таких размеров, что там стали писать сложную тырпразную херню. На это все и появились такие монстры как symfony и zend итд.
Сами поддерживали такую сложную херню и открывали для себя разные словечки из джавы.
Просто спорящие все время говорят о разном, кто-то говорит о уровне когда правда проще прям в контроле влезть в базу и скинуть данные во вьюху (привет джангошлёпы!). А у кого уже такой проект, когда необходимо разделить на сервисы и DAO.
Хуле тут так мало
https://hyperskill.org/knowledge-map/73
Хуле тут так много
https://www.youtube.com/channel/UCA7ymlAF32Up8VKeDVv9uQw/videos
Сейчас бы дебажить спринг. Вот он момент, когда фреймврорк послал тебя нахуй, а ты даже не можешь сорцы открыть и прочитать что там происходит потому что сорцы такого абстрактного говна как спринг не читаемы вообще.
И мне постоянно говорят, нафиг тебе исходники фреймворков читать. А вот чтобы понять что я буду делать в такой ситуации.
Хз, написано что вечно хостят, кину в шапку.
https://ibb.co/yRSzLsS
https://ibb.co/dB2m4nN
https://ibb.co/McTbJk0
> kotlin
Васянская обёртка над языком.
Дарт говно, но позволяет сразу пилить под ios+android.
То есть котлин это такой выбор для тех, кто создательно хочет работать на кого-то, вместо запуска своих проектов.
успел прочитать это - `Head First Kotlin 2020 Griffits Devid, Griffits Don`
и пощупать пару курсов на юдеми - поковырял котлин с джавой. кстати, какое же гавно эти виджеты и лэйауты андроид студии, ощущаешь себя дауном, перетаскивая компоненты мышкой и натягивая стрелочки для позиционирования виджетов, фотошоп какой то, я бы долго не выдержал такой хуйни
в общем, язык кайфовый, гибкий, можно писать ФП, можно ООП, все есть- перегрузки, полиморфизм, инкапсуляции и прочие абстрактные классы, каеф. к сожалению дальше погружаться не получится, буду искать работу по основному направлению- JS макакинг
всем удачи в освоении Котлина, замечательный язык, может еще удастся на нем пописать в будущем
>основной десктоп проект достиг пика и появилась возможность перекатиться в андроид разраба, предложили самостоятельно обучиться, но через 3 недели после трансфера на новый проект, они поняли, что легче найти готового mobile дева(а может уже нашли) за те же деньги чем платить мне 2к$ в месяц за вкатывание в мобильную разработку, поэтому попросили покинуть стартап
Вот это я понимаю, социально-ответственное поведение.
Хоть выходное пособие дали? Или попросили по собственному, а ты и проглотил?
оплатили время потраченное на учебу- 2 недели в полном размере, а оставшиеся до конца месяца часы будут оплачивать на 50%, но мне один хуй делать нечего, я чисто формально в конторе, типа отрабатываю последние 2 недели, все таски закрыты уже давно
>а ты и проглотил
а ты бы истерику устроил? там это никого не ебет, работаю по контракту на американский стартап- решили расторгнуть и расторгли. следующее место конечно буду искать с официальным трудоустройством, после такого то удара в псину
Имеется несколько подтипов sealed класса с разными типами данных внутри. Можно ли как-то с контрактами реализовать такую функцию чтобы внутри массива таких объектов происходил первого, который имеет конкретный подтип, причем чтобы функция возвращала уже скастованный объект?
val somevar = array.first { it is SomeSealedChildClass }
somevar имеет тип SomeSealedChildClass
Надо установить Android Studio (это такая бесплатная IDE для разработки под операционную систему Android). Запустить, создать проект, и там будет редактор форм, просто перетаскивай мышкой виджеты на форму, пиши обработчики, и всё.
Но судя по твоему вопросу, лучше для начала взять какую-нибудь книжку по основам Java страниц так на 1000 и прочитать её.
https://pastebin.com/z1QrYKML
нет ошибок, просто зависание. Убрал эту функцию, написал лог в onCompletion и поставил туда брейкпоинт. В итоге результат считается нормально, но в брейкпоинт не заходит, т.е. этот метод не вызывается. Похоже на что-то такое https://stackoverflow.com/questions/39909996/spring-deferredresult-oncompletion-not-called-from-test-cases
на то что у меня на скриншоте красным подсвечено - не смотрите, я там в процессе отладки скрин делал.
Хз, не спрингую.
На практике, если платят хорошо, то нужно сорцы фреймворка изучить. Но по опыту, лучше мега фреймворки не брать.
Потому как микрофреймворки не мешают, а мегафреймворки не дотягивают до плагинный возможностей какой-нибудь CMS, где можно сотню плагинов повесить и будет работать как часы.
О, неожиданно, стали пилить на нескольких языках.
https://blog.jetbrains.com/ru/kotlin/2020/08/kotlin-1-4-released-with-a-focus-on-quality-and-performance/
Какая тут логика вообще? Ты создаешь объект File, а потом хочешь добавить еще путь и создать новый, а потом еще?
Ты наркоман?
Вот, наверное, что ты хотел.
https://pl.kotl.in/aUatd7e8T
Как вы достали уже.
Тебе себе или работу найти? Если работу найти, смотри что требуют. Напиши парсер который собирает все данные с хаха.ру и сделай рейтинг востребованного стека.
Вот тебе первое задание.
Если для себя, то какой тебе понравится. Но опять же, кому-то нравится спринг и MVC, кому нравится микро-веб-сервера.
Кто-то хочет контролить каждое движение, кому-то нравится добавить аннотацию чтобы вся магия заработала.
Какой ты у нас сегодня?
>не оформится как полноценный язык с собственной инфраструктурой
Зачем? Ну, круто там всякие SQL писать на DSL, но надо понимать что такое котлин и что ему особо не нужно заново изобретать то, что всех и так устраивает.
А вот на нейтив, я думаю, будут врапперы писать и может даже что-то интересное увидим. Но бэкенд на нейтиве писать не будут.
>5-7 лет на джаве, можно было сладко перекатиться на котлин
Толстота то какая. Перекатился на котлин, где-то за выходные.
Сейчас тонна материала на английском по котлину, на ютубе конвеером просто контент снимают. Если человек усердный и хорошо плавает в ангельском, то смело вкатится в котлин без жабы.
Статика вообще позволяет изучать материал по докам на API
Да, но хипсторки почему-то считают микрофреймворки преимуществом, а не недостатком. Проект разрастается, эволюционирует, и получается изобретённый заново кривой и нестабильный клон спринга. У питонщиков тоже так - не хочу жирный монолит джангу, хочу боттле и фласк, чтобы потом устанавливать 20 плагинов для них и ебаться о связыванием этого всего вместе.
Ещё и реклама всех этих микрофреймворков - смотрите, у нас роуты компактнее. Будто роуты пишутся не 1% времени написания проекта, а 50.
Андроид тред дохлый, поэтому спрашиваю тут.
Есть задача - отслеживать все нотификации в бекграунде. Есть NotificationListenerService. На чем его запускать? Стандартный Service или же WorkManager? Также какие есть решения для длительных бекграунд процессов? Может что-то из корутин или RX?
FirebaseJobDispatcher, GcmNetworkManager, Job Scheduler уже рекомендуют заменять на WorkManager.
Хз че там у вас, но логика простая, отвечу в стиле мейл-ру.
Есть событие? Вешай на событие.
Есть йоба сервис которые дергает сервисы - вешай на него.
Есть аналог крона? Вешай сервис на крон.
Есть поток? Крути сервис в отдельном поток.
Все крутится в корутинах? Крути в корутине.
Rx - выкинь каку, люди от скуки всякую хуйню придумывают.
Просто посмотрите на его сигнатуру и класс Ordering
Это же пиздец
Я знаю, что публиковать приватные методы, это плохо и все такое. Но мне нужно для тестов чтобы API не ломать, как того навязывают юнит тесты. И да, я знаю что и для тестов этого делать не нужно, но опять же, юнит тесты навязывают дробление, а у меня красивое API, так что правило идет лесом
Хз, мы от мокания отказались, у нас интеграционные тесты, а в юнит тестах тестим только чистые функции
Посмотри тут, если тебе там что-то не понравилось.
https://kotlin.link/
>Оказывается сложную функцию нужно декомпозировать
Хуя ты разбежался. Как ты собрался декомпозировать инлайн функции?
>Пиздуй создавать экстеншен для Method который проверяет соответствие аргументов
Лол, мастер дизайна АПИ
val user = User()
User::calc.callPrivateFunc(user, 1, 3)
Вместо
user.callPrivateFunc("calc", 1, 3)
Ни чего что задача может требовать объявление функции динамически?? Если трогаешь рефлексию, будь добр чтобы это была рефлексия, а не говнокаша из статики и динамики.
Если тебе надо их тестить, то делай их публичными, и не выебывайся
Хуйня вбитая в неокрепшую голову.
Если по дизайну это должно быть скрыто, то некуй это публиковать или куда страшнее разносить по 100500 мелким классов.
Ты писал свой класс, ты имеешь право знать его приватное состояние, насколько оно соответствует твоим ожиданием на публичного взаимодействие API. Надо быть отбитым дебилом, чтобы не получит такое преимущество над своим кодом.
Тесты не должны ничего навязывать, тесты не должны менять дизайн программы. Это, блядь, тесты.
Как всегда есть публичные API, которое упрощенно и внутренние промежуточные алгоритмы (методы).
Алгоритмы эти, это чистые функции. Нет ничего подходящего, как тестировать чистые функции в юнит тестах.
Почему я должен себе в этом отказывать? Я не хочу в публичных функциях обертках дублировать тесты, потому что они очень обобщают.
Android/Kotlin/wasm на фронте
Linux - Kotlin - Spring - Postgres в тылу
Для этого его и точят.
Проблема в том что во всем этом ты будешь первопроходцем. То есть, наверняка уже есть какие-то обертки там на реакты, хуякты. Но тогда нахуя оно надо? Это как надевать сразу два гандона. Понятно, что круче будет, когда кто-то за нас напишет свои ui-hui фрейворки, без потребности нюхать js, хоть в js это будет собираться под капотом.
Котлин позволяет делать полностью плагиную систему, добавил, скажем, джарник с функционалом комментов, дал ему настройки - куда себя вставить и какой роут юзать и вуаля у тебя сразу система комментариев готова, с работой бд, с антиспамом.
Осталось только эту плагинную систему написать, ну ты понял.
допустим у меня есть сырцы одного приложния мне нужно чтобы приложения автомато запускало файл который я добовлю в исходники как это мне сделать
Официальный сайт?
Шапка треда?
>Котлин в примерах
https://play.kotlinlang.org/byExample/overview
>Koans
https://play.kotlinlang.org/koans/overview
>Try Kotlin (пробуй и кодь)
https://try.kotlinlang.org/
>Knowledge map
https://hyperskill.org/knowledge-map/209
Любая книга.
https://www.youtube.com/watch?v=iASKk2eqRoE&t=3s
Говнище полное.
Если пишешь на котлине реализацию джавового интерфейса, ты не можешь использовать нормальные джава-коллекции, только т.н. "mapped types". То есть если есть метод, в котором аргумент имеет тип java.util.Map, в котлине надо использовать MutableMap, а не
java.util.Map.
В итоге ты в принципе не можешь написать код без использования stdlib, пиздец нахуй.
Каким надо быть долбоёбом чтобы сделать такое уебанство?
> ты можешь использовать kotlin.collections.MutableMap
Он тянет зависимость от kotlin-stdlib, которая мне не нужна и вообще в проекте никак не используется.
> что тебе мешает написать интерфейс на джаве и спокойно использовать его в котлине?
Перечитай ещё раз. Я и пытаюсь в котлине написать реализацию интерфейса, определенного в джаве.
смоделировал эту ситуацию. действительно тупая хуйня, но ты долбоеб.
>Вопрос был не "зачем", а "как"
ты такой тупой чел, с такими пуками можно вообще что угодно говорить. пиши на питончике без стдлибы питончика, там же это наверняка можно, или нет? блять, точно. это же на любом языке невозможно, но ты, дебил, решил до этого доебаться=)
Да, только всрато.
https://kotlinlang.org/docs/reference/collections-overview.html
https://discuss.kotlinlang.org/t/a-hashmap-is-not-a-map/504/4
согласен, что выглядит всрато, только твой доеб еще более всратый. ты доебался не до странного поведения, а до невозможности написания кода без стдлибы, две разные вещи.
бтв я уверен что в жб не глупые люди сидят и с этого есть какие-то профиты. и в целом мне похуй на эту всратость, если бы мне нужно было реализовать джава-интерфейс, я бы использовал джаву.
Спасибо. Нашёл ещё https://kotlinlang.org/docs/reference/java-interop.html#mapped-types , оказывается, java.util.Map в джаве - не то же самое, что java.util.Map в котлине. Буду внимательнее читать доку.
>>1798921
> https://discuss.kotlinlang.org/t/a-hashmap-is-not-a-map/504/4
Спасибо.
Я не я, я просто мимо проходил.
JB всю свою историю клепала IDE, в которых конечно есть своя сложность, но фактически это просто текстовый редактор + несколько матановых алгоритмов, чтобы гуй не так тормозил на IDE-специфичном функционале все равно тормозит.
А вот опыта разработки языков программирования у JB нет, как и специалистов по PLT или теории типов. Были пацаны из Nemerle, которые пилили какую-то меташтуку, но Котлин проектировали не они.
В итоге получилось то, что получилось - кривоватый сахар поверх жавы, в котором
val m: java.util.Map<String, Any> = java.util.HashMap<String, Any>()
не компилится.
Будем честны - если бы не форс со стороны гугла, эта поделка нахер бы никому не вперлась.
Твоя проблема в том, что ты пытаешься бороться с языком, используя его на юз-кейзах, для которых он не предназначен, вместо того чтобы наслаждаться им, используя там, для чего он был задуман. В результате страдаешь сам, и исходишь на говно в этом ИТТ треде совершенно необоснованно, что не будет встречено пониманием среди местных ценителей.
В частности:
- ты пытаешься использовать тип java.util.Map. В котлине не нужно использовать этот тип. Он специально сделан неполноценным, чтобы настучать по пальцам таким долбоебам как ты. Вместо этого нужно использовать тип kotlin.collections.Map или MutableMap, который существует только в компайл-тайме, а на ран-тайме представлен старым добрым java.util.Map.
- ты пытаешься использовать язык без зависимости на стандартную библиотеку. Это обречено на фейл. Даже если ты чудом обойдешь стороной типы и функции оттуда, что уже сделает твой экспириенс работы с котлином весьма неприятным, компилятор все равно вставит обращения к этой библиотеке для компиляции языковых конструкций: корутины, рейнджи, callable references, да даже банальные автоматические проверки аргументов на налл в начале публичных методов и те требуют вызова интринсик-функции из рантайма.
Тебе необходимо принять, что для работы с котлином нужна стандартная библиотека, и дальше уже дейстовавать ситуации.
Но для этого нужно понять, что у тебя за ситуация? Почему ты всеми правдами и неправдами пытаешься избавиться от этой зависимости?
>Не просто абстрактную IDE, а в частности intellij idea
и не только идея, а еще куча ахуенных айдиишек, которые предоставляют фишки конкретно под язык. пытался недавно перейти на емакс для разработки на питончике, т.к. функционал ide мне не нужен, но оказалось так, что там столько ебли с настройкой того, что в любой intellij-based ide идет из коробки.
>так захотели дизайнеры языка
Это нихуя не объяснение. У тебя или нормальный язык, где есть четкое обоснование почему это не валидный код, со ссылками на спецификацию языка.
Или смузи из говна для хипстоты - в этом случае, можно и сказать "так захотели дизайнеры языка".
abreslav
JetBrains Team
Aug '14
Some explanation is available here: http://blog.jetbrains.com/kotlin/2012/09/kotlin-m3-is-out/ 578
In short, Java’s Map is mutable, and in Kotlin we replace it with a pair of interfaces (read-only) Map and MutableMap to facilitate better type safety. If these extended Java’s Map, they’d have to be mutable as well.
Да вот ничего это не объясняет.
Есть тип kotlin.Map, есть kotlin.MutableMap, есть java.util.Map и java.util.HashMap их все реализует. Причем первые два через магию компилятора, а не реализацию, а вот последний имплементит через декларацию, все как положено. Но почему-то приведение не работает. Причем не работает и для List и других коллекций.
val list: java.util.List<String> = java.util.Arrays.asList("abc", "def")
Тут он явно говорит, что asList() - возвращает MutableList и ниибет! Но это только для коллекций, для других типов все ОК.
val date: java.util.Date = java.sql.Timestamp(0)
Просто кое-кто увлекся своим йоба компилятором и забил на классическое наследование.
> ограничивает программиста, проталкивая свою идеологию.
Так делают все языки
Строго типизированные не позволяют сохранять в одной переменной разные типы
Джава заставляет обрабатывать чекед эксепшенс (хоть и признали что это был обсер)
Котлин запрещает использовать джавовую мапу т.к. разделил коллекции на мутабельные/иммутабельные
Он еще "ограничивает программиста" Заставляя на null все проверять, с этого у тебя жепа не горит случайно?
> запрещает использовать джавовую мапу т.к. разделил коллекции на мутабельные/иммутабельные
Звучит как буллшит.
Разделил - ну ок.
Почему я не могу использовать джавовую мапу как мутабельную? Чем MutableMap безопаснее чем java.util.Map? Ничем, просто Бреславу так захотелось.
Только недавно словил тупой и редких баг, где классическую мапу, которая по логике не должна быть мутированной, изменяли в говнокоде, очередным дауном, что приводило к плавающей ошибке дальше по логике.
Когда код спасает от очередного гения, это достойный код. Для всего остального есть скала.
Потому что нужно чтобы мутабельная мапа наследовалась от иммутабельной
Мы не можем прописать в джавовой Java.util.Map новый супер-интерфейс, поэтому все равно бы имели дело с mapping types
А раз так, лучше сделать шаг в сторону явного определения мутабельности и иммутабедьности по-умолчанию, чтобы поощрять функциональный стиль.
Отсюда названия Map + MutableMap а не ImmutableMap + Map
> нужно чтобы мутабельная мапа наследовалась от иммутабельной
То есть метод ожидает, что ему дадут иммутабельную мапу, а пользователь подсунет мутабельную и сломает инварианты.
Либо ты сам не понимаешь как это работает, либо это совсем пиздец в дизайне языка.
> То есть метод ожидает, что ему дадут иммутабельную мапу, а пользователь подсунет мутабельную и сломает инварианты.
Че?
Не совсем понял в чем проблема
Метод принимает обычную иммутабельную мапу, это говорит о том, что он ее не будет изменять, все
Это же обычное проявление полиморфизма, что должно сломаться, если передать хоть сотый подкласс от типа, который метод ожидает?
Ты про канкарренси проблемы, что ли?
Ты верно объясняешь суть, но путаешь иммутабельные коллекции с рид-онли коллекциями. В котлине интерфейсы List, Set, Map - это именно рид-онли коллекции. Их можно читать и нельзя изменять через эти интерфейсы. Но это не запрещает фактической реализации быть изменяемой.
Их реализации могут быть как иммутабельными, т.е. не меняющимися ни при каких обстоятельствах, так и мутабельными, как стандартные MutableList/Set/Map.
После змеек в Питоне, чот лайауты всякие, вот это все, среда разработки прямо как унреал енджин но нужна много всего чеееееее сложна сложна сложна
Я совершенно не ньюфаня, просто предоставляется возможность полностью погрузиться в одну из платформ, но внятной и глубокой информации по этому выбору нет (везде что-то поверхностное).
Есть у кого интересные мысли по поводу той или иной технологии, любое мнение будет полезно.
Нельзя делать два проекта одновременно.
Придется дернуть и собрать в maven jar-ник один проект и после этого только запустить второй.
А теперь представь что у тебя таких проектов и модулей штук 15.
В нормальном мире, градл бы мог собирать один независимый проект, потом магически подключать к другому и так далее. Но в реале тебя сразу пошлют нахер на ошибки типа - два плагина котлина подключить нельзя или прочее ошибки.
Другое, что меня сильно напугало, это, условно, юношеский максимализм и попытка захватить все платформы. Парни около 5 лет релизили прокси язык и тут же замахнулись на все что можно.
>>1813062
В чем проблема-то? Если в родительском проекте не подключать всем подпроектам плагин Котлина, то никаких конфликтов не будет.
https://github.com/breskeby/gradle-snippets/tree/master/multiparallel
В джаве, походу, плохо понимают что такое модули.
Проблема в том что модуль 1 полностью независимый, и ничего не знает про внешний мир, модуль 2, в свою очередь, может подключить модуль 1, при этом не внося никаких изменений в модуль 1
И казалось бы, ну сделай модуль 1 подпроектом для 2? Да? Но блин модуль 1 он же модуль и его возможно захочет проект 3,4,5...
>>1813775
Чел, у тебя или полная каша в голове или проблемы с выражением своих мыслей.
При чем тут вообще джава? Мы же про грейдл говорим и я использую проект в том смысле в котором его использует грейдл.
Если проекты независимые, то никаких
>его возможно захочет проект 3,4,5...
быть не может. Иначе они уже зависимые. Если зависимые, можно или на уровне зависимостей на проекта project(":lib") или бинарно, через публикацию атефактов в мавен репозиторий.
Мимикрок.
На мой взгляд котлин удобнее питона, в плане короткописания, если освоить и применять все его нюансы.
Из недостатков, конечно, хотелось бы какой-то интерпритатор (но со статик типами это бестолково), и такие тулзы как gradle или избыточные некоторые либы джавы, портят вкат людям, даже владеющими языками.
А, ну еще просраны короткие записи листов [], мап {k:v}.
Просто та лямбд, вроде с одной стороны круто, но с другой каждый выпук пишут на лямбдах. А чем плохи лямбды? В отличие от методов, которые понимаешь по названиями и описанию, лямбды это чистые кишки кода, в которые надо каждый раз погружаться.
На мой взгляд питон удобнее (именно для мелкоскриптов, которые лень долго писать), и дело не столько в синтаксических фичах, сколько во времени, которое пройдёт до получения результата. На питоне открыл терминал, запустил вим, написал 10 строчек, сохранил, запустил, по необходимости что-то доустановив и нащупав с помощью dir() и help() нужные функции/методы. А на котлине пока запустишь IDE и создашь проект, пока укажешь все зависимости в помнике или build.gradle, уже и забудешь, зачем всё это затеял.
Использовал одну IDE для котлина и для питона. В край я js в vs code запускал, для юзер-скриптов в браузере, это прям одномоментные почти однострочные скрипты. А вот гуманитарные программисты самоутверждающиеся за счет вима, это вообще отдельная тема, даже не хочу это трогать, уже не 2007 год, хватит этим страдать.
Что насчет подключение зависимостей, когда у тебя 10 строк то, это какой-то перебор в файле или подобное, все из стандартной библиотеки хватает. В любом случае самое понятие "скрипты" дебильное, чтобы не плодить говна по десяткам машин, так или иначе приходится писать полноценную утилитку, чтобы потом понять что это такое вообще.
С питоном вообще беда, пока ты в стандартной библиотеке все хорошо, но как только подтащил зависимость начинает пляс с этим requirement.txt, приходилось инсталятор небольшой писать, чтобы у знакомого запустился код, без страданий. Скрипт для скрипта, это предел моих впечатлений, даже в js грамотнее сделали, хотя node.js тот еще кусок говна.
Пора уже признать, что питон это натянутая сова убого дизайна, на глобус реальности. Не все там гладко, как хотелось бы, убогость дизайна и тонна отсебятины в api каждый блядский раз приходится гуглить какие-то моменты, потому что соизволили сделать именно так, а не как у всех. Собственно, эта херня ставит крест на языке, как об карманном инструменте.
Ну и динамико-дрисня, опечатался в одну букву - "веселой тебе отладки, мудила".
а разобраться в устройстве питона нельзя было? вот просто основы понять и все.
в итоге там основы + модули и все.
шикарнейший скриптовый язык
конечно тяжко пилить что-то огромное, но это проблема всех динамических языков.
>>1817158
>пляс с этим requirement.txt
Если очень не хотелось чтобы конечный пользователь ставил сам модули, ну так положи их рядом и все.
А еще вообще всю утилиту можно в зип упаковать.
И при желании вообще мог бы распространять как пакет и при его установке зависимости бы подтянулись
в общем все как обычно - выбирай любой из вариантов.
Пытался вникнуть в это все, понял что какие-то костыли поверх костылей и тупо переписал на шарфик, юзеру даже не пришлось ставить никаких йоба типа интерпретатора или виртуальной машины.
Но что касается котлина, то там тоже просто, юзер клацает на jar как на exe и все работает (винда так умеет)
>юзер клацает на jar как на exe и все работает (винда так умеет)
иии... ничего на винде не произойдет ибо жава по умолчанию не установлена. А если установлена то можно клацать на jar, а если установлен питон, то можно на py
>Пытался вникнуть в это все, понял что какие-то костыли поверх костылей
значит не пытался. там самый обычный подход с менеджером пакетов. Такое везде. Подходы одинаковые, проблемы одинаковые.
просто в динамических языках менее привычно делать портабельные вещи, но нет никаких проблем их сделать. Принцип их работы такой же как и везде - нужные либы просто лежат рядом