Elm 0.19.2 ปรับปรุงความเร็วในการบิลด์

 (elm-lang.org)
1 คะแนน โดย GN⁺ 5 시간 전 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • Elm 0.19.2 เป็นก้าวแรกของแนวทางที่จะทยอยนำ รีลีสขนาดเล็ก หลายครั้งมาใช้ เพื่อส่งมอบการปรับปรุงคอมไพเลอร์ก่อนก้าวไปสู่ Elm 1.0
  • ในโค้ดเบส Elm ขนาดใหญ่ การคอมไพล์ใหม่ทั้งหมดวัดได้ที่ 5.7 วินาที และการบิลด์แบบ incremental หลังจากนั้นใช้เวลา ต่ำกว่า 350ms ช่วยลดโอกาสที่สมาธิระหว่างพัฒนาจะสะดุด
  • การปรับปรุงครั้งนี้มุ่งลดการจัดสรรหน่วยความจำระหว่างการ parsing โดยในการทดลองกับโค้ด 850,000 บรรทัด พบว่า ปริมาณการคัดลอกของ GC ลดลง 20%, การใช้หน่วยความจำสูงสุดลดลง 10% และความเร็วโดยรวมดีขึ้น 7%
  • ในการทดสอบกับโปรเจ็กต์จริง ระดับการปรับปรุงแตกต่างกันไป โดยกรณีที่คอมไพล์ 351 โมดูลใหม่ทั้งหมด ลดจาก 4.981 วินาที เหลือ 2.595 วินาที หรือเร็วขึ้น 1.9 เท่า
  • แนวคิดด้านประสิทธิภาพและภาษาที่มาจากงาน Acadia จะถูกทยอยนำมาใช้ต่อไปในรูปแบบ รีลีสที่ไม่ทำลายความเข้ากันได้ และหลังจากเก็บรายละเอียดขั้นสุดท้ายแล้วจึงไปต่อสู่ Elm 1.0

การคอมไพล์ที่เร็วขึ้นใน Elm 0.19.2

  • Elm 0.19.2 คือรีลีสแรกที่นำ การปรับปรุงคอมไพเลอร์ ที่สะสมมา ทยอยใส่กลับเข้า Elm ในหน่วยย่อยเล็ก ๆ
  • คอมไพเลอร์ที่เร็วช่วยลดสถานการณ์ที่นักพัฒนาสลับไปแท็บเบราว์เซอร์แล้วเสียสมาธิ
    • หากการคอมไพล์แบบ incremental ใช้เวลา ต่ำกว่า 400ms ก็แทบไม่มีจังหวะให้เปลี่ยนไปทำอย่างอื่น
  • ประสิทธิภาพบนโค้ด Elm ขนาด 850,000 บรรทัด มีดังนี้
    • คอมไพล์ใหม่ทั้งหมด: 5.7 วินาที
    • incremental build: ต่ำกว่า 350ms
  • การเปลี่ยนแปลงจริงในครั้งนี้เน้นไปที่ การลดการจัดสรรหน่วยความจำระหว่างการ parsing
    • ปริมาณการคัดลอกของ GC ลดลง 20%
    • การใช้หน่วยความจำสูงสุด ลดลง 10%
    • ความเร็วโดยรวม ดีขึ้น 7%
  • สำหรับโปรแกรมที่มีขนาดเกิน 500,000 บรรทัด คาดหวังการปรับปรุงแบบค่อยเป็นค่อยไปได้ และสำหรับโปรแกรมที่เล็กกว่านั้น คอมไพเลอร์ของ Elm ก็ยังคงเร็วมากอยู่แล้ว
  • ในการทดสอบบนสภาพแวดล้อมจริง ระดับการปรับปรุงแตกต่างกันไปตามแต่ละโปรเจ็กต์
    • บางโปรเจ็กต์ดีขึ้นเพียงเล็กน้อย
    • กรณีคอมไพล์ 351 โมดูลใหม่ทั้งหมด ลดจาก 4.981 วินาที เหลือ 2.595 วินาที หรือ ดีขึ้น 1.9 เท่า
  • สามารถดาวน์โหลดเวอร์ชันใหม่ได้จาก Elm compiler 0.19.2 release

รีลีสถัดไปสู่ Elm 1.0

  • แนวคิดที่ได้จากงานพัฒนาคอมไพเลอร์สำหรับฐานข้อมูลชื่อ Acadia จะถูกนำมาใช้กับ Elm ด้วย
    • Acadia อยู่ในสถานะ private alpha ในขณะนี้
    • มีกำหนดเปิดเผยข้อมูลสู่สาธารณะในช่วงปลายปีนี้
  • แนวคิดที่จะนำเข้า Elm ครอบคลุมทั้งการปรับปรุงประสิทธิภาพและความสามารถของภาษา
    • ตัวอย่าง: parser ที่เร็วขึ้น
    • ตัวอย่าง: ชนิด equatable, hashable
  • เพื่อให้การเปลี่ยนแปลงเหล่านี้ผสานเข้ากับ Elm ได้อย่างเป็นธรรมชาติ จะทยอยปล่อยเป็นชุดของ รีลีสขนาดเล็กที่ไม่ทำลายความเข้ากันได้
  • หลังจากขั้นตอนเก็บรายละเอียดสุดท้ายแล้ว มีแผนจะก้าวสู่ Elm 1.0
  • ผู้ใช้ที่เพิ่งเริ่มต้นกับ Elm สามารถเริ่มได้จาก ตัวอย่างออนไลน์ และคู่มือ
  • Elm 0.19.2 เป็น patch release จึงสามารถดาวน์โหลดเวอร์ชันใหม่มาใช้กับโปรเจ็กต์เดิมได้ทันที

บทความที่เกี่ยวข้อง

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

 
GN⁺ 4 시간 전
ความคิดเห็นใน Hacker News

  • ทุกวันนี้ผมมองว่า Elm ใกล้เคียงกับ ภาษาเพื่อการวิจัยที่มีอิทธิพลสูง มากกว่า
    มีจุดโฟกัสชัดเจน ไม่มีโรดแมปสาธารณะหรือการสนับสนุนอย่างเป็นทางการ และดูเหมือนผู้นำแทบไม่สนใจการสร้างชุมชนหรือทีมแกนหลัก
    ถึงอย่างนั้น ประสบการณ์การทำงานก็ยอดเยี่ยมจริง ๆ และผลก็คือมีฟอร์กและโปรเจกต์ต่อยอดหลายตัวเกิดขึ้น เมื่อไม่นานมานี้ที่งานประชุม Gleam, Louis Pilfold พูดติดตลกว่า “ผู้ใช้ Elm ต่างก็ดูแลคอมไพเลอร์ของตัวเอง” ซึ่งในความเป็นจริงมีอย่างน้อย 6 ตัว และเมื่อเดือนที่แล้วก็มีประกาศเพิ่มอีก 2 ตัว
    ดีใจที่เห็น Evan ขยับไปสู่ 1.0 และหวังว่า หลังจากเรียก Elm ว่าเป็นสิ่งที่ “เสร็จสมบูรณ์แล้ว” โปรเจกต์ผู้สืบทอดสักตัวจะรับงานยากอย่างการรวมฟอร์กและขยายชุมชนต่อไปได้
    ส่วนตัวถ้าครั้งหน้าจะหาอะไรที่คล้าย Elm ผมคงดู Gleam + Lustre ดูเหมือนจะมีชุดผู้ดูแลที่ใส่ใจทั้งชุมชนและการออกแบบ และทำงานได้ทั้งฝั่งฟรอนต์เอนด์กับแบ็กเอนด์

    • เส้นทางของ Elm ค่อนข้างแปลก แต่การเรียกว่า ภาษาเพื่อการวิจัย ก็น่าจะถูกแล้ว
      ครั้งหนึ่งมันเคยถูกเผยแพร่อย่างกระตือรือร้น มีบทความบล็อกและงานนำเสนอจำนวนมาก รวมถึงความตื่นตัวและการนำไปใช้ไม่น้อย
      แล้วผู้เขียนก็หายไปโดยปริยาย และโปรเจกต์ก็หยุดนิ่ง
      แน่นอนว่าเป็นโปรเจกต์ของเขา เขาย่อมมีสิทธิ์ทำแบบนั้น แต่ผมคิดว่าควรตั้งความคาดหวังให้ดีกว่านี้ตั้งแต่แรก การเผยแพร่อย่างแข็งขันช่วยกระจายไอเดียก็จริง แต่ก็ทำให้นักพัฒนารู้สึกเหมือนถูกทิ้งแบบกะทันหันด้วย
    • สิ่งที่ดีที่สุดของ Elm คือมันให้ความรู้สึกแบบ Haskell ชัดมาก หลายปีก่อนผมเคยทำของสนุก ๆ ด้วย Elm
      สิ่งที่ดีเป็นอันดับสองคือปรัชญา “ถ้าคอมไพล์ผ่าน ก็ทำงานได้” พูดตรง ๆ ใน Rust ส่วนใหญ่ก็ให้ความรู้สึกคล้ายกันได้เหมือนกัน แม้จะไม่ค่อยมีฟีล Haskell เท่าไร แต่ก็ยังมีเงาอันอบอุ่นของบรรพบุรุษสายฟังก์ชันนัลอยู่บ้าง
    • Gren ดูเป็นผู้สืบทอดที่มีความสามารถพอ และชุมชนก็คึกคักพร้อมช่วยเหลือดี
    • ผมก็เป็นหนึ่งในนั้น ผมขยายภาษาเพื่อใส่ฟีเจอร์อำนวยความสะดวกหลายอย่าง และโดยแก่นแล้วทำให้รองรับ ช่องทางข้อผิดพลาด ที่เหมาะสม รวมถึง dependency injection ผ่าน union type ที่สามารถถูกลบออกได้
      Elm เป็นภาษาที่ดี แต่ Evan ดูไม่สนใจการสร้างสิ่งที่มีประโยชน์จริง ๆ และการบริหารภาษาโดยรวมก็เละเทะ
    • เพราะ Elm ดีมากนี่แหละ คนเลยดูผิดหวังกับ ความหยุดนิ่ง แต่ความหยุดนิ่งนั้นก็เป็นเหตุผลที่ทำให้ Elm ดีด้วยเหมือนกัน

  • ผมเคยเขียนไว้ในปี 2023 ว่าทำไมยังใช้ Elm อยู่
    https://taylor.town/elm-2023
    ตอนนี้ปี 2026 แล้วก็ยังใช้ Elm ต่อด้วยเหตุผลเดิม :)
    แถม Claude ดูจะเข้ากับ Elm ได้ดีมากด้วย
    https://taylor.town/diggit-000

  • ราว 2 ปีก่อน ผมทดลองทำเกม Snake บนเบราว์เซอร์ด้วย Elm ซึ่งเป็นภาษาที่ชอบ โดยใช้ ChatGPT vibe coding
    ตอนนั้นยังค่อนข้างหยาบ และผมสรุปว่าโมเดลภาษาขนาดใหญ่อาจฆ่า Elm ได้
    ตอนนี้ผมใช้ Elm ในโปรดักชัน และโมเดลภาษาขนาดใหญ่ก็ดีขึ้นมาก กลับกัน ผมมองว่า Elm เป็นภาษาที่เหมาะกับโมเดลภาษาขนาดใหญ่ในตอนนี้มาก จนอาจทำให้มีการนำไปใช้เพิ่มขึ้น เพราะมันเรียบง่ายกว่าภาษาส่วนใหญ่ เสถียร และมีสถาปัตยกรรมที่มีจุดยืนชัดเจนอยู่ในตัวภาษา ทำให้โค้ดเบสต่าง ๆ คล้ายกันมาก

    • AI ทำให้ผมอินกับดนตรีมากขึ้นด้วย ซื้อ MIDI keyboard และตั้งค่าซอฟต์แวร์ DAW จริงจังแล้ว
      ยังทำของด้วย Rust มากขึ้นและอ่านเอกสาร Rust มากขึ้นด้วย โมเดลภาษาขนาดใหญ่ไม่ควรเป็นข้ออ้างที่จะไม่เรียนรู้สิ่งที่เรากำลังใช้ ถ้าใช้แบบนั้นก็เป็นวิศวกรที่แย่
      โมเดลภาษาขนาดใหญ่ช่วยซื้อเวลาให้เราไปค้นคว้าและเรียนรู้ เพื่อให้ดูแลผลลัพธ์ที่ได้ต่อได้ ถ้าเข้าใจปัญหาอยู่แล้ว ก็จะเขียนพรอมป์ต์ได้ดีขึ้นด้วย
    • คำพูดที่ว่าโมเดลภาษาขนาดใหญ่อาจเพิ่มการนำ Elm ไปใช้ ทั้งถูกและไม่ถูก
      สุดท้ายขึ้นอยู่กับว่า Elm มีอยู่ใน ข้อมูลฝึก และ RLHF มากแค่ไหน ผมเห็นด้วยว่าเฟรมเวิร์กหรือภาษาที่มีโครงสร้างชัดเจนทำให้โค้ดเบสคล้ายกันมากขึ้นและสร้างโค้ดได้ง่ายขึ้น
      แต่แค่นั้นยังไม่พอ และโดยทั่วไปการที่นักพัฒนาจะนำไปใช้นั้นเป็นวาทกรรมที่ซับซ้อนกว่านั้นมาก
    • อาจจะดีขึ้นแล้วก็ได้ แต่ผมผิดหวังมากที่เห็นเอเจนต์อย่าง Claude Code สะดุดกับ ช่องว่างที่มีความหมาย ของ Elm อยู่เรื่อย ๆ
      มันจัดการ Python ได้ดีมาก เลยรู้สึกแปลก และ Elm ก็เป็นหนึ่งในภาษาสมัยใหม่ที่เสถียรที่สุดด้วย เสถียรจนคนบ่นว่าไม่เปลี่ยนเลยนั่นแหละ เพียงแต่ครั้งสุดท้ายที่ลองน่าจะประมาณ 1 ปีก่อน ตอนนี้คิดว่าน่าจะดีขึ้นแล้ว
    • มุมมองนั้นก็มีเหตุผล ผมไม่เคยคิดแบบนั้นมาก่อน แต่ถ้า ระบบนิเวศ ไม่เดินหน้า ก็คงยังลังเลอยู่ดี

  • ข้อจำกัดเกี่ยวกับ JavaScript แก้ไปแล้วหรือยัง? เท่าที่จำได้ ถ้าจะเชื่อมกับ JavaScript ต้องใช้กลไก Ports ของ Elm และเหมือนจะไม่ให้เขียนแรปเปอร์เองโดยตรง
    จำได้ราง ๆ ว่ามีดราม่าตอนมีคนฟอร์กเพื่อให้เขียนแรปเปอร์ JavaScript หรือ FFI เองได้

    • FFI ส่วนใหญ่ยังจัดการผ่าน ports อยู่ ฝั่งวิวบางทีก็ใช้เว็บคอมโพเนนต์
      นี่เป็นการเลือกโดยตั้งใจ และน่าจะคงไว้จนถึง 1.0 รวมถึงหลังจากนั้นด้วย

  • ไม่เคยรู้เลยว่าโปรเจกต์นี้ยังมีชีวิตอยู่ ไม่ได้ตั้งใจจะประชดนะ แต่คิดว่ามันจบไปแล้ว

    • โปรเจกต์มันตายไปแล้วจริง ๆ รีลีสก่อนหน้านี้คือ เมื่อ 7 ปีก่อน และหลังจากผู้สร้างหยุดดูแล คอมมูนิตีก็ก้าวข้ามโมเดล BDFL ไม่ได้ เลยหยุดนิ่งไปแบบนั้น
      ดังนั้นมันเคยตายไปแล้ว และตอนนี้ก็เหมือนเพิ่งฟื้นคืนชีพขึ้นมา เท่าที่รู้ ระหว่างนั้นคอมมูนิตีน่าจะซบเซาไปมาก
    • ผมไม่ได้เข้าไปเกี่ยวข้องกับคอมมูนิตีลึก ๆ แต่รู้จักคนที่มีส่วนร่วมในตอนนั้น และตามความเข้าใจของผม การ ตัด custom infix operators ออก ทำให้เสียแรงสนับสนุนจากคอมมูนิตีไปมาก
      มันเป็นฟีเจอร์ที่ได้รับความนิยมมาก แต่ถูกเอาออกเพียงเพราะผู้สร้างภาษาไม่ชอบ ทั้งที่คอมมูนิตีขออย่างหนักแน่นให้คงไว้
      ในเชิงเทคนิคอาจเป็นการตัดสินใจที่ถูกก็ได้ แต่ในเชิงสังคมมันไม่เป็นที่นิยมอย่างมาก และผมคิดว่าน่าจะเป็นการตัดสินใจที่ผิด
    • ดีใจที่ได้เห็นมันกลับมา Elm มี ความงดงามอย่างน่าทึ่ง ที่ทำให้อยากเอาใจช่วยอยู่เสมอ
    • ตลอด 2 ปีที่ผ่านมา ผมใช้ Elm ในงานจริงที่บริษัทซึ่งทำกำไรได้ดีมากและไม่ฟุ่มเฟือย
      ก่อนเข้าทำงานผมไม่รู้จักมัน แต่มีประสบการณ์กับ React, Redux ฯลฯ เลยเรียนรู้ได้เร็ว
      ถ้าเป็นคอมมูนิตี Elm คงเรียกสิ่งนี้ว่าเป็นฟีเจอร์ แล้วโค้ด React ที่เขียนไว้เมื่อ 6–8 ปีก่อน มีสักเท่าไหร่ที่ยังทำงานได้ดีแบบเหมือนเดิมทุกประการบน toolchain ของ React ในปัจจุบัน?
      ชุดค่านิยมต่างกันโดยสิ้นเชิง โค้ด React ที่ดีในปี 2026 ดูคล้ายกับโค้ด Elm ที่คอมไพล์ได้มาตั้งแต่หลังปี 2016
    • ผมเองก็คิดว่าคอมมูนิตีรอบ ๆ Elm แทบจะหายไปแล้วเหมือนกัน ถึงอย่างนั้นดูเหมือนผู้ดูแลเดี่ยวและผู้สร้างภาษายังอยู่
      ผมไม่เคยใช้ Elm นอกจากบทเรียนสอนใช้งาน แต่ช่วงหลังได้ทำ แอป full-stack ด้วย Gleam และใช้ coding agent เป็นหลัก ช่วงแรกผมควบคุมโครงสร้างโค้ดค่อนข้างเข้มงวด และกระบวนการนั้นก็เข้ากันได้ค่อนข้างดี

  • ผมสนใจ หลัง Elm 0.19 มากกว่า Elm 1.0 อีก 0.19 เป็นเวอร์ชันที่บล็อก native module ทั้งหมดที่ผู้เขียน Elm ไม่ได้อนุมัติอย่างเป็นทางการ และในมุมมองของผม นั่นแทบจะเป็นเครื่องหมายจุดจบของ Elm

  • นึกไม่ออกเลยว่าจะมีประกาศเส้นทางไป 1.0 ที่แย่กว่านี้ได้อย่างไร ใครจะสน? ถ้าไม่มีการรองรับ localization หรือ accessibility ก็ไม่มีเหตุผลที่จะเรียก UI framework ว่า production-ready 1.0
    ผมมองว่าการจำกัดขอบเขตที่ผู้มีส่วนร่วมภายนอกจะเชื่อมต่อกับ Browser API ได้ เป็นสิ่งที่ฆ่าแรงส่งของ Elm สำหรับทุกอย่างยกเว้นโปรเจกต์ของเล่น
    ตอนนี้มันดูเหมือน sandbox ที่ Evan ใช้เล่นกับไอเดียคอมไพเลอร์ มากกว่าจะเป็นของสำหรับ production

    • ผมว่าแบบนั้นไม่ถูกนะ แอป Elm ที่ผมดูแลอยู่ localize ครบถ้วน และผมคิดว่า accessibility ก็ค่อนข้างดี
      localization ทำโดยมี record ใหญ่หนึ่งตัวต่อภาษา แล้วส่งต่อไปยังแต่ละส่วนของแอปที่ใช้สตริง สำหรับพหูพจน์หรือกรณีพิเศษเฉพาะภาษา ก็ใส่ฟังก์ชันง่าย ๆ ไว้ใน record ได้ ซึ่งสะดวกมาก
      ส่วน accessibility ทำได้ด้วย HTML ที่ดี, ports และในกรณีซับซ้อนอย่าง typeahead autocomplete ก็ผสมผสานกับ Web Components
    • ก็ปล่อยให้เขาสร้างไปเถอะ คนที่รู้จริงจะมองออกเองเมื่อมันพร้อม ส่วนคนที่ไหลตามกระแส ยังไงก็ช่วยไม่ได้อยู่แล้ว
    • ด้านหนึ่งก็ดีใจที่เห็น Evan ยังสบายดี เขามีไอเดียค่อนข้างดีเกี่ยวกับการพัฒนาภาษา และ Elm ก็เป็นแรงบันดาลใจให้โปรเจกต์ที่น่าสนใจมาก ๆ หลายตัว
      แต่อีกด้านหนึ่ง หลังจากไม่มีอะไรเลย 7 ปี แล้วออก การปรับปรุงประสิทธิภาพคอมไพเลอร์ เล็ก ๆ อย่างหนึ่ง แล้วเรียกว่า “เส้นทางสู่ 1.0” มันก็ยังไงอยู่ ไม่ได้มีเจตนาร้ายนะ แต่ทำไปทำไม? มันตายไปแล้ว ไว้อาลัยกันไปแล้ว และทุกคนก็จากไปนานแล้ว
      จนกว่าจะมีรีลีสที่น่าทึ่งจริง ๆ ออกมา ผมคิดว่าคนจำนวนมากคงไม่สนใจ

  • เหมือน Evan กำลังชี้ไปที่อะไรบางอย่าง แต่ทุกคนกลับมองแค่นิ้ว ผมคิดว่านี่จริง ๆ แล้วไม่ใช่เรื่อง Elm เอง แต่เป็นเรื่อง การเตรียม Acadia
    ในการบรรยายของเขา Economics of Programming Languages https://www.youtube.com/watch?v=XZ3w_jec1v8 เขาเผยให้เห็นเล็กน้อยว่าสิ่งที่ทำมาตลอด 7 ปีคืออะไร มันเป็นภาษา query ที่นำแนวคิดแบบ functional มาใช้
    เขาชี้ให้เห็นขอบเขตที่ข้อมูล type มักแตกหักในเว็บแอป คือระหว่างภาษากับ storage และระหว่าง storage กับ transport
    ถ้าสามารถรักษาข้อมูล type ข้ามขอบเขตเหล่านี้ไว้ได้ เราจะได้อะไร? หนึ่งในคำตอบที่เขายกมาคือ migration ที่ง่ายขึ้น แทนที่จะเขียน SQL ด้วยมือ ก็จัดการด้วยความแตกต่างของ type ได้
    ดังนั้นผมคิดว่าคำถามที่ถูกต้องคือ เมื่อดูการเปลี่ยนแปลงที่เข้าไปใน Elm แล้ว เราสามารถอนุมานได้ไหมว่า Acadia จะมีหน้าตาอย่างไร incremental compilation จะให้อะไรกับภาษา query ได้บ้าง?

    • เมื่อคิดถึงประวัติของ Elm แล้ว ทำไมเราควรเชื่อว่า Arcadia จะไม่ลงเอยแบบเดียวกัน?
      ต่อให้ไอเดียดีแค่ไหน ถ้า Arcadia ไม่มี โมเดลการพัฒนาที่มองไปข้างหน้ากว่าและขับเคลื่อนโดยคอมมูนิตี ก็ไม่มีใครจะนำไปใช้ อย่างมากก็จะเป็นแค่ “โปรเจกต์ที่เป็นแรงบันดาลใจให้ XYZ” เท่านั้น
      Evan อาจคิดว่านี่คือสิ่งยิ่งใหญ่ถัดไป และมันอาจเป็นจริงก็ได้ แต่ผมไม่รู้ว่าโลกหลัง Elm จะตั้งใจฟังมากพอหรือเปล่า

  • การที่ทำให้ เฉพาะทีม Elm ใช้ฟีเจอร์ภาษาบางอย่างได้ เขาถอนกลับหรือยัง? นั่นดูเหมือนการตัดสินใจที่ฆ่าภาษาได้เลย

  • เข้าใจถูกไหมว่า Elm สูญเสียแรงส่งไปมากแล้ว? ตอนนี้แม้แต่บน HN ก็แทบไม่มีการพูดถึง และผมสงสัยว่านี่เป็นหนึ่งในเหตุผลที่ช่วงห่างระหว่างรีลีสกับข่าวสารยาวมากหรือเปล่า
    ถ้าดูช่วงห่างของรีลีส 0.19.2 “Faster builds, and the Road to Elm 1.0” คือเดือนกรกฎาคม 2026 ส่วน 0.19.1 “Friendly syntax hints, faster builds” คือเดือนตุลาคม 2019
 
GN⁺ 5 시간 전
ความคิดเห็นจาก Lobste.rs

  • ว้าว! Elm 0.19.1 ออกมาเมื่อวันที่ 21 ตุลาคม 2019 ก็ผ่านมา 7 ปีแล้ว และนั่นยังเป็นข่าวสาธารณะล่าสุดเกี่ยวกับการพัฒนา Elm ด้วย
    ดีใจมากที่ได้เห็นข่าวใหม่จากโปรเจกต์นี้

    • ตื่นเต้นจริง ๆ ที่ Evan กำลังวางแผน v1 release
    • ผมก็เข้ามาเพื่อจะพูดแบบนี้เหมือนกัน
      ตอนลองใช้ Elm กับไซด์โปรเจกต์แล้วสนุกมาก แต่จากภายนอกชุมชนดูค่อนข้างเงียบ ข่าวนี้น่าตื่นเต้นมาก

  • Elm ทำให้การพัฒนาเว็บสนุกขึ้น
    รอดูว่า 1.0 จะนำอะไรมาบ้าง

  • เป็นข่าวเซอร์ไพรส์ที่ทำให้รู้สึกดีจริง ๆ
    ผมชอบ ความเสถียร ของ Elm มาตลอด และดูเหมือนว่า 1.0 ก็จะไม่เปลี่ยนแปลงแบบสุดโต่ง ซึ่งโดยส่วนตัวคิดว่าเป็นทิศทางที่ดี

    • breaking changes ที่อธิบายไว้น่าจะส่งผลค่อนข้างมาก
      ถ้า == และตัวอื่น ๆ ไม่รับทุก type อีกต่อไป ก็น่าจะมีโค้ด Elm จำนวนไม่น้อยที่ต้องแก้ อยากรู้ว่ากระบวนการอัปเกรดจะเป็นอย่างไร

  • ดีใจที่ได้เห็น อัปเดตของ Elm
    ภาษาโปรแกรมที่ไม่มีอัปเดตเลยเป็นเวลาหลายปีนั้นค่อนข้างไม่ปกติ เข้าใจเหตุผลอยู่ แต่การรับรู้ของสาธารณะก็มีแง่มุมแปลก ๆ

    • ใช่ โดยเฉพาะในฝั่ง frontend ที่ทุกอย่างขยับด้วยความเร็วบ้าคลั่ง

  • ชอบข่าวนี้
    บางครั้งก็กลับไปดู Elm อีกครั้งเหมือนเป็นการพักจากความบ้าคลั่งของการพัฒนา frontend ยุคใหม่

  • ผมมีโอกาสได้ดูการบรรยายของ Evan ที่ ZuriHac 2026 และประหลาดใจมากที่เขาเปรยว่าจะมี Elm release ใหม่
    หวังว่าวิดีโอจะถูกอัปโหลดเร็ว ๆ นี้ แต่ดูเหมือนเขาจะเข้าใจแล้วว่าวิธีที่มุ่งเน้นความเสถียรนั้นไม่ค่อยเข้ากับความหมกมุ่นเรื่องความก้าวหน้าอย่างรวดเร็วของอุตสาหกรรมนี้ จากที่ผมเข้าใจ Elm อาจเดินเป็นก้าวที่เล็กลงและเร็วขึ้นได้ ตื่นเต้นมาก และการบรรยายนั้นทำให้ผมคิดถึง Elm ขึ้นมาเยอะ

  • อยากรู้ว่า Elm จะจัดการฟีเจอร์ที่เห็นชัดขึ้นอย่าง type แบบ equatable และ hashable อย่างไร
    หนึ่งในตัวเลือกการออกแบบที่เป็นประเด็นถกเถียงของภาษานี้คือการหลีกเลี่ยงฟีเจอร์ระบบ type แบบ Haskell ที่ทรงพลังกว่า เช่น typeclass โดยส่วนตัวแล้วผมรู้สึกไม่สะดวกมาตลอดที่แม้แต่ custom type ที่มีลำดับตามธรรมชาติและนิยามไว้ชัดเจน ก็ยังใช้เป็น key ของ dictionary ไม่ได้ ถึงอย่างนั้น โดยรวมก็เป็นข่าวดีที่งานบน Elm ยังดำเนินต่อไป

    • คงไม่ควรคาดหวังฟีเจอร์แบบ typeclass มากเกินไป
      จากถ้อยคำในบล็อก ผมจินตนาการว่าน่าจะเป็นการเพิ่ม constrained type variables ใหม่อีกไม่กี่ตัว นอกเหนือจาก constrained type variables ที่มีอยู่ตอนนี้ คือ number, appendable, comparable, compappend