How To Write Better Software With Zig - Loris Cro

Brainstorming
1

Collection of suggestions on how to write impactful, high quality software using Zig

For those who don’t watch youtube - list of suggestions from the talk: but

  • Don’t rewrite, reinvent!
  • Dependencies are technical and design debt.
  • Strive for tooling supremacy!
  • Being multithreaded friendly makes you async friendly.
  • A single assert can be worth a thousand unit tests.
  • Communicate about your project at least a little bit.
  • Make your project not impossible to contribute to.
  • The state of the art is not always great.
  • Be deliberate about your relationships.
  • “No watercooler complaints.”
  • Your greatest contributtion to the echosystem is being the best version of yourself.

It was very helpful to “try on” this list in my current project.

It would be interesting to hear your opinions,
especially since the author (@kristoff) is here and we can ask them directly!

8 Likes
2

“Dependencies are technical and design debt” is this a joke? Yea, let’s write a new GTK impl for every single project.

“Make your project not impossible to contribute to.” From what I’ve learned the hard way, it is impossible to contribute to Zig’s CI/CD segment. Maybe this notion would see an actual implementation so more people could improve the work for all the consumers.

3

You might want to watch the corresponding explanation in the video first, debt is not inherently evil, it’s one of humanity’s greatest inventions/discoveries.

Debt (dependencies) lets you hit the ground running but you give up the ability to quickly fix some bugs (it’s code that you don’t fully understand on the immediate) and you give up some decisional power when it comes to the design of the application. Depending on the nature of the dependency (how close it is to the core functionality offered to the user by your application), it might be an overall win, or a very bad idea.

6 Likes
4

a somewhat contradictory statement (because taken out of context) - we want someone to use out projects,

but in my last project (async messaging) I had several choices

  • use one of the “3rd party” Zig async IO/socket libs
  • use Zig std only

My choice was std

It’s important to just weigh the pros and cons

5

I don’t watch coding-tech-cs-etc videos (except conference talk recordings, of course). I prefer reading))

Oh, I can quickly push some code to the repository I do not own. This is how OSS should work, no? And I do not give up any power since no one can tell me how to write my project. As an example, I wanted to be able to pull head hashes from a git repo, but all dependencies were too heavy, implementing most of the git functionality that I do not need. So I just wrote my own solution to save bandwidth and cut CI/build times. Suggestions—sure, these are only welcomed. If I feel like I can do better, I push my code upstream so others can reuse it. Refusing to reuse is always a pretty inefficient approach and will actually lead to bloat and debt. Not to mention that this allows you to give consumers a great deal of flexibility.

6

actually it’s Zigtoberfest conference talk recording

7

but there is a text/sumary for those who do not want to watch the video, so i didnt checked.

2 Likes
8

I too found the bullets questionable. But the video clarification is quite good. It’s just the bullets that does not convey the point with 100% clarity. So they should probably not be listed in short form like that.

2 Likes