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#.
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, 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
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:
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.
Before we focus on our main contenders, let's briefly explore some other functional programming languages to get a better perspective.
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, 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 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# 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:
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.
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:
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.
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?
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"