Pengarang ekspres TJ mengucapkan selamat tinggal kepada Node.js dan menuju ke Go_node.js

Pertama sekali, ini adalah artikel yang diterjemahkan dari Farewell Node.js Saya benar-benar terkejut selepas membaca artikel ini, tetapi saya tidak bersetuju dengan beberapa pandangan pengarang Sebagai contoh, saya fikir pakej Node register adalah salah satu daripada banyak kelebihannya, tetapi Go mempunyai sedikit kekurangan dalam aspek ini. Disebabkan oleh keterbatasan peribadi saya, terdapat banyak perkara yang saya tidak faham semasa menterjemah, saya juga pergi ke blog pengarang dan stackoverflow untuk bertanya beberapa soalan dan mendapat jawapan. Masih terdapat banyak ketidaksempurnaan dalam terjemahan, dan saya harap anda boleh mendapatkan beberapa petunjuk.

PS. Sebagai seorang pemula dalam Node.js, saya ingin mengucapkan terima kasih kepada TJ atas kerja kerasnya dan melalui perjalanan yang baik.

Teks:

Perpisahan Node.js

Tinggalkan alam Node.js

Saya telah berlawan dengan Node.js dalam pengeluaran cukup lama, dan malangnya sekarang saya tidak lagi seronok melakukan kerja itu, sekurang-kurangnya buat masa ini, ini adalah perpisahan rasmi saya. Lebih penting lagi, saya memerlukan penyelenggara.

Node hebat dalam beberapa cara, tetapi ia bukan alat yang sesuai untuk jenis perisian yang saya minati pada masa kini. Saya masih merancang untuk menggunakan Node untuk tapak web, tetapi jika anda berminat untuk mengekalkan sebarang projek, tinggalkan komen dengan nama pengguna Github anda, nama pengguna npm dan nama projek untuk memberitahu saya. Biasanya yang saya minta ialah anda tidak mengubah sepenuhnya API sedia ada Jika anda benar-benar mahu melakukan ini, lebih baik untuk memulakan projek baru.

Koa adalah projek yang saya akan terus kekalkan. (Dengan Co dan rakan-rakan)

Kisah Holy Grail

Saya sentiasa menyukai C, tetapi semua orang yang bekerja dalam pembangunan C tahu bahawa ia berharga tetapi mudah ralat. Sukar untuk mewajarkan pilihan bahasa dalam kerja seharian kerana ia bukan yang paling pantas untuk kerja itu. Kesederhanaan juga adalah sebab ia sentiasa dipuji, tetapi anda tidak akan pergi jauh tanpa banyak templat.

Apabila saya semakin terlibat dalam pembangunan sistem teragih, arah aliran prestasi Node yang lebih tinggi daripada ketersediaan dan keteguhan membuatkan saya semakin kecewa. Sepanjang minggu lalu, saya telah menulis semula sistem pengedaran yang agak besar dalam Go untuk menjadikannya lebih mantap, berprestasi dan lebih mudah diselenggara, dan kerana kod segerak pada umumnya lebih elegan dan lebih mudah untuk dibangunkan, ia mempunyai lebih banyak liputan boleh diuji yang Baik.

Saya tidak mengatakan Go adalah Holy Grail, ia tidak sempurna, tetapi untuk banyak bahasa yang wujud hari ini, Go ialah jawapan yang sangat baik untuk saya. Memandangkan lebih banyak bahasa "generasi akan datang" seperti Rust dan Julia menemui niche dan matang mereka, saya pasti kami akan mempunyai lebih banyak penyelesaian yang hebat.

Secara peribadi, saya sangat teruja dengan bahasa GO kerana kelajuan lelarannya. Saya sangat teruja melihat mereka tidak sabar-sabar untuk mencapai versi 2.0, dan menurut berita yang saya dengar, mereka tidak takut dan memecahkan perkara Hebat yang asal. Saya suka jika ia benar, kebanyakannya kerana saya percaya bahawa jika ia benar-benar baik untuk bahasa, ia harus memecahkan perkara yang sedia ada dengan cepat. Tetapi saya juga bukan gergasi perisian yang menjalankan banyak sistem. :D

Editor: Saya pasti telah salah tafsir beberapa penyerahan ke senarai mel mereka tidak bersemangat untuk membuat perubahan pada bila-bila masa. @enneff

Kenapa Pergi?

Jika Node berfungsi untuk anda dan anda tidak perlu risau, ia masih merupakan alat yang hebat. Tetapi jika sesuatu mengganggu anda, jangan lupa untuk keluar dari kotak anda dan lihat apa yang ada di luar kotak - dalam beberapa jam pertama membina produk dengan Go, saya sudah terpikat.

Sekali lagi, saya tidak mengatakan bahawa Go ialah bahasa terbaik mutlak dan anda perlu menggunakannya. Tetapi ia sangat matang dan kuat untuk usianya. (Kira-kira semasa saya sebaya dengan Node). Pemfaktoran semula jenis adalah menyeronokkan dan mudah, kerja dan alatan penyahpepijatan yang disediakan oleh Go adalah hebat, dan komuniti mempunyai peraturan yang sangat kuat tentang dokumentasi, format, penanda aras dan reka bentuk API.

Kerana terlalu terbiasa dengan modulariti melampau Node dan telah mengalami pustaka standard Ruby yang busuk, apabila saya mula-mula mendengar tentang Go, saya fikir perpustakaan standardnya adalah mengerikan. Selepas saya mendalami bahasa ini, saya menyedari bahawa kebanyakan perpustakaan standard pada peringkat ini sangat diperlukan, seperti mampatan, json, IO, buffered IO, operasi rentetan, dll. Kebanyakan API ini ditakrifkan dengan baik dan berkuasa. Adalah mudah untuk menulis keseluruhan program hanya dengan menggunakan perpustakaan standard ini.

Pakej Go pihak ketiga

Kebanyakan perpustakaan Go kelihatan serupa, dan kebanyakan kod pihak ketiga yang saya gunakan setakat ini adalah berkualiti tinggi, yang sukar ditemui dalam Node kerana JavaScript menarik pembangun tahap kemahiran yang berbeza dalam skop.

Untuk pakej Go, tiada pusat pendaftaran, jadi anda biasanya melihat 5 atau 6 pakej yang sama pada masa yang sama. Ini boleh menyebabkan kekeliruan pada masa-masa tertentu, tetapi ia mempunyai kesan sampingan yang menarik iaitu anda perlu menyemak dengan teliti setiap pakej untuk memutuskan yang mana satu penyelesaian terbaik. Oleh Node biasanya terdapat pakej kanonik seperti "redis", "mongodb-native" atau "zeromq", jadi anda akan berhenti di sana dan hanya menyimpulkan bahawa ia adalah yang terbaik.

Jika anda melakukan beberapa kerja yang diedarkan, anda akan mendapati jenis data asas serentak Go yang mengagumkan sangat membantu. Kita boleh mencapai sesuatu yang serupa dengan penjana dalam Node, tetapi pada pendapat saya, penjana hanya separuh daripada tugas. Tanpa pengendalian ralat bebas, susunan pelaporan masih biasa pada tahap terbaiknya. Apabila penyelesaian ini berfungsi dengan baik, saya tidak mahu menunggu selama tiga tahun untuk komuniti menyusun semula.

Pada pendapat saya, pengendalian ralat Go adalah luar biasa. Node hebat dalam erti kata bahawa anda perlu mempertimbangkan setiap ralat dan memutuskan perkara yang perlu dilakukan. Walau bagaimanapun, Node gagal pada:

Anda boleh melakukan panggilan balik berulang kali

Anda tidak boleh membuat panggilan balik sama sekali dan tersesat dalam keadaan tidak stabil (contohnya, jika anda terlupa untuk menghantar ralat mengendalikan panggilan balik, apabila ralat berlaku, Node akan menelan ralat tanpa sebarang maklum balas)

Anda mungkin mendapat ralat luar kotak

pemancar mungkin mendapat beberapa peristiwa yang salah

Melupakan pengendalian acara yang salah akan merosakkan segala-galanya

Selalunya tidak pasti apa yang perlu dilakukan dengan salah

Pengendalian ralat sangat berlebihan

Panggil balik menyebalkan
Dalam Go, apabila kod saya tamat, ia tamat dan anda tidak boleh melaksanakan semula dalam penyata. Dalam Node ini tidak ditentukan. Anda akan berfikir bahawa program dilaksanakan sepenuhnya sehingga perpustakaan secara tidak sengaja memanggil panggilan balik beberapa kali, atau gagal mengosongkan pengendali dengan betul dan menyebabkan kod itu dilaksanakan semula. Agak sukar untuk mencari sebab ini dalam kod pengeluaran sebenar, jadi mengapa perlu bersusah payah? Bahasa lain tidak meletakkan anda melalui kesakitan ini.

Nod masa hadapan

Saya masih berharap Node berfungsi dengan baik dan ramai orang melabur banyak di dalamnya, ia mempunyai potensi sedemikian. Saya rasa Joyent dan pasukan perlu menumpukan pada kebolehgunaan - prestasi tidak bermakna jika aplikasi anda rapuh dan sukar untuk nyahpepijat, pemfaktoran semula dan dibangunkan.

Hakikat bahawa kami masih akan mengalami ralat "Ralat: getaddrifo EADDRINFO" dalam masa 4-5 tahun memberitahu kami di mana keutamaan pembangunan Node. Maklumlah, perkara ini mudah terlepas apabila anda menumpukan pada membina teras sistem. Saya rasa pengguna telah menyuarakan pendapat mereka tentang perkara jenis ini berulang kali tanpa melihat sebarang hasil. Kami biasanya mendapat segelintir respons terhadap dakwaan bahawa apa yang kami ada sudah sempurna. Dalam amalan, ini tidak berlaku.

Strim terganggu, panggilan balik tidak mudah digunakan, ralat tidak jelas, dan alatan tidak mudah digunakan, tetapi peraturan tersebut kurang berbanding Go. Walaupun begitu, saya mungkin terus menggunakan Node untuk beberapa tugas tertentu, seperti membuat halaman web, atau beberapa API atau prototaip yang berselerak. Jika Node boleh menyelesaikan beberapa masalah asasnya, ia mempunyai peluang untuk kekal relevan, tetapi hujah untuk prestasi mengenai ketersediaan tidak pergi terlalu jauh apabila terdapat alternatif yang mempunyai prestasi yang lebih tinggi dan ketersediaan yang lebih tinggi.

Jika komuniti Node memutuskan untuk menerima penjana dan melaksanakannya dalam bahagian teras Node, dan menyebarkan ralat dengan betul, ada kemungkinan perkara ini boleh dirujuk. Ini akan meningkatkan ketersediaan dan keteguhan Node secara drastik.

Berita baiknya ialah sebentar tadi saya bercakap dengan lelaki hebat dan berbakat yang menyumbang kod teras kepada StrongLoop. Mereka mengambil pendekatan yang jelas dengan mendengar maklum balas pembangun kepada platform dan merancang untuk mencari cara yang betul untuk menyelesaikan isu ini untuk menjadikan Node lebih mudah untuk digunakan pada masa hadapan. Saya tidak pasti bagaimana konflik pembangunan serentak bahagian teras oleh berbilang syarikat akan berakhir, tetapi saya harap pihak yang didorong oleh pemaju akan menang.

Ini tidak dimaksudkan untuk menjadi serangan peribadi, terdapat ramai orang yang benar-benar berbakat bekerja dengan atau di atas Node, tetapi itu bukan tempat saya berminat lagi. Saya mempunyai masa yang hebat dalam komuniti Node dan bertemu dengan beberapa orang yang sangat menarik.

Moral cerita ini ialah, jangan dihadkan oleh kalangan anda sendiri! Lihat apa yang tersedia di tempat lain dan anda mungkin menikmati pengaturcaraan lagi. Terdapat begitu banyak penyelesaian hebat di luar sana, saya membuat kesilapan kerana menunggu terlalu lama untuk bermain dengan mereka!