การนำ Haskell มาใช้และดำเนินงานระดับองค์กรที่ H-E-B

 (blog.haskell.org)
1 คะแนน โดย GN⁺ 8 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Haskell ถูกนำมาใช้ระหว่างการปรับปรุงซัพพลายเชนของร้านค้าและศูนย์กระจายสินค้ากว่า 435 แห่งให้ทันสมัย และ 8 ปีต่อมา โค้ดประมาณ 1 ล้านบรรทัด ที่ดูแลโดยหลายทีมกำลังทำงานอยู่ในระบบโปรดักชันหลัก
  • Haskell ช่วยลดประเภทของข้อผิดพลาดขณะรันไทม์ และรองรับการรีแฟกเตอร์บนฐาน GHC รวมถึงการเชื่อมต่อกับระบบเลกาซี แต่ต้องยอมรับภาระการดูแลเองเพราะ SDK มีไม่พอ และ ความซับซ้อนของฟีเจอร์ประเภทขั้นสูง
  • ความสำเร็จขึ้นอยู่กับความสามารถและวัฒนธรรมของทีมมากกว่าตัวภาษา และในสองโปรเจกต์ การนำไปใช้ไม่สามารถตั้งหลักได้ เนื่องจาก space leak ในทีมที่ไม่มีผู้เชี่ยวชาญ Haskell และการย้ายออกของนักพัฒนาหลัก
  • GHC runtime ไม่เคยเป็นสาเหตุของเหตุขัดข้องในโปรดักชันของ H-E-B และเมื่ออีโคซิสเต็มอย่าง HLS, OpenTelemetry และการทำโปรไฟล์พัฒนาขึ้น Haskell ในโปรดักชันจึงกลายเป็น ตัวเลือกที่แข่งขันได้
  • ควรจำกัดฟีเจอร์ขั้นสูงไว้หลังไลบรารีขนาดเล็กและอินเทอร์เฟซที่ชัดเจน ควบคู่กับการทดสอบ การสังเกตการณ์ และการแบ่งปันความรู้ และในยุคของ coding agent การตรวจสอบด้วย type ของ GHC และ feedback ที่รวดเร็ว จะยิ่งสำคัญขึ้น

โจทย์การปรับเมนเฟรมให้ทันสมัย

  • ลูกค้าของ H-E-B ผู้ค้าปลีกซึ่งเป็นบริษัทเอกชนที่ใหญ่ที่สุดในเท็กซัส ให้ความสำคัญกับการที่สินค้าวางเต็มชั้นในร้านมากกว่าระบบภายใน
  • เป็นเวลาหลายทศวรรษที่ เมนเฟรม COBOL ทำงานได้อย่างเสถียร แต่ในช่วง 10 ปีที่ผ่านมา ฟีเจอร์ที่ขับเคลื่อนด้วยเทคโนโลยีอย่าง curbside pickup, การส่งถึงบ้าน, สต็อกแบบเรียลไทม์ และการค้นหาภายในร้านได้เกิดขึ้น
  • เมื่อขยายการดำเนินงานซัพพลายเชนไปยังร้านค้ากว่า 435 แห่งและศูนย์กระจายสินค้าที่สนับสนุนร้านเหล่านั้น ระบบหลักเดิมจึงต้องรองรับความต้องการที่เกินขอบเขตที่ออกแบบไว้ตั้งแต่แรก
  • ความยากหลักของการปรับเมนเฟรมให้ทันสมัยไม่ใช่การย้ายโค้ดไปคลาวด์ แต่คือการรักษา ความรู้เฉพาะขององค์กร ที่สะสมอยู่ใน business logic เลกาซีมาหลายทศวรรษ
  • การแยก monolith ที่จัดการตารางหลายร้อยตารางออกเป็น microservice ที่ทีมวิศวกรรมอิสระเป็นเจ้าของ เป็นงานใหญ่ทั้งด้านเทคนิคและการเมือง และมีค่าใช้จ่ายสูง

การนำ Haskell มาใช้และขนาดการดำเนินงาน

  • ที่ปรึกษาเสนอ Haskell เป็นภาษากลางสำหรับโปรเจกต์ใหม่ที่จะมาแทนที่แอปพลิเคชันเมนเฟรมที่ใหญ่ที่สุดของบริษัท
  • งานที่เริ่มต้นเป็นการทดลองเติบโตขึ้นเป็นระบบโปรดักชันด้านซัพพลายเชนหลักหลายระบบ
  • 8 ปีหลังการนำมาใช้ หลายทีมในโดเมนต่าง ๆ ดูแลโค้ด Haskell รวมกัน ประมาณ 1 ล้านบรรทัด
  • การเดินระบบโปรดักชันในระยะยาวเผยให้เห็นทั้งผลลัพธ์จริงและความยากลำบากด้านเทคนิคและองค์กร

ข้อดีที่ธุรกิจได้รับ

  • สิ่งที่องค์กรต้องการไม่ใช่ lazy evaluation, pure function หรือ immutable data โดยตัวมันเอง แต่คือระบบคล้าย COBOL รุ่นถัดไปที่จะทำงานได้ 40 ปีโดยไม่มี null pointer exception และมีต้นทุนบำรุงรักษาต่ำ
  • แอปพลิเคชัน Haskell กำจัดประเภทของข้อผิดพลาดขณะรันไทม์ที่พบบ่อยในโปรแกรมเชิงคำสั่งและแบบ dynamic typing ได้โดยพื้นฐาน
    • บั๊กไม่ได้หายไปทั้งหมด แต่ปัญหาที่เหลือจะไปกระจุกที่ ข้อผิดพลาดของ business logic มากกว่า null pointer exception หรือการสับสนของ type
  • ในการย้ายจากระบบเลกาซีแบบ strangler fig ที่กินเวลาหลายปี GHC รองรับการรีแฟกเตอร์อย่างปลอดภัย
    • สามารถแก้ไขซ้ำ ๆ ระหว่างที่ requirements ก่อตัวขึ้นได้ จึงย้ายระบบแบบ agile แทน waterfall ได้
    • องค์กรสามารถวัดผลอย่างค่อยเป็นค่อยไป แทนการลงทุนล่วงหน้าในผลลัพธ์ที่อาจถูกตรึงไว้อย่างผิดพลาด
  • Parser ของ Haskell ทำให้สามารถใช้รูปแบบเลกาซีที่ยาวหลายพันบรรทัด เช่น IBM copybook แบบ fixed-width เป็น contract ได้โดยตรง
  • ด้วย foreign function interface (FFI) ที่ทรงพลัง จึงเชื่อมต่อกับบริการเดิมที่มีเฉพาะไลบรารี C ได้ด้วย
    • H-E-B เขียนไลบรารี Haskell ที่ห่อหุ้ม simdjson C++, Oracle ODPI-C และ IBM MQ

การขาด SDK และความเป็นเจ้าของ contract

  • เมื่อ Haskell SDK มีไม่พอ ก็ต้องสร้าง client และโค้ด integration ที่จำเป็นเองและดูแลต่อเนื่อง
  • สิ่งที่ได้แลกมาคือการเป็นเจ้าของ contract โดยตรง หลีกเลี่ยง vendor lock-in และไม่ต้องรอให้ผู้ดูแลโปรเจกต์ upstream ปล่อยแพตช์
  • H-E-B มองว่าการแลกเปลี่ยนนี้คุ้มค่าสำหรับ dependency หลัก
  • Coding agent สามารถจัดการงานเชิงกลไกอย่างการย้ายไลบรารี Go ไปเป็น Haskell ได้ดี จึงลดช่องว่างความเร็วในการพัฒนาระหว่างภาษา
    • อย่างไรก็ตาม การแปลตรง ๆ อาจใช้ประโยชน์จาก type system ของ Haskell ได้ไม่เต็มที่ หากไม่มี prompt ที่ประณีต

การรวมหลายภาษาผ่าน DSL ฝังตัว

  • Haskell มีจุดแข็งในฐานะภาษา host สำหรับ DSL ฝังตัว (eDSL)
    • ทีมกลางสามารถนิยาม domain model หรือ business logic เพียงครั้งเดียว แล้วสร้างเป็นโค้ดที่มี type ปลอดภัยในภาษาที่ทีมอื่นใช้
    • ทีมอื่นสามารถเชื่อมต่อกับระบบนั้นได้โดยไม่ต้องเขียน Haskell โดยตรง
  • Hydra เป็นเฟรมเวิร์ก DSL แบบโอเพนซอร์สที่พัฒนามาจากงานด้านข้อมูลกราฟของ Uber
    • bootstrap จาก Haskell และสร้าง implementation ที่เทียบเท่ากันในเชิงความหมายสำหรับ Java, Python, Scala เป็นต้น
    • รับประกันความเทียบเท่าของ implementation รายภาษาด้วยชุดทดสอบร่วม
  • H-E-B ทำต้นแบบ Haskell DSL สำหรับการคำนวณทางการเงินที่อ่อนไหว ซึ่งทีม Haskell, TypeScript และ Java สามารถใช้ร่วมกันได้
  • ยังสร้าง DSL สำหรับ JSON schema แบบสองทางด้วย
    • คล้ายกับ autodocodec แต่ใช้ tagless final encoding ที่ให้ผู้ใช้ขยาย semantics หลักด้วย type class ของตนเองได้
    • ทำให้การจัดการเวอร์ชัน schema, การสร้างเอกสารและ OpenAPI รวมถึง regression test และ golden test เป็นมาตรฐาน
    • สามารถเขียน interpreter เฉพาะกิจเพื่อแปลง JSON schema เป็นคำนิยามตาราง PostgreSQL หรือแทนที่ aeson ด้วย simdjson พร้อมใช้การตรวจสอบเพิ่มเติมได้

การสรรหาคนและวัฒนธรรมวิศวกรรม

  • ภาษา moderne ก็มีฟีเจอร์ด้าน type safety, purity และ concurrency ที่ได้รับอิทธิพลจาก Haskell อยู่มาก ดังนั้นความต่างที่แท้จริงอยู่ที่ วัฒนธรรมวิศวกรรม ที่ภาษาช่วยส่งเสริม
  • Haskell ดึงดูดนักพัฒนาที่ให้ความสำคัญกับความถูกต้องและการออกแบบ abstraction
  • การสรรหาคนสำหรับบทบาท Haskell ไม่ได้ยากเท่าที่ผู้บริหารคาดไว้
    • มีผู้สมัครที่มาสมัครเพราะตัว Haskell เอง แม้ไม่ได้สนใจซัพพลายเชนเป็นพิเศษ

ข้อจำกัดของงบประมาณความซับซ้อน

  • Haskell เป็นภาษาเก่าและมีข้อบกพร่องหลายอย่าง จึงสำคัญที่จะตาม GHC release รุ่นใหม่ให้ทัน
  • หากทีมไม่มีผู้เชี่ยวชาญ ข้อบกพร่องด้านภาษาหนึ่งอย่างอาจแพร่ไปทั่วทั้งโปรเจกต์ได้
  • ในช่วงแรก ที่ปรึกษาที่ชำนาญได้วาง guardrail เพื่อป้องกันการใช้ language extension และ operator แบบกำหนดเองมากเกินไป
  • ในช่วงที่ยังไม่มี language edition อย่าง GHC2021 และ GHC2024 แต่ละทีมต้องดูแลชุด extension พื้นฐานเอง
    • สิ่งนี้ทำหน้าที่เป็น งบประมาณความซับซ้อน ที่จำกัดขอบเขตภาษาที่พนักงานใหม่ต้องเรียนรู้ก่อนมีส่วนร่วมได้
  • Dependency เองก็ใช้งบประมาณความซับซ้อนเช่นกัน จึงยากที่จะบังคับใช้ในระดับองค์กร
    • servant แสดง API เป็น DSL ระดับ type และการขยาย combinator แบบกำหนดเองมาพร้อมกับ type family และ error ที่เข้าใจยาก
    • haxl โมเดลแหล่งข้อมูลทั้งหมดเป็น GADT ที่ index ด้วยชนิดผลลัพธ์ เพื่อ batch งานพร้อมกัน
  • ยิ่งนักพัฒนาชำนาญขึ้น ก็ยิ่งมีแรงดึงดูดให้ใช้ pattern อย่าง GADT, type family, generic, tagless final, arrow, free structure และ higher-kinded data type
    • เมื่อแนวคิดเหล่านี้ถูกวางทับบนโดเมนธุรกิจที่ซับซ้อนอยู่แล้ว คำมั่นเรื่องการบำรุงรักษาที่ง่ายก็อ่อนแรงลง
    • เพราะฟีเจอร์ขั้นสูงเพิ่มขึ้นทีละน้อยเมื่อคุ้นเคยกับอีโคซิสเต็ม การเพิ่มขึ้นของความซับซ้อนจึงอาจเผยตัวช้า

หลักการดำเนินงานของ Haskell ที่น่าเบื่อ

  • การสนับสนุน Haskell ที่น่าเบื่อ ในระดับองค์กรนั้นทำได้ง่าย แต่บังคับใช้ยาก
  • หาก encapsulate Haskell ขั้นสูงไว้หลังอินเทอร์เฟซที่สมเหตุสมผล ก็ลดขอบเขตผลกระทบ และจำกัดงบประมาณความซับซ้อนไว้ในไลบรารีขนาดเล็กที่ผู้เชี่ยวชาญจำนวนน้อยดูแลได้
  • ความซับซ้อนระดับภาษาไม่ใช่ปัญหาของ Haskell เท่านั้น แต่ Haskell มีชุดเครื่องมือขั้นสูงให้ใช้กว้างเป็นพิเศษ
  • จำนวนโค้ดที่จะแตกในการอัปเกรด GHC ครั้งถัดไป สะท้อนความซับซ้อนของโปรเจกต์ Haskell ได้ดีกว่าจำนวนบรรทัดโค้ดหรือปริมาณ token ที่ใช้

สองโปรเจกต์ที่ตั้งหลักไม่สำเร็จ

  • Haskell สามารถเพิ่มขีดความสามารถให้ทีมหนึ่ง แต่ก็เป็นอุปสรรคให้กับอีกทีมได้ และที่ H-E-B ก็มีสองโปรเจกต์ที่ตั้งหลักไม่ได้ด้วยเหตุผลต่างกัน
  • กรณีแรก นักพัฒนาที่มีประสบการณ์แต่ไม่มีประสบการณ์ Haskell ทำตาม template และ convention ของโปรเจกต์จากทีมอื่น แต่ space leak ทำให้ทั้งโปรแกรมหยุดทำงาน
    • การที่ไม่มีนักพัฒนา Haskell ที่แข็งแรงคอยนำทางทีม ทำให้ปัญหาเดียวนี้นำไปสู่การยุติโปรเจกต์
  • กรณีที่สอง วิศวกรที่สนับสนุน Haskell และสร้างแอปพลิเคชันย้ายไปโปรเจกต์อื่นเพราะการเปลี่ยนลำดับความสำคัญ
    • เหตุผลนี้ไม่เกี่ยวกับตัวภาษาเอง
  • ทั้งสองทีมมีทางเลือกที่จะกลับไปใช้เทคโนโลยีเดิม และไม่มั่นใจว่า Haskell เพิ่ม productivity ได้
  • หากมีทางออกอย่าง Spring Boot template แรงจูงใจที่จะวินิจฉัย space leak ที่ยากให้ถึงที่สุดอาจลดลง
  • เมื่อ LLM สามารถแปลทั้ง codebase ได้แบบกลไก ตัวเลือกการเขียนใหม่ก็ยิ่งกว้างขึ้น
  • แนวป้องกันระยะยาวไม่ใช่โค้ดที่ฉลาดจนเขียนใหม่ได้ยาก แต่คือ ทีมที่อยากดูแล Haskell ต่อไป

เหตุขัดข้องในโปรดักชันและการวินิจฉัย

  • แม้แต่ทีมที่ยอมรับ Haskell ก็พบปัญหาร้ายแรงหลายอย่าง
  • GHC runtime ไม่เคยเป็น root cause ของเหตุขัดข้องในโปรดักชันของ H-E-B
  • throughput และการใช้หน่วยความจำในสภาวะปกติแข่งขันได้เพียงพอสำหรับ workload ของ H-E-B และกรณีปัญหาที่กล่าวถึงเป็นข้อยกเว้น ไม่ใช่สถานการณ์ทั่วไป
  • วิศวกรแก้ปัญหาโดยไล่ดู segmentation fault core dump, metrics ของ garbage collection และ heap profile
  • ไม่ควรสละ test coverage ด้วยเหตุผลว่ามี type system ที่แข็งแรง
  • เนื่องจากแอปพลิเคชัน Haskell กำจัดประเภท error ง่าย ๆ ได้ตั้งแต่ขั้น compile chaos engineering จึงช่วยเผยข้อขัดข้องด้าน logic และ resource จริงได้ตรงกว่า

เครื่องมือพัฒนาและอีโคซิสเต็มที่เปลี่ยนไป

  • ระบบยุคแรกเริ่มจาก GHC 8.2 และตอนนั้นต้องเขียน API client และ SDK สำหรับแพลตฟอร์มยอดนิยมส่วนใหญ่เอง
  • ยังไม่มี Haskell Language Server, GHCup เพิ่งเริ่มเกิดขึ้น และ runtime profiling ก็ทำได้ยาก
  • นักพัฒนาที่คุ้นกับ Java IDE รู้สึกว่า tooling ของ Haskell ไม่สะดวก และ H-E-B ยังเคยสนับสนุนการพัฒนา Debug Adapter Protocol สำหรับผู้ใช้ VS Code ด้วย
  • ปัจจุบันพัฒนาไปไกลเกินระดับที่ทำ Haskell สำหรับโปรดักชันได้แล้ว และอยู่ในระดับที่แข่งขันได้
  • เครื่องมือพัฒนามี HLS, ghcid, ghciwatch, static-ls, tricorder และ editor plugin
    • บางส่วนใช้ GHC plugin เพื่อการพัฒนาที่เน้น GHCi อย่างเต็มรูปแบบ บางส่วนใช้ VS Code และ HLS
    • เปิดให้ผู้พัฒนาเลือกเครื่องมือตามที่ถนัด
  • ด้าน observability ใช้ hs-opentelemetry และ opentelemetry-auto
    • opentelemetry-auto เป็น GHC plugin ที่แทรก OTel span เข้าไปในฟังก์ชัน Haskell โดยอัตโนมัติ
    • สามารถให้สภาพแวดล้อมการ instrument ที่คล้ายกับ Java และ Python ได้

ไลบรารีโปรดักชันและการปรับปรุง runtime

  • บริการใช้ไลบรารีอย่าง warp, aeson, attoparsec, stm, conduit, servant และ orville-postgresql
  • หากอีโคซิสเต็มไม่มีฟีเจอร์ที่ต้องการ ก็พัฒนาไลบรารีเอง
    • arbiter เป็นคิวงาน PostgreSQL แบบ transaction-based ที่เกิดจากงานของ H-E-B และปัจจุบันทำงานอยู่ในโปรดักชัน
  • GHC กำลังปรับปรุง runtime diagnostics, ประสิทธิภาพ compiler, ความสามารถด้าน monitoring เช่น eventlog streaming และ exception annotation
  • หลังจาก info table profiling ถูกนำเข้ามาใน GHC 9.2 ความกังวลเรื่อง space leak ก็ลดลงมาก

คอมมูนิตี้ภายในและการกระจายความรู้

  • H-E-B ให้ความสำคัญกับไลบรารีภายใน และสนับสนุนให้นักพัฒนามีส่วนร่วมทั้งในโปรเจกต์ภายในบริษัทและโอเพนซอร์ส
  • ตลอดหลายปีมีการจัดพบปะ Haskell ทุกสองสัปดาห์ เพื่อให้วิศวกรแชร์ผลการสำรวจและให้ความรู้กับคนอื่น
  • หากต้องการลด silo ในองค์กรระดับ enterprise ไอเดียและ pattern ต้องไหลเวียนระหว่างทีม
  • การทำให้วิศวกรจำนวนมากขึ้นอ่านและเป็นเจ้าของ codebase ได้ ช่วยลด ความเสี่ยง bus factor ที่การลาออกของคนหนึ่งคนอาจทำให้โปรเจกต์สั่นคลอน

เกณฑ์ในการอนุญาตฟีเจอร์ขั้นสูง

  • ตั้งกฎพื้นฐานแบบหลวม ๆ แต่ tech lead เป็นผู้ตัดสินสุดท้ายว่าจะใช้งบประมาณความซับซ้อนตรงไหน
  • หากต้องเข้ารหัสข้อมูลส่วนบุคคลที่เก็บไว้ การรับประกันระดับ type ที่ทำให้การรั่วไหลของข้อมูลอ่อนไหวกลายเป็น compile error แทนเหตุการณ์ runtime อาจคุ้มค่ากับการลงทุน
  • งานรวม API contract สี่ชุดด้วย pattern trees-that-grow อาจไม่คุ้มพอที่จะซ่อน schema ภายนอกด้วย type family
  • Haskell ที่น่าเบื่อไม่ได้ห้าม type-level programming หรือฟีเจอร์ GHC ขั้นสูง แต่กำหนด convention อย่างมีหลักการ แล้วประเมินต้นทุนของการออกนอกกรอบ
  • convention หลักคือ “ไม่มี action-at-a-distance ที่ไม่คาดคิด”
    • หลีกเลี่ยงการสร้างโค้ดด้วย TemplateHaskell และ logic serialization ที่อิง Generic
    • เขียน boilerplate เองเพื่อให้ programmer เห็นพฤติกรรมอย่างชัดเจน
    • ไม่ได้ห้าม deriving ผ่าน quasiquoter หรือ Generically โดยสิ้นเชิง
  • เมื่อจะสร้าง type-level state machine สำหรับเว็บฟอร์ม หรือใช้ GADT ในที่ที่ ADT ธรรมดาก็เพียงพอ ต้องมีความสงสัยอย่างสมเหตุสมผลและการโต้แย้งในระดับทีม
  • Haskell ขั้นสูงมีอยู่ทั้งในไลบรารีและแอปพลิเคชันโปรดักชัน แต่ต้องจำกัดขอบเขตของการทดลอง
  • วิศวกรรมจริงเกิดขึ้นระหว่างการปรับสมดุลระหว่างงานกับการเล่นทางเทคนิค

อนาคตของ Haskell และ coding agent

  • ตลอดหลายปีที่ใช้ GHC พบและรายงานบั๊กจำนวนเล็กน้อย แต่ไม่มีปัญหาที่ทำให้งานหยุดชะงัก
  • เหตุการณ์ในโปรดักชันเกิดขึ้นไม่บ่อย และส่วนใหญ่มากเกิดจาก business logic มากกว่า type error หรือ runtime
  • เมื่อสัดส่วนโค้ดที่ coding agent เขียนเพิ่มขึ้น bottleneck กำลังย้ายจากการเขียนโค้ดไปสู่การตรวจสอบ
  • Type system ของ GHC ช่วยให้มนุษย์รีแฟกเตอร์ได้อย่างปลอดภัย พร้อมกันนั้นยังให้ feedback loop ที่รวดเร็ว ซึ่งปฏิเสธโค้ดที่ agent หลอนขึ้นมาก่อนรัน
  • หากต้องการขยายความเป็นไปได้ของ Haskell ในอุตสาหกรรม ควรมีการแบ่งปันกรณีความสำเร็จในโปรดักชันจริงให้มากขึ้น

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

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

 
GN⁺ 8 시간 전
ความคิดเห็นจาก Lobste.rs

  • นอกเท็กซัสอาจไม่ค่อยรู้จักกัน แต่ H-E-B เป็นสถาบันระดับสัญลักษณ์ของรัฐเท็กซัส มีทั้งขนาดและอิทธิพลมากจนแทบจะเรียกได้ว่าเป็นอีกหน่วยงานหนึ่งของรัฐบาลรัฐ
    หลายสาขามีจุดทำตอร์ติญาเอง และสำหรับสินค้าที่ผลิตในปริมาณมากก็ถือว่าคุณภาพยอดเยี่ยมทีเดียว แถมยังใช้ Haskell อีกด้วย

    • ชื่อนี้มาจาก ตัวย่อ H.B. ของ Howard Butt ซึ่งเป็นตระกูลผู้ก่อตั้ง ถ้าจะตั้งตามชื่อผู้ก่อตั้งแบบ Wegmans, Hannaford Market หรือ Walmart ก็ทำได้ แต่ก็น่าโชคดีที่ไม่ได้ชื่อ Buttmart
    • สงสัยว่ามันเป็นเหมือน Costco เวอร์ชันท้องถิ่นหรือเปล่า

  • เรื่องที่บริษัทอย่าง H-E-B เลือก Haskell มาแทนที่ COBOL นั้นน่าทึ่งมากจริง ๆ
    การบอกว่า coding agent สามารถย้ายไลบรารี Go มาเป็น Haskell แบบเชิงกลได้จนช่องว่างด้านความเร็วในการพัฒนาลดลง แล้วก็ยอมรับทันทีว่า หากไม่มีพรอมป์ต์ที่ฉลาดพอ ก็อาจใช้ประโยชน์จากระบบชนิดข้อมูลได้ไม่เต็มที่ สองประโยคนี้สะท้อนปัญหาที่ขัดแย้งกันเอง
    ในทางกลับกัน การที่ข้อผิดพลาดเล็กน้อยถูกกำจัดออกไปตั้งแต่ขั้นคอมไพล์ ทำให้เมื่อฉีดความขัดข้องของอินฟราฯ ด้วย chaos engineering สิ่งที่โผล่ออกมาคือข้อผิดพลาดเชิงตรรกะและทรัพยากรจริง ๆ แทนที่จะเป็นสัญญาณรบกวนจากภาษาแบบ dynamic typing ฟังดูเป็นเหตุผลที่น่าเชื่อที่สุดในการพิจารณา Haskell

    • H-E-B มี องค์กรวิศวกรรม ที่ทั้งขนาดใหญ่และมีชื่อเสียงดีพอสมควร คล้ายกับ Walmart เลยไม่ถึงกับน่าตกใจมากนัก พวกเขายังเปิดสำนักงานซอฟต์แวร์โดยเฉพาะใน Austin เพื่อดึงดูดคนเก่งสายซอฟต์แวร์ที่ไม่อยากทำงานที่สำนักงานใหญ่ใน San Antonio

  • สัปดาห์ก่อนพยายามตั้งค่า isolated Haskell build บน Bazel แต่หาโซลูชันที่พร้อมใช้งานได้ทันทีไม่เจอ
    ดูเหมือนว่า rules_haskell จะไม่ได้แยกสภาพแวดล้อมโดยปริยาย และแนวทางที่พบบ่อยมักพึ่ง nixpkgs อย่างมาก ดูเหมือน Haskell จะพึ่งพา system C++ linker อยู่ เลยสงสัยว่านี่คือสภาพจริงในปัจจุบัน หรือมีทางเลือกอื่นที่ผมพลาดไป