Nim 2.0 - ภาษาโปรแกรมที่มุ่งเน้นพาราไดม์การเขียนโปรแกรมเชิงคำสั่งและระบบมาโคร

 (nim-lang.org)
2 คะแนน โดย GN⁺ 2023-08-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การจัดการหน่วยความจำ ORC กลายเป็นค่าเริ่มต้น
  • แบ็กเอนด์ JavaScript ใช้ BigInt เป็นค่าเริ่มต้นสำหรับ int64 และ uint64 และโค้ดที่ทำงานร่วมกับ JS backend แล้วใช้ชนิดข้อมูลเหล่านี้อาจต้องอัปเดต
  • --experimental:strictEffects ถูกเปิดใช้งานตลอดเวลา และพารามิเตอร์ callback ต้องมี annotation effectsOf
  • ภาษา markup เริ่มต้นของคอมเมนต์เอกสารเปลี่ยนจากโหมด RstMarkdown เดิมเป็น Markdown และมีการเพิ่ม pragma {.doctype: Markdown | RST | RstMarkdown.} รวมถึงคำสั่ง md2html และ rst2html
  • ฟังก์ชันบางส่วนเกี่ยวกับ os ใน standard library ถูกแยกออกเป็นอินเทอร์เฟซใหม่ที่ใช้ abstraction Path โดยมีให้ในโมดูล std/oserrors, std/envvars, std/paths, std/dirs, std/files, std/symlinks, std/appdirs, std/cmdline
  • โมดูล standard library หลายตัวถูกย้ายไปเป็นแพ็กเกจ Nimble ดังนั้นเมื่อใช้ std/punycode, std/asyncftpclient, std/smtp, std/db_*, std/md5, std/sha1, std/sums จำเป็นต้องติดตั้งผ่าน nimble หรือ atlas
  • การใช้ break แบบไม่มีชื่อภายใน block แบบไม่มีชื่อถูกประกาศเลิกใช้ (deprecation) และจะกลายเป็นข้อผิดพลาดในเวอร์ชันถัดไป
  • นิยาม "strictFuncs" เปลี่ยนไป โดยห้ามบันทึกค่าผ่านการ dereference ของ ref หรือ ptr
  • การ unpack tuple ของตัวแปรถูกจัดการเป็น syntax sugar ที่ขยายเป็นการกำหนดค่าหลายครั้ง และรองรับการ unpack tuple แบบซ้อนกันแล้ว
  • มีการนำ top-down inference ไปใช้ในกรณีพื้นฐานหลายจุด ทำให้โค้ดตัวอย่างสำหรับการเริ่มต้น seq[(float, byte, cstring)] คอมไพล์ได้
  • สามารถกำหนดค่าเริ่มต้นให้ฟิลด์ของ object ได้ และฟิลด์ที่ไม่ได้ initialize อย่างชัดเจนจะใช้ค่าเริ่มต้นนั้น
  • เพิ่มสวิตช์ทดลอง strictDefs เพื่อตรวจสอบว่าตัวแปรได้รับการกำหนดค่าอย่างชัดเจนก่อนใช้งานหรือไม่ และตรวจสอบว่าตัวแปร let ถูกกำหนดค่าเพียงครั้งเดียวพอดี
  • การทำงานร่วมกับ C++ เพิ่ม pragma virtual และ pragma constructor ที่ขยายความสามารถ ทำให้สามารถนิยาม constructor และ virtual proc ที่แมปกับ constructor และ virtual method ของ C++ ได้
  • มาพร้อม Nimble 0.14 ซึ่งรองรับ lock-file และตำแหน่งเก็บไลบรารีเปลี่ยนจาก $nimbleDir/pkgs เป็น $nimbleDir/pkgs2

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

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

 
GN⁺ 2023-08-02
ความคิดเห็นจาก Hacker News

  • กำลังใช้ Nim ในโปรดักชันได้อย่างพึงพอใจ ส่วนใหญ่ทำเครื่องมือวิเคราะห์ข้อมูลและสร้างรายงาน แล้วคอมไพล์เป็นไฟล์ CLI executable ที่สคริปต์ฝั่งเซิร์ฟเวอร์เรียกใช้
    Nim สร้างไฟล์ executable ที่เร็วและมีขนาดเล็ก และมีโครงสร้างข้อมูล JSON แบบ heterogeneous กับไลบรารี dataframe ที่ดี ชอบใช้สแตกอย่างมาก ดังนั้นแม้แต่โครงสร้างข้อมูลแบบไดนามิกอย่าง sequence และ table ก็เป็นพอยน์เตอร์บนสแตกที่ชี้ไปยังข้อมูลบนฮีป และอายุการใช้งานถูกจัดการโดย stack frame
    ในโปรแกรมแทบไม่มี dynamic reference และไม่ต้องกังวลเรื่อง GC ระบบชนิดข้อมูลเรียบง่ายและสมเหตุสมผล ช่วยชี้นำให้เขียนโค้ดที่ถูกต้องได้ง่าย ค่าเริ่มต้นก็ใกล้เคียงกับ referential transparency และถ้าไม่ระบุให้หลุดออกจากแนวทางนั้น ทุกอย่างจะเป็น immutable value passing
    Generic มีพลังและทำงานตามที่คาดไว้ และ uniform function call syntax ก็มีประโยชน์อย่างไม่น่าเชื่อ แค่สร้าง procedure และ function ที่รับชนิดข้อมูลใดชนิดหนึ่งเป็นอาร์กิวเมนต์แรก ก็สามารถเขียนสิ่งที่เทียบเท่ากับ method หรือ interface ได้ ทำให้ไม่ต้องมี abstraction แบบนั้น โครงสร้างโค้ดจึงเรียบง่ายและแบนลง
    ใช้แล้วสนุกจนทำให้นึกถึงตอนที่เคยค้นพบ D แต่ดีกว่าด้วยซ้ำ ถ้าจินตนาการถึง Python ที่มี type annotation แบบ native compiled ซึ่งเกือบ 100% เป็น business logic และไม่มีสิ่งรุงรัง นั่นก็ใกล้เคียงกับประสบการณ์ของ Nim

    • คำอธิบายนั้นไม่ใช่แบบเดียวกับ C++ vector หรือ map ที่วางอยู่บนสแตกหรือ? คือภายในจัดสรรหน่วยความจำเมื่อจำเป็น และเมื่อคอนเทนเนอร์ทั้งตัวหลุดออกจาก scope ก็ถูกทำลาย
    • เริ่มอยากลองดู Nim แล้ว อยากรู้ว่า ระบบ build เป็นอย่างไร CMake นี่ทรมานจริงๆ
    • ดูเหมือน Python มากจริงๆ หวังว่าจะได้รับความนิยมมากขึ้น และดูเหมือน Rust ที่ใช้ง่ายกว่ามาก
    • ดูดีนะ อยากรู้ว่า การจัดการแพ็กเกจ อยู่ในสภาพไหน และ ecosystem ตอนนี้แข็งแกร่งแค่ไหน

  • ตั้งตารอที่จะลองใช้รีลีสนี้ ในฐานะคนที่เขียนโปรแกรมเป็นอาชีพมา 25 ปี ผมมองว่า Nim เป็นภาษาที่รวบรวมข้อดีจากหลายโลกไว้ได้ดี
    ใช้ง่ายเหมือน Python เป็นภาษา strongly typed แต่ type inference ยอดเยี่ยม และค่าเริ่มต้นถูกออกแบบให้เร็วและปลอดภัย เหมาะตั้งแต่ embedded ไปจนถึง high-performance computing
    ด้วย UFCS, generic และ concepts ทำให้ได้ข้อดีของ OOP แต่ไม่ค่อยต้องสร้างโค้ดโครงนั่งร้านที่วางความสัมพันธ์ของข้อมูลอันเปราะบางแบบไม่รู้จบเพียงเพื่อการจัดระเบียบ ต่างจาก Python ความกำกวมจะกลายเป็น compile error
    รู้สึกว่าโปรแกรมเดียวกันมีขนาดเล็กกว่า อ่านง่ายกว่า และเข้าใจง่ายกว่าภาษาอื่นส่วนใหญ่มาก เบื้องหลังก็ไม่ได้มีเวทมนตร์มากมาย เพราะค่าเริ่มต้นมันสมเหตุสมผล
    compile-time metaprogramming อยู่คนละระดับ มันฝังอยู่ในแกนของการออกแบบภาษา ไม่ใช่ dialect แยกหรือการเล่นแทนที่ข้อความ และยังใช้งานได้ตรงไปตรงมา ตัวอย่างเช่น สร้างโค้ด parsing แบบปรับแต่งเองจากไฟล์ได้ง่าย เพื่อตัด boilerplate ซ้ำๆ ออกไป และคอมไพล์ก็เร็ว
    ด้วยระบบชนิดข้อมูลที่ยอดเยี่ยม จึงเขียนให้ดีได้ง่ายกว่า Python แต่ประสิทธิภาพทัดเทียม C/C++ และยัง deploy เป็นไฟล์ executable ขนาดเล็กแบบ standalone ได้ง่ายมาก
    มี native ABI สำหรับ C, C++, ObjC, JS, FFI ที่ยอดเยี่ยม และ interoperability กับ Python ที่ดี สามารถใช้ ecosystem ที่มีอยู่ได้โดยตรงโดยไม่ต้องเขียนใหม่
    ลองจินตนาการถึงการเขียน pseudocode สไตล์ Python สำหรับ ESP32 แล้วได้โค้ดที่มีประสิทธิภาพมากโดยแทบไม่ต้องลงแรง และเมื่ออยากได้ก็ยังควบคุมแบบ bare-metal ได้ ใช้ภาษา efficient ภาษาเดียวกันเขียนเว็บแอปที่มีทั้ง backend และ frontend ทำเกม bullet hell ที่เร็ว โดยไม่ต้องกังวลเรื่อง GC เพราะถ้าไม่ระบุเป็นอย่างอื่นก็จัดสรรบนสแตก
    ในมุมธุรกิจ คุณค่าที่ใหญ่มากคือสามารถทำ prototype ได้เร็วเหมือน Python แต่ก็เร็วและเบาพอสำหรับโปรดักชันอยู่แล้ว อาจกลายเป็นอาวุธลับของบริษัทได้

    • กำลังใช้ Nim เป็น เป้าหมายสำหรับ scripting ในเกมและงานอื่นที่พูดละเอียดไม่ได้ เพราะมันแปลงเป็น C และ C++ ได้
      จุดที่ดีมากคือเราจัดการสภาพแวดล้อม C ซึ่งเป็น runtime ชั้นล่างเองได้ ขณะเดียวกันก็ใช้ภาษาระดับสูงสมัยใหม่ด้านบนที่รองรับสิ่งอย่าง JSON เป็น first-class ได้ดี แม้จะเป็นคนชอบ Python แต่ Nim ก็ดีกว่าและเป็น Python ที่ดีกว่า
    • อยากรู้ว่าแนวคิดการเขียนเว็บแอปด้วยภาษา efficient ภาษาเดียวกันทั้ง backend และ frontend นั้นทำงานอย่างไรในทางปฏิบัติ
      โดยเฉพาะ JS interoperability ระหว่างพัฒนาสะดวกแค่ไหน และไปไกลกว่าการคอมไพล์ Nim เป็นไลบรารี JS แบบ standalone หรือไม่ สามารถเรียก browser API โดยตรงจาก Nim หรือเรียกผ่าน wrapper ที่ค่อนข้างเรียบง่ายได้ไหม?
    • ในกรณีที่ระดับไมโครวินาทีมีความสำคัญ เช่นโค้ดที่ประมวลผล ADC 22 kSPS บน ESP32 พูดตรงๆ ว่าต้องใช้เวลา ปรับจูนราว 2 ชั่วโมง ตอนนั้นเพิ่งเริ่มเรียน Nim เลยเป็นงานหลีกเลี่ยงการ allocation เพิ่มเป็นหลัก
      ถึงอย่างนั้นตลอดประมาณ 4 ปี ก็ไม่มี performance regression ใหญ่ๆ หรือการเปลี่ยนแปลงที่จำเป็นมากนัก

  • ขอแสดงความยินดีกับทุกคนที่เกี่ยวข้องและทั้งชุมชน Nim ใช้ Nim เป็นภาษาหลักมาตลอด 10 ปีที่ผ่านมา และชอบฟีเจอร์ใหม่ๆ ของ Nim 2.0 มาก
    บางอย่างเป็นฟีเจอร์ที่เปลี่ยนเกมจริงๆ สำหรับโปรเจกต์ของผม ตัวอย่างเช่น ค่าเริ่มต้นของ object ในทางทฤษฎีอาจทำให้ Norm[1] ทำงานกับ object type ได้ ไม่ใช่แค่ object instance เท่านั้น ถ้าไม่มี enum ที่ overload ได้ซึ่งเพิ่มเข้ามาใหม่ Karkas[2] คงเป็นไปไม่ได้เลย ตอนนี้ยังอยู่ระหว่างทำงาน
    [1] https://norm.nim.town
    [2] https://karkas.nim.town

    • ในบรรดาการเปลี่ยนแปลงล่าสุด ผมชอบค่าเริ่มต้นที่สุด โดยรวมแล้วมีประโยชน์และช่วยลด boilerplate สำหรับการ initialize ลงอีก อีกทั้งยังทำให้รับประกัน สถานะที่ถูกต้องใน compile time ได้ในสิ่งอย่าง enum อาจรวมถึง object variant ด้วย

  • Nim เป็นภาษาที่ดีมากสำหรับการเขียนซอฟต์แวร์ สามารถ deploy ได้รวดเร็ว พัฒนาได้สนุก และยังสร้างซอฟต์แวร์ที่มีประสิทธิภาพสูงมากได้
    แต่จากประสบการณ์ก็ยังมีจุดคมๆ อยู่ ต้องปรับ compiler C/C++ และตัวเลือกให้เข้ากัน ข้อความ error แย่มาก และบางไลบรารีทำงานได้เฉพาะกับการตั้งค่าและระบบบางแบบเท่านั้น ถึงอย่างนั้นเมื่อคิดว่าชุมชนยังเล็ก ก็โทษมากนักไม่ได้ การผสานกับ VS Code ทำงานได้ดีและแทบไม่ crash

    • ผมมองว่าข้อความ error ที่ห่วยและเครื่องมือที่ยังไม่พอคือปัญหาใหญ่ที่สุดของ Nim นอกนั้นโดยรวมเป็นภาษาที่ยอดเยี่ยม
    • อย่างน้อย การรายงาน error ก็ปรับปรุงขึ้นแล้วเมื่อเร็วๆ นี้: https://nim-lang.org/blog/2023/03/31/version-20-rc2.html

  • ถ้า Manning Publications ได้เห็นสิ่งนี้ ก็หวังว่าจะมีหนังสือ Nim เวอร์ชันล่าสุดออกมา และอยากให้พิจารณาการจัดหน้ารูปแบบอื่นที่ใช้ฟอนต์อ่านง่ายกว่านี้
    ผมซื้อหนังสือยอดเยี่ยมของ Dominik Picheta มาแล้ว แต่ฉบับกระดาษอ่านยากมากเพราะฟอนต์บาง ถึงจะตัดแว่นแล้วก็ยังอ่านลำบาก จนต้องใช้ PDF แทน องค์ประกอบของฟอนต์อย่างเส้นและก้านตัวอักษรบางเกินไป
    ตอนแรกคิดว่าเป็นปัญหาของผมเองเพราะอายุมากขึ้น เลยลองเทียบกับ K&R ฉบับพิมพ์ครั้งที่ 2 ต้นฉบับ แต่เล่มนั้นยังอ่านได้ชัดเจนสมบูรณ์แบบ

    • araq/Andreas Rumpf ซึ่งเป็นหัวหน้าโปรเจกต์ก็ออกหนังสือด้วย: https://nim-lang.org/blog/2022/06/29/mastering-nim.html
    • แม้จะไม่ได้สังกัด Manning แต่ถ้ามีบัญชีล็อกอิน ก็สามารถส่งคำขอแบบนี้ผ่านหน้าติดต่อได้: https://www.manning.com/contact

  • Reddit เขียนบทความเกี่ยวกับวิธีที่พวกเขาใช้ Nim: https://www.reddit.com/r/RedditEng/comments/yvbt4h/why_i_enj...
    บริษัทใหญ่และสตาร์ทอัพจำนวนมากขึ้นเรื่อย ๆ กำลัง นำ Nim ไปใช้ ตื่นเต้นกับ Nim 2.0 มาก และขอบคุณทุกคนที่มีส่วนร่วมอย่างยิ่ง

    • เรื่องที่ว่าบริษัทใหญ่และสตาร์ทอัพจำนวนมากขึ้นเรื่อย ๆ นำไปใช้นั้นน่าสนใจ อยากรู้ว่ามี สถิติหรือข้อมูล ที่เกี่ยวข้องไหม หรือเป็นแค่เรื่องเล่าจากประสบการณ์
      ถ้าเป็นเรื่องเล่าก็ได้ พอจะยกชื่อบริษัทสักสองสามแห่งได้ไหม?

  • Nim เป็นภาษาที่ผมชอบที่สุดมาพักหนึ่งแล้ว และตื่นเต้นมากที่ในที่สุด 2.0 ก็ออกมา ฟีเจอร์จำนวนมากในรุ่นนี้เป็นสิ่งที่รอกันมานาน
    ข้อเสียเพียงอย่างเดียวคือ ตามที่กล่าวไว้ด้านล่าง โมดูลที่รวมมาบางส่วนถูกย้ายไปยัง รีโพซิทอรีของบุคคลที่สาม ไม่ใช่ปัญหาใหญ่ แต่การที่ไลบรารีรองรับ SQLite มาในตัวนั้นเป็นเรื่องดี พอเริ่มรองรับฐานข้อมูลบางตัว ก็อาจถูกกดดันให้รองรับฐานข้อมูลมากขึ้นอยู่ดี แต่ที่ค่อนข้างแปลกใจคือแม้แต่การรองรับ MD5 และ SHA1 ก็ถูกถอดออกด้วย

    • ถ้าอะไรเข้าไปอยู่ในไลบรารีแบบ “batteries included” ไลบรารีมักจะหยุดนิ่งได้ง่าย Python ยังลากแบตเตอรี่ที่ตายไปแล้วบางส่วนมาตั้งแต่ยุค 90 แต่ที่นั่นมันจำเป็น
      การรองรับ path หรือ logging อยู่ในมาตรฐานนั้นดี แต่บางอย่างควรอยู่เป็น ของบุคคลที่สาม เพื่อให้พัฒนาไปได้ดีกว่า

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

    • เกี่ยวข้องกันอยู่บ้าง ถ้าใช้ Denim จะสามารถเรียกโค้ด Nim จาก Node.js/Bun ได้: https://github.com/openpeeps/denim
      มันทำงานในลักษณะการสร้าง Node addon เหมาะสำหรับนำโค้ด Nim กลับมาใช้ซ้ำในเว็บแอป หรือใช้กับโค้ดที่ต้องการประสิทธิภาพสูง

  • เมื่อไม่กี่เดือนก่อนผมลองดู Nim แล้ว ในแง่ฟีเจอร์มีหลายอย่างที่อยากให้ Python มี เช่น ทำงานร่วมกับ C/C++ ได้ง่าย, static typing, การคอมไพล์, การ cross-compile ไป Android/iOS แล้วรันได้
    แต่ถึงแม้ภาษานี้จะไม่ได้ใหม่แล้ว ระบบนิเวศยังเล็ก ไม่มีไลบรารีคุณภาพสูงจำนวนมากแบบ numpy, scipy, pandas, opencv ของ Python น่าเสียดายที่ผู้เล่นรายใหญ่ไม่ค่อยนำไปใช้ และคิดว่าคงดีถ้า Unreal Engine ลองนำ Nim ไปใช้ แทนที่จะสร้างภาษา scripting ใหม่ของตัวเองชื่อ Verse
    อีกอย่างที่น่าเสียดายคือความสามารถในการทำงานร่วมกับไลบรารี C/C++ ได้ทันทีโดยไม่ต้องสร้าง adapter เอง อยากให้เป็นแบบแค่นำเข้า header ก็จบ
    ถ้ามีการทำงานร่วมกับ Rust ที่ง่ายคล้ายกันก็คงดี เพราะจะช่วยเพิ่มการนำไปใช้ และใน Rust หา crate ข้ามแพลตฟอร์มคุณภาพสูงที่ทำงานได้ดีแม้บนอุปกรณ์มือถือได้ง่ายกว่า
    กังวลว่าในอีกไม่กี่ปี Python ที่เร็วขึ้น, การเอา GIL ออก, nuitka, briefcase สำหรับมือถือ ฯลฯ อาจไล่ตามทัน หรือ Mojo อาจมาแย่งที่ของ Nim ไป

    • ถ้าจะพูดเข้าข้าง Nim ความจริงแล้วแทบจะมีแค่ Python เท่านั้นที่มี ระบบนิเวศแมชชีนเลิร์นนิง ขนาดใหญ่อย่าง numpy, scipy, pandas, opencv, pytorch, tensorflow, keras การทำงานสไตล์ ML/AI ด้วยภาษาที่ไม่ใช่ Python นั้นยากจริง ๆ
      ถึงอย่างนั้น Nim ก็มีไลบรารี nimpy ที่ทำงานร่วมกับ Python ได้แทบจะไร้รอยต่อ กล่าวคือสามารถนำเข้า PyTorch, scipy, opencv มาใช้ใน Nim ได้เลย

  • อยากรู้ว่ามีใครเคยใช้ Nim กับ Zig จริง ๆ ไหม อยากฟังว่าทั้งสองคล้ายและต่างกันอย่างไร และอยากเห็น benchmark เว็บเซิร์ฟเวอร์แบบ idiomatic ของทั้งสองภาษาโดยอิงจาก Nim v2 ด้วย

    • ผมเคยใช้ทั้งคู่ในโปรเจกต์ OS งานอดิเรก ใช้ Nim[1] และ Zig[2] และโดยส่วนตัวชอบ Nim มากกว่าเยอะ โค้ดกระชับและสง่างาม ทำให้โฟกัสที่ลอจิกหลักแทนที่จะต้องต่อสู้กับภาษา
      Zig ก็ดี และผมชอบการรองรับค่า optional กับแนวทางการจัดการข้อผิดพลาด แต่ผมไม่ค่อยชอบ ไวยากรณ์ที่รก อย่าง !?[]u8 ซึ่งใช้แทน error union ของ optional pointer ไปยัง multi-pointer ของ uint8
      ในโค้ดส่วนใหญ่ที่ต้องมีการจัดสรรแบบไดนามิก การต้องเตรียมและส่ง allocator ไปด้วยก็รบกวนลอจิกหลัก งานเล็ก ๆ อย่างการต่อ string หรือการจัดรูปแบบก็กลายเป็นเรื่องยุ่ง
      Zig ยังไม่มี dynamic dispatch ด้วย ทำให้เขียนโค้ดแบบ polymorphic ได้ยาก และต้องอ้อมไปใช้ duck typing บางรูปแบบ สุดท้ายผมจึงสรุปว่า Zig ไม่เหมาะกับผม
      [1] https://github.com/khaledh/axiom
      [2] https://github.com/khaledh/axiom-zig
    • ผมดูแล binding ที่ generate อัตโนมัติสำหรับไลบรารี C ของผมใน Zig, Nim, Odin และ Rust อยู่ ส่วน binding ของ Rust ถ้าจะทำให้ idiomatic กว่านี้ก็คงต้องปรับแต่งแน่นอน
      จากตัวอย่างต่าง ๆ จะเห็นว่าแทบจะเป็นโค้ดเดียวกันที่เขียนในหลายภาษา จึงพอมองภาพรวมได้ แต่ในแง่ฟีเจอร์ของภาษาแล้วยังแตะเพียงผิวเผิน เช่น ตัวอย่าง Zig ไม่ได้ใช้ฟีเจอร์ comptime
      Zig: https://github.com/floooh/sokol-zig/tree/master/src/examples
      Nim: https://github.com/floooh/sokol-nim/tree/master/examples
      Odin: https://github.com/floooh/sokol-odin/tree/main/examples
      Rust: https://github.com/floooh/sokol-rust/tree/main/examples
    • เคยเขียนโปรแกรมด้วยทั้งสองภาษา แต่ไม่ได้ใช้ Nim มาสักพักแล้ว ผมว่าความสนุกในการเขียนโค้ดฝั่ง Nim มีมากกว่า
      Zig น่าเบื่อกว่า แต่ทั้งหมดเป็นความน่าเบื่อด้วยเหตุผลที่ดี ส่วนตัวผมคงไม่เขียน OS ด้วย Nim แต่ Zig ถ้า mature แล้วน่าจะยอดเยี่ยมสำหรับงานนั้น ผมเริ่มใช้มันกับซอฟต์แวร์ฝังตัวแล้ว
      Nim ผมคงใช้กับเครื่องมือ CLI, แอปพลิเคชันเซิร์ฟเวอร์ และอาจรวมถึงแอป GUI กับเกมด้วย
      ทีม Zig ดูเหมือนทุ่มเทกับ โครงสร้างพื้นฐานของคอมไพเลอร์ ทั้งหมดมากกว่าเยอะ และจากประสบการณ์แล้วน่าประทับใจจริง ๆ มีนวัตกรรมดี ๆ หลายอย่าง
    • เคยใช้ทั้ง Nim และ Zig ในโปรเจกต์ใหม่ ๆ มาแล้ว ความแตกต่างเชิงรายละเอียดมีเยอะ แต่ถ้าพูดลักษณะง่าย ๆ Nim ใกล้เคียงกับความพยายามทำ มีดพับสวิส แบบ Python ให้อยู่ในรูปภาษา compiled
      Zig เป็นภาษาที่โฟกัสกว่ามาก โดยเล็ง niche เฉพาะในฐานะผู้สืบทอดและตัวแทนของ C และทำเป้าหมายนั้นได้ยอดเยี่ยม
      ผมคิดว่าความชอบภาษาอยู่ที่ความต้องการและความอยากส่วนตัวที่ภาษาปัจจุบันตอบไม่ได้ ผมลงหลักกับ Zig เพราะสนใจแนวทางที่มุ่งเป็นผู้สืบทอด C แต่ก็เข้าใจว่าทำไมคนอื่นถึงเลือก Nim
    • Zig ดูเหมือนจะไม่มี implementation ใน TechEmpower Benchmarks แต่ Nim มี: https://www.techempower.com/benchmarks/#section=data-r21&l=y...