Вышел первый релиз Kotlin 1.0

Original author: Kotlin 1.0 Released: Pragmatic Language for JVM and Android
  • Translation
Вчера вышел первый релиз (1.0) языка программирования Kotlin от компании JetBrains.
Как пишет компания в своем вчерашнем пресс-релизе — «это был долгий путь но мы наконец выпустили первый релиз и вместе с тем представляем новое лого(иконку) языка»
It’s been a long and exciting road but we’ve finally reached the first big 1.0, and we’re celebrating the release by also presenting you with the new logo

image


Делается акцент на том что это прагматичный ЯП для JVM и Android c упором на совместимость, безопасность, выразительность и хороший инструментарий:
Kotlin is a pragmatic programming language for JVM and Android that combines OO and functional features and is focused on interoperability, safety, clarity and tooling support.

Being a general-purpose language, Kotlin works everywhere where Java works: server-side applications, mobile applications (Android), desktop applications. It works with all major tools and services such as
IntelliJ IDEA, Android Studio and Eclipse
Maven, Gradle and Ant
Spring Boot (Kotlin support released today!)
GitHub, Slack and even Minecraft :)


Подчеркивается понятие прагматичность в данном случае — создатели не ставили целью изобрести полностью новый ЯП и концепции, а построили например систему типов, предотвращающую появление багов или создали абстракции — которые способствуют повторному использованию кода и в целом фокусировались на вещах способных сделать ЯП очень хорошим и удобным инструментом:
Understanding one’s core values is crucial for any long-running project. If I were to choose one word to describe Kotlin’s design, it would be pragmatism. This is why, early on, we said that Kotlin is not so much about invention or research. We ended up inventing quite a few things, but this was never the point of the project. Of course we were building a type system that prevents bugs, and abstraction mechanisms that facilitate code reuse, as anybody in our position would. But our (pragmatic) way of doing it was through focusing on use cases to make the language a good tool.


А также самое критичное — совместимость с существующим кодом и инфраструктурой:
In particular, this approach lead us immediately to the notion that interoperability with existing code and infrastructure is crucial.


Чтобы меньше пришлось переучиваться, переписывать заново, т.е. чем больше можно переиспользовать — тем лучше:
But elegance, though highly appreciated, is not the primary goal here, the primary goal is being useful. And the less our users have to re-learn, re-invent, re-do from scratch, the more they can re-use, the better.


По этим же причинам — не создавался собственный сборщик проектов, а также было решено использовать теже самые интерфейсы коллекций что и в JDK, последнее в том числе для простоты, чтобы избежать проблем преобразования данных «туда-обратно»:
— So, why doesn’t Kotlin have its own package manager, or its own build system?
— Because there’s already Maven and Gradle, and re-using their huge number of plugins is crucial for many projects.
— Why did we invest a lot of time and effort into making JDK-compatible collection interfaces, when it was so much easier to just redesign collections from scratch?
— Because tons and tons of Java code work with JDK collections, and converting data on the boundary would be a pain.


Создатели подчеркивают что язык полностью готов к промышленному использованию и проверен на многих реальных масштабных проектах:
Is it mature enough and ready for production?

Yes. And it has been for quite some time. At JetBrains, we’ve not only been implementing the compiler and tooling but have also been using Kotlin in real-life projects on a rather extensive scale over the last two years. In addition to JetBrains, there are quite a few companies that have been using Kotlin in production for some time now.


Поясняется что столь долгий путь к релизу (более 5 лет с момента появления в 2010) был обусловлен тщательной проверкой архитектурных решений на практике т.к. компилятор должен быть обратно-совместимым со всеми будущими версиями Котлина:
In fact, one of the reasons it took us a long time to reach 1.0 was because we paid extra attention to validating our design decisions in practice. This was and is necessary, because moving forward the compiler will be backwards compatible and future versions of Kotlin must not break existing code. As such, whatever choices we’ve made we need to stick with them.


Что за сценой Котлина? Опенсорсный проект и сотни контрибьюторов, компания JetBrains сейчас пока основной спонсор Котлина, которая инвестировала в него огромные ресурсы и будет продолжать это делать в долгосрочной перспективе. Уже сейчас около 10 больших продуктов компании используют Котлин.
JetBrains is the main backer of Kotlin at the moment: we have invested a lot of effort into developing it and we are committed to the project for the long run. We wrote it out of our own need to use in our own products. And we’re happy to say that to date, close to 10 JetBrains products, which include IntelliJ IDEA, JetBrains Rider, JetBrains Account & E-Shop, YouTrack as well as some of our smaller IDE’s and some internal projects are using Kotlin. So it’s here to stay!


Компания планирует организовать централизованное обсуждение предложений по дальнейшему развитию языка и сделать этот процесс еще более прозрачным.
Moving forward we are planning to set up a centralized venue for design proposals and discussions, to make the process even more visible and organized. Standardization efforts have not been started for Kotlin so far, but we realize that we’ll need to do it rather sooner than later.


Архитектура языка и развитие проекта осуществляется командой внутри компании из более 20 человек в полном режиме.
Language design and overall steering of the project is done by the team employed at JetBrains. We currently have over 20 people working full time on Kotlin, which also yet another testament to JetBrains’ commitment to Kotlin.


Первый релиз нацелен на долгосрочную обратную совместимость языка и его библиотеки стандартных типов:
As of 1.0, we are committed to long-term backward compatibility of the language and its standard library (kotlin-stdlib)
-a newer compiler will work with older binaries (but older compilers may not understand newer binaries, like javac 1.6 can’t read classes compiled by javac 1.8);
-older binaries will keep working with newer binaries at runtime (newer code may require newer dependencies, though).


Ближайшие планы — постоянные улучшения инструментариев языка, поддежка JavaScript (компиляция как в JVM так и в JS где это возможно) и оптимизация генерации Java8 байткода с использованием новых возможностей.
As for the plans, our nearest goals are (apart from bug fixes):

Constant performance improvements for the Kotlin toolchain (this includes, for example, incremental compilation in Gradle, that is in the works now);
JavaScript support (including cross-compilation into both JVM and JS where possible);
Support generating Java 8 byte code with optimized lambdas, etc (Java 6 will be actively supported as long as Android users need it).
Tooling updates and bug fixes will be released as incremental updates, i.e. 1.0.X. Bigger changes will first go though an Early Access Program (EAP) and then will be released as 1.1.


Доки, мануалы — доступны на официальном ресурсе проекта — kotlinlang.org
Обратная связь через форум или чат котлина


Have a nice Kotlin! Now :)


p.s. все вроде круто и ожидаемо, всем спасибо, единственный нюанс только навевает сомнения — гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд. многие могут сами добавить из наболевшего. Так ли это будет критично если раз в 10-15 лет эта самая обратная совместимость будет не соблюдаться для изменения языка в лучшую сторону? У нас уже есть Java с вечной обратной совместимостью, так ли нужно это теперь еще в Котлине? Предлагаю голосовать:

Only registered users can participate in poll. Log in, please.

Нужна ли в Котлине «вечная» обратная совместимость?

Share post

Comments 41

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

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

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

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

            Моя история: давно хотел запилить себе пару приложений на андроид, но всегда пугала 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#.
              –13
              Какой смысл писать новый язык на замену Java, если он основан на все той же тормозной JVM?
                +3
                Ну на джаве написано много всего. Если надо с этим "всем" работать, но при этом не хочется сидеть на языке из 90ых — велкам котлин. Особенно если речь идет об андроиде, где скала не очень с ее оверхедом да на бедный андроидный гц.
                  –5
                  Недавно выбирали кроссплатформеный инструмент для мак/вин/линукс. Остановились на Qt, как раз из-за тормозов JVM.
                  Плюс, в Qt есть QML.
                    +5
                    А вы уверены, что тормоза были именно из-за JVM, а не из-за свинга, например?
                      +4
                      Наврное потому что под JVM есть овер миллионы качественных библиотек на все случаи жизни. А под с++ к сожалению у даже не все делают клиентов. К примеру elastic search.
                      +21
                      Годы идут, а люди всё продолжают верить мифам про «тормозную JVM».
                        0
                        Мы не верим, мы знаем, потому что пробовали. И потратили много человекочасов на оптимизацию Java-кода, GC и прочего JIT. Да, JVM тормозная. Это в первую очередь сказывается на времени старта Java-приложений, а во вторую на времени stop-the-world пауз для тех долгоживущих приложений, которым пофиг на время старта.
                          +4
                          А можете про специфику приложения рассказать? Как JVM тюнили? Какую альтернативу используете?
                            +1
                            Ой ли, спорный вопрос кто быстрее стартует. Огромное приложение на C++ будет в память грузится дольше, чем Java, которая по мере необходимости грузит классы. stop-the-world тоже спорная проблема, которую можно решить, если у вас конечно не realtime.
                              –2
                              Ой ли, спорный вопрос кто быстрее стартует.


                              Факт «на 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). И да, бывают случаи, когда приложению действительно нужно столько данных держать в памяти.
                                +9
                                Все потому что у вас jvm это огромное c++ приложение, логично что его нужно прогрузить, да и что такое 40ms?
                                Вы что flash?) Для сбора мусора с большим хипом есть G1. Если нужно держать столько данных в памяти, то скорее всего нужно делать off-heap. А о чем спор собственно, вы бы еще пустой класс создали, вы посмотрите сколько стартует приложение побольше. Масштаба LibreOffice к примеру. И 40mc
                            –1
                            Android Studio (IDEA) — тормозит, Gradle — тормозит, Android — тормозит. Это мифы?
                              +4
                              Gradle — Groovy, Android — не JVM, IDEA — покажите отзывчивое не тормозное IDE по мощности сопоставимое с ней.
                                +2
                                а железо норм?

                                i5-3470 3.20GHz × 4, 16G оперативы, ssd диск +проекты на тонны java кода — IDEA летает.
                            +17
                            И это будет язык программирования по подписке.
                              +9
                              Пишешь себе, пишешь. А он раз и за неуплату откатывается на год назад и половина кода перестает компилироваться :(
                                –2
                                почему же? нормальная поддержка только в IDEA будет имеется ввиду?
                                +3
                                Давайте вместе переведем доку по котлину? :) http://kotlin.su
                                  0
                                  гарантия вечной обратной совместимости, т.е. тоже самое что и в самой Java. Так ли это необходимо? Последствия известны на примере ущербных generics, устаревшего дизайна коллекций и не всегда удобной реализации лямбд и тд

                                  насколько я понимаю, дженерики сделаны такими, потому чтобы новые бинарники воспринимались старыми JVM(правда это так и не получилось). котлин же явно декларирует, что новые бинари на старом рантайме работать не будут.
                                  На счет устарелого дизайна коллекций и тд, в котлине есть такая фича, можно запретить использование deprecated метода в момент компиляции. То есть если через 10 JB решат, что fun mySuperPuperFunc() — это аццтой, то эту функцию они пометят @Deprecated(level = DeprecationLevel.Error) и новый код не сможет её больше юзать(не будет компилироваться). При этом старые бинари будут отлично работать. ИМХО нормальное решение
                                    +3
                                    Меня немного расстраивает принципиальное пренебрежение JetBrains к русскоговорящей аудитории.
                                    Да, понятно, что большинство из ЦА помимо родного знает и английский язык,
                                    понятно, что так шире охват.
                                    Но при обилии русских сотрудников в компании можно хотя бы такие статьи самим переводить.
                                      +3
                                      Ну обычно JB и пишут статьи про свои продукты, причём довольно хорошо. Скорее всего, кто-то из компании сейчас оформляет статью сюда (ну я так думаю). А эта статья очень похожа на попытку успеть первым написать что-то...
                                        +2
                                        я тоже так думал что вот-вот они напишут и сюда, но прошло больше суток — и ничего, поэтому решил написал сам, акцентируя конечно те аспекты в языке которые меня волнуют в первую очередь и по которым хотелось услышать мнения общественности.
                                        Как видите прошло уже больше 2 суток а от них статьи все нет, поэтому не считаю эту статью чем то лишним или неуместным.
                                          0
                                          Я тоже не считаю её лишней, есть ведь что пообсуждать)
                                          0
                                          del
                                          +2
                                          Думаю большинство из ЦА не знает русский язык. Sad but true.
                                          +1
                                          Чувствуется, скоро количество языков будет равно количеству девелоперов и каждый сможет писать на своем неповторимом.
                                          Желание найти волшебную таблетку от всего понятно — но какой то это экстенсивный путь что ли.
                                            +1
                                            В том и соль, что за 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» на нормальную импортную бензопилу для промышленного лесоповала. :)
                                              0
                                              со многим вышесказанным — согласен, но только опять же — зачем тогда было гарантировать вечную обратную совместимость сорцов например? Через 20 лет синтаксис и "этой таблетки" может устареть и придется опять хачить и поддерживать как в Java получается, а народ снова потихоньку начнет искать и переползать на "новую таблетку".

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

                                            Only users with full accounts can post comments. Log in, please.