1 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • SSH daemon ปิดใช้งานบริการ shell และ exec เป็นค่าเริ่มต้น ทำให้ผู้ใช้ที่ยืนยันตัวตนแล้วไม่สามารถรันโค้ด Erlang ตามอำเภอใจได้ เว้นแต่จะตั้งค่าไว้โดยชัดเจน
  • เมื่อเริ่มต้น SSH daemon ระบบจะไม่เปิดใช้งาน SFTP subsystem เป็นค่าเริ่มต้นอีกต่อไป จึงทำให้ค่าเริ่มต้นด้านความปลอดภัยเข้มงวดยิ่งขึ้น
  • มีการเพิ่มแอตทริบิวต์ -unsafe เพื่อใช้ระบุฟังก์ชันที่ไม่ปลอดภัย และคอมไพเลอร์จะสร้างคำเตือนโดยอัตโนมัติเมื่อมีการเรียกใช้ฟังก์ชันที่ Erlang/OTP ทราบอยู่แล้วว่าไม่ปลอดภัยเสมอ
  • xref สามารถค้นหาการเรียกใช้ฟังก์ชันที่ไม่ปลอดภัยและฟังก์ชันที่ไม่มีเอกสารได้ และการกรองแอตทริบิวต์ ignore_xref ก็ถูกเปลี่ยนให้จัดการภายใน xref เอง
  • ในการตั้งค่าเริ่มต้นของ SSL นั้น x25519mlkem768 กลายเป็นกลุ่มแลกเปลี่ยนกุญแจที่ถูกเลือกเป็นอันดับแรก และอัลกอริทึมแลกเปลี่ยนกุญแจเริ่มต้นของ SSH ก็เปลี่ยนเป็น mlkem768x25519-sha256 ซึ่งรวม ML-KEM-768 และ X25519 เข้าด้วยกัน
  • ตำแหน่งของไดเรกทอรีทำงานปัจจุบัน . ในเส้นทางโค้ดเริ่มต้นของระบบ Erlang ถูกย้ายจากลำดับแรกไปอยู่ลำดับสุดท้าย ทำให้ลำดับการโหลดเปลี่ยนไป
  • จะไม่มีการแจกจ่าย 32-bit Erlang/OTP build สำหรับ Windows อีกต่อไป
  • มีการนำ native records ตาม EEP-79 มาใช้งานแล้ว และใน Erlang/OTP 29 ยังถือเป็นฟีเจอร์ทดลอง
  • มีการเพิ่ม guard BIF is_integer/3, multi-value comprehension ตาม EEP 78 และการ bind ตัวแปรภายใน comprehension ผ่านความสามารถ compr_assign
  • คอมไพเลอร์เพิ่มคำเตือนเริ่มต้นสำหรับ catch, การส่งออกตัวแปรออกนอก subexpression, and/or และ match alias pattern เช่น {a,B} = {X,Y} พร้อมมีตัวเลือกสำหรับปิดใช้งานแต่ละรายการ
  • guard test แบบเก่ามีกำหนดจะถูกถอดออกจากภาษาใน Erlang/OTP 30 และคำเตือนเดิมเกี่ยวกับการใช้ obsolete guard จะยังคงมีผลต่อไป
  • สามารถใช้ io_ansi เพื่อส่ง ANSI/Virtual Terminal Sequence ไปยังเทอร์มินัลได้ และใช้ ct_doctest เพื่อทดสอบตัวอย่างในเอกสารของโมดูล Erlang และไฟล์เอกสาร

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

 
GN⁺ 5 시간 전
ความเห็นจาก Hacker News
  • การปรับปรุงต่าง ๆ ดูดีไม่น้อย การปิดใช้งาน SSH daemon เป็นค่าเริ่มต้น รวมถึงปิด SFTP เป็นค่าเริ่มต้นด้วย ถือเป็นการเปลี่ยนแปลงที่ดีในแง่ความปลอดภัย
    โมดูล io_ansi ก็ดูน่าสนใจมาก ตอนนี้ Erlang ยังไม่ได้มีเรื่องเล่ามากนักในฐานะตัวเลือกที่เหมาะสุดสำหรับการสร้างแอป command line ที่ซับซ้อน แต่ถ้าเข้าไปอยู่ใน standard library แล้วก็น่าจะช่วยได้มากในอนาคต วิธีที่ fwrite ทำงานข้ามโหนดได้อย่างเป็นธรรมชาติก็เป็นจุดเด่นแบบที่คาดหวังจาก Erlang พอดี
    การเพิ่ม Native Records ก็น่าสนใจเหมือนกัน ตอนนี้ใน Elixir จะรู้สึกว่ามีทั้ง record, tuple และ map ปะปนกันไปตามกรณี เลยสงสัยว่าจะถูกนำไปใช้อย่างไรต่อไป แม้ตามที่ EEP บอกไว้ record แบบเดิมคงไม่ถูกเลิกใช้ทั้งหมด แต่ก็ดูเป็นการพัฒนาที่สำคัญ
    https://www.erlang.org/doc/apps/ssh/ssh.html
    https://www.erlang.org/docs/29/apps/stdlib/io_ansi.html
    https://github.com/erlang/eep/pull/81

    • ดูเหมือนว่า SSH daemon ไม่เคยถูกเปิดใช้งานหรือเริ่มทำงานอัตโนมัติมาก่อน ถ้อยคำของสองรายการนี้ต่างกัน แต่ความหมายดูจะเป็นว่าเมื่อเริ่ม SSH daemon แล้ว องค์ประกอบที่ระบุไว้จะไม่ถูกเริ่มต้นโดยปริยายอีกต่อไป
      ตอนนี้ SSH daemon ปิด shell และบริการ exec เป็นค่าเริ่มต้นแล้ว ตามหลัก secure by default ทำให้หากไม่ได้ตั้งค่าไว้อย่างชัดเจน ผู้ใช้ที่ผ่านการยืนยันตัวตนจะไม่สามารถรันโค้ด Erlang ตามอำเภอใจได้
      ระบบย่อย SFTP ก็จะไม่ถูกเปิดใช้งานเป็นค่าเริ่มต้นอีกต่อไปเมื่อเริ่ม SSH daemon
  • เผื่อใครสงสัยว่า OTP ใน Erlang/OTP คืออะไร เดิมทีมันคือชุดของไลบรารีและหลักการที่ช่วยให้สร้างแอปพลิเคชันที่มีความน่าเชื่อถือสูงและทนทานต่อความล้มเหลวได้อย่างเป็นมาตรฐาน สำหรับงานด้านโทรคมนาคม
    ไอเดียพื้นฐานอ่านแบบสั้น ๆ ได้จากบทนำของ “OTP Design Principles”
    https://www.erlang.org/doc/system/design_principles.html

    • OTP = Open Telecom Platform
  • ถ้าแอป production ของคุณยังต่ำกว่า 29 ก็ควร อัปเดตให้เร็วที่สุดเท่าที่จะทำได้ ไม่ว่าจะเป็นเวอร์ชันนี้หรือแพตช์ล่าสุด เพิ่ง deploy ขึ้น production ไป แล้วระบบสแกนความปลอดภัยอัตโนมัติเจอ CVE ระดับ CRITICAL 2 รายการ พร้อมรายการความเสี่ยงระดับ HIGH อีกหลายรายการที่มีวันที่อยู่ในช่วงกุมภาพันธ์ถึงพฤษภาคม 2026

    • มีลิสต์ไหม?
  • สงสัยว่ายังมีคนใช้ Erlang กับโปรเจกต์ใหม่อยู่ไหม
    รู้ว่าที่นี่มีคนชอบ Elixir เยอะ แต่หมายถึง Erlang ล้วน ๆ
    ถ้ายังใช้ Erlang อยู่ อยากรู้ว่าอะไรทำให้ชอบมันมากกว่า Elixir

    • ปีนี้ก็ยังมีนะ มีงาน IoT ใหม่ที่ใช้ AtomVM, แอปพลิเคชันเซิร์ฟเวอร์ที่เขียนด้วย Erlang และ TUI framework ที่ยังทำอยู่
      Elixir ไม่ได้ให้ข้อได้เปรียบเชิงปฏิบัติที่ชัดเจนกับผมเมื่อเทียบกับ Erlang แน่นอนว่ามันอาจมีข้อดี แต่ Erlang เข้ากับวิธีคิดของผมมากกว่า ผมก็อยากลองเรียนรู้หรือขอความช่วยเหลือแบบเป็นกลุ่มสังคมดูเหมือนกัน แต่ยังหาแวดวงที่เหมาะกับตัวเองไม่ค่อยเจอ
  • มีใครอธิบายสถาปัตยกรรมภายในได้ไหม?

  • สงสัยว่า record จะไปอยู่ตรงไหนใน ecosystem

    • เกือบจะตอบว่า “record ก็มีมาหลายสิบปีแล้วไม่ใช่เหรอ?” แต่แล้วก็ไปอ่าน changelog
      น่าสนใจดี สงสัยว่าจะมีโลกที่วันหนึ่ง Elixir คอมไพล์ map เป็น native records ไหม
  • มีใครรู้ไหมว่า WhatsApp ยังใช้ Erlang อยู่หรือเปล่า?

    • ใช่
      พวกเขาใช้ Erlang มาตั้งแต่ช่วงต้นยุค 2010 และตอนนั้นวงการเทคก็เริ่มรู้กันว่า WhatsApp รองรับผู้ใช้ที่ใช้งานอยู่มากกว่า 400 ล้านคนได้ด้วยวิศวกรราว 30 คน
      ตอนนั้นผมติดต่อวิศวกรคนหนึ่งที่นั่น และตอนที่ผมยังอยู่ในสหรัฐฯ เขาก็กรุณาตอบคำถามบางอย่างทางอีเมล สุดท้ายเราได้นั่งดื่มกาแฟกัน และจนถึงตอนนี้ก็ยังติดต่อกันอยู่
      เรียกได้ว่า Erlang ยังเป็นส่วนสำคัญของ WhatsApp อยู่จนถึงทุกวันนี้
    • จากสิ่งที่นำเสนอใน Code BEAM Europe 2025 ก็ดูมีความเป็นไปได้ค่อนข้างสูงว่ายังใช้อยู่: https://www.youtube.com/watch?v=tC435RGwRCI
    • ไม่ได้รู้โดยตรง แต่ผมออกมาในปี 2019 และ repository สาธารณะที่เกี่ยวกับ Erlang ของ WhatsApp ก็ยัง active อยู่ เท่าที่รู้ Erlang ก็ไม่ได้กระจายไปทั่วทั้ง Meta ดังนั้นถ้า WhatsApp เลิกใช้ Erlang ไปแล้ว ก็คงไม่ค่อยมีเหตุผลให้ทำงาน Erlang ต่อหลังจากนั้น
    • ใช่ อดีตลูกน้องผมตอนนี้ทำงานอยู่ที่นั่น
    • ใช่ ใช้ Erlang อยู่ และ Rust ก็กำลังเพิ่มขึ้นเรื่อย ๆ
  • เพิ่มการรองรับ attribute -unsafe สินะ ถึงเวลาพอดีที่จะเขียนใหม่เป็น Rust /s

  • ไม่รู้จริง ๆ ว่าใครใช้ Erlang บ้าง เคยใช้ Rails แล้วลอง Phoenix ดู แต่รู้สึกว่าทำอะไรให้สำเร็จได้ยากกว่ามาก
    ผมไม่เข้าใจความคลั่งไคล้ Phoenix เลย
    สำหรับนักพัฒนาเดี่ยว Rails น่าจะเป็นระบบเว็บแอปที่ productive ที่สุดแล้ว LLM ก็เขียนโค้ด Ruby on Rails ได้ดีมาก แม้ corpus สำหรับ Python จะใหญ่กว่ามหาศาล แต่จากประสบการณ์ของผมมันก็ยังเขียนได้ดีกว่า Django มาก
    แอปเชิงทดลองผมเขียนด้วย Rails แล้วพอเริ่มนิ่งก็ค่อยเขียนใหม่ด้วย Go ถ้าขอบเขตแอปยังไม่ชัดเจนแล้วเริ่มด้วย Go เลยจะใช้โทเคนมากกว่ามาก แต่กับ Rails มันมีประสิทธิภาพมาก
    สมัยนี้ React หรือ Angular ก็ไม่จำเป็นแล้ว ใน Rails ก็ใช้ Hotwire ส่วนใน Go ก็ใช้ HTMX
    แม้แต่ฟอรัม Erlang เองก็ยังใช้ Discourse ที่เขียนด้วย Rails

    • ผมเขียนแอป Elixir แบบ full-time มาตั้งแต่ปี 2016 ลูกค้าพอใจมากกับการ ไม่เห็นระบบล่ม จริง ๆ แล้วในช่วง 10 ปีที่ผ่านมา แอปพลิเคชันทุกตัวที่ผม deploy ขึ้น production มี uptime 100% ยกเว้นความล้มเหลวของฮาร์ดแวร์ ระบบปฏิบัติการ หรือเครือข่ายที่ผมควบคุมไม่ได้
      น่าจะลองเปิดมุมมองให้กว้างขึ้นหน่อย
    • ถ้าพูดเรื่องความเร็วในการพัฒนา ผมว่า Rails จะเร็วกว่า Phoenix แค่ประมาณวันแรกเท่านั้น หลังจากนั้นก็จะเริ่มชนกับ implicit logic หรืออะไรอย่าง method_missing และต้องเสียเวลาเพิ่มเพื่อทำความเข้าใจว่ามันทำงานอย่างไร
      Elixir/Phoenix ชัดเจนกว่ามากในจุดนั้น เลยทำให้การดูแลรักษาระยะยาว หรือก็คือหลังจากผ่านสัปดาห์แรกไปแล้ว สะดวกกว่ามาก ไม่มี state ซ่อนอยู่ ไม่ต้องไล่หาเลยว่า ModuleName.method(params) มาจากไหน และไม่ต้องตั้งค่าอะไรเป็นพิเศษเพื่อรันเมธอดนั้น แค่ส่งอาร์กิวเมนต์ที่ถูกต้องก็พอ ข้อเสียคือไลบรารีแพ็กเกจสำเร็จรูปมีขนาดเล็กกว่าเท่านั้น
    • เดาไหมว่า Ruby Discord ใช้อะไร?
    • ที่ Phoenix น่าสนใจหลัก ๆ ก็เพราะ OTP, channels และ LiveView แต่ LiveView ไม่น่าจะเป็นตัวเลือกที่ผมจะเลือกในปี 2026 แล้ว และถ้าไม่ได้ต้องการฟีเจอร์พวกนั้น มันก็อาจจะไม่น่าสนใจเท่าไร
      Ecto ก็ไม่เลว
      Claude Code เขียนโค้ด Elixir ได้ดีมาก
      ที่น่าขำคือไม่ว่าจะมี LLM หรือไม่มี คุณก็จะ productive กว่าถ้าใช้เทคโนโลยีที่ตัวเองรู้จักอยู่แล้ว
    • ประโยคที่ว่า “ถ้าขอบเขตแอปยังไม่ชัดเจนแล้วเริ่มด้วย Go เลยจะใช้โทเคนมากกว่ามาก แต่กับ Rails มันมีประสิทธิภาพมาก” มันมีความย้อนแย้งอย่างแรงอยู่ในตัวเอง พูดยืดยาวขนาดนี้แต่สุดท้ายก็เผยว่าคนที่เขียนโค้ดจริง ๆ ไม่ใช่ตัวเอง