Using Zig for this project has been great. I opened two Zig PRs based on doing this work 25561 and 25538. I am trying to figure out how to use the zig build system as a next step. Also wondering about using the atman/zg project from codeberg for utf8 decoding, but I am not sure yet what the pros and cons are vs the std library.
I am using this new Zig code on the ecoji.io website because its wasm file is so much smaller than the previous wasm generated by golang. For the wasm file on the website, I built it using ReleaseSafe out of an abundance of caution. If I build w/ ReleaseSmall then the wasm file is really really small, but I wanted to keep safety.
I set up an automated build for the project on codeberg. That is working well. However one concern I have is it pulls zig directly from the ziglang servers w/o using mirrors. It does use caching on codeberg though, so its only done that pull once so far for many builds. Want to improve this.
Not that I am aware of, its something i created for fun and to learn. I initially came up with the project to learn golang. After posting it, people opened issues and PRs about incorrect usage of unicode and using characters that are too similar or not interesting. Their PRs led to ecoji v2 that fixed those problems. Someone did try to use it in their application and reported that it has too many characters that are similar. They concluded they needed a smaller set of highly distinguishable emojis. Ecoji uses 1024 emojis because at the time of creation there were >1024 and <2048 emojis, so 1024 was a greedy choice. To be useful for something like visual verification of an encoded hash, it would probably need a smaller set than 1024.
As an interesting alternative, I came across GitHub - jacobsandlund/uucode: uucode - fast unicode library in zig today and it looks really interesting. From what I can tell it is based on some of the unicode code in Ghostty and doesn’t require allocations which is great.