บน Windows ก็สามารถติดตั้งผ่าน scoop ได้เช่นกัน

ดีเลย..

ดูเหมือนว่า Zed จะทุ่มเทกับการผสาน AI ไม่น้อยเลยนะ

Agent Client Protocol (ACP)
Zed - AI code editor ที่เร็วที่สุด
โค้ดเอดิเตอร์สำหรับการทำงานร่วมกัน "Zed" ตอนนี้เปลี่ยนเป็นโอเพนซอร์สแล้ว

เห็นด้วยอย่างยิ่งทั้งหมดครับ แต่ผมคิดว่ามากกว่าคำว่า "ผู้เกลียด AI" ใช้คำว่า "ผู้ปฏิเสธ AI" จะดีกว่าไหมครับ เพราะความหมายแฝงและน้ำเสียงของคำว่า "ความเกลียดชัง" นั้นไม่ค่อยดี และความเกลียดชังก็มักก่อให้เกิดความเกลียดชังเสมอ

biome ก็ยังคงเร็วกว่าอยู่ดี แต่ถ้ามองแค่เรื่องความเร็ว oxlint ของ voidzero ก็เร็วกว่าอีก

แต่ในแง่การใช้งานและเอกสารประกอบ biome ใช้งานได้สะดวกกว่า ดังนั้นถ้า ESLint เดิมไม่สามารถทำให้เร็วขึ้นพร้อมกับเสถียรมากขึ้นได้จากการเปลี่ยนจากชุด ESLint + Prettier ไปเป็น ESLint + ESLint Stylistic การปรับแต่งแบบมัลติเธรดครั้งนี้ก็น่าทึ่งก็จริง แต่อดคิดไม่ได้ว่าสักวันหนึ่งมันอาจถูกแทนที่

ว้าววววววว;;

น่าสนใจดีนะ

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

ดูเหมือนว่ายังไม่ได้นึกเลยว่า React ก็ทำลายประสิทธิภาพการทำงานเหมือนกัน

ถ้าโค้ดยาวมากแต่ยังอธิบายได้ง่ายว่า "มันทำอะไร" ก็ไม่ถือว่าเป็นหนี้

ที่บอกว่าการใช้ AI อย่างไม่ยั้งคิดสร้างหนี้ ก็เพราะมันทำให้การอธิบายสิ่งนั้นยากขึ้น

ไม่ใช่ว่ามีการแฮ็กการสื่อสาร แต่เป็นการแฮ็กเกตเวย์ครับ
เซิร์ฟเวอร์เกมจะขยายหรือลดจำนวนลงตามปริมาณโหลด
ดังนั้นตอนล็อกอิน เกตเวย์จะเป็นตัวบอกว่าควรเชื่อมต่อไปยังเซิร์ฟเวอร์ไหน
ทุกวันนี้สามารถขอใบรับรอง TLS ได้ฟรี ก็เลยสร้างระบบ https ให้ปลอดภัยได้ด้วยใช่ไหมครับ?

ก็น่าจะหมายถึงว่า เกตเวย์ที่ถูกแฮ็กชี้ไปยังเซิร์ฟเวอร์ที่ไม่ถูกต้อง และเซิร์ฟเวอร์นั้นก็ดักข้อมูลทั้งหมดไว้พร้อมดำเนินการโจมตีแบบ MITM

คำพูดในความเห็น Hacker News ด้านล่างนี่ตรงเผงเลย

"Next.js มีชั้น abstraction มหาศาลที่ไม่จำเป็นสำหรับ 99.9999% ของโปรเจกต์ และในกรณีส่วนน้อยที่จำเป็นต้องใช้ของแบบนี้จริง ๆ ผมคิดว่าทำโซลูชันแบบคัสตอมจากชิ้นส่วนระดับล่างจะดีกว่าเสียอีก"

API ที่ซับซ้อนเกินจำเป็นอย่างไร้สาระ, สภาพที่ทั้งไม่เสถียรและไม่สมบูรณ์แต่ก็ยังหน้าด้านโปรโมตว่า production ready, และการพึ่งพา vercel อย่างหนักจนถ้าไม่ใช้ vercel ก็แทบจะรันงานจริงจังได้ยาก

ฉันเริ่มต้นเส้นทางอาชีพจากสายเว็บ เลยไม่แน่ใจว่าเพราะแบบนั้นหรือเปล่า แต่การพัฒนาเว็บ (โดยเฉพาะฝั่งฟรอนต์) เดิมทีก็พัฒนากันด้วยอารมณ์ประมาณนี้แหละ
มีรสชาติแบบเปลี่ยนแปลงรวดเร็วตลอดเวลา...

ฝั่ง JS ก็ให้ความรู้สึกประมาณนั้นน่ะครับ มีอะไรหลายอย่างที่เขาว่ากันว่าดี แต่พอแยกดูแล้วแต่ละอย่างก็มีปัญหานิด ๆ หน่อย ๆ กันหมด และกระแสก็เปลี่ยนเร็วตามเทรนด์ไปเรื่อย ๆ...
อาจเป็นเพราะผมเคยใช้ Java, EJB, Struts เป็นหลักด้วยก็ได้เลยรู้สึกแบบนั้น

ขอบคุณครับ

https://github.com/kelseyhightower/nocode

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

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

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

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

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