ขอบคุณครับ

https://github.com/kelseyhightower/nocode

ในแง่ผิวเผิน จำนวนบรรทัดของโค้ด (LOC) ก็สำคัญเช่นกัน ในมุมของประสิทธิภาพการทำงาน การอ่านและทำความเข้าใจหนึ่งหน้ากับการอ่านเพียง 3 บรรทัดแล้วเข้าใจนั้นย่อมต่างกัน

แน่นอนว่าผมเองก็ใช้ asyncio ในโปรดักชันจนช่ำชองเหมือนกัน แต่ผมก็ยังไม่พอใจกับประสบการณ์การใช้งานในตอนนี้มากพอที่จะประเมินได้ว่า "ใช้งานได้ดี" ครับ..

asyncio ในปัจจุบันถูกออกแบบมาโดยมี GIL เป็นเงื่อนไขตั้งต้น พูดอีกอย่างหนึ่งก็คือเป็นกลยุทธ์หลีกเลี่ยง GIL ดังนั้น GIL จึงไม่ได้โต้ตอบกับ asyncio โดยตรง

แต่ถ้ามองจากภาพรวมของการเขียนโปรแกรมแบบ concurrency ทั้งหมดที่ทำงานอยู่บนพื้นฐานของ asyncio ผมคิดว่าการพูดว่า GIL ไม่เกี่ยวข้อง ก็เหมือนกับการพูดทำนองว่า 'เพราะเป็น Python ก็เลยทำไม่ได้อยู่แล้ว'

ผมเห็นด้วยว่าเราไม่อาจคาดหวังได้ว่าทิศทางปัจจุบันของ GIL จะทำให้มันไม่ด้อยกว่าเมื่อเทียบกับ "ทางเลือกอื่น" ต่าง ๆ
แต่ผมคิดว่าการบอกว่าควรเลือกใช้ทางเลือกอื่นแทน Python ไม่ควรนำไปสู่น้ำเสียงว่าไม่มีปัญหาอยู่แล้ว แต่ควรนำไปสู่น้ำเสียงว่ายังมีปัญหาอยู่ไม่ใช่หรือครับ

ครั้งนี้ผมลองทำเว็บพัฒนาดูด้วยความสนใจส่วนตัวล้วน ๆ ในสายที่ไม่เกี่ยวกับงานพัฒนาที่เคยทำเลย เดิมทีผมทำบอร์ดประกาศด้วย next.js v15 app router แต่พอเห็นโพสต์แบบนี้ทีไร ก็รู้สึกเหมือนหมดไฟที่จะลองอะไรใหม่ ๆ ทางฝั่งเว็บทุกทีเลยนะครับ ทำไม ecosystem ถึงไม่เสถียรขนาดนี้กันนะ แบบนี้เดี๋ยวพอมีของใหม่ออกมา คนก็จะแห่กันไปใช้พักหนึ่ง แล้วก็บ่นก่อนจะไปหาตัวอื่นอีกหรือเปล่า วงการเว็บพัฒนานี่คงยากจริง ๆ นะครับ

อำนาจและเงินก็เป็นแรงขับเคลื่อนให้โปรเจ็กต์ยังคงอยู่จริง ๆ
ทุกครั้งที่เห็นหน้าเว็บที่ถ้าไม่ใช่ Chromium ก็ทำงานได้ไม่ปกติ ก็อดถอนหายใจไม่ได้เลย

พูดตามตรง.... ก็น่าจะไม่มีบริษัทไหนนอกจาก Google ที่ยังพอรักษา Chrome ไว้ได้ในระดับนี้อยู่แล้วมั้งครับ ยิ่งไปกว่านั้น ถึงจะไม่ถึงขั้นเหมือนอุตสาหกรรมเซมิคอนดักเตอร์ แต่อำนาจครอบงำตลาดเว็บเบราว์เซอร์ก็เป็นอีกเรื่องที่สหรัฐฯ คงไม่อยากปล่อยมือ.... จากนี้ไปก็น่าจะยังยอมให้มีการผูกขาดอยู่ในระดับหนึ่งครับ

เพิ่งมาตรวจสอบครับ
ขอบคุณสำหรับคำตอบที่ใส่ใจมากครับ!

ถึงจะรู้สึกไม่สะดวก แต่พอใช้ไปสักพักก็จะคุ้นเคยได้อย่างรวดเร็วไม่ใช่หรือ?
มนุษย์เป็นสัตว์ที่ปรับตัวเก่ง

แม้จะไม่ได้ระบุไว้อย่างชัดเจนในเนื้อหา แต่ก็อาจหมายถึงว่าเมื่อเขียนโค้ดด้วย AI มนุษย์จะไม่คุ้นเคยกับมันเท่าโค้ดที่เขียนเองโดยตรง จึงอาจกลายเป็นหนี้ทางเทคนิคได้หรือเปล่า?

อ้อ ผมก็เป็นผู้ใช้แบบเสียเงินเหมือนกันครับ ฮ่าๆ
พอลองไปดูประวัติใน App Store ก็พบว่าตั้งแต่เวอร์ชัน 1.51 เป็นต้นไปกลายเป็นฟรีแล้ว
สำหรับผม มันเป็นเครื่องมือที่ขาดไม่ได้เลย เพราะการตั้งค่าจอภาพของ MacBook จะแตกต่างกันไปตามสถานที่ที่ใช้งาน

ก็ไม่ได้เขียนวิทยานิพนธ์สักหน่อย...

รู้สึกว่า GIL โผล่มาแบบค่อนข้างไม่เข้าประเด็นนะ.. ต่อให้เอา GIL ออกไปได้
ถ้าอยากใช้มัลติเธรดทั้งกับงานแบบ I/O bound และ CPU bound
ก็คงจะดีกว่าถ้าเลือกทางเลือกอื่นที่ไม่ใช่ Python..

เหมือนว่า asyncio จะเป็นอะไรที่คนซึ่งลงลึกกับ Python หลายคนไม่ค่อยชอบกันพอสมควรเหมือนกันนะ
เหมือนเคยได้ยินความเห็นอยู่บ่อยๆ ว่า gevent น่าจะได้กลายเป็นกระแสหลักมากกว่า

ขอบคุณสำหรับการแนะนำแอปดี ๆ ครับ

เขียนเพิ่มเติมแล้ว

ใช้ asyncio กันเยอะนะครับ.. ใช้งานได้ดีทีเดียว.. มีข้อจำกัดตรงที่การยกเลิกงานเป็นแบบ edge-triggered (ไม่ใช่ level-triggered) แต่จริง ๆ แล้วงานเขียนโค้ดที่ต้องรับรู้การยกเลิกงานและจัดการแบบ graceful ก็ไม่ได้เกิดขึ้นบ่อยนัก และปัญหาที่ใหญ่กว่านั้นคือ event loop ถือ weak reference ไปยัง task จึงอาจหายไปได้เพราะ gc.. แต่เรื่องนั้นแก้ได้ด้วย structured concurrency.

สำหรับงาน i/o สำคัญ ๆ โดยทั่วไปก็หาไลบรารีที่รองรับ asyncio ได้ไม่ยาก..

ส่วน GIL? ก็ไม่ได้เกี่ยวมากนัก.. แนวคิดที่จะใช้ asyncio เพื่อรันงานที่กิน CPU แบบขนานกันนั้นค่อนข้างแปลกอยู่แล้ว.. ถ้า GIL ได้รับการปรับปรุง ก็น่าจะเป็นประโยชน์กับการทำมัลติเธรดสำหรับงานที่กิน CPU มากกว่า.. async คือการหมุนช่วงคอขวดของ i/o ให้มีประสิทธิภาพสูงที่สุด...

สรุปก็คือ.. แม้จะมีปัญหาด้านการออกแบบอยู่บ้าง แต่ในการใช้งานเพื่อให้บรรลุเป้าหมายก็ไม่มีปัญหาอะไรเป็นพิเศษ และใช้งานใน production ได้ดีครับ.

ถึงจะเป็นการโจมตีแบบ MITM ก็เถอะ แต่เขาถอดรหัสการสื่อสาร https ได้ยังไง? หรือมีแค่ผมที่ไม่รู้?

เมื่อเทียบกับ Biome แล้ว ความเร็วจะเป็นอย่างไรบ้างนะ?