На самом деле проблема намного глубже и шире. Сводиться она к трем состовляющим: лени, жадности и тупости.
На уровне рынка: бизнес всеми силами создает условия чтобы у среднего разработчика было все меньше мотивации расти. Зарплата перестала коррелировать с знаниями и опытом и все больше стала зависеть от связей, умения себя нахваливать и врать.
На уровне компании: с ростом числа проектов - нужно и больше менеджеров, которых нет. Приходят слабые менеджеры, основное желание которых - скинуть с себя все обязанности на остальных. Отсюда мы получаем новый формат команд, человеко-оркестров, где каждый сам себе и аналитик и руководитель и скрам мастер. Естественно, такие руководители будут нанимать не, опытных а максимально удобных и приятных для себя людей. Далее, повышать зп будут не самых технически грамотным а самым удобным и приятным софт-скилистам. Как результат - отрицательный отбор, хардскиловые специалисты вымываются, а софтскиловые, понимающие что здесь мягко и тепло а за бортом не очень остаются.
На уровне проекта: слабые менеджеры не могут продавать заказчика, в результате, не самого высокого технического уровня ответственные софт-скилисты, начинаю в спешке писать еще более отвратительное говно не пытаясь спорить с руководством.
Вот отсюда по итогу и беруться Иваны из статьи, которые своими действиями по сути делают возвраточку бизнесу который для всего этого создал условия.
Через две недели и тысячи коммитов, ИИ радостно сообщит что у него лапки и нужен кожаный. Кожаный констатирует что за две недели было выполнено 100500 задач каждая их которых крутилась в цикле сансары и все ее коммиты перемерджены с тысячами коммитов других чудо задач. Оператор управления ИИ приходит к выводу что проще проект сжечь чем что-то откатывать или чинить.
Предлагаю на такие случаи выводить на экран довольную морду Бориса Черни.
Т.е. причина - она не техническая, но, скажем так, идеологическая. Это то, что я хотел сказать.
Я и не писал что они не могу это сделать технически я писал что не могут - фактически.
про специализацию там и нет ничего
Parametric JVM, specializing and optimizing generic class and method parameterizations at run time
Сама по себе Вальхалла - по большому счету - это как раз попытка поправить “костылики” в системе типов, которые “наросли” в Java за всё это время.
Нет. Это попытка сделать в духе C# со своей спецификой - добавить возможность иметь в рантайме типы значения и позволить использовать специализацию в дженериках вместо боксинга. Это исключительно задача для изменения JVM. нынешняя JVM ничего про дженерики не знает точно также как не может инлайнить данные друг в друга.
Сто лет в обед у них там все хорошо сделано изначально и работает. Ничего не понял что там внезапно выяснилось?
Любопытно. Но, не могли бы вы таки “поискать”?
Если попадется - обязательно скину.
?! Вы, имхо, не понимаете о чём говорите. Никакого прямого влияния на асинхронную обработку это не имеет.
История от колбэков NodeJs, горутин Go, корутин C# до виртуальных потоков Java это история - как удобно управлять асинхронностью. Асинхронная операция - это операция которая может быть прервана и выполнена позднее. В контексте Web это в основном сетевые запросы. Смысл виртуальных потоков - сделать эти операции неблокирующими из коробки вот и все. Какой то там философской дикой разницы нет, немного разный инструмент. Что корутины что горутины это удобный инструмент управления асинхронными задачами, не важно параллельно мы выполняем задачу на нашем процессоре или на другом сервере. Виртуальные потоки это просто оптимизация этого процесса. В старой Java для этого использовался отдельный поток и это было не эффективно а в новой доросли до возможностей не блокировать ОС поток. По сути очень близко к тому что в Go но менее удобно.
Достаточно того, что в “спецификацию Java” входит аnnotation processing (aka JSR-269) как таковой. Что, имхо, уже делает ваше утверждение насчет “что написано в коде плюс минус будет в байткоде” - немножечко некорректным.
Возможность не равно данность. Если я открываю голую Java то написанный код близок к байткоду если я открываю голый Kotlin, без всякого аnnotation processing и фреймворков это с порога не так.
Ну дык я про это и говорю. Кто-то не стал заморачиваться публикацией source jar, а стандартный javap для Kotlin и будет выдавать то самое “месиво”.
А мне как пользователю Kotlin какое дело? В Java я с таким не сталкиваюсь а в Kotlin сталкиваюсь - это единственное что важно.
Ну вот у F# с C# ровно такая же “проблема”, как у Kotlin с Java. Так понятней?
Какое мне дело до F#? Я пишу про Kotlin и Java. Если будем говорить про F# и C# то буду критиковать F#.
Вы - судя по всему - не понимаете как связан конкретный Kotlin с конкретным JDK. Эта связь настолько эфемерна, что можно утверждать, что её и нет никакой.
Т.е. никто вам не запретит писать на старом Kotlin под последний JDK.
И - ровно точно так же - никто не запретит использовать последний Kotlin (со всеми его фичами) на древней JDK, типа 1.8
Верите нет но большинству пользователей вообще фиолетово на это. Важно только тем у кого ограничения. Вот у KoltinJS, ну в теории то он есть и кто-то может писать на нем но вот на практике он практически никому не нужен как платформа.
Большинство пользователей заинтересовано работать на последней версии JVM и разработчики Kotlin вынуждены с этим считаться. Разработчики вынуждены считаться с всеми фичами новых JVM для того чтобы Kotlin работал оптимально. Можно сколько угодно рассказывать про теоретическую слабую связь с Java экосистемой но на практике эта связь сильная и вынуждает Kotlin следовать в этом мейнстриме как бы Вам не хотелось убедить себя в обратном.
И гораздо лучшей системой типов. Про это, почему-то всё время забывают.
Не нужно перехваливать. С Гораздо лучшей: Haskell, Scala, TypeScript, Rust. А Kotlin с чуть лучшей.
Вообще-то может. И более того, на старте это даже, имнип, рассматривалось. Но оно действительно ломает совместимость со стороны Java кода
Звучит как "Так то я тебе наваляю но просто не хочу". Если не сделали, значит в силу разных обстоятельств не могут. Никого не волнует что бы они в теории могли или не могли, волнует только то что есть и чего нет в языке.
с другой, покрывают львиную долю практической потребности в специализации.
Львиная доля потребности в специализации - это иметь нормальные, не тормозные коллекции и другие контейнеры. Именно этого все хотят и именно поэтому в Java их делают уже 12 лет. Если бы reified type parameters закрывали львиную долю потребностей в Java бы их ввели давно но на деле как раз менее важные потребности.
?! Если вы про ML-подобный (с deep deconstruction и т.п.) - так от него тоже отказались осознано, а не потому, что “невозможно”. На практике, PM в Kotlin (в гораздо более продвинутой форме) был (и есть) с самых первых версий. Он постоянно развивается, и - насколько я в курсе - даже в самой своей продвинутой форме (на данный момент) не требует никаких фич от JVM… т.е. вполне себе компилируется в “java 8”.
Был хороший доклад от Андрея Бреслав, лень искать, где он ответил на вопрос почему не сделали pattern matching. Ответ был такой: это очень муторная и сложная фича пользы от которой не так много, тем более в Java уже делают, мы дождемся пока они сделают, проанализируем и может быть сделаем.
А можно чуть подробнее про “приседания и костыли”? Реально интересно, чего вы там “такого” находили, что оно было нужно.
Spring и Hibernate требуют пустого публичного конструктора,что несовместимо с Kotlin без костылей в виде плагинов. Mockito из коробки нормально работать не будет. Jackson / Gson из коробки тоже нормально не работают. Могу ошибаться, но вроде бы с MyBatis были какие то проблемы в свое время. Таких либ достаточно которые без оберток-костылей не будет работать.
Вы зря сравниваете корутиты Kotlin и виртуальные потоки Java. Они - сильно “про разное”…
Нет, они про одно и тоже, про работу с асинхронными операциями. И главная проблема не в прикручивании чего-то к чему-то а в мейнстриме. В Java он в том чтобы ничего лишнего не писать и оно само под капотом будет работать, большинство библиотек будут поддерживать Java подход и будет идти вразрез с Kotlin.
Даже в Kotlin JVM есть вещи, которые, скажем так, не дружат с “миром JVM”. Но они там, есть, т.к. с точки зрения развития языка “это нам нада”(с).
Компилятор Kotlin генерирует байткод который не поддерживается JVM но она его по старой дружбе всеравно выполняет?
О да. Особенно - на практике :-) Вы не используете annotation processing? Ну там Spring и/или Lombok? Реально? А что вы такое пишете на Java?
Spring и Lombok входят в спецификацию Java?
?! А можно по подробнее, об чём речь? Емнип, правила аллокации в Kotlin полностью аналогичны таким же в Java. Зачем в бейткод-то смотреть?
Вот я напишу Вам Int а вы скажите, это примитивный тип или ссылочный?
Тут вообще не понятно “про что”. Если вы про то, что “стандартные” java decompiler’ы сильно плохо дружат с Kotlin - то есть такое. Но есть же специализированные инструменты для.
Я захожу в исходники через инструмент который написала компания который этот язык и сделала и часто вижу или месиво нечитаемое или вообще отсутствие реализации как будто бы я в C. Можно ли запариваться, использовать специальные инструменты? Можно. Но вот почему то в Java у меня таких проблем нет и в C# тоже а в Kotlin есть.
:-) Рискую открыть вам “страшную тайну”, но даже kotlin 2.3 (самая новая, на данный момент версия языка) компилируется в JDK 1.8 без особых ограничений по, собственно, фичам Kotlin’а. Ну да… какие-то платформозависимые (типа @JvmRecords) аннотации становятся не доступны - но и только.
Рискую тоже открыть тайну - мало кому интересен язык который будет крутиться на устаревшей платформе, поддержка которой через какое-то то время закончиться.
Это я к тому, что самому Kotlin JVM от самой JVM “много не нужно”.
В теории да, на практике - очень нужно. Никто в здравом уме при нормальных обстоятельствах не выберет между последней версией Java и свежим JDK и Kotlin на старой 1.8 в пользу последнего.
Да, все так. Чудовищной ошибкой Microsoft было делать C# только под Windows. Жадность покоя не давала. Только в 2016 одумались и сделали кроссплатформу. Хоть доля C# на рынке большая до Java естественно не дотягивает. Но как язык и платформа C#/.net это прям пример как нужно делать.
ps. Занимательный забавный факт.
Java опередила C# за счет кроссплатформенности в свое время. Но если посмотреть сейчас, то почти все что пишут на Java это корпоративный бэкенды. Ну и мобилки (Kotlin). В то время как на C# пишут и бэкенды и фронтенды и десктопы и игры и CLI утилиты и чего только не пишут.
Котлин мультиплатформенный язык так-то, JVM, LLVM, JS, WASM.
Существует небольшая разница между может и нужен. Scala вон тоже все может, другой вопрос что про знаменитое использование Scala на фронтенде мы чего-то не слышим. В Kotlin все это делали, разумеется и если бы взлетело, у языка было бы сильно больше смысла. Но не взлетело. По факту сейчас Kotlin это андроид, немного backend и еще меньше KPM. Остальным не зашло.
Ну так и у Джавы с этим все стабильно плохо. В dotnet уже как с десяток лет существуют обобщения на уровне рантайма, а в джаве мы продолжаем затирать типы во время компиляции.
Какой смысл говорить что у Java проблемы если язык который ее должен заменить не может решить эти проблемы? И открою секрет, не могут не потому что глупые а потому что зависимы от JVM, не смотря на всю мультиплатформенность. И во многих фичах всегда будут ограничены и придется ждать пока лет через 100 лет не сделают в Java.
Тоже спорно, VT конечно лучше обычных потоков, но утилизация процессора на еденицу работы у него кратно хуже, чем у WebFlux, Coroutines. У VT RPS ниже, p99, p95 задержки выше, чем у последних двух. А нормального structured concurency так до сих пор и нету, JEP сидит в инкубаторе с 20 JDK. В Котлине это идет из коробки и будет попроще для восприятия.
Мне тоже корутины нравятся больше, но вопрос не в этом. Вопрос в том что VM это ментрим который диктует Java и который влияет на всю экосистему Java с которой Kotlin вынужден считаться.
Совместимость у Котлина с джавой лучшая в своем классе. Для ознакомления советую попробовать написать обертки с Жабы на Скалу, интересное занятие, которое никому не порекомендую.
Здорово. Но у Java, с Java экосистемой, совместимость еще лучше. Человека выбирающего между Java и Kotlin мало будет интересовать что там у Scala.
Да не уже-ли? For each итератор по списку сгенерирует одинаковый байткод как на Java, так и на Kotlin. Если хотите предсказуемый байткод, так и пишите простой и предсказуемый код, в документации все описанно, где, что и когда генерируется.
-А что это у нас тут написано?
x : Int
-Это целое число. -Этот ссылочный или примитивный тип? -Да.
Я это все к чему. Котлин в первую очередь проектировался для снижения нагрузки для разработчика и утверждение, что Котлин это просто сахарок от части верно. Но Котлину уже 15-ый год стукнул, за это время он успел обрасти своими уникальными фишками и экосистемой, а после перехода на K2 перед разработчиками открылись двери для введения новых фишек по типу Error types | Unions, позволяющих отказаться от try catch в пользу более понятных ошибок, отлавливаемых еще на этапе компиляции.
Смысл языка в его концептуальной модели, т.е. в ответ на вопрос - а зачем его вообще создали а не выбрали уже существующее решение. К примеру Scala тоже на JVM но концептуальная модель Scala - гибрид ООП + ФП на JVM. У Clojure идея уже про более простую и практичную интерпретацию ФП на JVM. Каждый из этих языков концептуально самодостаточен и особо в этом не пересекается с Java или JVM или друг другом. Также, концептуальная модель есть и у Java, что дико разделяет ее с модельную C#. У других языков все тоже самое. Но вот когда доходит до Kotlin все становиться не понятно. Язык сделали для собственных нужд. Делали по принципу - а давайте понапихайем со всех языков модных фич. Выстрелило на андроид по историческим причинам (привет Java7). Потом придумали концепцию - пишем все на Kotlin. Идея не взлетела. И по итогу остался язык который, добавляет свистоперделки, с которыми в целом прикольно но можно и без них, но который не решил многих важных проблем Java и вынужден ждать когда она решит их сама, и который вообще не может выбежать за само развитие Java. Они сделали Error types | Unions? А концептуально оно где должно встать в языке где все на исключениях? В какой-нибудь Scala это сто лет в обед есть и даже больше. Kotlin пере-Java недо-Scala? Или это очередной прием из серии - давайте возьмем модную фичу и запихнем в язык? В конце концов - проектировался для снижения нагрузки для разработчика? Получилось? Ну спорно. С одной стороны добавилось модных фич, коду стало меньше. С другой появились фичи которые это нагрузку только повышают а в "умелых" руках вообще позволяют писать ахтунг. Концептуально, ничего такого критического, чтобы отвечало на вопрос зачем переходить с Java на Kotlin, на данный момент нет. Только свистоперделки и по приколу.
Ну поправьте если не так но я не наблюдаю сколь значимого интереса у публики, ни ни в виде статей, ни в виде видео, ни на конференциях, ни на проектах. А вот критики хватает. Где то есть немного KMM, но такое чтобы у проекта был и back и web-frontend и мобилки и desktop на KMP скорее на экзотику тянет чем на что-то серьезное. И я молчу что по сравнению с каким нибудь React-native или Flutter, KMP позиции очень слабые.
Используется ли оно? Используется. Можно ли сказать что идея выстрелила и стала мейнстримной, что можно массово наблюдать целые проекты полностью написанные на Kotlin? Однозначно - нет.
Язык без какой либо уникальной идеи или киллер-фичи. Просто Java с лучшим синтаксисом.
Полная зависимость от JVM мира. Java может позволить продвигать новые фичи через оптимизацию механизмов JVM. Kotlin только через кодогенерацию и костыли. Kotlin не может позволить себе реализовать такие вещи как специализацию для дженериков или нормальный петтерн-матчинг, потому что придется угробить на это ресурсы а потом сделают в Java более оптимально и повториться история с корутинами. Kotlin вынужден считаться с JVM поэтому никогда не сможет качественно обогнать Java и вынужден быть завязан на ее жизненный цикл. Медленно, но с каждой новой фичей в Java, смысла в Kotlin все меньше а предоставить что-то качественно иное он не может по описанным выше причинам.
По поводу производительности, можно просто написать Int и попросить кого-нибудь ответить на вопрос где это число будет размещено в памяти. Без похода в байткод не разобраться.
Совместимость? Хреновая. Можно сколько угодно рассказывать про безопастность по null и наследующем шаге отстрелить себе ноги в любом месте где есть вызов Java кода. И это еще хуже так как от not null типа вообще не ожидаешь NPE, а оно будет. Также большинство либ рассчитано под Java и не все без приседаний и костылей будет работать.
Очевидность и понятность языка - хреновая. В Java, при всех ее минусах, то что написано в коде плюс минус будет в байткоде. Kotlin вам вообще ничего и нигде не гарантирует. Любите читать исходники? Если повезет почитаете не месиво. Если не поведет исходники вы вообще не увидите.
Вот и получается язык без какой то внятной причины для существования. С каждый шагом когда Java медленно но верно завозит сахар, смыла в этом еще меньше. Язык который не имеет контроль над основной своей платформой и в следствии чего вечный аутсайдер. Лет 5-6 назад, когда были надежды что это будет язык для всех платформ и на нем можно будет делать от бэка до мобилок, фронтов до десктопов - звучало несколько интригующе и смело. Сейчас, когда понятно что загнулись все платформы кроме андроида и JVM, ну такое себе.
Так а что нужно делать на Го по вашему мнению в сложном домене?
Использовать методики и средства в соответствии с инструментами. Если философия Go банальность и простота то нужно использовать максимально линейные и простые подходы чтобы развить сильные стороны и избегать слабых.
Кубер это чисто техническая тулза. Сложная, да, но не с доменной точки зрения. Модели в среднестатистическом электронном документообороте будут по поведению и машине состояний в разы сложнее, чем модели в кубере.
Давайте будем честны. Если на проекте будет действительно сложная бизнес-логика, то она уедет на какой-то вариант внешнего или самописного BPMN где ей будут уже заниматься аналитики, это и проще и правильнее чем в коде изображать сложный бизнес. Если на проекте будет действительно сложная бизнес-логика, то весь ООП пойдет на помойку. Даже банальный Update большого количества записей скорей всего будет описан запросом, а не вытаскиванием из базы избыточных данных чтобы методы подергать. Если еще сложнее, то там уже информация будет строиться в специальные структуры данных которые можно быстро обрабатывать и удобно хранить.
Все эти игры в эмуляцию бизнес-объектов подходят только для тепличных условий, где в действительности большой сложности и нет и где DDD подход имеет сомнительную эффективность но вполне заметные издержки.
В том то и дело, что ООП это буквально высокоуровневая надстройка над средствами менеджмента данных, которая позволяет заниматься бизнес-моделированием и немного забить на техническую часть (то, как именно данные хранятся и передаются).
Вот только если посмотреть правде в глаза, за много десятилетий существования ООП, мы видим его вырождение. Большая часть backend проектов это про anemic model. Frontend/Mobile/Desktop(вот уже где самое место) практически поголовно отошли от ООП подхода. Уже много лет в языки ничего ООП-шного не добавляется а некоторые новые языки вообще отказались от этой парадигмы. И это не потому что ООП плохое. Оно очень узко местечковое, также как и ФП и нельзя на нем строить системы. Можно долго спорить но факты есть факты.
Зачем нести туда не-ООП язык? Ради моды?
Затем что мир не крутиться вокруг ООП и не крутиться вокруг архитектурных рюшечек. Есть и другие требования для проектов.
А кто решает если не разработчики? Бизнес приходит и говорит: "используете обязательно DDD"? Да бизнес это вообще не волнует. На Go можно писать хоть легкий домен хоть сложный домен хоть Kubernetes, если руки из правильного места.
Проблема в том что в языке не успела сформироваться культура написания таких проектов а "мигранты" по больше части ничего кроме ООП, слоистых архитектур, чистых кодом, интерфейса на каждый чих и прочего мракобесия не видели и не умеют, вот они и начинают строить джаву в абсолютно другом языке, с другими свойствами, плюсами и минусами, закономерно получая кусок говна. Потому что в Go нужно вывозить за счет минимализма который язык дает и тупой как доска простоты и банальности. А на деле, подумаешь в Go нет классического ООП - будем изображать накручивая костыли, подумаешь в Go нет средств упрощения абстракций - конечно же будем городить 10 слойные архитектуры, писать кучу бойлерплейта там где его нечем победить, подумаешь в Go совершенно другой механизм как работы так и философии интерфейсов - пофиг будем делать как в Java.
Не в бизнесе это дело а в людях который пришли со своим уставом в чужой монастырь. Такая же ровно история когда такие уходят в JS/TS или например в Rust.
Тут вообще нужно смотреть с другой стороны. JS изначально даже не классический ООП язык. То что к нему впоследствии приделали классы сделало еще хуже. Получилась еще более кривая и проблемная пародия на Java. И вот из одной крайности, сообщество повело в другую. В ФП. Почему? Потому что это закрывает многие базовые проблемы JS. Например, функции как единицы построения программы подходят куда лучше кривых и проблемных объектов и классов в JS. Еще более важным моментом является использование концепции иммутабельности данных для закрытия проблем с работой в асинхронной среде.
По поводу отсутствия хвостовой рекурсии, типов высших порядков, отсутствия паттерн матчинга - это все фигня и вообще не показатель функционального языка. Это скорей критерии чистого Haskell-подобного языка. Взять Scala, там исключений нет или есть мутабельность по умолчанию? Да там половина языка Java подобна, о чем говорить. В том же Clojure исключения есть, нет никакиких pattern matching, никаких игр с монадами и Higher-Kinded Types.
По мне главные критерии ФП языка - это все-таки неизменяемость из коробки и логика языка в которой программа строиться вокруг функции как основного юнита.
Главная проблема в сообществе JS - это попытка играть во "взрослый/чистый" ФП подобный Haskell не имея никаких средств поддержки языка. Отсюда выходит весь ад. Попытки играть в каррирование, в монады превращает код в адское нечитаемое месиво. Но это не особенность JS. На одном из проектов встретил точно такой же подход в Java, где начинались модных ФП книг и пошли эмулировать монады и каррирование, как итог - еще хуже чем то что я видел в JS.
Понятно что JS - это не ФП язык. Но не нужно все мерить по Haskell. JS/TS в такой ситуации, что разумная доля ФП подхода без перебора пока что дает сильно больше преимуществ чем другие подходы. Вопрос лишь в адекватных рамках этого.
При разработке Go авторы сделали все чтобы язык был максимально прямолинейным и простым, местами до тупости. Не все получилось просто но зато получилось сделать язык с максимально коротким сроком обучения. Что позволили ему быстро набрать популярность за счет переучивающихся разработчиков с других языков.
Но вот произошла типичная история про мигрантов - бежим из страны в которой невозможно жить чтобы в новой стране воссоздать ту страну из которой сбежали.
Так же по факту произошло и с Go. Сбежавшие джависты и еже с ними, уставшие от задравшего всех многословного переабстрагированного энтерпрайз подхода, принялись в Go строить заново все то от чего убегали.
По итогу Go, где пожертвовали всем ради простоты, с таким подходом превращается в кусок говна. Так как не остается ни простоты ни удобства.
Возможно, когда-то, когда трава была зеленее, когда не было таких зп и люди шли на заниматься там чем им интересно, это можно было бы назвать частично правдой.
Но уже очень много лет как, средний IT-специалист - это больше гуманитарий без какого-то нестандартного мышления, ибо просто пришел в сферу где платят больше, а учитывая что менеджеры сейчас поощряют свот-скилы куда больше чем хард - это все кратно ухудшает.
Яркий пример деградации в IT сфере - очень многие современные менеджеры не вывозят свои позиции ни по навыкам ни по компетенциям ни по лидерским качествам, поэтому пытаются скинуть как можно больше своих обязанностей и ответственности на команду. Такой менеджер всегда в первую очередь будет искать послушных, покладистых и беспроблемных разработчиков, которые будут делать за него его работу вместо технически грамотных специалистов. Потому что с последними придется считаться, спорить, заниматься сложной менеджерской деятельностью, вместо это можно просто нанимать приятных людей которые будут все делать за тебя, оправдывая это аджайлом, командностью, ответственностью и взаимозаменяемостью. Рыба всегда гниет с головы.
На самом деле проблема намного глубже и шире. Сводиться она к трем состовляющим: лени, жадности и тупости.
На уровне рынка: бизнес всеми силами создает условия чтобы у среднего разработчика было все меньше мотивации расти. Зарплата перестала коррелировать с знаниями и опытом и все больше стала зависеть от связей, умения себя нахваливать и врать.
На уровне компании: с ростом числа проектов - нужно и больше менеджеров, которых нет. Приходят слабые менеджеры, основное желание которых - скинуть с себя все обязанности на остальных. Отсюда мы получаем новый формат команд, человеко-оркестров, где каждый сам себе и аналитик и руководитель и скрам мастер. Естественно, такие руководители будут нанимать не, опытных а максимально удобных и приятных для себя людей.
Далее, повышать зп будут не самых технически грамотным а самым удобным и приятным софт-скилистам. Как результат - отрицательный отбор, хардскиловые специалисты вымываются, а софтскиловые, понимающие что здесь мягко и тепло а за бортом не очень остаются.
На уровне проекта: слабые менеджеры не могут продавать заказчика, в результате, не самого высокого технического уровня ответственные софт-скилисты, начинаю в спешке писать еще более отвратительное говно не пытаясь спорить с руководством.
Вот отсюда по итогу и беруться Иваны из статьи, которые своими действиями по сути делают возвраточку бизнесу который для всего этого создал условия.
Через две недели и тысячи коммитов, ИИ радостно сообщит что у него лапки и нужен кожаный. Кожаный констатирует что за две недели было выполнено 100500 задач каждая их которых крутилась в цикле сансары и все ее коммиты перемерджены с тысячами коммитов других чудо задач. Оператор управления ИИ приходит к выводу что проще проект сжечь чем что-то откатывать или чинить.
Предлагаю на такие случаи выводить на экран довольную морду Бориса Черни.
Я и не писал что они не могу это сделать технически я писал что не могут - фактически.
Нет. Это попытка сделать в духе C# со своей спецификой - добавить возможность иметь в рантайме типы значения и позволить использовать специализацию в дженериках вместо боксинга. Это исключительно задача для изменения JVM. нынешняя JVM ничего про дженерики не знает точно также как не может инлайнить данные друг в друга.
Сто лет в обед у них там все хорошо сделано изначально и работает. Ничего не понял что там внезапно выяснилось?
Если попадется - обязательно скину.
История от колбэков NodeJs, горутин Go, корутин C# до виртуальных потоков Java это история - как удобно управлять асинхронностью.
Асинхронная операция - это операция которая может быть прервана и выполнена позднее. В контексте Web это в основном сетевые запросы. Смысл виртуальных потоков - сделать эти операции неблокирующими из коробки вот и все. Какой то там философской дикой разницы нет, немного разный инструмент. Что корутины что горутины это удобный инструмент управления асинхронными задачами, не важно параллельно мы выполняем задачу на нашем процессоре или на другом сервере. Виртуальные потоки это просто оптимизация этого процесса. В старой Java для этого использовался отдельный поток и это было не эффективно а в новой доросли до возможностей не блокировать ОС поток. По сути очень близко к тому что в Go но менее удобно.
Возможность не равно данность. Если я открываю голую Java то написанный код близок к байткоду если я открываю голый Kotlin, без всякого аnnotation processing и фреймворков это с порога не так.
А мне как пользователю Kotlin какое дело? В Java я с таким не сталкиваюсь а в Kotlin сталкиваюсь - это единственное что важно.
Какое мне дело до F#? Я пишу про Kotlin и Java. Если будем говорить про F# и C# то буду критиковать F#.
Верите нет но большинству пользователей вообще фиолетово на это. Важно только тем у кого ограничения. Вот у KoltinJS, ну в теории то он есть и кто-то может писать на нем но вот на практике он практически никому не нужен как платформа.
Большинство пользователей заинтересовано работать на последней версии JVM и разработчики Kotlin вынуждены с этим считаться. Разработчики вынуждены считаться с всеми фичами новых JVM для того чтобы Kotlin работал оптимально. Можно сколько угодно рассказывать про теоретическую слабую связь с Java экосистемой но на практике эта связь сильная и вынуждает Kotlin следовать в этом мейнстриме как бы Вам не хотелось убедить себя в обратном.
Не нужно перехваливать. С Гораздо лучшей: Haskell, Scala, TypeScript, Rust. А Kotlin с чуть лучшей.
Звучит как "Так то я тебе наваляю но просто не хочу". Если не сделали, значит в силу разных обстоятельств не могут. Никого не волнует что бы они в теории могли или не могли, волнует только то что есть и чего нет в языке.
Львиная доля потребности в специализации - это иметь нормальные, не тормозные коллекции и другие контейнеры. Именно этого все хотят и именно поэтому в Java их делают уже 12 лет. Если бы reified type parameters закрывали львиную долю потребностей в Java бы их ввели давно но на деле как раз менее важные потребности.
Был хороший доклад от Андрея Бреслав, лень искать, где он ответил на вопрос почему не сделали pattern matching. Ответ был такой: это очень муторная и сложная фича пользы от которой не так много, тем более в Java уже делают, мы дождемся пока они сделают, проанализируем и может быть сделаем.
Spring и Hibernate требуют пустого публичного конструктора,что несовместимо с Kotlin без костылей в виде плагинов.
Mockito из коробки нормально работать не будет.
Jackson / Gson из коробки тоже нормально не работают.
Могу ошибаться, но вроде бы с MyBatis были какие то проблемы в свое время.
Таких либ достаточно которые без оберток-костылей не будет работать.
Нет, они про одно и тоже, про работу с асинхронными операциями. И главная проблема не в прикручивании чего-то к чему-то а в мейнстриме. В Java он в том чтобы ничего лишнего не писать и оно само под капотом будет работать, большинство библиотек будут поддерживать Java подход и будет идти вразрез с Kotlin.
Компилятор Kotlin генерирует байткод который не поддерживается JVM но она его по старой дружбе всеравно выполняет?
Spring и Lombok входят в спецификацию Java?
Вот я напишу Вам Int а вы скажите, это примитивный тип или ссылочный?
Я захожу в исходники через инструмент который написала компания который этот язык и сделала и часто вижу или месиво нечитаемое или вообще отсутствие реализации как будто бы я в C. Можно ли запариваться, использовать специальные инструменты? Можно. Но вот почему то в Java у меня таких проблем нет и в C# тоже а в Kotlin есть.
Рискую тоже открыть тайну - мало кому интересен язык который будет крутиться на устаревшей платформе, поддержка которой через какое-то то время закончиться.
В теории да, на практике - очень нужно. Никто в здравом уме при нормальных обстоятельствах не выберет между последней версией Java и свежим JDK и Kotlin на старой 1.8 в пользу последнего.
Да, все так. Чудовищной ошибкой Microsoft было делать C# только под Windows. Жадность покоя не давала. Только в 2016 одумались и сделали кроссплатформу. Хоть доля C# на рынке большая до Java естественно не дотягивает. Но как язык и платформа C#/.net это прям пример как нужно делать.
ps. Занимательный забавный факт.
Java опередила C# за счет кроссплатформенности в свое время. Но если посмотреть сейчас, то почти все что пишут на Java это корпоративный бэкенды. Ну и мобилки (Kotlin). В то время как на C# пишут и бэкенды и фронтенды и десктопы и игры и CLI утилиты и чего только не пишут.
В теории то оно понятно, там и Scala в JS умеет. На практике в реальной жизни это либо андроид либо backend т.е. один к одному с джавой.
Тогда лучше не пробовать C#. Можно словить разочарование от осознания - насколько на самом деле все нормально и удобно можно было сделать.
Первый раз такое слышу. тимсити - детище JB не удивительно
Т.е. Kotlin это язык для frontend? Или в чем задачи разные?
Очень интересно было бы узнать под какие такие разные задачи, языки которые крутятся на одном и том же рантайме и отличаются только синтаксисом?
Существует небольшая разница между может и нужен. Scala вон тоже все может, другой вопрос что про знаменитое использование Scala на фронтенде мы чего-то не слышим. В Kotlin все это делали, разумеется и если бы взлетело, у языка было бы сильно больше смысла. Но не взлетело. По факту сейчас Kotlin это андроид, немного backend и еще меньше KPM. Остальным не зашло.
Какой смысл говорить что у Java проблемы если язык который ее должен заменить не может решить эти проблемы? И открою секрет, не могут не потому что глупые а потому что зависимы от JVM, не смотря на всю мультиплатформенность. И во многих фичах всегда будут ограничены и придется ждать пока лет через 100 лет не сделают в Java.
Мне тоже корутины нравятся больше, но вопрос не в этом. Вопрос в том что VM это ментрим который диктует Java и который влияет на всю экосистему Java с которой Kotlin вынужден считаться.
Здорово. Но у Java, с Java экосистемой, совместимость еще лучше. Человека выбирающего между Java и Kotlin мало будет интересовать что там у Scala.
-А что это у нас тут написано?
-Это целое число.
-Этот ссылочный или примитивный тип?
-Да.
Смысл языка в его концептуальной модели, т.е. в ответ на вопрос - а зачем его вообще создали а не выбрали уже существующее решение. К примеру Scala тоже на JVM но концептуальная модель Scala - гибрид ООП + ФП на JVM. У Clojure идея уже про более простую и практичную интерпретацию ФП на JVM. Каждый из этих языков концептуально самодостаточен и особо в этом не пересекается с Java или JVM или друг другом. Также, концептуальная модель есть и у Java, что дико разделяет ее с модельную C#. У других языков все тоже самое. Но вот когда доходит до Kotlin все становиться не понятно. Язык сделали для собственных нужд. Делали по принципу - а давайте понапихайем со всех языков модных фич. Выстрелило на андроид по историческим причинам (привет Java7).
Потом придумали концепцию - пишем все на Kotlin. Идея не взлетела. И по итогу остался язык который, добавляет свистоперделки, с которыми в целом прикольно но можно и без них, но который не решил многих важных проблем Java и вынужден ждать когда она решит их сама, и который вообще не может выбежать за само развитие Java.
Они сделали Error types | Unions? А концептуально оно где должно встать в языке где все на исключениях? В какой-нибудь Scala это сто лет в обед есть и даже больше. Kotlin пере-Java недо-Scala? Или это очередной прием из серии - давайте возьмем модную фичу и запихнем в язык?
В конце концов - проектировался для снижения нагрузки для разработчика? Получилось? Ну спорно. С одной стороны добавилось модных фич, коду стало меньше. С другой появились фичи которые это нагрузку только повышают а в "умелых" руках вообще позволяют писать ахтунг.
Концептуально, ничего такого критического, чтобы отвечало на вопрос зачем переходить с Java на Kotlin, на данный момент нет. Только свистоперделки и по приколу.
Ну поправьте если не так но я не наблюдаю сколь значимого интереса у публики, ни ни в виде статей, ни в виде видео, ни на конференциях, ни на проектах. А вот критики хватает. Где то есть немного KMM, но такое чтобы у проекта был и back и web-frontend и мобилки и desktop на KMP скорее на экзотику тянет чем на что-то серьезное. И я молчу что по сравнению с каким нибудь React-native или Flutter, KMP позиции очень слабые.
Используется ли оно? Используется.
Можно ли сказать что идея выстрелила и стала мейнстримной, что можно массово наблюдать целые проекты полностью написанные на Kotlin? Однозначно - нет.
А в чем заковыристость, если не секрет?
Разуметься. Проблема в том что Kotlin Multiplatform не взлетел.
Реальность:
Язык без какой либо уникальной идеи или киллер-фичи. Просто Java с лучшим синтаксисом.
Полная зависимость от JVM мира. Java может позволить продвигать новые фичи через оптимизацию механизмов JVM. Kotlin только через кодогенерацию и костыли. Kotlin не может позволить себе реализовать такие вещи как специализацию для дженериков или нормальный петтерн-матчинг, потому что придется угробить на это ресурсы а потом сделают в Java более оптимально и повториться история с корутинами. Kotlin вынужден считаться с JVM поэтому никогда не сможет качественно обогнать Java и вынужден быть завязан на ее жизненный цикл. Медленно, но с каждой новой фичей в Java, смысла в Kotlin все меньше а предоставить что-то качественно иное он не может по описанным выше причинам.
По поводу производительности, можно просто написать Int и попросить кого-нибудь ответить на вопрос где это число будет размещено в памяти. Без похода в байткод не разобраться.
Совместимость? Хреновая. Можно сколько угодно рассказывать про безопастность по null и наследующем шаге отстрелить себе ноги в любом месте где есть вызов Java кода. И это еще хуже так как от not null типа вообще не ожидаешь NPE, а оно будет. Также большинство либ рассчитано под Java и не все без приседаний и костылей будет работать.
Очевидность и понятность языка - хреновая. В Java, при всех ее минусах, то что написано в коде плюс минус будет в байткоде. Kotlin вам вообще ничего и нигде не гарантирует. Любите читать исходники? Если повезет почитаете не месиво. Если не поведет исходники вы вообще не увидите.
Вот и получается язык без какой то внятной причины для существования. С каждый шагом когда Java медленно но верно завозит сахар, смыла в этом еще меньше. Язык который не имеет контроль над основной своей платформой и в следствии чего вечный аутсайдер.
Лет 5-6 назад, когда были надежды что это будет язык для всех платформ и на нем можно будет делать от бэка до мобилок, фронтов до десктопов - звучало несколько интригующе и смело. Сейчас, когда понятно что загнулись все платформы кроме андроида и JVM, ну такое себе.
Использовать методики и средства в соответствии с инструментами. Если философия Go банальность и простота то нужно использовать максимально линейные и простые подходы чтобы развить сильные стороны и избегать слабых.
Давайте будем честны.
Если на проекте будет действительно сложная бизнес-логика, то она уедет на какой-то вариант внешнего или самописного BPMN где ей будут уже заниматься аналитики, это и проще и правильнее чем в коде изображать сложный бизнес.
Если на проекте будет действительно сложная бизнес-логика, то весь ООП пойдет на помойку. Даже банальный Update большого количества записей скорей всего будет описан запросом, а не вытаскиванием из базы избыточных данных чтобы методы подергать. Если еще сложнее, то там уже информация будет строиться в специальные структуры данных которые можно быстро обрабатывать и удобно хранить.
Все эти игры в эмуляцию бизнес-объектов подходят только для тепличных условий, где в действительности большой сложности и нет и где DDD подход имеет сомнительную эффективность но вполне заметные издержки.
Вот только если посмотреть правде в глаза, за много десятилетий существования ООП, мы видим его вырождение. Большая часть backend проектов это про anemic model. Frontend/Mobile/Desktop(вот уже где самое место) практически поголовно отошли от ООП подхода. Уже много лет в языки ничего ООП-шного не добавляется а некоторые новые языки вообще отказались от этой парадигмы. И это не потому что ООП плохое. Оно очень узко местечковое, также как и ФП и нельзя на нем строить системы. Можно долго спорить но факты есть факты.
Затем что мир не крутиться вокруг ООП и не крутиться вокруг архитектурных рюшечек. Есть и другие требования для проектов.
А кто решает если не разработчики? Бизнес приходит и говорит: "используете обязательно DDD"? Да бизнес это вообще не волнует. На Go можно писать хоть легкий домен хоть сложный домен хоть Kubernetes, если руки из правильного места.
Проблема в том что в языке не успела сформироваться культура написания таких проектов а "мигранты" по больше части ничего кроме ООП, слоистых архитектур, чистых кодом, интерфейса на каждый чих и прочего мракобесия не видели и не умеют, вот они и начинают строить джаву в абсолютно другом языке, с другими свойствами, плюсами и минусами, закономерно получая кусок говна. Потому что в Go нужно вывозить за счет минимализма который язык дает и тупой как доска простоты и банальности. А на деле, подумаешь в Go нет классического ООП - будем изображать накручивая костыли, подумаешь в Go нет средств упрощения абстракций - конечно же будем городить 10 слойные архитектуры, писать кучу бойлерплейта там где его нечем победить, подумаешь в Go совершенно другой механизм как работы так и философии интерфейсов - пофиг будем делать как в Java.
Не в бизнесе это дело а в людях который пришли со своим уставом в чужой монастырь. Такая же ровно история когда такие уходят в JS/TS или например в Rust.
Тут вообще нужно смотреть с другой стороны. JS изначально даже не классический ООП язык. То что к нему впоследствии приделали классы сделало еще хуже. Получилась еще более кривая и проблемная пародия на Java. И вот из одной крайности, сообщество повело в другую. В ФП. Почему? Потому что это закрывает многие базовые проблемы JS. Например, функции как единицы построения программы подходят куда лучше кривых и проблемных объектов и классов в JS. Еще более важным моментом является использование концепции иммутабельности данных для закрытия проблем с работой в асинхронной среде.
По поводу отсутствия хвостовой рекурсии, типов высших порядков, отсутствия паттерн матчинга - это все фигня и вообще не показатель функционального языка. Это скорей критерии чистого Haskell-подобного языка. Взять Scala, там исключений нет или есть мутабельность по умолчанию? Да там половина языка Java подобна, о чем говорить. В том же Clojure исключения есть, нет никакиких pattern matching, никаких игр с монадами и Higher-Kinded Types.
По мне главные критерии ФП языка - это все-таки неизменяемость из коробки и логика языка в которой программа строиться вокруг функции как основного юнита.
Главная проблема в сообществе JS - это попытка играть во "взрослый/чистый" ФП подобный Haskell не имея никаких средств поддержки языка. Отсюда выходит весь ад. Попытки играть в каррирование, в монады превращает код в адское нечитаемое месиво. Но это не особенность JS. На одном из проектов встретил точно такой же подход в Java, где начинались модных ФП книг и пошли эмулировать монады и каррирование, как итог - еще хуже чем то что я видел в JS.
Понятно что JS - это не ФП язык. Но не нужно все мерить по Haskell. JS/TS в такой ситуации, что разумная доля ФП подхода без перебора пока что дает сильно больше преимуществ чем другие подходы. Вопрос лишь в адекватных рамках этого.
Забавная ирония судьбы.
При разработке Go авторы сделали все чтобы язык был максимально прямолинейным и простым, местами до тупости. Не все получилось просто но зато получилось сделать язык с максимально коротким сроком обучения. Что позволили ему быстро набрать популярность за счет переучивающихся разработчиков с других языков.
Но вот произошла типичная история про мигрантов - бежим из страны в которой невозможно жить чтобы в новой стране воссоздать ту страну из которой сбежали.
Так же по факту произошло и с Go. Сбежавшие джависты и еже с ними, уставшие от задравшего всех многословного переабстрагированного энтерпрайз подхода, принялись в Go строить заново все то от чего убегали.
По итогу Go, где пожертвовали всем ради простоты, с таким подходом превращается в кусок говна. Так как не остается ни простоты ни удобства.
Возможно, когда-то, когда трава была зеленее, когда не было таких зп и люди шли на заниматься там чем им интересно, это можно было бы назвать частично правдой.
Но уже очень много лет как, средний IT-специалист - это больше гуманитарий без какого-то нестандартного мышления, ибо просто пришел в сферу где платят больше, а учитывая что менеджеры сейчас поощряют свот-скилы куда больше чем хард - это все кратно ухудшает.
Яркий пример деградации в IT сфере - очень многие современные менеджеры не вывозят свои позиции ни по навыкам ни по компетенциям ни по лидерским качествам, поэтому пытаются скинуть как можно больше своих обязанностей и ответственности на команду. Такой менеджер всегда в первую очередь будет искать послушных, покладистых и беспроблемных разработчиков, которые будут делать за него его работу вместо технически грамотных специалистов. Потому что с последними придется считаться, спорить, заниматься сложной менеджерской деятельностью, вместо это можно просто нанимать приятных людей которые будут все делать за тебя, оправдывая это аджайлом, командностью, ответственностью и взаимозаменяемостью. Рыба всегда гниет с головы.