Challenges for 2024

Looking Forward To Making Stuff
yearly review

January 23, 2024

Another year and another set of goals to work towards.

1. Learn A New Programming Language.

After some consideration, I decided it was time to learn a new programming language. Python is a wonderful language but at some point I need to branch out into others. While I have used other languages - C, Java, Javascript, R, etc - none of them were the kind of general language to build software projects out of. This begs the question: What is Python bad at? These are simple to answer: Speed and Multi-proccessing. So, kind of the same thing. If you’ve done and profiling - or read discussions about Python - this is where the language fails all the time. From the Global Interpreter Lock to code limited to Python only, this language does not scale very well. If I am going to pick a language then it should be: 1. A Compiled Language… 2. … with a focus on speed. 3. … with real multiprocessing support. 4. … that is also currently useful for real world projects.

Not Golang

Considering how popular this language is, it would be really safe bet to pick. It has plenty of jobs around, it is backed by Google, the language is intentionally built for both multi-proccessing and is supposed to be trying to replace C with respect to the speed of the language. For all accounts, this would be a top pick but I wont.

Firstly, I do not trust Google and am not looking forward to the internet detaching itself from this monster. Google has been behaving very poorly in a multitude of ways. At present, the current fight is them actively pushing anti-consumer anti-ad blocking updates into their Chrome browser. And, since this is the only real current browser - sorry Firefox; you’re just too small - this is simply not acceptable for the Internet. Helping them to continue the trend of dominating more and more of the Internet is a mistake I refuse to contribute to.

Secondly, it reminds to far too much of the C Programming language. My short time playing around with the language reminded me just how much I dislike C/C++ as a language. Sure, channels are nice but it’s still really just C at the end of the day. And, I have a strong dislike of that language. The updated standard for the C Language have been really nice but they’re still not as wide spread and it cannot simply remove the millions of lines of terrible C code spread around everywhere. I cannot expect Golang is going to be better in this regard - even with Google’s backing.

Third, Golang is opinionated in the ways I disagree with. Python has very strict rules about white space and readability so I have no problems with opinionated languages. Another would be Rust - which will come up later - which is strictly stubborn about scope in all the right ways. Golang is not. Golang inherits the annoying flexibility of C and imposes frustrating packaging expectations. Who in their right mind decided to enforce the expectation that your code will be on Github/Gitlab? Version control is fine but I definitely do not want it enforced on how I structure my code.

Not Rust

I read some books and played around with this language and I quite liked it. It is getting included in the Linux Kernel, it is very fast and many foundational linux utils are being re-written in the language. So, why not?

This language is very hard. Rust is a totally different monster compared to many other languages. It works hard to ensure that you do not bite yourself since the language is intended to for Multi-proccessing first. And, these kind of problems are simply hard to keep track of by their nature. This makes the language not accessible for simple scripts or as a daily driver language. If you are using Rust then you’re dedicated to using Rust. Frankly, I do not have the kinds of problems the language focuses on. And, the wall to basic programs is simply too high to be practical for a general purpose language. This is a strong contender on the list but I decided against it.

Not Zig

Likely, you do not even know Zig exists; that is already a problem. Zig is a language intended to also replace the C Programming language which also includes the ability to compile C code into Zig and include it in the projects. If you are already a C programmer then this is very attractive. Imagine including all the libraries you already know along with building in a new language with its own added values. So, why not?

Firstly, it’s just too much like C. This is probably a theme at this point but reading C code makes me hate life. It is just that painful to read coming from Python and anything that looks like it is pain. Zig looks like a better, cleaner language but that is it. I also do not need backwards compatability with anything C so the primary utility is largely useless.

Second, the language is so new that much of the normal infrastructure around it - packaging, unit testing, users - is small enough that finding help is going to be a problem. And, much of those people are going to be the same people working in C - and I would like to avoid them as much as possible. Again, if you already know C then all this is under your finger tips again - and it is not for me.


This is ended up being my choice. The language has everything I want: scales amazing, has multiprocessing built in, and is currently used for real world projects. The language is also very nice to read if you have ever looked at Elixir code. You can build basic programs from it without much trouble even though it is a functional programming language. It is also novel so I wont be having C flash backs while trying to solve problems. The language is also well developed with a solid core libraries along with an extended library of useful packages. Building packages for the language is surprisingly simple too.

2. Replace Goodreads.

As a semi-avid reader and long time user of Goodreads, this site is awful. The site was fine for most of what it was used for: a place to record books and share what books you are currently reading with your friends. Small things like adding the books you are reading can no longer be done. Recently, the ability to update book progress via the website literally did not work for almost a week. As a project, I think I am going to try to replace the site with my own solution instead. I have had some ideas about features which I think should exist and that Amazon has simply failed to implement. So, I’m going to go through the whole design process - probably using Elixir - to plan out and build the site.

3. Video Game

I have wanted to design and build my own video game for some time. In fact, I have eluded to attempts a few times. One way or another, something always comes up to derail the projects. But, I have been watching some lectures online about building a game with Entitiy Component Systems from scratch and this should be small enough that even I can do this alone. The class final project is to make a game which lines up with my own goals. With consideration to the game, I am admittedly undecided. Whether this will be a Tower Defense game or a simpler version of Vampire Survives I cannot say yet. Each time I think about what I would like to work on, I find myself falling into a new game pitch. Once the foundational tools are in place though I’ll be forced to make a decision. While there is a post on here about trying to build a potential 2D competitor to Dead By Daylight, there are now games coming out which I think do a better job than I could as a solo developer and will therefore need to abandon that project.

4. 100 Days of Code.

Tying into the previous challenges, starting in February I will be participating in the 100 Days of Code challenge to attempt to enforce the habit of writing code. Sadly, I spend more time learning than coding which has been a mistake made over the years - a habit which has grown worse with time. The abundance of information and interesting projects has continually put me on the wheel of watching and reading instead of application. This is such a large change from when I coded every single example from Programming Python as I worked through it; and, this is just as applicable to the Machine Learning work I have done. While I have built some models and written a good number of dashboards, this is no where near as many as I could or should have done at this point.

All my learning with Elixir, the Goodreads project, the gaming project are going to be public in the repo as should be expected of the challenge and should help break the habit of only learning. Frankly, I have already finished most of the lectures and I finished reading Tidy Modeling With R by Max Kuhn and Julia Silge so next month is an apply month only.

5. Writings

Which leads into the final challenge: Documentation. Namely, all the projects I work on will be converted to blog posts. All the projects I have worked on already will be getting their own posts. All the little explorations should be thrown up for anyone to read. As someone who also likes the idea of publishing failures, even the ideas that did not work should end up for all to see. This only saves others time not repeating the same mistakes as me. And, if nothing else, writing should help guide others away from falling into the same holes so lets get those posts online! I’m going to add Book Reviews as well for non-fiction books worth reading; I have quite a stack of them for this year and am already making good progress through them.