cturtle

I love Organic Maps! I don't use it for driving, but I do use it regularly for hiking. It is reassuring to know that even if I don't have service I can open the app and can check to see if I'm still on the trail. Highly recommended! I'll have to try navigation sometime.

It’s not often I come across someone familiar with Islington. I also highly recommend his books, The Will of the Many is my favorite read this year.

I keep hearing good things about Cradle, I’ll have to give that a read.

Maybe you compiled in Debug rather than a Release mode? There is also definitely enough time before Zig reaches 1.0 to improve things.

In addition to the other answers, this is the most logical way to handle most errors in this specific type of code. The http code in the Zig standard library doesn’t know how the programmer wants to handle all the errors, so it uses try to bubble up any error it doesn’t know how to handle.

Why so many uses of try? Because Zig is all about readability, and anytime you see try you _know_ that the called function can possibly fail.

No I hadn't considered that. I wouldn't be against my "zf algorithm" being ported to other tools though. But when I first had the idea for zf I had just learned Zig and it seemed like the perfect way to practice with my new language.

> Kakoune does the same

Great! I’m glad I’m not the only one to have thought of this simple idea :)

Author here! I’m aware of the FZF search syntaxes. They are very useful! I designed zf to be a small tool that worked a bit better for me by default without special syntaxes.

I value simplicity and control.

Zig is a very consistent language in syntax and semantics, so there are a small number of features I need to be concerned with. My understanding is that once Zig reaches a stable 1.0 the language will not change. Although there is a lot of churn right now, I appreciate the idea of a language that is simple, and stays simple.

The code is also very readable. I haven't found another language (yet) that I can just open up the standard library source code and understand just about everything. With no hidden control flow I can easily read a function and not have to question what a line of code does. Everything it does is right in front of me.

I also love that Zig is trying to fix many of C's problems. Rather than a global libc allocator, each function that can allocate (by convention) accepts an allocator as an argument. In my projects this has been really great for understanding what code paths allocate, which has made it easy to package my fuzzy finder as an allocation-free Zig module and C library.

Now, if I were working on a project with more critical safety requirements, I might consider a different language. But for most of my personal projects Zig is exactly what I need.

GSoC was a great experience. It was my first time planning a major contribution to an open source project. It would have been much more challenging for me without the help of my mentor and the other core contributors, so it is important to have a good support system for any involved.

My projects were focused on user interface improvements, so I also spent a lot of time gathering feedback from users. It was really valuable for me to learn how to get feedback at different stages of the development cycle, and also to learn how to filter the good from the bad feedback.

I hope Gitea is accepted!

I did! I did the Google Summer of Code twice with Blender and ever since I find myself preferring the patch workflow of Phabricator over the merge/pull request found elsewhere. I am comfortable with both, but phabricator just clicked with me better

It’s fitting that this is on the homepage because the Qualtrics CEO is named Zig /s

The linked post mentioned that the compiler itself does compile faster, but not by much. Memory usage is the greatest impact of stage2.

The speed will come when the native backends are finished. Right now the compile time is mostly llvm. The idea is a native and fast backend for debug (development) builds, and llvm for optimized releases.