Jika Anda ingin mengetahui sesuatu, pelajari yang terbaik dari yang terbaik. Hari ini, pertanyaan saya dijawab oleh dewa Corutin dan konkurensi, Roma elizarov Elizarov. Kami berbicara tidak hanya tentang Kotlin, seperti yang mungkin Anda pikirkan, tetapi juga tentang banyak topik terkait:

• Golang dan goroutine;
• JavaScript dan penerapannya untuk proyek-proyek serius;
• Java dan Project Loom;
• pemrograman olimpiade di Kotlin;
• cara belajar pemrograman dengan benar;
• dan hal-hal menarik lainnya.

Kotlin - bagus!

Hai Pertama, beberapa kata tentang diri Anda. Apakah Anda sudah lama melakukan Kotlin?

Saya memiliki sejarah panjang dengan Kotlin. Pada 2010, Kotlin memulai sebagai proyek di JetBrains, tempat saya tidak bekerja saat itu. Tetapi Max Shafirov (dia kemudian terlibat di Kotlin dan merupakan salah satu penggagas gerakan ini di dalam JetBrains) mengundang saya untuk menjadi ahli eksternal dan melihat desain dan komentar. Awalnya, bahasa ini dirancang untuk menyelesaikan masalahnya, karena JetBrains memiliki basis kode Java sendiri yang besar, dengan masalah yang dapat dipahami yang selalu ada dalam kode tersebut, dan saya ingin membuat bahasa itu sendiri sehingga kode saya dapat ditulis dengan lebih menyenangkan, efisien, dengan lebih sedikit kesalahan. Lakukan saja modernisasi. Secara alami, ini dengan cepat tumbuh menjadi gagasan bahwa karena kita memiliki masalah seperti itu, itu berarti bahwa orang lain memiliki masalah seperti itu, dan mereka membutuhkan konfirmasi dari orang lain bahwa mereka berjalan dengan benar.

Saya diundang sebagai ahli untuk melihat dan membandingkan apa yang terjadi dengan apa yang dibutuhkan. Tentang nullability - saya bersikeras bahwa ini harus dilakukan, karena pada saat itu jelas bagi saya bahwa jika Anda menulis di Jawa, ada banyak masalah, tetapi nullability adalah masalah utama yang terus-menerus Anda temui.

Saya tidak berpartisipasi dalam pekerjaan tim, saya hanya melirik secara berkala, berpartisipasi dalam kompetisi di Kotlin (Piala Kotlin). Saya telah bersaing sepanjang hidup saya, tetapi bahkan kemudian saya tidak berpartisipasi secara aktif. Misalnya, saya tidak akan mencapai final kompetisi seperti Facebook Hacker Cup, bentuknya tidak sama karena saya tidak lagi berpartisipasi dalam kompetisi secara berkelanjutan. Dan saya ambil bagian dalam Piala Kotlin dan, karena tidak menarik banyak penonton, saya dengan mudah mencapai final.

Pada waktu itu (2012-2013), Kotlin adalah pemandangan yang menyedihkan dari sudut pandang penyetelan, karena semuanya melambat di sana. Sejak itu, tim telah melakukan pekerjaan dengan baik. Saya bergabung dengan tim dua tahun lalu, tepat setelah rilis 1.0 dan sebelum Google secara resmi mengenali bahasa tersebut. Sebagai sebuah tim, saya mengambil semua jenis asinkron dan coroutine, hanya karena ternyata saya memiliki pengalaman yang tepat, saya banyak bekerja di berbagai sistem perusahaan besar di DevExperts, dan ada banyak asinkron dan komunikasi. Karena itu, saya membayangkan dengan baik bidang masalah - apa yang perlu diperbaiki dan apa yang menyakiti orang. Ini sangat sesuai dengan kebutuhan Kotlin, karena tidak hanya menyakitkan bagi kita. Itu menyakitkan semua orang. Bahkan JVM memulai Project Loom, yang seolah mengisyaratkan bahwa itu menyakiti semua orang. Saya masih berurusan dengan perpustakaan Kotlin, dan fokus utama kami adalah pada semua jenis aplikasi dan asinkron yang terhubung.

Artinya, Anda terutama terlibat dalam perpustakaan, bukan kompiler, dan hanya itu untuk itu?

Tidak, saya sedang melakukan compiler sejauh. Saya berkomunikasi dengan teman-teman, dan tim perpustakaan kami mengatur semua yang mereka lakukan di kompiler. Kami juga pelanggan, kami membuat banyak pencarian fitur ketika kami menemukan beberapa kekurangan, dan kami adalah penguji dari baris pertama dari segala sesuatu yang baru yang diluncurkan.

Ternyata, jika Anda masuk ke YouTrack, menyaring dengan Anda, Anda dapat menemukan banyak hal menarik.

Ya, Anda dapat menemukan banyak tugas, karena saya selalu menemukan sesuatu.

Anda menyebutkan Project Loom. Itu dibuat oleh orang yang membuat Quasar. Dari samping terlihat sangat lucu, saya hanya ingin menulis artikel tentang Habra tentang Loom. Bisakah Anda memberi tahu saya sesuatu tentang dia?

Saya melihat presentasi, idenya jelas. Semua orang membutuhkan coroutine dan pemrograman asinkron. Sebagai contoh, di masa lalu di JPoint, orang - orang dari Alibaba mengatakan bagaimana mereka meretas JVM dan mengacaukan hotspot, hanya menggulung di patch yang mereka bahkan tidak menulis, tetapi beberapa orang sebelum mereka. Mereka kemudian menggergaji diri mereka sendiri. Laporan yang bagus. Saya sangat merekomendasikannya.

Apakah Anda merekomendasikan melakukan ini?

Jadi perlu dilakukan di perusahaan. Setiap perusahaan besar, di atas ukuran tertentu, ketika beberapa ribu orang mulai bekerja untuk Anda (dan untuk orang yang kurang), pertahankan hack OpenJDK Anda. Dan tentu saja, jika Anda memiliki kasus pengguna yang kritis terhadap bisnis, mengapa tidak meretas sesuatu untuk Anda sendiri, saya tidak melihat masalah besar dalam hal ini. Bukannya saya merekomendasikannya, tetapi saya harus. Jika tidak ada utas ringan di HotSpot, lalu apa yang harus saya lakukan? Ini, pada kenyataannya, menunjukkan bahwa orang membutuhkan apa yang sudah matang. Dan umpan balik yang kami dapatkan di coroutine juga mengatakan bahwa ya, sudah lewat waktu, orang-orang membutuhkan stream yang ringan, orang-orang membutuhkan kereta yuzkeys untuk stream yang ringan. Fakta bahwa mereka seharusnya didukung di JDK sudah lama tertunda, dan dalam hal ini saya tidak ragu bahwa ketika Loom datang ke produksi cepat atau lambat, itu akan diminati. Ada orang yang membutuhkannya. Ada orang yang bahkan demi patch HotSpot ini.

Saya melihat masalah umum - Anda memiliki semacam server web, banyak orang mengetuknya, dan mulai memblokir pada utas.

Ini adalah masalah yang cukup umum. Dan server web, dan server aplikasi, dan backend. Jika Anda melihat presentasi yang sama dari Alibaba, mengapa hal ini diperlukan, maka mereka tidak memiliki server web, mereka memiliki arsitektur perusahaan klasik, mereka memiliki semua jenis layanan yang ditulis pada Java backend, layanan ini sedang dimuat. Saya bekerja dengan DevExperts dengan cara yang sama: layanan sedang dimuat, Anda menerima permintaan yang sama sekali tidak Anda proses - di dunia modern Anda memiliki semua yang terhubung. Dan Anda tidak memroses permintaan ini sendiri, tetapi Anda menghubungi 100500 semua layanan lain dan menunggu mereka merespons. Dan jika layanan ini lambat, maka Anda memiliki banyak utas menunggu. Anda tidak dapat memiliki puluhan ribu aliran tunggu ini. Dan hanya karena beberapa omong kosong Anda mendapatkan yang berikut: satu layanan yang Anda gunakan melambat, dan banyak utas sedang berdiri dan menunggu. Dan sekarang ini adalah masalah yang sangat besar.

Salah satu alasan mengapa orang bermigrasi ke Go secara besar-besaran bukan karena bahasanya bagus, tetapi karena ada aliran yang ringan di luar kotak, dan tidak ada masalah seperti itu: goroutine dapat menunggu, dan mereka tidak mengeluarkan biaya. Di Alibaba yang sama, solusi yang mereka implementasikan umumnya bodoh dari semua yang bodoh. Mereka tidak terlalu ringan dalam arti bahwa mereka mengalokasikan satu tumpukan besar 2 megabyte untuk masing-masing coroutine, meretas HotSpot sehingga tumpukan ini dapat diaktifkan. Mereka menghemat aliran fisik, tetapi tidak menyimpan tumpukan. Dan bagi mereka, solusinya bekerja - omong-omong, sangat sederhana, mereka memiliki patch HotSpot, seperti yang saya pahami, tidak terlalu besar. Orang-orang dari Loom memulai sesuatu yang lebih global. Mereka memutuskan untuk menghemat tidak hanya pada stream fisik, tetapi juga pada stack, agar tidak menghabiskan 2 megabyte per stream. Dalam prototipe, tumpukan saat ini melewati HotSpot, itu disalin ke dalam struktur pinggul kecil. Dan mereka dapat menggunakan kembali tumpukan fisik ini untuk tujuan lain.

Tetapi ada peretasan yang licik: ketika Anda kembali ke kinerja, mereka menyalinnya tidak semua, tetapi hanya yang paling atas.

Ya, ada mobil peretasan dan optimisasi. Apa yang akhirnya keluar dari itu sangat sulit untuk dikatakan. Karena pada contoh pendekatan dengan penyalinan, masalah berikut segera muncul: apa yang harus dilakukan dengan panggilan asli? Dari dalam panggilan asli, Anda tidak dapat lagi menyalin tumpukan panggilan asli. Pendekatan Alibaba tidak memiliki masalah seperti itu. Asli, bukan asli - apa bedanya, Anda baru saja melepaskan tumpukan itu dan meninggalkannya sendiri, mengambil tumpukan lain, semuanya berfungsi. Dan masih terlalu dini untuk mengatakan apakah itu akan berhasil atau tidak, kadang-kadang Anda bisa hidup dengan tumpukan asli ini, kadang-kadang Anda tidak bisa - pada tahap ini terlalu dini untuk mengatakan. Misalnya, cara penerapannya di Go adalah mekanisme yang sama sekali berbeda. Saat Anda mengeksekusi kode gosh, tumpukan gosh kecil digunakan. Dengan demikian, ketika sebuah gosh runtime memanggil suatu fungsi, ia akan melihat seberapa banyak kebutuhan stack. Jika tumpukan saat ini tidak cukup, itu akan dialokasikan kembali - meningkatkan ukuran tumpukan yang dipilih. Jika, karenanya, Anda membuat panggilan asli, maka mereka sudah mengambil beberapa tumpukan asli besar dari kumpulan tertentu dan menggunakannya.

Dan untuk kode gosh juga?

Itu tidak masalah. Mereka hanya dapat beralih ke tumpukan asli yang besar jika Anda perlu memanggil beberapa fungsi eksternal, yang tidak jelas berapa banyak tumpukan yang dibutuhkan. Dan ketika Anda mengeksekusi kode gosh, Anda tahu berapa banyak tumpukan yang dibutuhkan, sehingga kami dapat menjalankannya di tumpukan kecil. Ini adalah pendekatan yang sangat berbeda. Jangan menyalin, tetapi segera jalankan di tumpukan kecil. Faktanya, tidak ada banyak perbedaan antara pendekatan-pendekatan ini sampai Anda sesekali tertidur.

Kami terus-menerus ditanya pertanyaan: “Apa yang lebih cepat? Apa yang cocok? Bagaimana Anda melakukannya di coroutine? " Kami di coroutine tidak meretas JVM. Tujuan kami adalah agar ini bekerja di bawah JVM normal. Dan agar Android bekerja juga. Ada ART sendiri, yang juga tidak tahu apa-apa tentang coroutine. Jadi, tentu saja, kita harus membuat byte dengan pena, yang melakukan sesuatu yang sangat mirip dengan menyalin tumpukan yang dilakukan Loom, hanya saja kita melakukannya dalam bytecode. Kami mengambilnya ketika sudah terlambat. Ambil setumpuk, bersantai, dan salin ke pinggul. Kami tidak di runtime yang akan melakukan ini untuk kami, kami telah menghasilkan bytecode yang melakukan ini. Ini mempertahankan dan mengembalikan keadaan coroutine. Karena kami tidak menjalankan runtime, tentu saja, kami memiliki lebih banyak overhead dari ini. Dalam runtime Anda dapat melakukan segalanya dengan lebih cepat. Di sisi lain, jika Anda menggunakan coroutine untuk pemrograman asinkron, maka Anda harus tertidur, jika Anda pergi untuk menunggu respons dari beberapa layanan, dan mengirim permintaan ke beberapa layanan sangat mahal sehingga seluruh biaya overhead untuk menyalin tumpukan tidak mengganggu siapa pun - apakah itu lambat atau cepat, itu tidak masalah sama sekali. Ya, jika Anda menggunakannya secara khusus untuk pemrograman asinkron. Pada coroutine di Kotlin, sisiknya sangat besar, seperti yang ditunjukkan dalam prototipe Project Loom.

Perbedaan lain adalah bahwa karena kita di Kotlin dipaksa untuk melakukan ini dalam bytecode, kita memiliki efek samping yang menarik. Di satu sisi, tampaknya tidak berhasil, dan di sisi lain, sebaliknya. Ini terdiri dari yang berikut: tidak mungkin untuk menidurkan fungsi sewenang-wenang. Anda memerlukan fungsi yang dapat tertidur, menandai ditangguhkan dengan pengubah - perhatikan secara eksplisit bahwa fungsi tersebut dapat berhenti sementara dan menunggu sesuatu menjadi panjang. Di satu sisi, Anda tidak perlu ini di Loom, karena runtime dapat membuat apa pun tidur. Solusi Alibaba sama - Anda dapat mengambil setumpuk dari utas apa pun. Atau di Go - semuanya dapat dikunci di sana, kode apa pun dapat tertidur. Gorutin dan lakukan. Di satu sisi, pendekatan ini sangat mirip dengan pemrograman dengan utas. Seolah-olah Anda pemrograman seperti sebelumnya, hanya sekarang utas disebut serat dan menjadi sangat murah. Jika Anda hati-hati melihat presentasi dari alat tenun yang sama, ternyata serat dan benang masih merupakan hal yang berbeda. Cara memastikan bahwa kode lama yang ditulis dengan utas sepenuhnya keluar dari kotak serat - tidak jelas, dan apa yang akan berhasil - tidak ada yang tahu. Masalah mulai di sana: apa yang harus dilakukan dengan deadlock, apa yang harus dilakukan dengan kode yang dioptimalkan untuk thread lokal, sekali lagi beberapa hash atau id thread lokal melakukan beberapa optimasi kinerja. Dan Go memiliki masalah yang sama - ketika ID perangkat keras tidak diekspos, menulis semacam algoritma kinerja tinggi menjadi non-sepele.

Tetapi di Kotlin ini bukan?

Di Kotlin, kami tidak mencoba berpura-pura bahwa benang dan serat adalah hal yang sama. Kami bahkan tidak mencoba menjalankan kode lama, pada prinsipnya kami tidak memiliki tugas seperti itu. Kami mengatakan: "Maaf, karena kami tidak runtime, kami tidak dapat secara sewenang-wenang mengambil kode Java lama dan mulai beralih sesuatu di sana." Dan kami bahkan tidak akan mencoba. Kami memiliki tugas yang berbeda. Kami mengatakan bahwa kami memiliki fitur bahasa, fungsi tertidur, Anda dapat menulis kode asinkron dengannya, dan ini adalah fitur baru dari bahasa tersebut. Dan kami benar-benar menjauhkan diri dari masalah ini ("bagaimana menjalankan kode lama"), kami mengatakan: "Ada kode baru, bagus, Orthodox, Anda dapat membuatnya tidur." Hingga taraf tertentu, ini membuat hidup lebih mudah, karena Anda tidak perlu melambung baik diri sendiri atau orang, tetapi apa yang terjadi jika beberapa govnokod tua yang tidak tahu bahwa mereka akan meluncurkannya pada serat akan tiba-tiba meluncurkan pada mereka.

Dalam model kami, kami tidak memiliki kode lama, hanya kode baru, yang awalnya siap untuk fakta bahwa hari ini ada di satu utas, besok di yang lain, dan jika, misalnya, perlu mengetahui utas mana yang sekarang, ia akan mengetahuinya. Ya, Anda perlu utas lokal, tetapi ia dapat mengenalinya. Namun, ia harus siap untuk fakta bahwa hari ini utas lokal adalah satu, dan besok - yang lain. Jika dia ingin tempat-tempat ini untuk bepergian bersamanya, ada mekanisme lain untuk ini, konteks coroutine di mana dia dapat menyimpan barang-barangnya, yang, bersama dengan coroutine, akan berjalan dari benang ke benang. Ini, dalam arti tertentu, membuat hidup lebih mudah bagi kita, karena kita tidak berusaha mempertahankan kode lama.

Dan di sisi lain, kami membuat seseorang secara eksplisit berpikir tentang API mereka, katakan: di sini saya menulis sebuah fungsi di Kotlin dengan coroutine. Jika sebelumnya saya melihat beberapa metode dalam kode saya, dapatkan apa yang tidak jelas, metode ini bekerja dengan cepat dan segera kembali atau online dan dapat bekerja selama satu jam - saya hanya dapat membaca dokumentasi dan memahami seberapa cepat itu akan bekerja. Atau mungkin dia bekerja cepat sekarang, dan besok programmer Vasya Pupkin akan datang dan membuatnya online sekarang. Dengan Kotlin Coroutines, kami menyediakan mekanisme yang dijamin bahasa dengan pengubah penangguhan . Ketika saya bekerja dengan coroutine sendiri, saya melihat beberapa fungsi, jika saya tidak melihat pengubah penangguhan, itu berarti ia bekerja dengan cepat, ia melakukan semuanya secara lokal. Ada pengubah menangguhkan, yang berarti fungsi ini entah bagaimana tidak sinkron, itu akan pergi di jaringan untuk waktu yang lama. Dan membantu untuk membuat API yang mendokumentasikan diri sendiri sehingga kita dapat segera melihat apa yang menunggu kita. Ini membantu untuk segera menghindari kesalahan bodoh ketika saya lupa di suatu tempat dan di suatu tempat dalam kode yang saya sebut sesuatu yang panjang tanpa curiga.

Dalam praktiknya, ini sangat bagus. Ini perlu secara eksplisit menandai fungsi tertidur ini. Dalam Go, misalnya, ini bukan, saya tidak harus menandai apa pun di luar sana. Ternyata ini efek samping dari implementasi kami (yang harus ditandai dengan pengubah menangguhkan) membantu Anda untuk membuat arsitektur yang benar, membantu Anda untuk mengontrol bahwa Anda tidak akan menyebabkan beberapa permainan asinkron acak panjang liar di tempat di mana Anda awalnya mengharapkan semuanya terjadi dengan cepat.

Tetapi ada beberapa hal yang sulit untuk dilarang, misalnya, semacam IO jaringan, file.

Tidak, IO jaringan cukup mudah dilarang. Berikut adalah file IO - rumit. Tetapi di sini lagi, titik yang sulit: untuk sebagian besar aplikasi, file IO adalah hal yang cepat, dan oleh karena itu sangat normal bahwa ia bekerja secara serempak. Aplikasi yang sangat jarang bekerja sangat banyak dengan IO sehingga menjadi masalah baginya untuk mengambil begitu lama. Dan di sini kami memberi seseorang kesempatan untuk memilih: Anda dapat langsung membuat file IO dengan kami dan tidak mandi uap, karena itu akan memblokir apa yang terjadi (karena biasanya cepat). Tetapi jika kasing khusus Anda memiliki perhitungan yang sangat panjang, sepertinya tidak sinkron, tetapi memakan banyak waktu CPU, dan Anda tidak ingin memblokir beberapa kumpulan utas lainnya, kami menyediakan mekanisme yang mudah dimengerti: Anda memulai terpisah thread pool untuk komputasi yang berat, dan alih-alih menulis fungsi reguler yang menyenangkan menghitung () , dan menulis dalam dokumentasi “Dudes, hati-hati, fungsi ini dapat bekerja untuk waktu yang sangat lama, jadi perhatian - jangan menggunakannya di mana saja, jangan gunakan di mana saja, jangan gunakan UI ”, kami menawarkan metode yang lebih sederhana Khanisme. Anda cukup menulis fungsi ini sebagai menangguhkan menyenangkan computeSomething () , dan untuk implementasinya Anda menggunakan fungsi perpustakaan khusus denganContext , yang melempar perhitungan ke kumpulan utas khusus yang Anda tentukan. Ini sangat nyaman: pengguna tidak perlu lagi melambung ke otak: ia segera melihat penangguhan, tahu bahwa panggilan ini tidak memblokir utangnya, dan ia dapat dengan mudah menyebutnya dari aliran UI dan seterusnya.

Ini akan beralih ke aliran yang diinginkan sudah di dalam, dan alirannya tidak akan diblokir. Ini adalah pemisahan keprihatinan yang benar: pengguna tidak peduli bagaimana itu diterapkan, tetapi orang yang mengimplementasikan dapat mentransfer dengan benar ke kolam yang dibutuhkan dan mendistribusikan sumber daya komputasi dengan benar dalam aplikasinya. Dalam praktiknya, ini terbukti sangat nyaman dalam hal gaya pemrograman. Kita perlu menulis lebih sedikit dokumentasi, kompiler akan memeriksa dan memperbaiki lebih banyak.

Saya pikir betapa amannya itu. - thread pool ?

, . . , , . , . , . - . - Java, , . , , . , . -. .

Kotlin, . , .

?

, : raw types? .

.

Java?

Ya

- , - . List, .

, List. List , . . raw List, platform type, , , List . raw type, , Java , . Java, , , , , , raw type. , — , . , — . — , , raw types. , migration story.

platform type ?

flexible. nullable-. , String. , String nullable String — . , String — nullable -nullable. Kotlin , , . String, nullable String. , - Java, .

?

, , , , . Flexible , dynamic. Flexible — , Java, String, nullable String, int.

- - , .

, , . . read only mutable. List MutableList. Java List, , Java- , , - List MutableList. , Java. , Java - , . , , . , , , List, , , MutableList, List . List, String, .

- , ? - ?

, . , . It just works. Java . nullability- , , nullable . , . , , , . , , , , - . , -. - JavaFx, - , JavaFx Java, , . , - , . . , , .

, .

Tentu saja , . Kotlin Native. : , seamless C- , , - .

, Native ?

, , Kotlin JavaScript, - - . «Write once, run anywhere», , . : , Common Kotlin Portable Kotlin, , . , - - , , . , , - . , .

JVM , Java, JS , JS, Native . , , , , . - JS, . -. - : double, String. JVM- 0 «0.0», JS . . JS , , — ? , . , , JS- . , -. , . - — , , — . , , , , JVM, JS, Native — , , - . .

?

Ya , , .

, …

, . , . Loom . - JVM. , .

, , Java?

, . . — . , . , - . , for ( i in 0..10 ) , for (int i = first . , , . . , .

- ?

, … , . . JVM JS.

Node.js?

! . , JS-. , , JS- . , . , - — , JS-, - — . , . .

« ». , ?

Tentu saja , , . JVM , Java, . JVM . legacy, enterprise, . , , . , JVM. , — , . , . , — JVM « ». . API , . , . , . , , . , , .

TechTrain « ?» . . , .

JS , Kotlin Java?

Java . «Kotlin in Action», , Java-. , Java- , , Kotlin-. , «by design». , Java- . . JPoint , Kotlin . , . , 60-70% Java. Java, , - . Java .

- — , , -. as-is. , , . Kotlin , , «», «». , «» — . while — . 100500 . Tapi mengapa? , Java-. - , « Kotlin», , .

, . . , , . , .

, -, ?

, . . Java- . Android- — , . . , . — .

- , ?

, . , , . , , . — , , . Kotlin . , . - , , , . : , . C++, Java, Python. . Java - , Java, . , , puiblic static void main… -, . Java, , . ?

Kotlin : , , Python, . C++ , C++ . , , . , . , , . Kotlin — . — Python. . . , . , . . — , , , , — . , .

, — ?

, . must have. , — . . , . — . , , , .

?

… , , . . JS- — . — . JS, , . - JS, type checkers, Flow TypeScript. - JS . Python. - DSL, . Django , . , . , , , . . Django, , CRUD-. , - — . -, - , , . . . Kotlin, , Java, . core belief Kotlin, .

, - , Kotlin ?

Tentu saja! , , - CRUD-. : , , — , . -, — , . , TypeScript Flow — JS.

Kotlin , Kotlin JS TypeScript , . TS Kotlin/JS, , TS , JS-, . Kotlin/JS , . , .

, — double…

, . , , .

- .

.

?

Saya mengadakan olimpiade :-) Dan saya sendiri berpartisipasi, tetapi jarang.

Saya hanya melihat bahwa di Olimpiade Java terkadang tersedia sebagai salah satu bahasa utama.

Sekarang hampir selalu tersedia. Dia muncul sekitar lima belas tahun yang lalu. Java dan C ++ adalah dua bahasa standar yang semuanya mendukung, dan kemudian variasi, tergantung pada kompetisi.

Apakah lebih sulit untuk menang di Jawa, apakah ada overhead yang tersembunyi?

Tergantung kompetisi. Dalam kompetisi normal, sama jika ada lebih banyak tugas dalam gagasan dan algoritma yang benar. Tetapi ada beberapa jenis permainan ketika tugas melibatkan optimasi non-asimptotik, di mana Anda perlu mengoptimalkan segalanya sesuai keinginan - di sana, tentu saja, akan sulit di Jawa, Anda harus mencoba banyak. Ditambah lagi ada lead time tes yang sangat singkat. Secara kasar, jika Anda memiliki batas waktu beberapa detik, maka HotSpot melakukan pemanasan pada kode kecil dalam sedetik dan tidak peduli. Dan jika Anda memiliki batasan untuk semuanya - satu detik, maka di Jawa Anda bisa kehilangan karena fakta bahwa ketika HotSpot sedang melakukan pemanasan dan kompilasi - satu detik telah berlalu.

Ya, ada kompetisi liar di mana Jawa sulit. Tetapi kompetisi normal (populer, didukung oleh orang-orang baik) - mereka mencoba melakukan tugas dan lingkungan sedemikian rupa sehingga Java dan plus memiliki peluang yang sama. Dan alasannya jelas: meskipun Jawa tidak tumbuh dalam pendidikan, itu tidak menurun banyak di mana pun. Di suatu tempat, beberapa universitas menolak untuk belajar Jawa dan beralih ke Python - dan karena ini, termasuk, sekarang banyak kompetisi telah belajar Python. Ini adalah bahasa ketiga yang stabil yang didukung. Kompetisi utamanya adalah siswa. Ada kompetisi profesional, dan perusahaan besar melakukan sesuatu seperti Facebook Hacker Cup, di mana setiap orang dapat berpartisipasi, tetapi tetap saja, tema utama dalam pemrograman olahraga adalah sekolah dan siswa. Di tahun sekolah dan siswa, orang akan terus melakukan dan melatih. Tetapi setelah lulus, setelah pergi bekerja - sangat sedikit orang yang akan terus berpartisipasi. Oleh karena itu, pilihan bahasa ditentukan oleh apa yang digunakan dalam pendidikan. Jika mereka mengajar plus, Java dan python, maka mereka akan berada di kompetisi. Bagi banyak programmer, Java adalah bahasa pertama, masing-masing, semua kompetisi mencoba mendukung Java. Demi kompetisi untuk belajar C ++ - game. Ini untuk pemrograman sistem, pemrograman tingkat rendah, Anda tidak perlu memiliki sejuta programmer C ++, itu tidak ada gunanya sama sekali.

Bagaimana Anda menyukai gagasan menambahkan Kotlin ke daftar bahasa standar?

Sebenarnya, kami secara aktif mempromosikan ide ini. Ada ICPC, yang berlangsung setiap tahun, mengumpulkan ratusan ribu peserta di seluruh dunia, lebih dari seratus tim pergi ke putaran final. Di ICPC, Kotlin didukung. Sekarang ada daftar bahasa: C / C ++, Java, Python dan Kotlin. Tetapi untuk saat ini, tentu saja, tidak ada yang benar-benar menulis tentangnya, karena masalah ini: penetrasi ke pendidikan pada tahap yang sangat awal. Dalam kompetisi siswa, bahasa-bahasa tersebut digunakan agar siswa diajarkan.

Apakah Kotlin sudah diajarkan di suatu tempat?

Di suatu tempat tepatnya diajarkan. Misalnya, di Politeknik St. Petersburg. Tetapi kita berada pada tahap yang sangat awal, pada "langkah 0" dari proses ini.

Tidak ada kekurangan fatal?

Tidak, Kotlin lebih baik untuk pendidikan dasar daripada bahasa lain. Pendidikan yang adil bersifat konservatif. Orang-orang memiliki program yang sudah jadi, buku pelajaran. Tidak ada yang suka berubah. Mengapa seorang profesor yang mengajar pemrograman di tahun pertamanya mengubah bahasa bahasanya, apa bonusnya? Ini dapat ditinjau setiap sepuluh tahun.

Bonusnya, misalnya, adalah orang yang meninggalkannya akan lebih beradaptasi dengan kenyataan.

Tidak. Karena itu tidak begitu penting bahasa mana yang Anda pelajari terlebih dahulu. Seorang programmer profesional dalam hidupnya telah mempelajari selusin bahasa dan menggunakan sekitar tiga bahasa secara aktif. Plus semua ini terus berubah. Apa yang Anda akan diajarkan untuk memprogram terlebih dahulu tidak begitu penting. Penting berapa banyak bahasa yang Anda miliki saat lulus dari universitas - ini adalah topik lain, ini penting. Dan di sini kita dihadapkan dengan masalah di pasar konservatif yang berfokus pada otoritas. Misalnya, di China ada masalah yang diklarifikasi setelah berbicara dengan orang-orang dari sana. Anda mengambil kantor besar di mana ada banyak programmer, Anda bertanya - mengapa Anda tidak menggunakan Kotlin? Tetapi karena sekarang, mereka tidak mengajar Kotlin di universitas, dan mereka tidak ingin belajar sesuatu yang baru, tetapi mengapa mereka?

Apakah tidak demikian halnya dengan kita?

Ini ada di mana-mana, hanya pada skala yang berbeda. Dalam budaya yang berbeda dengan cara yang berbeda. Ada budaya di mana, seperti kata guru, atau seperti kata guru, Anda akan melakukannya. Di suatu tempat orang lebih mandiri, lebih rentan terhadap eksperimen, inovasi. Di suatu tempat orang akan pergi dan mempelajari semuanya sendiri. Di suatu tempat mereka tidak akan mengangkat jari dan akan melakukan apa yang diajarkan kepada mereka. Ada lebih banyak implementasi Kotlin di Rusia, tetapi ini juga karena kami berasal dari sini, kami berbicara lebih banyak di konferensi dan sebagainya.

Ini adalah generasi saya, pemrogram telah menjadi penggemar. Saya tumbuh ketika mereka yang menyukainya memprogram, mereka mempelajari semuanya sendiri, karena tidak ada apa-apa. Dan sekarang ini adalah hal massal yang sedang diajarkan. Ambil seorang programmer modern, kebanyakan melakukan ini bukan karena dia mencintai, tetapi karena mereka mengajarinya ini dan sekarang mereka membayar banyak uang. Oleh karena itu, orang-orang tersebut tidak akan mempelajari teknologi yang baru saja dirilis. Mengapa mereka membutuhkannya?

Karena Anda akan mendapatkan banyak uang menggunakan fitur keren dari teknologi ini.

Tentu tidak! Di Kotlin, Anda lebih mungkin mendapatkan lebih banyak kesenangan.

Ada hal-hal spesifik yang benar-benar memiliki nilai bisnis - kami berbicara tentang penggunaan kembali antara bagian depan dan belakang ...

Tidak semua orang membutuhkannya. Di sisi lain, dan kesenangan juga. Tidak semua orang menikmati pekerjaan mereka sama sekali. Mereka dibayar uang - mereka bekerja, tidak ada bedanya bagi mereka apakah mereka suka atau tidak. Hari kerja berakhir - mereka menutup dan melupakannya, dan mulai melakukan hal-hal lain.

Ini entah bagaimana sangat membosankan, jika tidak mengerikan.

Sayangnya, inilah kebenaran kehidupan. Tidak peduli seberapa buruknya dia. Dan orang-orang seperti itu, tentu saja, tidak peduli. Kotlin, bukan Kotlin.

Sejauh yang saya mengerti, hanya banyak orang yang bekerja di JetBrains karena mereka suka bekerja.

Tentu saja JetBrains dalam hal ini adalah sampel yang tidak representatif. Orang yang dipilih secara khusus, termotivasi, yang sangat menyukai hal ini.

Waktu kita perlahan-lahan akan segera berakhir, jadi pertanyaannya adalah: bisakah Anda menyampaikan sesuatu kepada pembaca kami di Habré? Adakah kata perpisahan, wahyu?

Saya bisa menyampaikan salam berapi-api :-) Tapi saya tidak akan mengatakan wahyu apa pun, wahyu macam apa itu? Satu-satunya kesimpulan yang dapat diambil dari percakapan kami adalah bahwa siapa pun yang menikmati pekerjaan itu bahagia. Saya membaca beberapa blog orang baik yang diprogram di Jawa, hanya bekerja tanpa kesenangan. Dan kemudian, untuk beberapa alasan, mereka menjadi penasaran, kehidupan membuat mereka, mereka mencoba Kotlin, dan tiba-tiba menemukan sendiri bahwa Anda dapat menikmati pekerjaan. Anda bisa mencintai apa yang Anda lakukan. Apa yang Anda sukai dari bahasa pemrograman. Dan bukan hanya digunakan, tanpa emosi, sebagai alat. Tentu saja, bahasa adalah alat, tetapi Anda dapat mengaitkannya secara tidak langsung, atau Anda dapat menyukainya. Ini adalah sikap yang berbeda, termasuk sikap berbeda untuk bekerja.

Kotlin memiliki banyak orang yang memiliki perasaan hangat yang sebanding dengan cinta, justru karena Kotlin hanya baik untuk program, terutama setelah Jawa. Mungkin tidak hanya setelah Jawa. Mungkin tidak ada bahasa di mana itu sangat bagus (hanya kata seperti itu) untuk diprogram. Ada bahasa dengan lebih banyak fungsi, dengan fitur yang lebih kuat, ada bahasa dengan sistem tipe yang lebih ketat, ada bahasa di mana semuanya murni, ada di mana semuanya sebaliknya - tidak aman. Ambil dimensi apa pun dan Anda akan menemukan bahasa yang lebih baik daripada Kotlin di properti ini. Tetapi Kotlin memiliki keseimbangan sehingga bukan kebetulan bahwa ia di StackOverflow dalam jajak pendapat tahun ini menempati urutan kedua dalam daftar bahasa yang paling dicintai. Tampaknya, yang pertama adalah Rust. Tetapi Rust bukan pesaing bagi kami, karena Rust adalah bahasa pemrograman sistem. Kami tidak naik ke ceruk ini. Sama sekali tidak menyebalkan bahwa Rust dalam hal ini menyalip Kotlin. Kami berusaha menjadikan Kotlin bahasa utama untuk pemrograman aplikasi yang menyenangkan untuk menyelesaikan masalah aplikasi. Kami tidak memiliki dan tidak akan pernah memiliki beberapa fitur Rust, karena mereka sama sekali tidak diperlukan oleh programmer aplikasi. Dia seharusnya tidak mengelola memori secara manual atau memikirkan seluk-beluk kepemilikan, seorang programmer aplikasi harus menyelesaikan masalah bisnis. Dia harus mengubah domainnya menjadi kode. Dan ini harus menjadi transformasi yang paling langsung tanpa faktor yang mengganggu itu. Kami berusaha menghilangkan faktor-faktor yang mengganggu ini. Sehingga Anda mengubah tugas bisnis Anda secara langsung, tanpa air dan kode tambahan menjadi solusi.

Nah, ini adalah kompetisi yang agak tidak adil - semua bahasa seperti Jawa diciptakan bertahun-tahun yang lalu, dan Anda baru saja melakukannya.

Secara alami, Kotlin memperhitungkan pengalaman para pendahulunya. Seperti bahasa modern lainnya. Ini adalah kemajuan - ketika sesuatu yang baru dibuat dengan mempertimbangkan kekurangan lama. Untuk alasan yang baik, jenis nullable dibuat di Kotlin. Nah, pergi jauh, bawa perusahaan apa saja, pergi ke kantor besar mana saja, lihat log kerusakan mereka, dan Anda akan melihat bahwa pengecualian yang paling sering adalah NullPointerException. Ini adalah fakta yang terkenal, dan jika Anda membuat bahasa baru, Anda harus menyelesaikannya. Oleh karena itu, kami membayar banyak perhatian dalam bahasa untuk nullability. Dan sebagainya. Jika Anda tidak mendesain bahasa secara abstrak, bukan sebagai latihan akademis, tetapi mencoba menyelesaikan masalah orang yang sering mereka temui, maka bahasa tersebut ternyata baik. Kenapa dia dicintai? Karena dia menyelesaikan masalah mereka.