Bagaimana akka dibandingkan dengan Erlang? [Tutup]


97

Saya telah melihat akka baru-baru ini dan itu cukup mengesankan. Sepertinya ia memiliki sebagian besar fitur mematikan erlang - transparansi lokasi, hierarki pengawasan, dan banyak lagi. Apakah ada fitur erlang yang tidak dimiliki akka?


Tonton film tentang erlang ini dalam praktiknya. Sayang sekali tidak ada tentang scala youtube.com/watch?v=G0eBDWigORY
mhstnsc

Jawaban:


123

Penafian: Saya PO untuk Akka

  • Erlang melakukan copy-on-send - Akka menggunakan memori bersama (objek tetap) untuk pengiriman dalam VM
  • Erlang melakukan GC per proses - Akka menggunakan GC JVM
  • Erlang memiliki OTP - Akka terintegrasi dengan seluruh ekosistem Java (Apache Camel, JAX-RS, dll)
  • Erlang melakukan proses penjadwalan untuk Anda - Akka memungkinkan Anda untuk menggunakan banyak Dispatcher berbeda dengan peluang konfigurasi tanpa akhir
  • Erlang melakukan pemuatan ulang kode panas - Akka dapat mendukungnya, tetapi kurang fleksibel karena pemuatan kelas JVM

Itu yang ada di atas kepalaku.

Di sisi lain, menggunakan Akka berarti Anda dapat menggunakan Scala, Java, Groovy, atau JRuby untuk menulis aplikasi Anda.


39
Objek Erlang juga tidak dapat diubah dan model konkurensi tidak memerlukan copy-on-send dalam node yang sama. BEAM untuk benda besar mengirimkan referensi. Sumber: jawaban SO ini oleh @rvirdig .
FooF

26
Erlang melakukan copy-on-send untuk membuat GC lebih efisien - dapat bekerja dalam setiap proses. Inilah sebabnya mengapa tidak ada jeda GC yang besar di aplikasi Erlang dibandingkan dengan aplikasi JVM / Akka.
andreypopp

4
Nah, Andrey, hal semacam itu tergantung pada JVM / GC mana yang Anda gunakan. azulsystems.com/products/zing/whatisit
Viktor Klang

4
Erlang memiliki angka pengurangan untuk setiap proses, meskipun Anda berada dalam loop komputasi berat yang sibuk, VM Erlang dapat menjeda proses dan membiarkan proses lapar lainnya mengambil lebih banyak siklus CPU. Itu adalah fitur yang sangat penting yang tidak disediakan JVM.
Daniel

6
@MaX Erlang seringkali 5x lebih lambat dari pada Java karena kurangnya dukungan JIT. Tetapi Erlang tidak memiliki jeda GC, ini dirancang untuk konkurensi dan aplikasi telekomunikasi 7 * 24, Erlang lebih memperhatikan keadilan proses, menghindari kelaparan dan kebuntuan, tidak dirancang untuk throughput seperti JVM. Jadi, ini benar-benar jeruk dan apel.
Daniel

74

Dalam proses Erlang dijamin akan beralih kira-kira setiap 1000 pengurangan. Dalam kerangka kerja naif seperti agen Scala / Akka memiliki penjadwal hingga menyelesaikan pekerjaan dalam penerimaan. Sekakmat. Tamat. Hasta la vista :) Teman-teman, jangan buang waktumu untuk pseudo techs. Saya terkejut bahwa orang-orang di sini membandingkan Scala dengan Erlang.

Juga ada banyak lagi yang disebut "fitur pembunuh", tapi di sini saran saya, jangan berpikir dari segi fitur, pikirkan tentang idiom yang memungkinkan bahasa tertentu. Scala mencuri "fitur terbaik", Erlang mengaktifkan / mengimplementasikan Anda dengan idiom yang tepat untuk membangun sistem dengan andal, dengan bahasa tingkat tinggi yang didorong dari idiom yang benar tersebut. Ketika Anda belajar Erlang Anda membangun kembali pikiran Anda, cara berpikir Anda tentang sistem yang dapat diandalkan didistribusikan, Erlang mengajarkan Anda dan meningkatkan Anda. Scala hanyalah salah satu bahasa imperatif (oh, maaf, multiparadigmal, kata lucu) yang mencoba mencuri fitur bagus dari bahasa lain.


9
Erlang cara membuat semua IO secara implisit asynchronous sangat elegan. Async IO dapat dilakukan dengan menggunakan NIO API di Scala, yang menurut saya tidak tampak seperti check-mate, tetapi merupakan solusi yang kurang elegan.
HRJ

7
apa sih yang kamu bicarakan ?! bagaimana memproses 1000 tugas langsung lebih baik daripada penjadwalan roundrobin, atau bahkan mendekati penjadwalan kotak surat terkecil !!
FUD

8
@vjache - Saya setuju. Bertahun-tahun saya sebagai programmer java telah mengajari saya bahwa Anda pada titik tertentu harus menyelidiki lapisan di bawah Anda. Scala / Akka tampaknya hanyalah lapisan lain di atas banyak lapisan lainnya (Mis. Nio, netty, dll), yang semuanya perlu Anda pahami di beberapa titik. Meskipun saya baru saja mulai bekerja dengan Erlang, sepertinya saya akan memiliki lebih sedikit lapisan yang perlu saya pahami untuk menyelesaikan pekerjaan. Pemrograman terdistribusi di Erlang terasa jauh lebih ringan untuk Scala / Akka, mungkin dengan cara yang sama python adalah alternatif yang lebih ringan untuk java untuk aplikasi web.
Chris Snow

@ FUD: mungkin maksudnya 1000 instruksi Erlang? dia tidak mungkin bermaksud 1000 pesan ...
Erik Kaplun

2
@ErikAllik Maksudnya 1000 "pengurangan". Pikirkan pengurangan sebagai token untuk mengeksekusi sedikit kode (sebenarnya bukan, tetapi berfungsi untuk menjelaskan ...). Setelah 1000 pengurangan, penjadwal beralih ke proses yang berbeda. Info lebih lanjut di erlang.org/pipermail/erlang-questions/2001-April/003132.html
Aegis

40

Hampir tidak ada yang menyebutkan isolasi proses. Tanpa jaminan "utas Anda tidak dapat mengacaukan sampah saya", sistem terdistribusi jauh lebih sulit untuk dipikirkan. (Mereka sudah cukup sulit dengan proses Erlang.)

AFAIK (yang tidak jauh, mengingat pengalaman langsung saya yang terbatas dengan JVM), hanya Erlang yang benar-benar mendapatkan proses isolasi "benar" di JVM. Tuan Google dapat memberikan beberapa petunjuk tentang di mana menemukan penelitian oleh Fox dan Candea (?) Tentang sistem penelitian yang menggunakan teknik "mikro-reboot" ("komputasi berorientasi pemulihan"). Pengembang Erlang membaca penelitian itu dan mengatakan beberapa hal:

  1. Selamat datang di klub, kenapa lama sekali?
  2. JVM membuatnya sangat, sangat sulit untuk bergabung. :-)

Proses isolasi memang sangat bagus. Namun, bahkan Erlang tidak kebal terhadap NIF yang serba salah.
Viktor Klang

14

Bagi saya, pertukaran kode panas di seluruh klaster Erlang tanpa waktu henti (misalnya make:all([netload]:) adalah salah satu fitur pembunuh Erlang.

Tapi mari kita balikkan pertanyaan Anda: Akka memiliki apa yang tidak dimiliki Erlang? Tentu saja Anda dapat menambahkan lusinan ekstensi dan pustaka (scala, akka, spring, osgi, ...) ke Java untuk mencoba mendekati Erlang. Tapi di mana gunanya? Singkatnya, semua ekstensi ini jauh lebih kompleks daripada mempelajari bahasa Erlang sederhana yang sekarang telah terbukti selama lebih dari 2 dekade bahwa ia dapat melakukan pekerjaan yang menawarkan skalabilitas teratas tanpa waktu henti.


30
IMO, Scala adalah bahasa yang jauh lebih baik pada tingkat sintaks daripada Erlang. Ini memiliki objek, sifat, ruang nama yang tepat, keamanan jenis yang tepat, tidak ada sintaks rekaman yang jelek, dll. Komunitasnya lebih besar, saya dapat menggunakan semua alat Java yang tersedia dan rasanya lebih halus.
ryeguy

15
@ryeguy: "bahasa yang lebih baik pada tingkat sintaks" ... hmm, tentukan "lebih baik" untuk "sintaks". Ketika saya membandingkan sintaks bahasa adalah faktor yang paling tidak relevan (karena ini hanya masalah selera atau apa yang Anda gunakan).
Peer Stritzinger

4
@ryeguy Semantik berbeda, sintaks berbeda.
rvirding

3
pertukaran kode panas menjadi menyebalkan jika Anda perlu mempertahankan status antara versi kode yang berbeda, pada akhirnya lebih mudah untuk mematikan proses dan status migrasi saat startup
OlegYch

4
@ryeguy Sintaks dari bahasa pemrograman hampir tidak relevan; yang penting adalah semantiknya. Erlang adalah PL fungsional jadi tentu saja tidak memiliki objek. Ciri-ciri, keamanan jenis, dll karena Scala menjadi bahasa yang diketik dengan kuat, sedangkan Erlang diketik secara dinamis; itulah pilihan desain. Namun demikian, saya akan mengundang Anda untuk melihat Elixir jika Anda menginginkan manfaat Erlang dengan nuansa yang lebih modern;)
Aegis

5

Mungkin Erlang lebih baik untuk sistem terdistribusi yang lebih besar (mengikuti jawaban vjache) tetapi untuk server normal ketika Anda hanya ingin menggunakan kekuatan penuh dari beberapa CPU, maka Akka adalah pilihan yang baik— menyediakan abstraksi, kinerja, dan integrasi yang baik dengan ekosistem Java.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.