What is the #12in23 challenge?

Exercism released a new challenge called #12in23, where the goal is to try 12 programming languages in 2023, one each month.

You can read Exercism’s official announcement here:

Trying a new language in the context of this challenge means doing at least 5 Exercism’s exercises in that language.

I’ll be participating in this challenge. This blog post is how I plan to tackle it, which languages I’ll be trying and some context on why I’m trying them.

Defining “trying a language”

The first time I read the challenge, it seemed a bit daunting to try a language each month. But a key takeaway is that there is no restrictions on the language you should try. One can dedicate some months to languages they already know well, and this is exactly what I’ll be doing. In the context of this challenge, I’ll define “trying a language” as either trying a completely new language or getting more practice on languages I already know.

The spirit of the challenge is of course to also try completely new languages, and I’ll also be doing that.

Changing the “one language each month” rule

Before taking on this challlenge, I had some hand-wavy plans for the languages and things I’d like to learn for the upcoming months. To better integrate this challenge with the plans I had, I’ll have to relax the “one language each month” rule in 3 key ways:

  • There are some languages/frameworks that are top of mind, and confining them to a single month is not enough. These are languages and frameworks that I’ll need to practice, learn and improve all year in some form or another.
  • There are some languages that I know well - dedicating an entire month to just one of them is not needed. For these languages, I’ll group several of them into a single month, or I’ll try to combine it with some new language each month.
  • I’m expecting to really like some of the new languages I’ll try! For this reason, I might continue working on them even after the month dedicated to that language has passed.

All-year languages/frameworks

Top of mind this year is to practice Rust and React. I’ll be practicing Rust and React all year, regardless of what language(s) I decide to slot each month.

Rust is known for having a steep learning curve, and as someone who tried Rust before, I can attest to that. A single month to practice Rust is not enough, as there’s a lot to learn and practice. I’ll need to be thinking of it all year.

React is a framework I’ll also need to practice and get better at all year, so wouldn’t make sense to confine it to a single month.

There also languages that are part of my work or that I use in personal projects. This are languages like Kotlin, Typescript, Python, Go and Ruby. I expect these to appear all year too.

The plan

Time to plan the languages for each month!

When making this plan, I considered both languages that I already know well and new languages to try.

The reason I included some of the languages I already have some experience in some months, is simply because I don’t really feel fleunt in them, and I’d like to improve that.

When choosing new languages to try I looked for languages that:

  • Teach me something new about programming or introduce me a new concept 1
  • Give me new tools to solve problems
  • Are fun!

How I will try out these languages

At a base level, “trying out” a language to me means doing some exercises on the Exercism track. When learning a new language, I also look for small projects I can do using that language to complement Exercism. That will also be the case here.

Immediately discarded languages

When thinking about the languages to try for each month, there are some languages that I immediately discarded.

I did this because either I don’t think trying them out will add much value or I don’t see myself starting projects using it or I simply don’t find them interesting. Most of the time it’s a mix of these factors.

This includes languages like Perl, Prolog, Fortran, and some esoteric languages.

January - Javascript and Typescript

Last month I read JavaScript: The Definitive Guide by David Flanagan. In the meantime, I also started reading Programming Typescript by Boris Cherny and started a React course.

I’ll use January to get more practice on Javascript and Typescript, which complement my goals of also getting better at React this year.

February - Java and Kotlin

Java and Kotlin are languages that I’m familiar with and already wrote code in them, especially Java. I want to practice more Kotlin and really get to know the language better. For Java, I want to keep up with new features added since I last used it.

March - Ruby

I did some Ruby before, but I consider myself still a newbie. I came across some projects where I had to read some Ruby and I felt more knowledge would help a long way. My interest in Ruby will be primarily to be able to know how to read Ruby and use Ruby tooling.

April - WebAssembly (text format)

WebAssembly is mainly a target compilation for some other language. This means that often you want to write code in some language and tell it to compile to WebAssembly binary.

However, there is a format that represents textually the WebAssembly binary instructions, the WebAssembly text format. Exercism has a track where you can practice writting this text format.

One of the reasons I want to learn Rust this year is to play more with WebAssembly and use WebAssembly as a target compilation for Rust. This means I won’t have to deal with the binary or text representation of WebAssembly that often, but I still think there’s value in learning it as a way to know more about how WebAssembly works internally. The text format is also used in debugging and other tools to inspect and visualize the binary files WebAssembly produces, so at least being able to read it can be useful.

May - Julia

Julia is a very interesting language to me, since it seems to combine the “scripting feel” of Python, with all the advantages of other static-typed OOP languages.

If I end up liking Julia, I can see myself writing some of my scripts in Julia instead of Python.

June - Lua

A lot of tools use Lua as its scripting language and more advanced uses of those tools require knowing Lua.

My main motivation to learn it will be to dig a bit more on those advanced cases.

July - Ballerina

I don’t know a lot about Ballerina, but looks interesting. It seems to be very different from all the languages I’ve tried before, which tells me I’ll probably learn a lot from trying it.

Exercism recently added a Ballerina track and this will be a great time to check it out.

August - Nim

At first glance, a lot of the reasons to learn Julia are also valid for learning Nim. Nim is able to compile native executables, which is something I like to see in statically compiled languages.

Nim also claims to have a macro system that allows for direct manipulation of the AST, which looks interesting.

Other than that, a lot of things in Nim are also things I like in Go and for that reason alone I think I’ll like Nim!

September - PHP

My interest in PHP is mostly to be able to better be able to read it and work with its tooling.

Some pieces of software still use PHP and I run some of those on my server, so more PHP knowledge is always welcome.

October - Zig

The reasons for trying Zig are similar to Nim, but Zig also has support for compile time function calls? Sounds crazy and I love it, let’s give it a go.

November - Red

Looks very different from other languages and might be a good opportunity to try something really new. Might be a good tool to quickly build some visualizations.

December - Rust

Like mentioned previously, the plan is to use Rust all year. The goal by December is to do Advent of Code in Rust. I’ll use December to also finish up the Rust Exercism track if there’s something to complete there.

Honorable mentions

This is a quick list of languages that almost made the list and I seriously considered including them, but for some reason or another didn’t make it:

  • V

    I love Go, and V seems to be a spiritual sucessor to Go. However, I don’t think I’ll gain much in learning V if I can just use Go. Some of the “problems” of Go that V tries to solve seem to also be solved by other languages included in my list, which makes the argument for learning V even weaker.

  • Elixir

    Last year, Exercism organized an Elixir cohort for learning Elixir, in which I took part. I did some Elixir there and loved it. However, if I’m being realistic, I don’t see me working on an Elixir project this year, so I don’t think there’s value in me exploring Elixir further, at least for now. I almost included it though, and it’s for sure the language I feel the worst for not being included.

  • C#

    I want to dig deeper into the whole .NET ecosystem, but considering everything else I also want to learn, C# is just not a priority right now.


  1. Last year I had a blast trying Unison and it’s a perfect example of this. Unison asks “what if all your source code is just a database with the ASTs?”. The insights I got from experimenting this way of programming stuck with me. ↩︎