Pull to refresh

Comments 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 обычно убирают также в мажорных релизах.
Вообще, не обязательно.
Я бы сказал, чеклист примерно следующий:
— тривиальные императивные конструкции
— ООП
— параметрический полиморфизм(вот тут лично я впаялся в ко-/контравариантность)
— ФВП.
С таким бэкграундом можно учить синтаксис, пройти 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 получается, а народ снова потихоньку начнет искать и переползать на "новую таблетку".

Вон и судя по голосованию половина народа тут считает что достаточно совместимости в пределах мажорного релиза только.
Наверное тут нет однозначно правильного ответа. И с вашим доводом согласен и понимаю, что, может, к тому времени действительно новая таблетка будет лучше хаченной старой. Лишь бы без революций, ломающих всё нахрен без веских на то причин.
UFO just landed and posted this here
таки да. Напоминает квантовую механику. Там как только физики не могут обьяснить поведение субатомной частицы они придумывают новую. И скоро у каждого физика будет собственная частица.
Sign up to leave a comment.

Articles