Back

My desert island languages

Introduction

You're on a deserted, uninhabited island, with no internet but with a functioning laptop. You can only take 3 programming languages with you, what do you do? This totally realistic scenario is a little challenge I gave myself to evaluate what I like in a programming language, what features I want, what I definitely don't want, and what I'd use it for.

Since I don't like when articles take too long to answer their own premise, here are my picks:

  1. Rust as my favourite all-purpose language,
  2. Gleam as my backup, less complex all-purpose language,
  3. Lua for scripting.

There, with this out of the way, the rest of the article will essentially be a rant semi-rigorous analysis of all contenders I considered. But before that, let me start with some disclaimers. Taste in programming languages is very personal and, like everything in tech culture, very divisive. This post is not meant to be an attack on your favourite language, my tastes and choices are not a commentary on yours, and to cement that fact let me disclose that I know shockingly little about the theory of programming languages. If I met the perfect language in the street, I wouldn't even know. I'm a hobbyist, so my key criteria here are:

  • enjoyment: is it enjoyable for me to write code in this language?
  • beauty: there is a je-ne-sais-quoi about syntax that is purely esthetic and which can draw you in or out depending on your tastes.
  • ergonomics: does the language make your life easier?
  • performance: this isn't about raw performance but rather compared to similar languages/use cases.
  • ecosystem: this one is far from a deal breaker, but it's good to take into account.

General purpose language

This category is for the languages you can pretty much do anything with,1 from systems engineering to web development (frontend/backend) including data treatment, app creation, you name it. This is where the C++, Java, Go, Rust, TypeScript/JavaScript and Python of this world belong.

My pick: Rust

As I mentioned above, I chose Rust, and I already expanded in great detail what I love about it, so I'll keep this section rather short. There is a lot of hype about Rust, a lot of deserved frustration with how it's been shoved everywhere, every project needs to say "made with Rust" as a marketing ploy and somehow everything needs to be rewritten in Rust.

To be honest, the usual arguments used to sell Rust aren't really big factors for me. Yes memory safety is nice, but Go has shown garbage collection isn't a barrier to performance. Mostly, I enjoy how Rust mixes some key aspects of functional programming while keeping the "get things done" attitude of the C line of languages. Algebraic Data Types, error handling, options, iterators, these are all features I can hardly live without anymore.

The usual suspects

Contenders for this position are also the most popular languages, those which can actually get you employed. In no particular order,

  • Java: the enterprise darling, robust, performant, incredibly bureaucratic. Possibly the language I like the least. Writing Java gives me the same feeling as opening my Jira backlog, that of boredom and pain. If you love Java, congratulations, you may be superhuman.
  • C/C++: respect must be paid to these two languages which have shaped the programming landscape we have today. In the right hands, they can do anything. Alas, I'm not a software engineer, manual memory management is not something I signed up for, and I just never clicked with either of them. But in another timeline, I'd probably really like them.
  • Go: this is where I'm going to get flak. Go is by design incredibly boring and predictable. It makes for a perfect enterprise language: collaboration is seamless, code intent is usually clear and it brings high performance in a native binary but is still garbage collected. Yet somehow, I can't seem to love Go. I don't mind using Go at work, but I won't take it on an island with me.
  • Swift: Apple's homemade language, feels a lot like writing Rust (without lifetime and borrow checking). It's a pretty neat language to be honest, but it feels too tied to the Apple ecosystem so unless I'm spending all my time on the island writing macOS/iOS apps, I gotta pass.
  • Zig: Rust was often touted as the C++ successor, but Zig is the true C successor nowadays. It's a wonderful systems language, a great upgrade to C, has proven itself on large codebases (e.g. Ghostty, Bun before the rewrite to Rust) but for this role I just prefer Rust.

Some other languages I haven't tested yet but of which I obviously have preconceived opinions:

  • C#: I heard a lot of good about this, but the ecosystem is a bit too Microsoft-centred to me. Same flaw as Swift.
  • Kotlin, Scala: these two run on the JVM and improve on aspects of Java I don't like. I tried Kotlin briefly and liked it, and as a lover of functional programming, I like Scala in principle. But since I really don't like Java, I'm not sure if these improvements are enough. I would have to try them more.
  • Dart: Google's pet language, I quite like it, but my take is unless you're trying to develop a Flutter application, it's never going to be the best choice.

Honorable mentions:

  • Odin: I've heard a bit about this language, it's very low-level, but I like what I've seen. I still need to understand where it fits in the landscape.
  • Nim: A weird Python-like systems language you can somehow compile to C or JavaScript?! I mean, that's already a very interesting language. Didn't really get to use it much, and there are syntax things I'm a bit iffy about, but I'll keep an eye on it.

I'm keeping the higher-level languages for the next section, but TypeScript/JavaScript and Python could have also featured in this list.

High-level languages

Even if you are obsessed with Rust or C++, you probably don't want to reach for it for everything. When building a simple HTTP server or a basic CLI app, you don't always need to worry about memory management, or optimize data structures to the last byte. In Rust, this usually means adding .clone() everywhere and wrapping everything in Arc to avoid all the borrow checker inflexibility, but sometimes enough is enough and you should reach out for a more adapted language.

The obvious candidates

In this section, the size and quality of the ecosystem takes on a bigger role (no one wants to rewrite an HTTP server from scratch in Python). The logical choices here are

  • TypeScript/JavaScript: I used to loooove JavaScript, so JavaScript with types was like a dream come true. The ecosystem is huge and the language is surprisingly good once you get to know it, so it's easy to get productive.
  • Python: the king of data, there is a package for everything and anyone can understand what you did. But I work with Python every. single. day. I refuse to be trapped on an island with a Python codebase.

My pick: Gleam

So I chose Gleam, the new kid on the block of functional programming. I learnt OCaml at university, and worked a lot with the Wolfram language during my PhD, so I feel at home with Gleam. Gleam was literally built to make functional programming more accessible, and it does it wonderfully. I don't have the patience to dig into Haskell yet (perhaps I will one day), but with Gleam I can scratch that itch without popping a blood vessel. The Erlang runtime is also a great selling point. I don't pretend to fully understand why yet, but as with the JVM, the runtime manages a lot of the unpleasantness so you can have a performant language without having to micromanage it. A cool thing about Gleam is it compiles to both the BEAM/Erlang VM, but also to JavaScript (I know...) so you can do frontend/backend in one language. That's just cool.

Alternative FP languages:

  • OCaml: oof I love OCaml, it was my first taste of FP and I had a lot of fun with it. But OCaml's ecosystem is rough, the language is still too niche (sometimes, hype is useful, you get more momentum so more packages) so it's hard to get anything done really.
  • Elixir: another Erlang-based language, very similar to Gleam, but types were not a primary part of the design so I prefer Gleam.
  • Haskell: the academic language par excellence, Haskell is like the final boss of functional programming. I'm definitely not feeling there yet.
  • Roc: another friendly approach to FP, it just doesn't feel as cooked as Gleam yet, but I'll keep my eye on it!
  • Clojure: a Lisp dialect on the JVM. Not a great start for me. Clojure has a very good reputation (which I'm going to guess is earned), I just don't think it's for me.

I also wanted to consider the Wolfram language, but where do I even start. It's a proprietary language, it's pretty much fully tied to the ridiculously expensive Mathematica ecosystem and it has some very weird quirks when it comes to "all-purpose" programming. But for science and math, it's absolutely peerless. I've tried SymPy, SageMath, everything I could find, but Mathematica's approach remains, in my humble opinion, the best (and the fastest!).

Other contenders and honorable mentions

If we zoom out from FP, there are plenty of languages in this space which I passed on:

  • Julia: in theory, Julia is a Python-like lang specialized to science with a built-in JIT for near-native performance. In practice, Julia never really broke the ceiling and remained in Python's shadow for more than a decade.
  • Ruby: one of the most influential languages. You can do a lot with Ruby very quickly, it's like a more elegant Python. To me, it means it shares some of the aspects I'm less enthusiastic about (I don't like much dynamic typing anymore, give me a strict language any time of the day).

Honorable mentions:

  • Borgo: What did I just find? Rust meets Go, they fall in love, move in together, have a child called Borgo, which compiles to Go. I'm not sure if it's beautiful or a monstrosity yet, but it's something.
  • Grain: yet another "modern" FP approach. Still young though, and only compiles to WebAssembly. But otherwise I like what I saw.
  • Crystal: think "compiled static Ruby", because that's what it is. It ticks all my boxes (okay it's OOP but I'm not that difficult, it's not Java at least.)
  • Mojo: I keep hearing of this Mojo language. It is self-described as "The systems language for the AI era", which isn't exactly a mark of quality to me, but what I've seen of it looks interesting so I will, for once, reserve a hasty judgment for later.

Scripting languages

For my final language, I wanted something not too redundant with the previous two, with which you can already pretty much do whatever you want. So I thought a scripting language is what I'd be missing.

bash: the universal choice

In that space, the very obvious choice is bash (or really any POSIX-compliant shell). It's everywhere, everyone knows some of it, "when you ssh somewhere it's there" (I see that argument all the time but I never relate, I don't live on remote hosts.) The problem with bash is that it's a pure nightmare to write anything longer than 10 lines in it. Conditionals, loops, variables, everything is so ridiculously complex. I've written my fair share of it and I still routinely have to check a cheatsheet for basic language features.

My pick: Lua

That's why I picked Lua! It's a very well-known, very popular scripting language which I must shamefully admit I only discovered recently. I was aware of its existence (I had a brief Neovim period) but I didn't realize how amazing it was until I started using the agent harness Maki (rest easy, my only mention of LLMs today) whose plugin system is Neovim-inspired and therefore also in Lua.

I like it, it's so easy to read, yet so powerful and so lightweight. You can embed it pretty much anywhere, in any language, it's quite performant thanks to LuaJIT and you can even use it for your shell scripts!

Other contenders and honorable mentions

There are a few other candidates in that space:

  • Python, obviously, especially with uv run --script and inline dependencies! Python is nearly perfect for that role and in data it's often the best scripting language you can use for ad-hoc data analysis. But as usual Python's strength is also its weakness: it can do anything, so it doesn't really shine at anything (beyond its inexplicably large popularity.)
  • PowerShell is, I hear, a pretty decent scripting language, particularly for sysadmins. But beyond the Microsoft of it all, I find the syntax ugly as sin.
  • Ruby comes back here as a strong contender and I think it could have made the pick in this section honestly!
  • Perl is like the legacy scripting language par excellence. I never understood how it works, never got into it, I will probably not start on a desert island.

Honorable mention to Fish, which I use as my main shell and which I've enjoyed using to write functions and scripts. It's like a sane bash (but not POSIX compliant), you can't hate it really. Probably my second choice, just not that exciting compared to Lua I guess.

Other weird languages

I limited myself to 3 when it comes to the "programming" languages of this world, but there are plenty of other choices we can argue about if we extend the definition of languages.

Queries: SQL

It's undeniable that when it comes to queries, SQL has won. It's everywhere, it's the standard, we should just rename it "ISO-SQL" and be done with it.2 But my personal favourite is indubitably PRQL. It's mostly useful for analytical queries, which is what I work with every day, and brings the beauty of pipes to data operations in SQL. If you don't know it, try it immediately!

Configuration: TOML

I spent two hours the other day reading arguments about configuration languages. Here I'm on purpose not considering the serialization/deserialization part of the question (I don't care what the machine feels like when reading JSON, I care what I feel like writing JSON.)

I never really hated YAML that much (at least since the worst of it has been patched), so I was fine with it for a while. Especially compared to JSON which is just awful to edit by hand. But working with Helm has depressed me beyond words, and now I can say I hate declarative-YAML setups (looking at you GitHub Actions). At this point, just use a DSL...

When it comes to configurations, I think TOML hits the sweet spot, except that like many others I find the [table] v. [[table]] dichotomy confusing (I always have to check which one's for what).

Some takeaways

If you've read this far, congratulations. You'll probably have noticed I don't have many strong arguments for one language or another. Like I said before, this is all deeply personal, and the dirty little secret here is that every single language I mentioned on this page is still good at what it does and there is always someone, somewhere, who's using them with great satisfaction. So I'm not going to pretend there is a universal choice, these are just mine.

What this little exercise did was teach me what I like and what I don't like in a programming language:

  • I tend to prefer FP to OOP or pure C-style imperative style. I don't have a problem with the latter (as evidenced by Rust, and I like Python at work), but it doesn't always feel as satisfying.
  • I don't like boilerplate. At. All. That's like 90% of my LLM use (yes, I lied earlier, there's a second mention of them.) I just can't stand a ceremonious language like Java.
  • I have a weird thing against VM runtimes. That's weirdly my only gripe with Gleam, and it's probably stupid. But I just like having nicely compiled native binaries. Most scripting languages need an interpreter as well, so why make a difference with VMs? I don't know.
  • I can't live without monad-like error handling. Exceptions, whatever Go is doing, all these methods are just unpleasant to me now.
  • Give me strong static typing, now. I've written enough Python that I now hate working without built-in (as in not added as an afterthought) type checking. Rust is just pure joy here.

So, what are your deserted island languages?


  1. Some people may argue that with enough motivation, you can probably do anything with any Turing-complete language. That'd be true, but just because you can doesn't necessarily mean you should. At least, I probably won't. ↩︎

  2. But which flavor will it be... ↩︎