Pertama -tama, ini adalah artikel yang diterjemahkan dari perpisahan TJ Node.js. Saya memang menderita beberapa dampak setelah membaca artikel ini, tetapi saya tidak setuju dengan beberapa pandangan penulis. Sebagai contoh, saya pikir register paket Node.js adalah salah satu dari banyak keuntungannya, tetapi Go sedikit kurang dalam hal ini. Karena tingkat pribadi, saya tidak mengerti banyak hal saat menerjemahkan. Saya juga pergi ke blog penulis dan StackOverflow untuk mengajukan beberapa pertanyaan untuk mendapatkan jawaban. Masih ada banyak hal yang tidak ada dalam terjemahan, dan saya berharap untuk mendapatkan sudut pandang.
Ps. Sebagai pemula Node.js, terima kasih kepada TJ atas upayanya dan pergi jauh -jauh.
teks:
Ucapkan selamat tinggal pada node.js
Meninggalkan Node.js Realm
Saya telah melawan Node.js dalam produksi cukup lama dan sayangnya karena saya tidak lagi menikmati pekerjaan ini, setidaknya pada saat ini, ini adalah perpisahan resmi saya. Lebih penting lagi, saya membutuhkan pemelihara.
Node benar -benar hebat dalam beberapa hal, tetapi ini bukan alat yang cocok untuk jenis perangkat lunak yang saya minati akhir -akhir ini. Saya masih berencana untuk menggunakan Node sebagai situs web, tetapi jika Anda tertarik untuk mempertahankan proyek apa pun, tinggalkan pesan untuk menuliskan nama pengguna GitHub Anda, nama pengguna NPM, dan nama proyek untuk memberi tahu saya. Biasanya yang saya minta hanyalah Anda tidak sepenuhnya mengubah API yang ada. Jika Anda benar -benar ingin melakukan ini, lebih baik memulai proyek baru.
KOA adalah proyek yang akan terus saya pertahankan. (Dengan CO dan teman)
Kisah Cawan Suci
Saya selalu mencintai C, tetapi semua orang yang bekerja dalam pengembangan C tahu itu berharga tetapi rentan terhadap kesalahan. Sulit untuk membuktikan pilihan bahasa dalam pekerjaan sehari -hari, karena itu bukan pekerjaan tercepat. Kesederhanaan juga merupakan alasan mengapa itu selalu dipuji, tetapi Anda tidak akan melangkah terlalu jauh tanpa banyak templat.
Karena semakin banyak orang yang berpartisipasi dalam pengembangan sistem terdistribusi, tren pengembangan kinerja node atas kegunaan dan ketahanan telah membuat saya lebih frustrasi. Selama seminggu terakhir, saya telah menulis ulang sistem terdistribusi yang relatif besar di GO, yang kuat, berkinerja lebih baik, dan mudah dipelihara, dan memiliki cakupan yang dapat diuji lebih baik karena keindahan umum dan lebih mudah untuk mengembangkan kode sinkron.
Saya tidak mengatakan Go adalah cawan suci, itu tidak sempurna, tetapi Go adalah jawaban yang sangat baik bagi saya untuk banyak bahasa yang ada hari ini. Karena semakin banyak bahasa "generasi berikutnya" ini seperti Rust dan Julia menemukan tempat mereka sendiri dan dewasa, saya yakin kita akan memiliki lebih banyak solusi yang hebat.
Secara pribadi, saya sangat senang pergi karena kecepatan iterasinya, saya sangat senang melihat bahwa mereka ingin mencapai versi 2.0, dan menurut berita yang saya dengar, mereka tidak takut melanggar hal -hal hebat asli. Jika itu benar, saya senang, lebih karena saya percaya bahwa jika itu benar -benar bermanfaat bagi bahasa ini, saya harus dengan cepat memecah apa yang sudah ada. Tapi saya juga bukan raksasa perangkat lunak yang menjalankan banyak sistem. :D
Diedit oleh: Saya harus salah menafsirkan beberapa milis pengiriman, dan mereka tidak ingin membuat beberapa perubahan destruktif kapan saja. @enneff
Mengapa pergi?
Jika Node bekerja untuk Anda dan Anda tidak perlu khawatir, itu masih merupakan alat yang hebat. Tetapi jika ada sesuatu yang mengganggu Anda, jangan lupa untuk melompat keluar dari kotak Anda dan melihat apa lagi yang ada di luar kotak - saya tertarik padanya dalam beberapa jam awalnya menggunakan Go untuk membangun produk.
Sekali lagi, saya tidak ada di sana untuk mengatakan Go jelas merupakan bahasa terbaik dan Anda harus melakukannya. Tetapi untuk usianya, sangat dewasa dan kuat. (Pada usia yang hampir sama dengan simpul). Rekonstruksi jenis itu menyenangkan dan sederhana, pekerjaan rumah dan alat debugging yang disediakan oleh Go sangat bagus, dan masyarakat memiliki peraturan yang sangat kuat tentang dokumentasi, format, tolok ukur, dan desain API.
Sementara begitu terbiasa dengan simpul yang sangat modular dan setelah mengalami perpustakaan standar Ruby yang membusuk, ketika saya pertama kali mendengar tentang Go, saya pikir perpustakaan standarnya mengerikan. Setelah saya menyelam ke dalam bahasa ini, saya menyadari bahwa sebagian besar perpustakaan standar diperlukan pada tahap ini, seperti kompresi, JSON, IO, buffered IO, operasi string, dll. Sebagian besar API ini didefinisikan dengan baik dan kuat. Sangat mudah untuk menulis seluruh program hanya dengan menggunakan perpustakaan standar ini.
Paket GO pihak ketiga
Sebagian besar perpustakaan GO terlihat serupa, sebagian besar kode pihak ketiga yang saya gunakan sejauh ini berkualitas tinggi, dan sulit untuk menemukannya di Node karena JavaScript menarik pengembang di berbagai tingkat keterampilan.
Tidak ada registri untuk paket GO, jadi Anda biasanya akan melihat 5 atau 6 paket yang sama secara bersamaan. Pada titik tertentu, ini dapat menyebabkan kebingungan, tetapi memiliki efek samping yang menarik, dan Anda harus memutuskan mana yang merupakan pilihan terbaik dengan meninjau setiap paket dengan cermat. Melalui Node, biasanya ada paket spesifikasi seperti "redis", "mongodb-pribumi" atau "nolomq", jadi Anda akan berhenti di situ dan menyimpulkan bahwa mereka yang terbaik.
Jika Anda melakukan beberapa pekerjaan terdistribusi, Anda akan menemukan tipe data yang mendasari GO yang mengesankan menjadi sangat membantu. Kita bisa mendapatkan sesuatu yang serupa dengan generator di Node, tetapi menurut pendapat saya generator baru setengahnya selesai. Tanpa penanganan kesalahan independen, pelaporan tumpukan masih biasa bahkan jika itu yang terbaik. Ketika solusi ini bekerja dengan baik, saya tidak ingin menunggu masyarakat untuk mengatur ulang selama tiga tahun.
Menurut pendapat saya, penanganan kesalahan Go sangat luar biasa. Node sangat bagus dalam hal apa yang harus Anda pikirkan tentang setiap kesalahan dan memutuskan bagaimana melakukannya. Namun, Node gagal dalam:
Anda mungkin mengulangi panggilan balik
Anda tidak boleh melakukan panggilan balik sama sekali dan tersesat dalam keadaan tidak stabil (misalnya, lupa untuk melewati kesalahan untuk menangani panggilan balik. Ketika kesalahan terjadi, Node akan menelan kesalahan tanpa umpan balik)
Anda mungkin mendapatkan kesalahan takeaway
Emitter mungkin mendapatkan beberapa acara yang salah
Lupa peristiwa yang salah untuk menghadapinya akan merusak segalanya
Sering tidak yakin apa yang diperlukan untuk menangani kesalahan
Penanganan kesalahan sangat berlebihan
Panggilan balik itu mengerikan
Dalam go, ketika kode saya berakhir, itu berakhir dan Anda tidak dapat mengeksekusi kembali dalam sebuah pernyataan. Ini tidak pasti dalam simpul. Anda akan berpikir bahwa suatu program dieksekusi sepenuhnya sampai perpustakaan secara tak terduga memanggil panggilan balik beberapa kali, atau tidak jelas penangan dengan benar dan kemudian menyebabkan kode dieksekusi lagi. Cukup sulit untuk menemukan alasan ini dalam kode produksi yang sebenarnya, mengapa repot -repot dengan ini? Bahasa lain tidak akan membiarkan Anda mengalami rasa sakit ini.
Simpul masa depan
Saya masih berharap Node melakukan pekerjaan dengan baik, banyak orang berinvestasi sangat besar dalam dirinya, dan memang memiliki potensi itu. Saya pikir Joyent dan tim perlu fokus pada kegunaan - jika aplikasi Anda rapuh dan sulit untuk debug, refactor dan kembangkan, kinerja tidak ada artinya.
Dalam 4-5 tahun kita masih akan memiliki kesalahan kesalahan yang samar-samar ini: getAddrinfo eaddrinfo ", dan fakta ini memberi tahu kita di mana prioritas pengembangan node berada. Dapat dimengerti, ketika Anda fokus membangun inti sistem, mudah untuk melewatkan hal -hal ini. Saya pikir pengguna telah menyatakan pendapat mereka tentang hal -hal seperti itu lagi dan lagi tetapi belum melihat hasil apa pun. Kami biasanya mendapatkan beberapa tanggapan untuk mengklaim bahwa apa yang kami miliki sudah sempurna. Dalam praktiknya, ini bukan masalahnya.
Aliran terganggu, panggilan balik tidak mudah digunakan, kesalahan tidak jelas, alat tidak mudah digunakan, ada peraturan masyarakat, tetapi tampaknya kurang dibandingkan dengan pergi. Meskipun demikian, saya dapat terus menggunakan node untuk beberapa tugas tertentu, seperti membuat halaman web, atau beberapa API atau prototipe yang terfragmentasi. Jika Node dapat memperbaiki beberapa masalah mendasarnya, maka ia memiliki kesempatan untuk tetap relevan, tetapi ketika ada solusi lain yang berkinerja lebih tinggi daripada ketersediaan ketika kinerja yang lebih tinggi dan argumen ketersediaan yang lebih tinggi tidak terlalu jauh.
Jika komunitas node memutuskan untuk merangkul generator dan mengimplementasikannya dalam node inti dan kesalahan lulus dengan tepat, ada kesempatan untuk membuat referensi ini. Ini akan sepenuhnya meningkatkan kegunaan dan ketahanan simpul.
Berita baiknya adalah saya berbicara dengan seorang pria hebat dan berbakat yang menyumbangkan kode inti di Strongloop belum lama ini. Mereka secara eksplisit mengadopsi cara yang tepat untuk memperbaiki masalah ini untuk membuat node di masa depan lebih mudah bekerja dengan mendengarkan tanggapan pengembang terhadap platform dan perencanaan untuk menemukan cara yang tepat untuk memperbaiki masalah ini. Saya tidak yakin bagaimana konflik antara banyak perusahaan pada pengembangan simultan bagian inti akan berakhir, tetapi saya berharap pengemudi pengembang akan menang.
Ini tidak berarti ini adalah serangan terhadap individu, banyak orang yang sangat berbakat bekerja dengan atau di Node, tetapi ini bukan lagi sesuatu yang saya minati. Saya bersenang -senang di komunitas Node dan bertemu dengan beberapa orang yang sangat menarik.
Arti ceritanya adalah bahwa Anda tidak boleh dibatasi oleh lingkaran Anda sendiri! Lihat apa di tempat lain dan Anda mungkin menikmati pemrograman lagi. Ada banyak solusi luar biasa di luar ini, dan kesalahan yang saya buat adalah saya menunggu terlalu lama untuk bermain dengan mereka!