In the heart of every software engineer, a wish to learn and master an open source tool that isn't centrally backed by anyone, but for the people and by the people, awaits for the moment to shine.

Have you ever felt that programming should be more elegant, more predictable, and less prone to errors? If so, you might have already explored the world of functional programming. I've witnessed the rise of various functional programming languages, each promising to solve the common problems we face in software development. Today, I want to focus on two contenders in this space: F# and Gleam.

Both languages offer powerful functional programming capabilities, but as we'll see, Gleam is emerging as a superior choice for developers seeking freedom, simplicity, and a bright future. Let's dive in and explore why Gleam is winning over F#.

The Origins: A Tale of Two Languages

F#: Born in the Corporate Halls

F# was initiated in 2002 at Microsoft Research in Cambridge as a response to the "object-oriented tidal wave" of the mid-1990s. The development of the core features of F# 1.0 happened from 2004–2007, followed by its "productization" by Microsoft in 2007–10 and the release of F# 2.0.

Since then, F# has evolved as an open source, cross-platform language with multiple delivery channels. It offers a range of features including object programming, quotations, statically resolved type parameters, active patterns, computation expressions, async, units-of-measure, and type providers.

Gleam: A Community-Driven Innovation

Gleam, on the other hand, is a newer, community-driven language. It's a statically typed functional language that compiles to both Erlang and JavaScript, making it ideal for building scalable, fault-tolerant applications. Born out of the desire for a type-safe language on the BEAM (Erlang Virtual Machine), Gleam combines the robustness of static typing with the concurrency and reliability of the Erlang ecosystem.

Think of it as the big brother of Elixir

Functional Programming: A Paradigm Shift

Before we go deeper into the comparison, let's take a moment to understand what functional programming is all about.

Functional programming is a unique approach to coding that emphasizes using functions and immutable data to write cleaner, more predictable code. It focuses on:

• Pure functions: Functions that always produce the same output for the same input and have no side effects
• Immutability: Once data is created, it cannot be changed
• First-class functions: Functions can be passed as arguments, returned from other functions, and assigned to variables
• Higher-order functions: Functions that take other functions as arguments or return them
• Recursion: Using functions that call themselves to perform iteration

The appeal of functional programming lies in its conciseness, predictability, parallelizability, and modularity. It offers a different way of thinking about problems, often leading to more elegant and maintainable solutions.

But here's the thing: the term "functional programming" often attracts developers looking for an alternative to object-oriented programming (OOP). They're seeking relief from the complexity, unpredictability, and maintenance challenges that can arise with OOP systems. Both F# and Gleam offer this alternative, but as we'll see, they do so in different ways.

The Alternatives: A Landscape of Functional Languages

Before we focus on our main contenders, let's briefly explore some other functional programming languages to get a better perspective.

Elixir: Almost Perfect, But…

Elixir is an incredibly cool language built on the Erlang VM. It offers exceptional concurrency, fault tolerance, and a developer-friendly syntax. But there's one thing missing: that TypeScript feeling of safety. Elixir is not typed and will never be, which can leave some developers feeling exposed to potential runtime errors that could have been caught at compile time.

Lisp: The Grandfather of Functional Programming

Lisp, with its iconic parentheses, is pretty cool yet somewhat esoteric. It's powerful and flexible, but good luck finding developers to work with or for you at a reasonable price. The learning curve is steep, and the job market is niche.

Haskell: Beautiful but Challenging

Haskell is absolutely elegant, a pure functional language with strong static typing and lazy evaluation. Yet it's poorly implemented in many ways and remains esoteric. Almost nobody uses it in production environments (with some notable exceptions). It's too damn hard for most developers, almost like you're writing a white paper instead of a program.

You can try these languages for a week or two. After the initial dopamine rush, you realize somehow that maybe, just maybe, you are wasting your time using something that nobody wants or that very few people find appealing.

F#: The Handsome Cousin of C#

F# is undeniably a beautiful language. With its fantastic syntax and logical constructs, it offers a compelling functional programming experience within the .NET ecosystem. Here are some of its strongest points:

• Seamless .NET integration: F# is a first-class citizen in the .NET ecosystem, allowing you to leverage existing .NET libraries and frameworks
• Strong type inference: F# can often determine types automatically, reducing verbosity while maintaining type safety
• Pattern matching: F# offers sophisticated pattern matching capabilities, making complex conditional logic more elegant and readable
• Async workflows: F# had built-in support for asynchronous programming before it was cool, with a clean and intuitive syntax

Let's look at a simple example of F# code to appreciate its elegance:

let rec fib n =
    match n with
    | 0 -> 0
    | 1 -> 1
    | _ -> fib (n - 1) + fib (n - 2)

// Example usage:
let result = fib 10
printfn "Fibonacci of 10 is: %d" result // Output: Fibonacci of 10 is: 55

This code demonstrates F#'s conciseness, pattern matching, and recursive functions. It's clean, readable, and expresses the algorithm clearly.

Yet, with F#, something feels off…

It's like every time you write a line of code, part of your soul is now bound to Microsoft. You rationalize yourself into believing it's all good, yet you know that the language you put so much faith in is nothing more than the fruit of a corporation such as Microsoft.

Flashbacks of evil Bill Gates come to you in your nightmares. You don't want to be attached to or dependent on something a big multinational company primarily backs. Deep down, you know it's just another way for them to draw you into the .NET ecosystem.

The problem with the F# community, as some have pointed out, is that they keep asking how to convince C# developers to use F#. This approach might not be the right way to grow the F# ecosystem. Most C# developers come from enterprise environments with values and practices that are generally at odds with open-source, functional languages.

Moreover, the interoperability between C# and F# isn't as seamless as advertised. Everything prefixed with FSharp is ugly, FSharpFunc can't implicitly convert to Func, FSharpOption evaluates to null for None (so you get none of the safety in C#), and FSharpAsync is really difficult to consume from C#. This necessitates building an interop layer, which often feels like needless effort.

Gleam: A New Hope

Then, a glimpse of hope comes. It appears to be a sun, but as it clears out, it is a star, with a joyful smile. Gleam has arrived.

Even its inception has more humble and noble origins than the cold, ruthless, corporate Java-like environment of Microsoft. Gleam gives you hope, faith in open source. Its dad, Rust, makes you feel even more comfortable. You know Rust is the language of the rebels, not wanting to be tied to any big backer with deep pockets. Gleam means a new hope.

Gleam offers:

• Simple constructs: Gleam's syntax is clean and straightforward, making it easy to learn and use
• Easy-to-understand documentation: The documentation is comprehensive, well-organized, and beginner-friendly
• Vibrant and active community: Despite being newer, Gleam has attracted an enthusiastic and helpful community
• BEAM compatibility: Running on the Erlang VM gives Gleam access to Erlang's powerful concurrency and distributed computing capabilities
• JavaScript compilation: Gleam can also compile to JavaScript, making it versatile for both server and client-side development

Let's look at a simple example of Gleam code:

import gleam/io

pub fn is_adult(age: Int) -> String {
  case age >= 18 {
    True -> "You are an adult."
    False -> "You are not an adult yet."
  }
}

pub fn main() {
  io.println(is_adult(20)) // Output: You are an adult.
  io.println(is_adult(10)) // Output: You are not an adult yet.
}

Notice the clean, expressive syntax and the strong type safety. The code is readable and the intent is clear.

One particularly exciting aspect of Gleam is how it can enhance existing Elixir codebases. Imagine you're working on a critical payment processing system in Elixir and need to ensure your core logic's absolute reliability and correctness. Despite Elixir's strengths, its dynamic typing sometimes leaves room for subtle bugs.

Gleam, as a statically typed language for the BEAM platform, promises to enhance your system's robustness. You can write your core business logic in Gleam while keeping the surrounding code in Elixir (somewhat akin to the idea of a "functional core, stateful shell"). This approach gives you the best of both worlds: Elixir's productivity and ecosystem combined with Gleam's type safety for critical components.

The Future: David vs. Goliath

Maybe Gleam is not as big and well-polished as F# as of today. But looking at this precious child gives you the hope that it could one day turn into a monster that could crush big corporate contenders such as F#, C# and even Go.

The beauty of Gleam is that it's not trying to convince developers of another language to switch. Instead, it's building its own identity, solving real problems, and attracting developers who value its approach and philosophy.

This reminds me of how Rust started small but has grown to challenge established languages in systems programming. Could Gleam do the same in the functional programming space?

Conclusion

In the battle between F# and Gleam, the winner depends on what you value most. If you're deeply embedded in the .NET ecosystem and value mature tooling and corporate backing, F# might still be your best bet.

But if you value freedom, community-driven development, and a language that's designed from the ground up for functional programming without corporate constraints, Gleam is the clear winner.

Stay true, Gleam, true to your path. In the hearts of the devs, you represent a future where programming is not just a job, but a craft - where languages are tools of expression, not corporate assets.

What do you think? Are you ready to give Gleam a try? Or are you sticking with F# for now? Let me know in the comments!

As developers, we often get attached to our tools and languages, because of the time we invest into mastering them. It's important to remain open to new approaches and technologies. Gleam represents an exciting new direction in functional programming, and I'm eager to see where it goes from here.

---

If you liked this content I’d appreciate an upvote or a comment. That helps me improve the quality of my posts as well as getting to know more about you, my dear reader.

Muchas gracias!

Follow me for more content like this.

X | PeakD | Rumble | YouTube | Linked In | GitHub | PayPal.me | Medium

Down below you can find other ways to tip my work.

BankTransfer: "710969000019398639", // CLABE
BAT: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
ETH: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875",
BTC: "33xxUWU5kjcPk1Kr9ucn9tQXd2DbQ1b9tE",
ADA: "addr1q9l3y73e82hhwfr49eu0fkjw34w9s406wnln7rk9m4ky5fag8akgnwf3y4r2uzqf00rw0pvsucql0pqkzag5n450facq8vwr5e",
DOT: "1rRDzfMLPi88RixTeVc2beA5h2Q3z1K1Uk3kqqyej7nWPNf",
DOGE: "DRph8GEwGccvBWCe4wEQsWsTvQvsEH4QKH",
DAI: "0x33CD7770d3235F97e5A8a96D5F21766DbB08c875"