What is your go-to project for learning a new language?

Normally, I try to do the first 5-10 days of a previous advent of code to pick up a lang

That's exactly what I was coming here to suggest :)

@hpr's suggestion of writing something you actually want to use is the other big one. For me, writing a couple of projects I actually use every day is the main reason I was able to learn Zig.

https://codegolf.stackexchange.com/questions/33172/american-gothic-in-the-palette-of-mona-lisa-rearrange-the-pixels

Take pixels from picture A and try to use them to create picture B.

It deals with file IO, arrays, heavy math comparisons, I have a local server set up to animate my output so it involves web calls, and I try new ways to solve the problem each time because there is no "correct" solution.

Hm, I haven't gotten around to properly doing this apart from my day job, but depending on language you could also throw in Project Euler for algorithmic stuff, something like ToDoMVC for frontend-focused languages or generally some kind of "code katas" used to be big too.

All these toy things aside, I believe the actual best thing would be something you actually want to have or use, which would provide additional motivation as well as actual "requirements" or fun ideas to work on.

Maybe a little game, as well.

I tend to do something I am fairly familiar with domain wise. Learning F# a while back I did a parser for Swedish accounting data using parser combinations via fparsec. I hadn't done much with parser combinations before, but I knew the file format fairly well. Other times I build a lisp :) getting a basic interpreter is fairly straightforward (the book SICP is a good reference manual for this).

Contrary to other people's recommendation I would avoid building something I actually want to use. I want a certain level of mastery and understanding of the tool (language) before doing anything "serious" with it. YMMV.

There is a 1978 book called Etudes for Programmers (overview here, but you can find a full PDF pretty easily) that has a bunch of problems that most software developers think they can solve, but that most software developers have never actually sat down and solved. Things like simulating Conway's Game of Life, or a basic accounting system, or the AI for a simple board game.

I've only done a few of them, but they feel more satisfying than some of the Advent of Code/Project Euler puzzles, although I enjoy those quite a bit as well.

Not sure how generalizable this is, but I started learning Rust by going through Ray Tracing in One Weekend and translating as I go. It looks like someone's published a version for Rust specifically, but I actually found a lot of value in having to translate myself.

It's a good blend of not having to worry too much about the project/structure (as it's all planned out for you) but still forcing you to identify the goals and learn what language tools to apply.

Snake.

It's a simple thing but it requires some level of output, and understanding what options a coding language has for user interface is something that I feel too many coders gloss over.

"oh we'll just dump to the console" or "tie to your interface here" or whatever. Given how many ways there are to interact with the user these days and the initial "do you want what is essentially a web app" starting point, I NEED something that helps me test that so I can figure out what my real options are.

Obviously most everything these days has some way of at least connecting to JS, but even that can vary wildly.

I usually write a cli file deduplication program, i.e. finding files on disk that has the same content but not necessarily the same name. It's a bit of different data structures, standard library usage, error handling, string formatting and printing. Sometimes there's some dependency management as well if the hashing implementations are not part of the the standard library as well. At it's easiest it's pretty simple, but you can of course make it as complicated as you want as with any program.

IRC Bot. It's surprising how many languages make it nearly impossible :)

You need to have at the very least:

• A constant open TCP connection, modern servers require TLS/SSL too.
• A way to listen to PING messages from that connection and reply PONG or the server will kick you out for being idle (some kind of threading or event-based system)
• Sane way to parse strings

Then you can start adding stuff like logging (writing to files or sqlite), module support (calling plugins, hot-reloading them in some way), configuration (read config from a file or something else), support for multiple networks (need to have 2+ constant TCP connections and an ability tell which is which)...

And from that you can either go more on the bot side or start turning it into a client. Or go fancy and make the same core work for Discord and Telegram.

I pretty much exclusively want to make command line interface/text user interface apps, so my first thing to do to try to shake out any language is to attempt to find how it handles console-based input an output.

So far other than a couple of libraries in python, I’ve been very disappointed by how little modern programming languages tend to support the CLI. Many of them do have some sort of very lightweight I/O, but if you’re looking for things like proper ANSI codes or anything like that, best to just stick with things like Python. Sad thing is, I really don’t care for Python. My preference tends to go towards functional languages like Haskell and LISP, and procedural languages like Odin, and Go.

(I guess technically there are some good ones for JavaScript, but I hate node with a burning passion, I can’t figure out deno, and to be honest, I just don’t much care for either JavaScript or TypeScript.)

(Edit to fix Io -> I/O, this comment.)

When I want to "test drive" a language to see if I want to go any further with it, I'll write a ROT13 program. It includes a lot of the things I need to do on a daily basis, including text handling, file I/O, string manipulation, command-line handling, and simple data structures.

Usually, I'll start with a hard-coded string and expand from there, moving on to add handling text passed on the command line, a flag to open a file instead, and a flag to change the rotation number. Once I've done all that, if I'm not grinding my teeth, I'll start implementing something else and see how it goes.

A bit of a tangent, the biggest challenge I usually have with lisps is importing or programmatically referencing other files.

I don't enjoy anything that has to do with rendering, and prefer more utilitarian 'first' cases. So Conways Tree of Life and Snake are out.

What I do really enjoy is writing a CLI parser with a defined setup (usually using an array of objects, or similar) of commands, parsing them, and giving results.

Setting up a system to take --flags, long or -s (short), defining type information such as Path, String, Bool, etc. Setting required flags. But, in an easy defined way, not in a way that requires macros, or CLI parsing.

That way when I start a project I can create something like this (natively in the language, not using this problematic psuedocode):

[ 
    Command: {
        name: "run"
        short: "r"
        required: false
        desc: "runs something"
        handler: thingtoRun()
    },
    Command: {
        name: "echo"
        short: "e"
        required: true
        desc: "prints a statement to stdout"
        args: {
            Arg: {
                name: "statement"
                required: true
                type: String
                inherent: true
            } 
        }
        handler: echo_fn(args.Arg["statement"])
    }
]

fn echo_fn(statement: String) {
    print(statement)
}

> program echo --statement "Hello World!"

Hello World! 

> program e "Hello World!"

Hello World! 

> program echo

echo requires a 'statement'! 

> program --help

run :: runs something 
   no arguments needed 
echo :: prints a statement to stdout 
   --statement: required

This makes it easy to understand types of the language, set flags, set required flags, easy to debug/experiment in the future. It basically becomes the entire 'core' of any of my programs, even if the user never sees it, and it allows for an excellent way to get instant results and learn the language since you have to learn how to parse given data on the command line, and then have it execute other functions. It's fun!

You're essentially needing to figure out a way to read arguments from the command line, and then write an entire generic parser, and then is infinitely changeable, reusable, and you can re-implement in every project going forward (bonus points if you can use direct documentation comments to be included in your help message!). You can then build additionally scaffolding so you can build subcommands, different types, different results, etc. It's a great starting point that usually gives instant response as you are building, something important when you are first starting out in a new language so you don't end up being discouraged.

Edit: Fix my unuseable pseudocode to be more believable? understandable? correct?

My "Hello World" set of projects:

• Tic Tac Toe
• Battleship (sometimes with multiplayer if I expect to work with network later)
• Minesweeper
• Wordle

All this projects works perfectly in terminal, so CLI-first is a huge benefit to test apps without the need of complex UI, even in REPL environments. Also, games are fun to make.