Какие есть реальные преимущества написания Rest API на Java?

Go

Убогий многословный язык без исключений. На Java писать код раза в 3 быстрей.

NodeJS/Python/Php

Если речь о JS, нетипизированная параша, на Java писать код раз в 5 быстрей и в 10 раз меньше багов.

На Java писать код раза в 3 быстрей

Чушь несусветная, эта многословная дрянь и «быстрее» в одном предложении могут быть только в анекдоте.

Многословность не мешает писать код быстрей. Скорей наоборот, помогает. Ты же не машинистка, которая ограничена скоростью клавиатуры.

Говённый язык и бойлерплейтинг отвлекают от дела.

Поэтому я и говорю, что на Java писать куда быстрей, чем на Go.

В Go как раз всё лаконично и есть нормальные батарейки в отличие от.

само набирание текста во времени разработки составляет наверное тысячную процента и на стоимость разработки не влияет. синтаксис, вербозность - это никак вообще не влияет.

и есть нормальные батарейки

Например?

Да хотя бы простейшая фича — вычитать файл целиком, она есть в стандартной библиотеке, и это дофига приятно.

Представь стандартную библиотку питона, только без мусора, лучше вдвое и с байтами. Это Go.

Ещё как влияет. На этом просто не хочется писать. Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.

String FileUtils.readFileToString(file)
byte[] FileUtils.toByteArray(file)

А чем они хуже?

Но я посмотрел, действительно неплохо. Правда Java сильна сторонними библиотеками как мне видится.

Ещё как влияет.

Очевидно, на джаве ты не писал никогда. Если бы писал хоть немного, то так бы не говорил.

Тем более, понятно, что ты не писал проектов больше хелловорлда, которые реально работают и поддерживаются.

Ты кукаретик-пустослов, мнение которого ничего не значит.

язык без исключений не может быть лаконичным.

тем более го вообще уродец без дженериков и нормальной поддержки многопоточности (в чем Java лидер).

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

И вот так на каждый чих что-то извне тащить, класс, да?

Очевидно только, что ты трепло и петушара.

Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной рабами лишь бы не работать

fixed

а ты, со своим «опытом» на жабе, лучше бы молчал

Насчёт говноязыка согласен, не надо его использовать. Но Go ещё хуже.

Э-э-э… мсье сторонник плоских неймспейсов?

Сторонник удобства и поддерживаемости. Когда у тебя в проекте десятки зависимостей, а у каждой зависимости ещё чёрт знает сколько, ты уже не то, что не можешь гарантировать, что проект у тебя через год-два соберётся, ты уже сейчас не контролируешь то, что у тебя в прод попадает. Удачи со 100% покрытием при таком подходе.

Maven, ant? Не, не слышал.

А, так ты жертва 100% покрытия и прочего Clean Code… ок

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

Типичный Goшник detected.

В нормальных проектах не делают импорт по гитхаб-урлу. Там в проект добавляют конкретные версии. Которые через год-два не поменяются.

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

Что мешает зафиксировать версию в go.mod?

это такой символ веры из мира динамически и слабо типизированных языков

Ну как бы те же проекты на Java активно покрывают тестами. В ней слабая типизация?

Ты, кажется, не понимаешь что такое «сторонние библиотеки» в java мире. Это очень хорошо оттестенный код. Сделан он для того, чтобы не строили велосипедов. Через maven я обновляю версии примерно раз в 2 года, ито хз зачем. Просто чтобы up to date было. Итак все работает.

Например: покрывать тестами какой-нибудь apache poi нет надобности. У него огромное комьюнити и багов там почти нет.

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

Зачем сторонние либы покрывать тестами? Это лежит на плечах разработчиков этих либ. Покрывать тестами надо свой проект.

Рано или поздно оно сломается, и без тестов ты об этом узнаешь

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

Покрывать тестами надо свой проект

Его и надо покрывать. Только бычно, если твой проект сам не библиотека, 100% покрытие бесполезно. Но когда у тебя сторонее чёрт знает что используется во всём коде проекта, то тут-то от полного покрытия уже не уйти.

А старая ж не меняется - чего сломаться может вдруг?

Пинишь вплоть до версии патча? Это суперплохая практика. Если нет, то твой аргумнет не работает. По-хорошему пинить вообще нужно только мажор.

Пинишь вплоть до версии патча?

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

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

Я не говорю, что тесты вообще не нужны. Я говорю про этот фетиш под названием «100% покрытие».

то тут-то от полного покрытия уже не уйти

И опять-таки даже так 100% покрытие бесполезно. Оно всегда бесполезно, потому что код с 100% покрытием ничуть не более надежен, чем код с 80% покрытием. И без разницы, юзаешь ты сторонние либы или нет, они вообще ж никакого влияния на это не оказывают.

Пинишь вплоть до версии патча? Это суперплохая практика.

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

Ладно до минора, я сам так в основном делаю, но патч-то пинить как-то совсем не хорошо.

Да, да, не оказывают. Сломали тебе библиотеку, ты обновился, тесты упали.

То есть если мажор запинен, то ничего ломаться не должно

Какая-то феерическая наивность.

Представим, что эта библиотека - некий клиент для какого-то сервиса, делающий http-запросы (обертка над неким API). Чтобы протестить свой, код, использующий эту либу, в любом случае будешь писать mock-обертку, чтобы при выполнении тестов реальные http-запросы никуда не делались. А если так, то твой тест не гарантирует тебе ничего при поломке обратной совместимости в этой библиотеке.

Это классика, так и свой код нормально протестить не можешь. Посмотри в начало треда, речь ведь не об этом, там мне предложили аж для чтения файлов сторонние библиотеки использовать.

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

Убеждай себя дальше. Ездить на мерседесе глупо, он слишком отвлекает от вождения совими плюшками. Жить в частном доме накладно, снег же убирать надо. А вот жрать говно вот это по-нашему оууйее. Что? Попробовать пожить в доме и погонять на мерсе? Нее, говно оно уже мое, а то оно что-то нинашенское, угу, тысяча причин.

Жить в частном доме накладно, снег же убирать надо

Именно так. Купи себе дом сначала, потом пообслуживай, потаскайся в центр с окраины, тогда уже мне и расскажешь. А я пасс, мне хватило.

Мерса у меня, правда, никогда не было. Но и зачем он мне, я дурак что ли, чтобы сам водить. Это работа таксиста.

лишь показывают твою некомпетентность.

Мою-то? Ну ты и клоун.

именно многопоточность из коробки и есть основная киллер-фича Го

Ты не забыл дурачок что мы в контексте джавы говорим? Ты или о джаве ничего не знаешь или о многопоточности, раз у тебя «именно многопоточность из коробки и есть основная киллер-фича Го».

Пинишь вплоть до версии патча?

Внезапно, имеющая место быть практика даже на Node.

Считаешь её нормальной?

Жить в частном доме накладно, снег же убирать надо.

Частный дом – это шиздец. Считай вторая работа.

Хз, я просто локфайлы коммичу, а не фиксирую версию, убирая ^ в package.json

А, нода, ну тогда это отчасти оправдано. У меня какая-то библиотека до минорной версии обновилась (не помню почему, но откатить не вышло), после чего проект вообще не собрался, т.к. стейбл ноды отсох, его поддержку тут же в библиотеке дропнули, пришлось всё обновлять и код под новые версии фиксить. Причём я изначально лишь минорщину какую зафиксил, а вылилось это в итоге в работу на полдня.

А как вы обеспечиваете воспроизводимые сборки?

Воспроизводимость как таковая не особенно ценна, если есть хорошее покрытие.

А в случае когда это действительно принципиально, нужно где-то у себя кеш держать. Иначе хрень это, сторонние репозитории ты всё равно не контролируешь.

Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.

Глупость несусветная. Скала например вообще совершенной другой, самостоятельный язык со своей парадигмой, но с интеропом с Java. С таким же успехом можно вообще любой язык привести в качестве доказательства ущербности Java. Типа «Nim был запилен лишь бы не писать на джаве», смысла в твоем высказывании примерно столько же.

Что касается JVM, ну так есть еще perl на JVM. Язык Perl ведь не был «запилен лишь бы не писать на Java». Есть scheme на JVM (забыл как называется). Это лишь доказательства успешности самой идеи JVM и ее качества.

Если бы у тебя была хоть капелька мозгов (ну и представлений о вопросе по которому высказываешься), ты бы в доказательство своего (слабо сформулированного) наезда на Java привел бы C#.

Что касается котлина. Факт его существования твой наезд никак не доказывает. Котлин это бесполезный язык. Он добавляет необходимость разобраться с его синтаксисом (это не сложно, но зачем профессионалу замусоривать мозг и тратить на это силы?). Он добавляет новый синтакс который понимают не все редакторы/IDE, не все инструменты документации, не все статические анализаторы и т.д. и т.п. Он добавляет новый компилятор в проект, в систему сборки. При этом он не решает вообще никакой проблемы Java и ничего не добавляет. Вообще не понимаю, как люди купились на этот котлин.

Данный инструмент входит (тык) в NIO.2, начиная с релиза Java SE 7.

Ради решения этого и сделали поломку с JPMS в Java 9. Впрочем, эти проекты по кодовой базе настолько огромны, что уже действительно необходимо держать группу поддержки только на разрешение зависимостей. В остальном - ничем не хуже Go.

Мозгов у как раз и нет, если ты не понимаешь, что шарп запилен по сугубо стратегическим корпоративным соображениям, а не из-за качеств языка.

Твоё непонимание ситуации с котлином контр-аргуметом не является. Джавята от него в восторге, иначе так резко бы не перепрыгнули.

Пинишь вплоть до версии патча? Это суперплохая практика. Если нет, то твой аргумнет не работает. По-хорошему пинить вообще нужно только мажор.

Глупенький, в программировании во многих нормальных проектах обновление библиотеки не делается спонтанно и без всякой надобности. Это делают когда появляется такая необходимость. Когда надо - меняют номер и смотрят, что будет. Это отдельная задача при нормальной организации работы.

Подключенные к интернету проекты с плавающими номерами библиотек - это вообще не нормально, а то что это сегодня чуть ли не стандартная практика в индустрии - так индустрия на 90% состоит из полудурков типа тебя.

Некоторые и сегодня в Java проектах просто jar кладут в lib и получают стабильный самодостаточный проект.

Дурачок здесь ты, если не понимаешь почему нельзя пинить патчи.

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

Мозгов у как раз и нет, если ты не понимаешь, что шарп запилен по сугубо стратегическим корпоративным соображениям, а не из-за качеств языка.

Глупенький, ты сел вот в лужу, про стратегию запел. Это к делу не относится.

Вот это твое высказывание: «Не зря есть Scala, Groovy, Kotlin и ещё хренова туча херни запиленной лишь бы не писать на джаве.» - оно как было глупостью, так и осталось.

Твоё непонимание ситуации с котлином контр-аргуметом не является. Джавята от него в восторге, иначе так резко бы не перепрыгнули.

Во-первых, является.

Джавята от него в восторге

Какие? Кто? Полудурки типа тебя? Сколько их? Вайти-вайтишники на андройде вообще слабо соображают, что делают.

Короче, ты джаву видел только по телевизору. Представление о вопросе имеешь только приблизительное. Но «мнение имеешь».

Эта многословность сильно автоматизирована. Тем не менее, читать Java проекты начинающим куда проще, чем тот же Kotlin. Особенно, когда в последнем появляются Extensions. Вот от чего у меня люто горит, так это от способности разработчиков Kotlin’а впихнуть что-то, с чем гадать потом будешь: только что ведь была эта функция в классе, куда она делась?

Это к делу не относится

Напрямую относится, показывает нерелевантность твоего лепета про шарп.

Котлин вообще мерзость на мой вкус, если что. Но мощный отток на него — факт.

Воспроизводимость как таковая не особенно ценна, если есть хорошее покрытие.

Весьма ценна, если речь идет о продукте, который нельзя выкатывать каждый день, да даже каждый месяц. Выкатил заказчику версию, а через 6 месяцев получил фидбек с каким-нибудь трудновоспроизводимым багом. Необходимо откатиться, воспроизвести ошибку, пересобрать с добавленным журналированием, если не хватает, повторить её снова. Найти багу. Починить её «на месте», выкатить патч версию для старого релиза. Пропатчить все последующие версии. Обновить у заказчика старую версию (потому что новая ещё не готова к интеграции с данным заказчиком).

Дурачок здесь ты, если не понимаешь почему нельзя пинить патчи.

Дурачок, какие патчи? Патчи накладывают (либо приклеивают). У библиотек есть версии. Ну и почему же «нельзя пинить патчи»?

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

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

Ну, современный write-only потомок Java. Что-то между Java и Perl с человеческой маской.

Не удивлюсь, если Java впитает в себя какие-то удобные фичи из Kotlin (т.е. Records выйдут из preview, project amber завершится), после чего Kotlin начнёт долго и мучительно умирать. Я не вижу причины, почему язык-паразит, висящий сразу на нескольких «мамках» (JS, Native, JVM), может надолго захватить крупную часть рынка.

Спорным решением при этом будет не выкатить зподним и пропатченые библиотеки.

Тупица, в семантическом версионировании есть мажорная версия, минорная и версия патча. Дуй в школу.

У нас цикл обновления занимает несколько месяцев (как минимум три, у самого активного заказчика). Правятся конкретные ошибки, поскольку система работает почти без поддержки. Если в пропатченной библиотеке будут новые, неожиданные ошибки, обновиться получиться не раньше, чем ещё через несколько месяцев. Потому то, что не горит, предпочитаем не обновлять. Хотя есть свои минусы в этом, конечно.

Но ведь уже захватил и андроид теперь не отдаст.

А причина тому — разработчик. Кто пилит инструменты (InteliJ), тот и заказывает музыку, как оказалось.

Android - это проблемы политического толка (Oracle), а не проблемы платформы Java.

Тупица тут только ты. Я-то в отличии о тебя десятки проектов выкатил и поддерживал.

Это так называемый «патч» - части версии. Это новая отдельная опубликованная версия.

Если проект зависит от 1.2.3 - значит с ним и работают. Обновление, как я тебе дауненку объяснил уже, делается в рамках отдельной задачи. Но это делается по определенным причинам, в определенное время, и во вне определенных периодов.

Библиотека с таким обновлением вполне может привести к тому, что проект собирается, обозримо работает как было, но на самом деле работает немного по-другому. В реальном программировании есть потребность отличать эффекты от своих изменений от всех остальных эффектов. Иначе это путаница, трата времени и денег. Если поведение трудновоспроизводимо - это всё особенно неприятно.

Ты похоже в реальном программировании вообще никогда не работал. Дурачок, люди библиотеки даже завендориваю бывает. Причем бывает что с ревизии не имеющей версии.

Риальный клоун погромист не в состоянии отревьюить изменение приведшее к бампу патч-версии? Хаха. А ещё, небольшой секрет, даже изменения минора по-феншую не должно ломать API.

Воспроизводимость как таковая не особенно ценна, если есть хорошее покрытие

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

А в случае когда это действительно принципиально, нужно где-то у себя кеш держать. Иначе хрень это, сторонние репозитории ты всё равно не контролируешь.

Уже давно есть artifactory и nexus, которые умеют работать в режиме кэширующего прокси, в итоге артефакт скачивания с maven central repo ровно один раз, потом уже все тянут из репозитория.

Когда у тебя в проекте десятки зависимостей, а у каждой зависимости ещё чёрт знает сколько, ты уже не то, что не можешь гарантировать, что проект у тебя через год-два соберётся, ты уже сейчас не контролируешь то, что у тебя в прод попадает.

А ты контролируй. Не тяни в проект что попало.

Ну и да, в maven central лежит всё. https://repo1.maven.org/maven2/org/apache/maven/maven/2.0/ артефакты 2006 года, например. Поэтому всё прекрасно соберётся и спустя 15 лет. Другой вопрос, что, конечно, до такого лучше не доводить.

Риальный клоун погромист не в состоянии отревьюить изменение приведшее к бампу патч-версии? Хаха. А ещё, небольшой секрет, даже изменения минора по-феншую не должно ломать API.

Это ты уже от безысходности чушь несешь про «отревьюить изменение»?

Короче говоря, ты о программировании ничего не знаешь вообще. От слова совсем.

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

не можешь гарантировать, что проект у тебя через год-два соберётся

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

Проект гарантированно соберется и через 300 лет, если у тебя все версии библиотек те же, дурак.

В этом случае он перестанет собираться только если у тебя компилятор или система сборки поменялись.

не можешь гарантировать, что проект у тебя через год-два соберётся

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

Проект гарантированно соберется и через 300 лет, если у тебя все версии библиотек те же, дурак.

В этом случае он перестанет собираться только если у тебя компилятор или система сборки поменялись.

То есть, парировать ты не в состоянии, и можешь только съехать? Ладно. Слив засчитан.

висящий сразу на нескольких «мамках» (JS, Native, JVM) На чем висит язык у которого своей стандартной библиотеки нет, и он зависит от джавовской? И у которого нет собственного обеспечения кросс-платформенности по процессорам и ОС, а есть только джавовская JVM и джавовская опять же стандартная библиотека?

У джавы можно найти ряд недостатков серьезных, но котлин не решает ни один из них - вот в чем проблема. Джаве помогли бы структуры примитивных типов с возможностью размещения их в массивах (над этим работают в оракле), но котлин к этому никакого отношения не имеет. Джаве бы хорошие дженерики, но этой информации нет и 100% интероп котлин<->жава не получился бы.

что есть у котлина? лвти? так это вредная возможность. у меня 6 месяцев опыта программирования на джаве 8, параллельно использовал новую джаву с lvti - так это антифича, это понятно когда попробуешь. сначала кажется, что вот прогресс. но код с явными типами гораздо понятней и быстрее читается через месяц. а экономии никакой. что экономит этот вар? набор он тоже не экономит, потому как в идее фактически этот лвти встроен, про правой части которую ты набрал левую часть идея сама тебе напишет, те же три кнопки.

мультилайн строки разве что действительно решили в котлине, но они и в новой джаве будут.

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

Так генерики такие для обратной совместимости.

Система сборки поменяется в любом случае, не будешь же ты снапшотить окружение перед каждым билдом и хранить это вечно?

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

Когда ты начинаешь дебажить старую версию, это значит ты (ну, не только ты, ещё эксплуатация) уже в какой-то момент обосрался. Во-первых, какого хрена оно там старое? Во-вторых, какого хрена ты не отловил это раньше? В-третьих, если ты в принципе дебажишь, значит нить потеряна, ты не понимаешь что происходит и как это возможно.

Джаве помогли бы структуры примитивных типов с возможностью размещения их в массивах (над этим работают в оракле), но котлин к этому никакого отношения не имеет.

Inline classes немного помогает.

Джаве бы хорошие дженерики, но этой информации нет и 100% интероп котлин<->жава не получился бы.

Достаточно в объекте хранить Class для каждого generic типа, передавая его в конструкторе. Не сделали, но могли бы. Подозреваю, не сделали потому, что ценность этой фичи не так уж велика.

что есть у котлина

null-safe система типов это самое важное. Также из важного - улучшенная система коллекций, при этом совместимая с Java. На мой взгляд стримы гораздо хуже.

Ну и уйма «сахара». Про каждый можно сказать, что не так уж он и важен, но всё вместе делает программирование ощутимо приятней.

Не убедительно указал, маня, учись усердней.

Inline classes

Кажется, это что-то немного другое. Я говорю о «классе» из n примитивных членов, массив «экземпляров» которого будет включать непосредственно сами экземпляры с их членами (и занимать памяти размер_экземпляра x кол-во_эл-тов).

null-safe Проблема NPE преувеличена, на мой взгляд.

Если ты говоришь, что некоторую ценность он всё же несет, то значит так и есть. Но для меня (как для многих других, я уверен) польза от его внедрения не перевесит минусы и затраты, а «действительно важные» недостатки не исправит. Кроме того, двигает его только и исключительно гугл и только по политическим причинам. Почти уверен, что технические достоинства котлина гугл считает ничтожными и не перевешивающими затраты от его внедрения (есть доводы в пользу этого), а джавовское лобби там гораздо сильнее.

Кажется, это что-то немного другое. Я говорю о «классе» из n примитивных членов, массив «экземпляров» которого будет включать непосредственно сами экземпляры с их членами (и занимать памяти размер_экземпляра x кол-во_эл-тов).

Я понимаю, inline classes решают эту проблему для случаев, когда n = 1. В общем случае, конечно, требуется доработка JVM.

Проблема NPE преувеличена, на мой взгляд.

Дело не в проблеме NPE, а в более строгой системе типов. Любой ссылочный тип в программе может либо принимать null, либо не принимать. В Java это не выражается кроме как уверениями программиста и runtime проверками, в Kotlin выражается.

Собственно тот факт, что в Java всё больше библиотек обзаводятся аннотациями Nullable это такая неявная реклама Kotlin, где это всё работает нормально, а не прикручено сверху.

Тот, кто говорит, что на Java код пишется быстрей - никогда не писал на python. С Go не сравниваю - не знаю этой гуглоподелки и учить не собираюсь.

Ну это вы просто не умеете Java готовить - например, такая штука есть - https://maven.apache.org/enforcer/enforcer-rules/dependencyConvergence.html

У меня реальные проблемы со сборкой возникли только при переезде с Java 8 на 11. Но там охренеть сколько всего поменялось, самая засада - что jaxb выпилили из jdk.

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

Писать-то быстрее, а вот поддерживать и рефакторить — my ass!

У Go проблема с фреймворками, он годится только под микросервисы и конкретные небольшие задачи. А в целом, код пишется быстро и крайне приятно.

Ну вы же понимаете, что это вечный компромисс - скорость разработки против стабильности. На python у меня есть только опыт по допиливанию trac. Так что можно не только скрипты писать.

Так вот, немногословность обладает преимуществом не только в написании, но и в чтении кода. А читать код приходится гораздо чаще, чем писать. И вообще, хорошая большая программа - связка огромного количества маленьких. Можно даже на Javascript писать. :)

У Go проблема с фреймворками, он годится только под микросервисы и конкретные небольшие задачи.

Аналогичная беда у Javascript (npm + node.js) - такого лютого ужаса в библиотеках я нигде больше не встречал.

Писать-то быстрее, а вот поддерживать и рефакторить — my ass!

Рефакторить код на динамическом языке программирования? Сэр, я же не идиот и не самоубийца :))) Хуже этого только рефакторить perl-овый скрипт.

Тот, кто говорит, что на Java код пишется быстрей - никогда не писал на python.

Кто говорит, что на python код пишется быстрее чем на Java не замечает, что питоновскую программу надо запускать после каждой измененной строчки, хотя бы для того, чтобы убедиться, что нет обращений к несуществующим переменным, полям, что вызовы корректны хотя бы по числу аргументов и типам. Кроме того, в Java далее (когда программист переключится на работу с другим участком) эти проверки по прежнему будут происходить автоматически и бесплатно. В питоне же они будут якобы происходить только если написать юнит-тесты, что само по себе глупость, профанация и мошенничество.

Какой-либо рефакторинг (даже не меняющий логики) в питонах возможен только для микропрограмм на 500 строчек. Потенциал для инструментов статического анализа в python нулевой, потому даже питонский компилятор, если бы таковой существовал, не знает о программе ничего вообще.

Слишком много ситуаций, при которых python-IDE почти ничего не может подсказать. У Java всегда полное понимания кода IDE (кроме участков с рефлекшеном). Из-за этого само написание программы в С#/Java многократно быстрее чем на питоне.

Что касается вербозности, то преимущественно эти страшилки не имеют отношения к действительности, так всё это пишет IDE.

По документации Java и python - две противоположности. У Java лучшая в индустрии (после продуктов MS может быть), у python - самая плохая, уступает даже php. Скажите еще что документация не влияет на скорость разработки.

То есть так говорят только люди, которые в редакторе vim посчитали буквы, которые нужно печатать на python и на Java и сделали из этого вывод о скорости разработки. Но если бы человек подумал хотя бы на одну минуту вперед то обнаружил бы, что ситуация уже обратная.

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

Кто-то тут никогда не видел питон. 90% из поможет избежать даже pylint прямо «из коробки», и это не 99% только из-за метапрограммирования. Ещё этак 5% покроет MyPy, если упороться и идеально расставить типы.

Бульк.

ЧичерХеральт

Если речь о JS, нетипизированная параша

Вы просто не умеете его готовить всю жизнь сидите в своём ООП и не способны мыслить как-то по-другому. Такие люди приходят в js и начинают ныть, что им нужен typescript. Языки с динамической типизацией отличаются тем, что не ограничивает программиста делать вещи как-то по-особенному. На js, например, всякие вещи с рефлексей и декларативщиной делаются легко и непринужденно. Парадигма языка не обязывает тебя наяривать в присадку на ооп. Динамика это вообще единственное место, где можно что-то делать отличное от default.

на Java писать код раз в 5 быстрей

На js пишется 1 строчка там, где на жабке унаследуют два класса, напишут 4 и сделают абстрактную фабрику контроллеров. Ну может в будущем это и окупается, не знаю.

в 10 раз меньше багов.

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

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

Самое забавное – это то, что я сталкивался с практически идентичной ситуацией.

При этом он не решает вообще никакой проблемы Java и ничего не добавляет.

Добавляет и решает. Как минимум решает частично проблему обкатки новых функций, многие функции из Котлина в том или ином виде добавляются в java, можно посмотреть доклад https://www.youtube.com/watch?v=te3OU9fxC8U, там про это рассказывают.

Вторая проблема, которую решает kotlin, и которую никак не могут решить в java - это NPE, в kotlin-е в принципе отсутствует эта ошибка, она может возникнуть только на границе interop-а с java. Да, в java можно обмазаться анализаторами и чекерами, но во-первых таких единицы, а во-вторых это не убережёт от того, что в глубине какой-либо библиотеки вылезет NPE.

Что за бред ты несешь? Какая обкатка? Oracle в состоянии сам обкатывать новые фичи. Котлин тут ни при чем.

Ты бы лучше посмотрел видео выступления Brian Goetz из Oracle, где он объясняет про статус preview новых элементов языка Java, дурачок. Там же объясняются почему долго не делали некоторые вещи.

функции из Котлина в том или ином виде добавляются в java

Какие функции конкретно? Я не хочу смотреть это говно по твоей ссылке.

«Из котлина в джаву» ничего не добавляют. О существовании котлина там конечно знают. Джаве 20 лет, там многое не добавляли не потому, что не знали, что так можно, и вот теперь увидели в котлине и скопировали. Это надо быть дебилом чтоб так думать.

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

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

Вторая проблема, которую решает kotlin, и которую никак не могут решить в java - это NPE

Рукалицо

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

Ограничение - это а про парадигму самой явы. А что касается типов, с key[value] можно сделать много чего и в яве тоже, но там всё это не так просто. Тем ни менее, когда начинаешь делать рефлексию на яве ошибки начинают вываливаться в тот же рантайм и начинается та же самая пляска с тестами и стат.типизация уже не играет какой-то особой роли. Тут еще мода на var с auto и из приемуществ остаётся только ограничение совсем уже тупо не отстрелить себе конечности + какая-то производительность, которая правда потом убьётся о пляски с рефлексией.

Ограничение - это про парадигму самой явы.

Не сказал бы, учитывая рефлексию и аннотации, с помощью них можно реализовать например свойста, расширения (c#), и реализовывают https://projectlombok.org/.

Тут еще мода на var с auto

java var && auto != javascript var

какая-то производительность, которая правда потом убьётся о пляски с рефлексией

Не так уж она сильно и убивается.

Не сказал бы, учитывая рефлексию и аннотации, с помощью них можно реализовать например свойста, расширения

Лобмок делает это через такие костыли, что лучше про них не знать.

java var && auto != javascript var

Это понятно, с типом видно, что за тип переменной. var и auto всё увозят под ковёр, весь код становится сплошным auto. ide скоро начнут весь проект вывозить в рантайм, частично запускать и так работать.

Лобмок делает это через такие костыли, что лучше про них не знать.

Ну так инструменты для расширяемости не предназначены для конкретных задач, вот и выходит не очень красиво. Но они есть.

Это понятно, с типом видно, что за тип переменной.

Тип остается виден для компилятора, инструментов итд. Для тебя он тоже должен быть виден если ты не пишешь код в ed.

Ну так инструменты для расширяемости не предназначены для конкретных задач, вот и выходит не очень красиво.

Дело в том, что на js то, что делает лобмок делается одним циклом вообще без плясок. Соответственно так же делается что угодно, что в лобмок никогда не засунут.

Тип остается виден для компилятора, инструментов итд

Ну так дойдёт то того, что инструменты начнут жрать ресурсов больше, чем работающий проект. И от этого всё равно не будет никакого выхлопа.

Дело в том, что на js то, что делает лобмок делается одним циклом вообще без плясок.

Как там будет реализован @NotNull? Не видел. Ну и тут главное не забывать что lombok IDE способна понять.

Ну так дойдёт то того, что инструменты начнут жрать ресурсов больше, чем работающий проект.

Не дойдет, var вообще никак этому не способствует.

Как там будет реализован @NotNull?

Стат.фичи на динамике никак не реализуются, да и настолько ли они нужны?

Ну и тут главное не забывать что lombok IDE способна понять.

Способна. С loombok - костылём. Какой-нибудь класс в js можно также взять и исполнить, а потом подставлять что получилось хоть до посинения.

Не дойдет

Так уже дошло.

Стат.фичи на динамике никак не реализуются

@NotNull реализован в lombok, а не «в языке благодаря статике».

да и настолько ли они нужны?

Ну тут дело не в самом @NotNull...

Способна. С lombok - костылём. Какой-нибудь класс в js можно также взять и исполнить, а потом подставлять что получилось хоть до посинения.

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

Так уже дошло.

Ну var нивчем не виноват, IDE и так типы выводит, а var или int какая разница?

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

Дело в том, что люди пишут на яве, программируя на чём угодно. Понятно, что с динамикой так не прокатит на 100%, потому что её надо исполнять и проще пилить под repl, получая всякие автодополнения с наборами методов прямо из вм.

Ну var нивчем не виноват

Его надо вычислять, а там внутри будет var через var и 50 вызовов. Просто проблема пока не стоит настолько остро.

Его надо вычислять

IDE и так тип вычисляет.

Ну тут дело не в самом @NotNull...

А @NotNull тут дело не ограничивается. Это так - макушка. Любой нормальный код состоит из проверок чуть ли не полностью и стат. типизация тут никак не помогает. Максимум что можно, наделать обёрток, но, на той же жабке, это будет работать как говно. Есть, например double, который выражает площадь, но никому особо не холодно и не жарко от того, что программа проходит стат.анализ и собирается, когда в этот double кто-то засовывает телефон.
Или, нужно сложить два положительных int'а в яве.
Нужно во-первых, проверить на >=0, во-вторых, проверить, чтобы в сумме они не давали больше MAX_INT, выкинуть ошибку в случае чего, а потом только считать. В итоге получаем то, что основные ошибки - это рантайм, весь день кодим проверки вместо того, чтобы работать, а в итоге получается, что проверки сделали не все.

IDE и так тип вычисляет.

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

А @NotNull тут дело не ограничивается.

Я про то что @NotNull не было в языке как ограничителя, а lombok как библиотека его добавил, но возможно ли такое в js?...

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

Сложнее определять тип для IDE не станет.

Я про то что @NotNull не было в языке как ограничителя, а lombok как библиотека его добавил, но возможно ли такое в js?...

Ну, там есть typescript. По сути это тоже самое, что lombook, только более масштабно.

Typescript не библиотека, я короч к тому что Java расширяемый язычек, с возможностями.

Typescript не библиотека, я короч к тому что Java расширяемый язычек, с возможностями.

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

Есть, например double, который выражает площадь

Что за дичь я услышал?

программа проходит стат.анализ и собирается, когда в этот double кто-то засовывает телефон.

Кто засовывает? Куда? В REST запрос? И никуда поезд не сдвинется потому что вагон и маленькая тележка фреймворков валидации. И будет стоять над телефоном @PhoneNumber или вроде того.

Нужно во-первых, проверить на >=0, во-вторых, проверить, чтобы в сумме они не давали больше MAX_INT,

Прямо-таки каждодневный пример. Ни разу не высосаный из пальца. Ведь давно всем известно что есть хоть мельчайшая вероятность больших чисел то все используют long.

Что за дичь я услышал?

Что за дичь ты написал?

Кто засовывает? Куда? В REST запрос?

Юзер в поле ввода. Как всё это долетает - дело десятое.

И никуда поезд не сдвинется потому что вагон и маленькая тележка фреймворков валидации.

Так о том и речь, что от основных типов данных пользны не очень и много, и приходится делать костыли с аннотациями.

И будет стоять над телефоном @PhoneNumber или вроде того.

Мы говорим про площадь в которой номер телефона, а не про валидацию номера. Или ты предлагаешь проверять любые данные на всё, что только можно?

Прямо-таки каждодневный пример. Ни разу не высосаный из пальца. Ведь давно всем известно что есть хоть мельчайшая вероятность больших чисел то все используют long.

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

с типом видно, что за тип переменной. var и auto всё увозят под ковёр, весь код становится сплошным auto.

А зачем постоянно вычитывать типы? Они либо из контекста сразу ясны, либо среда разработки подскажет. Это же прекрасно, что современные статические ЯП все больше походят на динамические (т.е. человечные). Сложность вытесняется в компилятор, где ей и положена быть. Если кому-то страшно становится от неаннотированного кода, это к доктору.

Мы говорим про площадь в которой номер телефона, а не про валидацию номера. Или ты предлагаешь проверять любые данные на всё, что только можно?

Да предлагаю. Если пользователь настолько одарен что путает поля, то никакой язык ни с какой типизацией не поможет тебе выполнить тот запрос который он хочет. Только в моем случае он получит ошибку еще на этапе валидации, а другом уже внутри бизнес логики. И не факт что сразу. И первое дебажится в разы лучше.

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

Типа если в JS плюсовать Number аж после MAX_SAFE_INTEGER будет прям сильно по-другому. Ну хотя бы не в минусах, да.