It takes a long, long, long, long, long time…!
Last time I compiled a program I wrote was thirty years ago, using TurboC++ on MS-DOS.
This year I decided to start programming in Rust. The project I chose is boringtun, a userspace version of Wireguard written in Rust. Is it possible to recover the lost skills? Let’s find out.
I have been foolish enough to try to do this free-solo, just testing stuff and searching for answers online, here is what I learnt:
- You can’t start programming with just a compiler. You need a whole development environment and test environment. Setting up your environment may require almost as much learning as programming itself. This is something that you do “only once”, but is a steep hill to climb when you are a newbie, including an older newbie.
- Many necessary steps setting things are up are omitted in how-to instructions because they are considered way too obvious to mention. For example, before running
cargo install boringtun-cliyou have to install cargo AND download a local copy of the github repository. - Errors you get when making mistakes, that is often, range from useful, like “Command ‘cargo’ not found, but can be installed with: apt install cargo”, to not very informative, to downright misleading. This can be pretty frustrating.
- When searching for solutions, I now consider best practice to use search filters and look for recent answers first. Things get improved and fixed so fast, incompatibilities appear and disappear, workarounds become unnecessary, and solutions change, so you need to look for recent advice. This does not mean you will necessarily get the advice you need.
- While you may feel that there should be an easy answer for your problem, it may very well not be the case. With a combination of OS, cloud provider, location, budget, combination of technologies, and intent, it is not actually that rare to get into a rare situation.
- While you may think that you can repeat easily what you did, it is not true. If you want to save time, write down what you do, and what results you got from doing it. Don’t ever use “muscle memory” when you are as out of technical shape as me. Throwing a copy and pasted command may feel like using some else spell to get what you want. In reality, most of the time the command will only work properly when you know what you are doing. The key here is to be able to reproduce what has been successful in your environment.
- Understanding what you are doing has always 3 steps: Checking the current status of things, changing the status, checking the new status of things. Sadly most how-to instructions will only explain how to change the status. This leads to additional searches for solutions… I find it particularly annoying when changes in Linux need altogether different commands for checking status and changing status…
- It doesn’t matter how small you think a problem is. You can easily spend 4 hours trying to change the resolution of a remote desktop virtual monitor, or performing some other apparently minor fix.
- It is really, really, really hard to know how far along you are. So from the 100 percent of what you want, the last 8 hours represents a progress of 1 percent or 10 percent? When you are as ignorant as I was when I started, there is simply no way to know.
- When you are new to a subject, and there are many options available you can’t evaluate if the option is right for you … so go down the rabbit hole until you hit a wall and then go back and try another option, like a mouse in lab labyrinth. The problem is that you are blind to your requirements because you assume, mistakenly, that you want is what everyone wants.
- Example of labyrinth, summarized: I need a remote desktop in a virtual machine on the cloud, as I am going to install the IDE in the virtual machine and access it from everywhere. But, the resolution after I install the remote desktop solution is too small, I try to fix it but it does not work after many tries. But I try a different remote desktop from the one with resolution problems that is more compatible with the cloud provider solving the resolution issue, but it is too slow as it kills the shared CPU. But I can’t install the client in my work computer, so I need a remote desktop via browser option instead. Then I change to a more powerful virtual computer, and try and fail to install Google Chrome Remote Desktop, but the necessary higher spec is too expensive in monthly charges. So I drop everything I have done so far, and I install the IDE in my laptop instead. I still need a remote desktop, installing Google Chrome Remote Desktop just does not work. I comb through online advice and finally I give up when… I find DWService. Marvelous little program that just does the job. This, dear reader, is two weeks on and off of my life. Has it been a waste of time? I am not sure but it can certainly be expensive time wise just to find *what* you should be doing to get what you want, sometimes longer that actually getting it.
- I wish I could advice you to read error messages carefully, and chase every little one like a hound. But sometimes you try to fix every little error just to realize that what you have been trying to do shouldn’t be done at all, for the purposes that you are seeking. So sometimes it is better to fix every error, and sometimes is better just to give up and find an alternative. You have an idea and later find that is a stupid idea and there is a reason no one is doing that. It happened to me.
- I know this is hard to imagine for someone who has been in IT recently, but initially I had difficulties telling useful commands from text-to-be-replaced. It is embarrassing to admit but it took me some time to figure out what to do with the text in capitals in this command:
cargo build --bin boringtun-cli --release [--target $(TARGET_TRIPLE)] - Sometimes, after you solve a problem once, it “magically disappears” and does not come back. It is like there was a sensor in the system detecting your level of knowledge, and throwing an error only when you are not deserving.
- I wished there was a way, from the syntax, to tell commands that have a temporary effect, an effect for the duration of the session, a permanent effect, and the same or different effect depending on how many times you run the command. This would save millions of hours of learning of something that, in my humble opinion, shouldn’t have to be learnt.
In the next part I will explain my dev and test environments and how they are set up. I have not compiled anything yet with the IDE, hopefully tomorrow.
