Location: Tbilisi, Georgia
  Remote: Yes
  Willing to relocate: Yes
  Technologies: Rust, Nix
  Résumé/CV: https://alurm.github.io/cv.pdf
  Email: alan.urman@gmail.com

Software engineer, open source maintainer. Systems programming, developer tools, Unix.

Yeah, I've added macros `vec_len` and `vec_ptr` (or, enums, actually), which help somewhat.

`arr[3]` should be flagged by the compiler it is known to the compiler that you're operating on an array.

You can pass `arr` as `&arr` to functions, then compiler will know the length of the array since the type would be `T ()[2]`.

And you can then use it like this:

  void f(int *(*ints)[2]) {
      for (size_t i = 0; i < (size_t)vec_len[*ints]; i++) printf("f: %d\n", vec_ptr[*ints][i]);
  }

Curiously, this is a rare case where the "inverted" `a[b]` requires less typing compared to `(b)[a]`.

A compiler will not be able to flag `vec_len[ints]` though, which is unfortunate.

Thank you! I implemented this pattern initially about a year ago, but decided to write about it now. Since you liked it, it wasn't for nothing. :)

You're right, I added some more clarity in the README.

Interestingly, I think my approach will work fine on CHERI, since the pointer is never dereferenced, but I didn't test this. But yeah, there are some architectures where it would fail.

Good point! Added `vec_ptr[vec]` and `vec_len[vec]` helpers to mitigate this somewhat.

Thanks for mentioning it, I've heard about stb, but this time around I actually looked at the code. Their approach is very nice.

Making a strict subset of some existing language (Go) be a "better C" is quite an interesting idea compared to others (D, Zig, Hare, C3, D, ...), haven't seen it elsewhere. No new syntax. And Go seems to be a pretty good choice for this. Not sure if it's gonna fly though.

Yes, but you can generate JSON with other tools easily. home.md describes how you can do it with Nix, but just as easily you can use Cue or something else.

Edit: mentioned this in the README explicitly. Thanks!

You could at least use Hujson[0], which adds comments and trailing commas; makes for a more convenient editing experience, at the price of an additional parsing step.

[0]: https://github.com/tailscale/hujson

Yeah, in general (a bit of a tangent), ideas from Plan 9 are really powerful. For example, the Acme text editor exposes it's API as a file system (it's represented via Unix sockets in plan9port, but FUSE is available as well there). It's easy to write scripts to manipulate the editor, and quite fun.

I 100% have been inspired plan9, not actually a tangent at all!

I never spent much time in Acme. I did use wmii as a daily driver window manager for a number of years, which was also 9p based! I wasn't great at scripting it, and the docs have always been basically non-existent for it's 9p interfaces... but I did poke around and look at things, which was super easy to do because it was just a filesystem! I did find this short example of some wmii examples, inside a Chicken Scheme 9p write-up, which is lovely to see online: https://wiki.call-cc.org/eggref/5/9p#utility-procedures

It's a fine distinction, but I do like json2dir and my own work a bit more than 9p because with apps that expose 9p, if the app goes away, so does the filesystem! 9p is an interface to talk to some process state. But if you just keep state on the regular filesystem, it will stick around & persist beyond the life of the process. The downside is your app needs to watch for that state changing, needs to be able to reconcile changes as they happen. On the upside though, now you can use a lot of great filesystem utilities: for example btrfs or zfs snapshots or incremental-backups are going to work as usual!

Being able to easily script your world is-I think- a missing key to unlocking personal computing. Different technologies discussed, but another serendipitous thread on personal computing from today: https://news.ycombinator.com/item?id=44837783

Well, if you're generating JSON with Nix, you don't have to put everything inside of one file. It would be a better idea to split it up into multiple. You can also use builtins.readFile for reading config files which don't have to be generated in a complex manner. It's up to you to choose, I just kept everything inside of one file since it makes for a simpler example.

Edit: I have updated the documentation to mention this explicitly, thanks!