stevedoria.net

So, why Rust?

Ownership is Rust’s most unique feature and has deep implications for the rest of the language. It enables Rust to make memory safety guarantees without needing a garbage collector… (Klabnik)

Wedson Almeida Filho recommends adopting Rust for kernel development, declaring:

We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics.

Reading about Rust and its “ownership” concept reminded me of C++’s move semantics, which were introduced in C++ by ISO/IEC 14882:2011. It is possible to implement C++ code that mimics Rust’s ownership concept, but this requires skill and effort similar to implementing inheritance and polymorphism in C. Furthermore, C++ code can continue to be implemented without the ownership concept, which is proving to be an effective approach to resource management and addressing a huge class of security vulnerabilities. C++ tools do not enforce the ownership concept, leaving software implementers without active support from compilers for adopting that concept.

Ownership is a core feature of Rust. All Rust programs are implemented around ownership, and compilers are implemented to enforce consistency with ownership rules. Ownership can be borrowed and it can be passed around. When an owner goes out of scope, resources are released. Ownership of a resource and who is responsible for their release is enforced by Rust. Explicit invocation of free() or operator delete is avoided, and this reduces a class of security vulnerabilities that are embodied by stale pointers and memory exhaustion. Python’s with statement and C#’s using statement are not needed, allowing resource ownership to be ergonomically returned by a function to its callers. Rust’s compiler is capable of determining when resources are released and when resources are used after they are released. Rust’s tools enforce the ownership concept. Ownership and resource management are the cornerstone of the Rust programming language.

The Rust programming language allows for implementing performant software, which does not need a virtual machine, explicit release of resources, and garbage collection for resource management. Being performant and rivaling C’s proximity to the hardware, Rust is a fine addition to an embedded software engineer’s toolbox.

On the first day of the new year, I wrapped up the last few Kanji covered by WaniKani. My journey with WaniKani up until now has lasted at least 31 months, which is five months short of my third anniversary. In that time, I have been introduced to 2034 kanji and 6432 words.

In a little over seven months since my last write-up, I finished the last 25% of the WaniKani program. I think that without experiencing burnout, the WaniKani program can be completed in about 28 months by someone with full-time employment, and other responsibilities and interests. I do not remember taking a break from WaniKani, but I do remember how challenging levels 25 and 26 were for me. Maybe this was the time that many of the early items were being reviewed, and it was challenging to push through the levels because of the large amount of scheduled reviews for the earlier items and re-reviews of items missed.

My accuracy on the meaning and reading of kanji and words is around 85%. When working through the levels, I tried to keep close to 200 Apprentice items, but it had sometimes fluctuated to over 300 items when I made mistakes on Guru items. Mistakes on a spaced repetition system (SRS), such as WaniKani, are what drive the functionality and motivation of those systems. Items answered incorrectly are reviewed more frequently. Items answered correctly are reviewed less frequently after longer durations to reinforce recollection.

With 33 of 31 kanji needed to pass to the next level, the WaniKani dashboard shows that I would be on the 61st level, if such a level existed. There is still a good percentage of WaniKani content for me to review and Burn. One item that has stuck around since June 2021 is 名人, or “expert.” I have mistook the reading as みょうにん (“myounin”), みょうじん (“myoujin”), and めいにん (“meinin”). It is read めいじん (“meijin”). It is still a Guru item for me, so looking it up before my next review in two days is not cheating. ;)

I really appreciated the automated email messages that are sent out when a level is completed. They were like small celebrations of accomplishments. And, I looked forward to receiving them when I leveled up. I saved all of them, because they were encouraging and contained funny tidbits. I included the last of these emails to me below:

You just got to Level 60, Steve.

I don’t even have a gif deserving enough of your accomplishment.

Not many people get to this point, so what you did was really special.

I know this is an automatic email, but I’m seriously, actually really proud of what you’ve done.

I really hope it takes you places in life, work, or school. Knowledge truly is a powerful thing, and I hope you go out there and use it as much as you can. New doors are opening for you.

Speaking of which, it’s time to start thinking about leaving the WaniKani nest. You know how mother birds push their baby birds out of the tree to teach them how to fly, and sometimes they do but sometimes they don’t? That’s what needs to happen here. Although I’d love for you to use and pay for WaniKani forever, there’s a time where it’s better for you to go out into the real world, and that time is now. Feel free to finish this level and burn out previous items, but get out there and read Japanese! That’s why we’re doing this, after all.

Anyways, such a good job. You worked really hard. I know it’s tough. I’m really proud of what you’ve done, Steve.

Sincerely,
Koichi & the WaniKani Team

I am really proud of completing this program without third-party tools, aside from wkstats.com. WaniKani has helped build a solid foundation for me to continue with intermediate-level language textbooks and native content. As suggested by the above email, I will leave the WaniKani nest and graduate away from using it as my primary learning resource.

We, as software engineers, know full well that requirements change. Indeed, most of us realize that the requirements document is the most volatile document in the project. If our designs are failing due to the constant rain of changing requirements, it is our designs that are at fault. We must somehow find a way to make our designs resilient to such changes and protect them from rotting. (Martin 3-4)

I recently picked up a Raspberry Pi Zero W to gain familiarization with the Arm(R) architecture and instruction set. I could not wait for the Zero 2 W to become available, and the suggested price ($15) and compatibility of accessories for the current and future Zero boards helped me decide on the purchase. It has been more than ten years from my first Raspberry Pi purchase, but aside from different clock speeds, the processors between the Zero W Rev 1.1 and Model B Rev 2 are identical.

One personal goal for the purchase is developing assembly code that uses a vector instruction set, such as vfp or neon, and is called from C code. This represents a typical situation where a software system running on an Arm processor and is implemented in C but needs assembly to take advantage of specific processor features. A simple program implemented with two source files, sum.s and main.c, that uses C and assembly is presented here.

sum.s:

.cpu arm1176jzf-s
.fpu vfp
.syntax unified

.global sum
.type sum, "function"
.p2align 4
sum:
  add r0, r0, r1
  bx lr

main.c:

#include <stdio.h>

int sum(int a, int b);

int main()
{
  int i = 0;
  i = sum(5, 7);
  printf("%d\n", i);
}

The above source is compiled with the following command: gcc main.c sum.s

The sum function simply adds two input integers and returns the result to the caller. The main function calls the sum function with two constant integers and outputs the sum using printf.