🛌🏼 🚪 👌🏼 Zen Erlang [dan Elixir - sekitar. penerjemah] 💅 👩🏽‍⚕️ 🙏🏼

Pengantar dari penerjemah

Artikel ini adalah tentang Erlang , tetapi semua yang dikatakan sama berlaku untuk Elixir , bahasa fungsional yang berjalan di atas mesin virtual BEAM yang sama. Itu muncul pada 2012 dan sekarang aktif berkembang. Elixir membuat sintaksis lebih akrab bagi kebanyakan orang, ditambah kemampuan metaprogramming yang luas, sambil mempertahankan manfaat Erlang.

Lebih banyak dari penerjemah

Sebuah artikel dari 2016, tetapi tentang konsep dasar yang tidak kedaluwarsa.

Referensi konsep dan komentar dari saya (penerjemah) terletak di dalam tanda kurung siku [] dan ditandai dengan “catatan penerjemah”.

Jika Anda menemukan beberapa bagian terjemahan tidak cukup benar, terutama dalam hal istilah, atau jika Anda menemukan kesalahan lain, beri tahu saya, tolong, saya akan memperbaikinya dengan senang hati.

Terima kasih khusus kepada Jan Gravshin untuk bantuannya dalam mengoreksi dan mengedit teks.

Ini adalah transkrip gratis (atau parafrase panjang?) Dari presentasi saya di konferensi ConnectDev'16 yang diselenggarakan oleh Genetec.

001

Saya percaya sebagian besar orang di sini belum pernah memprogram di Erlang. Anda mungkin pernah mendengarnya, atau Anda tahu namanya. Oleh karena itu, presentasi saya hanya akan memengaruhi konsep-konsep tingkat tinggi Erlang, dan sedemikian rupa sehingga berguna dalam pekerjaan atau proyek sampingan Anda, bahkan jika Anda tidak pernah menemukan bahasa ini.

002

Jika Anda pernah tertarik pada Erlang, maka Anda mendengar tentang moto "Let it crash" [ "Let it fall" - approx. penerjemah ]. Pertemuan pertamaku dengannya membuatnya bertanya-tanya ada apa ini. Erlang seharusnya bagus untuk eksekusi multi-threaded dan toleransi kesalahan, tetapi di sini mereka menyarankan agar saya membiarkan semuanya jatuh: kebalikan dari perilaku sistem yang saya inginkan. Proposal itu mengejutkan, tetapi, bagaimanapun, Zen Erlang secara langsung terkait dengannya.

003

Dalam arti tertentu, menggunakan "Let it Crash" untuk Erlang sama menyenangkannya dengan "Meledakkannya" [ " Meledakkannya !" - kira-kira. translator ] untuk ilmu roket. "Meledakkan" mungkin adalah hal terakhir yang Anda inginkan dalam ilmu roket, dan bencana Challenger adalah pengingat yang jelas akan hal ini. Di sisi lain, jika Anda melihat situasinya secara berbeda, maka roket dan seluruh sistem propulsi mereka berhadapan dengan bahan bakar berbahaya yang dapat dan akan meledak (dan ini adalah saat yang berisiko), tetapi dengan cara yang terkendali sehingga dapat digunakan untuk mengatur ruang. bepergian atau mengirim muatan ke orbit.

Dan intinya di sini adalah benar-benar memegang kendali; Anda dapat mencoba melihat ilmu roket sebagai cara untuk menjinakkan ledakan dengan benar - atau setidaknya kekuatannya - untuk melakukan apa yang Anda inginkan dengannya. Pada gilirannya, Anda dapat melihat "Biarkan crash" dari sudut yang sama: ini tentang toleransi kesalahan. Idenya bukanlah kegagalan yang tidak terkendali yang meluas, melainkan mengubah kegagalan, pengecualian, dan menabrak alat yang dapat digunakan.

004

Musim gugur mendatang [Musim gugur mendatang - sekitar. translator ] dan annealing yang dikendalikan adalah contoh nyata dari memadamkan api dengan api. Di Saguenay-lac-Saint-Jean, daerah tempat saya berasal, ladang blueberry secara teratur dibakar dengan cara yang terkontrol untuk membantu merangsang dan melanjutkan pertumbuhan mereka. Cukup sering, Anda dapat melihat area hutan yang tidak sehat ditebangi oleh api untuk mencegah kebakaran hutan, sehingga hal ini terjadi di bawah pengawasan dan kontrol yang tepat. Tujuan utamanya adalah menghilangkan bahan yang mudah terbakar sehingga api alami tidak bisa menyebar lebih jauh.

Dalam semua situasi ini, kekuatan destruktif api yang menyapu tanaman atau hutan digunakan untuk menyembuhkan tanaman atau mencegah kerusakan hutan yang jauh lebih besar dan tidak terkendali.

Saya pikir arti dari "Let it crash" adalah persis seperti itu. Jika kita dapat memanfaatkan kegagalan, tabrakan, dan pengecualian, dan menjadikannya cara yang dapat dikelola, maka itu akan berhenti menjadi peristiwa menakutkan yang perlu dihindari, dan sebagai gantinya akan berubah menjadi elemen bangunan yang kuat untuk merakit sistem yang andal besar.

005

Dengan demikian, pertanyaannya menjadi bagaimana memastikan bahwa kegagalan lebih konstruktif daripada merusak. Chip utama untuk ini di Erlang adalah prosesnya. Proses Erlang sepenuhnya terisolasi dan memiliki arsitektur yang tidak dapat dipisahkan (tidak berbagi apa pun). Tidak ada proses yang dapat merangkak ke memori orang lain atau memengaruhi pekerjaan yang dilakukannya dengan mendistorsi data yang digunakan. Ini bagus karena itu berarti bahwa proses sekarat dengan jaminan 100% akan menjaga masalahnya sendiri dan menyediakan sistem Anda dengan isolasi kesalahan yang sangat kuat.

Proses di Erlang juga sangat ringan, sehingga ribuan dan ribuan dari mereka dapat bekerja secara bersamaan tanpa masalah. Idenya adalah untuk menggunakan sebanyak mungkin proses yang Anda butuhkan , daripada sebanyak yang Anda mampu . Bayangkan bahwa ada bahasa pemrograman berorientasi objek di mana pada waktu tertentu diizinkan untuk memiliki maksimum 32 objek yang bekerja secara bersamaan. Anda akan dengan cepat sampai pada kesimpulan bahwa untuk membuat program di atasnya, batasannya terlalu ketat dan agak konyol. Kehadiran banyak proses kecil memberikan variabilitas kerusakan yang lebih tinggi. Di dunia di mana kita ingin menempatkan kekuatan kegagalan pada layanan, itu bagus!

Mekanisme proses di Erlang mungkin tampak sedikit aneh. Ketika Anda menulis sebuah program dalam C, Anda memiliki satu fungsi main() yang melakukan banyak hal. Ini adalah titik masuk ke program. Tidak ada hal seperti itu di Erlang. Tak satu pun dari proses adalah yang utama. Setiap proses meluncurkan fungsi, dan fungsi ini memainkan peran main() proses khusus ini.

Sekarang kita memiliki segerombolan lebah, tetapi pasti sangat sulit untuk mengirim mereka untuk memperkuat sarang jika mereka tidak dapat berkomunikasi dengan cara apa pun. Di mana lebah menari [ lebah menari - sekitar. translator ], Erlang memproses perpesanan.

006

Pesan adalah bentuk komunikasi paling intuitif dalam lingkungan yang kompetitif. Dia adalah salah satu orang tertua yang berurusan dengan, dari hari-hari ketika kami menulis surat dan mengirimnya dengan kurir dengan kuda, ke mekanisme yang lebih aneh seperti semaphore Napoleon [ optical semaphore - approx. penerjemah ] ditunjukkan dalam ilustrasi. Dalam kasus terakhir, Anda cukup mengirim sekelompok pria ke menara, memberi mereka pesan, dan mereka mengibarkan bendera untuk mengirimkan data jarak jauh dengan cara yang lebih cepat daripada kuda yang lelah. Secara bertahap, metode ini digantikan oleh telegraf, yang, pada gilirannya, mengubah telepon dan radio, dan sekarang kami memiliki semua teknologi modern untuk mengirim pesan sangat jauh dan sangat cepat.

Aspek yang sangat penting dari semua perpesanan ini, terutama di masa lalu, adalah bahwa semuanya tidak sinkron dan pesannya disalin. Tidak ada yang berdiri di terasnya sepanjang hari menunggu kurir untuk kembali dan tidak ada (saya curiga) sedang duduk di dekat semafor, menunggu jawaban. Anda mengirim pesan dan kembali ke bisnis Anda, dan seiring waktu, seseorang memberi tahu Anda bahwa jawaban telah tiba.

Ini bagus - jika pihak lain tidak merespons, Anda tidak akan terjebak di teras sampai mati. Sebaliknya, penerima, tidak akan dihadapkan dengan fakta bahwa pesan yang baru tiba tiba-tiba menghilang atau berubah secara ajaib jika Anda tiba-tiba mati. Data harus disalin saat mengirim pesan. Kedua prinsip ini memastikan bahwa kegagalan selama komunikasi tidak mengarah ke keadaan yang terdistorsi atau tidak dapat diperbaiki . penerjemah ]. Erlang mengimplementasikan keduanya.

Setiap proses memiliki kotak suratnya sendiri untuk semua pesan yang masuk. Siapa pun dapat menulis ke kotak surat proses, tetapi hanya pemilik kotak yang memiliki kesempatan untuk melihatnya. Secara default, pesan diproses dalam urutan diterima, tetapi beberapa fitur seperti pencocokan pola [ pencocokan pola - kira-kira. translator ] memungkinkan Anda untuk mengubah prioritas dan fokus secara konstan atau sementara pada satu jenis pesan apa pun.

007

Beberapa dari Anda akan melihat keanehan dalam apa yang saya katakan. Saya terus mengulangi bahwa isolasi dan kemandirian sangat luar biasa sehingga komponen sistem dibiarkan mati dan jatuh tanpa memengaruhi sisanya. Tetapi saya juga menyebutkan komunikasi antara banyak proses atau agen.

Setiap kali pada awal dialog dari dua proses, ketergantungan implisit antara mereka muncul. Status implisit muncul dalam sistem yang menghubungkan keduanya. Jika proses A mengirim pesan ke proses B, dan B mati tanpa menjawab, A dapat menunggu jawaban selamanya, atau setelah beberapa waktu menolak untuk berkomunikasi. Yang kedua adalah strategi yang dapat diterima, tetapi sangat ambigu: sama sekali tidak jelas apakah sisi jauh telah mati atau sudah sibuk begitu lama, dan pesan tanpa konteks dapat masuk ke kotak surat Anda.

Sebagai imbalannya, Erlang memberi kita dua mekanisme untuk mengatasi masalah ini: monitor dan menghubungkan [ tautan - kira-kira. penerjemah ].

Monitor adalah tentang menjadi pengamat. Anda memutuskan untuk mengawasi prosesnya, dan jika itu mati karena suatu alasan, sebuah pesan akan memberi tahu Anda tentang apa yang terjadi di kotak masuk Anda. Anda dapat menanggapi ini dan membuat keputusan berdasarkan informasi yang ditemukan. Proses kedua tidak akan pernah tahu bahwa Anda melakukan semua ini. Karena itu, monitor cukup bagus jika Anda seorang pengamat. penerjemah ] atau urus status pasangannya.

Tautan [ tautan - kira-kira. translator ] - bidirectional, dan penciptaan satu menggabungkan nasib kedua proses terkait bersama-sama. Ketika suatu proses mati, semua proses yang terkait dengannya menerima perintah untuk menghentikan [ sinyal keluar - kira-kira. penerjemah ]. Tim ini, pada gilirannya, membunuh orang lain [ terkait - kira-kira. translator ] proses.

Semua ini menjadi sangat menarik, karena Anda dapat menggunakan monitor untuk mendeteksi kegagalan dengan cepat, dan Anda dapat menggunakan penjilidan sebagai desain arsitektur yang memungkinkan Anda menggabungkan beberapa proses sehingga kegagalan menyebar ke mereka secara keseluruhan. Kapan pun blok bangunan independen saya menjadi kecanduan satu sama lain, saya dapat mulai menambahkan ini ke program. Ini berguna karena mencegah sistem agar tidak sengaja jatuh ke keadaan tidak stabil, sebagian diubah. Koneksi menjamin pengembang: jika ada sesuatu yang pecah, maka itu rusak sepenuhnya, meninggalkan lembaran kosong, dan sama sekali tidak mempengaruhi komponen yang tidak mengambil bagian dalam latihan.

Untuk ilustrasi ini, saya memilih gambar pendaki yang diikat dengan tali pengaman. Jika pendaki hanya terhubung satu sama lain, mereka akan menemukan diri mereka dalam posisi yang menyedihkan. Setiap kali pendaki tunggal meluncur, anggota tim lainnya akan segera mati. Bukan cara yang baik untuk melakukan bisnis.

Sebagai gantinya, Erlang memungkinkan Anda untuk menentukan bahwa beberapa proses adalah khusus dan menandainya dengan parameter trap_exit . Kemudian mereka akan dapat menerima perintah keluar yang dikirim melalui komunikasi dan mengubahnya menjadi pesan. Ini akan memungkinkan mereka untuk memecahkan masalah dan mungkin mengunduh proses baru untuk menyelesaikan pekerjaan almarhum. Tidak seperti pendaki, proses khusus jenis ini tidak dapat mencegah proses kemitraan jatuh; ini sudah menjadi tanggung jawab mitra itu sendiri, diterapkan, misalnya, menggunakan try ... catch constructs. Proses, yang menangkap output, masih tidak memiliki kesempatan untuk bermain dalam memori orang lain dan menyimpannya, tetapi dapat menghindari kematian bersama.

Ini menjadi peluang penting untuk menciptakan pengawas. Kami akan segera menghubungi mereka.

008

Sebelum beralih ke supervisor, mari kita lihat beberapa bahan yang tersisa yang akan memungkinkan kita untuk berhasil mempersiapkan sistem yang menggunakan tetes demi keuntungan kita sendiri. Salah satunya terkait dengan cara kerja penjadwal proses. Kasus nyata yang ingin saya rujuk adalah pendaratan di bulan Apollo 11 [ Apollo 11 - kira-kira. penerjemah ].

Apollo 11 adalah misi yang pergi ke bulan pada tahun 1969. Dalam gambar kita melihat modul bulan dengan Buzz Aldrin dan Neil Armstrong di papan, dan foto itu diambil, saya percaya, oleh Michael Collins, yang tetap di modul perintah.

Dalam perjalanan ke bulan, modul dikendalikan oleh Apollo PGNCS (Bimbingan Utama, Navigasi dan Sistem Kontrol) [ Apollo PGNCS - kira-kira. penerjemah ]. Sistem kontrol melakukan beberapa tugas dengan jumlah siklus yang dihitung dengan cermat [ CPU - kira-kira. penerjemah ] masing-masing. NASA juga menemukan bahwa prosesor harus digunakan tidak lebih dari 85% dari kapasitasnya, dengan stok 15% gratis.

Karena para astronot ingin memiliki rencana cadangan yang andal jika mereka harus mengganggu misi, mereka meninggalkan radar pertemuan dengan modul perintah dan layanan - itu akan berguna. Ini dengan layak memuat sisa daya CPU. Segera setelah Buzz Aldrin mulai memasukkan perintah, pesan mulai muncul tentang kelebihan beban dan, bahkan, melebihi kekuatan komputasi yang tersedia. Jika sistem tersesat dari ini, maka mungkin tidak akan mampu melakukan tugasnya, dan semuanya akan berakhir dengan dua astronot mati.

Pertama-tama, kelebihan beban terjadi karena radar memiliki masalah perangkat keras yang diketahui, menyebabkan frekuensinya tidak sesuai dengan frekuensi komputer kontrol, yang menyebabkan "pencurian" siklus yang jauh lebih besar daripada yang seharusnya digunakan. Orang-orang di NASA bukan idiot, dan alih-alih menggunakan teknologi baru yang tidak diuji dalam kehidupan nyata untuk misi yang begitu penting, mereka menggunakan kembali komponen terbukti yang mereka ketahui tentang kesalahan langka. Tetapi, yang lebih penting, mereka datang dengan penjadwalan prioritas.

Ini berarti bahwa ketika radar ini, atau mungkin perintah yang dimasukkan, terlalu banyak memuat prosesor, tugas mereka terbunuh untuk memberikan siklus CPU pada hal-hal penting yang memiliki prioritas lebih tinggi dan benar-benar membutuhkannya. Itu pada tahun 1969. Saat ini ada banyak bahasa dan kerangka kerja yang hanya menawarkan pengiriman kooperatif dan tidak lebih.

Erlang bukan bahasa yang harus digunakan untuk sistem vital, ia hanya memperhitungkan kendala real- time lunak - kira-kira. penerjemah ], dan bukan pembatasan waktu-nyata yang ketat, dan karenanya menggunakannya untuk skenario seperti itu bukan ide yang baik. Tetapi Erlang menyediakan perencanaan proaktif [ dia adalah penjadwalan preemptive, kira-kira. penerjemah ] dan memprioritaskan proses. Ini berarti bahwa Anda, sebagai pengembang atau arsitek sistem, tidak harus berhati-hati, untuk mencegah pembekuan, benar-benar semua orang dengan cermat menghitung beban CPU yang diperlukan untuk komponen mereka (termasuk perpustakaan yang digunakan). Mereka tidak bisa mendapatkan kekuatan seperti itu. Dan jika Anda ingin beberapa tugas penting dilakukan kapan pun Anda membutuhkannya, Anda juga bisa menyediakannya.

Ini tidak terlihat seperti permintaan yang serius atau sering, dan orang-orang masih merilis proyek yang benar-benar sukses hanya berdasarkan penjadwalan kooperatif dari proses paralel, tetapi tentu saja sangat berharga, karena melindungi Anda dari kesalahan orang lain, serta dari Anda sendiri. Ini juga membuka pintu bagi mekanisme seperti keseimbangan beban otomatis, proses “menghukum buruk” atau “mendorong kebaikan”, atau menetapkan prioritas yang lebih tinggi untuk proses dengan lebih banyak tugas. Semua ini pada akhirnya membuat sistem Anda cukup mudah beradaptasi untuk memuat dan peristiwa yang tak terduga.

009

Komponen terakhir yang ingin saya diskusikan sebagai bagian dari memastikan ketahanan yang layak adalah kemampuan untuk bekerja di jaringan. Dalam sistem apa pun yang dikembangkan dengan tujuan aktivitas jangka panjang, kemampuan untuk berjalan di lebih dari satu komputer dengan cepat menjadi persyaratan wajib. Anda tidak ingin duduk di suatu tempat terkunci di balik pintu titanium dengan mobil emas Anda, tidak dapat mengimbangi kegagalan yang terutama memengaruhi pengguna Anda.

Jadi cepat atau lambat Anda akan membutuhkan dua komputer, sehingga satu selamat dari kegagalan yang kedua, dan mungkin yang ketiga, jika Anda ingin menggunakan bagian dari sistem Anda selama kerusakan.

Pesawat dalam ilustrasi - F-82 Twin Mustang [ F-82 Twin Mustang - kira-kira. penerjemah ], sebuah pesawat yang dirancang selama Perang Dunia II untuk mengawal para pembom jarak jauh yang sebagian besar pejuang lain tidak bisa menutupi. Dia memiliki dua kabin, sehingga pilot dapat mengontrol perangkat secara bergiliran; pada waktu yang tepat, adalah mungkin untuk membagi tanggung jawab sehingga satu pilot dapat menerbangkan pesawat, dan radar kontrol kedua dalam peran pencegat. Pesawat modern masih memiliki kemampuan serupa; mereka memiliki sistem duplikat yang tak terhitung jumlahnya, dan seringkali anggota kru tidur selama penerbangan, sehingga selalu ada seseorang yang siap, jika perlu, untuk segera mengambil alih kendali pesawat.

Adapun bahasa pemrograman atau lingkungan pengembangan, sebagian besar dari mereka dirancang tanpa kemungkinan pekerjaan terdistribusi, meskipun jelas bahwa ketika mengembangkan tumpukan server, Anda perlu bekerja dengan lebih dari satu server. Namun demikian, jika Anda akan bekerja dengan file, ada alat untuk ini di perpustakaan standar. Maksimum yang dapat diberikan oleh sebagian besar bahasa adalah dukungan soket atau klien HTTP.

Erlang menghargai realitas sistem terdistribusi dan menawarkan implementasi untuk kreasi mereka, yang didokumentasikan dan transparan. , , - [ pylyglot systems — . ].

010