Kotlin — статически типизированный, объектно-ориентированный язык программирования, работающий поверх Java Virtual Machine и разрабатываемый компанией JetBrains. Язык назван в честь российского острова Котлин в Финском заливе, на котором расположен город Кронштадт.
Маскот котлина Коди.
Что имеем:
+Современный синтаксис (реально удобный).
+Совместимость со всей jvm инфраструктурой.
+Возможность писать статический DSL прямо на самом языке.
+Дополнительные возможности котлина. (делегаты, функции, расширения класса, вариативность и т.д)
+Возможность нативной сборки, сборки в js, андроид и ios.
+Корутины
Для тех, кто переходит из процедурных языков программирования, объектно-ориентированный подход (ООП) может показаться полной ерундой.
В интернете часто приводят какие-то высосанные из пальца примеры с кошками, собаками и всякой абстракщиной. Но в реальной жизни все не так просто, и эти детсадовские примеры ни о чем не говорят. Когда ты только начинаешь изучать ООП, то сложно понять, зачем вообще городить эту огромную телегу с классами, наследованием, инкапсуляцией и прочими заморочками.
Поэтому лучший способ въехать в ООП - это сразу погрузиться в изучение какого-нибудь фреймворка. Когда ты видишь, как все это применяется на практике, то сразу начинаешь понимать суть.
Почему следует изучить java перед котлин, а не сразу изучать котлин:
1.Java основа: Без знания java ты не будешь понимать, что происходит под капотом kotlin. Синтаксический сахар kotlin скрывает сложные операции, и ты можешь понять конечный результат, но не механизм его достижения. Это как нажимать кнопку на чайнике и видеть, что вода нагревается, но не знать, почему и как это происходит. Лучше всего понять что под сахаром это в intellij перейти tools -> kotlin -> show kotlin bytecode -> decompile.
2.Код на Java: Большинство библиотек написано на java. Без знания java ты не сможешь понять их код и, соответственно, эффективно использовать или модифицировать их в своих проектах на Kotlin.
3.Может быть что где-то будут куски кода на java в проекте.
Антивирус в windows также замедляет компиляцию, так что отключите, добавьте в исключения папку или же перейдите на gnu/linux, macOS:
https://intellij-support.jetbrains.com/hc/en-us/articles/360006298560-Antivirus-Impact-on-Build-Speed
Попробовать котлин -> https://try.kotlinlang.org/
IDE. IntelliJ IDEA Community Edition -> https://www.jetbrains.com/idea/download/
Документация котлин -> https://kotlinlang.org/docs/home.html
Перевод документации -> https://kotlinlang.ru/docs/kotlin-doc.html
Скачать Kodee asset ->
https://kotlinlang.org/docs/kotlin-brand-assets.html#kotlin-user-group-brand-assets
Предыдущий тред: >>3105288 (OP)
>+Современный синтаксис (реально удобный).
>+Совместимость со всей jvm инфраструктурой.
>+Возможность писать статический DSL прямо на самом языке.
>+Удобные лямбды и наличие простых функции.
>+Удобный тулинг в том числе и на бесплатной IDE (комьюнити версии)
>+Возможность нативной сборки, сборки в js, андроид и ios.
>+Корутины
+Вендорлок от жыдбрейнс
+Работает поверх джавы, можно легко пересесть с игрушечного языка на нормальный
Даже ионку не поставил новую, тупо скопипастил с преведущего треда.
Картинку поменяли — игрушечный тормозной язык с уродливым синтаксисом не стал нормальным быстрым языком с OG синтаксисом.
Вот общался с 5 собеседующими. 4 из них спрашивали по многопоточке. Спрашиваю, а вы в работали с многопоточкой на практике? Все 4 отвечают - нет, никогда. В анкетах перед собесами тоже спрашивают про многопоточку наравне с микросервисами - работали ли вы.
Сейчас вот перед еще несколькими грядущими собесами вспоминаю что раньше читал по многопоточке и новое узнаю.
Но есть ощущение, что это просто ради собеса. Даже бесполезнее в реальной работе, чем с литкодами.
Раньше было желание прочитать книгу с поездами и добить какими то главами из более свежих книг, чтобы преисполниться. А теперь кажется, что чисто голову себе забью и забуду что-то полезное.
>Почему джавист плачет за маской
Это котлинодебил нацепил маску своего сахара поверх джавы
Но ведь на картинке на человечке который надел маску и плачет лого джавы, получается это джавист
>Но на картинке джавист притворяется котлом
Вот, начинает доходить потихоньку. Вы по сути те же джависты, только синтаксический сахар поверх прикрутили, гордо именуя крутым языком, волосы покрасили и тыквенный раф пить начали, но основная суть не изменилась
Ну и в чём минусы быть джавистом? Квартальная премия в кошелёк не помещается разве что...
Реально, какого хуя лого старое, ОП-хуй
> джавистом
Джавистом — ни в чём. Петухлинщиком — зашквар.
Хояешь чтобы си++ и си# начали обоссывать джаву в вашем треде? Ну как в старые добрые. Нет? Съебал с треда
> обоссывать джаву в вашем треде
Пока что у вас удаётся только себе на рыло ссать.
Но ведь ты сам сказал что петухлинщики это те же джависты
> Джавистом — ни в чём.
Ок, для тупоголового тебя скажу по другому, "полноценным джавистом — ни в чём".
Эта боевая картиночка обязательно ускорит петухлин в 11 раз и даст ему хороший синтаксис.
Как раз один и есть... и скорость как у джавы потому что рантайм тот же. Лучшее из обоих миров
>fun fun fun : Zalupa
Не расслышал хорошего синтаксиса.
> и скорость как у джавы потому что рантайм тот же
Ну да, там где петухлин своё не навешивает. А как навешивает так в 11 раз скорость сразу падает.
Настолько сильная депрессия от жабы и проектов на ней, что он бегает по тредам c# и kotlin и пытается убедить себя в том, что его жизнь - это не только боль и страдания, но и благой труд, ведь он - самый настоящий ООП Программист с большой П.
Покормите бедного)
Жава - лучший язык, в тыщу раз быстрее котлина и c#, у неё самый понятный синтаксис, и это лучший язык для тырпрайз разработки.
Не оставим же кабан кабаныча не довольным, жаву в массы! Каждому ребенку по жабе.
Если тебе так плохо, стань тимлидом, чтоб кода меньше писать
>Квартальная премия в кошелёк не помещается разве что...
За 10 лет гребли ни разу не платили премию, ни квартальную ни годовую. За 10 лет вышел на баснословные 200к. Начинал вообще с 15к на руки..
Тут на выбор, что хочешь, то и бери:
Сумин на юдеми
Котлин в действии 2 изд.
Neco RU (ютуб)
Philipp lackner (ютуб, у него старые видосы, но вполне пойдет для основ. Там уже навернешь что-то новее в виде доков или же предложений иде по коду)
if Nahuy.tak!.jiit!.posonii? != nil:
self.kak_vse_zaebalo()
Краткий экскурс.
Анончик, спасибо. А Котлин в действие разве не для джавистов придумали?
>Ну и в чём минусы быть джавистом?
Кроме того что пердишь в стул загнивая в банке с древним спрингом, надрачивая абстрактные фабрики бинов синглтонов, минусов нет.
А вот котлинодебилы пытаются выебнутся мол смотри какие мы сурьёзные типа джависты и в пизду и в красную армию, а на деле кроме мобилок этот язык никому не всрался.Да и то гугл все больше дарт продвигает, а хуявей вообще свой язык пилит
Да как по мне - для всех.
Ты же с джавы перекатываешься? Так ведь...?
Ниразу не питон, как свифт, только для линукс/андроид платформ.
Кидайте новости и контент, аноны, безработных вкатунов на шарпах не кормите. после того как жаба получила свои, по сути, модные шарпы, с синтаксисом на порядок круче, у них какая-то истерика пошла, хотя мы не пересекаемся вообще. Если, конечно, не начнут пердолить игры на котлине, а они должны начаться, ибо удобно для анроида пилить на одном стеке, а не древнем NET Framework 4.
Ты с 2022 капчуешь, дед? Все новомодные зумерки с подворотами и п
увольнением в 1 день уже давно используют korge.
Если ты реально дед (лет 25+), то есь lwjgl, как во времена майнкрафта альфы.
https://korge.org/
Кстати, уже вышел багфикс k2 и он стал более менее юзабельным, как и k/native. Скоро хочу попробовать интегрировать под компоуз мультиплатформу нативные плееры видео и аудио т.к. неудобно писать разный код под разные платформы
Для пердолинга в игрульки нужна полноценная 3D студия, а не xml обертка над идеей.
На самом деле там же просто скриптинг, и думаю, плагины для котлина есть и на юнити и на godot. Но кому это нужно? Если индюшки привыкли в свой вариант доисторического шарпа долбиться.
Для телеграма легко, а вот с дискордом лучше не стоит связываться.
Ответ на твой вопрос: нет, котлин для вката крайне простой, особенно если у тебя идея (иде) т.к. у нее есть автоперевод джава кода в читаемый котлин код. Практика неплохая, как понимание котлина в целом.
P.s. если нет либы под телегу на mvnrepository.com , то попробуй сам написать взаимодействие с помощью retrofit, а вот ktor не бери как клиент. Он еще недоработан нормально, в прошлых тредах отписывал проблемы и прочие неприятные вещи с ним
Ну, пик достижений телеграм ботов это питоновские библиотеки. Вообще сетевой стэк на яве/котлинге костыльный. Если на питоне достаточно сделать объект request и назначить ему строковые проперти, то в с котлином еще придется поебаться, начиная с процесса билда реквеста, заканчивая тем, что некоторые проперти это объекты, которые хуево задокументированы (кукисы). И даже если захочешь есть кактус, то в какой-то момент обнаружишь, что разрабы сесевых библиотек котлина начнали ежегодный рефакторинг кодовой базы.
> И даже если захочешь есть кактус, то в какой-то момент обнаружишь, что разрабы сесевых библиотек котлина начали ежегодный рефакторинг кодовой базы.
ДВАЧУЮ ДВАЖДЫ
Надеюсь, что они всё таки исправят свою говнолибу Exposed. Половину данных не модифицирует правильно, другую половину просто не оборачивает в единую транзацкию и иди ищи как вернуть всё назад
>Kotlin — статически типизированный, объектно-ориентиро...
Холд он, фэкбоиии! Кому всрался твой котел? С ним наигрались даже бигтехи за последние несколько лет и те попытки стартовать проекты на нем по типу домклика - провалились. Сейчас все переписывают на свежую джэву, т.к. новые фитчи катят каждые полгода. Сейчас бы ебаться с котлом и годами искать разрабов, которые умеют в идиоматичный котел, когда джаваскуфидонов как говна за баней, лол
>Кому всрался твой котел
Как минимум всем android разрабам
Вот совпал хэшкод у ключа, добавили элемент в бакет(в связный список(в ноду)).
Потом запросили значение по ключу, в бакете проходим по нодам и ищем ноду, в которой ключ будет equals нашему ключу. Но разве equals не сравнивает хэшкод просто? А хэш код двух ключей совпадает, значит и equals будет true для двух разных key у двух разных нод, то есть значение неверное может вернуться.
Объясните смузихлёбу
> на свежую джэву, т.к. новые фитчи катят каждые полгода
Всё что катит джава котлин подсасовает
Котлин для вката простой, особенно с IDE, которая переводит Java-код в Kotlin. Практика неплохая для понимания Kotlin. Если нет библиотеки для Telegram на mvnrepository.com, попробуй написать взаимодействие с помощью Retrofit, но не используй Ktor как клиент, он еще недоработан.
у меня вообще противоположная ситуация. после котлина никак не хочется на джаву возвращаться
Смотрю на котлин как на "сишарп" для джавы. Хера вы там сами с собой воюете я не понимаю, малолетние дегроды, вы одну инфраструктуру юзаете и если надо сможете откатиться взад в свою жабу и снова писать свои точки с запятой.
Да забей, тут походу половина людей считаетю что разраб = привязан к одному языку и к одному направлению
Мы вот перешли в мобилке. Вопросы?
На рыночке почему-то почти все требуют опыт в одном конкретном языке
Долбаебы наверное или у нас настолько много разрабов, что можно просить и язык и опыт в сфере просить
Вчера отказался от либы Coil для подсоса картинок. После перехода с 2 на 3 версию появились новые баги, а фич так и не завезли. Разраб почти важные issues на гитхабе закрывает с плашкой not planned, либо пишет что у него ничего не лагает, и вообще пусть сами пул реквесты делают раз такие умные. Взял более старую либу Glide, и у меня бувально все рендерится в 2 раза быстрее, появился нормальный error handling, с докой нет проблем. Тока надо Glide внутри AndroidView вызвать, и все будет по красоте.
Никакие. Они все говно на котлин и на андроид. Пизжу готовый код даже не со стака, а с реддита. Там почему-то более толковый код пишут лол. Гуглолахта засрала почти все сайты с туториалами по компоузу и андроид разработке.
У жидбрейнса такие себе описания корутин, которые придется изучать месяца два чтобы что-то понимать. Ну и Флоу не очень прозрачные. Остальной язык за 2 дня выучишь.
Ну а по андроиду я приведу хуевую анологию (других не существует, ну да ладно): гугл утверждает что в любой бочке с медом есть говно гугла, и не поев его меда не попробуешь. На деле оказывается можно отодвинуть говно ложкой в сторону и сразу начать есть мед, хотя на ложке и будет специфичный привкус. В общем у следующих методичкам рот в говне, а у хитрых в меде.
>Гуглолахта засрала почти все сайты с туториалами по компоузу
Терпи
Ну по факту гугл не самое лучшее советует. Поменял котлиновский Coil на явовский Glide. Корутины юзаю часто, но все чаще возникают мысли что я просто бездарно проебал месяц жизни на них, и хочется их вырезать из кода к хуям. Обычные ява треды оказались крайне простыми в освоении, и без ебанутых подводных камней.
>Coil на явовский Glide
У коила и glide алгоритмы разные. Но мне тоже glide чуть больше нравится, более плавно грузит множество картинок. На композе Coil юзаю, у него альтернатив нет нормальных для композа, работает стабильно, но для android view выбрал бы glide.
>хочется их вырезать из кода к хуям
>Обычные ява треды
Ты работал с большими проектами? Корутины не только для выполнения на фоновом потоке, но и для удобного свича между пулами потоков, и конечно для реактивного программирования с использованием flow.
С обычными тредами будет так называемый callback hell, судя по всему ты не сталкивался с объемным кодом на залупотредах а может ты бэкендер и у тебя меньше проблем с этим было
>без ебанутых подводных камней
К сожалению правда, у корутин подводных хватает, но сталкиваться с ними ты будешь никогда редко. Разве что для собесов полезно знать.
пысы: композ действительно будущее, но сейчас много готовых проектов на android view, так что если хочешь быстрее найти работу - android view твой выбор, даже не пробуй композ, а то потом не захочешь к view возвращаться никогда в жизни.
пысы2: Самое хуевое что советует гугл - это стандартная навигация. Никто блять не использует стандартную навигацию, все юзают сторонние либы или свою пишут
>корутин подводных хватает,
Можешь, пожалуйста, подсказать в чем они проявляются. Работаю год на бекэ Котлин и пока всё нормально.
>На композе Coil юзаю, у него альтернатив нет нормальных для композа, работает стабильно, но для android view выбрал бы glide.
Я просто положил AndroidView+Glide внутрь LazyVerticalGrid шириной 1 и кайфую. Лучше LazyColumn в плане производительности. Почему-то нигде не видел такое решение в Интернете.
>Ты работал с большими проектами?
Нет. Пишу тонкий клиент для склада. Списки бывают большими порой. Обычно в элементе списка содержится штук 6 текстовых полей со всякой поеботой типо артикулей и кол-вом и фото на складе. Когда картинки гружу, то создаю треды, а когда получаю ответы запросов, то жду корутины. Я хз где нужны пулы тредов кроме донатных казичей с жопастыми тетями. Флоу оказались непростыми, но смысл в них есть. Прада есть чувство что как только их полностью освою, их выбросят на мороз.
>пысы2: Самое хуевое что советует гугл - это стандартная навигация. Никто блять не использует стандартную навигацию, все юзают сторонние либы или свою пишут
У меня навигация построена на лямбде when(Singletone.screenValue) -> "1" {fun Screen1()}. Очень тупо, но читабельность кода хорошая.
>Работаю год на бекэ Котлин
О, прикольно. Я думал тут только из-за andoid сидят. Как вкатился, проект с жабы переписывали, или новый просто?
>подсказать в чем они проявляются
В не интуитивном сложном поведении. Вот примеры всяких приколов
https://youtu.be/Qj_vTsN_4uo
какие подводные?
>AndroidView+Glide внутрь LazyVerticalGrid шириной 1 и кайфую. Лучше LazyColumn
Ниче не понял, LazyVerticalGrid вместо LazyColumn?
Я проверял, самый плавный список будет либо полностью на android view и xml, либо полностью на композе. Мб ты ошибся где-то просто, с Coil + compose не должно быть проблем. Если список способен меняться, надо указывать key для item. Так же важно заранее указывать размер каждого элемента в Lazy списке.
>when(Singletone.screenValue) -> "1" {fun Screen1()}.
Это в принципе и есть основа любой навигации. Есть стэк навигации, ты в зависимости от экрана в этом стэке показываешь определенный экран.
Только там дофига деталей ещё добавляется, типа вложенных стэков, жизненный цикл прикрученный к каждому стэку и экрану, анимации перехода, и т.д.
>какие подводные?
Ебанутые требования к вкатунам, 0 вакансий джунов, необходимость иметь минимум год коммерческого опыта, может и накрученного.
Не знаю зачем тебе из плюсов в android, когда ты можешь в бэк пойти
Да, с джавы переписывали, устроился в компанию и они как раз стали переписывать все сервисы. За видео спасибо.
>LazyVerticalGrid вместо LazyColumn?
Да, так. Мне дали тз на пробу рисовать по 300+ айтемов списка (в каждом пикча). Ленивые колоны разочаровали потому что данные не выгружаются из памяти, и начинается упор в память (тестировал на 600+ пикч) вплоть до вызова GC. Вертикальный грид рисует то же самое, но без утечки памяти.
Странно, ну да ладно. У коил есть настройки для кэширования на диске ещё.
А для больших списков я бы юзал пагинацию
Да любой, что угодно только не андроид.
Я бы после плюсов пытался вкатиться в go/c#, а может и то и другое. У нас вот часть на c# часть на go как раз написана
Нейминг пиздец. Ты хотя бы по ебалу дай патору этого высера.
Так, я хоть что то смог понять, но не уверен, опчик:
Во 1. WrapRow конвертит из модели дб в котлин объект и гдето там хз где сохраняет.
Во 2. Почему 5 селектов? Эта ормка очень сломанная и впринципе на ней нельзя писать еще. Она мне недавно базу данных поломала тем, что все данные обновила, хотя был запрос на upsert.
В 3. Он оборачивает старые запросы (branch) в котлин объекты, кидает в кеш, а потом еще новые оборачивает в котлин объекты, потом кидает из хз_какой_тип в list, а потом еще мапает в хз что это просто.
ПС. Есть лучшая альтернатива и не баганная - ktorm
>На композе Coil юзаю, у него альтернатив нет нормальных
Я обнаружил что есть класс GlideImage, интеграция Glide для компоуза. Синтаксис как у койла. Работает идеально, хоть и числится в альфе. Так понимаю, то что что у явы альфой называют, у котлина это стейбл.
Кстати сравнил okhttp3-5.0.0альфа14 и apache httpserver-5.3.1. Оба примерно одинаково сделаны, но апач стабильный, охуенно задокументированный, и побогаче на фичи. В общем okhttp был бы годнотой, если бы разрабы пидорасы не переписывали библиотеку каждый год. Буквально каждая библиотека котлина, сделаная как замена явовской, это образцовый анала-гов-нет. Апач мне больше всего зашел из http либ на андроид. Зря его гугл в петушиный угол записали. Не их, вот и бесятся.
>Работает идеально, хоть и числится в альфе
Ты про эту залупу которая v1.что-то там alpha?
Я её пробовал, подходит только для самых примитивных кейсов.
Мало гибкости, api нищее.
А если попробовать сделать что-то чуть сложнее простого отображения без placeholder-а и индикатора загрузки, то всё сломается нахуй например анимации.
Они забили на поддержку композа, эта срань уже несколько лет в альфе. Я смирился, что их либа только для android view
Вспомнил, я когда-то пытался запихнуть в LazyVerticalStaggeredGrid с Adaptive элементами этот GlideImage, так у меня просто ебать экран зависал при скролле, просто не работала прокрутка с этой либой
Ну конкретно GlideImage альфа в LazyVerticalGrid у меня работает плавно.
>если попробовать сделать что-то чуть сложнее простого отображения без placeholder-а и индикатора загрузки, то всё сломается нахуй например анимации
Для анимаций в мобилках придумали flutter, а компоузеры все копротивляются. Не ешь каку.
Шиз, спок. У композа супер гибкое api для анимаций, в том числе доступно нативное api, работать будет плавнее.
Кроссплатформа - кал, у кабан кабаныча уже были проблемы, так что делим на платформы
Да я там пиздец разбор полетов устроил, я в ахуе. У чела 4 года стажа. И самое забавное что меня наняли на поддержку его кода, КОТОЫРЙ ОН СУКА ПО ПРЕЖНЕМУ ПИШЕТ БЛЯТЬ АААААААААААААААААААААААААААААААААА
Да, я уже это понял. На проекте древняя версия и там кэширование моделей не работает. Начиная с 0.30.1 это пофиксили , но на проекте 0.17.1 и малой кровью там не переедешь, а контора не хочет платить за рефактор.
1) Coil и GlideImage работают почему-то абсолютно одинаково, но все-же более лагуче чем связка AndroidView+Glide. И в эту связку легко встроить событие нажатия на картинку. У кого одинаково работает - возьмите андроид со старым железом.
2) Okhttp все-еще жалкий форк apache httpclient. Сейчас обосную. Качал картинки через okhttp, а они бьются блять. Оказалось что если сервер далеко (проход через прокси в соседнюю сетку с nginx'ом в роли финального босса), то стрим (байты) шлется как несколько пакетов с паузами. Okhttp закрывает соединение сразу после первого пакета. Так и не смог найти в доках как заставить клиент читать из стрима больше одного раза. А apache из коробки спокойно ждет до таймаута, и собирает поток полностью в целостный файл, и это все на дефолтных настройках без танцев с бубном.
Админам локалхоста, у которых на диване нет проблем с okhttp, советую как-нибудь сходить на работу.
заебись вы там копиума навернули, ваяете свою пагинацию. нахуа? в хибере есть готовый класс для этой хуйни
Invalid resource ID 0x00000000.
2024-09-10 20:13:11.436 20724-20724 AndroidRuntime
Ну они же нихуя не информативные, покажи блядь какой ты ресурс сука подгрузить не можешь пидорас ебаный.
С нуллом это вообще пиздец, нигде блядь его проверить нельзя если ставить ебучие !!, хуйня ебаная
>Invalid resource ID 0x00000000.
>AndroidRuntime
>покажи блядь какой ты ресурс сука подгрузить не можешь пидорас ебаный.
Ну так это дегенераты на разрабах андроида, и им некогда фиксить ошибки пока они на переставленных кроватях ебутся с новыми никому не нужными фичами. Лучше бы в жепы ебались просто. Еще вместо колонки юмора можешь почитать про то как они до ART вообще сидели на форке виртуалки явы 8 с библиотеками из явы 6 (dalvik). Потом давлика назвали ART, и напиздел что это другая виртуалка но мы-то знаем. Короче создатели андроида никогда нормальный код в жизни не идели, и даже не подозревают какую шляпу они пишут.
Нет, не сильно волновало. Большинство ошибок на бекэ ты не исправишь, остаётся только наверх их выкидывать.
Чтобы bad response отдать? В спринге и так можно прописать хорошие фильтры, которые всю чушь будут ловить.
собираюсь начать с Atomic Kotlin, но смущает что она про версию 1.5. Смогу ли потом наверстать упущенное, и если да, то подскажите последующие книги для освоения новых версий
Kotlin in action 2
Дальше просто смотрим видосы про котлин у philipp lackner'а и читаем доки на сайте котлина
>philipp lackner
Он из гуглолахты, так что научит только оверхеднутое говно по методичке писать. Учитесь снимать психологические блоки и читать про котлин+компоуз из нормальных источников: личных блогов, релиз ноутов, презентаций конференций (мобиус).
Так там почти ничего сложного нет.
Если прям с самого нуля и вообще ты хлебушек - head first kotlin и потом kotlin in action 2 >>3270475
Ну если судить по старым докам, то там работает так:
Копируют массив, который ты меняешь-> применяют к каждому элементу твой модификатор (фильтр, мапа, еще что) -> выходит массив
С секьюенс
Берут первый элемент -> модификатор -> в массив (если прошел), и так далее
А, ну потом отфильтрованный массив возвращают тебе, как мапа через .asSeq
Вот смотрю видео с примером Snackbar в компоуз. И там viewModelScope отравляет объект в Channel, а где то там уже в своем корутиноскоупе делается collect и выгребается.
Так вот этот объект содержит лямбду, по факту калбэк. И вот она вызывается после показа snackbar как .invoke() - и она выполняется почему то на первоначальном viewModelScope
где об этом почитать про захвата вот так первоначального скоупа метода что куда то передается?
и, собственно, как передать метод чтобы ничего не захватилось?
Я поймал ошибку, связанную с конфликтом K2 и Kapt и у меня даунгрейднулась версия котлина до 1.9 :D
Поподробнее плиз. Типа указана версия 2.0, но факту другая?
Выкинулась ошибка, ты снова тыкнул билд, и заработало само?
Указана версия:
2.0.10 (котлин)
2.0.10 (капт)
2.51 (dagger hilt)
При билде, выходит варнинг (примерно такой), но все равно билдится проект (hello world, без кода вообще): Kotlin 2 doesnt support KAPT, falling to kotlin 1.9 (непонятно какой версии именно, просто 1.9)
Ошибки или вылетов при синхронизации/сборке не было, просто белый текст варнинга. Думаю, если использовать фичу из kotlin 2 и словить баг с kapt (что он не поддерживается якобы), то билд зафелится т.к. используется совсем другой компилятор у kotlin 1.9
Это очередная суходрочка чтобы 2Ггц проца на андроиде схавать и заставить лагать. Ебанешься разбираться как там пидоры все переусложнили. Даже не пытайся. Просто объявляй в одном месте remember SnackbarHostState и SnackbarHost. Потом отсюда можешь в любую фунцию передать аргумент remember SnackbarHostState и менять его снизу (bidirectional flow чистой воды).
Хуе-мое, проще кодом объяснить.
@Composable
fun MainMenu() {
val state = remember { SnackbarHostState() }
val scope = ???
val host = { SnackbarHost(state) }
InvokeMessage(state)
}
@Comosable
fun InvokeMessage(state: ???) {
GlobalScope.launch {
state.showSnackbar("MESSAGE")
}
}
Мобилки. Ну и для рабов явы придумали аттракцион с переводом кода с явы на котлин, но это больше фан чем что-то продуктивное главное чтобы начальник не понял что мы переставляем кровати.
>Даже не пытайся
Не не. Я это и хочу понять. У меня нет проблем показа снэкбара.
Я хочу понять механизм кто в чем выполняется.
Я понимаю что suspend функция выполняется в скоупе для этого есть всякие там launch/async. Но тут ключевое "выполняется".
А получается, что даже просто определенные лямбды уже знают про скоуп.
То есть если если 1000 скоупов положат лямбды в единый список, и 600 помрет, а потом единый скоуп (пусть будет GlobalScope.launch) пройдет по этому списку и выполнит .invoke() у каждой, то будет выполнено 400 что ли?
А если я хочу выполнить все же 1000?
вот это я хочу понять. А снэкбар просто пример где я увидел то, что не ожидал.
Есть разные скоупы под разные задачи. В принципе в большинстве случаев можно пользоваться любым, но главные разичия таковые:
- ГлобалСкоуп, текущий тред, который спокойно обработает 1 задачу. Его даже вызывать не надо, он уже существует в рантайме
- КорутинСкоуп, работает до первой ошибки в корутинах
- СупервайзорСкоуп, выполняет все корутины даже если была ошибка
Плюс есть диспатчеры в корутинах, но это уже тонкий тюнинг заметный если упираешься в потолок производительности.
Так что если качаешь пачками пикчи, то через Супервайзор, если корутины зависят друг от друга то в обычном скоупе. Ну и глобальный когда надо буквально 1 операцию сделать в композабле с околонулевым потреблением ресурсов (создание скоупа тоже расходует ресурсы, и проще отдать в глобальный).
>определенные лямбды уже знают про скоуп
Это тебе надо к документации компилятора обращаться по теме strong skipping. В К2 дефолтный механизм с лямбдами немного изменился. Читая статьи по скиппингу ты найдешь много ключевых слов по своему вопросу.
спасибо ChatGPT за подробный, но абсолютно бесполезный ответ)
>>3274541
>strong skipping
гугл ведет в strong skipping для compose.
ну а вообще вот
https://youtu.be/KFazs62lIkE?t=999
Он пуляет в Channel из viewModelScope, а в глобальном контексте собирает из этого канала и показывает снэкбар, а если там есть каллбек, то его вызывает. И вот тут спорный момент
перевожу с буржуйского - "если вы запустите первый снекбар (с калбэком), а затем уйдете с экрана то viewModelScope будет очищен и вы не сможете запустить ничего с ним и поэтому калбек не будет выполнен (и это желаемое поведение)"
Я качнул репу с уроком по ссылке под видео. и не нашел ничего умнее чем вставить print($this) в скоупах и увидел что у них разные айди и пошел сюда спрашивать "это что за магия" - почему this и контекст каллбэка такой же как изначальный у viewModelScope? Разве калбэк не выполняется в том скоупе куда его передали и в итоге вызвали?
isActive при этом почему то всегда false
Но самое главное - я вызвал в его коде снэкбар и ушел с экрана (конечно создав при этом доп экран чтобы с него можно было уйти тупо нажав назад) и калбэк выполнился. Да, он говорит что viewModelScope Cancelled, но он все равно выполняется
Что противоречит челу в видео.
И я окончательно запутался.
compose тут не причем. Можно сделать и без композе и все равно калбэк выполнится. Тогда о чем глаголит этот чел?
(ну и попутно "что вообще происходит. почему в калбэке isActive = false)
Посмотри, может isActive это проперти унаследованная от предка, которая просто не используется
На котлине вообще разрабатывают бекенд? Или 99% работы это андроид?
Странно, я смотрю вакансии и почти всё это мобильная разработка. Я просто хочу перейти из одного стека в другой, опыт в бекенде 6 лет, выбираю между C#, Go и Java/Kotlin. Синтаксис котлина крайне приятен, но хочется уверенности в том, что будет не слишком сложно искать работу.
Работы мало, джава со своими виртуальными потоками поднасрала котлину
Но виртуальные потоки доступны так же из котлина.
>>3276731
Я бы выбирал котлин, только если он реально зашел тебе, а остальные прям нет.
А так, я чаще всего вижу бэк на c#, java и go.
И да, котлин чаще всего используют именно для мобильной разработки. Если только вкатываешься в язык, то как будто трудно найти вакансию котлин бэкендера без опыта. Хотя можешь попробовать, если ты бывший джавист, т.к. джаву иногда переписывают на котлин, ну или вместе используют.
Какой у тебя стэк то был?
Бывших php-шников принимают на golang вакансии, например.
Я бы попробовал в go вкатиться
Писал бекенд на ноде 6 лет, последние несколько месяцев на го. Го не сильно понравился, а вот тайпскрипт обожаю, и котлин на него сильно похож, при этом нет дурацких ограничений дырявого, медленного и одноногого рантайма. Серьёзные большие проекты редко делают на ноде/тайпскрипте, так что нужен и язык посерьёзнее.
Вкатывайся, думаю бэк на спринге 50/50 пишут, но легаси бэк это ток джава. И большинство вакансий так или иначе требуют джаву. Но не всё так плохо, ты можешь свои модули для легаси писать на котлине, по любому будут микроспрвисы которые будешь писать с нуля со свободой выбора. Учите Котлин, но знайте джаву
Видимо, по мнению "старших" из ютуба. Чушпанов же не слушают, а там тебе всегда пояснят за язык и как if и while правильно на ровном языке написать.
Самое смешное, какие бы новые технологии джава не реализовывало раз в 10-15 лет в своем JVM, все это будет доступно и в котлине.
О чем ты вообще?
Серьёзный язык это когда разработка крупных серьёзных проектов на этом языке — обычное дело
Сейчас на языке хер-нейм напишут круд-микросервис, выпустят статью, что мы переписали с жопа-нейм на хер-нейм ради пиара. И ты "впечатлительный" поверишь в серьезность языка.
В крупных и серьезных проектах не хватает крупных и серьезных спецов, именно поэтому зачастую в крупных компаниях зоопарк из языков, зачастую даже круды на кривом жопоскрипте пишут. Вот такая там реальность, а не как ты нафантазировал себе, авторитетозависимый.
Мне не нужны стать чтобы во что-то верить, я знаю какие языки фактически массово используют в крупных проектах
Сейчас массово используют го в микросервисах (и жс, куда его можно засунуть).
Если бы ты действительно что-то знал, то в этом треде не сидел бы.
Я это знаю. Про жс ты не прав, его в крупных проектах используют, и в монолитах, и в микросервисах, но не массово. Го используют вполне массово, особенно в постсоветском пространстве.
Соя в комментах насрала.
А вообще парень прав, язык красивый и удобный, но ровно до тех пор, пока не пишешь критически важное. Тут и начинаются танцы с бубнами по типу "вы руззкий, активацию/оплату не дадим" или более потребление памяти из-за оверхедов. Ну и idea - параша, которая ломается время от времени просто потому-что может
Завязка на идею + блядский градл это ред флаги из-за которых никто их моих знакомых не захотел пробовать котлин. Вот так и проебали jb server-side гошникам.
Двачую, грэдл убивал вкатунов возможно вообще вся старая жабья тырпрайз инфраструктура и убила котлин.
>server-side гошникам.
Обмазался шарпами, доволен как слон. Да, синтаксис, конечно, не такой молодежный, как у котлин, но если ты писал годами на джаве/пхп это прям сказка. В целом, от изобилия возможностей, я прям балдею.
Понятно, что все упирается в работу, но рекомендую потыкать, хотя бы в юнити поковырять вечерами свою инди-перделку. Веб и мобилки уже осточертели.
А еще не совсем понимаю kmp и вообще этот нейтив и компиляцию в жс. Выглядит как мечты студентов захватить весь мир. В итоге нигде не приуспели.
Понятно что основная идея охватить максимум рынка и продать больше ide, но увы vsc код наступает на пятки.
Кстати нейтив была бы неплохая идея для бекенда и возможно взлетела, если бы они были более открытими, более документарованными и у котлина был бы свой lsp от разработчиков языка. Считай бинарник без виртуальной машины, еще и с нормальным синтаксисом. Жадность фраера сгубила хули, плюс из-за того что ими иде пользуются по всему миру, то решили что могут делать все что хотят, охуевая больше чем майкрософт.
Вообще если сейчас выпустить условную гошку под капотом с ООП синтаксисом по типу котлина или тайпскрипта, где не нужно писать бойлерплейт, только чуть упростить чтобы было понятно для всех и повысить скорость компиляции, например от части сахара избавится. Ну и реализовать как-то метапрограммирование, например как атрибуты макросы в расте, которые в компайлтайме генерируют код и выглядят как привычне всем аннотации/декраторы. Чтобы было открыто, хорошо документаровано, а не как в котлине "Я у соседа спрошу", ставилось одной командой apt install zver-language или запуском zver_language.exe для ущербных, работал бы lsp сервер чтобы можно было работать от вима до идеи, ну и все остальное из коробки как в той же гошке.
Это вообще сразу взлетит на мой взгляд.
У зига интересная кодогенирация и никаких макросов, макросы это на самом деле зло. Но доков там не будет, да и это системщина (альтернатива си). Хорошая дока это только мейнстрим языках. Можешь потыкать aot в шарпах, хз насколько там рефлексия работает в aot, но зато макросах потребности нет.
А вообще оптимизации у jit сильнее чем достижимо в aot.
сейчас прибегут фанбои, но ложи болт, будь полиглотом
Книжка по зигу https://pedropark99.github.io/zig-book/
мимо
https://www.youtube.com/watch?v=sS3pW1frcEg
https://www.youtube.com/watch?v=c8hZFtl8EuQ
https://www.youtube.com/watch?v=HAJO9MuV2F8&
Кликбейт название всего лишь, нафиг такое скидывать вообще
Так васм входит в kmp по идее, не?
Хотя получается они делали компиляцию в js и прочее, а теперь достаточно только добавить компиляцию wasm, и он уже разберется дальше сам.
Я думаю котлин только выиграет, будут брать язык для wasm, на котором максимально удобно писать. Дарт офк не выберут, предпочтут котлин и верстку на нем. Какие ещё удобные языки есть из современных? Питон - это гадость. Swift только на ум приходит
Я бы сюда добавил еще то что все крутится вокруг жабы, в итоге пишут на спрингоговне, всякие JPA, все вот эти вот аннотации, конфиги в особо клинических случаях xml
Вот это прям пиздец отвращение вызывает, я готов смириться с некоторым вендорлоком от жыдбрейнс если будут слишком много борзеть то на крайняк появится форк но вот то что придется погружаться в это ынтерпрайз болото нет
Принеси вакансии на ktor не добавленные ради красного словца ключевые слова для поиска, а реально проекты на ktor. Писать для себя можно хоть на экзотике типа хаскеля с кложей, другой вопрос будет ли это пригодно на практике
Ну хз, почти любой бэк - это легаси кал энивей.
Я бы go учил, чтоб на что-то относительно свежее попасть.
Котлин скорее прикладной язык, в первую очередь для мобилок. Мб в будущем и для фронта/десктопа, но в бэке как будто ниша занята c#, go и джээээвой
Как я понял, васм немного соснул и они переключились на wasi, идея типа общего байткода. Мол ты можешь юзать библиотеки, которые написаны на разных языках и твои библиотеки смогут так же все юзать. Еще можно готовые компоненты динамично подключать и передавать по сети (там в презентации дергали с раста на ноду и питон)
Насколько это вообще юзабельно, время покажет, но мне что-то кажется не все так гладко, такая же идея вроде у дотнета была. Или у них не вышло или мягкие пожадничали.
То есть, если это прям очень гладко и удобно, смысла в кмп, возможно, не будет.
А так васм в котлине в альфе. Проблема котлина, это медленное развитие, когда как в шарпах уже пилиться готовый продукт типа блазора, го васм работает только через отдельный компилятор, хотя го сам костыль.
Интересная табличка.
https://developer.fermyon.com/wasm-languages/webassembly-language-support
Читаемость го ужасная, простые действия типа пожонглировать данными превращается в портянку на два три экрана, когда в котлине это просто несколько строчек (если по строчкам дробить).
Го больше 12 лет, там раньше и сейчас велосипедили каждый свое, сопровождать такой код ужасно. Поверь, лучше старые спринги подергать, которые дефкто стандарт, чем неведомые самописульки в процедурном стиле в тонне бойлерплейта и без документации.
Коротко об истории успеха, в свое время двери с ноги открывали со словами что это будет кросплатформеная мегагиперхуйня
Насколько я понимаю в мобильной дресне, то всякие дарты и ксамарины это слой абстракции, это жизнеспособно, просто мягкие просрали рынок.
А вот кмп это нативный код для разных платформ - как это может выстрелить я хз, ну типа как ты будешь котлин либы юзать в среде мака, кто тебе их будет переносить? Тебе все равно нужен будет мак, не проще взять просто свифт и писать по готовым докам в родной среде?
Проблема в том что это будет в любом случае слой абстракций и определенные ограничения, под разные платформы невозможно нативно писать и как только требуется выйти из этого заповедника абстракций так и начинается глобальная боль
Предлагают писать доменный код на котлине, и юзать котлин либы, которых по идее достаточно для всего.
А с версткой уже проблемки, как и с некоторыми системными хуйнями, так что проект не будет полностью на котлине, но вся доменная логика на котлине пишется в kmp по идее. Либ хватает.
Но мелкокомпаниям офк проще разделять на платформы
https://gitverse.ru/features/gigaide
Затестите и скажите ваше мнение.
>То есть сбер взял эти ide которые open source, объеденил в одно и добавил своё расширение гигакод, и сказал это ГООООЛ? Так что ли?
Типа того, еще взяли на работу кого-то из жыдбрейнс кто идею писал. На сколько я понял если бы они могли спокойно покупать идею по принципу пармезана и креветок из Беларуси, то никто бы мозги не ебал, а тут конкретно перекрыли доступ к идее, вот и решили такое запилить.
>Затестите и скажите ваше мнение.
Та же самая идея, только некоторые расширения свои вместо родных
Ого, Коклин еще не окончательно протух судя по бурлению тредика, респект
Охереть наговнили, в win11 нельзя увидить эту программу в apps, собственно, по простому удалить.
>>3304752
Щас бы оценивать что-то по бурлению тредов на дваче. Тогда можно прийти к выводу что gnu/linux имеет популярность как windows, а фаерфокс еопулярнее хромиума. Если всё работает обсуждать нечего, если всё говно то бурления обсуждения. Намёк понял?
/pr не на дне по скорости постинга, только из-за автоботов в треде "мы вам перезвоним". Так что тут еще можно поспорить что протухло.
Если судить по зведным репам в гитхламе, то за последние годы рост в 3 раза. Даже на протухающем SO есть рост (пикча)
Что такое вообще тэг xo? Мне даже в /xo не смогли ответить, что такое xo.
Что обсуждают в /xo, может алгоритмы? Может фреймворки, нет, там обсуждают как же хочется тяночку и как кушают пиццу. Это никакой не /pr это просто филиал /b без порнухи.
Этот график говорит лишь о том что много вопросов по нему и небезосновательно
>и небезосновательно
Если это было так, то раст давно бы обогнал питон, но увы, твой манямир не работает.
Этот график говорит сколько вкатунов или перевкатунов интересуются языком, не хватает только графика по просмотрам, так как большая часть по поиску попадают.
Котлин обеспечен андроидом, как js обеспечен браузерами. Так что вероятнее твой яп загнется быстрее, чем обеспеченные платформой языки.
>Котлин обеспечен андроидом
На Ведриде можно писать нормальной Джавой и не учить очередной синтаксический сахарок за пределами гуглопетушарни который не нужен, это и к Го относится
Все логично, растом вкатуны и долбоебы не пользуются там слишком высокий порог входа, плюс люди с опытом сначала идут в документацию, а потом заебывают всех вопросами, собственно из-за чего большая часть нубских вопросов просто отпадает
>там слишком высокий порог входа
Достаточно быть пидарасом в прямом смысле этого слово, никто из норм языков в растопарашу не перекатывается и не будет
>Достаточно быть пидарасом
Ты немного неправильный путь для изучения раста выбрал, вот у тебя и не получилось. Я понимаю ты ищешь легкий путь для себя повторяя то что делают трапики в Калифорнии, но попробуй не через анально-ректальный способ, а с чтения документации для начала
>Ты немного неправильный путь для изучения раста выбрал
Так, а зачем мне его учить? Что бы что?
Я как понимаю ты не правильно понял процесс обучения и просто хотел получить удовольствие став пидарасом
Если бы я стал пидарасом, я бы учил Коклин и любил ДжетБрейнс.
>нормальной Джавой
Ты писал на это говнине после котлина? Да даже после шарпов, которым 20+ лет и то больно.
Очень удобно просто спросить у гулугу как сделать "это" в "этом" языке даже если читал доку.
Я полиглот и у меня уже каша того как делается одно и тоже, но по разному в разных языках, так что в жопу читать доку каждый раз.
Раст несложный, это буллшит, он просто неудобный, но из-за боязни отмены об этом мало говорят, ибо язык политический.
>Ты писал на это говнине после котлина
Конечно, выучил ЯвуС++ все двери открыты, что не скажешь про анально огороженный Коклин, тем более душок ДжетБрейнс вызывает еще большее отвращение
Ты просто обиженный жизнью, приятно что у котлин треда появился свой обиженный хейтер, но скорее всего ты тот шиз, которых срет во всех тредах.
Проиграл)
На котлине кайф писать, а вот от джевы блевать тянет, ну да ладно. Даже если тебе джэва больше нравится, на андроиде ты писать не сможешь, т.к. новые фишки джэвы только в новых версиях появляются, а предыдущие версии андроида их не поддерживают.
В котлине же новые фишки поддерживаются на всех версиях андроида, благодаря компилятору котлина. В андроид мире джавы всё меньше и меньше, а со временем её полностью выпилят за ненадобностью. По сути котлин стал идеальным инструментом для плавной миграции с джэвы. А когда всё на котлине будет, то и jvm можно попробовать выпиливать, т.к. появится какой-нибудь wasm, или kotlin native
> В андроид мире джавы всё меньше и меньше, а со временем её полностью выпилят за ненадобностью
Поэтому на Ведроид пишут на каком нибудь Реакте или Электроне, никто об Коклин не шкварится
Ну зачем, у нас редактор кода, а не инстаграм.
Там ещё ИИ нашёптывать может, прямо в твой код можно посадить его, чтобы срал.
Платно же и еще без прокси не скачать ничего, вчера плагины ручками качал ставил (так как тор только).
Забавное нытье и как житбрейнсы симулируют работу техподдержки.
-У меня пустая говнина сожрала 3гб, а две говнины 5гб!
-Пожалуйста свяжитесь с техподержкой и отправьте данные
И все это вместо того чтобы сказать - это жаба-IDE брат, смирись, это норма!
https://intellij-support.jetbrains.com/hc/en-us/community/posts/6746377604498-The-IDE-is-really-taking-up-too-much-memory
Есть ли будущее у жабы и котлина с таким тулингом? Я не помню чтобы так жрало раньше, что они там делают?
Хотя в угу статистика показывает что жрет немного (пикча)
>Я не помню чтобы так жрало раньше, что они там делают?
Здрасте, с высеров ДжетБрейнс всегда лолировали, хорошо что это говно теперь везде снесли
Последний раз в 20 году писал мелкую херню, помню жрало по гигу, наверняка где-то это можно настроить, но кому это надо? Жаба вообще не пригодна для обычного софта, даже если правда отъедено 400мб, то какого фига она сверху еще 2000 захапала?
А еще раньше можно было синхронизировать конфиги через гитхаб, хотел прицепить старые конфиги, но был послан, оказывает теперь только через аккаунт жб. (づ ◕‿◕ )づ
>аккаунт жб.
Так они даже оплаченные лицензии если ты в РФ блокируют, там уебки феерические, с другой стороны поделом кто себе в жопу вендорлок засунул
Ни разу не видел такого. Мб в первый раз когда заходишь, новая версия идеи подсказки включает
На линуксах та же история, именно поэтому я и перелез на vscode незадолго до блокировки лол
>-Пожалуйста свяжитесь с техподержкой и отправьте данные
А в техподдержке тебя пошлют на хуй на инглише, ребята из Питера, по причине того что ты не в той стране родился. Так забавно читать когда тикеты такие закрывают, в ТП сплошные русские фамилии
Странно, у них и так все плохо, а они еще себе рынок рушат.
>у них и так все плохо
Как у монополистов может быть плохо? Только не надо говорить , что кто-то vs code напердолил расширениями так, что это теперь полноценная ide. Если хочешь обсуждать джетбрейнс прошу в /s, тут обсуждают Котлин: https://2ch.hk/s/res/3534595.html
>Если хочешь обсуждать джетбрейнс прошу в /s
Ты аутист? Как софт для разработки, который фактически прибит к котлину обсуждать вне раздела программирования? С кем я там буду обсуждать IDE?
Это как советовать художнику идти обсуждать мольберт в раздел лесозаготовки.
>>софт для разработки, который фактически прибит к котлину.
sudo snap install kotlin --classic
Можешь теперь разрабатывать в блокноте
>Как у монополистов может быть плохо?
Ага, где-то на уровне нодпад++
>Только не надо говорить , что кто-то vs code напердолил расширениями так, что это теперь полноценная ide
Неожиданно, но для 99% IDE это автокомплит и раскраска буковок.
>Как у монополистов может быть плохо?
>Только не надо говорить , что кто-то vs code
Так все равно, что высрали свой vscode в виде флита, который идет на компромисс жадности и поддерживает все языки.
У тебя график протух
https://visualstudiomagazine.com/articles/2024/07/26/so-dev-survey.aspx
>поддерживает все языки
Так это заебись же, или ты кроме Кеклина ничего больше ниосилил?
Это тот же график просто вкладка другая.
https://survey.stackoverflow.co/2024/technology#most-popular-technologies-new-collab-tools-other
>>3306694
Раз здесь собрались джетбрейнс эксперты, кто-то объяснит в чём смысл android studio если есть intellij + android плагин?
>Это тот же график просто вкладка другая
Ага, точно, странно конечно что они Нотепад как ИДЕ записали, хотя я активно им пользуюсь
>android studio
Ну может в том, что его сама Гугля и ведроид комунити поддерживает, плюс бесплатно и без повесточки.
> Если хочешь обсуждать джетбрейнс прошу в /s
Тогда и тред туда переноси
Если ты нажмёшь на главной кнопку c++ то обнаружишь что на плюсах нет тредов. Значит по твоей логике он сдох?
На котлине популярны веб сервера? Подскажите максимально современный стек для этого. Это спринг какой нибудь или спринг бут? Или го ебет с отрывом?
Это так называемый некст-ген ДХ или я чего то не понимаю? Вы там ебнутые? Если даже базовый функционал такой, представляю какие там приседания с языком будут.
Ну давай по порядку:
Темплейты везде есть. На js это create-react-app, на ruby это rails new, на питоне разве что нету, но это потому-что каждый городит себе свой велосипед и считает, что это нормально.
Либы устанавливаются достаточно тяжко из-за системы сборки. Они управляют всем проектом и каждый считал, что нужно добавить "от себя". Причем gradle это не java, это jvm+native. Ты буквально можешь собрать проект на scala + kotlin native. Ясен хрен, что там для поддержания такого суперинструмента будут куча тонких настроек.
С языком обычно приседаний нет, но диды решили, что все jvm языки это что-то супер серьезное, так что заоверинженерили.
TL;DR
Диды из оракл и им подконтрольных заоверинжкнерили инструментарий, но не язык. Если есть желание потерять веру в человечество и светлое будущее - JVM сделан для тебя.
Мы же = терпим = и фиксим очередные проблемы со сборкой и r8 proguard
Так в том и дело что в любом современном языке/фреймворке проект с темплейтом стартуется одной командой из терминала и либы ставятся также. И супер инструментарий у них, а не у этого говна на палке. Зашипить темплейты и сделать их копипейст одной командой в терминале вместо дрочки в браузере, видимо тоже джава не даёт и опять поднасрала.
Котлин себя позиционирует как молодой, современный, молодежный язык, но как была дрочка с джавой для старых пердунов так она и осталась.
Ты немного не понял, это не язык который в nano пишут. Для таких существует язык си.
Джава мир очень большой чтобы темплейты в утилиту загонять, кому-то это может нахрен не надо.
Почему не сделали гредл плагин типа gradlew new my-best-pet-site? Да потому что сборка подразумевает до сотни (а может тысячи) вариантов билдов, ты представь как это перечислять в консоле? Или сделай такой плагин сам, вдруг ты в семье гений.
В общем, если ты чего-то не понимаешь, то это не значит что все тупые. В жаба мире довольно большая гимнастика делается чтобы все между собой дружило и было гибко (джава это лего, но в отличии от го, все компоненты подходят друг к другу).
Если тебе сложно, то рекомендую просто спринг взять.
Ты можешь это прям в гугл написать
>>3311047
https://www.techempower.com/benchmarks/#hw=ph&test=fortune§ion=data-r22&l=xan9xb-cn3
Если нужен комбайн по типу asp.net - то де-факто стандарт это спринг. Я не знаю есть ли веб-комбайны в го.
На нем прикручивают спринг и копаются в корпоративном говне
Пчёл, ты бы хотя бы хоть в вопросе разобрался.
Ксамарин ребрендировали и немного перепаковали, выделив для него отдельный workload в дотнете.
Еще лицензия теперь более свободная. Тебе напомнить про суды метаксой которая посмела выложить на гитхаб "собственность" жид-брейнсов?
>Подскажите максимально современный стек для этого.
asp net core
Тебе надо разобраться в вопросе сначала, дружок - бэкендер.
Посмотри доклады по корутинам, и какую проблему они решают.
Никто не запрещает тебе пользоваться тредами, как в джаве. Есть и другие библиотеки для асинхронной работы, без корутин. Не хочешь корутины - не используй. Они могут быть избыточны для бэкенда.
>Объясните мне нахуй JB выдумал эти ебучие корутины
Чтобы ты не нюхал реактивный костыльный адок.
>если у вас функции все равно разного цвета
Стекфулл горутины очень непрактичные, медленные и еще имеют шедулер. Без доступа в jvm получилось бы очень страшное. То есть, почему все выбирают стеклесс, но ценной покраса - это производительность и легкость. именно поэтому маркетинг го акцентировал внимание что их стекфулл горутины якобы очень легкие и быстрее. Но это маркетинг, го в реале не такой быстрый
>а не взял рабочую схему async-await
Они ее и взяли, просто хотели как лучше, или же хотели сильнее прибить к IDE (есть такое мнение, к сожалению не имею знаний чтобы потвердить). В любом случае это стеклесс.
>или треды как в го-джаве
Они реализованы через jvm, а не на стейт машине (как например шарпах, где их вирт.машина не знает ничего про асинки). Ты можешь юзать грин треды на котлине на новой jvm. Все что делает джава, она делает и для бэкенда котлина.
> Все равно надо писать ебаный suspend, все равно надо специальным синтаксисом исполнять асинхронщину.
Это все равно лучше чем реактивное программирование (ты не представляешь какое это дно).
Асинхронное программирование это вообще другая область, кринж по покрас придумали маркетологи го, ибо го надо было конкурировать с асинхронностью в других языках (так как наличие асинхронности в других яп превращала го в тыкву).
>>или треды как в го-джаве
Естественно я про новые грин-треды, а не платформенные треды.
>Тебе напомнить про суды метаксой которая посмела выложить на гитхаб "собственность" жид-брейнсов?
Стори?
>стеклесс
Поясни, что такое стеклесс? Чем котлин-корутины отличаются технически от TPL ?
>отличаются технически от TPL
Гугли чем отличается асинхронные и обычные (системные) потоки
> стеклесс?
Гугли различия между stackless и stackfull корутинами.
или
https://habr.com/ru/articles/850970/
>Стекфулл горутины очень непрактичные, медленные
А вот это интересно. Я наоборот думал, что вшитые грин треды быстрее работают, а то петушонкинсы любят понять, типа suspend замедляют, засирают код(стейт машинами)
Прочитал статью, там написано, что stackless корутины через планировщик работают.
А чем является планировщик, и что он делает в котлин корутинах?
Имеется ввиду сама стейт машина(свич кейс), или что?
>Стекфулл горутины очень непрактичные, медленные и еще имеют шедулер. Без доступа в jvm получилось бы очень страшное.
Без доступа к JVM у тебя вообще хер что получится. Менеджить стек из Java кода нельзя.
>именно поэтому маркетинг го акцентировал внимание что их стекфулл горутины якобы очень легкие и быстрее. Но это маркетинг, го в реале не такой быстрый
>кринж по покрас придумали маркетологи го, ибо го надо было конкурировать с асинхронностью в других языках (так как наличие асинхронности в других яп превращала го в тыкву).
Батхерт ЖБ маркетолуха, совсем не заметен. Капча намекает.
Там шедулер да еще сами толстые по природе, в статье описано.
Когда жабисты выкатили зеленых, дотнетчики засуетились
и начали исследовать зеленые у себя. По результат оказалось что это хрень медленнее чем даже базовые асинки на стейт машине (у жабы они через вирт.машину сделаны), в общем, они отказались в пользу того чтобы оставить как есть (асинк/авэй) но улучшить теперь у себя через вирт машину.
История:
https://github.com/dotnet/runtimelab/issues/2398
парень хочет разобраться с асинк/авэй, дайте ему стул
Проблема асинков котлина, в том что они не оптимизируются jit, отсюда печальные цифры. Я не тестил, со слов какой-то конференции на трубе (в любом случае при правильных условиях корутины могут быть лучше системных, но в случае jvm я бы заюзал родные зеленые)
>Батхерт
Про цветные функции раздули гошные евангелисты (сам гугли статью). То что ты по природе если влез в асинки, уже говорит о том, что ты в мире асинхроной радости (даже мэйн асинкаешь) и другого пути нет. Ты либо там, либо там, никаких цветов нет.
А я сидел, угарал над ними, и такой, типо, какая война? А что случилось? Россия в опасности?
Пиздец, до сих пор кекаю с этих мамкиных воинов
>джет-брейнсов
Даже хабропидарасня почти перестала на них теребонькать
>>3320110
Судя по тому что они сделали бесплатными RR, WS и Raider (гоферы сосать!) - у них совсем все плохо. правда в замен нужно будет поделиться планкой памяти
>на техническом собеседовании неуместные вопросы задавали
Это какие же?
у меня все было чинно, благородно, никаких срамных вопросов не было
>Про цветные функции раздули гошные евангелисты (сам гугли статью). То что ты по природе если влез в асинки, уже говорит о том, что ты в мире асинхроной радости (даже мэйн асинкаешь) и другого пути нет. Ты либо там, либо там, никаких цветов нет.
Во первых многие про это писали, включая архитектура этих ваших горутин https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d Аргументы против покраса лампаса всё равно остаются валидными.
Во вторых как раз у корутин всё не айс с перформансом и потреблением памяти https://youtu.be/kwS3OeoVCno?si=67dWOss5pDUZ7Crk&t=1500
Цветные функции это хайп, который не коснулся только ленивый. Асинхронный программирование != синхронное. То что пытаются сгладить два этих мира, как раз показатель некомпетентности авторов и проблема цветных функций появляются тогда, когда это начинают делать.
За счет неблокирующего и/о и того что шедулинг ОС-потоков дорогой, даже неоптимизированные котлиновские корутины будут лучше чем дрочка старого реактивного программирования на жабе. А кому надо было максимум - юзал вертекс. В любом случае жаба сделала для котлина зеленые треды, мы не против.
Ты этот покрас все равно будешь иметь, и лучше использовать suspend или async await, чем городить коллбэк hell, так называемый.
Или что, лучше коллбэки передавать, говноеды?
В go никуда покрас не делся, там для перекида значения нужно Channel как колбэк в параметры функции передавать.
Visual Studio на этом же проекте отъедает 1.5 гигабайта после дня разработки
Как интересно сложилась жизнь. В свое время у джавы был эклипс, нетбинс и жб. Сейчас джава фактически вендерлок на жб. У шарпов была только вижла, теперь vs/community, vscode, rd, условно ReSharper.
>Сейчас джава фактически вендерлок на жб.
Только в мирке манякоклиниста
Только в таоем ограниченном манямирке.
https://www.jrebel.com/blog/best-java-ide
>Цветные функции это хайп, который не коснулся только ленивый. Асинхронный программирование != синхронное. То что пытаются сгладить два этих мира, как раз показатель некомпетентности авторов и проблема цветных функций появляются тогда, когда это начинают делать.
Ни у одного нормального разработчика, нет цели делать асинхронный код. Асинхронный код это просто один из способов решить проблему немасштабирования платформенных тредов. Но есть и другие способы, которые по перформансу, удобству - превосходят все эти корутины и асинки. Ты просто берешь и запускаешь код в горутине/виртуальном треде. И у тебя работают все легаси библиотеки с блокировками на IO и просто блокировками. А асинки это просто костыль, как-то по быстрому пофиксать проблему. Он может быть оправдан в случае Андроида, там в Dalvik реализовывать виртуальные треды не рационально. Но на десктопе вируальные треды/горутины настолько уделывают корутины, что даже не стоит пытаться с ними работать.
Рим пал, легионер!
>За счет неблокирующего и/о и того что шедулинг ОС-потоков дорогой, даже неоптимизированные котлиновские корутины будут лучше чем дрочка старого реактивного программирования на жабе. А кому надо было максимум - юзал вертекс.
>Каневский: это все конечно же был пиздежь!
Реактивное программирование требует больше дроча, но гораздо лучше оптимизируется JIT. А уж если писать на NIO, то по перформансу корутины вообще сосут по самые яйца.
>В любом случае жаба сделала для котлина зеленые треды, мы не против.
Java сделала так, что Котлин стал не нужен в 99% бекенд проектов.
>Java сделала так, что Котлин стал не нужен в 99% бекенд проектов.
Чувак, джава уже давно ничего не делает. Котлин не стартанул в бэкенде, не потому что джава стала лучше, а потому что мало кто начинает новые проекты на jvm.
Пытался нарыть хайп с новыми потоками, а всем насрать, ибо все доживают на древних версиях jvm.
Реактивная жаба, это такой же рудмент как EE. Это не просто "больше дроча", это кривой оверхедный ад, кто его придумал, у того больной мозг.
Асинхронное программирование не стыкуется с обычным, еще раз, те кто пытается сгладить это два мира просто некомпетентен. Раньше до какой-то версии го (вроде 1.14), можно было положить целый сис.поток с миллионами горутин просто дробилкой в цикле (не отдавать управление). Потом они добавили вытесняющую многозадачность, но в этом громком слове лишь подход, что на 61 итерации поток принудительно переключается и все. Так что асинхронное программирование это, можно сказать, другой вид программирования.
>Чувак, джава уже давно ничего не делает. Котлин не стартанул в бэкенде, не потому что джава стала лучше, а потому что мало кто начинает новые проекты на jvm.
Этой мантре уже лет 5 точно. Самим этот ебанный аутотренинг не надоел?
>Самые востребованные разработчики — джависты. В среднем для них открывали более 1,7 тыс вакансий ежемесячно, и они занимают 19% всего рынка вакансий для разработчиков.
https://habr.com/ru/articles/803935/
>Реактивная жаба, это такой же рудмент как EE. Это не просто "больше дроча", это кривой оверхедный ад, кто его придумал, у того больной мозг.
Расскажи, асинхронный ты наш, как ты будешь реализовать back pressure в корутинах? Опять с каналами пердолиться?
>Этой мантре уже лет 5 точно. Самим этот ебанный аутотренинг не надоел?
Какие же вы пиздлявые. Этот вывод зафорсился локально в узком кругу, под пиво вечером, месяца 3 назад, с мыслью почему котлин "не смог", среди бывших жабистов. Я тут его пару раз упомянул чтобы попустить жабьего-евангелиста (вероятно это все ты).
>Самые востребованные разработчики
На момент 2006 года на коболе было написано больше всего кода в мире! Но слышал ли ты тогда о коболе? Никто не отрицает большую капитализацию кода джавы, но это кобол-код, я же говорю о том кто начинает код сегодня и что завтра станет капиталом кода.
>Расскажи, асинхронный ты наш, как ты будешь реализовать back
К счастью, я эту шизу обошел стороной, асинхронное программирование покрывает 100% все мои задачи, что там шизы с реактивным программированием высрали, меня не интересует. Еще спроси как на EE развернуть контейнер сервлетов, коболятина ты нудная.
Очень интересная статистика изолированного от мира рынка. Можно еще ссылочку на исследования трендов айти в Иране и северной Корее?
Ну к слову, вне рф джава еще больше ебет говняк, так что ты и тут обосрался.
>Какие же вы пиздлявые. Этот вывод зафорсился локально в узком кругу, под пиво вечером, месяца 3 назад, с мыслью почему котлин "не смог", среди бывших жабистов. Я тут его пару раз упомянул чтобы попустить жабьего-евангелиста (вероятно это все ты).
Обожрался - скажи что троллил. Классика.
>>3321725
>На момент 2006 года на коболе было написано больше всего кода в мире! Но слышал ли ты тогда о коболе? Никто не отрицает большую капитализацию кода джавы, но это кобол-код, я же говорю о том кто начинает код сегодня и что завтра станет капиталом кода.
В 2006 вакансий кобола уже не было. И как раз количество вакансий и говорит о том, что новые проекты активно начинают на джаве. Для поддержки существующих приложений, не надо много людей. В основном люди нужны на написание новых систем и активное развитие существующих.
>>3321730
>Очень интересная статистика изолированного от мира рынка. Можно еще ссылочку на исследования трендов айти в Иране и северной Корее?
А ты типа уже в солнечном санфране работаешь?
>В 2006 вакансий кобола уже не было.
Ты следил? Пиздлявка.
Большое число вакансий может говорить о текучке, отскребать легаси говно даже +10% к зп та еще радость.
Но это никак не говорит что новых проектов много.
>поддержки существующих приложений, не надо много людей
То что ты зеленый, я и так уже понял. Ты ни дня на джаве не работал, тебя это выдало. ты даже не понимаешь какие процессы идут в тырпрайзе
>Ты следил? Пиздлявка.
Дебилушка, представь себе да! Уже тогда ходили шуточки про Cobol. Например сайт Cobol on Cogs был создан в 2007.
>Большое число вакансий может говорить о текучке, отскребать легаси говно даже +10% к зп та еще радость.
>Но это никак не говорит что новых проектов много.
Ты пока только пиздишь беспруфно, но никак не объяснил как ты меряешь количество новых проектов на том или ином языке.
Спустя год спросите, что происходит в котлин треде - ответ будет всегда один.
Ше не вмерла джава 8
Пишу на шарпах, пытался написать пару проектов на котлине, но очень сильно не хватает выразительности
Потому что в нашем Z-bank запустили новый микропенис на жаве. Это точно оправданный выбор технологии, а не наши дауны ничего кроме джавы не знают!
Потому что ты мудак, вот почему!
Пришел сюда и начал высирать хуйню про новые проекты и кобол, не привел ни одного аргумента. А теперь еще требуешь, чтобы кто-то опровергал твой высер.
>Маскот котлина Коди.
Разработчики котлина либергнойные хуесосы предавшие свою страну, осудившие СВО и съебавшие в Чехию донатить на AFU
>пользоваться пидоаршьим софтом когда есть кресты от белых людей
)
Биомусор, вернись в pro.jvm jobs чат к своим кровожадным животным.
Еще одно необразованное тупое животное. Очень жеско щас пернул тебе в лицо, подсвинявый (ну или свинявый за пределами кропивача)
>Разработчики котлина либергнойные хуесосы предавшие свою страну, осудившие СВО и съебавшие в Чехию донатить на AFU
Факт, котлин для выруси
>Разработчики котлина либергнойные хуесосы предавшие свою страну, осудившие СВО и съебавшие в Чехию донатить на AFU
А патриоты оставшиеся в России и поддержавшие СВО, уже написаль что нибудь дельное?
>А патриоты оставшиеся в России и поддержавшие СВО, уже написаль что нибудь дельное?
Да.
>Michail Zarečenskij
Ксенопоцреот из палаты мер и весов.
За пределами Ведроида Коклин не нужен, да и под Ведроид он не нужен, хз зачем Гугля его там завирусил
"Язык Kotlin, сопутствующая инфраструктура, а так же интеллектуальная собственность проекта будут полностью управляться свободным инклюзивным сообществом. Это большая победа для нас", - заявил Гжешув Бзежинский, временный операционный директор JetBrains по управлению расходами.
>Kotlin в фонд Apache Software Foundation.
Закопали свое говноподелие короче
>держи боже что нам не гоже
>пусть лохи с этим говном ебутся
Как же тяжело коболисту и котлин выгнал с телефонов и новые шарпы душат и го с микропенисов погнал. и над всем этим сидит смеется жопоскрипт, который просунули везде, кроме только около юнити-игр
Чистый код от Анкла Бэба. Если лень читать, то структурировать приложение нужно так Контроллер -> СервисИмпл имплементс Сервис -> Рипазитари.
Всю логику сгружаешь в СервисИмпл
Какая страна такое и айти
А вообще у котлина хороший и огромный чатик в телеге.
>Apache Software Foundation
Теперь его окончательно превратят в джаву
>временный операционный директор JetBrains
А ведь слухи о проблемах в ЖБ не такие уж и слухи похоже
Это же наброс местного безработного джава шиза который скорее всего вообще код не пишет, потому что гадит в разных тредах даже в /gd
>>3344479
Ну знаете, в вашем мире jvm можно ожидать всякого, даже такой наброс может быть вполне реальным. Я после того как школьники из майнкрафта взломали один из самых популярных логгеров уже ни чему не удивляюсь
Ну, я так понимаю, на Котлине можно писать фуллстек-приложения на бекенде, используя compose, без подключения Vaadin в Java.
мимоджвабекендер
Тут в соседнем треде >>3369186 (OP) плачут, что в Go не могут вкатиться никак
https://raw.githubusercontent.com/ABTSoftware/SciChart.Android.Examples/refs/heads/SciChart_v4_Release/app/src/main/java/com/scichart/examples/fragments/examples2d/createStockCharts/CreateRealTimeTickingStockChartFragment.kt
>как заюзать эту весчь в своём приложение, т.е. как склонировать и импортнуть
Ты не знаешь как gic clone работает или что?
В java 21 в основном жмет: checked exception, отсутствие try expression, null.
При этом очень ценим скорость компиляции, простоту java. Не хочется уходить в scala-подобный пиздец, где из-за обилия возможностей в каждом проекте свой диалект scala, а еще это пиздец как долго компилится и ide хуево подсказывает.
Итого выбираем между двумя вариантами:
- java + lombok sneakyThrows или аналог в виде либ
- kotlin + белый список разрешенных фич языка. Белый список хотим сделать через lint внешней тулой или опциями компилятора.
Собственно вопросы:
- Есть ли у котлина проблемы с долгой компиляцией и/или тупизной код ассиста?
- Какие фичи котлина можно смело запрещать, т.к. они усложняют понимание кода?
- Какие подводные у котлина?
>тупизной код ассиста
нет
>проблемы с долгой компиляцией
Мб чуть дольше джэвы. В целом так же, ток надо брать kotlin 2.n версию
>Какие фичи котлина можно смело запрещать, т.к. они усложняют понимание кода?
Например такой код не очень читаемый(пикрил).
Но запрещать фичи я бы не стал, достаточно линтер настроить
>Какие подводные у котлина?
Все "поля" являются свойствами, с возможностью переопределить гетер и сетер. Есть конечно аннотации, чтоб "поле" было именно полем, но не советую их использовать, код засрется.
Нет модификатора package private.
Нет ключевого слово static, вместо этого object/ companion object.
Ну и могу упомянуть ключевое слово suspend и корутины. Можно подумать, тащить ли их в проект, может они не нужны вам, а то некоторые не любят корутины.
Ну вроде спорные моменты перечислил, которые на уме были(особенно для джэвистов). В остальном пиздатый язык, код пишется на чиле.
а какие плюсы лично ты бы выделил? Потому что мимоджавабекендеру (мне) как-то мало причин переходить (даже пробовать) котлин, но хотелось бы найти
Сап, хочу написать простой crud с базейкой, попробовать впервые kotlin. На каком стеке это сделать максимально легко и актуально? ^_^ спринг бут?
>Потому что мимоджавабекендеру (мне) как-то мало причин переходить (даже пробовать) котлин, но хотелось бы найти
А, так твой голос даже не значит ничего, я зря распинался. Зачилься, всем пох че ты там хочешь/не хочешь, без тебя разберутся.
Не надо писать "рассматриваем", когда лично ты не рассматриваешь и не решаешь нихуя.
Это другой чел. За ответ спасибо, ушли пилить rfc на внедрение
оригинальный вопрошающий
Понял.
>>3380429
Чел, ну серьезно, если мало причин пробовать котлин, то не пробуй. К чему вопросы такие?
Язык говна, язык ВСЖ. Не зря даже название на это указывает.
Елизаров убежал в Яндекс. Бреслава выгнали нахуй, т.к. он шиз со справкой и теперь он пытается в ололо стартап для психолухов. Жемеров тоже свалил
Что с название не так, шиз? Наверное самое удачное в этом языке это способность не промахнуться в гугле по говно базворду как го или раст. Помню лузлы как в тиобе обосрались нарисовав популярность в пик появления игры го (с покемонами).
>Бреслава
Там, чел вроде как выгорел, как сам говорил. А вообще это жадность, экономить и запилить теху без реальных специалистов, да еще моментами студентами. Они буквально писали 5 лет транспайлер в байткод из слизанных фич других языков (груви/скала).
Но вообще, ошибка делать прокси язык для стагнирующей технологии, это было понятно и по скале и груве и еще че-то там. У жабы был очень сильно раздут пузырь востребованности тогда.
С названием всё как раз заебись, отлично отражает ВСЖ суть языка и идеи захуячить классы куда не надо. Джава популяризировала эту дегенеративную хуету, Котлин продолжил.
>ВСЖ
Хватит придумывать и использовать мало популярные слова, это даже не гуглится (а на форум доты я заходить не хочу).
>идеи захуячить классы куда не надо
Полиморфизм и контракты на интерфейсах позволили работать 100+ макакам вместе, не трахая друг другу мозги каждую минуту. В общем, ООП дало (и дает по сей день) способ разработки овер сложного программного обеспечения. А внутренняя изменяемость через инкапсуляцию вообще основа разработки очень сложного многослойного ПО (не отсреливая себе или напарнику яйца и не переписывая все и вся по чиху).
Например в модном и молодежном расте, внутренняя изменяемость недоступно через барроу чекинг. От чего те кто пытаются натянуть эту сову на мега глобус, отстреливают рефакторингом не только себя яйца, но и коллегам (причем массово картечью, ибо нехер пердолить процедурный язык в 2010+ году).
>классы куда не надо.
Малолетний ньюфажа не палиться. Но кроме процедурного, функционального и мульти-ООП больше ничего нет. Первое устарело и непригодно для овер-сложного софта (да даже для соло скриптов, ты за неделю такую лапшу создаешь, даже пытаясь сделать модульно), второе, ФП, экзотика не отражающая реальные потребности.
Вот и думай.
>придумывать и использовать мало популярные слова
Нормис, уёбывай с моих двощей.
На удивление годное 6-часовое видео по вкату в Коклин из Джэвы:
https://www.youtube.com/watch?v=dMyRywABp_c
После этого видео прочту спижженую на рутрекере новинку Kotlin in Action, Second Edition и напишу в резюме, что знаю котлин, как-то так.
проблема котла - это отсутствие работы. раньше бигтехи пытались стартовать проекты на котле на беке, но быстро попустились и вернулись на джеву где нужные фитчи уже завезли
Мы переживали за тебя джава-шиз, думали случилось что-то. Тут и капча соответствующая, на держи.
Ну го же там каким-то хером оказался там. Мы забываем что программисты это не всегда высоко интеллектуальные личности.
да, в райфайзене вот много микросервисов на котлине, но теперь уже их там не так активно стартуют на нём, теперь монетку подбрасывают чтобы решить, на чём делать
> теперь монетку подбрасывают чтобы решить, на чём делать
Я в принципе так и представлял как работает бигтех.
>Ну го же там каким-то хером оказался там.
Стильно, модно, молодежно.
https://pl.kotl.in/tvL5uweLW
Иногда в тестах нужно поймать конкретно одно поведение в функции.
Ловить по тексту в мессаге - зло (отвалиться сразу же как текст поправишь).
Делать обобщенные ошибки вида BadАргументЕггор - зло, в сложном алгоритме нужно конкретно закуток где планируем обосраться.
Поэтому приходиться делать нечто похожее на пике для полного контролля.
То есть, если ты делаешь один - делай как хочешь. Если ты в команде, то умные дяди объяснят нет, но покажут макакинг-паттерн как делают у них, и пофиг правильно или нет, так хотел старший.
Умный дядя к сожалению это я в команде. Спасибо, видимо this is the way.
Я не эксперт в котлине, но там похоже обработка ошибок подобие современных го/растов (ошибки возвращают как значения). Реальную необходимость можно увидеть только в работе с корутинами. Если делается вне корутин - то просто подражание.
Проблема в том, что котлин в целом не заставляет и не предлагает передавать ошибку как значение, оставаясь в java парадигме, что все ошибки это exceptions и должны выбрасываться. Но при этом kotlin в отличии от java не заставляет тебя писать try-catch если какая-то функция может выбросить exception. Более того если ты сам не напишешь в аннотации к функции, что она может выбросить исключение, то тот кто вызывает функции и не узнает, что она может это сделать. И это всё с полным молчанием от компилятора, exceptions просто игнорируются.
Эта даже не дихтомия: исключения или ошибка-значение. Это просто отрицание, что ошибки могут существовать. Это огромная дыра в kotlin, которую сами же разработчики языка предлагают заполнить использованием сторонней библиотекой Arrows.kt или установкой стороннего плагина в IDEA, который будет проверять что функции могут выбросить исключение и об этом предупреждать. Btw, плагин убивает IDE на больших проектах, всё начинает лагать, а время "анализа" класса стремится к бесконечности.
И ведь это не проблема только версии 1.0.0. Языку уже 14 лет и никто не собирается как-то решать этот вопрос.
Лучше бы я остался на java.
В начале были чеккед-ошибки (что сейчас везде переизобретает новое поколение), но где-то в начале нулевых, многие нажрались с этим говна и трендом стали анчекед ошибки, которые подхватил тогда шарп и после котлин и им подобные.
Где-то 15 лет назад я был юн и топил за чеккед ошибки (конкретно в джаве), но с возрастом прошел туже эволюцию, что и до меня 10 лет назад и понял какое это дно.
Я уверен, что скоро придут к теме, что эти Result говно.
Как это было с открытием SQL (где-то в 70-80е), люди снова изобрели noSQL, нахлебались по кругу говна и потом такие - не так уж и плох этот SQL
Единственное может это быть технически связанно с корутинами. Но это лишь потому что обосрались, дизайнить язык надо сразу с асинхронщиной, а не потом костылить поверх (привет разработчикам zig)
>не так уж и плох этот SQL
Там прост недостаточно бигдата и память завезли к концу 10-х, всё влезает в один постгрес, пэтому нах не надо ебаться с какой-нибудь касандрой.
>дизайнить язык надо сразу с асинхронщиной, а не потом костылить поверх
А если я хочу выбирать, какой эвент луп использовать, и напрямую дёргать его апи?
А вот и Свидетели Голанга подъехали.
Ошибка должна объясгять что за ошибка произошла и давать достаточно информации об этом. Создавать ошибку на каждый метод - это бред. И в тесте проверять в каком именно методе произошла ошибка - ещё больший бред. Тесты проверяют поведение системы, а не то в каком методе произошла ошибка. Передал в метод вместо числа фигню - получил NumberFormatError, и не важно какой метод его вернул.
>Создавать отдельный Error класс для каждой функции?
Нет конечно, один раз обертку делаешь, для запросов, и всё.
Можно создать обертку с generic-ами, если нужно подставлять каждый раз что-то новое.
Этим пользуются для удобства, но если тебе не удобно, то try catch никуда не делся
А ты видимо скуфидла, которая "тестирует" на моках? Видал таких потешных скуфидонов))) Они еще это называют TDD и заставляют всех писать "тесты на методы"))) Бля, умора)) Замокаются по самые помидоры и потом дрочат свое мокито, лол. Протестировал моки, скуфидонище?))
А на чем тестировать? Или Галь, у нас тесты красные, сходи к системанейм, спроси у них что-то сломалось или нам ошибку искать
> Ошибка должна объясгять что за ошибка произошла и давать достаточно информации об этом.
Так.
> Создавать ошибку на каждый метод - это бред.
А как ты будешь различать какие ошибки возрвращает метод? Result<ValueT, ErrorT>. Вот ErrorT должен быть enum или sealed класс, чтобы можно было ограничить, что вот такие-то типы ошибок могут случится. И не получиться создать ошибку с типом CommonError и потом её вместе с ошибками CaptureError запихнуть в Result. Или то или другое.
Остаются exceptions, но как я объяснил выше >>3396106
разработчики kotlin не дали пользователям инструментов для нормальной работы с exceptions тупо заставив комплиятор игнорировать throws. И получается если ты хочешь макнуть пользователя явно в то, что ошибку нужно обработать приходиться пихать её в Result, которые имеет ограничение на типы описаннное выше.
> Нет конечно, один раз обертку делаешь, для запросов, и всё.
Окей, объясни мне, есть класс для ошибок
sealed RequestError {
object TimeoutError: RequestError()
object UrlIsNotAvailableError: RequestError()
}
И ошибки выше окей для какой-нибудь функции
requestPictures()
Но для функции
requestAudio(audioParameters: AudioParameters)
Есть ещё ошибка
sealed class AudioMetadataError {
object InvalidAudioParameters: AudioMetadataError()
}
И вот как их объединить для Result? Так чтобы не пришлось создавать отдельный класс для всех ошибок для одной функции и для другой с копипастом этих ошибок.
> разработчики kotlin не дали пользователям инструментов для нормальной работы с exceptions тупо заставив комплиятор игнорировать throws
В Джэве де факто так давно вообще уже все делают @SneakyThrows
Да, но в java таким образом у тебя есть выбор. В kotlin у тебя выбора нет.
Неудобно, но хотя бы выглядит как алгоритм как заставить пользователя обрабатывать возможные ошибки. Пиздец, почему это не написано в официальной доке?
Броу, если тебе для внутренней работы api удобнее обычные ошибки юзать, то так и делай.
Result обертки для публичных api уже делаются, чтоб чекать все ветки кнопкокрасу в фиче(запросы) Result котлина - говно кстати, надо своё писать
Причем иногда сервисы кидают ошибки через throws, а кнопкокрас на своей стороне пишет мапер из try catch к Result/Operation.
Да я уже понял, что это видимо новая ФП реальность. Я не против. Я против, что так хуево поддерживается котлином. Нашёл несколько обсуждений на их форуме про это. Вывод какой: да, проблема существует, нет прямо сейчас что-то с этим делать не будем.
>Я против, что так хуево поддерживается котлином
Что ты имеешь ввиду? Знаешь другие способы обрабатывать ошибки?
Я вроде в сообщениях выше объяснил в чем проблема. Стандартный Result не поддерживает указания типов ошибок. Это всегда абстрактный Throwable. То есть пользователю API нужно смотреть сначала в сигнатуру функции на наличие @Throws, чтобы понять какой exception конкретно ему нужно обработать. Если @Throws не указан (а указаниетего не обязательно комплиятором и жалеть не warning), то пользователь должен смотреть документацию. Если и в документации не указано (разраб забыл обновить доку), то юзер оказывается в полной неопределённости, что ему делать.
Это ебать какой flaw языка. Альтернатива это писать свой Result, но тут возникает та же проблема. Или указывай обоьщенный, ничего не значиший тип ошибки или создавай для каждой функции отдельный sealed класс с ошибками-подкласамми.
Если бы был Union тип (T | Error1 | Error 2 ...), то эта проблема была решилась бы, вот только нет такой возможности в языке.
>Result не поддерживает указания типов ошибок. Это всегда абстрактный Throwable.
Ты рофлишь чтоль, забудь этот стандартный Result, и напиши свой, где успех - это generic, и ошибка - тоже generic. Либ - оберток достаточно, не смей стандартный юзать в проде
Почему "не смей стандартный юзать в проде"?
> пиши свой
Я же тебе уже объяснил в чем проблема со своим. Если всё что ты можешь это игнорировать мои аргументы, то в этом общении нет смысла.
>Union тип (T | Error1 | Error 2 ...), то эта проблема была решилась бы, вот только нет такой возможности в языке.
Унион тип ты сам можешь создать, а ошибки наследовать от него, но нах он нужен.
Ты случайно не залетный джун? Покажи пример хоть один, где ошибки через унион тип прокидываются
> Унион тип ты сам можешь создать, а ошибки наследовать от него, но нах он нужен.
А я хуй знает зачем ты предлагаешь наследовать от Union type. Я предлагал передачу множества типов как возвращаемый тип, а наследовать от хуй пойми чего.
> Ты случайно не залетный джун?
Нет. А ты случайно не пидор?
> Покажи пример хоть один, где ошибки через унион тип прокидываются
И ты ещё у меня спрашивал про джунство?
https://ziglang.org/documentation/master/#Error-Union-Type
https://youtrack.jetbrains.com/issue/KT-68296
>https://ziglang.org/documentation/master/#Error-Union-Type
Литерли то же самое, если Result юзать.
Но прикольно, что механизм строго один, не важно каким способом обрабатываешь, catch или switch.
вместо error set можно юзать enum/sealed.
>А как ты будешь различать какие ошибки возрвращает метод?
Как деды завещали: BaseError, от него наследуем FooError и BarError. В обработчике: when(x) и погнали, все что можно обрабатываем, остальное пробрасываем выше/игнорируем. В общем-то ничем принципиально от обработки эксепшенов не отличается.
>>3396715
>И получается если ты хочешь макнуть пользователя явно в то
...ты страдаешь херней. Просто не делай это. И всё. Обработка ошибок, забота пользователя. Это он должен прочитать документацию и обработать ошибки, твой код должен просто сообщить об ошибке. Ну и в документации отписать, когда и какие ошибки возможны.
Да ты прав кажется, я не разобрался когда читал. Ладно, я уже понял, что придется для каждой функции создавать свой набор ошибок. Оверкил, но альтернативы кажется нет.
>>3396978
> Как деды завещали: BaseError, от него наследуем FooError и BarError. В обработчике: when(x) и погнали, все что можно обрабатываем, остальное пробрасываем выше/игнорируем.
То есть ты теряешь типизацию ошибки. Точнее вместо сильной типизации используется слабая типизация где да, BaseError это не String, но BaseError вообще любая ошибка во вселенной и давай уважаемый юзер обрабатывай NetworkError в функции drawCircle() потому что по контракту Result<T, BaseError>, а значит ошибка может быть любой.
> В общем-то ничем принципиально от обработки эксепшенов не отличается.
В жабе хотя бы комплиятор указывал какие конкретно эксепшены могут быть. Тут же тупо аналог Throwable прилетает, только называется BaseError.
> Обработка ошибок, забота пользователя. Это он должен прочитать документацию и обработать ошибки, твой код должен просто сообщить об ошибке.
Я люблю программирование. Я люблю писать хорошие программы и хорошие библиотеки. Подход где обработка ошибок это проблема пользователя, а я просто буду кидать ему Throwable, а он пусть идет читать документацию, введет к созданию плохих программ и плохих библиотек. Использовать я его не хочу.
Идеального решения не изобрести, ты хочешь того, чего не существует.
Ты эти ошибки всё равно будешь заранее указывать, потому что по другому не сделать.
В жабе, после ключевого слова throws, перечисляешь ошибки.
В zig, создаешь error set, внутри перечисляешь ошибки.
В Kotlin, создаешь enum/sealed класс/интерфейс, внутри перечисляешь ошибки.
Все решения схожи, но чуть по разному реализуются.
Да, но вопрос в том, какие инструменты предоставляет язык, чтобы помочь с задачей по обработке ошибок. В Kotlin таких инструментов нет. Старые, из Java, были убраны, новые были не добавлены. Совет от разработчиков: городить велосипеды с sealed классами и копипастом одних и тех же ошибок в каждый sealed класс каждой функции программы.
Безумие...
>В Kotlin таких инструментов нет
Да, гибкий подход, все дела...
Try catch всё ещё есть, а throws всех доебал просто бойлерплейтом.
У тебя есть выбор - заставлять обрабатывать ошибки, или не заставлять.
В Java такого выбора нет, ты обязан этот throws прописывать, либо хэндлить. Хотя чел написал про @SneakyThrows аннотацию, наверное это фиксит проблему.
>городить велосипеды с sealed классами
да
>копипастом одних и тех же ошибок в каждый sealed класс каждой функции программы
нет, если ты копипастишь ошибки, то что-то делаешь неправильно.
Я подозреваю, что ты в sealed ошибки добавляешь вообще ВСЕ возможные ошибки, но это неверно.
Есть объективные ошибки юзера, например, если он вводит out of bounds индекс. Такую ошибку офк не надо добавлять в sealed, тут вступает в дело подход let it crash.
> нет, если ты копипастишь ошибки, то что-то делаешь неправильно.
Тогда я не понимаю как сохранить строгую типизацию, что может быть ошибка А, B, C при выполнении функции foo() и могут быть ошибки A, D, E при выполнении функции bar() не используя exceptions. Я выше приводил пример, что получается при использовании Result:
https://pl.kotl.in/tvL5uweLW
Правильно тебя тимлид гоняет, что аж жопа горит на двачах, как вас балбесов еще учить тесты писать.
Всё, я вник в твою проблему.
Если это не функции для публичного апи, то я бы хуй забил и делал через try catch, а обертку делал только для финального публичного взаимодействия.
Если у тебя либа низкоуровневая, то я так же не стал бы sealed хуйню городить, тут документация нужна увы.
А одна одинаковая ошибка из трех
(А, B, C) и (A, D, E)
не так критично, чтоб скопировать.
Ещё можно такой пикрил костыль сделать, но это шиза имхо
Спасибо.
> Если это не функции для публичного апи, то я бы хуй забил и делал через try catch, а обертку делал только для финального публичного взаимодействия.
Для публичного апи, всё что ниже как раз через try catch сделал
> А одна одинаковая ошибка из трех
> (А, B, C) и (A, D, E)
> не так критично, чтоб скопировать.
Да, я так и сделаю скорее всего
>То есть ты теряешь типизацию ошибки. Точнее вместо сильной типизации используется слабая типизация где да, BaseError это не String, но BaseError вообще любая ошибка во вселенной и давай уважаемый юзер обрабатывай NetworkError в функции drawCircle() потому что по контракту Result<T, BaseError>, а значит ошибка может быть любой.
Я не говорил что BaseError должен быть один на все приложение. Какой нибудь RPC может возвращать RpcError, у которого внутри будет NetworkError со своими подтипами, ProtocolError ошибки протокола и ServerError ошибки сервера со своими подтипами.
>В жабе хотя бы комплиятор указывал какие конкретно эксепшены могут быть. Тут же тупо аналог Throwable прилетает, только называется BaseError.
Тот же JPA выкидывает RuntimeException и никто их не декларирует. Весь спринг сидит на рантайм эксепшенах и никто не жалуется.
>Я люблю программирование. Я люблю писать хорошие программы и хорошие библиотеки.
Ты любишь овериженирнг. YAGNI.
>Подход где обработка ошибок это проблема пользователя, а я просто буду кидать ему Throwable, а он пусть идет читать документацию, введет к созданию плохих программ и плохих библиотек. Использовать я его не хочу.
90% обработки ошибок это проброс выше/логгирование/сообщение пользователю, 10% ретрай/фалбек, а вот оставшееся это уже реальная обработка ошибок.
>Ты не очень разбираешься в тестирование, да?
Лучше тебя это точно.
Разработка ведётся через Compose Multiplatform, причём под десктоп да-да, не под ведро, так уж вышло.
И, значит, насрав пару решений без отделения бизнес-логики от gui я понял, что занимаюсь какой-то полной хуйнёй и погрузился в изучение MVI и MVVM. В целом понятно, как оно должно работать на уровне модель-вью, но возник вопрос следующего характера:
У меня есть поток, выполняемый параллельно с интерфейсом, который, собственно, и делает всю основную работу приложения.
Как мне ПРАВИЛЬНО извлекать из него данные в модель? Все гайды вертятся вокруг удалённого бэкэнда, а мой случай не разбирается, похоже нигде.
Так вот, как доставать данные? Делать в рабочем потоке публичные переменные и использовать их в модели? Передавать экземпляр модели в рабочий поток? Сейчас у меня все состояния хранятся непосредственно в рабочем потоке, но их, как я понимаю, надо выносить в модель, так вот, какая должна быть архитектура в этом месте?
Приведу пример для ясности:
Имеется mutableStateOf<Boolean>, хранится в рабочем потоке как публичное поле. В процессе выполнения потока меняется каждую секунду. В зависимости от его значения на gui меняется, к примеру, поле с галкой. Я так понимаю, правильно будет вынести это mutableState из рабочего потока в modelview, дабы интерфейс общался уже с ним, но как правильно реализовать обновление этого mutableState из рабочего потока?
Паттерн observer. Когда меняется переменная, дергаешь колбек в главном потоке.
Вообще странно, что у вас нет какого-то стандартного способа как в Андроиде. Handler, LiveData, Flow. Это структуры из Андроида (Flow вроде и в обычном котлине есть) для передачи данных из одного треда в другой тред.
Btw, советую ArchUnit, чтобы контролировать архитектуру. Не знаю если оно правда будет работать с Kotlin Multiplatform
https://www.baeldung.com/java-archunit-intro
По андроиду все понятно в принципе, а что насчет бэкенда? Особенно для вкатунцов, сложно ли найти первую работу?
Просто мне тут один знакомый с умным видом пытался доказать, что вкатунцы предпочитают java/go/python для бэка, поэтому вариант с kotlin в выигрыше, да и вообще это касается и опытных работяг
У нас бэк пишут на жабе. Вообще я бы был удивлен если бы встретил чистого Kotlin разработчика без знаний Java. То есть в вакансиях скорее всего будет указано Java/Kotlin или просто Java, но не один только Kotlin.
>Compose Multiplatform, причём под десктоп
Нихуя себе.
Сколько платят, какой грейд?
>поэтому вариант с kotlin в выигрыше
Так и вакух на котлин почти нет.
И вообще вкат уже всё, если хочешь найти место без такой ебанутой конкуренции, то тебе в девопсы
>За 10 лет вышел на баснословные 200к
Мисье, да вы наверное работу раз в 5 лет меняли (с фирмы "рога и копыта" на "копыта и рога")?
Первая работа - 15к. Спустя полтора года гребли дали "повышение" до 17к. Уволился и нашел вторую работу на 30к, там спустя 2 года дали повышение до 50к. Потом уволился и нашел уже за зарплату в 70к, спустя 3 года дали 90к. Ну и такими перебежками дошел до 200к сколько сейчас и получаю
Я так понимаю работа вся в маленьких провинциальный городах?
Первая работа в провинции в офисе. Остальные удаленка на ДС
>Рассматриваем kotlin в качестве альтернативы java 21 на бекенде.
зачем брать это говно если есть c# ?
Было весело, но я больше могу, такой лютой дрочи с грэдлом, кодогенерацией, асинхронщиной я больше не вывезу. Всем спасибо за ответы и общение, было весело.
Передаю привет мамаше разраба Coil'а. Либа дерьмище, не работает вообще. Сделал тестовое с этой либой, у меня всё работало, а у лида всё отшибло и в итоге сказали "мы вам перезвоним" 👍
Не сдавайся. Если уже дошёл до собеседований значит уже прошёл большой путь. Насчёт сторонних либ это везде так. Лучше брать что-то "старое", зато проверенное временем, чем новое, но забагованое.
О каких собесах идёт речь, my dude? ТЗшку кидают до собесов, а там тебя уже нахер шлют.
Я такую охеренную модульную архитектуру там расписал, даже расписал почему, но из-за РКН (забанили APIшку к тестовому заданию, там какой-то западный сервис был) и Coil'а всё пошло под откос. Конечно, я не буду отчаиваться слишком сильно. всё равно кидаюсь резюме в конторы, где нужен android, но перекатываться 100% буду. Я уже слишком стар для фронтенда, хочется писать на сишке/гошке, не думать про всякие новые фишечки в языке и просто писать код.
мейн язык как всегда java, котлин лишь на уровне знания синтаксиса требуют обычно.
У котлина вне андройда наверное нет, чем да
нету, после начала войны с котлина ушли ключевые разработчики.
мы решили от JVM стека отказываться в пользу c#
Смелое, но тупое решение, просто взять и перелопатить весь стек с миллионном человеко-часов кода. Если ты не фантазер, то беги от таких тимлидов, после завтра наденете чулки и будете бэкдора писать на расте, как писали три года на гошечке, через жонглирование прокси серверов.
Двачую.
Правда сам сейчас занимаюсь похожей малополезной активностью. Делаю рефакторинг здоровенного проекта, де-факто, пишу его заново. При этом можно было бы выкрутиться и через костыли его юзать не заглядывая внутрь, но когда выяснилось, что проект не реализует одну из нужных фичей, то я решил, что в пизду эти костыли и нужно просто переписать проект и реализовать недостающий функционал в нем.
Вариант с тем, чтобы фичу прикрутить сбоку выглядит максимально ненадежно. Проект сложный, автор любитель использовать наборы примитивов вместо классов, что приводит к интересным последствиям когда функции ожидают на вход набор чисел и строк с названиями "dd2", "s", "hc", "range". Шансы не накосячить крайне малы.
При этом это ещё лучшее решение, что есть в опенсоурсе. Остальные ещё хуже. Как не сложно догадаться область связана с навукой и код писали учёные, а не разработчики. К слову код выполняет задачу быстро, дерзко, мощно, каждый бит оптимизирован (написано на расте), есть даже документация публичного апи, но кодовая база это пиздец.
>просто взять и перелопатить
Зачем? У нас уже много лет параллельно разработка осуществляется и на джаве, и на с#.
Текущие проекты на java мы так же поддерживаем, никто их бросаться переписывать не будет.
Мы просто сели и подумали как-то, что дотнет получше будет, и новые проекты на нём пишем.
>и новые проекты на нём пишем.
Обычно новые проекты пишут на Расте, гыгыгы
За туже зарплату ипаться с двумя языками и совершенно разными экосистемами. Умно. беги оттуда
Котлин хотя бы прокси язык и сахаро-синтаксически, в какой-то мере, те же шарпы для джавы, даже современнее и приятнее (это признают и шарписты).
Я говорю, наверните еще раст и тайпскрипт, когда-нибудь бизнес научиться гнать вас в шею. Сишарп/дотнет, конечно, норм теха, но она никак не помогает иметь компетентность в профессии.
Без рофлов, почему нет? Наконец-то сделали нормальный С++ без боязни отстрелить себе писос одним неловким движением?
Производительность ебет все остальные языки. Синтаксис конечно не котлин, но я на нем пишу без крови из глаз в отличии от плюсов. ООП присутствует пусть и в немного непривычном виде. "Учиться" на нем писать не нужно, он буквально самочевиден, а в тех местах где нет, то статический анализатор в pedantic режиме объяснит почему не прав.
Единственный минус нет поддержки работы с cuda, но она экслюзивно только у плюсов сегодня есть.
> те же шарпы для джавы, даже современнее и приятнее
судя по практике нет. В котлине больше с градлом ебёшься, чем код пишешь. C# просто работает.
К счастью, сишарп остался в провинциальных галерках, заводах и одном банке
А Коклин где? Кроме Андроида, где его пропихивает без смазки Гугля
Градл ппц гибкий, в сторонних языках мне приходилось писать скрипты (нехер осваивать гредл методом тыка/SO/гпт и тогда все заработает другими красками).
> Градл ппц гибкий, в сторонних языках мне приходилось писать скрипты
А с гредлом пишешь грэдл плагины. Плюс только в том, что можно писать на котлине, а не на стопоннем недоязыке типа симейка.
>осваивать гредл
Пока освоишь гредл, он сам собой поломается, затем сам починится раз 10. При этом надо будет несколько раз обновить версию градла, затем откатить и выкачать пол интернета.
С каждым следующим проектом осваиваешь градл, иногда часа по два...
В дотнете я просто делаю dotnet build и всё
>нехер осваивать гредл методом тыка/SO/гпт
Ну, на самом деле что у градла что у мувена одна проблема - отсутствие документации. На сайте очень кривенькие гайды и какие-то обрывки сознания. Т.е. ты буквально пытаешься со слезами на глазах и сжимая от бессильной злобы зубы, написать рабочий помник или градл скрипт, который наконец соберет тебе проект так как нужно
Смотря сколько тебе лет.
Знаешь, что общего у AR-15 и градла?
кнопка-самопочиняйка