Вышел Kotlin 1.4

GC, GC - рознь. Если бы одного его наличия было бы достаточно, то в Java не разрабатывали столько разных сборщиков (вон, G1GC сколько лет делали сначала инженеры Sun, а потом и Oracle. А сейчас - сколько лет делают Shenandoah?), а проекты на Go не переписывали бы на Rust (например, часть бэкенда у Discord) как раз из-за не оптимальной реализации GC именно в Go

а проекты на Go не переписывали бы на Rust (например, часть бэкенда у Discord) как раз из-за не оптимальной реализации GC именно в Go

Да, просто Go не для монструозных поделий. Там stop the world GC и это известно давно. К тому же, уверен, в Discord думают, что GC – это значит с выделением и освобождением памяти работать вообще не надо. Хотя это не так.

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

Конечно же у макаки всё будет nullable, потому что без null неудобно. И всё будет точно так же падать. С другой стороны, что плохого в дополнительной проверке компилятором? Это примерно как с генериками. Можно и без них жить, кастовать всё через void где надо, фигле заморачиваться. Да и декларации типов не очень нужны, просто передавай всегда правильные данные Не будь макакой!

Самый приятный синтаксис у Си++.

А зачем для этого котлин? Статический анализ это все и так покажет. А он обязателен для проекта с 20+ разработчиков.

И какой статический анализатор умеет нормально ловить абсолютно все возможные npe? Плюс ява как язык не слишком заточена под safe-операции с nullable. Есть optional, но синтаксис у него мягко говоря тяжёлый, как и все что связано с лямбдами в яве. Плюс если каждое nullable-поле обернуть в optional - количество кода сильно вырастет, а читабельность упадёт до нуля.

И еще больное место - коллекции с nullable. Обычно это тупо запрещается на уровне code style, но иногда стреляет, особенно если коллекция из внешнего источника. И накикие jsr305 тебе эту коллекцию не подкрасят. А коллекция из Optional это писец

Так и в случае котлина полная нулсейфти не гарантируется. Прилетит тебе из явы коллекция с нуллами и привет нпе.

Прилетит тебе из явы коллекция с нуллами и привет нпе.

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

Считай что это просто синтетика, которая позволяет проверять null сильно короче чем даже checkNotNull, и которая с ними работает куда удобнее чем optional

Ещё большой плюс - ты поймаешь npe сразу в датаклассе, а не через n прыжков вверх вниз по стеку

Вышел Kotlin 1.4

Вот что вошло в Kotlin 1.4.0:

круто, что это всё туда вошло, но сначала нужно написать, что это вообще такое...

Эталонное ненужно (Kontlin) от создателей (JetBrains) эталонного ненужно…

Пусть расцветают сто цветов, пусть соперничают сто языков. (с)

Ха... я-то вендокапца не ждал никогда. Ну, разве что в пионерском детстве, во времена OS/2. Опять же, будь я чуть постарше, я бы понял, что сдвинуть махину в виде MS + всё ПО под венду - нереально, даже если ты сделаешь самую лучшую ось (OS/2, QNX).

А вот вендроидокапут - он близок. Все знают, что это говно - даже сам Гугл. Более того - от того же Гугла маячила какая-то «замена Ведроиду», что уже намекает.

Прикол ещё и в том, что смарт - это убогий компромисс между удобным 24" моником и мобильной коробочкой, по которой можно звонить. А компромиссы долго не живут, их заменяют революционными прорывами.
Так что если кто-то всерьёз ставит на долгую карьеру мобилоразработчика под Ведроид - я б на вашем месте серьёзно подумал.

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

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

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

Symfony в PHP

Туда уже завезли магию с автоконфигами, которые нормально работают только в аквариумных услоаиях?

мозговая инфекция

Не инфекция а нервное расстройство - нульпойнтерофобия.

А для тех, кто придумал checked exceptions, в аду стоит отдельный котел.

И чем же checked exceptions так плохи?

И получаем over9000 языков, которые применяются полутара человеками (кроме авторов), но хайпятся и увеличивают разряженность сообщества в нормальных языках. Хорошая идея. По моему linux дистрибутивы пошли по этой дроге и мы получили множество сборок Ubuntu/Arch/Debian с нескучными обоями

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

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

Значит тебе нужные проверки на null и unit тесты ? :) Ок, пишешь на все возможные кейсы проверки на null if (x == null) затем выполняешь покрытие этой локики юнит тестами, т.е. в каждую логическую ветвь нужно зайти и протестировать работу. За прорытием следит Sonar и CI проверяющий coverage. Гарантирую что 80% времени ты будешь писать только тесты.

NPE появляются постоянно, и если ты не видишь NPE то значит у тебя нет доуступа к лоагам с продакшена. Я работал в продуктовой фирме, где всем на почту сваливались ошибки на backend, и там была куча NPE несмотря на жесткие требования по покрытию. Так же я работал в бодишопе и у нас небыло NPE по причине что логов мы не видели, java машина от NPE не упадет, просто кто-то из пользователей получит ошибку 500 о которой мы не узнаем, если эти ошибки не станут значимыми для заказчика.

Kotlin позволяет указывать информацию о nullability в типе, плюс может делать необходимые выводы типа, это уменьшает количество NPE при совместной разработке. Контракты прописаны в коде и за их соблюдением следит компилятор. Это тоже самое что стираемые дженерики в Java, ведь никто не знает что за объекты находятся в коллекции, у нас есть только контракт в коде соблюдение которого гарантируют компилятор, его можно обмануть, засунуть в коллекцию что угодно, но в 99% так не делают и у нас нет массовых ClassCastException. Тоже самое с NPE и null-safety в Kotlin.

Хорошо что мы не слушаем мнения таких как ты

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

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

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

Вышел Kotlin 1.4
Вот что вошло в Kotlin 1.4.0:

Что такое Kotlin?

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

По этой, собственно, причине любят в основном андроидщики

А вот вендроидокапут - он близок

И что же его заменит интересно?

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

И приложения писать отдельно под каждую мобильную платформу, потому что нет кроссплатформенного ничего - это днище.

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

Хорошо что мы не слушаем мнения таких как ты

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

При чем здесь бинарные сборки? Как будто Котлин решает эту проблему. В остальном согласен.

Даёшь javascript как основной язык мобильной разработки или вообще разработать свой NodePhone.

Как это не оброс, если пивотал уже даже документацию пишут для котлина наравне с джавой?

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

Что такое Kotlin?

Что такое Android то хоть знаешь?

По моему linux дистрибутивы пошли по этой дроге и мы получили множество сборок Ubuntu/Arch/Debian с нескучными обоями

Это хорошо или плохо? Надо оставить одну федору с гномом?

одобряю) и гуй на HTML, точечно допилив, где тормозит

И чем же checked exceptions так плохи?

В интернете обсасывалось много раз. Они просто не нужны. Их нет ни в scala, ни в kotlin, ни даже в C#. Они не дают абсолютно никаких плюсов, только одни неудобства. Они очень сильно раздувают код, препятствуют использованию лямбд и method reference. Хотя тут наверное виноваты не столько checked exceptions, сколько конченая реализация лямбд. В облаках в приложении с коротким жизненным циклом все catch выглядят примерно так:

} catch (Exception e) {
    throw new RuntimeException(e);
}

ещё один. я не спрашивал что такое Kotlin, там даже вопросительного знака нет

Даёшь javascript как основной язык мобильной разработки

Вы тут все в танке? Уже сейчас мейнстрим это реакт натив и флуттер с дартом (это такой нескучный жабаскрипт). Котлин уже просрал полимеры.

Это хорошо или плохо? Надо оставить одну федору с гномом?

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

И так со всеми категориями ПО. Для того, чтобы linux наконец стал полноценной пользовательской системой не надо 100500 аналогов Х, нужен 2-3 качественных и проработанных решения.

С разморозкой, уже как бы давно

А что вам не хватает в актуальной версии Java? ЕМНИП сейчас в Kotlin нет ничего, чего бы не умела Java, в неё (могу ошибаться) даже сахара много завезли

Так, аноны, вы совсем тут распоясались. Я учу котлин, значит язык стоящий.

Владимир

ЕМНИП сейчас в Kotlin нет ничего, чего бы не умела Java, в неё (могу ошибаться) даже сахара много завезли

Код на 40% короче.

Владимир

Шо, даже checked эксепшены убрали?

сложно. разъясни)

Люто плюсую. Не расстраивайся анон, мы тут имеем дело с «вот и выросшим поколением». Которым нужна большая зелёная надпись «у вас в программе кажется нет null pointer dereference» или «borrow checker’у похоже всё понравилось».

Да при чём тут это. Корячиться и пялиться в комп за какие-то копейки никто не станет. От того и все дела. Раньше, может ты не в курсе, но книгопечатание тоже было пристижным и высокооплачиваемым. Но теперь это просто обычная работа. Точно так же и программирование – обычная работа. И поколения тут не при чём. За нехилый прас тебе любая макака каждый свой проект наизусть выучит и перепишет на три других языка. Вот только за хилый прайс никто не будет изучать всё это дерьмо.

Современный рынок услуг программиста – «мне нужно мой говнокод, который делала натуральная макака ещё дешевле тебя сделать рабочим быстро и дёшево». Вот и всё. И катят тут не тольо null pointer deference, а вообще все возможные проверки, линты и так далее. Иначе проект (или «проект») не существовал бы в принципе. Отмени первое, отпадёт и второе.

прочитай исходный пост громко вслух с правильным английским произношением слов

=)). йасно. главное не попутать RP vs GA.))

Как это не оброс, если пивотал уже даже документацию пишут для котлина наравне с джавой?

Вот когда Spring перепишут на Kotlin, вот тогда это и будет «оброс».

Использование break и continue внутри циклов when

ZX Spectrum?

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

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

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

так что не жизнеспособна такая схемка в перспективе.

в итоге вася заплатит 3-7 раз разным макакам, а мог бы сразу заплатить 3х денег не-макаке и забыть про этот код на следующие 10 лет

В этой схеме вася имеет наполеоновские планы. Ни гроша за душой¹. И тратит он деньги инвесторов, которые вообще не рубят в теме, но рубят в презентациях и прочем. И когда он подходит к ним с нехилым прайсом, то они его бреют – т.к. не вкладывают в васянские технологии. Но когда он подходит с небольшим прайсом, то менее продвинутые инвесторы ведутся и вкладывают.

После запускается круговорот: инвестор - вася-наполеон - макака - покажи что сделал, можно ли на эту показуху привлечь ещё бабла - круг.

При этом сам васёк теряет только свою репутацию и то, смотря как посмотреть. Т.к. менее продвинутые инвесторы – это тоже макаки, только от инвестиций².

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

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

Сноски:

• ¹ – в реальности он тратит своё бабло, чтобы показать надёжность инвестиций. Но это я так, для трагизма.
• ² – вплоть до вася-инвестиционной пирамиды, когда вася обещает сделать ещё кое-что и ещё кое-что дополнительно, и берёт бабло, чтобы доделать текущую поделку.

нууу, в этом тоже есть смысл. ты же знаешь, что поисковик гугла изначально был написан на джаве, но потом его переписали на с++? в прототипах тоже есть смысл, но для прототипа язычок должен предлагать скорость разработки, а не мнимую «безопасность», которая не безопасность, а обычное фуфло. большая скорость разработки подразумевает возможность допустить, обнаружить и быстро исправить ошибку, а не возможность поеб*ться с компилятором. так что тут котлин тоже мимо кассы, увы.

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