Kotlin 1.0最初のリリースがリリースされました

昨日、 JetBrainsの Kotlinプログラミング言語の最初のリリース（1.0） がリリースされました 。
同社の昨日のプレスリリースによると、「長い道のりでしたが、ついに最初のリリースをリリースし、同時に言語の新しいロゴ（アイコン）を発表しました」

長くエキサイティングな道でしたが、ついに最初の大きな1.0に到達しました。新しいロゴもお見せすることで、リリースを祝います。

これは、互換性、セキュリティ、表現力、優れたツールに重点を置いたJVMとAndroidの実用的な言語であるという事実に重点を置いています。

Kotlinは、オブジェクト指向と機能の機能を組み合わせたJVMおよびAndroid用の実用的なプログラミング言語であり、相互運用性、安全性、明快さ、およびツールのサポートに焦点を当てています。

Kotlinは汎用言語であるため、Javaが動作するすべての場所（サーバー側アプリケーション、モバイルアプリケーション（Android）、デスクトップアプリケーション）で動作します。 次のようなすべての主要なツールとサービスで動作します
IntelliJ IDEA、Android Studio、Eclipse
Maven、Gradle、およびAnt
Spring Boot（Kotlinサポートは本日リリース！）
GitHub、Slack、さらにはMinecraft :)

この場合、プラグマティズムの概念が強調されます-作成者は、完全に新しい言語と概念を発明することを目指していませんでしたが、たとえば、バグの出現や作成された抽象化を防ぐ型システムを構築しました-これは、コードの再利用に貢献し、核言語を非常に便利で便利なツールにすることに焦点を当てています：

長期にわたるプロジェクトでは、コアバリューを理解することが重要です。 コトリンのデザインを説明する言葉を1つ選ぶとしたら、それはプラグマティズムです。 これが、Kotlinが発明や研究にそれほど重点を置いていないことを早くから述べた理由です。 私たちはかなり多くのものを発明することになりましたが、これがプロジェクトのポイントではありませんでした。 もちろん、バグを防ぐタイプシステムと、コードの再利用を容易にする抽象化メカニズムを構築していました。 しかし、それを行うための（実用的な）方法は、ユースケースに焦点を当てて、言語を優れたツールにすることでした。

また、最も重要なのは、既存のコードとインフラストラクチャとの互換性です。

特に、このアプローチは、既存のコードおよびインフラストラクチャとの相互運用性が重要であるという概念にすぐにつながります。

再学習を減らすには、もう一度書き直してください。 再利用できるほど、良い：

しかし、エレガンスは高く評価されていますが、ここでは主要な目標ではなく、主要な目標は有用です。 また、ユーザーがゼロから再学習、再発明、再実行する必要が少なくなればなるほど、ユーザーはより多く再利用できるようになります。

同じ理由で、独自のプロジェクトコレクターを作成せず、「往復」データ変換の問題を回避するために、JDKと同じコレクションインターフェースを使用することも決定しました。

-では、なぜKotlinには独自のパッケージマネージャーやビルドシステムがないのですか？
-既にMavenとGradleがあり、多くのプロジェクトで膨大な数のプラグインを再利用することが重要だからです。
-コレクションをゼロから再設計する方がずっと簡単だったのに、なぜJDK互換のコレクションインターフェイスを作成するために多くの時間と労力を費やしたのですか？
-多数のJavaコードがJDKコレクションで機能するため、境界でデータを変換するのは面倒です。

作成者は、この言語は産業での使用に完全に対応しており、多くの実際の大規模プロジェクトでテストされていることを強調しています。

十分に成熟しており、生産の準備ができていますか？

はい そしてそれはかなり前からありました。 JetBrainsでは、コンパイラーとツールを実装しているだけでなく、過去2年間にわたってKotlinを実際のプロジェクトでかなり大規模に使用しています。 JetBrainsに加えて、かなり以前からKotlinを本番環境で使用している企業がかなりあります。

このように長いリリース方法（2010年に登場してから5年以上）は、実際のアーキテクチャの決定を徹底的にチェックすることによるものであると説明されています。 コンパイラは、Kotlinのすべての将来のバージョンと下位互換性があります。

実際、1.0に達するまでに長い時間がかかった理由の1つは、実際に設計上の決定を検証することに特に注意を払ったためです。 これは、コンパイラが前方互換性を持ち、Kotlinの将来のバージョンが既存のコードを壊してはならないためです。 そのため、どのような選択を行ったとしても、それらに固執する必要があります。

コトリンのシーンは何ですか？ オープンソースプロジェクトと何百人もの貢献者であるJetBrainsは現在、Kotlinのメインスポンサーです。 すでに、同社の約10の大きな製品がKotlinを使用しています。

現在、JetBrainsはKotlinの主な支援者です。Kotlinの開発には多大な努力を注ぎ、長期的にプロジェクトに取り組んでいます。 自社製品で使用する必要性から作成しました。 そして、これまでのところ、IntelliJ IDEA、JetBrains Rider、JetBrains Account＆E-Shop、YouTrack、およびいくつかの小規模なIDEやいくつかの内部プロジェクトがKotlinを使用しているJetBrains製品が10近くあります。 滞在するためにここにいます！

同社は、言語のさらなる開発のための提案の集中的な議論を組織し、このプロセスをさらに透明にすることを計画しています。

今後、デザインの提案と議論のための集中型の場を設置し、プロセスをさらに可視化して組織化することを計画しています。 Kotlinの標準化の取り組みはこれまでのところ開始されていませんが、後ほど早く行う必要があることを認識しています。

言語アーキテクチャとプロジェクト開発は、20人以上のフルモードの社内チームによって実行されます。

プロジェクトの言語設計と全体的な運営は、JetBrainsで採用されているチームによって行われます。 現在、Kotlinでフルタイムで働いている20人以上の人がいます。これは、KetlinへのJetBrainsのコミットメントのさらに別の証拠でもあります。

最初のリリースは、言語とその標準タイプのライブラリの長期的な後方互換性を目的としています。

1.0では、言語とその標準ライブラリ（kotlin-stdlib）の長期的な後方互換性に取り組んでいます。
-新しいコンパイラは古いバイナリで動作します（ただし、古いコンパイラは、javac 1.6がjavac 1.8でコンパイルされたクラスを読み取れないなど、新しいバイナリを理解できない場合があります）。
-古いバイナリは、実行時に新しいバイナリで動作し続けます（ただし、新しいコードでは新しい依存関係が必要になる場合があります）。

当面の計画は、言語ツールの継続的な改善、JavaScriptサポート（可能な場合はJVMとJSの両方でのコンパイル）、および新機能を使用したJava8バイトコード生成の最適化です。

計画に関して、私たちの最も近い目標は（バグ修正を除く）です。

Kotlinツールチェーンの継続的なパフォーマンスの向上（これには、現在作業中のGradleでのインクリメンタルコンパイルが含まれます）。
JavaScriptサポート（可能な場合はJVMとJSの両方へのクロスコンパイルを含む）;
最適化されたラムダなどを使用してJava 8バイトコードの生成をサポートします（Androidユーザーが必要とする限り、Java 6は積極的にサポートされます）。
ツールの更新とバグ修正は、インクリメンタル更新、つまり1.0.Xとしてリリースされます。 大きな変更は、最初に早期アクセスプログラム（EAP）を通過し、その後1.1としてリリースされます。

ドック、マニュアル-プロジェクトの公式リソースで利用可能-kotlinlang.org
フォーラムまたはチャットkotlinによるフィードバック

素敵なコトリンを！ 今:)

PSすべてが一種のクールで期待されています、ありがとう、唯一のニュアンスは疑いを投げかけるだけです-永遠の後方互換性の保証、すなわち Java自体と同じです。 これは本当に必要ですか？ 結果は、欠陥のあるジェネリック、時代遅れのコレクション設計、ラムダの便利な実装などの例で知られています。 多くは痛みから追加できます。 10〜15年ごとにこの下位互換性を尊重して言語を改善することが重要でない場合、それは非常に重要ですか？ 永遠の後方互換性を持つJavaがすでにあります。Kotlinで本当に必要ですか？ 私は投票することを提案します：