ทำไมต้อง F#?

 (batsov.com)
7 คะแนน โดย GN⁺ 2025-04-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • F# เป็น ภาษาเชิงฟังก์ชันตระกูล ML ที่มุ่งเป้าไปยัง .NET และพัฒนาโดย Microsoft โดยเมื่อเทียบกับ C# ซึ่งเน้นเชิงวัตถุเป็นหลักแล้ว F# จะมุ่งเน้นไปที่กระบวนทัศน์การเขียนโปรแกรมเชิงฟังก์ชัน
  • บทความนี้สรุปคุณลักษณะของภาษา F#, ecosystem, สถานะของเอกสารประกอบ, เครื่องมือพัฒนา, กรณีการใช้งาน, สถานะของชุมชน และการเปรียบเทียบ F# vs. OCaml

F# คืออะไร?

  • F# เป็นภาษาการเขียนโปรแกรมอเนกประสงค์ ที่ออกแบบมาเพื่อให้เขียนโค้ดได้กระชับ แข็งแรง และมีประสิทธิภาพ
  • ออกแบบมาเพื่อให้สามารถ โฟกัสกับการแก้ปัญหาได้โดยตรง โดยไม่ต้องกังวลกับไวยากรณ์ที่ซับซ้อน
  • เป็นโอเพนซอร์ส ข้ามแพลตฟอร์ม และเข้ากันได้ดีกับ .NET

  • คุณสมบัติ

    • ไวยากรณ์ที่เบาและ immutable by default
    • type inference และ generalization
    • first-class function, ชนิดข้อมูลที่ทรงพลัง, pattern matching
    • รองรับ asynchronous programming (Async)
    • เป็นภาษาต้นกำเนิดของ pipeline operator (|>) อันโด่งดัง

  • ตัวอย่างโค้ดแบบง่าย

    open System  
let names = [ "Peter"; "Julia"; "Xi" ]  
let getGreeting name = $"Hello, {name}"  
names |> List.map getGreeting |> List.iter (printfn "%s")
  • F# เริ่มต้นจากภาษาที่ Don Syme พัฒนาขึ้นที่ Microsoft Research ในปี 2005
    • เริ่มจาก โครงการวิจัยที่พกพา OCaml มายังแพลตฟอร์ม .NET (Caml.NET)
    • หลังจากนั้นได้ถูกรวมเป็นผลิตภัณฑ์อย่างเป็นทางการตั้งแต่ปี 2010 และในปี 2024 ก็มีการออก F# 9.0
    • ณ ปี 2025 ภาษานี้ได้กลายเป็นภาษาที่เติบโตเต็มที่ในวาระครบรอบ 20 ปี
  • เหตุผลหลักที่ทำให้ลองทดลองใช้ F#
    • เพื่อตรวจสอบว่า .NET พัฒนาไปเป็นโอเพนซอร์สและข้ามแพลตฟอร์มแล้วจริง
    • เพื่อเปรียบเทียบข้อดีข้อเสียกับ OCaml
    • เพราะมีเสียงประเมินเชิงบวกต่อ tooling อย่าง Rider, Ionide เป็นต้น
    • เพราะสนใจในการสำรวจภาษาใหม่แบบเรียบง่าย

F# ในฐานะภาษา

  • F# เป็น ภาษาเชิงฟังก์ชันตระกูล ML และมีไวยากรณ์ที่คุ้นเคยสำหรับผู้ใช้ OCaml
  • นักพัฒนาที่เคยใช้ Haskell หรือ Lisp มาก่อนก็สามารถปรับตัวได้ไม่ยาก
  • ใช้โครงสร้างไวยากรณ์ที่อิงช่องว่าง จึงเหมือน Python ตรงที่ การเยื้องมีความสำคัญทางไวยากรณ์
  • ออกแบบมาให้แม้แต่มือใหม่ก็เรียนรู้ไวยากรณ์พื้นฐานได้อย่างรวดเร็ว

  • สรุปคุณลักษณะของภาษา

    • การนิยามและการนำฟังก์ชันไปใช้ สามารถเขียนได้อย่างกระชับและเป็นธรรมชาติ
    • เงื่อนไข ลูป tuple และการจัดการ list ใช้งานได้อย่างสะอาดในสไตล์เชิงฟังก์ชัน
    • ใช้ record, discriminated union, pattern matching เพื่อจัดการโครงสร้างข้อมูลที่ซับซ้อนได้อย่างกระชับ
    • ผ่าน pipeline operator(|>) ทำให้สามารถ จัดโครงสร้างการไหลของข้อมูลให้เห็นชัดเจนราวกับการต่อฟังก์ชันเข้าด้วยกัน
    • F# เหมาะมากกับการเขียน ad-hoc script โดยเขียนเป็นไฟล์ .fsx แล้วรันได้ทันทีด้วย dotnet fsi
    • ยังมีสภาพแวดล้อม REPL ให้ใช้งาน จึงเหมาะกับ exploratory programming

  • ไวยากรณ์ที่เป็นมิตรกับผู้ใช้

    • มีคุณสมบัติไวยากรณ์เชิงปฏิบัติ เช่น คอมเมนต์แบบบรรทัดเดียวและหลายบรรทัด, ตัวแปร mutable, list slice
    • ด้วยความเข้ากันได้สูงกับ C# จึงใช้งาน .NET API ได้ง่าย
    • รองรับ operator overloading กับหลายชนิดข้อมูลได้อย่างเป็นธรรมชาติ
    • สามารถพิมพ์ค่าของชนิดต่าง ๆ ได้สะดวกด้วย printfn จึงมีประโยชน์ต่อการดีบักและการทำ logging

  • ผู้บุกเบิกด้าน asynchronous programming

    • ต้นกำเนิดของแพตเทิร์น async/await คือ F# 2.0 ซึ่งภายหลังส่งอิทธิพลต่อหลายภาษา เช่น C# และ JavaScript
    • F# มีโครงสร้างที่ช่วยให้เขียน asynchronous programming ได้ อย่างเป็นธรรมชาติโดยไม่ต้องใช้ callback
    • แม้ลำดับของโค้ดจะอ่านได้เหมือน synchronous แต่การทำงานจริงเป็นแบบ asynchronous

  • การลงทุนของ Microsoft และพัฒนาการของภาษา

    • Microsoft เคยจัดสรรบุคลากรให้ F# อย่างจำกัดมาเป็นเวลานาน แต่ ในปี 2022 ได้ตั้งทีมเฉพาะที่กรุงปรากและเริ่มลงทุนอย่างจริงจัง
    • จากการออก F# 8.0 และ 9.0 ทำให้เห็นว่า ทั้งภาษาและ tooling กำลังพัฒนาเร็วขึ้นมาก
    • เมื่อความสนใจภายใน Microsoft เพิ่มขึ้น ก็ทำให้มีความคาดหวังต่อ ศักยภาพการเติบโตในอนาคต ได้เช่นกัน

F# เป็นภาษาที่เรียนรู้ง่าย แต่ก็มี type system ที่ทรงพลังและกระบวนทัศน์การเขียนโปรแกรมเชิงฟังก์ชันที่ครบถ้วน โดยเฉพาะอย่างยิ่ง เป็นตัวเลือกที่น่าสนใจมากสำหรับนักพัฒนาที่อยากนำแนวทางเชิงฟังก์ชันมาใช้ในโปรเจกต์บน .NET

ระบบนิเวศ (Ecosystem)

  • จากการใช้งาน F# มาในช่วงเวลาที่ค่อนข้างสั้น พบว่า ไลบรารีหรือเฟรมเวิร์กที่ทำมาเพื่อ F# โดยเฉพาะยังมีไม่มากนัก
  • ผู้ใช้ส่วนใหญ่มักพึ่งพา API พื้นฐานของ .NET และไลบรารีภายนอกที่ออกแบบโดยยึด C# เป็นหลัก
  • นี่เป็นปรากฏการณ์ที่พบได้บ่อยใน ภาษาโฮสต์ (hosted language) อย่าง Scala, Clojure, Groovy

  • ไลบรารีหลักสำหรับงานเว็บ

    • Giraffe: เว็บเฟรมเวิร์กน้ำหนักเบาบน ASP.NET Core ที่มุ่งสู่สไตล์เชิงฟังก์ชัน
    • Suave: เฟรมเวิร์กเว็บเซิร์ฟเวอร์แบบเรียบง่ายในสไตล์ combinator สำหรับ routing และการประกอบงาน
    • Saturn: เฟรมเวิร์กสไตล์ MVC ที่สร้างบน Giraffe ได้แรงบันดาลใจจาก Ruby on Rails และ Phoenix
    • Bolero: เฟรมเวิร์กสำหรับพัฒนาแอปฝั่งไคลเอนต์บน WebAssembly และ Blazor
    • Fable: ทรานส์ไพล์ F# ไปเป็น JavaScript เพื่อเชื่อมต่อกับ ecosystem ของ JS อย่าง React, Node.js เป็นต้น
    • Elmish: UI framework ที่อิงแพตเทิร์น MVU(Model-View-Update) และมักใช้ร่วมกับ Fable
    • SAFE Stack: สแตกสำหรับพัฒนาเว็บเชิงฟังก์ชันแบบ end-to-end โดยผสาน Saturn, Fable, Elmish, Azure เป็นต้น

  • ไลบรารีหลักสำหรับ data science

    • Deedle: ไลบรารีวิเคราะห์และจัดการข้อมูลสไตล์ pandas
    • DiffSharp: ไลบรารีเชิงคณิตศาสตร์ที่ให้ความสามารถด้าน machine learning และ automatic differentiation
    • FsLab: ชุดเครื่องมือ data science แบบรวมศูนย์ที่มีทั้ง visualization และเครื่องมือวิเคราะห์สถิติ

สถานะของเอกสารประกอบ

  • เอกสารทางการโดยรวม จัดระเบียบได้ดีและมีคุณภาพสูง
  • บางส่วนอยู่ใน Microsoft Docs และบางส่วนกระจายอยู่ใน F# Software Foundation
  • แม้โครงสร้างเอกสารอาจดูค่อนข้างกระจัดกระจายอยู่บ้าง แต่ style guide ของภาษา, เอกสารการออกแบบ, และ API ของ standard library มีประโยชน์มาก

  • ลิงก์เอกสารที่แนะนำ

  • แหล่งเรียนรู้จากชุมชน

    • F# for Fun and Profit: รวมบทสอนและบทความเชิงเรียงความ (ค่อนข้างเก่าแต่ยังใช้ได้อยู่)

เครื่องมือพัฒนา (Dev Tooling)

  • ระบบนิเวศของเครื่องมือพัฒนา F# ในอดีต ถูกปรับให้เหมาะกับ Visual Studio เป็นหลัก และรองรับ editor อื่นค่อนข้างน้อย
  • โชคดีที่ในช่วง 10 ปีที่ผ่านมา สภาพแวดล้อมด้านเครื่องมือดีขึ้นมาก

  • จุดเปลี่ยนทางเทคนิค: FSharp.Compiler.Service(FCS)

    • FCS เป็นไลบรารีเดียวที่รวมทั้งคอมไพเลอร์ F#, ฟีเจอร์สนับสนุน editor และ scripting engine ทำให้สามารถใช้งาน F# ได้ใน editor และสภาพแวดล้อม tooling ที่หลากหลาย
    • ด้วยเหตุนี้ VS Code, เครื่องมือสร้างเอกสาร, และ backend ทางเลือกต่าง ๆ จึงรองรับ F# ได้ และช่วยขยาย ecosystem
    • ตัวอย่างเด่นคือ Ionide ที่ให้การรองรับ F# อย่างครบถ้วนใน VS Code และ มียอดดาวน์โหลดมากกว่า 1 ล้านครั้ง

  • editor ที่ได้ลองใช้

    • Emacs (fsharp-mode): ให้ความสามารถพื้นฐาน, ไม่รองรับ TreeSitter, มีกิจกรรมการพัฒนาไม่มาก
    • Zed: การรองรับ F# ยังจำกัด
    • Helix: มีการรองรับพื้นฐาน
    • VS Code (ปลั๊กอิน Ionide): เป็นหนึ่งในสภาพแวดล้อมที่สมบูรณ์ที่สุด
    • JetBrains Rider: แม้เป็น IDE เชิงพาณิชย์ แต่รองรับ F# ได้ทรงพลังมาก

    ฟีเจอร์ส่วนใหญ่ทำงานบนพื้นฐานของ F# language server(fsautocomplete) ดังนั้น editor ใดก็ตามที่รองรับ LSP ได้ดี ก็ใช้งานได้ทั้งหมด

  • จุดที่น่าเสียดาย

    • fsharp-mode อิงกับ codebase เก่าและพัฒนาได้ช้า
    • Zed ยังขาดฟีเจอร์
    • VS Code มีบางฟังก์ชัน (เช่น ขยาย/ย่อ selection) ที่ทำงานได้ไม่ดี
    • ผู้ใช้บางคนก็รู้สึกว่า VS Code ใช้งานไม่สะดวกเพราะปัญหาเรื่อง keybinding/โมเดลแบบ modal

  • code formatter และ linter

    • Fantomas: code formatter ทางการของ F# ที่ผู้ใช้และทีมส่วนใหญ่ใช้งานอยู่
    • FSharpLint: เคยได้รับความนิยม แต่ตอนนี้แทบหยุดพัฒนาไปแล้ว
    • อย่างไรก็ตาม ด้วย คอมไพเลอร์ที่ทรงพลัง ทำให้การพึ่งพา linter ต่ำ

  • เครื่องมืออื่น ๆ

    • Paket: ตัวจัดการ dependency สำหรับ .NET (คล้าย npm, pip, bundler)
    • FAKE: DSL สำหรับเขียน build script ด้วย F# คล้าย rake ของ Ruby

กรณีการใช้งาน (Use Cases)

  • ด้วย ecosystem ที่กว้างขวางของ .NET ทำให้ F# มีศักยภาพในการใช้งานได้หลากหลายด้าน
  • โดยเฉพาะด้วยความสามารถของ Type Providers จึงเหมาะมากกับ งานวิเคราะห์และจัดการข้อมูล
  • เหมาะกับการพัฒนา backend service และแอปพลิเคชันแบบ full stack และบางเครื่องมือก็ทำให้ พัฒนา frontend ได้ด้วย

  • ขอบเขตการใช้งานหลัก

    • การวิเคราะห์ข้อมูล: ใช้ type provider ของ F# เพื่อจัดการข้อมูลแบบ static type ได้
    • บริการ backend: ใช้ F# ร่วมกับเว็บเฟรมเวิร์กที่แข็งแกร่งของ .NET ได้
    • แอป frontend: ผ่าน Fable และ Elmish จึงพัฒนา UI ที่เชื่อมกับ ecosystem ของ JS ได้
      • ตั้งแต่ Fable 4 เป็นต้นไป ยังสามารถทรานส์ไพล์ไปยังภาษาอย่าง TypeScript, Rust, Python ได้ด้วย

  • ตัวอย่าง Fable (คำสั่งทรานส์ไพล์แบบง่าย)

    • JavaScript:
      dotnet fable
    • TypeScript:
      dotnet fable --lang typescript
    • Python:
      dotnet fable --lang python

สถานการณ์ของชุมชน

  • โดยรวมแล้วชุมชนมีขนาดไม่ใหญ่ และ อาจเล็กกว่า OCaml ด้วยซ้ำ
  • Reddit และ Discord เป็นพื้นที่สื่อสารที่คึกคักที่สุด
  • มีชุมชน Slack เช่นกัน แต่เข้าถึงได้ยากเพราะระบบเชิญอัตโนมัติมีปัญหา
  • บทบาทของ Microsoft ภายในชุมชนยังไม่ชัดเจน และชุมชนค่อนข้างขับเคลื่อนกันเอง

  • แหล่งข้อมูลหลักที่ชุมชนดูแลอยู่

    • Amplifying F#: ช่วยขยายการรับรู้เกี่ยวกับ F# และกระตุ้นการมีส่วนร่วมของภาคธุรกิจ
    • F# for Fun and Profit: คลังบทสอนและบทความเชิงเรียงความ
    • F# Lab: ชุดเครื่องมือชุมชน F# สำหรับ data science
    • F# Weekly: จดหมายข่าวสรุปข่าวสาร F# ล่าสุด

ความนิยมและความเป็นจริง (The Popularity Contest)

  • F# ไม่ได้อยู่ในอันดับสูงของตัวชี้วัดความนิยมส่วนใหญ่ (TIOBE, StackOverflow, ประกาศรับสมัครงาน ฯลฯ)
  • แต่นี่ก็เป็นความจริงที่ ภาษาเชิงฟังก์ชันส่วนใหญ่ต้องเผชิญ และไม่ใช่ปัญหาเฉพาะของ F#
  • แม้ยังไม่ใช่กระแสหลัก แต่ก็ยังมีฐานผู้ใช้ระดับใกล้เคียงกับภาษาเชิงฟังก์ชันอื่นอย่าง Clojure, OCaml, Emacs Lisp

  • ทำไมต้องใช้ F#?

    • นอกเหนือจาก โอกาสในการหางาน แล้ว เหตุผลในการเลือกภาษาโปรแกรมก็มีได้หลากหลาย
      • เพื่อความสนุก (มีคนพูดกันว่า F ใน F# หมายถึง “Fun”)
      • เพื่อเรียนรู้กระบวนทัศน์และแนวคิดใหม่ ๆ
      • เพื่อฝึกคิดในแบบที่ต่างออกไปจากวิธีคิดที่คุ้นเคย

  • แหล่งข้อมูลที่เกี่ยวข้อง

เปรียบเทียบ F# vs OCaml

เป้าหมายแรกเริ่มของ F# คือการนำข้อดีของ OCaml มาสู่ .NET และนำข้อดีของ .NET กลับไปสู่ OCaml
– Don Syme, ผู้สร้าง F#

  • F# ถูกพัฒนาขึ้นโดยได้รับแรงบันดาลใจจาก OCaml และในช่วงแรกมีความคล้ายกันมากถึงขั้นรองรับนามสกุลไฟล์ .ml, .mli ด้วย
  • เมื่อเวลาผ่านไป มันก็ค่อย ๆ พัฒนาเป็นภาษาอิสระของตัวเอง และตอนนี้ทั้งสองภาษาก็กำลังเติบโตไปคนละทิศทาง

  • ข้อดีของ F#

    • อยู่บนแพลตฟอร์ม .NET
      • ใช้งานไลบรารีจำนวนมหาศาลได้
    • มีการสนับสนุนจาก Microsoft
    • เป็นมิตรกับผู้เริ่มต้น
      • มีไวยากรณ์ที่คุ้นเคยสำหรับผู้ที่เคยใช้ภาษาเชิงวัตถุ (เช่น C#)
      • ข้อความ error จากคอมไพเลอร์ค่อนข้างชัดเจน
      • ประสบการณ์การดีบักตรงไปตรงมามากกว่า
    • รองรับ asynchronous programming ได้แข็งแกร่ง
    • มีฟีเจอร์ที่ OCaml ไม่มี
      • anonymous record
      • active pattern
      • computational expressions
      • sequence comprehension
      • type providers
      • units of measure

  • ข้อเสียของ F#

    • อยู่บนแพลตฟอร์ม .NET
      • การออกแบบภาษามีการประนีประนอมหลายจุดเพื่อรองรับการทำงานร่วมกับ .NET (เช่น การยอมให้มี null)
    • เป็นของ Microsoft
      • แต่ละคนมีระดับความชอบต่อ Microsoft ต่างกัน
      • ทรัพยากรที่จัดสรรให้ F# ค่อนข้างน้อย
      • ในระยะยาวยังไม่แน่ชัดว่า MS จะสนับสนุน F# มากน้อยแค่ไหน
    • ปัญหาเกี่ยวกับชื่อ
      • คนที่ไม่ชอบ naming convention แบบ PascalCase, camelCase อาจรู้สึกไม่สะดวก
      • ชื่อ F# อาจสร้างปัญหาในการค้นหาหรือการตั้งชื่อไฟล์ (จึงมักเขียนเป็น FSharp ด้วย)
    • ขาดฟีเจอร์ขั้นสูงบางอย่างที่ OCaml มี
      • first-class module, functor
      • รองรับ GADT ได้ไม่ดีนัก
    • ไม่มีมาสคอต และไม่มีกล้องอูฐด้วย

  • จุดร่วมและการเปรียบเทียบกัน

    • ทั้งสองภาษาสามารถ target ไปยัง JavaScript runtime ได้
      • F#: Fable
      • OCaml: js_of_ocaml, Melange
    • ตอนนี้ Fable ดูมีความสุกงอมมากกว่า แต่ยังต้องการประสบการณ์ใช้งานจริงเพิ่มเติม
    • ทั้งคู่เป็นภาษาที่ทรงพลังแต่เฉพาะกลุ่ม และมีโอกาสต่ำที่จะกลายเป็นภาษายอดนิยมในวงกว้างในเร็ว ๆ นี้
    • F# มีความเป็นภาคปฏิบัติที่ค่อย ๆ แทรกเข้าไปใน codebase C# เดิมได้
    • ข้อเสียอย่างหนึ่งคือ โปรเจกต์ F# ยังใช้ไฟล์โปรเจกต์แบบ XML และต้องกำหนดลำดับการคอมไพล์ด้วยตนเอง
      • เมื่อเทียบกับระบบ build ของ OCaml อย่าง Dune แล้ว อาจรู้สึกยุ่งยากกว่า
    • หากมีจุดประสงค์เพื่อการเรียนรู้หรือศึกษารูปแบบของภาษา OCaml อาจเหมาะกว่า
    • แต่ถ้าต้องการสร้างเว็บเซอร์วิสหรือ backend เชิงปฏิบัติ F# อาจเป็นตัวเลือกที่ดีกว่า
    • โดยเฉพาะในฐานะภาษาที่ผสานกับ .NET ได้ดีและยังคงสไตล์เชิงฟังก์ชันไว้ F# คือเครื่องมือที่ทรงพลังมาก

ความรู้สึกส่งท้าย

  • ผู้เขียนรู้สึกว่า F# เป็นภาษา ที่สนุกและใช้งานได้จริงมากกว่าที่คิดไว้มาก
    • เขาบอกว่าให้ความรู้สึกคล้ายตอนที่ได้เจอ Clojure ครั้งแรกในอดีต
    • โดยเฉพาะเมื่อนึกถึงว่า Clojure เคยเป็น Lisp ที่ใช้งานได้จริงที่สุด เพราะทำงานร่วมกับ Java ได้ยอดเยี่ยม
  • หาก .NET เป็นโอเพนซอร์สและพกพาได้ตั้งแต่แรก
    • ClojureCLR อาจได้รับความนิยมมากกว่าปัจจุบัน
    • และ ชุมชนกับ ecosystem ของ F# ก็น่าจะเติบโตมากกว่านี้ เช่นกัน
  • การที่ F# ไม่ได้เป็นโอเพนซอร์สจนถึงปี 2010 ก็เป็นสิ่งที่ ขัดขวางการยอมรับในช่วงแรก

"ความผิดพลาดครั้งใหญ่ที่สุดคือทั้ง .NET และ F# ไม่ได้เป็นโอเพนซอร์สในช่วงแรก และนั่นทำให้พลาดโอกาสไปมากมาย" – Don Syme

  • แม้ OCaml จะไม่ได้เรียนรู้ยาก แต่ สำหรับคนที่เพิ่งเริ่มกับภาษาตระกูล ML, F# อาจง่ายกว่า
    • อุปสรรคในการไปถึงขั้น production ก็ต่ำกว่า
  • โดยเฉพาะ นักพัฒนาที่มีประสบการณ์กับ .NET ควรลองสัมผัส F# อย่างยิ่ง
    • F# ไม่ได้เป็นเพียงภาษาที่ยอดเยี่ยมในตัวเองเท่านั้น แต่ยังเปิดโอกาสให้ใช้ ecosystem อันแข็งแกร่งของ .NET ได้ด้วย
  • ผ่านเครื่องมืออย่าง Fable สามารถทรานส์ไพล์โค้ด F# ไปเป็น JavaScript, Dart, Rust, Python เป็นต้นได้
  • ในชุมชน F# มีคำพูดว่า "F ใน F# หมายถึง Fun(ความสนุก)"
    • ผู้เขียนเองก็รู้สึกจากการได้ลองใช้จริงว่าคำนี้เป็นเรื่องจริง และย้ำว่า มันไม่เพียงสนุก แต่ยังใช้งานได้จริงอีกด้วย
  • ท้ายที่สุดยังกล่าวถึงความเสถียรและความน่าเชื่อถือของ F# ด้วยคำว่า "ถ้าคอมไพล์ผ่าน ส่วนใหญ่ก็มักจะทำงานได้ดี"

In sane type systems we trust!

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

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

 
GN⁺ 2025-04-03
ความคิดเห็นบน Hacker News

  • F# เป็นภาษาฟังก์ชันนัลที่ดีที่สุดตอนเขียนแอป Ruby on Rails ขึ้นมาใหม่

    • พิจารณา Haskell, Ocaml, Scala และ F#
    • แม้จะไม่คุ้นกับเทคโนโลยีของ Microsoft แต่ F# ก็กลายเป็นตัวเลือกแรก
    • Haskell นำมาใช้ได้ยากเพราะความเป็น pure ส่วน ecosystem ของ Ocaml ก็ยังไม่เพียงพอ
    • Scala ดูซับซ้อน
    • F# เริ่มต้นได้ง่าย และชุมชนก็เป็นมิตร ฉลาด และพร้อมช่วยเหลือ
    • มี ecosystem ที่ยอดเยี่ยมพร้อมการเข้าถึงไลบรารีของ dotnet
    • มีไลบรารีและเฟรมเวิร์กที่ยอดเยี่ยมอย่าง FsHttp ที่ทำงานร่วมกับ http server ได้ง่าย
    • WebSharper เป็นเว็บเฟรมเวิร์กที่ดีที่สุดในบรรดา ecosystem ทั้งหมด
    • เครื่องมือยังไม่อยู่ในสภาพที่ดีที่สุด แต่มีความหลงใหลในภาษานี้มาก

  • เคยลอง F# แต่ยังใหม่กับ ecosystem ของ .NET

    • ตกใจที่แค่ "hello world" ก็มีการสร้างไฟล์โปรเจกต์และ boilerplate จำนวนมาก
    • สนับสนุน FP, immutability และภาษาสมัยใหม่ แต่มีงานน้อย
    • มีแนวโน้มจะชอบภาษาที่ใช้กับ AI ได้ง่าย
    • ในอินเดียสถานการณ์แย่กว่านี้ แต่ใน EU ยังสามารถเลี้ยงชีพได้อย่างยั่งยืนด้วย Java/TypeScript
    • หางานที่ค่าตอบแทนดีด้วย Kotlin + TypeScript ได้ยาก

  • บริษัทของเราเปลี่ยนจาก C# มาเป็น F# เมื่อ 6 ปีก่อน

    • เปลี่ยนจากภาษาสไตล์ C มาได้ยาก แต่คุ้มค่า
    • คอมไพล์ช้าและไม่รองรับ hot reload
    • มีโอกาสใช้งานในเชิงอาชีพไม่มาก
    • การจ้างนักพัฒนาอาจเป็นเรื่องยาก

  • เหตุผลที่การยอมรับ F# ชะงักงันคือระบบ build ที่ไม่ดี

    • Rust เป็นภาษาที่ยอดเยี่ยม แต่ไม่เหมาะกับ problem domain จำนวนมาก
    • เหตุผลที่เลือก Rust คือระบบ build
    • แม้แต่ภาษาที่มีมูลนิธิไม่แสวงหากำไรและมีหลายบริษัทสนับสนุน ก็ยังมีระบบ build ที่แย่

  • เรียน F# ในปี 2013 และสนุกมาก

    • ประสบการณ์ผู้ใช้ไม่ดี
    • มีปัญหาเรื่อง naming convention, รูปแบบการเรียกฟังก์ชัน, ไวยากรณ์พื้นฐาน, ความสามารถของ type system และการรองรับ IDE
    • ย้ายไป Scala และรู้สึกว่ามีความสม่ำเสมอกว่า F#
    • F# เป็นภาษาฟังก์ชันนัลภาษาแรก และเปลี่ยนมุมมองต่อการเขียนโปรแกรม

  • F# เป็นกรณีหายากที่ผู้ใช้ทุกคนพึงพอใจมาก

    • คุ้นเคยกับ ecosystem ของ .NET อยู่แล้ว จึงน่าจะเรียนรู้ได้ง่าย
    • สงสัยว่า workflow แบบไหนจะได้ประโยชน์มากที่สุด

  • เมื่อ C# ได้รับความสามารถหลายอย่างของ F# ข้อดีของ F# ก็ลดลง

    • เขียนโค้ด C# เป็นสไตล์ฟังก์ชันนัลเป็นหลัก แต่มีข้อดีตรงที่ยังใช้ไลบรารีตามวิธีดั้งเดิมได้

  • มี SaaS ที่ทำกำไรได้และเขียนด้วย F# ทั้งหมด

    • 3dpack.ing
    • Rust ray tracer ที่เขียนด้วย F# และคอมไพล์เป็น WebAssembly
    • fable-raytracer

  • F# เป็นภาษาที่ยอดเยี่ยม

    • ต่อให้ไม่เขียนเลยสักบรรทัด ก็ยังเป็นภาษาตัวอย่างที่ยอดเยี่ยม
    • อ้างอิง fsharpforfunandprofit.com บ่อยมาก

  • F# สวยงาม แต่ใช้อย่างคล่องแคล่วยาก

    • รู้ C# แค่นิดหน่อย จึงเข้าใจแนวทางเชิงวัตถุของ F# ได้ยาก
    • เจอปัญหาเดียวกันใน Clojure และ Scala
    • ไม่อยากเรียน C# หรือ Java ก่อน