It depends on the things that you want to learn and amount of extra work you want to put into it. For instance, I used Go for the most of AoC 2018 problems and I had always been using C/C++ in algorithmic contests when execution time mattered. And yet, I wouldn't say I know any of these languages good enough to write a production-grade system because I only learned usage patterns common for small, write - run once - throw away applications.

On the other hand, the author of that post seems to have used a lot of more complex language features, did profiling, debugging, made use of many libraries etc - a lot of extra stuff that wasn't necessary to give correct answers but is crucial in 'real world' programming.

A long, long time ago, I used Haskell to reimplement the examples from Software Tools (https://crsr.net/Programming_Languages/SoftwareTools/). It was how I got over the How-do-I-write-real-code-in-Haskell hump.

I strongly recommend it.

I've been starting to learn Rust and found the post quite useful. I think the inherit constraints with these sorts of challenges allow for time to think of creative ways to use a language's fundamentals, rather than focusing too much on architecture. It forces learning through immersion, akin to being dropped in a foreign land without knowing the language.

It depends on your style of learning tbh. I enjoy going through a language's basics in docs (Golang playground and Rust's docs are fantastic) and then solving a problem.

My first "app" in Golang was a discord bot. I have to do maintenance on it occasionally and it's been a great learning experience.

I would say it depends on what you are trying to learn.

These types of problems will give you a good intro to a language, but won't introduce you to the more advanced libraries which you'll likely need in a professional context (e.g. threading/mutexs, tcp/udp, etc).

I think this kind of learning is great. One of the benefits of this type of exercise is that tackle certain types of problems that are not that common in day-to-day coding, and you do it over and over, so you become quite comfortable with areas that you might otherwise not use frequently.

Building larger projects is of course also a great way to learn!

I lean towards keeping to one kind of challenge at a time. If the problems wouldn't be hard in your favorite language, mostly, then this is a great way to exercise a new one. It's fun and you can learn more by checking other people's solutions afterwards.