Eksekusi memang penting, tetapi berbagi dan persiapan juga bisa memberi dampak, jadi saya kurang sependapat.

Sepertinya Zuckerberg banyak beradaptasi terhadap perubahan.

Selain pekerjaan, memang ada berbagai hal yang tidak perlu, tetapi rasanya juga ada hal-hal yang perlu tercampur di dalamnya, jadi saya agak sulit untuk sepenuhnya setuju.

Ini bukanlah hal-hal yang bisa disebut bekerja.

Tulisan yang paling tidak bisa saya setujui dari yang baru-baru ini saya baca

Memang begitu.
Sepertinya kode asinkron yang benar-benar baik pada dasarnya adalah jenis kode yang memang menuntut banyak perhatian.

Sebenarnya, kalau proyeknya sudah sampai perlu mengoptimalkan asynchronous Python, menulisnya dengan bahasa lain jauh lebih baik dari sisi performa maupun stabilitas.

Sepertinya ini hasil gabungan antara judul yang sengaja memancing perhatian dan pembaca yang tidak membacanya dengan saksama.

Kalau nomor 1 selalu independen, memang bagus dilakukan seperti itu,
tapi kalau setelah kode diubah jadi tidak independen, rasanya merepotkan juga karena harus meninjau dan memperbaiki semua tempat yang memakai fungsi itu.
Kalau pekerjaannya tidak memakan waktu terlalu lama, mungkin melakukan await secara serial lebih baik dari sisi pengelolaan kode

Saya belum mengecek video sumbernya, tetapi kode solusi untuk kesalahan 4 itu salah.

Instance task yang dikembalikan oleh create_task() harus ditugaskan ke setidaknya satu variabel, dan variabel tersebut harus tetap hidup sampai task selesai. Jika tidak, ada risiko instance task terkena garbage collection saat coroutine masih berjalan.

Jika fungsi yang membuat task seperti di atas segera berakhir, sebaiknya gunakan cara seperti mengembalikan instance task, menugaskannya ke variabel global, atau menugaskannya ke variabel instance.

P.S.)
Meskipun nilai kembalian memang tidak diperlukan dan Anda yakin coroutine akan selesai dalam waktu singkat, untuk instance task tetap lebih baik ditulis agar pada suatu saat dilakukan await. Kalau tidak suka begitu, setidaknya pasang penanganan exception yang ketat pada setiap coroutine yang akan dijalankan sebagai task, lalu siapkan struktur logging yang menampilkan pesan log tanpa celah. Kalau tidak, bisa terjadi Exception tidak tertangani dan gagal secara diam-diam meskipun task menimbulkan masalah besar.

Di proyek yang saya kembangkan/kelola untuk mencari nafkah, saya pernah merancang pola di mana puluhan modul masing-masing membuat satu task seperti while self.ok(): cmd = await self.cmd_queue.get(); await self.process(cmd); lalu terus menjalankannya. Sebelum pola penanganan exception-nya mapan, setiap kali satu masalah meledak, mental saya juga ikut meledak—pengalaman langka, haha.

Bahkan dari sudut pandang saya yang bekerja di perusahaan yang memakai C#, yang bisa dibilang pelopor pola Async/Await, saya juga cukup sering melihat kode yang salah seperti kesalahan nomor 1, yaitu menyusun await secara sederhana berurutan satu per satu.

Saat melihat kode seperti itu, entah bagaimana, saya merasa ada pola yang sama: mereka hanya tahu bahwa di depan pemanggilan method async harus memakai kata kunci await, tetapi tidak terlalu memikirkan lebih jauh soal urutan eksekusi asinkron, sehingga kode seperti ini pun muncul.
Ketika ada beberapa await, untuk sebagian hasilnya dipakai tepat di bawahnya sehingga di situ langsung menerima nilai hasil await dari objek Task<T>, sedangkan untuk sebagian lain hasilnya baru dipakai cukup jauh di bawah sehingga cukup menerima Task<T> dulu lalu baru di-await nanti; menulis kode dengan mempertimbangkan alur asinkron seperti ini memang pekerjaan yang menuntut pemikiran lebih.

Setidaknya saya sendiri menulis kode di method yang dideklarasikan asinkron dengan mempertimbangkan alur pemrosesan seperti itu. Namun, kadang saat melihat kode peninggalan mantan karyawan yang sedang saya maintenance, ada kalanya saya mendapat kesan, ‘Saya sebenarnya cuma ingin menulis kode sinkron secara sederhana, tapi karena method yang harus dipakai di tengah hanya tersedia dalam tipe asinkron, ya sudah saya tulis begini saja.’

Hidup Rust!

Setelah sedikit mencoba pengembangan firmware dengan Embassy
Stabilitas bahasanya memang bagus, tetapi.... karena tooling-nya sangat baik, produktivitasnya jauh lebih unggul dibanding saat menggunakan C/C++.

Skynet! Skynet!!!

Air berkarbonasi itu bukannya landasan peluncur highball ya? ahem

Bukan cuma tulisan seperti ini, bahkan di YouTube pun banyak orang yang berkomentar hanya setelah melihat judulnya saja.

Berita yang tak terduga.

Efisiensi diukur dengan angka, tetapi fleksibilitas tidak — kalimat ini terasa sangat berkesan.

Semacam Deep wiki ya

Saya setuju.

Bagian yang paling saya pikirkan adalah bagaimana memasukkan penjelasan tambahan agar pembaca bisa memahami.
Ketika pengambil keputusan adalah orang yang awam di bidang tersebut, atau...