Mengikuti jejak gerakan Scala Rusia. Bagian 3

Ini adalah bagian terakhir dari penyelidikan gerakan Scala di Rusia. Pada bagian pertama, saya belajar dari Roman Grebennikov tentang beau monde Voronezh, C ++ dan Erlang, dan dari Roman Timushev tentang Akka pertama dan kelahiran pertemuan Moskow. Pada bagian kedua, saya berbicara dengan Alexander Podkhaluzin dan Mikhail Mutsyanko : mengenal Scala, 2007, Scala Days, Scala Native, pindah ke Kotlin, daripada Scala baik untuk bank, acara pertama di St. Petersburg, Eclipse, Jason Zaugg, IDE dan Scala Plugin.



Selama persiapan bagian kedua, Vladimir Uspensky ( vuspenskiy ) mengarahkan saya ke Alexander Podkhalyuzin , yang dengannya kami merekam wawancara besar. Hari berikutnya saya menerima pesan dari Vladimir, tetapi sekarang dengan sejarah pribadinya: Qiwi, Scala di Tinkoff, pertemuan pertama, tautan ke blog lama (terima kasih khusus untuk ini), dan fungsionalisme dari 2008 dari Rúnar, yang berjalan di Jawa, - ini masih darah dari mata, setidaknya tidak biasa. Selain itu - kisah-kisah Roman Elizarov , Alexei Fomkin dan Nikolai Tatarinov . Fitur mempekerjakan pengembang Scala, kursus tentang Coursera, kompilasi "kode sempurna", "iblis", desain di Kotlin, 10.000 baris kode, perbankan Internet Tinkoff, lagi-lagi Tinkoff, Play Framework, meninggal dunia Flash, "Sunrise" dan pertemuan St. Petersburg - tentang semua ini di bagian akhir trilogi di bawah potongan.

Vladimir Uspensky: Coursera, Tinkoff dan fitur perekrutan untuk Scala

Vladimir : Pada waktu itu saya bekerja di Qiwi dan refactored banyak kode Java, tetapi masih banyak air dan boilerplate. Saya tersiksa, tetapi entah bagaimana merendahkan diri.

Setelah beberapa waktu, saya pergi ke blog Alexander Temerev dan Vlad Patryshev . Vlad berada di garis depan dalam implementasi Java, seperti yang saya mengerti. Saya membaca tentang Scala dengan mereka, mulai memperhatikan menyebutkan konstruksi aneh bagi saya saat itu, seperti opsi di Jawa . Saya bahkan meluncurkan opsi ini di suatu tempat dalam produksi. Ada Penanganan Kesalahan Malas yang lebih eksotis di Jawa dan Paralelisme Jawa Orde Tinggi oleh Rúnar Bjarnason . Semua ini meledakkan otak dan bertanya-tanya bagaimana cara menerapkannya semua.

Ketika saya mempelajari contoh-contoh spesifik, misalnya, dari Daniel Spiewak : Scala for Java Refugees , ini persis apa yang saya lewatkan. Semua air dan inkonsistensi aneh seperti `_` vs `*` vs `?` Dari kode Java `_` vs `*` vs `?` , dan esensi tetap.

Itu adalah Scala 2.7 dan, lebih tepatnya, itu tidak stabil. Banyak proyek telah mencobanya untuk tes unit atau Kelas Kasus. Untuk menambahkan Scala ke proyek Java, Anda harus mengonfigurasi kompilasi bersama di Maven . Tetapi saya memutuskan untuk mencoba dan menambahkan dukungan ke satu proyek tidak penting di Qiwi. Semuanya bekerja - saya sangat senang, tapi di situlah akhirnya.

Bekerja di implementasi Tinkoff dan Scala

Tiba-tiba, saya diundang ke Tinkoff untuk memimpin pengembangan bank Internet baru, yang sepenuhnya dikembangkan di dalam perusahaan. Pada awalnya saya menemukan tugas-tugas saat ini, tetapi ketika saya sampai di backend, saya menyadari bahwa sudah waktunya untuk mengimplementasikan Scala.

Baru saja keluar Scala 2.9 dengan sintaksis modern, pada waktu itu. Koleksi paralel yang trendi sangat cocok untuk menjalankan sesuatu dengan cepat secara paralel, jika detailnya tidak penting. Dan pencipta Groovy James Strachan mengeluarkan : "Saya dapat dengan jujur ​​mengatakan jika seseorang telah menunjukkan kepada saya buku Programming Scala karya Martin Odersky, Lex Spoon & Bill Venners pada tahun 2003 saya mungkin belum pernah menciptakan Groovy."

Faktor lain dalam memilih Scala adalah bahwa semua orang yang kemudian mengerjakan alat, bahasa, perpustakaan, atau menulis tentang Scala adalah super pintar dan energik. Karena itu, ada kepercayaan bahwa ini adalah pilihan yang tepat untuk masa depan.

Tepat ketika bekerja di bank, saya mulai pergi ke konferensi asing. Scala Days pertama di 2012, flatMap geeky di Oslo. Saat itu saya bertemu Zhenya Burmako . Sekarang kita kadang-kadang berjalan di sepanjang lautan sudah ada di sini di California.

Mempekerjakan Pengembang Scala

Secara bertahap menulis bank online. Pada 2012, ia menjadi yang terbaik di Rusia menurut Global Finance . Bagi saya, ini adalah konfirmasi dari pernyataan "Lakukan secara normal, itu akan normal", dan bukan sesuatu yang luar biasa.

Oleg Tinkov mempromosikan topik bank, yang lucu. Mungkin ini membantu kami mempekerjakan pengembang yang baik - orang-orang ada di tim, tetapi saya ingin berkembang. Pertama, kami menulis dalam lowongan "Java-programmer, Scala - plus." Tetapi menyebutkan Java dalam pekerjaan untuk pengembang Scala memotong orang-orang yang tidak ingin ada hubungannya dengan Java. Karenanya, kami mengubah lowongan menjadi Pengembang Senior Scala. Ini memungkinkan saya untuk mempekerjakan beberapa orang yang saya ingin sekali bekerja pada suatu hari nanti.

Grup Facebook

Saya ingin memahami siapa, secara umum, di Rusia dan Moskow, yang juga secara independen tertarik pada Scala, dan apa yang dipikirkan masyarakat. Tidak ada pertemuan atau obrolan, dan idenya adalah untuk mengumpulkan semua orang. Dia membuat grup di Facebook , di mana kami merencanakan beberapa pertemuan pertama. Apa itu pertemuan tanpa grup di Meetup ? Saya pergi untuk membuat, tetapi grup sudah ada - Roman Timushev dibuat. Kami memutuskan untuk bergabung, dan menambahkan Misha Aksarin .



Pertemuan pertama dikumpulkan dengan dalih kursus Scala tentang pemrograman reaktif di Coursera . Banyak yang mengintip, tetapi sekitar 20 orang datang: mereka bertemu, memberi tahu siapa yang mereka lakukan dan tertarik, mendiskusikan latihan dari kursus dan setuju untuk bertemu lagi.

Jadi itu dimulai.

Roman Elizarov: 10.000 baris tentang Scala, perfeksionisme, dan kompilasi tanpa ampun

Roman Elizarov ( elizarov ) - pemimpin kelompok JetBrains, berpartisipasi dalam pekerjaan pada coroutine, perpustakaan di Kotlin.

Catatan oleh penulis . Sebelum merekam wawancara, saya pikir itu akan menjadi bencana jika saya mengambilnya hanya dari orang-orang yang terlibat dalam Scala. "Pemujaan" terus menerus atau, lebih buruk, "kesalahan orang yang selamat". Karena itu, saya memutuskan bahwa saya pasti akan menambahkan lalat di salep.

Ini lebih sulit - orang dengan pengalaman nyata yang karena suatu alasan belum memasuki bahasa adalah urutan besarnya lebih kecil daripada pembenci dengan nol pengalaman di Scala. Tapi kemudian saya ingat posisi Roman Elizarov ( elizarov ) - pemimpin kelompok JetBrains - di mana ia menulis di Scala di antara kasus-kasus itu, yang menyebabkan banyak kejenuhan, termasuk tambang. Meskipun negatif, tidak mungkin bahwa Roman menulis posting pada beberapa rumor tentang bahasa tersebut. Pasti ada alasan, semacam pengalaman negatif dari penggunaan - ternyata seperti itu. Di bawah ini wawancara dengannya hanya tentang ini, dan beberapa diskusi tentang desain dan koneksi coroutine dengan Scala CPS Plugin.

Kasus pada tahun 2010

Roman Elizarov : Sekitar tahun 2000, saya memprogram semua jenis enterpases di Jawa. Oleh karena itu, saya mengikuti bahasa JVM, termasuk Scala. Tampaknya pertama kali saya membaca tentang bahasa sekitar 2005-2006.

Ketika Anda membaca secara abstrak, sintaksnya sangat keren. Saya ingat membaca deskripsi, bermain-main, dan saya sangat menyukai semuanya. Banyak hal di Jawa yang terperinci dan sulit untuk dikerjakan, mudah dilakukan di Scala. Semua ini sudah membuat saya tertarik, bukan dari sudut pandang FP, tetapi dari yang pragmatis - saat kita menulis kode. Tapi, karena basis kode Java sudah besar, banyak kelas saat ini, itu tidak mungkin untuk digunakan dalam praktek sampai cerita terjadi pada 2010.

Pada 2010, mitra kami dari Amerika Serikat, dari perusahaan, bosan. Mereka menginginkan hal-hal baru, dan mereka menulis sebuah subsistem baru sepenuhnya di Scala. Dia memiliki semacam antarmuka web, dia melakukan sesuatu yang sederhana. Pada saat yang sama, ini bukan Kerangka Play - hanya layanan web menerima permintaan dari pengguna, yang disebut Java API. Situs web normal untuk melakukan semacam fungsi interaktif internal. Mitra gash itu, itu berhasil, semuanya baik-baik saja.

Saat itu kami adalah kontraktor mereka. Pengembang subsistem telah bermain cukup dan memutuskan untuk melakukan hal-hal lain. Pelanggan kami mendatangi kami dan berkata: "Guys, ambil benda ini untuk dukungan? Dia tetap menggunakan API Anda. " Hebat, ini dia - cara nyata untuk mencoba dengan Scala. Jadi tidak ada yang mengizinkan kami untuk memprogram di Scala, karena semuanya sulit, tetapi karena sudah ada proyek, itulah alasannya. Ini, pada kenyataannya, pengalaman produksi pertama dengan Scala.

Kesan pertama Scala adalah seberapa kompak kodenya daripada di Jawa . Scala memungkinkan Anda menulis hal-hal rumit secara kompak. Subsistem mengambil sekitar 10.000 baris kode, tetapi di Jawa dibutuhkan dua kali lebih banyak karena kelas-kelasnya. Sintaksnya, semua objek internal untuk transfer data, bahkan seluruh adaptasi Java API semuanya kompak.

10.000 baris pertama dan terakhir di Scala

Ketika pengembang pergi, mereka meninggalkan kode yang belum dirangkai - dalam arti hanya kode . Kami mencoba mengambilnya untuk dukungan, tetapi ada masalah - kompilasi.

Kompilasi kode Scala adalah sebuah pencarian. Kode hanya mengkompilasi dengan versi spesifik Scala Compiler - akurat ke versi titik, ke versi patch. Versi yang lebih besar atau lebih kecil tidak lagi dikompilasi .

Ini memutuskan bagi saya pada tahun 2010 nasib Scala di perusahaan, di mana ada jutaan baris kode. Menakutkan membayangkan bagaimana hidup jika Anda mengubah versi minor kompiler dan tidak akan melakukannya.

"Kamu tidak akan ingat persis mengapa?"

Roman Elizarov : Mengapa itu berantakan saya tidak ingat, tentu saja. Sesuatu terus berubah dari versi ke versi. Mungkin kita berada di waktu yang salah?

Tetapi saya terus memantau perkembangan Scala, meskipun faktanya hanya di perusahaan kami tidak mengimplementasikan ini. Akibatnya, fungsionalitas dipindahkan ke aplikasi Java lainnya. Pada Scala ini di perusahaan ini tidak ada lagi.

10.000 baris ini adalah yang pertama dan satu-satunya. Kode ini berfungsi untuk waktu yang lama dalam produksi, tetapi kemudian diurai oleh layanan lain dan dihilangkan.

Khusus untuk kegiatan profesional saya, pengalaman ini meninggalkan bekas yang tak terhapuskan, dalam arti bahwa, bagaimanapun, kompatibilitas semua ini diperlukan. Sekarang saya melakukan Kotlin. Tidak mengherankan bahwa kita hanya menghabiskan jumlah waktu yang tidak realistis dan kekuatan tambahan untuk memastikan kompatibilitas segala sesuatu. Kadang-kadang jumlah waktu yang liar tidak masuk ke fungsi, tetapi hanya agar semuanya kompatibel. Secara khusus, pengalaman masa lalu saya mempengaruhi ini.

Masih terus mengingat Python. Mengenai kompatibilitas, kami memiliki dua bug: Scala dan Python. Ketika datang ke kompatibilitas, tidak ada yang ingin mengulang transisi dari 2 ke 3 Python, dan tidak ada yang ingin menjadi seperti Scala.

"Kode sempurna"

- Seringkali Anda ingin mengulang sesuatu sehingga semuanya “cokelat”?

Roman Elizarov : Saya terlibat dalam desain dan saya selalu ingin mengulang semuanya . Saya tidak pernah menyukai apa yang saya lakukan. Sementara saya sedang mempersiapkan sesuatu untuk dirilis, saya menemukan beberapa hal yang ingin saya ubah. Segera setelah saya melepaskan sesuatu, saya sudah melihat kekurangan di dalamnya: belum selesai, di sini kita harus menulis ulang dari awal. Tapi ini jalan ke mana-mana. Hanya ada dua pendekatan: baik saya akan meningkatkan kode tanpa batas waktu dan tidak pernah sampai ke rilis, atau saya akan meluncurkan rilis dan itu akan menjadi Legacy. Anda tidak dapat merilis kode yang sempurna .

Lalu saya menghabiskan separuh waktu untuk meningkatkan produk, dan yang kedua pada kompatibilitas dengan apa yang sudah saya rilis. Pengalaman membantu "meletakkan sedotan" di muka. Saya melihat bahwa saya harus segera memperbaikinya, dan menghabiskan banyak waktu pada saat rilis di jaring pengaman untuk mengantisipasi perubahan di masa depan. Tentu saja, melakukan sesuatu dari awal dan tidak mengkhawatirkan kompatibilitas jauh lebih mudah. Tetapi komprominya adalah Anda melakukannya dengan sempurna, atau mereka menggunakan produk Anda. Satu tidak termasuk yang lain.

Desain di Kotlin

Roman Elizarov : Saya terus-menerus mengikuti Scala, karena ketika kami merancang sesuatu di Kotlin, kami mempelajari apa yang dimiliki bahasa lain, termasuk Scala. Sekitar dua tahun lalu, kami merancang coroutine Kotlin. "Inspirasi" utama adalah, tentu saja, C #. Semuanya dimulai dengan dia dan dari sana sudah lahir itu saja. Kemudian kami mulai mempelajari Go.

Ketika desain mulai menyimpang dari C # dan "kelanjutan" muncul, dan kemudian "kelanjutan dibatasi", kami mulai mempelajari bahasa lain sekali lagi. Di Google, saya menemukan Scala - ternyata sudah ada " kelanjutan yang dibatasi " di dalamnya.

- Apakah Anda berbicara tentang Plugin Compiler?

Roman Elizarov : Ya. Pada saat yang sama, desainnya sangat mirip dengan yang sekarang ada di Kotlin. Tentu saja ada perbedaan sintaksis: di Kotlin kami menulis pengubah penangguhan di awal, dan di Scala Anda menulis anotasi csp pada nilai pengembalian. Tapi apa bedanya di mana harus meletakkan pengubah: dalam jenis nilai pengembalian atau di awal?

Desain di Scala sangat mirip dengan yang ada di Kotlin. Saya menjadi tertarik - bagaimana, karena desain yang begitu keren, mengapa tidak terbang? Mengapa tidak ada yang menulis seperti itu di Scala modern? Mereka menunjukkan kepada saya bagaimana mereka menulis di Play Framework - tidak ada plugin di sana.

Semua orang menulis futures, dan kami punya ide bagus untuk menghilangkan futures, karena desain ini lebih nyaman. Dan begitulah yang terjadi di Kotlin: masa depan tidak diperlukan, ada coroutine. Di Scala, mereka meninggalkan "kelanjutan" dan tidak terbang. Mengapa

Tidak masuk akal dan kejamnya kompilasi

Dalam proses pencarian, saya menemukan pengumuman paling orisinal. Tahun itu, "kelanjutan dibatasi" muncul di Scala. Di Scala maka semuanya dilakukan sama seperti sekarang di Kotlin.

Pengumuman dalam hal ini bersifat indikatif. Dikatakan: "Kami melakukan" pembatas yang dibatasi ", lihat, kita dapat menulis hal-hal keren yang sama seperti di Lisp." Sebagai contoh, kami mengambil contoh pada Lisp dari karya-karya tahun 80-90an, dan menulis ulangnya di Scala: daftar di-dock, di sini “shift / reset”. Dalam Lisp dan bahasa serupa, ada konstruksi untuk kelanjutan yang dibatasi , yang ditetapkan sebagai "shift / reset". Nama meledak otak - tidak ada yang tahu apa itu shift / reset. Baik orang yang telah mempelajari Lisp, maupun orang yang belum pernah bertemu dengannya.

Hal utama dalam pengumuman ini adalah komentar seperti ini: “Ini masuk akal. Saya hanya menghabiskan waktu di Wikipedia dan juga beberapa tempat lain untuk mencoba memahami hal ini. Dari sudut pandang saya, ini adalah cara berbelit-belit untuk menambahkan angka dan saya tidak tahu apa yang diperoleh atau dicapai. " Mereka menjelaskan inti dari posting tersebut.

Karena itu, pengumuman fitur penting seperti itu sama sekali tidak berguna. Jika dibaca oleh orang yang menulis kode untuk aplikasi, ia tidak akan menerima jawaban untuk pertanyaan: "Mengapa saya membutuhkan ini sama sekali? Masalah apa yang akan dipecahkannya? ”Penulis tidak mengajukan pertanyaan seperti itu. Oleh karena itu, fitur tidak terbang - bukan karena itu buruk, tetapi karena tidak ada tugas untuk terbang .

"Apakah dia salah diterapkan?"

Roman Elizarov : Ya, mereka salah mengajukan. Seolah-olah diumumkan, tetapi mereka tidak menjelaskan mengapa itu diperlukan dan masalah apa yang bisa dipecahkan. Tetapi masalahnya bukanlah "kebenaran" atau keindahan. Ngomong-ngomong, kami di Kotlin juga tidak tahu cara menulis posting blog yang indah, tetapi menulis posting yang tepat tidak cukup untuk menulis pengumuman yang indah. Presentasi yang benar bukan merupakan penjelasan mengapa, tetapi juga penjelasan dari sudut pandang API .

Saya membaca kode, dan di sana metode shift / reset digunakan. Mengapa disebut shift / reset di tahun 70-an? Saya mencoba mencari penulis nama dari masa lalu, tetapi tidak bisa. Hanya seseorang yang datang dengan nama ini. Bagi seorang programmer modern, kata-kata ini tidak mengatakan apa-apa sama sekali. Mereka tidak berarti apa-apa.

Saya berurusan dengan coroutine begitu banyak sehingga sepertinya saya harus tahu segalanya tentang mereka, karena saya membaca banyak makalah ilmiah. Tetapi ketika saya melihat kode yang menggunakan "shift / reset", saya berusaha keras setiap kali untuk memahami apa yang terjadi di sana dan mengapa itu diperlukan sama sekali. Sepertinya semacam sihir hitam, sementara tidak ada artinya.

Alexey Fomkin: Flash almarhum, Voskhod dan pertemuan Moskow pertama

Alexey Fomkin ( yelbota ) - programmer, pembicara, podcast, kontributor Open Source, penggemar Scala.

Catatan oleh penulis . Setelah mundur dari urusan Timushev dan Uspensky , seluruh gerakan di Moskow bersandar pada Alexey Fomkin . Selain itu, ia meluncurkan podcast Scalalaz , dan melihat podcast lain: DevZen , Debriefing , Remote Talk . Melewatkannya dalam seri artikel ini akan menjadi kesalahan besar.

Dari bisnis Anda ke pengembang Scala

Alexey Fomkin : Saya mungkin akan sangat bosan - tidak ada yang menarik. Saya punya kisah pribadi saya. Ini menarik bagi saya, tetapi bagi pembaca mungkin membosankan.

Sebenarnya, saya terlibat dalam Action-Script, dan kemudian saya memiliki bisnis kecil saya sendiri. Ketika bisnis ditutup, saya dibiarkan tanpa segalanya, karena Flash sudah mati saat itu. Karena itu, tidak ada yang lain dalam resume saya. Saya sedang mencari pekerjaan, saya merasa tertekan secara emosional karena saya kehilangan segalanya.

Saya tidak melihat diri saya sebagai direktur teknis, bahkan pemimpin tim sekalipun. Setelah kegagalan dengan perusahaannya, hanya ada ambisi untuk programmer biasa. Saya mencoba untuk mendapatkan pengembang JS di Yandex. Tetapi mereka menolak saya karena saya tidak mengenalnya dengan baik - yang tentu saja benar.

Lalu aku teringat Scala. Saya mencobanya berkali-kali, mulai tahun 2010 - Saya suka bahasanya. Saya mencobanya karena di kantor tempat saya bekerja pada 2010, ada Oaml. Saya ingin, seperti OCaml, hanya untuk memiliki JVM - saya menyukainya. Di samping, saya menulis beberapa proyek tentang Scala, dan pada 2014 saya mulai mendaftar di perusahaan saya.

Ada ide untuk bergerak menuju Scala: ada banyak penawaran, banyak proyek, dan pengembang kekurangan pasokan. Kemudian saya tegang dan dalam beberapa bulan berhenti dan memperbarui semua pengetahuan saya. Saya beruntung - saya mendapat direktur teknis dan mengetik tim Scala.

Voskhod, obrolan Skype, dan organisasi pertemuan pertama

Pada saat yang sama, saya berpikir bahwa kita harus mencoba untuk membangkitkan beberapa hal, sampai topiknya tidak berkembang di Rusia. Dia berbicara dengan Uspensky , Timushev , dan Askarin . Ternyata Askarin dibiarkan sendirian - Uspensky "ada di koper." Saya berbicara tentang melakukan Meetup atau tidak. "Ya, benar." Dan ini adalah mitap terakhir yang diatur tim lama. Itu di beberapa lembaga negara, Research Institute "Voskhod" .Aku pergi ke sana, bercerita tentang Scala JS atau sesuatu, dan kemudian topik ini mati sama sekali. Karena semuanya begitu buruk dan tidak ada kegiatan, saya memutuskan untuk mengatur semuanya sendiri - saya mulai menjadi aktif dalam obrolan Skype, di mana rockies nongkrong.

- Berapa banyak orang di sana?

Alexey Fomkin : Saya tidak ingat - tidak banyak dari mereka dalam obrolan modern. Tulang punggung utama adalah 10-50 orang yang terus berbicara. Sisanya datang, pergi, ajukan pertanyaan - sama seperti sekarang.

Itu tahun 2015: Skype chat, Scala.js, pertemuan pertama dengan perusahaan tempat dia bekerja. Kami menggunakan Scala dengan kuat, dan saya mempromosikan Scala.js. Saya pergi ke semua jenis pengembang JS, di podcast, berbicara tentang Scala.js dan memanggil Meetup.

Pada 2016, kami memulai podcast. Saya menangis dan menanggapi banyak orang. Pada prinsipnya, hampir semua masih tersisa, kecuali Taranenko . Kemudian Grigory Pomadchin dan Olya Makhasoeva bergabung .

- Adakah yang membantu mitaps? Saya kesal ketika Anda pergi - seolah-olah semuanya sudah mati.

Alexey Fomkin : Di dalam perusahaan Max Pavlov membantu. Dia tahu cara memprogram, tetapi lebih banyak manajer. Saya terlibat dalam presentasi, bagian Scala, dan Max membantu organisasi: tempat, peralatan, pendaftaran.

Semuanya disponsori oleh Data Monsters , alias Flexis, alias Adi Sait - nama yang berbeda pada waktu yang berbeda. Saya sedang bekerja di sana saat itu. Pertemuan lain yang saya habiskan di tahun 2018. Dia sendirian.

Nikolai Tatarinov: Mainkan Kerangka Kerja, kursus pertama dan cabang mitaps St. Petersburg

Nikolai Tatarinov adalah pengembang di SoundCloud, mantan penyelenggara SPb Scala Meetup.

Catatan oleh penulis . Sekarang tentang cabang mitaps St. Petersburg . Meskipun mereka mulai belum lama ini, 9 peristiwa telah terjadi. Dalam hal kualitas kinerja, mereka telah meningkatkan standar: saluran YouTube mereka, siaran langsung.

Salah satu panitia adalah Nikolai Tatarinov . Meskipun sekarang dia sudah pensiun karena pindah, tetapi saya datang kepadanya dengan pertanyaan standar. Nikolay berbicara tentang entri ke dalam bahasa, gerakan, sedikit memengaruhi status Play Framework sebelum rilis 2.0 dan nasib Actor Messaging .

Kerangka main

Nikolai Tatarinov : Di pekerjaan pertama saya di 2012, kami menggunakan Play Framework pertama. Itu dibuat dalam rupa Rails. Itu menarik karena kami memiliki aplikasi yang memudahkan untuk melakukan perubahan. Tapi itu dalam keadaan prototipe - itu tidak berkembang menjadi semacam sistem produksi. Semuanya dicampur di sana - dan itu berkembang.

Kerangka Bermain pertama adalah Java dan Groovy. , - — - Python-. , Maven Sbt. — Play Framework Play Framework .

, Play Framework , . — , « ».

Play Framework, , Scala, , — . - Play — . , — , . , . Play Framework , . , .

C Play Framework . , - , Scala . .

2013 — « Secon », . , — , - . , Scala. - , Scala Coursera.

Coursera

« Scala ». , , . , — , , . , , Scala .

Guava 7- Java. : . . , , , .

Scala

: 2014 . , , - Scala. 2015 , Actor . , Dialog , .

— Dialog Actor?

: . , Actor, Dialog. , Actor. , , .

, Actor, . Scala — . , Scala, - , — .

- Scala , — , . - , . , , .

, , . , , Java . — , . , - , . Scala.

, , Scala. SoundCloud. Scala.

: . IT Global Meetup — IT-, 2-3 . . — FProg Spb . : , , , , Coq.

. , Clojure, , — , Coq, , . .

, Scala. IT Global Meetup . , «Java Scala». , . , . , eLama, - , , Scala.

, Scala-, 50. Scala, . 2016 . , , . Slick, , Vodka .

Scala- 2017. , , , . , . . eLama" — .



Meetup DINS. , . — . , Meetup . , , 60-70 — . - .

. . , - . , - Excelsior JET, . , , .


PartialFunction .

« » — eax.me , , Scala 2013 . , , .

ScalaConf 2019 — (15 ) . Scala 26 . , « Hskell», — , Scala. ScalaConf 2019. .