cturtle

One of the new features I found interesting, declarations for global variables, is buried in the reference manual. Here's a link to the section that discusses it: https://www.lua.org/manual/5.5/manual.html#2.2

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.

I’ve absolutely had satisfaction with my several personal projects written in Zig. And based on an imperfect measurement (GitHub stars) I have also had moderate success in making something useful. It’s a terminal fuzzy finder [0]. I also maintain a Zig Lua bindings package [1], and I’m working on a port of an old Macintosh game [2].

Zig is exactly what I want out of a language though, so take my opinion with a grain of salt :)

[0]: https://github.com/natecraddock/zf

[1]: https://github.com/natecraddock/ziglua

[2]: https://github.com/natecraddock/open-reckless-drivin

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

Firenvim may be a partial solution: https://github.com/glacambre/firenvim

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.

Thanks for reaching out! At the moment I can't think of anything specific. It was just some small papercuts that added up enough to prevent me from using it regularly, not a lack of features. But lite-xl did show me that building a text editor isn't as difficult as I first thought, and I now have many ideas for my own personal editor that I might make one day. If I ever give lite-xl another try I'll be sure to share any requests

The other replies are correct, but there is a bit more to it.

Lua is a very small language with a tiny standard library. To extend it you write modules in C (or another language with bindings). This allows connecting the Lua code to various libraries. A notable example in lite is SDL. Without the C code in this repo the Lua code wouldn’t be able to use SDL for drawing or inputs

Lite (and lite-xl) is an amazing little editor. I especially love how fast the program opens. There’s just a few small things that bother me enough to keep me from using it, but I remain impressed by the code and how lightweight it is.

That’s because “proper” macOS apps close windows not apps when you click the little red dot in the upper left. See some of the answers here https://unix.stackexchange.com/questions/4618/why-mac-applic...

And I agree it’s different from all the other operating systems, once I understood why it made sense.

For example, I can copy an image to my clipboard, and open Preview. No window opens, but the top menu bar shows that Preview is open. From there I can choose the “new from clipboard” entry. It’s just a different model of interaction.

Maybe the runtime safety in debug builds? Like for out of bounds, int overflows, etc. In my zig projects those checks have saved me from using a debugger or valgrind in many cases.

As others mentioned, yes! If you’re curious on how it works I write a sort of deep-dive on the git internals of how this works: https://nathancraddock.com/blog/2022/custom-git-commands/

I clicked the link expecting that song, but the performance was entirely unexpected. Very strange!

Yes not everything can be imported perfectly. With my project making a Lua wrapper library in Zig I had to fix a few poorly translated macros. Overall though most translated just fine.

I think with some work on Zig’s end a few more cases could be handled though.

Thanks for sharing this! I have a project on the todo list that this will be perfect for!

Among all the other suggestions, I appreciate the refinement to the type system that zig has over c. Like bools and ints are distinct types, built in slice types to associate a pointer and length, arrays have a length, well-defined integer sizes (i32 for example), optional, errors, etc. it’s little things like that which make a language much easier to use in the long run.

Just finished reading the daily Calvin and Hobbes comic before coming here. Here’s an RSS feed [0] if anyone is interested.

[0]: https://www.comicsrss.com/rss/calvinandhobbes.rss

Yes I do find it painful. Because rust’s memory safety restricts the number of valid programs, it is (to me) more difficult to write code. That’s not a bad thing though! It’s just not a trade off I’m willing to make most of the time.

If my project requires the memory safety that rust offers, I’ll choose rust. But most of the time I’ll pick something else to lower my mental load when coding.

This is great. There are so many nuances in UI design and I hadn’t considered this before.

Does anyone know of other resources like this that explain easily missed UI best practices?

You do have a point, it is annoying. I’ve written thousands of lines of zig code at this point, and I still frequently have to go back and fix things when the compiler informs me I left a variable or constant unused.

But I think it is less annoying than trying to figure out why things aren’t working at runtime. It’s an interesting trade off, but I appreciate zig trying something different here.

Exactly! The idea is during development you use the super fast backend that supports hot code swapping. Then when you want to make a release build you use llvm and get all the optimization benefits of a longer compilation.