It's an AMI Rowe R-88 if you'd like to see it.
You can learn a ton just trying to do a production grade home assistant deployment - move on to SSL termination at the load balancer with letsencrypt, try different deployment strategies for upgrading the server with zero down time, write custom extensions... etc etc.
I've now got a small Pi cluster running k8s to deliver a bunch of services at home, and its all really easy to maintain. I've absolutely used the skills and knowledge gained in my day job too, which is nice. Home Assistant is great to learn a lot of production web app stuff, all you need to get started is as little as the PC you already own, or something like a Pi to host it. As it can solve problems in your actual life, it's rewarding enough to be interesting I've found.
https://en.wikipedia.org/wiki/Reverse_proxy
If you use LetsEncrypt's DNS-01 challenge to setup the SSL automatically, you can even deploy valid working SSL for IPs in the private range (192.168.x.x, 10.x.x.x etc etc), allowing auto-deployment of SSL for private services on your LAN, not just publicly accessible/exposed IPs. You can get around port forwarding during initial letsencrypt setup with this too, as all happens via DNS providers public APIs.
> https://letsencrypt.org/docs/challenge-types/#dns-01-challen...
Caddy is really easy to deploy as a Docker instance as well. There are many, many ways to accomplish LetsEncyrypt with HA though! It's really just an example of a common generic reverse proxy problem - searching for "reverse proxy letsencrypt" will show you many other ways to do it too. If you are using Docker to host your services at small scale, there are some really clever options now that auto-configure Caddy and SSL via letsencrypt all just using docker compose:
Do you find that there are functions that are unique to k8s for a selfhoster that demand a system with that kind of overhead?
Of course you don't need that k8s cluster and of course you shouldn't really use pis. But it'll be fun. You could also just use 10 vms running on your computer and each vm is one node in the k8s cluster if you don't want to buy hardware. Then you see what happens when "hardware failure" occurs. I.e. you kill a vm without shutting it down properly. Or yank the power on one of the pis.
The point is, once you need it for a real project now you know how it works and when to actually use it and when not to. Heck all the stuff I set up on my single old 200MHz system, no vms nothing taught me basically everything I needed to become an actual sys/network admin later.
I'm reasonably sure that being able to talk about my home k3s-on-pi's cluster was a positive factor in getting my latest job :)
I think you've read the op's question too fast and not fully empathized with his situation. He already found a problem when he wrote, "I have a clear idea in mind with some code already in C++ to proof-of-concept it for myself,
The bulk of op's words surrounding that goal is asking about the process of coding being fun. But then we get several (well-meaning) advice to just focus on the end goal being fun rather than the coding process being fun. Yes, that's a valid perspective -- but a lot of people also require the process itself to be fun too.
E.g. Let's say a programmer wants to code a custom music library manager:
- John wants to use Lisp because having a REPL for quick iteration and feedback loop is "more fun".
- Jane would rather use Python because having a bunch of 3rd-party libraries for lots of tasks is "more fun" than coding a lot of boring low-level tasks from scratch.
Advising people to have a sort of zen enlightenment of only caring about the final product and being totally detached from the process is unrealistic for many programmers. It's a perspective that may work for you but for many others, the particular tools do matter in terms of joy.
In the op's case, he wished that there was a tool that was cross-platform, with easy multi-threading, no incidental complexity, etc. (To answer op's question, there isn't such a tool that meets all requirements.)
We often see a variation of the lament: "I wish programmers would quit focusing on particular programming languages. They're all Turing Complete. Just pick one and get on with it."
That's true if the product is corporate project. In that case, the employee needs to suck it up and just use whatever (not-so-fun) programming tool to get the job done. But personal projects like the op's question can try to look for alternative coding environments that are more fun to use.
An analogy in woodworking was illustrated by 2 different shows on PBS:
- Norm Abrams (The New Yankee Workshop) used power tools to build his projects.
- Roy Underhill (The Woodwright's Shop) used hand tools to build his projects.
Roy Underhill likes hand tools because power tools are noisy. On the other hand, Norm Abrams uses power tools as it's fast. Neither are wrong. Both can craft a chair but the tools still matter.
A lot of woodworkers can't just detach themselves from the usage of tools and only focus on the final product. The choice and use of particular tools is a core part of the joy.
I've had a long time dream of getting a broken jukebox and gutting it for a Raspberry Pi, but keeping the external interface in tact. I know next to nothing about hardware engineering, and can't write more than ten lines of Python without needing to Google something, but I finally got a broken juke in need of fixing, a multimeter, and a hard drive full of music ready to go. The fun isn't the Python or learning GPIO, it's that eventually I will have a cool retro jukebox with hardware and software I wrote in my basement.