Wed, 03 Jun 2026 07:39:11 -0500The Month of Zig - Day Three

I'm going to attempt to write a port of Jet, a journaling tool I use daily that I've written and re-written in several languages.  It requires little more than terminal and file I/O, and it's usually realized in less than 50 lines of code.

The first thing I need to do is figure out how to get input from the terminal.  I found an example of this in zig.guide, but  Weirdly it doesn't work so I guess it's time to reach for the standard lib docs.

Hmm... seems I'm too green to glean what I need from this.

I did some web searches to find an example and they were all over the place.  I learned that the reason the example in zig.guide doesn't work is that a chunk of the standard library (std.fs.File) was just removed in the current version of Zig (although I can find no explanation as to why).  I suppose that's to be expected in something that is still in it's sub-v1 stage but still... 

It's easy to get discouraged at this stage.  The tension of the feeling like you're trying to do something trivial against having a not-even-tenuous grasp of what you are working with is a very uncomfortable feeling and often enough to make you abandon your beliefs and ambitions and send you running-back to something comfortable.  This is especially hard for me because I don't often find myself in this situation (probably because I'm very good at "cultivating naivete"), so when it does happen to me, it's debilitating.

For example, right now my brain is coming-up with lots of justifications for giving-up on Zig and falling-back to what I know to write a new language or something equally asymmetric to my goal of breaking-free of AI-poisoned languages by learning the only one that both exists and is committed to rejecting AI.

To counter this I'm trying to remember what it was like to push-through this feeling before.  I start with thinking about similar contexts; other programming languages I've learned.  

For many there's no equivalent.  BASIC, Hyperscript, Dylan, VBscript, Javascript, PHP, Python, Lua all these were trivial to learn incrementally, even in the case of BASIC which I learned before I knew how to program at all.  

What about assembly, the first "language" I learned after BASIC?  Honestly I'm not sure I ever "learned assembly" as much as I learned what I needed of the instruction set of the various CPU's I've written assembly for.  I don't think I've ever written an entire stand-alone program in assembly, just the parts that demanded maximum performance or a feature of the CPU I couldn't reach from the higher-level programming language I was working in at the time.

The next language I learned was C and C++.  I first learned C using Borland Turbo C++ for DOS, and C is well-equipped for doing terminal input/output so here again it was fairly easy to get started writing programs like the ones I wrote in BASIC.  C is very procedural, so it was not hard to "get productive" using the same sort of programming I learned in BASIC, and once I understood that functions were similar to BASIC's subroutines, I was off to the races.  The main thing I got hung-up on were pointers (doesn't everyone?), but once I really understood they were just addresses I thought about them the way I thought about memory when working in assembly and I did fine.  C++ on the other hand, I don't think I really learned it at the time, it wasn't until I was working with graphical environments that I really felt the need for something like C++ so to the extend that I dabbled in classes, etc. was very rudimentary when I was writing my own projects in C every day.

From there most of the "language learning" I did next was really learning about their libraries/toolkits/etc.  Objective-C, C#, Java, most of the work was remembering what library the thing you wanted to do lived in and which of the several similar functions/classes/objects you should use.  I suppose I have to mention Visual Basic here but again there wasn't a lot about the language itself to learn.

SQL, hmm... learning that might apply to my current condition.  Rudimentary SQL ("SELECT * FROM PUBS"*) is trivial but really understanding how SQL works and how to write it in ways that make the most of it is very different from the types of programming I had done up to this point.  I was "productive" in SQL long before I really knew what I was doing, and it wasn't until I spent a week in a SQL class with a bunch of Oracle DBA's being forced to switch to MS SQL Server that it really sunk-in.  Thinking-back to climbing that mountain, the fundamental shift of understanding was a much bigger jump than what I'm tackling now with Zig.  The challenge with Zig isn't a fundamental thing like SQL (it's still a procedural language) but more so just the verbosity and breadth of knowledge needed to do what seem to me like basic things.

So how did I cross the Rubicon with SQL?

I'm not really sure.  I don't remember having any pressure to do so (I wasn't trying to solve a problem or meet a customer's need), and I'm not sure I was particularly driven by curiosity (I was more focused on the things I was building than what I was building them out of at the time).  I guess it could have been immersion, I was taking a class in Chicago with people I didn't know in a town I wasn't familiar with, so I spent all day with the material and had nothing to do at night so I experimented with what I learned each day for hours.  I didn't know anybody, but the instructor and everyone in the class was already very familiar with using the SQL language in far-more-complex ways than I ever had (or probably ever will), so every conversation was with an expert.

This sort of classroom-oriented, institutional way of learning is something that normally never works for me, but in this one case it was very effective.  I returned from that training with a completely different way of looking at and working with SQL, and this informed my work with other languages and tools as well.  In fact it's probably what helped me understand other languages and forms of logic that have the same sort of immediate/parallel execution that SQL has running on an RDBMS.

What I'm bumping-up against in Zig is nothing like the shift I needed to undergo to understand SQL, so I don't know that a week of deep immersion is necessary (although given the condition my brain is in now, maybe?) but reflecting on what it took to gain that understanding of SQL puts what I'm struggling with now into perspective and makes it feel a lot less overwhelming.  In this light, I think what I need to do is simply accept that what it takes to read and write input from a person at the console in Zig is a lot more groundwork than it is in pretty much every other language I've learned, and that there's probably a good reason for this, I just don't know enough about the language to understand that reason yet.

After all, it's only been three hours...

* this is an inside joke from the I2 Team days...