Read a comment on Ziggit that just made my day. One of the things I've been enjoying while learning Zig has been that it's a fairly new language. This has some unusual and unforeseen benefits. Also I've been able to see first hand how LLMs are just wrong if they haven't seen the right things. Most of Claudes answers are just wrong. Which I quite like as the crutch is non-existent. I have to do it the old school way of reading the code and just trying shit out. The language reference is really good, but the standard library docs are quite sparse. Without even thinking, I simply just looked at the code, it has been a long while since I've done this, as Go has really good docs as it's standard library is much older. Even then, it's hard to understand the code by reading about it, so if there are no examples, I usually just look at the code. It just seems like the logical thing to do. The other advantage is that, you start seeing patterns on how the language authors write in the language that you are trying to learn. I've even been able to be helpful to others in StackOverflow without the mods complaining or down voting my answers within seconds of the answer.
I'm not advocating for not having any documentation but I think we could think about documentation differently. Instead of explaining the methods, types and other obvious things, documentation could instead be about the general principles of how to use a module. Passing down knowledge that only the tribes deep inside would know. Now, I'm assuming people actually read the docs. I'll be honest, unless something is really new, I scroll down straight down to the method that looks like what I need. Sometimes only to realize an hour later that there is another method that I should have been actually using. I cannot blame anyone but myself for this. The shear length of certain documentation makes me not want to read it sometimes. Even though I'm actively trying to read the friendly manual. People have probably already tried this, only to have a bunch of other people complain about how they are finding it difficult to use the module.
Anyway, the idea is that docs are great but code is good too. We are programmers after all. It is the source of truth after all. See don't read.
I don't fully understand the reasoning not to have a string type in Zig. But I agree for different reasons.
Sometime this week, I came across this proposal to include a string type in Zig. A year or two ago I would have agreed, but without even reading the proposal I was hoping that they would not go ahead with this proposal. The only reason I would have agreed a couple of years ago with the proposal is because I did not understand what strings were in terms of programming. Probably because in the higher level languages, it's abstracted away to the point where things are just expected to happen. You can do anything. But as you go deeper down the programming language layers you realize that everything is really just bits. You hear this all the time about programming, I certainly did, does not mean I really understood how my code translated into bits. I still don't completely, it's better than it was, there is still a long way to go, and I'd like to do some assembly programming in the years ahead.
Back to strings, since I've been programming in Zig I've never once missed not having a string type. After a while you just get used to working with u8s or []u8s. It's not that hard, it's not easy but it's certainly not impossible.
It's probably why I feel, getting good at Go has helped me become a much better programmer. It's made learning Zig a lot easier, than it would have been if I had gone from JavaScript to Zig. It's kinda ironic how I did not like programming in C when I started out as I could not understand how you went from C to programs outside of the terminal. Now I find myself wanting to write programs at a lower level, after having done years of JavaScript. Although without JavaScript I would have never gotten this into programming. I still write it, will continue to do so. It's awesome. So is programming at the "lower" levels.