Как стать автором
Обновить

Комментарии 41

Какой-то странный ммм… перевод.
> не нужна никакая: в любом релизе можно нарушать (как в Scala например)

В Scala не так.
нагуглил это

Things have improved since. Scala now uses an EPIC.MAJOR.MINOR numbering scheme, and promises that you can freely swap out minor releases. Typesafe also promises source-level compatibility between major releases, so something that works in 2.11.x will be — at worst — deprecated in 2.12.x and not removed until 2.13.x

т.е. только мажорные релизы только могут ломать? хотя про Typesafe не понял — в 2.14.x могут убрать depricated имеется ввиду? т.е. в минорном релизе получается.
Да, могут ломать только мажорные. Deprecated обычно убирают также в мажорных релизах.
Порог вхождения какой? знать Java ?
Вообще, не обязательно.
Я бы сказал, чеклист примерно следующий:
— тривиальные императивные конструкции
— ООП
— параметрический полиморфизм(вот тут лично я впаялся в ко-/контравариантность)
— ФВП.
С таким бэкграундом можно учить синтаксис, пройти kotlin koans и садиться писать.
Впрочем, Java стоит знать хотя бы на уровне свободного чтения — библиотеки-то все на ней.
А как там с анонимными функциями? Это те же анонимные функции, что в java 8 или свои, как в groovy например?
https://github.com/JetBrains/kotlin/blob/master/spec-docs/function-types.md
TL;DR: свои, kotlin.jvm.functions.Function[0..22];

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

Моя история: давно хотел запилить себе пару приложений на андроид, но всегда пугала Java с её архаичным синтаксисом из 90-х, aka public static void main, который уже они не смогут поменять по соображениям совместимости. Хотелось проинвестировать своё время в изучение чего-то более эффективного в мире JVM. Уже собрался щупать Scala (и иметь проблемы с интеропом и слишком быстро меняющимся языком и сломом обратной совместимости) или Groovy (автор которого чуть ранее от него отказался). Но наткнулся на Kotlin. И вот, после того как я решился сделать свой проект на нём, мои волосы стали мягкими и шелковистыми. Лично для себя отметил:
— 30 минут чтения обзорных статей по базовому синтаксису, и можно начинать (если уже есть опыт в программировании).
— IDEA помогает изучать язык, выдавая в нужные моменты очень информативные подсказки.
— Она же, наконец-то, делает половину тупой работы, типа выведения типов и статического анализа за разработчика, что нереально облегчает жизнь. Не понимаю людей, которые пишут сложный код в блокнотах, Sublime или vim'е, если можно делать это в нормальных IDE.
— Маленький рантайм и прямой интероп с Java в обе стороны, без плясок. Синдром Not Invented Here и желание «переписать весь мир» под свой модный язык не наблюдаются. Наоборот, ставка на максимальное реиспользование того, что есть, но при этом чтобы делать это удобно.
— В плагине к IDEA есть крутая фича — Ctrl+Shift+Alt+K — и Java-код преобразуется в Kotlin, попутно вычищая тонны синтаксического мусора. Не всегда работает гладко, но даже я разобрался, что исправить в паре мест, чтобы заработало (когда мелкую java-либу сконвертил для того, чтобы дописать).
— Статическая типизация и их решение по nil-типу помогает существенно сократить вероятность отстрелить себе ногу.
— Кода пишешь как на Python'е (в плане читаемости и краткости), а получаешь все плюшки JVM.
— Семантически и большей частью синтаксиса похож на Swift. Очень похож (хотя Swift в плане удобства немного впереди). Так что, считай, в довесок ещё и Swift, считай, изучаешь.

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

И да, я до этого никогда не щупал ничего связанного с JVM. Java отпугивала, а небольшой опыт в Clojure — не совсем про то. Имел дело только с вещами типа Python, JS, C#.
Какой смысл писать новый язык на замену Java, если он основан на все той же тормозной JVM?
Ну на джаве написано много всего. Если надо с этим "всем" работать, но при этом не хочется сидеть на языке из 90ых — велкам котлин. Особенно если речь идет об андроиде, где скала не очень с ее оверхедом да на бедный андроидный гц.
Недавно выбирали кроссплатформеный инструмент для мак/вин/линукс. Остановились на Qt, как раз из-за тормозов JVM.
Плюс, в Qt есть QML.
А вы уверены, что тормоза были именно из-за JVM, а не из-за свинга, например?
Наврное потому что под JVM есть овер миллионы качественных библиотек на все случаи жизни. А под с++ к сожалению у даже не все делают клиентов. К примеру elastic search.
Годы идут, а люди всё продолжают верить мифам про «тормозную JVM».
Мы не верим, мы знаем, потому что пробовали. И потратили много человекочасов на оптимизацию Java-кода, GC и прочего JIT. Да, JVM тормозная. Это в первую очередь сказывается на времени старта Java-приложений, а во вторую на времени stop-the-world пауз для тех долгоживущих приложений, которым пофиг на время старта.
А можете про специфику приложения рассказать? Как JVM тюнили? Какую альтернативу используете?
Ой ли, спорный вопрос кто быстрее стартует. Огромное приложение на C++ будет в память грузится дольше, чем Java, которая по мере необходимости грузит классы. stop-the-world тоже спорная проблема, которую можно решить, если у вас конечно не realtime.
Ой ли, спорный вопрос кто быстрее стартует.


Факт «на C++ можно написать медленно стартующую программу» никак не опровергает факт «JVM медленно стартует».

Немного цифр:

$ cat Nop.java 
public class Nop
{
  public static void main(String[] args)
  {
  }
}

$ javac Nop.java

$ time java -cp . Nop

real    0m0.039s
user    0m0.030s
sys     0m0.000s

$ cat nop.c 
int main()
{
}

$ gcc nop.c -o nop

$ time ./nop

real    0m0.000s
user    0m0.000s
sys     0m0.000s


JVM тратит 40мс довольно жирного проца (i7 4770) чтобы сделать ничего, тут не о чем спорить.

stop-the-world тоже спорная проблема, которую можно решить


Попробуйте собрать мусор в приложении с хипом > 32GB. Получите паузу в несколько секунд (или даже в несколько десятков, если без тюнинга GC). И да, бывают случаи, когда приложению действительно нужно столько данных держать в памяти.
Все потому что у вас jvm это огромное c++ приложение, логично что его нужно прогрузить, да и что такое 40ms?
Вы что flash?) Для сбора мусора с большим хипом есть G1. Если нужно держать столько данных в памяти, то скорее всего нужно делать off-heap. А о чем спор собственно, вы бы еще пустой класс создали, вы посмотрите сколько стартует приложение побольше. Масштаба LibreOffice к примеру. И 40mc
Android Studio (IDEA) — тормозит, Gradle — тормозит, Android — тормозит. Это мифы?
Gradle — Groovy, Android — не JVM, IDEA — покажите отзывчивое не тормозное IDE по мощности сопоставимое с ней.
И это будет язык программирования по подписке.
Пишешь себе, пишешь. А он раз и за неуплату откатывается на год назад и половина кода перестает компилироваться :(
почему же? нормальная поддержка только в IDEA будет имеется ввиду?
гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд

насколько я понимаю, дженерики сделаны такими, потому чтобы новые бинарники воспринимались старыми JVM(правда это так и не получилось). котлин же явно декларирует, что новые бинари на старом рантайме работать не будут.
На счет устарелого дизайна коллекций и тд, в котлине есть такая фича, можно запретить использование deprecated метода в момент компиляции. То есть если через 10 JB решат, что fun mySuperPuperFunc() — это аццтой, то эту функцию они пометят @Deprecated(level = DeprecationLevel.Error) и новый код не сможет её больше юзать(не будет компилироваться). При этом старые бинари будут отлично работать. ИМХО нормальное решение
Меня немного расстраивает принципиальное пренебрежение JetBrains к русскоговорящей аудитории.
Да, понятно, что большинство из ЦА помимо родного знает и английский язык,
понятно, что так шире охват.
Но при обилии русских сотрудников в компании можно хотя бы такие статьи самим переводить.
Ну обычно JB и пишут статьи про свои продукты, причём довольно хорошо. Скорее всего, кто-то из компании сейчас оформляет статью сюда (ну я так думаю). А эта статья очень похожа на попытку успеть первым написать что-то...
я тоже так думал что вот-вот они напишут и сюда, но прошло больше суток — и ничего, поэтому решил написал сам, акцентируя конечно те аспекты в языке которые меня волнуют в первую очередь и по которым хотелось услышать мнения общественности.
Как видите прошло уже больше 2 суток а от них статьи все нет, поэтому не считаю эту статью чем то лишним или неуместным.
Я тоже не считаю её лишней, есть ведь что пообсуждать)
Думаю большинство из ЦА не знает русский язык. Sad but true.
Чувствуется, скоро количество языков будет равно количеству девелоперов и каждый сможет писать на своем неповторимом.
Желание найти волшебную таблетку от всего понятно — но какой то это экстенсивный путь что ли.
В том и соль, что за 20 лет в индустрии многое поменялось, а языки отстают. Хачить старые и сложившиеся можно либо сломом обратной совместимости (никто не хочет переписывать человекотысячелетия кода), либо нагромождением. Вот и делают новые, актуальные.
Не просто же так появляются все эти Scala, Kotlin, Go, Rust и прочие. Я думаю, это говорит о том, что штуки вроде Java, C++ и остальные просто сильно отстали от реалий современной жизни, не помгоают, а скорее мешают быстро и эффективно писать код, имеют довольно высокий порог вхождения и их уже не исправить. Это даже не поиск таблетки от всего, это скорее попытка произвести новые таблетки от современных болезней взамен тех, у которых уже дважды истёк срок годности и которые лечат от болезней, которыми уже мало кто болеет.

Для меня преимущество Kotlin в том, что в нём можно использовать всё то, что уже написано для JVM-экосистемы (в которую, напомню, вложены человекотысячелетия), при этом код писать в 3 раза быстрее, читаемее и с поддержкой актуальных концепций. Собственно, ради этого и batteries included я в своё время выбрал python, ради этого же сейчас выбираю JVM. Могу сказать, что Kotlin для Java — это как Swift для ObjC или как CoffeeScript, каким он должен был получиться, для Javascript.
Т.е. основная цель как раз — дать возможность работы с уже имеющимся, но по-новому. А не как, скажем, Go, с революционной идеей — пожертвовать всем уже созданным до него ради создания полностью своей изолированной от всего имеющегося очередной yet another экосистемы со своей атмосферой. Вот это экстенсивный путь.

А то, что предлагает Kotlin — это замена ручной пилы «Дружба-2» на нормальную импортную бензопилу для промышленного лесоповала. :)
со многим вышесказанным — согласен, но только опять же — зачем тогда было гарантировать вечную обратную совместимость сорцов например? Через 20 лет синтаксис и "этой таблетки" может устареть и придется опять хачить и поддерживать как в Java получается, а народ снова потихоньку начнет искать и переползать на "новую таблетку".

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

Публикации

Истории