Elixir 1.17 เปิดตัว: ประเภทเชิงทฤษฎีเซตสำหรับแพตเทิร์น, Duration, OTP 27

 (elixir-lang.org)
1 คะแนน โดย GN⁺ 2024-06-13 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เพิ่มความสามารถของ gradual set-theoretic types ที่อนุมานประเภทจากแพตเทิร์นและแจ้งเตือนในเวลาคอมไพล์ เพื่อค้นหาข้อบกพร่องและบั๊กในโค้ดเบสโดยไม่ต้องเปลี่ยนซอฟต์แวร์เดิม
  • คำเตือนประเภทแบบใหม่ขณะนี้เน้นที่ atom และ map/struct โดยตรวจจับการ pattern matching กับคีย์ที่ไม่มีอยู่จริงและการเข้าถึงฟิลด์, การเรียกฟังก์ชันที่ไม่ใช่โมดูล, การเรียก anonymous function ที่ไม่ถูกต้อง, การเปรียบเทียบเชิงโครงสร้างระหว่าง struct, การเปรียบเทียบประเภทที่ไม่ทับซ้อนกัน, binary pattern ที่ไม่ถูกต้อง, และการ rescue exception ที่ไม่ได้กำหนดไว้
  • Typechecker ขณะนี้อนุมานประเภทจากแพตเทิร์นภายในฟังก์ชันเดียวกันเท่านั้น ส่วนการวิเคราะห์ guard และข้ามขอบเขตฟังก์ชันจะเพิ่มในรีลีสถัดไป
  • เพิ่มการรองรับ Erlang/OTP 27 และยุติการรองรับ Erlang/OTP 24; แนะนำให้ย้ายไป Erlang/OTP 26 ขึ้นไป รวมถึงบน Windows
  • การรองรับ WERL ซึ่งเป็นอินเทอร์เฟซกราฟิกของเทอร์มินัล Erlang สำหรับ Windows มีกำหนดถูกนำออกใน Elixir v1.18
  • เพิ่มชนิดข้อมูล Duration ใหม่และ Date.shift/2 ทำให้เลื่อนวันที่ เวลา และ date time ตาม duration ได้ โดยใน DateTime จะจัดการการเปลี่ยนเขตเวลาและ Daylight Saving Time
  • เพิ่ม Kernel.to_timeout/1 เพื่อทำให้ duration และ integer กลายเป็นค่า timeout มาตรฐานสำหรับใช้ใน API หลายตัว เช่น Process, GenServer
  • สามารถใช้ฟีเจอร์ process label ของ Erlang/OTP 27 ใน Elixir ได้ผ่าน Process.set_label/1 และ Logger จะฟอร์แมตรายงาน gen_statem พร้อมใส่ process label ของ Erlang/OTP 27 ในอีเวนต์ logger
  • เพิ่ม Keyword.intersect/2,3, Mix profiler ตัวใหม่ mix profile.tprof, และ guard Kernel.is_non_struct_map/1 เพื่อลดกับดักที่ %{} แมตช์กับ struct ด้วย
  • เมื่อเพิ่ม mix profile.tprof แล้ว mix profile.cprof และ mix profile.eprof จะถูกจัดเป็น soft-deprecation

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

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

 
GN⁺ 2024-06-13
ความคิดเห็นจาก Hacker News

  • ในช่วงไม่กี่ปีที่ผ่านมา ระบบนิเวศของ Elixir กำลังกลายเป็นทางออกที่เรียบง่ายที่สุดสำหรับการใช้งานหลากหลายจริง ๆ
    การพัฒนาเว็บด้วย Phoenix และ LiveView นั้นรวดเร็วและสนุก, ทำปัญญาประดิษฐ์ได้ด้วย NX/Axon/Bumblebee, สตรีมและประมวลผลเสียง·วิดีโอได้ด้วย Membrane, ทำ CQRS และ event sourcing ได้ด้วย Commanded, สร้างอุปกรณ์ embedded ได้ด้วย Nerves และยังทำแอปมือถือได้ด้วย LiveView Native ที่กำลังพัฒนาอยู่
    คิว, pipeline และ batch processing ก็จัดการให้เหมาะกับงานได้ด้วยฟีเจอร์พื้นฐาน หรือ GenStage, Broadway, Oban
    ถึงอย่างนั้น โดยส่วนตัวแล้วฟีเจอร์หลักคือ IEx ซึ่งเป็น REPL ของ Elixir ความสามารถในการโต้ตอบโดยตรงกับโค้ดที่กำลังพัฒนาหรือรันอยู่ในโปรดักชัน, ตรวจดูภายใน และดีบักได้นั้นถึงขั้นเปลี่ยนชีวิต
    การมี type เพิ่มเข้ามาเป็นชิ้นส่วนสุดท้ายของจิ๊กซอว์ที่จะทำให้เรามั่นใจในโค้ดที่ deploy มากขึ้น

    • นอกจากนี้ ExUnit ยังทำให้การทดสอบง่ายมาก, ตัวจัดการแพ็กเกจ Hex ก็ทำงานได้ดีเฉย ๆ และ FLAME ทำให้สามารถขยาย process ไปยังคอมพิวเตอร์เครื่องอื่นได้ด้วยโค้ดแทบจะแค่บรรทัดเดียว
      Ecto ทำให้จัดการฐานข้อมูล SQL ในแบบ functional ได้ แม้ยังไม่แน่ใจว่าควรมอง ORM อย่างไร แต่การที่ query ที่ประกอบกันได้ไม่กี่ตัวช่วยตัด SQL ออกไปได้ 90% ก็ถือว่าสำเร็จ
      หลังจากทรมานอยู่หลายเดือนกับการ deploy, uptime, segmentation fault, เวลาเกี่ยวกับแพ็กเกจ และอื่น ๆ ก็ย้ายเว็บเซิร์ฟเวอร์กับชั้นข้อมูลมาเป็น Elixir + Phoenix และตอนนี้ทดสอบได้ดีกว่ามาก, ให้เหตุผลได้ง่ายกว่า, เชื่อถือเรื่อง scalability ได้ และ deploy ก็ง่าย
      ด้วยแนวคิด convention over configuration ทำให้เริ่มต้นกับ Phoenix ได้เร็วอย่างไม่น่าเชื่อ และเร็วกว่ามากเมื่อเทียบกับ FastAPI รู้สึกว่าน่าจะทำตั้งแต่หลายเดือนก่อน
      ตอนนี้กำลังฝึกโมเดลด้วย Nx และลองเล่น Bumblebee/Livebook พร้อมทั้งใส่ฟีเจอร์ presence และ live ให้แอปได้แทบฟรี
    • ขอโปรโมต LiveView Native สักนิด ไม่ได้ทำได้แค่แอปมือถือ แต่ยังทำสำหรับ เดสก์ท็อป, นาฬิกา, TV, Apple Vision Pro ได้ด้วย
      ทั้งหมดใช้แนวคิด, ประสิทธิภาพ และความสะดวกในการพัฒนาของ LiveView เหมือนเดิม
    • ในฐานะคนที่มาจากภาษาที่มี ระบบ static type ที่ทรงพลังและมีประโยชน์ นี่คือช่องว่างที่เสียดายที่สุด จึงกำลังสนใจ Gleam อยู่
      คงยากที่จะกลับไปใช้สิ่งอย่าง Erlang หรือ Elixir อีก
    • เห็นด้วยว่า REPL ของ Elixir อยู่ระดับยอดเยี่ยม และเป็น killer feature ตัวจริงของภาษานี้
      ทุกครั้งที่เขียนโค้ดด้วยภาษาอื่น โดยเฉพาะตอนเขียนโค้ดรับเงิน จะคิดถึงมันมากจริง ๆ
      ถ้ามี REPL ที่ดี แรงเสียดทานที่มักเจอในการเขียนโปรแกรมจะลดลงมาก แทนที่จะต้องรันทั้งแอปเพื่อจิ้มทดสอบชิ้นโค้ดที่มีปัญหา ก็สามารถค่อย ๆ ต่อไอเดียและทดสอบไปทีละนิดได้ทันที
      standard library ของ Elixir ก็ยอดเยี่ยม และการเข้าถึงเอกสารจาก REPL ก็ง่ายมาก ช่วยให้รักษา flow ได้ดีมาก เวลาเขียนโค้ด Elixir แทบไม่ค่อยต้องเปิดเบราว์เซอร์เพื่อค้นคำถามเล็ก ๆ เพราะปกติหาคำตอบได้โดยไม่ต้องออกจาก REPL
      เลยเป็นแรงจูงใจให้เขียน docstring ดี ๆ ในโค้ดของตัวเองด้วย
      สิ่งที่ดียิ่งกว่าคือสามารถรัน REPL ควบคู่กับโค้ดที่กำลังทำงานอยู่ ได้ แม้เวลาต้องรันแอป ก็รันไปตามปกติ แล้วในสภาพแวดล้อมพัฒนาก็สามารถปรับแต่ง live data และตรวจดูสถานะภายในได้ ซึ่งใน stack อื่นมักทำไม่ได้หรือต้องใช้ debugger
      พอมีฟีเจอร์เกี่ยวกับ type เข้ามาอีก ก็คาดว่าเครื่องมือจะยิ่งดีขึ้น
      แถมยังมีความสนุกและพลังของ functional paradigm, มีวิธีที่แข็งแรงในการจัดการ mutability และ state และไม่ต้องรับมือกับ syntax แบบ LISP โดยส่วนตัวแล้วเป็นภาษาที่ลงตัวครบทุกโน้ต จึงชอบมากจริง ๆ
    • ภาษาอื่น ๆ ก็มีของแบบนี้เยอะไม่ใช่หรือ? Ruby มี IRB
      IEx ทำอะไรที่ IRB ไม่มีหรือเปล่า?

  • ตลอดหลายปีที่ผ่านมา ทีม Elixir และ Erlang ทำงานได้ดีมากจริง ๆ และจะไม่พูดถึงผลงานของผู้เขียนไลบรารีกับหนังสือก็ไม่ได้
    ไม่เคยตั้งตารอ release ไหนขนาดนี้มาก่อน ผมติดตาม commit ของ Elixir และ OTP มาพักหนึ่ง และรู้สึกว่า Elixir/Erlang กำลังมีแรงส่งอย่างชัดเจน

  • ผมใช้ Elixir เป็นแบ็กเอนด์ของไซด์โปรเจกต์ ส่วนฟรอนต์เอนด์เป็น Remix และงานฝั่งแบ็กเอนด์นั้นลื่นไหลและมีประสิทธิภาพมาก
    ยอมรับว่า LiveView ให้ productivity สูง แต่ในกรณีของผมต้องจัดการกับการเชื่อมต่อเครือข่ายที่ไม่เสถียร จึงเป็นไปตามคาดว่าประสบการณ์กับ LiveView ไม่ค่อยดีนัก
    อยากให้ในหัวของนักพัฒนา Elixir ถูกแยกออกจาก LiveView บ้างในระดับหนึ่ง แม้ใช้เป็นเพียงแบ็กเอนด์ API ธรรมดา ๆ โดยไม่มี LiveView หรือช่องทางเรียลไทม์ Elixir ก็สนุกมากจริง ๆ

    • ผมชอบ Elixir มากจนใช้กับแทบทุกอย่าง และ LiveBook ก็กลายเป็นที่เริ่มต้นหลักเวลาจะทำซอฟต์แวร์เล่น ๆ
      แต่ LiveView ผมไปไม่ค่อยไหว มันเข้าใจค่อนข้างยากและมีกับดักเยอะ เช่น บางครั้งต้องจำไว้ให้ได้ว่าต้องจัดการตรวจสอบการยืนยันตัวตนทั้งใน pipe_through ของ router และ callback on_mount ของ LiveView ดู [0]
      แค่ความจริงที่ว่าประโยคข้างบนไม่มีความหมายอะไรเลยสำหรับนักพัฒนาที่เพิ่งรู้จัก Phoenix และ LiveView ก็เพียงพอจะเป็นหลักฐานว่า LiveView ไม่ควรเป็นวิธีเริ่มต้น
      มันสร้าง learning curve ที่ชันมากในจุดที่ไม่จำเป็น ตัว Elixir/Phoenix เองนั้นง่าย
      ถ้าเป็นนักพัฒนาที่เพิ่งเรียน Elixir/Phoenix ผมคิดว่าลำดับที่ถูกต้องคือเริ่มจาก Phoenix dead views แบบสไตล์ MVC ก่อน แล้วค่อยอ่าน “Elixir in Action” เพื่อเรียนพื้นฐาน OTP หนังสือเล่มนี้อ่านง่าย เปิดโลกมาก และเปลี่ยนวิธีเขียนโค้ดของผมไปแทบทั้งหมด
      แล้วหลังจากนั้นค่อยไป LiveView จะดีกว่า
      [0]: https://hexdocs.pm/phoenix_live_view/security-model.html#liv...
    • ถ้ารัน mix phx.new พร้อมแฟล็ก —no-live ก็ใช้ Phoenix โดยไม่มี LiveView ได้ โปรเจกต์เดิมก็สามารถเอาออกด้วยมือได้เช่นกัน
    • คำตอบที่มีมาจนถึงตอนนี้พลาดประเด็นสำคัญ
      ปัญหาไม่ใช่เรื่องความรู้ทางเทคนิคหรือค่าเริ่มต้นตอนติดตั้ง แต่เป็นเรื่องการรับรู้ของนักพัฒนา คนจำนวนมากเกินไปนึกถึง LiveView ก่อนเมื่อพูดถึง Elixir และ ecosystem ที่เหลือ แล้วก็เดินผ่านโดยมองข้ามมันไป
      Elixir มีอะไรมากกว่านั้นมาก และแม้แต่ Phoenix เองก็ใหญ่กว่า LiveView
      สามารถสร้าง แอปพลิเคชัน Elixir ที่ productive และคุ้มต้นทุนได้เต็มที่ แม้ไม่มี LiveView หรือแม้แต่ Phoenix ด้วยซ้ำ การเลือก Elixir สำหรับแบ็กเอนด์ควรเป็นเรื่องที่พบได้บ่อยกว่านี้ แต่ก็เข้าใจคติความเชื่อและความกลัวที่ทำให้คนเลือกทางอื่น

  • ผมกำลังสร้างสตาร์ทอัปของตัวเองเป็น Elixir full-stack 100% และมันเป็นเทคโนโลยีที่ดีที่สุดเท่าที่เคยใช้มา
    ผมคอยบอกต่อเพื่อนสายเทคจริงจังอยู่เรื่อย ๆ ว่ามันดีแค่ไหน
    ตอนนี้คงจะดีมากถ้า RabbitMQ กับ client ของมันรันบน OTP 27 ได้ อยากอัปเกรดแล้ว

    • อยากรู้ว่าคุณทำงานแบบไหน ถึงรู้สึกว่า Elixir เข้าจุดพอดี เมื่อเทียบกับเทคโนโลยีอื่น
    • RabbitMQ ค่อนข้างแข็งแรงนะ คุณเจอปัญหาแบบ performance leak หรืออะไรทำนองนั้นอยู่หรือเปล่า?
      เราใช้วิธีล็อกอิน client ด้วยใบรับรอง SSL มาหลายปีแล้ว และพอใจกับความเสถียรมาก

  • สำหรับ Elixir และ Phoenix จะชมเท่าไรก็ยังไม่พอ และพอมี type เข้ามาด้วยก็จะยิ่งดีขึ้น
    คุณคงได้ยินเรื่อง BEAM และพลังของมันบ่อย แต่จากประสบการณ์ คุณสามารถไปได้ไกลมากจริง ๆ กว่าจะถึงจุดที่ต้องคิดถึงส่วนนั้นของ stack Phoenix ช่วย abstract ส่วนนั้นออกไปได้ยอดเยี่ยม ทำให้ได้ประโยชน์โดยไม่ต้องพยายาม
    ตัวอย่างเช่น Oban คุณได้งานเบื้องหลังที่ทรงพลัง ยืดหยุ่น และใช้ง่ายด้วยโค้ด Elixir ภายใน Postgres แทบจะฟรี ๆ เลย มันยอดมากจริง ๆ
    แนะนำให้ลองใช้ดู

    • ถ้าไม่ใช่เพราะ LiveView ผมคงเห็นด้วยเต็มที่
      เพราะ LiveView และการตลาดรอบ ๆ ที่หมกมุ่นกับมัน คนที่เดิมทีน่าจะยังไม่ต้องรู้จัก OTP ไปได้อีกนาน กลับต้องเจอ OTP ตั้งแต่ช่วงต้นมากของเส้นทาง บางทีอาจตั้งแต่ controller route แรกเลยด้วยซ้ำ
      การเขียน flow ของ LiveView ที่แน่นหนาและทดสอบได้ดี มีความซับซ้อนทางปัญญาพอ ๆ กับการเขียน stateful GenServer ที่มี flow ไม่เป็นเส้นตรงหลายแบบและมีจุดเข้า call/cast หลากหลาย
      LiveView ใช้คำศัพท์อีกชุดและมีชั้นอำนวยความสะดวกเล็ก ๆ อย่าง async assigns แต่ในเชิงกลไกแล้วมันคือ GenServer ตามตัวอักษร ผมคิดว่าการเข้าใจจุดนี้ให้ดีเป็นเรื่องสำคัญหากจะใช้มันอย่างมีประสิทธิภาพ
      ส่วน Oban ผมชอบมากจริง ๆ และคิดถึงมันมากเวลาไปอยู่ ecosystem อื่น

  • นอกเรื่องนิด มีใครเคยใช้ elixir-desktop [1] ไหม? มันเป็นชุด wxWidgets + LiveView เลยค่อนข้างคล้ายแอป Electron
    ใน [2] Wojtek Mach อธิบายว่าทีม Elixir สร้าง Livebook Desktop อย่างไร ครอบคลุมตั้งแต่ว่าโปรเจกต์เริ่มต้นอย่างไร บั๊กละเอียดอ่อนที่พบระหว่างทำแอปสำหรับ macOS ข้อจำกัดของ wxWidgets บน Windows ไปจนถึงรายละเอียดการ implement หลายอย่าง
    อยากให้ทีม Elixir ออกสิ่งที่คล้าย elixir-desktop อย่างเป็นทางการบนฐานของ Livebook เช่น fork repository ของ Livebook แล้วมีโปรเจกต์ template อย่างเป็นทางการสำหรับสร้างเดสก์ท็อปแอปพลิเคชันที่ใช้ LiveView
    ตอนนี้ Livebook แจกจ่ายเป็นไฟล์ executable สำหรับ Windows และ Mac อยู่แล้ว ถ้าใช้แนวทางเดียวกันเพื่อให้นักพัฒนาแจกจ่ายไฟล์ standalone executable ได้เหมือน Electron จะเป็นอย่างไร?
    ผมรู้จัก LiveView Native [3] ด้วย แต่คิดว่าเป็นคนละทิศทางกัน
    [1] https://github.com/elixir-desktop/desktop-example-app
    [2] https://www.youtube.com/watch?v=Kiw6eWKcQbg
    [3] https://native.live/

  • ตั้งตารอวันที่ข้ออ้างว่า ไม่มี type ซึ่งเคยขวางการแพร่หลายของ Elixir จะหายไป

  • ตลอด 10 ปีที่ผ่านมา ผมได้อ่านเรื่องราวเจ๋ง ๆ เกี่ยวกับ Elixir ที่นี่มาตลอด และก็ชอบภาษานี้ด้วย
    แต่ผมเลิกหางาน Elixir ไปเมื่อหลายปีก่อน เพราะเงินเดือนดูเหมือนจะต่ำกว่าภาษากระแสหลักอยู่เรื่อย ๆ
    มันอาจเป็นภาษาที่ผมอยากใช้มากที่สุด แต่สำหรับผม เงินเดือนกับผลิตภัณฑ์ที่ยอดเยี่ยมสำคัญกว่าเทคสแต็ก ดังนั้นในทางปฏิบัติผมอาจไม่ได้ทำงานกับมัน ถึงอย่างนั้น การเฝ้าดูจากระยะไกลก็ยังสนุกอยู่

    • ในฐานะนักพัฒนา Elixir ฟังดูน่าแปลกใจที่ว่า เงินเดือนต่ำกว่าภาษากระแสหลัก
      สงสัยว่ากำลังหางานในสหรัฐฯ หรือในภูมิภาคอื่น
    • เงินเดือนโดยทั่วไปสูงกว่าสแต็กกระแสหลักอย่างสม่ำเสมอ ส่วนหนึ่งเป็นเพราะ ตำแหน่งงาน Elixir ส่วนใหญ่ต้องการวิศวกรระดับซีเนียร์

  • ฟีเจอร์ที่ดีในรีลีสนี้คือการเพิ่ม get_in/1 ที่ทำงานกับ struct ได้ เช่น สามารถเขียนแบบ get_in(struct.foo.bar) ได้
    ถ้า foo คืนค่าเป็น nil การเข้าถึง bar ก็จะไม่เกิด exception

    • ใน Elixir เวอร์ชันก่อน ๆ ก็ทำได้ แต่ไวยากรณ์ดูรกกว่า
      สำหรับลำดับชั้นที่ไม่ใช่ map ธรรมดา ต้องใช้ Access.key แบบนี้
      get_in(struct, [Access.key(:foo), :bar])

  • นี่คือชิ้นส่วนสุดท้ายที่ผมต้องการแล้ว ตั้งตารอขั้นต่อไป
    นอกเหนือจากนั้น ตามเกณฑ์ของผม ภาษานี้ถือว่า สมบูรณ์ในเชิงฟังก์ชัน 100% แล้ว

    • ครั้งสุดท้ายที่ผมดู Elixir ดูเหมือนจะมีฉันทามติว่า “สุดท้ายก็ ต้องทำ Erlang ด้วย”
      ตอนนี้ยังเป็นแบบนั้นอยู่ไหม หรือไม่จำเป็นต้องลงไปถึง Erlang อีกแล้ว?