2 คะแนน โดย GN⁺ 2023-12-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เหตุใด Jepsen จึงเขียนด้วย Clojure?

  • Jepsen ถูกสร้างขึ้นมาเพื่อทดสอบระบบที่มีภาวะการทำงานพร้อมกัน โดยหลัก ๆ คือฐานข้อมูล
  • โครงสร้างข้อมูลแบบ immutable ของ Clojure และการรองรับ concurrency ที่ยอดเยี่ยม ช่วยให้เขียนโปรแกรมที่ทำงานพร้อมกันได้อย่างถูกต้องง่ายขึ้น
  • จำเป็นต้องรองรับไคลเอนต์ฐานข้อมูลที่หลากหลาย และ Clojure ก็ทำงานร่วมกับ Java ได้ดีมาก

การเลือกภาษาเพื่อการทดสอบ

  • ต้องการภาษาที่กระชับและยืดหยุ่น เหมาะกับงานทดสอบเชิงทดลอง
  • Clojure มีความกระชับ และให้ความยืดหยุ่นทางไวยากรณ์ผ่านระบบมาโคร
  • สำหรับการทดสอบที่ต้องจัดการกับโครงสร้างข้อมูลซับซ้อน โครงสร้างข้อมูลและฟังก์ชันใน standard library ของ Clojure เหมาะอย่างยิ่ง

ประสิทธิภาพและความเสถียร

  • ต้องการภาษาที่มีประสิทธิภาพในระดับ "ดีพอ" โดย Clojure อาจช้ากว่า Java อยู่บ้างเมื่อเทียบกันโดยตรง แต่ช่องว่างด้านประสิทธิภาพสามารถแก้ไขได้
  • เครื่องมือ profiling ที่ยอดเยี่ยมของ JVM ทำงานเข้ากับ Clojure ได้ดี
  • Clojure มีความเสถียรสูงทั้งในฐานะแพลตฟอร์มบน JVM และในตัวภาษาเอง และมีปัญหาไลบรารีเสื่อมสภาพอย่างรวดเร็วน้อย

ข้อเสียและการตัดสินใจ

  • Clojure มีข้อเสียคือชุมชนวิศวกรรมขนาดเล็ก และไม่มีระบบ static type ที่ได้รับการยอมรับอย่างกว้างขวาง
  • อย่างไรก็ตาม Jepsen ถูกดูแลและใช้งานโดยทีมขนาดเล็ก จึงไม่ได้ทำให้ข้อเสียเหล่านี้เป็นปัญหาใหญ่นัก
  • หลังจากทำต้นแบบ Jepsen ด้วย Clojure แล้ว ก็สรุปได้ว่านี่เป็นการประนีประนอมที่ค่อนข้างดี

ความเห็นของ GN⁺

  • เหตุผลสำคัญที่สุดที่ Jepsen เขียนด้วย Clojure คือโครงสร้างข้อมูลแบบ immutable และการรองรับ concurrency ที่ทรงพลังของ Clojure ทำให้เหมาะกับการทดสอบระบบฐานข้อมูลที่มีความซับซ้อนด้าน concurrency
  • บทความนี้น่าจะน่าสนใจสำหรับผู้ที่สนใจวิศวกรรมซอฟต์แวร์ โดยเฉพาะการเขียนโปรแกรมแบบ concurrency และระบบฐานข้อมูล และยังเป็นกรณีศึกษาที่จับต้องได้ว่าการเลือกภาษาโปรแกรมหนึ่ง ๆ สามารถส่งผลต่อโปรเจกต์จริงอย่างไร

1 ความคิดเห็น

 
GN⁺ 2023-12-07
ความคิดเห็นจาก Hacker News
  • ผู้ใช้คนหนึ่งที่ใช้ Clojure และ ClojureScript มา 10 ปี เน้นย้ำข้อดีของ Clojure ได้แก่ การเขียนโค้ดโดเมนในไฟล์ .cljc แล้วคอมไพล์ได้ทั้งฝั่งเซิร์ฟเวอร์และไคลเอนต์, ประสิทธิภาพและการนำกลับมาใช้ซ้ำของ transducers, รวมถึงความเสถียรและความเข้ากันได้ย้อนหลังที่ยาวนานของ Clojure
  • สำหรับปัญหาของ ecosystem ของ Clojure มีความเห็นว่าเครื่องมือมีความต่างกันสุดขั้วทั้งด้านการเข้าถึงและการใช้งาน และถ้ามีเครื่องมือหรือเฟรมเวิร์กที่ใช้ง่ายกว่านี้ Clojure ก็น่าจะถูกนำไปใช้แพร่หลายมากขึ้น
  • นักพัฒนาคนหนึ่งที่ใช้ Clojure มา 7 ปีบอกว่าความไม่พอใจหลักคือการขาดระบบ type ที่แข็งแกร่ง และมองว่า Clojure มอบพลังให้มากขึ้นแก่ผู้พัฒนาที่ชอบ Ruby หรือ Python
  • ทีมหนึ่งที่พัฒนาด้วย Clojure และ ClojureScript กล่าวถึงข้อดีด้านการเข้าถึงของ Clojure และ workflow แบบ REPL พร้อมบอกว่าการใช้ Babashka/nbb กับโปรเจ็กต์หรืองานขนาดเล็กนั้นมีประโยชน์
  • ผู้เริ่มต้น Clojure รู้สึกว่าสถานะข้อผิดพลาดของเครื่องมือเข้าใจยาก แต่ก็เห็นคุณค่าของแนวคิดนวัตกรรมต่าง ๆ ใน ecosystem ของ Clojure พร้อมกล่าวถึงความจำเป็นที่ต้องปรับปรุงเรื่องการใช้วงเล็บและการจัดการ nil
  • มีการชี้ว่าความต้องการแบบเกือบเป็นหลักคำสอนของชุมชน Clojure ในการผสมผสานไลบรารี อาจทำให้ความเร็วในการทำงานของทีมพัฒนาเว็บจริงช้าลง และกล่าวถึงความจำเป็นของเว็บเฟรมเวิร์กที่ใช้งานง่ายกว่า
  • มีความเห็นว่าชุมชนวิศวกรรมที่มีขนาดเล็กและการไม่มีระบบ static type เป็นข้อเสียของ Clojure ขณะที่การทำงานร่วมกับ Java เป็นจุดแข็ง
  • ผู้ใช้ Clojure คนหนึ่งชี้ถึงปัญหาข้อความ error ของ Clojure และการขาด type hint พร้อมบ่นถึงความยากในการรีแฟกเตอร์โค้ดขนาดใหญ่
  • มีคอมเมนต์ที่แนะนำเว็บไซต์บทเรียนแบบ interactive สำหรับผู้เริ่มต้น Clojure
  • ผู้ใช้คนหนึ่งบอกว่าชอบ Clojure แต่ก็ได้เรียนรู้ว่าในท้ายที่สุดแล้ว ecosystem มีความสำคัญสำหรับแอปพลิเคชันสมัยใหม่ที่ซับซ้อน